Chapter 5. Implementation Process – Customer's Perspective

In order to have a successful implementation of Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central, the company for which these ERP systems are implemented has to actively participate in the project.

In this chapter, we will cover the following aspects of the work a company should carry out to implement an ERP system such as Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central:

• Defining goals
• Defining internal processes and key users
• Defining requirements for the new ERP system
• Defining acceptable gaps and workarounds for a standard product
• Collecting all "nice-to-have features" from key users for the next steps in the projects
• Involving end users
• Following up on the entire process of implementation

We will explain the theory of all of these points, and we will also follow up on the entire process with a very specific example from a real-world implementation.

Definition of goals

Implementing Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central as your ERP system is not a turnkey project. Purchasing and implementing an ERP system is not like installing Microsoft Office, for which you run the Setup.exe file and are done with it (based on "next-next-end" philosophy). Implementing an EPR is a process and, with such a process, you need the people that are involved to actively participate in all phases of the implementation. How involved the client's team is will affect the final result of the implementation:

In the preceding diagram, you can see that implementing Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central on the partner side is a project that can be framed within a larger project, the implementation on the customer side. Depending on the scope of the project, the amount of work on each side may differ.

As in any project, defining goals is essential, to measure whether the project succeeds or not. Goals have to be...

Measuring goals

Before defining goals that are measurable, you and your partners should clearly agree on how the goals are to be measured, before and after. For example, if a goal is to reduce the number of chargebacks from a customer within six months, then it could be as simple as looking at the G/L accounts to which you post chargebacks.

Some goals are tougher to measure, for example, if the goal is to increase the productivity of the workforce, it may not be as simple as running some financial reports. For goals like these, it's recommended to define what "increase productivity" means. Is it to reduce printed documents? Is it to reduce the time between customer service calls? Once that's defined, the next question would be how to quantify and measure the goal.

When defining a goal, it should be SMART, as shown in the following definition:

Define different goals for your company and partners that are going to implement your Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central...

Defining internal processes and key users

Once the goals of the project are clear, and when the company knows what they want to accomplish with their brand new ERP, it's time to go into details and write down all of the company processes one by one that will have to be performed or supported by Microsoft Dynamics NAV.

When you think about your processes, don't just expose what they should theoretically be. Ask the people who are actually carrying out those processes about what they really do. Also, ask about the exceptions to the processes, as handling exceptions for a normal process usually requires more time from end users.

You may want to take this opportunity to eliminate exceptions for a normal process by changing how the process works. Exceptions are basically processes that are created to do something that a normal process does not accommodate. So, essentially, the user has to pay special attention and spend extra time handling these exceptions. What's worse is if they start building...

Improve before automating

IT tools allow us to automate all kinds of tasks with the aim of reducing time and errors. But not everything should be automated. An inefficient and complex process can be sped up using some kind of automation but it will still be an inefficient and complex process. Because of its complexity, the cost (in terms of time, validation, and money) of automating the process will probably be greater than expected.

In addition, trying to automate an already messed up process will only make your process more messy. It is much better to improve your business processes and think about automation once they are good and efficient.

You should also think about the importance of a process and about how often that process is done. A process that is done dozens of times per day is probably worth automating, while a process that is done once a year may not be the best candidate for automation.

The process in our example has to be clearly improved before any kind of automation is applied...

Getting the requirements

How do I know what my requirements are? Well, if internal processes have been defined, this should be an easy question to answer. You should start with the most important and frequent processes, and move on to the least important or infrequent processes. The important and frequent ones should be handled by the ERP, while the least important and infrequent processes may or may not be handled by the ERP, depending on your goals and the budget for the implementation.

 

General considerations for Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central

Talk to the consultants who will be implementing Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central for your organization. Tell them what your process looks like, who is involved in it, what information is required, and so on. They will tell you how this specific process is resolved in these ERP systems.

If the way these ERP systems handle the process matches the way you handle the process, you've...

Define acceptable gaps and workarounds

The standard product is a great product, but obviously it cannot contain all the functionalities necessary for the company. It is necessary to try to adapt to it or use workarounds to manage what may seem unmanageable.

In addition to the work of consultants, already seen in the previous chapter, the customer must play their part in trying to adapt as much as possible to the standard and accept any unmanageable gaps that can be bypassed by workarounds proposed by the consultant. The customer (the key user of the process in general) must always be the sponsor of the project and of the product.

If, instead, new gaps/requirements emerge that cannot be managed through workarounds (during the project or after the go-live date), it is necessary to classify them so as not to alter the course of the project, under an example of classification. For example, we can classify the new requirements/gaps that are detected in this way:

• Need to start
• Need after starting
• Nice...

Change management

This does not meanchanging your company's management team!

Implementing a brand new ERP means a lot of changes within an organization. The first change is the software the company is using. This will affect the people that use the ERP intensively, and they will probably be worried about the project and how it will affect their daily tasks.

But this is not the only change that the company will face. While changing the ERP, you will probably change some processes, or you could even change who is responsible for doing certain tasks. Usually, these changes are not easy to make. You will have to take action in order to reassure people and help them during the change process.

 

For example, on an implementation project I was involved in recently, the company had an employee whose major task was to post all the sales invoices in the system after the user "checked" whether everything was correct with the invoice before posting.

With the implementation of Microsoft Dynamics NAV or Microsoft...

Get involved in testing the system

When a project starts, a consultant will take all the requirements needed to implement Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central and determine which of those requirements will be covered with the standard application and which ones will be developed for you.

Implementing Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central for a company is a unique process, since it will cover the specific needs of your company. Even for similar companies, there will be many differences between processes, making their implementation unique. No matter how much experience the implementer has in the companies of your sector, you and the people in your organization are the best testers to verify that everything works as defined.

Usually, the implementer will set up a second Microsoft Dynamics NAV server (or a Microsoft Dynamics 365 Business Central Sandbox instance, as explained in a later chapter) for you, so that you can test the system...

Involve end users

End users are the people who will actually be using Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central on a daily basis. The project will truly succeed if they fully utilize the system. And they will only fully utilize the system if they believe it's reliable and find that it makes their jobs easier.

For all of this to happen, it is important that they get involved in every step of the implementation, from the very beginning. They may not have a high position within the company, and they may not have the power to make certain decisions, but they will definitely have a lot to say.

When we talked about the definition of internal processes, we said that you had to ask yourself and your people what your processes were, the activities inside each process, and the information used by the process. We also said that real processes should be considered and not just theoretical processes. The ones who actually know real processes and activities are end users. If their...

Continuous follow-up 

To maintain precise control of a project, to manage problems that emerge during the project, and to provide an estimate of when the project will be completed, it is also necessary for the customer to perform continuous follow-up. If this is not done, functional testing will be difficult to validate. There is also the risk of not verifying something that could be critical, which may lead to non-satisfaction of the project.

For example, the atomic bomb was the first project managed using real project management; the countdown of NASA is considered the most perfect instrument of analysis and control in the world. Managing an ERP project does not involve any of this, just common sense and continuous follow-up.

It is always necessary to keep a project under control, to avoid the emergence of unexpected deviations from the original guidelines that could increase the risk of failure of the project itself.

In particular, it is useful to request the following:

• A follow-up during...

Summary

In this chapter, we looked at how to handle the implementation of Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central from a customer's perspective. We covered a few areas but the whole idea is that you, as a customer, have to manage the implementation as a project. The implementer cannot do all the work for you. People within your organization will have tasks and responsibilities assigned to them, and you will have to monitor and control all of those tasks.

Get involved with the project management and with the project's progress; in order to make the project successful, continuous follow-up is needed to check the project's progress step by step. The customer must work hand in hand with the consultant to get good results (a mixed team is the best).

In the following chapter, you will see how a company may have data in other applications (their old ERP system, spreadsheet files, and so on) and how it can be massively imported into Microsoft Dynamics NAV or Microsoft Dynamics...