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. 

Designing Microsoft Dynamics NAV Implementations

Design is one of my passions.  Throughout my career, I have had the privilege and opportunity to design implementations and solutions on Microsoft Dynamics NAV from small informal businesses to large, global corporations.  I have learned a few things over the years which I will now share. 

Pre-Design

Pre-design are those activities prior to design which will facilitate the design process.  This may include agreeing upon a design approach, business process mapping/re-engineering, training on the base product, and preparing for the design requirements meetings. 

Discussing the design approach early in the process will prevent heartache downstream.  By design approach, is meant the manner in which the design process will be carried out.   The design activities can then be steered accordingly.   Here are some important points to consider:

• Is your client adverse to customizing the product?
• Is your client open to changing key internal processes to suit the software?
• Are the key internal processes inflexible due to technical reasons, contractual obligations, or otherwise requiring customization?   
• Is the budget inflexible or fixed? 
• Is efficiency and ease-of-use more important than avoiding customization?
• Has the legacy system been heavily customized?  

The answers to these questions should guide the designer in how the meetings are conducted and how the design activities are carried out.  The design approach could be summed up in a statement such as:

Client prefers an out of the box approach, customizing only in the X module, where customer obligations dictate specific requirements not supported by NAV out of the box.  Code changes are to be heavily scrutinized. 

Another one might be:

Budget is more or less fixed, requiring lengthy board reviews and approvals for changes to the budget.  Core requirements have been identified in spreadsheet X. Anything outside of the core requirements will be placed on hold to be discussed after the initial go live.  

Another example:

A key target is to streamline the current manufacturing process.  It has been acknowledged that NAV's out of the box manufacturing process will require customization to reduce keystrokes and to prevent data entry errors.  Great attention will be placed on efficiency throughout the manufacturing process.  Finance and sales will use NAV primarily out of the box.   However, the sales order entry will be customized to reduce keystrokes and place key functions on the users roles for quick access.  Speed of sales order entry is key.  

Now, it would be very wise to ensure the entire implementation team is briefed on the design approach prior to the process mapping and design meetings and to lead the meetings accordingly. 

Business Process Mapping

Business process mapping may include the as-is processes as well as the to-be processes.  The to-be processes should be mapped in coordination with the desired ERP system.  Otherwise, the to-be processes may veer far from the out-of-the box processes and the resulting to-be processes will be out of sync with the standard ERP system requiring major customization. 

Business process mapping is of value in several aspects.  Often it is the first time personnel have had open discussions on how their job relates to other jobs in the company and it gets the team involved in an open dialog.  Discussions can get heated as viewpoints shift and new patterns and agreements are made.   Secondly, it moves the processes and procedures of the organization out of the "minds" of individuals into the material universe where it can be visualized, discussed and improved.   Thirdly, it lays the foundation for the design of the ERP system and facilitates a smooth transition from business process to design requirements.  

Is business process mapping required for all implementations?  No, successful implementations have been done with and without them.  Larger, more complex implementations would benefit from business process mapping.  However, any company would benefit from documenting and understanding their internal processes. 

Pre-Design Training

Pre-design training is highly recommended for implementations where the implementation is not an obvious out-of-the box installation.  Armed with a better understanding of the system, the client can better collaborate during the design process.  

Preparing for Design

This includes items such as preparing an agenda, ensuring the room is properly set up, the meeting sizes are not too large, access to legacy systems, projectors, and so forth.

In the next series of this blog, I will cover the design process.