The following section of this chapter will describe each phase in a Microsoft Dynamics NAV implementation, and the tasks each one includes. In a Waterfall environment, you can do one thing after another. In an Agile environment, don't forget to loop through all of them, especially the phases called getting the project requirements, analysis, development, and part of the task from the deployment phase.
It's especially important to define how the information will flow through all the phases to ensure that important information does not get lost.
This is the first contact between the partner and the customer—the big lines on which the project will be drawn.
This phase is usually executed by the sales or marketing people, with the help of a business consultant. Many companies think that at this stage the project hasn't started yet, so they don't think that this job is part of the project. But it actually plays a very important role.
Selling a project like a Dynamics NAV implementation is not just selling the software itself. It is not enough just to be aware of what the product can or cannot do. Part of successfully selling Dynamics NAV is instilling confidence in how you will approach the project.
Therefore, the salespeople need to sell not only the product, but also the methodology the company is using and the amount of work the customer will face in the next months. In addition, a good salesperson will discuss how the partner will help the customer face this challenge.
As the salespeople are part of the project, they have to identify fundamental aspects that will help the other members to do their job. A salesperson can help by identifying some of the risks of the project, for instance, mention the departments that have asked for a new ERP system, or someone from the customer's side who is not convinced about the need to change the ERP. They also have to identify if the customer processes are mature enough or need to be rethought. They are also responsible for properly identifying the key people in the customer's organization capable of doing this rethinking or figure out if they are expecting the partner to do it for them.
All this may completely change how the project will be approached. So it is important to identify it at earlier stages. At the end of this stage, a first cost and duration estimation must be done. It is important to be as close to reality as possible.
This is the time for discussion between the partner and the customer. I mean the real deep down discussion, almost like a husband and a wife would. The business consultants and the key users will do a series of meetings in which the key users will explain to the business consultants the way they do business, the information they have to handle through their business processes, the reports they run, the users that are involved in the different stages of each process, and the problems they have with their actual business processes, and most importantly, how they expect the new system to help them solve their daily pains.
The business consultants will need to listen carefully to the key users and understand their pain points from their current operation. Only after understanding the customer's needs will they be able to design the right solution for the customer.
In order to do that, they not only have to be active listeners, but should also actively participate in the definition of the processes by asking all kinds of questions to the key users; namely, periodicity of the process, volume, amount of people involved, how automated it should be, how to handle exceptions to the process, how strict the process is, how important it is, and any other questions you may think of.
As they listen to the customer's processes' explanations, they should point out how this process is handled in Dynamics NAV to identify and mention as an evidence to everyone the differences between the customer's actual business process and the way it is handled in Dynamics NAV. This way, the customer may decide to change or reengineer its own processes or may ask to modify the behavior of Dynamics NAV to adapt to their predefined process.
With all the information gathered in the project requirements meetings, the business consultants should write a document in which the processes are explained and defined in as much detail as possible. This document should be reviewed by the key users so that everyone agrees that what was explained is what has been understood, and that all the decisions made in the project requirements meetings are reflected in the document.
As part of the project requirements, data migrations will also have to be handled and will include questions such as what kind of data will be migrated into Dynamics NAV, what volume of information this means, from where the data will be extracted and in which format, and so on.
To make sure everything has been talked through and defined, it is important for the business consultants to have a checklist of things to ask to the customer and use it in the project requirements meetings.
In this checklist, all Dynamics NAV functional areas should appear and have their own questions. Let's see an example of a checklist:
- Financial Management:
- What are the tasks of the financial department?
- Which chart of accounts is used? Is it sector specific?
- How are posting accounts created?
- Which kinds of transactions are posted? Can they be predefined or established as recurring transactions?
- Which kinds of analytical information will have to be reported?
- Does the company create accounting budgets? How often? Are they created over the chart of accounts or over analytical concepts?
- What legal reporting does the company have to do? How often?
- Does the company consolidate the accounting information with some other company in the same group?
- Are additional currencies used?
- How are banks managed?
- Are fixed assets managed in the ERP system?
- How many fixed assets has the company got?
- Which depreciation method is used?
- Do you keep maintenance track of your fixed assets?
- Will the fixed assets have to be automatically imported in Dynamics NAV?
- Marketing and Sales:
- Do you create your contacts in the ERP system?
- Do you use a CRM system?
- Customers and sales processes:
- How many customers do you have?
- Is extra information about the customers needed in the customer card?
- Do your customers have different shipment directions?
- How do you classify your customers?
- What is your sales process?
- Do you invoice your customers per sales order they make or do you make a single invoice with multiple sales orders?
- When do you invoice your customers?
- Which documents are sent to the customers?
- How are the sales prices established?
- Are discounts applied to the customers?
- Who introduces new sales orders in the system?
- Do the sales orders require some kind of approval?
- Which payment terms are applied to the customers?
- Which payment methods are used to get the payments from the customers?
- Do you ask your customers for prepayments of the sales orders?
- Vendors and purchase processes
- Items and stock management
- Warehouse management
- Jobs and resources
- Manufacturing
- Service
- Human resources
- Others:
- Will Dynamics NAV receive information from some external application? A website, maybe?
- Will Dynamics NAV have to send information to some external application?
- In how many different devices will Dynamics NAV be used?
We have just written the functional areas of Dynamics NAV and a few examples of questions that can be asked for some of them. A complete checklist should be written for all the functional areas, and all those questions should be answered in the project requirements meetings.
The solution design includes the configuration needed in standard Dynamics NAV functionality for it to behave in the way in which the customer's requirements are met. It also includes the technical analysis and design of modifications, the development of new functionalities, and the data migration tools that will be used to get the data into the system. Different things have to be taken into account for each type of design.
All kinds of configurations have to be established in a Dynamics NAV implementation process:
- Posting groups will determinate how the documents and transactions will end up in an accounting transaction. There are several posting groups that have to be configured, such as the following:
- General Posting Setup
- Customer Posting Group
- Vendor Posting Group
- Fixed Assets Posting Group
- Bank Account Posting Group
- Inventory Posting Group
- Inventory Posting Setup
- VAT (Tax) Posting Setup
- Currencies
- Job Posting Group
- Series of numbers to be used in all the documents and the master data registers.
- The dimensions that will be used for analytical purposes.
- The allowed dimensions' combinations and the dimension priorities.
- The default dimension values for G/L accounts, customers, vendors, items, and so on.
- The following are the setup of all functional areas:
- General ledger setup:
- Allowed posting dates
- The way addresses appear in printouts
- The invoice rounding precision
- The global and shortcut dimension codes
- The payment tolerance
- Sales and receivables setup:
- The series of numbers to be used in the customers and sales documents
- Whether it is mandatory to inform about an external document number in the sales documents
- Whether stock out and customer credit warnings should be prompted to the user
- Whether the posted invoices and credit memos should also create shipments and return receipts
- Purchases and payables setup:
- The series of numbers to be used in the vendors and purchase documents
- Whether it is mandatory to include an external document number in the purchase documents
- Whether the posted invoices and credit memos should also create receipts and return shipments
- Inventory setup:
- The series of numbers to be used in the items and item documents, such as transfer orders
- Whether the cost and expected cost should automatically be posted to the general ledger
- Whether it is mandatory to use locations in item movements
- Warehouse setup:
- The series of numbers to be used in the warehouse documents
- Whether receipt, put-away, shipment, and pick documents are required
- Manufacturing setup:
- The series of numbers to be used in the manufacturing documents and resources, such as work centers
- Jobs setup:
- The series of numbers to be used in jobs
- Whether the job item costs should automatically be updated
- Resources setup:
- The series of numbers to be used in resources
- Work types
- Resource units of measure
- General ledger setup:
- Item tracking codes if they are required.
- Payment terms for the customers and vendors.
- Payment methods for the customers and vendors.
- Configurations that will be used at the customer or vendor level, such as whether prices for a certain customer or vendor are VAT included or not.
- Configurations that will be used at item level like the costing method to be used or replenishment parameters.
- Approval workflows for the sales and purchases documents.
This is a list of typical and common configurations that have to be established in Dynamics NAV. But that's not all. There is a bunch of things that can be achieved in Dynamics NAV through configuration. Not only do those configurations have to be established on the implementation, but they also have to be documented so that the users apply the same configurations to items, customers, vendors, and so on, that are created in the future.
The modification of the standard Dynamics NAV functionality may be as simple as showing extra existing fields in some pages or as complex as altering the way in which the item costs or posting routines are managed.
All modifications have to be designed carefully so that they do not cause inconsistencies in other areas or functionalities and do not disable the future use of a standard functionality.
For example, if a modification is done regarding items, even if item variants are not used, make sure you take them into account to not disable the item variant functionality. Why? That's because you never know if the customer's business will change in the future and will require item variants.
We will discuss development in depth in Chapter 8, Development Considerations.
New functionalities should be designed complying with the design philosophy behind Dynamics NAV, as explained in Chapter 3, General Considerations.
These functionalities include using a master data table, using series of numbers to number your master data registers and your documents, writing a posting routine for your functionality, using non-modifiable ledger entry tables, and using posting groups if the new functionality has to end up in accounting transactions.
For each kind of data that will be migrated into the system, we will have to define the tool to be used to achieve this task. In Chapter 6, Migrating Data, all kinds of details regarding data migration are explained.
Once the analyst has defined the developments that have to be done, it's time for the developer to do his/her job.
The development should follow the standard way of development in Dynamics NAV, using the appropriate name convention for tables, captions, fields, pages, and all the other Dynamics NAV objects.
All kinds of developments should be clearly identified using the Documentation trigger than can be found in every single Dynamics NAV object, and also by using the comment lines in the code itself to identify where the developed code begins and where it ends.
Don't wait until the development has finished to validate it, and show it to the customer. Use prototypes for complex functionality development and show it to the customer as it gets developed. This way the design and development misunderstandings or mistakes can be identified in the early stages and corrected so that no one's time is lost.
The deployment phase ends with the go-live day. A lot of work must be done before the system gets ready to start using it, and it is time to synchronize the entire job done in the previous phases. The best way to face this synchronization is to actually have some of the tasks done in the previous stages as provisional work. This way, major inconsistences can be found and fixed.
The deployment phase includes the following tasks:
- Software and hardware installation
- Configuration
- Data migration
- User acceptance testing
- End users training
- Go live!
This task is all about installing the Dynamics NAV components on the server side, and installing the Dynamics NAV client on the required machines. Also make sure that Dynamics NAV is accessible from all the required devices.
In big implementations, with lots of users using Dynamics NAV from different locations, a load test must be performed. A load test simulates the amount of transactional operations and concurrency pressure that the system will face. The load test will help you determine whether the hardware was properly sized and configured or not.
We recommend you to install the Dynamics NAV test environment at an earlier stage in the project, so that you can release functionality to the customer as it gets developed. It will help you with the final user acceptance test and will allow you to improve your development.
Dynamics NAV includes many tables that include the word "setup" in their names. They are the base to define how each module will behave, so they need to be properly configured. There are also all sorts of supplementary setups, including posting groups, payment methods, dimensions, security roles, and so on.
If you are going to release your developments to the customer periodically, not just at the end of the project, then you will have to execute the configuration task at the beginning of the project. This way the customer can see and test the development with an environment that is similar to the one they will find once they start using the system. If you do so, you will also help the people doing the development. It's easier to develop using a development environment similar to the production one.
Don't think that if you do it at the beginning of the project, you will have to do the same job twice. The company you set up at the beginning cannot be used for production, since test transactions and documents will be posted during development and testing. However, you can always copy all the tables, except entries, posted documents, and master data. There are more than 200 tables that can be considered as part of the Dynamics NAV configuration.
We've done this dozens of times and it's something that really helped us in our implementation, so we encourage you to try it.
Chapter 6, Data Migration, explains in detail what has to be taken into account to perform data migration. In many cases, the data will have to be transformed or adapted in order to use it in Dynamics NAV.
The data migration task should be performed twice. The first time should be done in the test environment, so that the user acceptance test can be performed using real data. The second data migration is done the day before the go-live day. You can also do the first data migration at the beginning of the project. This way you will help the developers do their job with real data which will help them understand the company they are developing for.
Since data migration requires the partner to work closely with the customer, an early data migration will help both the partner and the customer to get used to working together. It will also help the customer to get more involved with the project right from the beginning.
All the work is done and the system is ready to go live. During development, each individual functionality has been tested several times, and also on every release, the users test the system. One more test is required, the one that tests the whole system. All the processes have to be tested, from the initial input, going through all the stages, to the last output. You also need to test if the data generated during each process fits their analysis and reporting requirements.
This test is the last chance to find out if something is wrong and needs to be adjusted. Detecting an issue during the acceptance test and fixing it before going live may save a lot of money.
It's after this test that both the partner and the customer have to agree that everything is ready to go in production. Do not go live if anyone is not comfortable after the test.
Last but not the least, the end users have to be trained. They are the ones who are actually going to use the system, so they need to know how it works. Many of them will see Dynamics NAV for the first time during the training. If possible, make them practice with the system during the training.
The training shouldn't be taken too early, or they will easily forget what they have been told.
As you can probably guess by now, Dynamics NAV is not like installing Microsoft Office. It's not a static software where the vendor installs it and then leaves. It's a constantly evolving organism that must be maintained because the customer's business will always face new challenges that require more out of Dynamics NAV.
The support phase starts on the go-live day when Dynamics NAV is ready and all the users start to intensively use the system.
No matter how hard you try during the training (try it hard anyway), the users will have a lot of doubts and they need someone by their side. So for the first couple of weeks, depending on the size of the implementation, someone from the partner side is going to be at the customer's office to help them resolve issues as they come up.
But this is not only about functional questions and problems. It would be easy if it was only functional questions and problems. Actually, the support phase is the hardest one! During this phase you will also have to handle the following issues:
- Old tasks from previous phases: You will be carrying over a few tasks from the previous phases that weren't important enough to stop the go-live. But the day you start, those tasks become very important all of a sudden. Those tasks become important because the users don't feel comfortable with the new process. They may have a hard time adapting to the new way of doing things. The rate at which the users adapt to the new processes varies, depending on the individuals. Not only extreme patience has to be practiced, empathy from the support person will need to be observed as well.
- System stabilization: Even if testing had been done before the "go-live", you can expect the users to find bugs in your developments once they intensively start using the system. Some setups may be wrong as well. You will have to handle and fix all these kinds of issues.
- Data stabilization: A massive data migration had been done right before the go-live and a lot of other data had been configured or entered by hand.
Although the data has been checked before going live, issues with the data will also appear. For the next few weeks, you will have to spend time to stabilize that data.