Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.7K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 326 Dynamics CRM
- 110 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 994 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
A typical implementation problem: whose fault is it?
Shenpen
Member Posts: 386
Dear Friends,
after 3 years of suffering I thought I know all the tricks on how to implement Navision in an easy way, but now I still meet with such annoying problems... I will tell you one typical problem of our current installation and please tell me whose fault it is? Is it Navision fault, user fault our my fault?
The situation is the following: there is a central warehouse and 5 stores selling clothes.
Every day inventory in stores is replenished by Transfer Orders. They are generated automatically (not by Req. Wsheet but my code). Almost every time, there is some error: they ship a different item than that is on the order. Usually it is a slightly different color or whatever and then they ship a light yellow instead of the dark yellow one on the order. It is a common mistake. Yes I know the correct solution would be to implement some kind of barcode checking, but that's a future plan.
So, when they send wrong items to the stores (when there are some different items on the shipping note than in reality) there is no straightforward way to correct it.
My solution to solve this problem whas the following:
1) Receive those goods you "agree" with (because you physically got the same goods.)
2) Receive the wrong goods on a different receipt in order for the Transfer Order to get deleted.
3) There is a new button on the Transfer Receipt, called "Send back". This is my code. It creates another transfer order that sends back all the goods on the receipt.
4) Ship the new transfer.
5) Call the central warehouse and tell them what other goods you want (or create another transfer manually for that) to have sent to you in Navision that you received physically.
It is a very complicated process. It took weeks for users to understand it's logic (why do I have to receive something I did not get physically?) and everybody hates is, including me.
In the legacy system, it was very easy, because it allowed everything: negative inventory in In-Transit warehouses and whatever.
My question is: whose fault is it? Are the users dumb? Is Navision too stiff? Or is it me who would have had to come up with a better solution? After 3 years and thinking myself of a C/SIDE "guru", we still have 30 similar problems on all projects, always running out of days sold and whatever.
Is there a conceptual solution of all sufferings of this kind?
after 3 years of suffering I thought I know all the tricks on how to implement Navision in an easy way, but now I still meet with such annoying problems... I will tell you one typical problem of our current installation and please tell me whose fault it is? Is it Navision fault, user fault our my fault?
The situation is the following: there is a central warehouse and 5 stores selling clothes.
Every day inventory in stores is replenished by Transfer Orders. They are generated automatically (not by Req. Wsheet but my code). Almost every time, there is some error: they ship a different item than that is on the order. Usually it is a slightly different color or whatever and then they ship a light yellow instead of the dark yellow one on the order. It is a common mistake. Yes I know the correct solution would be to implement some kind of barcode checking, but that's a future plan.
So, when they send wrong items to the stores (when there are some different items on the shipping note than in reality) there is no straightforward way to correct it.
My solution to solve this problem whas the following:
1) Receive those goods you "agree" with (because you physically got the same goods.)
2) Receive the wrong goods on a different receipt in order for the Transfer Order to get deleted.
3) There is a new button on the Transfer Receipt, called "Send back". This is my code. It creates another transfer order that sends back all the goods on the receipt.
4) Ship the new transfer.
5) Call the central warehouse and tell them what other goods you want (or create another transfer manually for that) to have sent to you in Navision that you received physically.
It is a very complicated process. It took weeks for users to understand it's logic (why do I have to receive something I did not get physically?) and everybody hates is, including me.
In the legacy system, it was very easy, because it allowed everything: negative inventory in In-Transit warehouses and whatever.
My question is: whose fault is it? Are the users dumb? Is Navision too stiff? Or is it me who would have had to come up with a better solution? After 3 years and thinking myself of a C/SIDE "guru", we still have 30 similar problems on all projects, always running out of days sold and whatever.
Is there a conceptual solution of all sufferings of this kind?
Do It Yourself is they key. Standard code might work - your code surely works.
0
Comments
This is quite a common problem in complex implementations, and it is a combination of the users not explaining their process well enough for you to understand, and you making assumptions about those processes. I have seen it many times that the onsite consultant *thinks* they understand the process, and goes out to lunch with the project manager to 'be important all day', instead of going through every possible scenario with some actual users to flush out those situations.
The fact is, Navision works a certain way. We can argue about whether or not this is 'too stiff', and we would probably agree on a lot of the arguments you have against certain standard Navision processes. Your job as a consultant is to discover the process in their legacy system and point out the differences to the customer, so they are part of finding a solution/work around in Navision, so that when they run into those issues, you *know* that they were part of deciding whether this was acceptable.
It is not any one body's fault, but a combination of events that lead you to this, and if you're smart (which I think you are) you learn from it and maybe be a little more humble in your next implementation.
By the way, it is simply IMPOSSIBLE to discover ALL discrepancies. There is no such thing as the perfect software solution. There will always be surprises. It is your job to prepare the customer for the fact that they WILL run into unforeseen scenarios, to set that expectation.
RIS Plus, LLC
Because of this, it is very important to stress the point of accurate item handling right from the beginning when Navision is implemented . It usually takes months ( sometimes years) for the end-user to understand what Item Cost Adjustment means and how it works in Navision.
We have clients with "Various Items" , that means several items with item costs ranging from sometimes below 1 EUR to over 1000 EUR handled with the same item no. It took me almost 2 years of persuasion to convince the client that this had no future if an accurate inventory valuation is required.
tell doesn't mean hear
hear doesn't mean understand
understand doesn't mean comprehend
comprehend doesn't mean perform
(I am not sure with exact translation)
You need some feedback mechanism to know, that you understand and you are making it in a good way (for example prototyping with customer etc.). And you need to ask correct people (not the bosses, but the target users). Because from boss you can get answer for questions like "what is your target for your new IS", but from users you have answers for questions like "how you are doing this, and what you need to do if..." etc.
How it will work inside, it is on you. Best module is module, about which you are thinking for few days and after that you add 3 lines of code somewhere and it is working :-) (of course, only if the customer pay that). I know that from my experience, when we needed one big customization in manufacturing, my co-worker was thinking about it for 8 days, after that he told me the plan, I was thinking about it 2 days (going through codeunits etc.) and after that, I added about 10 lines of code on 3 places and it was working... :-)
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
Yes, it is something I have often heard in this forum, and could never agree. I mean when a company is sacrificing 5% of their yearly sales (yes, sales, not margin - maybe around 30% of their margin) to gain a competitive edge by implementing Navision then the least thing they want to hear is that there will be problems. Would you want to hear that in your new $150 000 some things will be really hard, compared to you legacy $10 000 software? People buy ERP to be more effective, not to less.
Would that be a honest business practice that after salesdroids were schmoozing for half a year and kept saying "Oh, it is a perfect software, it sells your products by itself and bank notes come rolling out of the floppy drive." then after the contract is signed, then go there, and say "Well, folks, you will suffer like hell until you learn to use it!" ? This would simply be not honest. IMHO the only thing we can do is to foresee 10 steps like a chess player, and hack with lightning speed to make N. usable.
The problem is that it is like a race and I always feel to be losing it - I can foresee and pre-hack 10 problems but there is always the 11th. one.
As for 3 years is not much... damn, were Navision be properly documented, 3 months should be enough. What other job is in the world you cannot learn in 3 months to a well-average level? Usual learn-in time for a programmer or accountant or whatever is no more thant a few weeks.
[/quote]
Do It Yourself is they key. Standard code might work - your code surely works.
Which means they don't have to understand it. Either we must convince people to use Standard Costing, or to hack things up and down until it will be rock-stable.
Again what I can say is that people buy ERP to be more productive. It means that we cannot demand more from a warehouse employee than to shoot a bar code, enter a quantity and press "This has went out of the stock." Anything more hurts productivity, which ultimately leads to heated debates with the customer who feels cheated - and rightfully feels it.
Do It Yourself is they key. Standard code might work - your code surely works.
As for doing simple changes, I cannot agree. Recently we got a Request for Proposal - there was a legacy system in Delhpi, and we should implement Navision in a way that the UI would remain the same (so, recreate the forms of the legacy system in Navision). Yes, we laughed our asses off too, and the gave a proposal of 400 days, just to reply something. And later on I thought that wow, after there is a serious proposal, then everything else is just negiotation, so maybe we will truly have to do it... [-o< Luckily, someone else won with about 250 days or something like that...
But this funny story shows something: people really expect that N. is nothing else but a more automatic version of the legacy system.
So we cannot get anything working without making forms simpler, change the terminology to similar as the legacy system, in short, to create at least some metaphors that users can start to understand the system.
To go back the fault question, might it not be a customer fault that they don't check N. before buying, but don't even try to get the the concept of ERP itself before buying? Or maybe we should have educate them... but I don't think anyone would like to hear a sentence starting with "The concept of ERP was basically designed for report-reading managers, not user productivity, so don't expect anything easy..."
Do It Yourself is they key. Standard code might work - your code surely works.
No, you do not need to change forms (in a big scale) etc. You need to change mind of the people. Customer must know, that he is not buying his old ERP with new face. He is not buying his old ERP with more functions. He must be buing Navision as tool for his better profit, overview, grow up, dynamics, opprotunity, possibility, etc. He must know, that if he will need something to change in his processes in some time, he will be able to do it. He must know, that if he will use Navision, and he will have more employee, it will be no problem. If he will buy Navision as his new tool to growing up, he must know, that it take some effort from his side to work better. Because new ERP is not only new Software, but better work organization... And when implementing new ERP, it is best time to reorganize processes to work better.
Customer buying new ERP which do not want to change anything in his company, do not understand what he want to do. Of course, the changes cannot be like "we must do it in this way, because Navision need it" but "we must do it in this way, because it is better for us".
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
RIS Plus, LLC
Inventory might be a sensitive part, but you can have huge surprises in all every part of the system. I remember, it was two years ago, I was around the end of my second project, and felt somewhat confident that the worst part of my career is over. And then N. started to put holes into invoices: I mean Postes Sales Invoice No.-s 1,2,3,4,and then 6,7,8... Here in our country the tax bureau eats one alive for this, because they smell cheating in such situations. And investigated and investigated... and then I found that posting an Invoice from an Order and that is not successful, because there is an error, reserves a number - and if that order is later invoiced from a separate invoice, then the hole caused by the reserved number stays there forever... I was furious... I just couldn't believe. Not that such things happen, because no design can be perfect, but I was furious because no one told it us.
And yes, this I think what is the fault of Navision A/S / Microsoft in these situations: not writing a number of FAQ's, not writing tons of 'most common issues' documents, not being honest in documentation and writing stuff like "beware using this function, this and this problems are possible".
I think what we have here is the old "inner circle" problem. I mean that every consultant company in Denmark where there is still 80% of the Navision sales; and the big, established constultant companies in other countries, like LS in Iceland, NaviConsult in Austria etc. has people with 8-10 years of Navision experience, who 1) cannot really find more surprises, because they know them all 2) they are in the inner circle, they have a close relationship with the core developers, and if they find any problem, they just write a personal e-mail directly to a core developer saying "Hi Eric, please check this out."
I am sure and more and more sure everyday, that at least in the age of Navision A/S, there was a definite "inner circle" of consultants around the core developers, who received the information of possible problems in semi-formal ways, and it was these kind of consultant companies that were successful. It's just a classical "old boys network".
Everybody else, a simple, average company starting a new Navision business stream and hiring two young programmers and one young accountant to go learn Navision from (almost useless) books and trainings, and not being in the inner circle where the information flows semi-formal ways, I am sure that always suffered the same way we did.
What could I achieve in 3 years on my own, without help from the inner circle? Now I can guarantee that if you have a proposal of 80 days we finish the job in 110-120 so we will have some profits at least. is that a succes? I don't know. I have seen dozens and dozens companies going bankrupt by trying to be a Navision implementor, because they sold 50 days and then worked for a year until everything worked properly. Compared to that, it is success. But does ERP has to be such a bad business? I don't think so, and I think it is not our fault.
I think Microsoft is willing to break up this inner circle secrecy and is willing to treat all partners as equals. There are many signs to this. I will look forward for doing so.
Do It Yourself is they key. Standard code might work - your code surely works.
But if people are completely unable to comprehend and use it, then it can be only two solutions: either they are dumb or there truly is a usability issue. But they are not dumb, they are right that they should not be forced to do some rain dance to accomplish simple things... isn't it right? And I am trying to dumb down things as possible, but when people or not understanding the concept of Direct/Indirect Costs (for example) itself, then what?
Do It Yourself is they key. Standard code might work - your code surely works.
We have a client which in their old ERP system were used to e.g. purchase 1 pce for 100 EUR and then break this up for sales into 100 pce for 1 EUR. In the old ERP system that was possible because only the valuation amount without the quantity was used. After being told that in future they had to always use the actual quantity ( or use BOM to split the purchase up) and ensure that the item cost was correct in all credit memos they were somewhat shocked. Item handling in Navision is not as easy as some people make it out to be. If all the rules are followed, usually it will work out. But it demands concentrated work on every day for the normal end-user as well as lot of know-how of the working principles for the client's accountant who has to answer to the public accountant as to what "is going on".
The customer came to you with a problem, you proposed a solution, that would not meet there needs.
Just my opinion
David
Are we living on the sames planet? Have you ever allowed to talk to customer before selling, and allowed to say "no, we don't have a solution to your problem, our software is too sophisticated to you, we don't want this sale, thank you" without getting eaten alive by every manager and salesman who looks at nothing but profits? :shock:
I have never ever met a would-be customer that would come to me for requesting a solution to a problem. I have met with people who thought like
"Employees are complaining... okay, change the ERP. What did I see in my mailbox, marketing from SAP and Microsoft? Okay. Well, let it be Microsoft, because I like MSWord. Let's go to the salespeople. How much does it cost? What? What do you want with this 100-pages proposal? What's all that service and consulting about? Just tell me one figure, in short sentence, that how much a goog system costs. What are my requirements?... well... it shall be good. Yeah, good. " And it's all with the salespeople.
And our salespeople? "Let's sell something, I am under my quota... what do we have? Servers, hardware and Navision. What? This guy is complaining something about a warehouse? OK, let's just sell Navision!"
And only after these two kind of people signed a contract do we actually meet. Okay, I hold a 2-hours demo, but that's almost nothing.
Do It Yourself is they key. Standard code might work - your code surely works.
Net result : an unmaintainable and unupgradable installation of Navision, an NSC in money problems, a customer that feels betrayed (allthough the customer is partly to blame) and an IT department that is very frustrated.
it is interesting that we both are from countries with similar economic realities and the reality we experience is so different - why?
And then what? Then they just go to someone else. They go from the capitol to the countryside, where they can surely find an entrepreneur who promises everything on a low cost, because he has 3 programmers who are willing to do the worst kind of work 12 hours a day, because there are no other jobs in the area.
But who we could tell them what they should want? We are the vendors, after all. (And don't even try to convince me "No, Microsoft is the vendor." - no one ever, ever accepts that - why would they, when they don't have to? ) I would be really surprised the next time I buy a hamburger the clerk said "No, you are too fat for that."
Another thing: a typical implementation is going from a very-very productive, but we hard to have any reports/analysis $10 000 operations software to a quite unproductive, but very well analysable and reportable $100 000 Navi. Is that a way of making dynamics or better profit? Yes, we can make Navi productive if got a 100-120 days project and a deadline of 3-6 months (as opposed to the usual 1.5 -2 months we are forced to accept), but without that?...
I smell a fundamental error here. A company of a yearly sales of $50M does have processes, which can be reorganized or not. A typical Navision client with a yearly sales of $4-6M does not have any processes at all - they just work the way we do: solve problems one after the other and that's it. They grew by hiring people if someone complained of being overburdened: never been an organizational structure defined. And it means it's not just changing processes, it is of establishing processes, a very big BPR. I don't think we could do that within a typical 2 month project.
Actually all the problems I see typically not process-related, but related to the individual effectiveness of users. If you could create 30 invoice per day in the legacy system and now you can 25 that means you will have 1 hours of overtime every day. And that will make you angry.
You know big companies live of organization, SMB-s live of individual talents. This is why the big ones seem so dumb and ineffective. I am starting to think that the original concept of ERP itself was designed for big and ineffective corporations... [/quote]
Do It Yourself is they key. Standard code might work - your code surely works.
Almost got the point, almost
1. In reality, there is usually no internal IT for a Navision-size company.
Paying a sysadmin for 20-40 white collars (those whoe have a computer) would be an overkill - or so they think.
2. I have never seen consultants who would abandon a customer. I have seen managers order them to do so but ususally the are empathic with users and support them in their free time for free or whatever.
Do It Yourself is they key. Standard code might work - your code surely works.
Why is that, my friends, that the most often used buzzword in our industry is "business process", when actually business processes have almost nothing to do with implementing Navison?
The reason is simple: what business processes can we implement in Navision without rewriting half of it? We can implement something like Jill creates and order, Jim ships it and Joe invoices it. That's not a "process", but the most trivial way of working every $3000 Clipper-based DOS program supported in 1995. And then? Jill generates a manufacturing plan, Joe reviews the orders, Jack hands out the materials. Well, you can bet that they want to do it in a completely different way Navision works. Usually one guy will do all 3 phases and will find UI such too complicated.
One of the most important developments we make is to "join" steps in the workflow, fow example: import items in the Items AND generate a Purchase Order, because for many companies this is one logical step.
And beyond that? We can help with around 20% of business processes - the most trivial ones - with an unmodified Navision. We can help in the "from quote to invoice", and the "from RfQ to vendor invoice" and "from low inventory to Finished Prod. Order" process. This is around 20% - the most trivial processes. How could we help, for example, to measure vendor efficiency with an unmodified Navision? At least a new report is needed, but usually much more. Now, that's an important process, to choose your vendors carefully, yes. Shipping, receiving, handing material in and out etc. is just trivial, a simple must-have, but not a competitive advantage. It can be a competitive advantage us, as there are many ERP that cannout even produce a proper invoice in a reliable way. Actually most ERP software is so amazingly bad, buggy, badly designed and outdated that Navision with it's barely acceptable capabilities shines like a diamond compared to them. I never understood how can one use iScala for example, without shouting the hair off the vendor...
So, actually,Navision is not business process automation tool. It is an operations and accounting - well, somewhat automation, but mostly administration tool with excellent and wonderful top-management analysis capabilities and almost nonexisten mid-management analysis capabilities.
It's an excellent financial accounting/controlling backend software half-heartedly turned into a well, barely acceptable frontend operations software with almost nonexistent controlling/analysis of the later one.
So why are we always talking about processes anyway?...
Do It Yourself is they key. Standard code might work - your code surely works.
Thank you for reminding me of why NSC work was so stressfull:). I feel your pain and that is about all I'll say about that.
I traded my sanity for a railgun
If you ask the employee - what are you doing with this document? They sey "I give it to Tom". Then you go to Tom and ask him "what are you doing with this document, Tom?" he answers "nothing, sometime come Jane and takes all the documents." There is space for you to say, hey "Why you are giving the documents to Tom? You can give it directly to Jane!" - and this is your main help to the customer. Help him with their work, organize their work. If they have no such a management, which organize their work, it is on you. If you will try to implement ERP in such a company without organizide work, you will never be sucessfull. Why? Because one ask you for something, you will implement this,but in 2 weeks come someone other and ask you "hey, why I must to enter this there? I do not wont to enter it. I want it in this and this way, change it!" And you will change it and change it ....
Do not forget, that each change in SW application after going live, is more costly than do the change during implementation and you will have more and more bugs and problems. If you solve all main processes during implementation, the cost of the ERP is much lower.
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
It's interesting that you said all post-implentation changes are harder... actually you know I created and scrapped many theories how to make implementations easy, and one of the ideas working best actually the opposite:
1) Get to go live as fast as you can as no one will listen to you seriously, will not disclose requirements seriously, test and practice seriously etc. until they really got other chance than use it.
2) Have users enter problems and change requests in a web-based bugtracking or Change Request / Trouble Report tool, where you have issues, statuses, developers assigned etc. It just keeps things manageable.
Actually what you write is basically right, if we could some way make customers pay serious attention to us before go-live. But we can't, because, for example, they usually take it for granted that all functionalities of the legacy system exist the same way in N. so they don't even tell that isi a requirement.
And yes, this was the most important thing I learned from this topic, and it's from a former post of yours: while all implementation methodologies start with "analyse processes", it is just plain wrong, the right way is to "study processes as they are modelled in the legacy system. This is a big difference, and thank you for the idea. The best start of a project is to become a competent user in the legacy system, which I think we can do in 2-3 days, no more.
But... why aren't you and basically nobody else in this forum is supporting my claim that Navision A/S / Microsoft supplied us with inadequate documentation and it is the cause for a high proportion of our problems. Inadequate documentation means they just write "If you press X , Y happens." And they never wrote "Companies selling Z usually want Y to happen, in order to do that, press X." No FAQ, no case studies with in-depth analysis for most industries, no common problems document... in short, complete lack of the "optimize for the common case" kind of view. Although it seems Microsoft slowly starting to recognize it much better than Navision A/S ever did - the Express tools are an order of magnitude better usable than the ridiculous OnTarget. OnTarge never said "this and this is a common requirement and you can achieve it by X and X". Express does. Still, it is too idealistic...
Do It Yourself is they key. Standard code might work - your code surely works.
Dear Dakkon,
yes, that could be cool
ONTOPIC
Do It Yourself is they key. Standard code might work - your code surely works.
I have been a worked in the system integration business for over 17 years. During this time I have worked with several of the middle-tier accounting system and have spent significant time in both developer and implementor roles. Most of this time has been spent as an employee of a company that was either a NSC or reseller of another accounting system.
Navision and similar products are intended to be sold along with supporting services. That is why they are sold through an authorized channel and not off the shelf at the local software discount store. Unless Microsoft intends to change this marketing strategy, I would not hold my breath waiting for "Navision Implementation for Dummies" to be published. (My appologies to Wiley Publications) How many people do you run into that say they are an implementor/developer for QuickBooks?
Shenpen:
if you think you have learned all the tricks after only 3 years of "suffering" then you are only fooling yourself. The problem you describe in your initial post, appears to me to be more of a business operations problem than a technical issue. TECHNOLOGY IS NOT A SOLUTION FOR POOR BUSINESS OPERATION PRACTICES. Your client needs to understand that his real problem is a follows:
1. His warehouse employees are picking the wrong products for shipment.
2. His legacy system contributed to the problem by allowing it to continue and excepting the incorrect item information.
3. Navision has brought the issue to his attention through stonger enforcement of business processes.
As far as who is at fault, I think everyone (software publisher, salespeople, implementors, developers, and customers) have a share of the blame. (I am not excluded from this group).
A big part of this job is about listening and observing. No matter how many documents Microsoft publishes or how many books you read, you will never understand your client's business better than they do.
To be continued....
[/b]
I would like to comment on this topic since this is a common and hot issue in every ERP implementation, not only Navision. I have some point to share :
1. Structurize your implementation project even it is small project.
You can not do it by yourself, 'we are not superman'. You need a team to perform an implementation, not only a developer. One crucial element in your case is where is your business analyst (BA) or application consultant whose resposibility is to understand 'business process'. The BA will communicate with user and the developer to achieve best solutions. That's why you are so frustated since you do BA job, don't push yourself too hard. If your BA get confused or can not explain to user, then the main fault is in your BA or in overall your project management is bad since you have not having the good BA. In this case I will say this is NSC fault.
2. 80% of ERP implementation is human, rest of it is technical.
So, the problem is always communication, understanding, knowledge and all human or social things. Perhaps you have problem with your client, means your relationship with client is decreasing due to lack of communication.
thank's
radianis
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
This is what people said about knowledge management.
So far the Navision knowledge is in anybody head who had experience it but not for everybody who are new to Navision.
So you must have more than 3 year experience to understand Navision.
But frankly saying since Microsoft took over Navision, there are big improvement in managing Navision knowledge.
There are better manual book (even you have to pay more...), ecourse (again have to pay..) or some Navision SCM book or this forum ....
So let us wait Navision to become better solutions... =D>