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.
The Importance of Roles in Microsoft Dynamics NAV
What is a role in Microsoft Dynamics NAV? A role defines what menu items you see as well as what appears on your Role Center (the main page you see when you log into NAV). Below is the default Sales Order Processor role.
An optimally configured role would give users quick access to their most often used pages, reports and functions, would provide useful information at a glance through the use of tiles (see blue squares above) and contain any other relevant information.
You can assign the default roles to users and begin using them and while this is better than not using any roles at all, for ease-of-use and efficiency, it is highly recommended to tailor roles for your organization.
The Role Center is just another page with an important distinction - custom code cannot be written on the page. This is intentional so that non-development resources can set up their own roles. However, setting up roles is a technical endeavor and requires use of the development environment, so is most easily done by a developer, though non-development resources could be trained to configure roles. However, before volunteering to set up all the roles for a company, it would be a good idea to observe a resource seasoned in configuring roles before committing to the task. It is not a simple point-and-click affair and not-at-all intuitive if you are not familiar with the NAV development environment.
A good procedure to take in configuring roles would be:
1) Look over the standard roles in NAV. Best done by running the roles using the Development environment. These are in the 9000 page number range.
2) Make a list of the roles for your company. E.g. (CFO, Controller, A/R Manager, A/P Manager, Sales Order Processor, Inventory Control, etc.)
3) For each role, list out the pages and reports that role will need access to. Use the standard role as a guide. Consult with an actual user of the future role while doing this.
4) List any tiles that may be useful for the Role. Tiles display a numerical value which usually drills down into further detail. E.g. A tile that shows the number of open sales orders. When clicking on the tile, the user views a list of open sales orders. The standard roles may have tiles you would like to incorporate into your role or may give you ideas for other tiles. Consult with an actual user of the future role while doing this.
5) Once you have defined the roles and what is to be contained in them, you can start configuring roles. It is best to start with an existing role, copy it and configure the copied role. This will leave all of the standard roles untouched and they can be used for reference.
6) Finally, assign the role to a future user of that role and have them test it out and get their feedback and make any desired changes.
Optimally configured roles should result in users being able to carry out their jobs more efficiently within Microsoft Dynamics NAV, highlight key data and metrics, reduce training time, and time spent locating screens, reports and functions.
Star Wars and Implementing ERP Software?
I know what you're thinking- this is a really old marketing trick, positioning and leveraging against the soon-to-be-released "Star Wars - The Force Awakens" movie, and guess what, you would be right. The two subjects have absolutely nothing to do with each other, but neither do popchips and Star Wars as I casually noted while strolling down the grocery aisles over the weekend.
So here's just a bit of fun. If you had to pick your favorite Star Wars characters to implement your ERP software, who would you select? Here are my top picks:
Sales/Account Executive - Han Solo- he's charismatic, outgoing, bold and doesn't hold back. He may be a bit reckless with his tongue and he may seem to be all-too interested in his sales commission, but at the end of the day, he'll take care of business.
Senior Developer - Luke Skywalker without question. He's bright, a quick-study, honest and capable. He's tired of farming anyway and he's ready for a new game.
Project Manager - Princess Leia. She's tough, resilient, smart and can think on her feet in a fire-fight. She'll get the job done on time and in budget, even if it means leaping into a trash compactor. She won't back down when it comes to loyalty and principles even in the face of evil.
IT Technician - Anakin Skywalker (before he turned to the dark side). If he can build and repair droids, he can install your SQL Server database with literally one arm tied behind his back.
Implementer - C3PO - you really should not have your personnel trained by a robot, but he does speak six million languages, so whether your implementation is on the dry desert scape of Tatooine or the lofty cloud-city of Bespin, he'll be able to communicate effectively to your staff and he can set up a database faster than any human around.
Third Party Consultant - Lando Calrissian. At first, your not sure if you can trust him and you're pretty sure you can't. He's got that charm and beguiling smile, and he may turn you over to the dark side if his hand is forced, but he'll figure out a way to make the project a success.
Executive Sponsor - Yoda. I can hear him now, "Security, you will set up and a SOX audit you will avoid."
'Nuff said.
ERP User Documentation, a Compulsion
I admit it- I have a compulsion and that compulsion is to document procedures and customizations. I realize I am a prime candidate for the twelve step program, "Documentation Anonymous". In fact, I refuse to deliver any development without user documentation describing where to find and how to execute any particular development, along with testing tips, and other juicy tidbits. Worse, I have passed this disorder down the organization to others.
How this disorder befell me is an interesting story. You see, I just got tired of training the same procedure or task to one person after another and then again after someone forgot. This is no fault of any other persons as human memory in its current state is not perfect. It was my responsibility because I didn't document it. And I found, magically, the amount of traffic regarding said procedure or task died down to a mild murmur, and eventually to a wonderful blissful silence.
When procedures, tasks and details are held in minds of others and not in writing, it is subject to degradation, loss, alteration and other forms of unfortunate circumstance. Employee transfers, promotions, leaves, new hires, etc. are just a few of the possibilities. As these procedures and tasks are handed off from one person to another, data inevitably gets altered or bits of data gets dropped off and knowledge is then lost. "Tribal knowledge" can be converted to "Permanent knowledge" by documenting procedures, tasks and customizations.
I may have struck a serious blow to the financial interests of "Documentation Anonymous" and if so, the world will be a better place!
Microsoft Dynamics NAV in the Cloud or On-Premise?
There's a lot of talk about the cloud these days and not a day goes by without a new company springing up offering a new cloud service. Cloud services are advantageous because they don't require high up-front costs such as hardware, specialized services & training or high initial software license fees.
Microsoft Dynamics NAV, in the recent past could only be purchased by buying the software license. The up-front costs could be high depending on the number of users and of course, you needed adequate hardware, internal or external IT staff to install, configure and maintain the servers and requisite software. The initial investment was often quite high.
Now Microsoft Dynamics NAV can be purchased two ways. The traditional "buy the software license" approach is still available. However, if you don't want dump a load of cash into hardware and IT resources, you can purchase NAV on a subscription basis. Here, your initial up-front costs are very low, no specialized hardware or IT services are needed and your data is secure and backed up automatically. You simply pay a monthly fee per user. Note: there is a small initial up-front fee and pricing varies depending on the options you select as well as the size of your database.
Your NAV solution can be hosted in the cloud on our preferred hosting provider's data centers or on Microsoft's data centers also known as "Azure". Our hosting provider will install NAV and take care of all the of the technical details and you will have NAV up and running in no time! Your solution will still need to be configured for your business, but all of the infrastructure will have been taken care of so you can focus on your implementation and your business.
Plugging Dynamics NAV Security Holes
The default security roles that come out of the box allow certain users to access the Chart of Accounts, G/L detail and financial reports when they should not have access.
The technical reason behind this is specific permission sets give the user the ability to read G/L accounts and G/L Entries. These include sales/purchase order entry, posting of sales/purchase orders, and so forth. Further, the default permissions give users the ability to view all pages (screens). Therefore, these users have the ability to view the chart of accounts, see balances and drill down into the G/L entries.
The obvious question is, "Why do you not simply take away the ability to read the G/L account or entries?" Users may need to select a G/L account on the sales or purchase lines for misc. charges or to record an expense and the posting routines need to read the G/L entries. Therefore, these permissions cannot simply be taken away.
The next obvious question is, "Why not give users access only to specific pages (screens)?" This is a valid question and yes this can be done, but it will a mind-numbingly and time-intensive task which could take a hundred hours or more. There are third party tools which can help, but there are other possibilities without purchasing additional software.
A recommended approach is to set up roles for each department so that users only see the pages, reports and tools they will need. Then the key thing is to remove the Departments menu from the user's role. Users will not be able to access any page, report, etc. that they cannot see on their menu. They will not be able to search and find any feature that is not specifically on their role. Therefore, they will not have access to the Chart of Accounts, or financial reports. Setting up roles as described above accomplishes two goals:
- Simplifies the user-interface greatly and enhances the user experience.
- Enhances, but does not replace the security settings.
Still with the above done, there is still a few holes to be plugged. Users, while looking up a G/L account, could go to the G/L Account Card or Navigate and see the detail of posted entries. Navigation is an immensely useful feature, but the user could potentially drill down into the G/L entries, remove the filter and see any data in the G/L. This can be resolved with a few lines of code on the G/L Account Card and General Ledger Entries pages. It is recommended to add a field to the User Setup table which very few users will have access to. Call it, "G/L detail access". Then code the G/L Account Card and Entries page to error out unless the user has "G/L Detail Access". This should plug the final holes.
What if you don't have roles configured as above and you need to plug the holes right now? Then, you would take the coding approach above and apply it to all objects to be blocked. This would include minimally: G/L Account Card, G/L Entries page, G/L Registers Page and Report, Chart of Accounts and all reports on the General Ledger menu under Entries and Financial Statement. This sounds daunting, but is easily accomplished in a few hours.
Don Saito
All content provided on this blog is for informational purposes only. ERP Efficiency Experts, LLC makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. ERP Efficiency Experts, LLC will not be liable for any errors or omissions in this information nor for the availability of this information. ERP Efficiency Experts, LLC will not be liable for any losses, injuries, or damages from the display or use of this information.
Estimate for Upgrading Microsoft Dynamics NAV Causes Acid Reflux
If you are currently on NAV and looking to upgrade, particularly from NAV 2009 or earlier to NAV 2013 on up, you may have received an estimate from your partner which may have caused a moderate to severe physical reaction, depending on your constitution.
The reason for the huge costs to upgrade are primarily due to the major technological improvements in NAV 2013 and the lack of stellar upgrade tools for NAV 2009 and earlier. To make NAV more-web accessible, the screens (forms) were replaced by pages, data conversion tools (dataports) were replaced by XMLports and the proprietary report writer was replaced with Visual Studio.
So, what can you do to reduce the upgrade costs? Ask for a detailed estimate that breaks down the estimate by type of object. For example, what is the estimate to upgrade tables, forms, reports, dataports and codeunits.
The largest cost will likely be upgrading modified reports. So, this opens the door to reducing your upgrade costs. You can ask your provider to install code to track which reports you actually run prior to upgrading. You can also review the modified reports to see if you truly need them in the new system.
It is very likely a good majority of Dataports (data conversion utilities) do not need to be upgraded as there are often used for initial data conversions when you went live and no longer needed.
Upgrades from 2013 and onward will be much less likely to cause a severe reaction as the upgrade tools have been markedly improved.
Don Saito
All content provided on this blog is for informational purposes only. ERP Efficiency Experts, LLC makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. ERP Efficiency Experts, LLC will not be liable for any errors or omissions in this information nor for the availability of this information. ERP Efficiency Experts, LLC will not be liable for any losses, injuries, or damages from the display or use of this information.