Preparing for ERP Implementation

A vast majority of ERP implementations are held back by numerous obstacles—some seen and some unseen. The ramifications are overly costly and stressful implementations which fall well short of the ERP’s true business potential project.

The following information is about an ERP implementation approach which avoids standard implementation assumptions and practices—mainly by elevating the ERP buyer’s internal team and project structure to fully control and lead the project. In doing so, the buyer can escape the ERP implementation industry culture which presumes buyers are not prepared, and which is the basis of industry methods and attitudes which are a roadblock to reach toward excellence.

Major Process Steps

1: Pre-Implementation Planning

a. Targeted Business Process Topic Discussions

This process identifies and documents business process topics having a high risk of encountering implementation project problems and results not reaching full potential. These business processes fit one or more of the following criteria:

  • Are considered complex.
  • Have entrenched legacy business process thinking.
  • Are subject to potential high change management issues.
  • Exist at or bridge the ERP boundary.
  • Are subject to influences from upstream or downstream business processes in the ERP project scope.
  • Have high cost saving potential if achieved well.
  • All these findings are organized by business process categories, subcategories, and topics for easy recall during the ERP implementation.

b. Existing Business Process Support Tools Listed

These are existing spreadsheets, paper forms, procedure lists, commercial and developed point-applications and more, which currently support business processes and metrics considered to be in the ERP scope. These existing tools are critical to assess in the business process design phase of the ERP implementation, with most tools being methodically removed from use after the go-live event.

c. Establish Buyer Controlled Implementation Approach

In this step a number of important project resources are identified, and project control protocols are set. The resulting project approach usually leverages about 80% of the ERP implementer’s typical processes and does not need to be disruptive to their approach and style. However, the implementer is no longer depended upon for top-level project management or leadership, but instead focused upon being an ERP application subject matter expert. The following are key areas of review and potential modification and augmentation to a typical implementation approach.

  • Establish project control protocols which are profoundly important to project success. These project governance rules relate to:
    • Project scope control.
    • Project momentum and continuity protection.
    • ERP adaption to native functionality to eliminate illegitimate legacy processes and metrics from coming forward.
    • Comprehensive project management structure.
    • Full control of project discovery and planning in an agile collaboration framework 100% controlled by the ERP buyer.
  • Project team member required—internally and from implementer with standards for skill, experience, capacity, and responsibility (see later section of this document called Implementation Project Staffing Approach).
  • Implementation project plan development which considers the ERP buyer’s readiness to conduct the ERP implementation and the implementer’s methods, tools, and project management structure.
  • Cost monitoring and control model for the project.

After the modified implementation approach is developed, the effort to prepare and train participants varies. In more complex projects a one to two-day workshop is conducted with the client team, one or more EAI consultants, and selected members of the implementer and other key third party consultants.

d. Immersion for Implementer

Using selected discovery developed in Step #1a (Targeted Business Process Topic Discussions), review the ERP buyer’s enterprise processes with the implementer’s lead business process consultant (aka: anchor consultant), and potentially other implementer or third-party consultants as needed on specific topics. This immersion is designed to be a highly efficient method to:

  • Educate new consultants about the ERP buyer in general.
  • Provide new consultants detail about the business process objectives which materially fit the interview criteria listed in the prior step called Targeted Business Process Topic Discussions.
  • Rapidly build consultant’s confidence and competence to move smartly into the business process design phase of the formal implementation.
  • Begin the process of developing preliminary plans to meet process objectives in the new ERP and locate potential problem areas.
  • Replace typical familiarization interviews which usually consume much more time and cost, and which carry a high risk of moving the implementation back toward the typical and adverse approach and culture.

2: ERP System Implementation

a. Prepare

Activities to prepare the internal company team and the implementer’s team based on planning developed in (1) major step #1c Establish Buyer Controlled Implementation Approach, (2) major step #1d: Immersion for Implementer and (3) in earlier comments in this section of this document.

b. Hardware/Software Installation

To the extent the ERP will be hosted by the buyer on site or other arranged hosting-only entity, 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 began. The respective ERP vendors typically have a formal function that recommends hardware configurations for the new system.

The recommendations made by the ERP vendor may not be sufficient or congruent with existing IT infrastructure, so it’s useful to locate a capable and experienced independent IT infrastructure expert to review and comment on the ERP expert’s suggestions. If there is any disagreement or doubt, it’s usually preferred to upgrade or increase the capabilities of the hardware provided there are not large cost differences. If one ERP hardware and IT infrastructure scenario is significantly more expensive, then the represented benefit needs to be more closely studied in the context of the cost.

Installing the hardware and other infrastructure should be done by experts. The same is true for new operating systems, virtualization software, databases, and eventually the ERP. Furthermore, all parties involved should be coordinating by reviewing installation details to ensure that the hardware and software is compatible with and supports other components in the ERP system. The resulting IT infrastructure should be strong to avoid being the source of issues or complications going forward.

c. Business Process Design

This activity begins with the implementer advising about the order of processes to discuss, first influenced by the process structure of the particular ERP, and to a lesser degree by the priorities or other constraints of the company’s internal team. For example, a company’s process area experts and the Implementation Process Manager begin with a discussion on the general ledger and related accounting issues, then they progress to a discussion on purchasing functionality standard structure, options, and issues or concerns.

Most early discussions will be about default options and discussion topics in the ERP implementer’s normal list. However, many nonstandard process and metrics items will come up along the way in these discussions.

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, procedures, etc.). The presence of these materials should result in more being achieved with native functionality than otherwise occurs when future-state process design influencers are not seen. For objectives that cannot be achieved with native functionality, configuration or development instructions should be entered into the ERP Implementation Control FrameworkTM. For example, the ERP-specific approach to achieve a nonstandard business process objective usually results in one or more Requirements, and each Requirement may result in several configuration details (native functions may also have configuration details too).

To further underscore the potential level of involvement and difficulty in properly achieving any particular business process objective, see an example in Addendum E. The key point being if these sorts of process design and implementation details are not sought out and used, then many more sub-standard and even unworkable processes will result in the new ERP.

d. Standard Process Setup

From the initial discussion in the prior step called Business Process Design, decisions should be made on most default or optional ERP configuration options. These configurations are made and point tested in this step.

e. ERP Development and Integrations

From the prior major stage 2c called Business Process Design, non-standard business processes and metrics objectives were identified and some were authorized for pre-go-live development. For each of these, an ERP development specification is created. These development specifications can be held in the ERP Implementation Control FrameworkTM from EAI.

f. ERP Testing

The internal project team should run and execute the business process point testing and increasing levels of enterprise-level testing of the new ERP-supported processes with support from the implementer’s ERP experts.

This testing process should be a formal and visible element to the implementation process. Testing plans for native ERP functionality is often reasonably provided for by the ERP implementer. Test plans for new functionality and reports developed with ERP tools should be managed in the ERP Implementation Control FrameworkTM from EAI.  Besides ensuring the correct results are achieved, testers should look for any ERP approaches which are slow or have usability issues. The cumulative effects of such speed and usability issues often marginalize the business application’s utility and value.

The test environment will depend on the business application, the complexity of the business objectives, and the number of people available for testing. The testing environment and plan needs to be established with the experts in the particular business application.

g. ERP Data Development/Migration

The company-specific approach for operational data clean-up and eventual migration was developed in earlier planning in this document, section: Establish the Buyer Controlled Implementation Approach. 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 as subsets need to be dynamically available in the new ERP (dynamically = directly available for use in new ERP transactions). Key points are:

  • The results of the Business Process Design work (Major Stage #2c) will uncover many details which affect the operational data clean-up and migration activities, therefore more complete data migration planning can only be produced after this process design and early point testing is mostly complete, although some data clean-up work can proceed earlier.
  • Only a subset of all current operational data will be relevant enough to be stabilized and put directly into 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 clean-up and migration. If other data is later determined necessary to be directly moved into ERP data tables, it can be cleaned-up and 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 ICF has a data field for this purpose.
  • 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. ERP data field limitations or other validation criteria may reject data or make it behave improperly 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.

h. Hosting Environment Set

This comprises the work to establish a proper hosting and management environment for the ERP.  Practically speaking, the hosting environment does not need to be put in place until a time closer to the planned go-live event. Some ERP sellers and resellers claim it needs to be up sooner, but this is nearly never true as a pre-go live copy of the application can be provided through other means for development and testing. Further, the expense for the full-strength formal hosting environment can be postponed. 

i. Procedure Development

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 go-forward processes and metrics not native in the ERP. 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.

The modern ERP typically has utilities and related training videos to help with developing procedures and to make the procedures appropriately visible in the ERP user interface.

j. System User Training

Similar to procedure development in the prior stage, the training for future ERP users 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 selecting trainers and avoiding any training materials that are generic for areas that have been tuned for the business.

During the ERP development, point testing, enterprise testing and other steps, there should have been many company team members becoming familiar with the ERP who can help with the final development of the user training.

k. Go-Live Event

The event in which the new ERP is turned on and first scope functions are now used in live operations by the company team. The go-live event is usually conducted at the end of a quarter and over a weekend.

The decision to run the two ERP (old and new) for some period of time after the go-live event is based on a number of ERP buyer factors and can be confirmed a month or two before the go-live event. Typically, running two systems in any form is to be avoided.

L. Post Go-Live Stabilization

After an ERP go-live event there will always be processes or metrics not apparently 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 bugs, build confidence in the new ERP, and not fix items that are actually not broken.

3: ERP Continuous Improvement

a. Remaining Objectives

During the implementation only a subset of all business process support objectives are achieved. In the EIA methods these remaining objectives are pursued until achieved.

The Valuable Results

  • Control and lower implementation costs
  • More functions implemented – and faster
  • Improved coordination between all implementation participants
  • Lower stress on your team

Flexible Service Delivery Options

  • Many process steps can be trained and performed by your team or our facilitators.
  • Services are configurable to support business software projects that are in process – building upon your completed work.

Reduce Problems & Costs! – Join Us for Our

ERP Implementation Control Webinar