Enterprise resource planning (ERP) systems implementation projects are relatively complex in terms of technological and organizational risks, as well as multiple interrelated processes that need to be automated. Often, established processes are modified during the ERP project implementation process. The approach to implementing such a project and its elaboration, careful adherence to the procedures and processes laid down in the methodology are critical factors for the success of the project.
Schematically, the project for implementing the Microsoft Dynamics 365 Finance and Operations Applications ERP system, used by SMART business, can be represented as follows:
ERP Implementation Steps (Stages)
- Project Start
- Process Modeling and Analysis
- System Configuration
- System Testing
- System Deployment
- Go Live/Support
Let’s take a closer look. The following ERP implementation steps (stages / phases) are present within the framework of the Microsoft D365FO Apps ERP system implementation project. Depending on the specifics of the project, these phases can be strictly sequential or performed partially in parallel:
I. Project start
The work within this stage is carried out with the purpose of initiating the project and obtaining the information and plans necessary for the implementation of further steps. The key deliverables of this stage are:
- Project baseline. This plan is based on the Project Estimation data (see the “Estimation Process for the ERP System Implementation” article), but here it is adapted to real resources, their calendars and contractual conditions. The approved project plan is the baseline for further comparison of actual project indicators with planned ones (work, duration, cost, resources, efforts, schedule data).
- Project organizational structure and roles (the initial definition of this data can be performed within the pre-project activities (see the “Estimation Process for the ERP System Implementation” article), but the final approval takes place here.
The diagram for the “Project Start” stage is given below:
II. Process modeling and analysis
This stage includes:
- Analysis of current processes, architecture and data flows (As Is Model) in the form of interviews and documentation of their results in the form of a text description and development of process diagrams.
- Collection of requirements and limitations for processes, data flows and forms of information presentation and their documentation in a suitable form.
- Modeling the system to cover the requirements for processes, data flows and forms of information presentation.
- Formalization of requirements for the desired processes, data flows and forms of information presentation in the form of a Functional Requirements Document (FRD). This document contains business process diagrams (Process Mapping), a text description of these diagrams, as well as other information.
- Definition of a requirements backlog and the corresponding work on configuring the system, requirement priorities and their specifics in the form of a Fit&Gap document, where:
- Fits are work on configuring the system, and
- Gaps are work on developing new functionality or expanding the existing one.
- Definition of integration points of the ERP system with third-party products, descriptions of data flows and technical parameters of information exchange,
- Definition and formalization of the general architecture of the solution, showing the ERP system and its place in the general structure of the Solution, indicating integration points and data flows within the Solution,
- Approval of FRD and Fit&Gap documents within the Technical Task for system configuration,
- Clarification of the Baseline with possible adjustments based on the data of the Technical Task and, if necessary, modification and re-approval of the Project Baseline.
Depending on the approach used to implement the system (standard or based on a prototype), as well as the complexity of the project, the work within the “Analysis and Modeling” stage may differ in both scope and labor costs, as well as in content. Thus, the FRD is not developed for simple processes and projects, as well as for projects carried out using a prototype model, that is, based on the functionality of the system already pre-configured before the project. Also, for such projects, a simplified and reduced-scope version of the analysis of the Customer’s current processes is used. Thus, the scope of work, efforts, cost and duration within the Analysis and Modeling stage directly depend on:
- the type of implementation (standard approach or based on a prototype),
- the complexity of a specific business process,
- the complexity of the project as a whole,
- the number and specificity of system requirements,
- the number and specificity of integration points,
- other factors.
The diagram for the “Analysis and Modeling of Processes” stage is given below:
III. System Configuration
This ERP implementation step includes:
- Perform Setups (Fits).
- Perform Development (Gaps) – adding/changing functions, fields, filters, developing reports, primary forms, etc. using built-in system tools:
- Preparation of development specifications,
- Development,
- Testing.
- Configuration of data sources, workflows, data parameters, reports using built-in system tools.
- Demonstration of the system prototype for selected processes.
- Discussion and approval of key development specifications.
- Preparation of test scripts:
- Functional test scripts,
- Integration test scripts.
- Internal Functional Testing – the system is tested by the project team resources.
The diagram for the “Configuration” stage is given below:
IV. System Testing
This stage includes comprehensive testing of the system within the framework of:
- Individual processes, integrations or groups of processes (Functional Testing) – User Acceptance Testing:
- Preparation of test data,
- Demonstration of the system operation within the test scripts and training of key users,
- The system is tested by key users with the support of the project team,
- Adjustments to the system and the corresponding test scripts.
- The entire system (End-to-End Testing):
- Internal Integration Testing – the system,
- External Integration Testing – testing the system by key users with the support of the project team,
- Adjustments to the system and the corresponding test scripts.
- Load testing – used only if there are a large number of operations and/or users.
The diagram for the “System Testing” stage is given below:
V. System Deployment
At this ERP implementation step, the system is prepared for Go-Live:
- User training (key and end users). The main training of key users is performed at the Testing stage, but additional training may be required at the System Deployment stage. End user training is performed by the Customer’s Key Users. In exceptional cases, the Contractor’s specialists may be involved.
- Preparing data migration templates.
- Data migration (from the old system(s) and manually) and checking their correctness. This work is performed by the Customer’s specialists. It should also be taken into account that this task may be associated with significant efforts and take a long time. Incorrect data is one of the most common problems during Go-Live.
- Setting up access rights to system data – performed by the Customer’s specialist after appropriate training.
- Preparing the production environment of the system.
- Preparing a system Go-Live plan. This plan is developed to describe step-by-step the actions aimed at successful Go-Live. These actions can be either preparatory or describe the sequence of starting system operation for departments/processes tied to the calendar.
- Implementation of the system Go-Live plan.
- Preparation of role-based user instructions – performed by the Customer’s specialist based on the completed Functional Test Scripts.
The diagram for the “System Deployment” stage is given below:
VI. Go Live/Support
This stage is the final one for the project/project release and represents the actions aimed at system Go-Live according to the Go-Live Plan, supporting users in their operational work in the system, eliminating errors and making changes. This stage is limited in time, which depends on the contractual conditions. The work performed within this stage is as follows:
- Implementation of the Go-Live Plan.
- User support.
- Elimination of errors.
- Making changes.
Upon completion of this ERP implementation step, the project/release is considered complete, and the system is then in the post-project support mode.
The diagram of the “Go-Live” stage is given below:
Change Control
Change Control is a set of approaches, documents and procedures aimed at the controlled introduction of changes to the system and project plan. Changes are any adjustments to the approved project documents (FRD, F&G, Architecture, Points of Integrations, Project Baseline, all types of test scripts, data import templates, etc.). The change management procedure contains the following steps:
- Initiation and description of a change request (CR):
- Description of the need,
- Priority.
- Analysis of the request by the specialist responsible for the area:
- Essence of the request,
- Feasibility,
- Areas of influence of the change.
- Review of the Analysis of the request by the project management.
- Request estimation by the specialist responsible for the area:
- Efforts,
- Cost,
- Duration.
- Review of the estimation by the initiator of the change, a member of the project management group and decision making:
- Accept,
- Reject,
- Postpone.
- Implementation of change upon its approval:
- Inclusion in the plan and adjustment of the Project Baseline,
- Work execution,
- Testing:
- Internal,
- External.
- Demonstration of the system operation after the change implementation.
- Deployment of the change.
The following should be taken into account:
- Changes are one of the most common reasons for increasing the duration and cost of the project as a whole.
- Complex changes can be implemented iteratively.
- Ignoring the above change management procedure can lead to unpredictable consequences for the operability of the system.
- The number of changes directly depends on the quality of the work at the Analysis and Modeling stage and the corresponding project documents.
- The efforts required to implement possible changes are usually impossible to plan accurately. For this purpose, reserves are included in the baseline.
The diagram of the “Change Control” process is given below:
The approach to implementing ERP projects based on Dynamics 365 finance and operations applications, used by SMART business and based on the Microsoft Sure Step (Success by Design) methodology, is a logical and comprehensive set of processes, documents and procedures. Following this approach in implementation projects is a vital element for the successful implementation of an ERP system implementation project of any complexity.
20+ years in business, project and sales management. President of the Project Management Institute (PMI), Kyiv Chapter from 2007 to 2012. Hands-on project implementation experience in Enterprise Resource Planning (ERP), Human Resources (HR), Marketing, Organizations, EPM, PPM, BPMS and Business Processes (BP).
