Microsoft Dynamics NAV Design Evolution

Designing and developing a Professional Services vertical for Microsoft Dynamics NAV has been an experience.  There were days of joy when a function worked just right and there were days of frustration when a piece of code simply refused to behave, but I soon came to realize that each day was simply another evolution.  The product was evolving day-by-day, steered by obsession over quality, user-friendliness and efficiency.   Because I was using the product to run my business, I became intimately aware of the user as I was the user and that has to be the prime element of sound software design - one has to put oneself in the shoes of the user while designing and developing. 

There is much to be improved and simplified in Microsoft Dynamics NAV from a user's point of view in order to bring about the goals of efficiency, ease-of-use and user-friendliness.   In no particular order, here are my thoughts on design evolution as it relates to Microsoft Dynamics NAV, though many of these points apply to software design in general and can be applied at any time through thoughtful design and development. 

1.  Automate activities that burden the user when there is really no reason to involve the user:

• Posting Warehouse Item Journal should also update Item Ledger rather than having user run a separate Item Journal, Calculating and Posting.  
• When time sheets are posted, automatically integrate to the job ledger rather than having user a run a separate Job Journal, Suggest Lines function. 
• Automate inter-company posting so that users do not have to monkey with inboxes and outboxes.  

2. Greatly reduce the chance of data errors or omissions, by enforcing mandatory fields during master record set up (e.g. customers, vendors, items, pricing, etc.).  The mandatory fields should be configurable by an admin not a developer!

3.  Always give the user a message indicating if a process was successful, failed or was aborted.  This should be a commandment!

4.  Make warning and error messages user friendly in plain terms with suggested corrective actions where possible.  I would like to see the message 'The update has been interrupted to respect the warning" permanently stricken from the database and replaced with a simple, "Operation aborted". 

5.  Hide, by default, all fields that are not likely to be used by the intended audience.   Let's take the North American database for instance.   The General Journal should be simple, but it is not!   Hide the Gen. Posting Type, Gen. Bus and Gen. Prod. Posting Groups!  Show the Debit and Credit Amount fields.   Extra fields = Extra Clutter = Not User Friendly = Not efficient. 

6. The opposite to 5 is just as important.  Show, by default, all fields that are likely to be used by the intended audience.   The Time Sheet approval screens are an extreme example of this.  Out of the box, they are essentially useless if you are using resource numbers or job numbers.   You cannot see the names of the resources or the names of the jobs that you are approving time for.   Many default screens simply do not show, by default, necessary data that is needed by the end user.  This sometimes requires developers to get involved, increases cost of the implementation and reduces efficiency.  

7. Eliminate multiple tree selections.  E.g. clicking Order, Drop Shipments, Purchase Order on the Sales Order is time consuming and cumbersome.  Selections should be a one-button press or at most a two-level tree.   

8. Make setting up master records easier.  Setting up Customers and Vendors require users to select Posting Groups.  Take the concept from the Item Card Category Code which defaults Posting Groups and other key fields and pay it forward!

9. Obsessively reduce keystrokes and clicks.  My mantra is "Three clicks is painful, two is sufferable, one is good and zero is best!" 

10. Make the interface intuitive, easy-to-use and fun!   Fun and ERP software may be polar opposites, but it does not have to be that way!

11. This brings me to the long and short of it- you have to know your audience to design software for your audience.   For example, I have not yet met an accountant who wants to see anything but the Vendor Name in the description in the General Ledger for payments to vendors, yet the NA version of NAV still to this day, uses a description that is of no use to accountants.