ERP Consultants



ERP Implementation Support



In all of our ERP projects since 1996 no client has ever said “my last ERP implementation was a good time. Everything went just as planned.”    The recollections and stories are usually quite the opposite.

Typical ERP Implementation Approach Chart 2k-Post go-live Stabilization2j-Go Live Event2i-System User Training 2a-Prepare 2b Hardware and Software Installation 2c-Business Process Design 2d-Standard Process Setup 2e-ERP Development and Integrations 2f-ERP Testing 2g-ERP Data Development/Migration 2h-Procedure Development



The reasons ERP implementations are almost always over budget, take longer, and cost more than planned is explained in our 1-hour implementation control webinar. In response to these persistent problems, EAI has built and tuned over the years an implementation approach that manages or avoids project factors that cause these typical problems. The main difference in the EAI implementation approach and the ‘typical implementation approach’ is the level of project ownership and control by the buyer of ERP. This includes the imperative for the buying company to fully own the future-state process planning, design of metrics, data migration, and identification and retirement of existing process support tools (forms [paper or electronic], spreadsheets, databases, point applications, etc.). The steps are:

  1. Prepare (Major Stage #2a): Activities to prepare the internal company team and the implementer’s team based on planning developed in the pre-implementation (1) major step #1d Implementation Approach Developed, (2) major step #1e: ERP Implementer Immersion. Return to Chart
  2. Hardware and Software Installation (Major Stage #2b): The discussion of necessary hardware and other IT infrastructure to support the new ERP should have begun in earnest a few months before the formal implementation duties begin. The respective ERP vendors will have a formal function that recommends hardware configurations for the new system. Return to Chart
  3. Business Process Design (Major Stage #2c): This activity begins with the implementer advising about the order of processes to discuss, usually based on the particular ERP, and to a lesser degree by the priorities or other constraints of the company’s internal team. During these discussions there’s an in-depth and purposeful use of the previously developed Enterprise Discovery and the accompanying list of existing process support tools (e.g. spreadsheets, paper forms, etc.). These discussions will result in many new entries into the ERP Implementation Development Specification. Return to Chart
  4. Standard Process Setup (Major Stage #2d): From the initial discussion in the prior step called Business Process Design decisions will be made on most default or optional ERP configuration options. These configurations are made and tested in this step. Return to Chart
  5. ERP Development and Integrations (Major Stage #2e): From the prior major stage 2c called Business Process Design, a development specification will be created to further set up the new ERP. This development specification should usually be achieved by use of the ERP’s built-in configuration, workflow, BI/metrics, and integration tools. This specification is managed in an EAI tool called: ERP Implementation Development Specification. Return to Chart
  6. ERP Testing (Major Stage #2f): The internal project team should run and execute the point testing and comprehensive testing of the new ERP-supported processes with support from the implementer’s ERP experts. This builds on protocols set forth in earlier sections that emphasize protecting the business process intent. The internal team knows the business process intent better than anyone. Return to Chart
  7. ERP Data Development/Migration (Major Stage #2g): The company-specific approach for operational data cleanup and eventual migration was developed in earlier planning in this document, section: Implementation Approach Development.  The plan should now be tuned and put into effect. Operational data are current records on BOMs, customers, suppliers, routings, and many other sets of data that may need to be dynamically visible in the new ERP (dynamically = directly available for use in new ERP transactions). Key points are:
    • The results of the detailed implementation planning will determine many details which affect the operational data cleanup and migration activities, so final data migration planning must wait until this planning is mostly complete, although some operational data cleanup work can proceed earlier.
    • Only a subset of all current operational data will be relevant to be 'dynamically' visible in live ERP data tables. Other operational data will be acceptable in other electronic or static forms. Applying this distinction carefully can reduce the strain and time to complete the data cleanup and migration. If other data is later determined to need to be 'dynamically' visible, it can be migrated then.
    • The timing of when to conduct data cleanup activities can vary based on the data set and other factors. This should be carefully discussed for each data set so the process to clean up operational data can be planned with sufficient time to avoid an unnecessarily large data review or cleanup exercise close to the go-live event.
    • The operational data which needs to be dynamically visible in new ERP will need a final review for stability before being moved into the new ERP. Data field limitations or other validation criteria may reject data or have it not behave properly if entered into the ERP's data field. This activity needs to be carefully conducted with the expert in the ERP before test migrations (and full migration) are conducted. Return to Chart
  8. Procedure Development (Major Stage #2h): There are typically many changes to how the ERP looks and how routine processes are performed, based on prior efforts to tune the ERP to support many processes and metrics that were not native. In situations such as this, company-specific procedure development is useful to speed new user adaptation and make the training and stabilization of future new users easier. Return to Chart
  9. System User Training (Major Stage #2i): Similar to procedure development in the prior stage, the user training typically should be adapted to how the ERP has been set up and not be standard generic system training. The ERP sellers will have material that can usually be adjusted to reflect the installation-specific changes. Careful attention should also be given to the selecting trainers. Return to Chart
  10. Go-Live Event (Major Stage #2j): The go-live event is usually conducted at the end of a quarter and over a weekend. The go-live date staying firm presumes proper preparation and success in the prior stages so the go-live event is reasonably smooth. Return to Chart
  11. Post Go-Live Stabilization (Major Stage #2k): After an ERP go-live event there will always be processes or metrics broken and otherwise not working correctly. There will also be many errors that are a function of system user training and other problems. As a result, there needs to be a careful and dedicated effort to smartly manage this post go-live period so the company using the new ERP can rapidly address the bugs and build confidence in the new ERP. Return to Chart

Implementation Project Staffing Approach

The project participants described below are required to support the ERP implementation. A foundational point about the team hierarchy shown below is where the ERP project management is conducted. With the ERP buyer’s Internal Project Team having the experience, skill, and capacity to lead the project, the implementer’s team falls under the project management protocols of the buyer and largely fills the role of the ERP expert and works with the internal team to determine the optimal way to achieve business process objectives with the new ERP.


ERP Implementation Project Team Coordination Chart



The external implementation consulting firm is effectively comprised of various experts in the new ERP and management. They are not experts in the specific company that will be using the new ERP and the correct business processes/metrics necessary for the company. Therefore their input is always subordinate to those that own and control the business process objectives—but this does not mean the knowledge and advice of a skilled implementer is not valuable. This is critical—especially when the company is attempting to be highly adaptive to the better practice structure of the new ERP.

The implementation project roles Engleman Associates, Inc. (EAI) supplies:

Implementation Process Manager: The ERP implementation control approach detailed in this document seeks to reach exceptional results, described as the ‘True project potential’ with modern ERP software well suited for the Buyer’s business. Toward reaching these results, the following skills, experience, and capacity are necessary from the Implementation Process Manager.

Methodology Expert: The EAI Methodology Expert is a top-level expert in the methods and tools that have been developed by Engleman Associates, Inc. (EAI). EAI methods and project tools are designed to meet the varied demands of specific business software projects. An EAI Methodology Expert primarily works with the project team as a coach in a consultative role and provides:

“Just the Facts” Webinar

It’s difficult to convey the strength of the Engleman Associates Implementation approach through the written word. Therefore we encourage you to participate in our free one-hour webinar on ERP implementation control. This webinar is a 'just the facts' case study and not a sales pitch. We strive to make this a productive use of your time as you will take away concepts and tips to use. The presenter is typically Mark Engleman who developed this overall implementation control process. He has been involved in over 600 ERP projects and has presented hundreds of ERP training webinars. For the current schedule, send an email to or give us a call.