5-Step ERP Implementation Process

When implementing an ERP, following a proper process matters as much or more than which particular ERP solution you choose.

By following a structured and proven approach to your implementation, you have a much higher chance of success. Based on our experience of over 2,000 implementations completed, we recommend you follow these 5 ERP implementation steps.

 

This process was originally based on Microsoft’s Sure Step methodology. However, our method has continued to evolve (as have Microsoft’s recommended processes).

Sure Step had separate “design” and “development” steps, but we find that combining them into an iterative “solution modeling” step allows for more real-time feedback between client and solution partner, with less reworking required, and a better final fit with customer needs.

1. Diagnostic

In this step, you have initial discovery meetings with your solution partner to uncover your basic needs for the new ERP. This step answers high-level questions like:

• What are the core requirements for the new solution?
• What inefficient processes (like repeated manual data entry) will the new ERP streamline?
• What other business applications does the new solution need to integrate with?

The diagnostic step is normally taken before a major letter of engagement is approved, and so some sources leave this out of descriptions of the implementation process itself.

However, it is important for risk mitigation. A very thorough diagnostic step helps you avoid serious surprises in the next step, analysis.

2. Analysis

In this step, you and your partner review your specific business processes and determine your exact requirements.

Your solution partner should work together with you to ensure that all the relevant business processes are documented in sufficient detail.

At the end of this step, you should have a statement of work for the implementation project along with your documentation of business requirements and the solutions your partner proposes.

Common terms for this documentation are

• Business Requirements Document (BRD)
• Functional Requirements Document (FRD)
• Fit-Gap Analysis
• Solution Design Proposal

This documentation guides the next step, solution modeling.

3. Solution Modeling

The solution modelling step is by far the biggest step, and includes several sub-steps:

• Technical setup
• Design and documentation
• Construction and configuration
• Development
• Data Migration Planning
• Training
• Testing

Technical setup: Your partner prepares proper development environments for the new ERP. Much of this usually happens behind the scenes, but you may need to pay for licenses and fill out forms.

Design and documentation: Further documentation is now created to specify exactly how the ERP will be customized or integrated with other systems to fit the business processes and needs.

Construction and configuration: This involves setting up the details of the ERP’s interface and functioning. An ERP like Dynamics 365 Business Central or Finance & Operations can be configured in many ways. A skilled implementation partner, armed with proper documentation of your business needs, can usually fit most of your needs through configuration.

Development: This includes customization and integrations with other business applications. Generally, customization is more difficult than configuration, and tends to lead to later maintenance costs. However, some customization is often important to meet the unique needs of your business.

The designs for all customizations and integrations should be documented for the customer and approved before development begins.

Data Migration Planning: There are 3 important aspects of data migration planning to consider: what to migrate, how to format it, and how to clean it. Your partner can offer advice and templates for formatting and importing the data.

Training: It’s also usually best to “train the trainer.” Have your partner focus on training a smaller number of your team members thoroughly. Then in the deployment step, those team members train the rest of your staff. That makes your company’s understanding of its new ERP deeper and more robust.

In some projects, testing and training may be done as part of deployment instead of solution modelling.

Testing: User Acceptance Testing (UAT) is an essential step in any ERP implementation, but it is sometimes unwisely neglected in a rush to reach the “finish line” of go live. Note: It’s important that the testing be done by your team members (who have already been trained).

The specific tests to do are guided by a script, which should be tailored to your business. For UAT best practices and an example script for Dynamics 365, read User Acceptance Testing for D365.

4. Deployment

In the deployment step, sometimes called cut-over, you and your partner prepare and then go live with the new ERP.

The process here includes several technical steps, such as:

• Creation of the production environment
• Load testing
• Data migration and validation

This step also includes training of your staff as a whole. We generally recommend this be done by your own team members, previously trained by your partner.

Finally, your new ERP goes live. It’s often good to have this done on a Monday morning, so your team can come in fresh and start work in the new system.

5. Operation

The goal of the operation step is to transition you from the implementation project, through a successful go-live, into ongoing support.

You and your partner create final documentation for the solution as well as for a project review.

You may also have ad hoc questions that require input from your partner.

At the end of this phase, the new ERP is transitioned to client ownership with ongoing support from your partner.

ERP Implementation Project Governance

At the same time as all the above steps in the implementation are occurring, it’s also important that you and your partner have sufficient project governance for the process.

Depending on the complexity of your project, you will need one or two tiers of governance.

1. Project management team. This group is responsible for the day-to-day guidance of the project. They should:

• Develop the project schedule and track progress
• Handle change requests
• Identify, manage, and communicate risks, along with their possible impact on schedule, budget, and deliverables
• In advanced projects, escalate issues to project sponsors when necessary

Your implementation partner should provide project management, and in very large implementations there should be a project manager from the customer side as well.

For advanced projects, you will also need the 2^nd level of governance.

2. Project sponsors. These are the high-level sponsors on both the client and solution partner sides. Together, the sponsors’ role is to:

• Serve as a steering committee to remove barriers and resolve conflicts the project management team can’t resolve on their own
• Provide high-level guidance aligning the project to business needs
• On the client side, demonstrate support for the project, thus assisting with buy-in from the company at large

Ideally, the sponsors are not actively working in the project as managers or subject matter experts. It’s important to have a degree of separation between the “in the trenches” focus of implementation, and the supervisory guidance that sponsors should provide.

Encore, a Dynamics 365 Partner

At Encore, we’ve performed over 2,000 implementations of Dynamics ERP and CRM solutions, along with Power BI and the rest of the Microsoft stack.

We provide training and advice, as well as ongoing support to our clients.

If you are undergoing or preparing for an ERP implementation project, you may also want to learn more about:

• ERP implementation risks
• ERP implementation success factors
• Our services as a Dynamics implementation partner

For specific advice and assistance with your implementation project, contact us.