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
This is a process to identify and document 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.
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 implementation business process design phase and then most tools methodically removed from use.
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).
- Project plan development which considers the status of the ERP buyer’s readiness improvements and the implementation methods, tools, and project management structure of the implementer.
- 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.
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 typically consume much more time and cost and carry a high risk of moving the implementation back toward the typical and adverse approach and culture.
2: ERP System Implementation
The discussion of necessary hardware and other IT infrastructure to support the new on-premise ERP should have begun in earnest a few months before the formal implementation duties begin. 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 (in this case the potential benefits need to be studied more closely). The idea is that if there is an opportunity to improve the IT infrastructure, additional hardware capabilities can expand ERP system speed and availability.
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.
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. 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 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 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.). These discussions will result in more being achieved with native functionality that otherwise occurs when future-state process design influencers are not seen. For objectives that cannot be achieved with native functionality, many configuration or development instructions being entered into the ERP Development Specification. For example, the ERP-specific approach to achieve a particular nonstandard business process objective usually results in one or more Requirements; each Requirement may result in several configuration details (native functions may also have configuration details too). The following graphic demonstrate the need for multiple configuration tools and techniques to achieve five discrete Requirements—and the geometric complexity and cause-and-effect of these requirements to other requirements.
To further underscore the potential level of involvement and difficulty to properly achieve a particular business process objective see an example in Addendum F. The key point being if these sort of process design and implementation details are not sought and used, then many more sub-standard and even unworkable processes will result in the new ERP.
From the prior major stage 2c called Business Process Design, an ERP Development Specification is created to further set up the new ERP. The business process objectives described in the ERP Development Specification are assumed to be achieved by use of the ERP’s built-in configuration, workflow, metrics/reports, and integration tools. In other words, process objectives that can be achieved by native functionality or native metrics would not be listed in the ERP Development Specification.
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 testing process should be a formal and visible element to the implementation process. When an ERP approach is designed to meet a particular business process objective, those responsible for testing should see this function on a list and start developing test scripts and other ways to determine if the developed or configured process approach is actually working. Besides ensuring the correct results are achieved, testers should look for any ERP approaches which are slow or have usability issues. The cumulative effect 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.
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 as subset needs 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 cleanup and migration activities, so more complete data migration planning can only be produced after this process design and early point testing is mostly complete, although some 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 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 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.
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 that were 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 to help with developing procedures and to make the procedures appropriately visible in the ERP user interface.
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 selecting trainers.
During the ERP development, point testing, enterprise testing, and other steps, there will have been many company team members becoming familiar with the ERP who can help with the final development of the user training.
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 determined around a month before the go-live event.
After an ERP go-live event there will always be processes or metrics 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.
3: ERP Continuous Improvement
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.