The NAV Viking´s Blog 
Greetings fellow NAV-ist!
My name is Johannes Gudmundsson, AKA the NAV Viking. I have been working in the Dynamics NAV field for almost two decades. I have served in all roles from junior technical phone support to founding a NAV practice which I run today. This blog is meant to be an outlet for anything NAV related that I feel can be of benefit for others.
To celebrate that iNECTA is turning 14 today, I am going to list out important points that are often missed in 14 different functional areas within NAV.
1. General Ledger
Accounting periods need to be created and managed for all years. It is possible to post and operate NAV normally without any accounting periods set. But this is not advisable. Make sure you have created all the periods for all the years you have been operating and for the year ahead. It is impossible to close the year and post to retained earnings without them.
2.Accounts Receivable
Make sure your accounts receivable GL Account does not allow direct post. This is a simple, but often overlooked detail. If you allow direct posting to your AR GL account then your AR aging and GL might not tie out. That is the first flag your auditor will look for.
3. Accounts Payable
As with Accounts Receivables, the GL account for AP needs to also have the direct post flag off.
4. Sales Order Management
Do not overflow your customer list with accounts that you never sold to. You can quote contacts in NAV, and when the quote becomes an order, the contact automatically turns into a customer. You customer list can quickly become messy if you do not use this feature.
5. Purchase Order Management
If you are managing any type of distribution business and haven´t looked at the requisition worksheets, you should. The requisition worksheet is the piece that connects supply with demand allowing your business to elevate from managing order by order to managing aggregate demand with supply.
6. Inventory Control
Make sure you understand automatic cost posting and expected cost posting fields. Many users just set these fields to what they think they should have and move on. Not having a full understanding of these fields, will lead to confusion when deciphering the inventory and cost of goods accounts. I could probably write a whole separate blog entry on these features.
7. Warehouse Management
Understand the difference between bin management and shelf management. It is usually better to be very selective on when you turn on bin management in a location. Although bin management might solve the immediate problem of not being able to store things in bins in the system, it introduces the overhead of managing everything in a bin. If you are implementing scan guns at the same time, then the overhead is less.
8. Fixed Assets
NAV has fixed assets, so use them! For some reason many users do not implement fixed assets in NAV, and prefer to run the depreciation in Excel or another program. NAV has excellent features in the fixed asset module and can handle almost any depreciation method. It ties to the sales and purchasing systems to automate acquisition and disposal postings among other things.
9. Manufacturing
Check out the Production Journal, found in the line level on a Production Order. It is a very handy way to post consumption and output on a all-in-one page. Users often go straight into the standard consumption and output journals without investigating this little feature.
10. Jobs
There is a relatively new page called WIP cockpit which is an excellent overview of what your WIP consists of. Work in process can be a difficult account to decipher if you do not have right tools. WIP cockpit provides an onscreen overview of WIP.
11. Resource Planning
This entire area is often overlooked. Resources are an excellent feature that can be used for things that are bought and sold, but you do not want to maintain inventory for. It provides a separate ledger for each resource which can be used for analysis. Although the system does not allow for resource purchases out of the box, it can be easily extended to do so.
12. Service Management
NAV is capable of managing service items that are not actual items. For example a service company can take over existing service items that the customer has. Users often think that the system will only take care of items sold.
13. Human Resource
Even if you outsource your payroll, it is still a good idea to maintain the employee file. One nice feature, is that you can connect the employee to the fixed asset to label who is responsible for the property, such as a laptop, etc.
14. Administration
Understand the posting date restriction in NAV. You can setup restrictions on posting both on the top level for all users and the user level. NAV does not hard close periods, only years. By properly managing the allowed posting dates, you can take at least some of the chaos out of your Chart of Accounts.
Over the years, we at iNECTA have been brought in many times to troubleshoot performance. The system being for some reason slow in a business that has high volume. There are many reasons why a system can get slow and in the blog post I wanted to highlight the differences between infrastructure and application bottlenecks.
The first area people blame when the system slows down is infrastructure. Either the machine is slow or the network congested. This is the most visual to the user. There is a box on your desk and another box in a closet that blink with lights. They are connected with a wire, so any one of those three things must be the fault. The solution must be to either improve the components or replace these things. Although this is often the case and great improvements can be made by upgrading infrastructure there is another layer which often gets overlooked, namely the application.
The application layer is not as visual to the user. There is nothing you can physically touch or see. It´s just a mysterious thing that happens when the user interacts with the computer. Most people misperceive the speed of this to be only related to the performance of the actual workstation, server or network. This could not be further from the truth. An application can be badly designed or programmed and can cause much worse performance issues than any hardware could.
Most applications are installed on your computer and there is not much you can do about the way they are designed. You might be able to tune some settings, but usually that is the extent of it. You are at the mercy of what is called the application black box. You send input into the box and it gives you output. How it goes about it, you have little or no control over.
With Dynamics NAV, the consultant has enormous control over the design and programming of the application. The consultant can change the way the system goes about accepting the input and producing the output. This can result in much more dramatic improvements than the infrastructure layer. I would like to outline a very simple example that occurs too often in the programming layer and it might not be as obvious to spot to the unexperienced.
Let´s assume in our example that we have N numbered documents that are scattered in random order on one table in a room. Your job is to find a number of documents, X, and move them to another table across the room. One way to do this is to look for the first document to move, out of the N documents, and then when you find it, walk with it over to the other table and then back. This process would be repeated X times.
We can immediately see that this process can be sped up by first finding all the documents, putting them in a stack and move the stack over to the other table. If walking over to the other table would take one second we have just shaved X-1 seconds of our process. In many cases X could be in the 1000s.
How about that random order of documents? When we are looking for something which is not sorted we have to go through each one, one by one. So imagine looking for a name in a phone book that is not sorted. Let’s say it takes 0.5 second to compare. If you are looking for a document out of 1200, it would take you on average 600 seconds or about 10 minutes. Whereas if it was sorted it would take you about 5 seconds.
So if we put these numbers into formulas to compare. Let’s assume we have 10,000 documents and we have to find 1,000 to move. Let’s also assume it is a computer doing the work (not a very fast one) and it takes us 0.01 second to move and 0.01 second to compare.
In the first scenario our approximation formula would look something like this:
X(0.5 * 0.01 * N) + X * 0.01 = 1000(0.5 * 0.01 * 10000) + 1000 * 0.01
= 50,010 seconds or about 14 hours
In the second scenario our formula would look something like this:
X(Log2(N) * 0.01) + 0.01 = 1000( 0.0997 ) + 0.01
= 99.71 seconds or about 2 minutes
It is evident that the difference is incredible. We have 2 minutes compared to 14 hours. When the numbers of documents is very low, then the difference is not much, but as the system accumulates data, the previous scenario will pretty much render the system useless.
In conclusion, we can see that when you improve your hardware, you might get significant improvements. But very real improvements can be made in the actual application, when the consultant has access to how the data is calculated and manipulated. It does require an experienced person to figure out where the bottlenecks are and how to solve them. We at iNECTA have solved many such problems over the years, transforming a system that people thought was not able to handle the amount of data, to a lean, streamlined machine ready to take on a lot more.
At iNECTA we have worked with many different industries. Some tend to lend themselves well to the standard ERP methodology, others bite and scratch when you try to cage them. One of those is the floral industry. We have had quite an exposure to flower companies and know that some paths which would sound intuitive at first could become a complete catastrophe very quickly.
The flower business is a very interesting one. Most companies that deal with flowers know that it is hard work. Operations start extremely early in the morning and go late into the night. During heavy seasons such as Valentines and Mother’s day, the workload is pretty much 24 hours a day to keep up with the demand. This alone makes it a challenging feat for implementing a software system. Nothing can go wrong and if it does there is not much time to react and fix the issue.
Long hours and high load are not the only challenges. The product itself poses many difficulties for a system that is meant to organize the processes of a company. As pleasant as flowers are to the eye, they can be extremely unpleasant to work with. Different flowers can look similar so they are easily mistaken one for another. You can’t stick a barcode label on a stem of flower and the boxes they come in are very often opened and broken up. They move in large volumes through the supply chain and are relatively inexpensive by themselves. Vendors do not always send the same volume or product as the buyer buys and that is generally accepted in the industry. The customers do not always receive what they order and that is also accepted as long as the sales person understands the relationship and generally what the customer wants. Those are only some of the issues faced when working with flowers.
Personally, I welcome challenges as these to work with and in my opinion, only a very flexible ERP system, such as Dynamics NAV, stands a chance in fully adding value to an industry that has such difficult business processes.
Most of the time in these environments the companies manage to capture the sales and purchase process inside a system. Since inventory expires quickly they don’t have to account as much for it when figuring out their gross margin. This is of course the minimal way of tracking the business and completely ignores the product in the process. It takes away any possibility of managing the supply chain. The brave businesses will tackle sales and purchasing processes separately. But when they try to connect the two together everything blows up.
The trick is to understand flowers and the people who work with them. The system will have to dynamically align itself with the ebb and flow of product and be smart enough to realize when things do not exactly match. It has to be nimble enough to react without compromising the integrity of the data or speed of data entry.
As we have plied through the trials and tribulations of making the business processes and systems just perfect for this industry, it has been easy to find motivation to go on. All we had to do is look around us and find ourselves surrounded by one of the most beautiful things on earth, flowers.
This topic has the danger of becoming an overly technical one, so I will attempt in this blog post to focus on the benefits from a high level design perspective. Hopefully everyone can understand why structure is so important.
In my math days I was fascinated with the topic of abstract algebra. A lot of that subject has to do with the structure of things. For example abstract algebra could attempt to describe the possible variations of a snowflakes and crystals. Many of the results are very beautiful and reminds us that mathematics and art can be very close subjects.
When we look at a software system as big as a regular ERP, it does have a clearly defined structure. If you are a technical person who has worked with the system for a while, you will soon realize whether the structure is nice to work with or not.
As a user you might be able to go on with your daily activities whether the structure is bad or not. It comes into play when the system needs to be modified. A poorly structured system is going to be hard to change and will pose a high risk of behaving abnormally. In a well-designed system, the modification will seem natural and flow right with the rest of the system. Dynamics NAV has an excellent structure and it is the reason why still today I find it very rewarding to work with. The structure has remained similar since its original version. It has been evolved through modern technology and the structure extended with functionality, but the core structural principles have always remained intact.
Dynamics NAV goes even so far as to preserve the elegant structure at the cost of the user experience. For example, on a sales order we have the field “document no.” and “external document no.” The “document no.” refers to the sales order number, but the “external document no.” refers to the customer’s purchase order number. So why not call it customer’s purchase order number? The reason is because the designers of the system were adamant about maintaining the structure as abstract and symmetrical. Once the user gets it, then learning the rest of the system becomes easier and things seem to make sense, wherever they are. Basically, “external document no.” works on pretty much all documents. Sales Order, Purchase Order, Sales Cr. Memo, Sales Return Order, and most other documents all have external document number. The meaning is different based on context. That’s an example of an abstraction.
You can also find nice symmetry. For example if you turn the sales process around, you get the purchase process. Almost all functions of the sales process can be inversed to get the purchase functions. The code and the structure behind it is setup in a similar fashion. The sales and purchase process hangs together by the things being traded, such as inventory, resources, etc. If you look closely, you will see that NAV replicates symmetry almost everywhere, except in the resources. You can sell resources but not buy them. The idea is that the definition of a resource is something the company owns and is paid for through expenses or fixed assets. However, if you want to extend the system to allow purchasing of resources, generating the code is extremely natural, since the symmetry is clear on all aspects.
People often talk about some systems being easier to modify than others. I think this is often mistakenly attributed to the programming language being easy or the programmer has access to more tools. The reality often is that the system is basically better designed, which therefore makes it easier to work with and modify.
Consultants working in the field have to understand this structure and leverage that it is there. Not doing your homework on the structure, is like driving a Ferrari and never getting out of first gear.
Microsoft will officially release NAV 2015 this October. An early release is already available to download for partners. Significant enhancements have been made towards the cloud and mobility. In this blog I want to talk in general about ERP new releases and upgrades rather than going into technical details.
When Microsoft announces a new major release of NAV it usually has both the marketing name, NAV 2015 and the technical name, version 8.0. Comically according to the marketing name we end up promoting either last years or next year´s product for one year.
Should you always go for the latest version?
Unfortunately, software releases do not always behave like most other products where newer is always better. With ERP releases, newer is sometimes better for some companies. A new release could involve a radical technical change, which ultimately will greatly enhance the product, but the early releases could have issues. So you could say that ERP software releases behave like fine wine. They need to age a bit but if you wait too long, they will turn.
The decision to wait or not to wait on purchasing or upgrading to the latest release, has to be intelligently made. It highly depends on the functionality being used and what is addressed in the new release.
As an example the upgrade from NAV 5.0 to NAV2009 and finally to NAV2013 (5.0 did not have a marketing name) was one of the largest jumps I have seen since we moved from character based systems to windows. It was more than revolutionary. But along with all the glory, came some major obstacles. It was obvious that while a great number of new doors were opened, some of the old tried and trusted doors were simply removed. In some cases it was similar to getting a new car that could fly but the speedometer was in the backseat! We at iNECTA built functionality on top of the versions in order to make the work well. You could say we moved the speedometer. In some cases we told our customers to wait on going all the way until the new version, like wine, had reached its optimal age.
The latest version, NAV2015, has been fine-tuned further and now instead of focusing on any of the shortfalls of the new technology, we are able to leverage all the new doors that have been opened. It is really a privilege to be backed by Microsoft. Microsoft has a vision and is willing to go through severe changes in order to get its product to the right technology path with an open future. It has the bandwidth and courage to support such a change.
As a consultant, you have to be very aware of the changes and how they affect your customers. We become the Sommelier of the ERP harvest, we advise the customer when to wait, when to discard and when to drink.
With fall come many beautiful things. Leaves change colors, football season starts and kids go back to school. It is also the last chance to file taxes. This can either be a beautiful experience or an absolute terror.
I have had conversations where people argue the sole purpose for an accounting software system is to be able to accurately file income taxes. Countries like Bahamas would then simply not need accounting software. While this is a noble thought, the reality is that most developed countries in the world have income tax laws and enforce them rather strictly.
As companies go through getting the numbers to tie out and preparing all the data to submit to the government, it is a good idea to take a look at all the work that goes into it. How can you save on that work for next year? Is there anything you can improve proactively, rather than being reactive at the last minute?
Many companies, do not have an integrated system. They might run separate sales invoicing system and purchase order system. At the end of the year, they do an inventory count, add up all the sales and purchases and come up with the gross profit something like this:
GROSS PROFIT = SALES – PURCHASES +/- CHANGE IN INVENTORY VALUE
Then they add up all their overhead expenses and get to their net profit.
While this is a simple way to figure out how well you did last year there are a number of problems with this approach. Perhaps the most glaring one, is the fact that you are sailing the ship and most of the time you do not know whether it is going in the right direction. If you wait until the end of the year to see if you made the numbers, it might be too late to take action. Other problems, include details that are missed. For example you might have received inventory, but not the invoice. Are you accounting for that in your purchase system? How did you arrive to the value of your inventory? Are you using FIFO, LIFO, average or standard costing method? If you are not using standard, then you need to prove that the value is really what you say it is. If the sales and purchase systems are not connected with an inventory system, then that could be a difficult problem.
Some companies just print the entire thing out and send it to their CPA to deal with. The CPA firm will just file according to what they receive. They do not take any responsibility to the quality of the data. If there is an audit then they come back to the company to prove the numbers.
Finally, even if the company is using an integrated system where purchase, sales and inventory all talk together and post to the chart of accounts, there still might be issues. Many systems are not sophisticated enough to accurately balance out accounts receivable, accounts payable and inventory value to the general ledger. This becomes clear as daylight during tax time, but seems often to go unnoticed throughout the year.
As an executive responsible for running a company successfully, numbers are everything. It would be a good feeling to know your numbers not only tie out every year, but always. System is always in sync with the information entered. Instead of worrying if the numbers are correct, you can worry about how to run the business. That is the state every business should strive for. Microsoft Dynamics NAV is the tool we at iNECTA use to get our customers there. Filing your taxes can be a beautiful thing!
Throughout my Dynamics NAV years, our team has adopted quite a few implementations that have for some reason gone wrong. We are usually able to straighten the implementation out and get it on the right track. I have often wondered why things went wrong in the first place. There are several different reasons that come to mind. Sometimes it’s the consultant’s fault, sometimes the company’s and sometimes both. In this article, I wanted to focus on a particular type of failure which has to do with the consultant.
ERP consultants can by categorized into two types, functional and technical. In this case, I am not counting the project managers. A technical consultant usually starts out as a programmer with a computer science degree. The functional consultant will usually have a business or accounting degree. When ERP systems are being implemented, you will usually need at least one of each on the consultant’s team. There are very few people that have mastered both sides of the coin. The people that have, I like to refer to as ambidextrous.
Let’s now say that the team at work has expertise in one side but not another. How does that affect the project and what are the dangers?
Functionally oriented team
A team that is comprised mostly of functional consultants, will know the accounting principles and understand a good portion of the application. If they are intelligent and possess a high level of application knowledge, they will find ways to solve issues at hand using the standard package. This is very often possible, but sometimes means that the company has to make compromises. The risk of failure is less, since the original program is not modified and will work more or less out of the box from the manufacturer.
The problem with this approach, even though it involves little risk, is that the company’s incentive to change a system was usually to leverage new features and introduce flexibility. We already have more inexpensive systems in the market that you cannot change. Why go to a more expensive system and still be shackled. You can say the implementation went through and everyone is using the system, but functionality was heavily compromised.
When we enter a scenario like this, the company is usually asking us why things cannot be changed. The previous implementation team, simply said that it cannot, without an explanation.
Technically oriented team
To be able to change an ERP system is a powerful thing. Power needs to be handled with responsibility. A team that has more technical expertise than functional, will know how to change the system. They might think they know the functional side well enough but if they do not, it can be a very dangerous mixture.
When the company has a business process that has to be implemented, and the technical consultants are not aware of it in the standard system, they will simply create it! The consultant might not have deep accounting or supply chain knowledge. But they have the power to change and add to the system, and they use it. This can be very risky. If the change to the program does work, then chances are you have just recreated something that was already there. When upgrades come about, the out of the box functionality gets an upgrade path from the manufacturer, but the modified functionality needs to be handled specifically. There is of course the chance that the modification does not work, or even worse, looks like it works but generates erroneous data.
When a company seeks us out to help with implementations that have gone bad and the team has been too technically oriented, things are usually quite messy. The system could be behaving strangely, locking up regularly and not handling volume. The first thing we do is see how we can strip things down and utilize the system better or in another words, think more like a functional consultant.
I sometimes get asked, “The functionality works, even though it might be a recreation of functionality that is already there, or not properly extending it, why is it bad? It works!” The reason why it is bad, if it is not properly done has to do with upgrades and further extensions. If the development is nicely done extending the system, then every exception can be logically worked out. Upgrades also become straight forward and will, for a lack of a better word, flow. Any consultant which has been tasked with fixing these things, will understand.
Conclusion
I hope I have made the point that a team needs to have solid functional and technical consultants. When a company has had the experience of an imbalanced team, they will on the next go around overcompensate in the other direction. Companies that went through an overly functional implementation, will go development mad and companies that went through heavy technical implementation, will shun away from any development and make big compromises. Like in life, a good balance is the key to success!
While another Icelandic volcano, Bárðabunga, is set to explode, filling the clouds with ash and making our lives a little harder, there are other types of clouds that are making our lives easier.
Years ago many thought the cloud was just a buzzword that would help sell more software but lacked substance. The reality has proven otherwise. The cloud has been a revolutionary step into the future.
Businesses have long been used to having server closets somewhere in the basement of a building where all end users connect to transact business processes, read email and store data. These servers would then connect to the internet to talk to the rest of the world. Maintaining these servers became the responsibility of a local IT team, who would have to make sure the power, the air conditioning and connectivity remained perfect. At the same time when it came time to upgrade, those servers had to be physically replaced or opened up and configured. Whenever a server would power down. Someone would have to go over to the closet and push a button. Sometimes, equipment was installed to remotely turn servers on and off. Then there were the setups of routers and firewalls, to keep all this safe from the constant attrition of evil forces.
This is the situation in many places today, but I firmly believe this will be a thing of the past for most companies in the not too distant future. The features and functionalities of cloud technology is enormous today and is growing at a stellar speed.
Back in the late 90’s during the dot.com boom, people had the vision of what we are living today. Investors put in serious investments in ideas that on paper made sense. Once it was time to start the car the wheels fell off. The technology at the time simply was not ready. The powerful companies back then, took a step back and revaluated what had happened and started taking serious steps in the right direction. I am lucky enough to have been a part of one of them, Microsoft.
We are a Dynamics NAV and CRM partner. For us the advance to the cloud started with Office 365. We, as many other companies, were running an exchange server at a colocation. We decided that since we were Microsoft Partners, we should definitely practice what we preach and move over to the cloud with the e-mail. The migration was fantastic and we have never looked back.
In the next step we pushed all of our development and in house servers to Microsoft Azure and after that there was no need for our collocated servers, which were donated to charity. Azure is a fantastic way of running Dynamics NAV. We create new machines regularly when the need arises, and just delete them when we are done.
One of the comical issues we have faced, when entering a highly virtual environment is that there are so many servers and machines, that you kind of find yourself a little lost on the network. Things are constantly changing. A machine you had worked with before, could have been moved, shrunk, expanded or deleted. The management of the servers has changed from making sure the physical boxes are doing well, to making sense of the highly flexible environment in the cloud.
All in all, this progress has been evolutionary. It is very exciting for people working in the field and I for one cannot wait for the new things that come out and truly take advantage of the power of the technology at hand.
Companies have a peculiar life cycle. When you look at them over a period of time, it is almost like they are a living organism. They consume revenue, and excrete expenses. If they consume more than they excrete they grow bigger. The software system is like a central nervous system. It has links to all the body parts and sends messages to and from the central system.
When a company grows, if the software cannot grow with it, the nerve endings fail to reach all the extremities. The people in charge will have to make assumptions regarding what is going on, where they have no visibility. They start taking calculated risks. To further the analogy, they might find out that they have no feeling or control of one of the hands. They figure, they are in risk of losing a finger, but since there are five fingers for each hand they would probably be still be operational, without one. As the company grows even more, these assumptions are made more frequently, until the risk and uncertainty becomes alarming or something goes drastically wrong. This is usually uncovered during the annual doctor checkup, or in another words, independent audit.
When a company has received less than desirable bill of health, it is time to take greater control of things. This is usually when I enter the picture. ERP consultants are like the brain doctors. Our purpose is to take out the existing brain and replace it with a new one!
We take the memories of the old brain and upload them into the new one. Sometimes people want to leave some unpleasant memories behind and they are then stored in an archived system. We upgrade the nerves to handle more bandwidth and extend them to reach further into all extremities.
The new brain, if it is Dynamics NAV, more than likely has much more flexibility than the old brain, and can be aligned to control the organism in ways it couldn’t before. Getting it to do a wide variety of very compelling and competitive moves. This increases the chances of the organism in a fiercely hostile business environment, where only the fittest survive. The company organism has evolved!
Once again, I am in an airplane crossing the Atlantic on my way to another NAV implementation. I am pleasantly surprised to find that they finally offer Wi-Fi on my airline while crossing the waters. A satellite must have been reassigned from Cold War duty to facilitate people uploading pictures of their airplane food. In any case, it allows me to take care of my routine blog posting at 30 thousand feet.
Whenever I start a new implementation or even in the sales phase, I emphasize the importance of keeping things simple. I sometimes reference the following story to drive my point home.
During my math days at the University of Miami, I had a teacher from Russia name Dr. Kaliman. He was an excellent research mathematician which sometimes had little tolerance for pupils that could not quite follow his lectures. I was a rather verbal student insisting on asking about anything I could not fully understand. I clearly remember one afternoon in class where Dr. Kaliman had gone through several blackboards of math proofs, underlying the foundation of a Theorem which was to be the main proof that day. With chalk covering his shirt and pants, he vehemently wrote AB = BA. I had to open my mouth and break his concentration: „Dr. Kaliman, what do you mean with AB = BA?“ Dr. Kaliman looked at me rather frustrated, and very passionately told me „Johannes, it is so simple, it is hard to explain!“
So what´s the moral of the story? When I looked at AB = BA, I immediately started to associate more things to the equation. I started thinking about how it worked when data flows through it. How could it be applied? What really did A and B stand for? I was drastically overthinking the problem at hand. It turned out that this would then be used to prove something like:
LET AB = BA, AA = 1, BB = 1
SHOW ABAB = 1
Where the solution would be
ABAB = AABB (using AB = BA)
AABB = 1*1 = 1 (using AA = 1 and BB = 1)
Therefore ABAB = 1 QED.
This of course has absolutely no context and my mind spinning trying to make more of something that wasn’t, was taking me further from the solution.
In the NAV world we are faced with similar situations. In some cases both the customer and the consultant will fall into the trap of overemphasizing and overthinking an issue that either can be trivially solved or really does not matter in the grand scheme of things. We are so trained to solve problems that sometimes unknowingly we create our own problems to solve. Always looking for simplicity is the key to successful implementations.
The NAV Viking´s Blog 