Considering Navision

Stephen_Connor

Hi All

I am new to this forum.

We are a company that is considering purchasing Navision as our ERP solution. We would very much like to contact some existing users to gauge their opinions on the product.

If anyone would be prepared to contact me, please email me on
stephen.connor@halian.com


Thanks & Best Regards
Steve

Timo_Lässer

Please do not cross post in this forum. [-X

http://www.mibuso.com/forum/viewtopic.php?t=8698

Kowa

He didn't really cross-post, only accidently used the wrong forum for his initial request.

themave

New to Navision, things to consider.

1. Make sure Navision will work with as few modifications as possible. Or modify it completely and know that you will not upgrade it later. If you have a lot of modifications, it will make upgrading, even from say 4.0 to 4.0 sp1 very difficult. And at a minimum costly. We are upgrading from 2.0 to 4.0 now and our solution provider will not even consider going to SP1 until after the whole upgrade is complete. Then it will be another minor upgrade where they will have to review 600 to 700 objects changed in SP1 To see what changes will need to be made to allow us to go from 4.0 to 4.0 sp1. Now if going just to a SP1 Upgrade is a major undertaking, imagine what going from Navision to Dynamics is going to be like.
2. What you will find, in my opinion is that each major upgrade, takes some existing functionality, and makes it a separate granule, so you have to now pay an additional license to be able to use the same basic feature you already had before upgrading.
a. Examples, in 2.0 users setup allowed assigning users to department codes for purchasing, sales, inventory. Now you have to purchase the $3000 responsibility centers to get the same basic functionality.
b. Drop ship purchase orders could be created directly from Sales orders, now functionality is gone completely, you must purchase third party add-on for $1500 to get the functionality.
c. Basic bin functionality was part of advance distribution, now to record a bin code for an item, you must purchase another granule.
d. There are many, many more examples like this.
3. Microsoft (Navision) used a lot of third party developers to provide major functionality in the early releases, 2.0 advanced distribution for example. As they did major upgrades they developed some of the functionality themselves. And dropped other parts of the program, so you could not upgrade without losing functionality, or paying to have it programmed back in.
4. When you ask about it, the standard reply is that feature is no longer supported, or we can add that back to you for a price. Or the new version as changed the underlying tables, so that is no longer available.
5. If you have modifications, you will find that each upgrade say from 2.0 to 2.6, or 2.6 to 3.1, or 3.1 to 3.7, or 3.7 to 4.0, is not worth the trouble of upgrading, as you get very little new functionality with each upgrade, compared to the cost of actually upgrading, both in the upgrade and the training of the users. You will end up not upgrading, but still paying the annual maintenance fees for the right to upgrade.
a. My suggestion would be to pay for the annual maintenance in the first year, get all the bugs worked out and stop the maintenance at that point.
b. When you find Navision no longer meets your needs then look at a new system, it could be the latest Navision or something else. Any either case, the amount you saved in annual maintenance fees, will be able to cover the entire purchase of the new system. Navision is very easy to get information into and out of, so you should be able to transition to a new system. If you stay with Navision, don’t license it as an upgrade just buy the new system and pay to have your data transferred. In the long run it will be cheaper then paying an annual fee, then upgrading and training on the new version, since the training cost will be the same either way. And starting with a new system and modify just what you now need, and converting your old data, will be cheaper then upgrading all the modifications you already had done.
6. Navision itself is a nice program, you can make simple changes yourself. It is relatively complete. And if you are willing to change your business practices to match the program, it can work really well for you. But anything complicated will require either the application designer granule ($8000) or programming by your solution provider. As you can not access cal code in forms, nor can you access codeunits. Without cal code in forms, you can only make very limited new forms or functionality.
7. Don’t be fooled by the sales pitch that it is easy to change things, if you read a few post here, the top programmers ridicule new programmers because they say things like, “ I have been programming Navision for three years and thought I new it all” the common response is “ Are you kidding, you can’t learn all there is to know about Navision programming in just three years.” Now, to me, if you are a professional programmer and have been programming for three years in Navision, you should not be considered a newbie, but the reality is you will be. Because it is a complicated program. And just by reading this forum, you will see that there are a lot of bugs, in the program, a lot of missing pieced people have figured work arounds for.
8. The other thing you learn on this forum, is that most programmers have a complete distain for the end user, they feel they know little, don’t know how to run their own businesses, and if they were just willing to pay an unlimited amount to the programmer everything would be ok.
9. I can say, and would challenge anyone to counter it. That there is very little functional improvement between 2.0 with advanced distribution and 4.0. The major actual improvements are really just bug fixes, for features that where incomplete before. This covers a 6 year period and several major upgrades. Those being: 2.6, 3.1, 3.7 and now 4.0. The major differences are a new interface, which one could easily argue is no better then the old menu system ( it only provides a common look and feel Microsoft wants for the unified code base in Dynamics) I can find very little new functionality, and find that I now have to pay more for features I once had as standard.

Shenpen

My suggestion would be the following.

The basic problem is that the concept of ERP itself is so damn complicated that it is no ERP anywhere in the world provides the same smooth, productive ,easy experience as f.e. MS Outlook or Excel.

There are two basic approaches to this situation.

One of them is the "put a functionality for every possible need into the software" - a good example is B**n. (I'd rather not type the whole name, but I think you can guess). When someone told me how deeply you can configure a purchase process in B**n I felt envy. However, these point is that it is so damn hard to program such functions that with those software you can easily find yourself in a position that it's totally buggy and half of it just doesn't work.

The Navision approach is to keep it simple, transparent, developer-friendly. With this, they managed to avoid serious bugs - even in the most buggy releases, with a handful of simple custom batch jobs we could handle them. I never seen a company just stopping shipping goods because the ERP does not work. But I've seen it happen with B**n, S****a, etc...

So, if you choose Navision, you have something that more or less surely works. However, don't even think users will be able to use it out of the box. It is amazingly complicated for a non-accountant, non-computer-literate user - you got tons of fields on an Item Journal f.e. and just figure out what to do with it. Not gonna happen. It is so because this one table, Item Journal does actually all material transactions, ever. So it is really big stuff. In most ERP, these tables are hidden. In Navision, it is just exposed to the user. The good thing is that it makes Navision amazingly simple from the developers point of view: when you create a shipment from an order, it will create and post an Item Journal Line for every line. It means that you have no more than a few thousands of line of code to investigate if you have to change something or want to investigate why something does not work the way you'd expect it.

And it means if you buy 50 development days, solution centers can make wonders. Literally, half of what you experience in Navision can be totally rewritten in 50 days to make it truly productive and user-friendly.

However, if you think in long-term maintanence cost, stability and such, maybe you don't want that. In that case, there is a good trade-off: automation. Navision lends itself extremely easy to automate. For example, if you generally have sales orders with only one or two lines, you can write a batch job that has a Customer No. and five Item No. and five Qty. and then the batch job generates the order. And it means your users don't have to grok a form with several hundred fields, just a very simple form. It can mean five times as much productivity, and happy people. And this kind of automation does not touch the standard system, upgradeable, and a solution center should charge no more thant half day for it, if they have developers that are good for anything. Moreover, these batch jobs are actually reports. So if you buy just Report Designer which also allows you 100 new reports, and ask the solution center for the following books: Application Developers Guide, Solution Developers Guide, and the third one I forgot but it is called some kind of "architecture", then you can do it yourself as well. Item Wizard, Customer Wizard, etc...

I think if you manage to keep this simple approach: don't accept the standard, don't customize, but build automating functions on top of the standard, you can have a really good ERP.

Of course, if you don't really care what will be in five years, then customize everything My clients usually force me to, but if you are clever, and don't have dreams of a perfect ERP that sells stuff by itself and bank notes come rolling out of the floppy drive, then it is better to automate than to customize. And it is easy in Navision. Easier than everywhere else.

Savatage

http://www.microsoft.com/resources/case ... d=Navision

We're on page 4

Shenpen

Themave: one thing about upgrades: I myself tend to agree with you, but on the other hand with 3.6 (when it was already Microsoft, but just in name) I spent a good 30 uncharged days to repair small, but irritating bugs. It was still stabler than many well-known ERP as the client was never even close to stopping doing business, but they were irritating. With 3.7B they were gone. There is a general rule about software: use the highest sub-version of the previous version - that is generally the most stable. Use 3.7B, but not 4.0. Use 4.0SP1, but not 5.0 when it comes, only when it's 5.0SP1 or 5.0B or whatever.

davmac1

SP1 is really more like 4.1 because it adds functionality as well as fixing bugs.
It also improves SQL Server integration.
I did find a couple of items missing from the change log (Customer card and vendor card forms), but otherwise a fairly smooth upgrade from 4.0.

kine

I think that for you is best to see Navision in real. Try to contact some reference for Navision, go there, ask people which are working with Navision and are not writing to some forums, because they know about internet only from phone bills.