Preparing for ERP Implementation
Most ERP implementations are held back by avoidable obstacles—some seen and some unseen. This results in overly costly and stressful implementations that fall well short of the true business potential of the ERP project.
The following is information about an ERP implementation approach that avoids standard implementation assumptions and practices—mainly by elevating the buyer to have the right skill and capacity to purposefully lead the project. This implementation approach, from Engleman Associates, Inc. (EAI), is comprised of (1) Pre-implementation Planning and optional (2) Implementation Support—which could take different forms, such as periodic monitoring of the implementation to full internal project management. This implementation readiness process should start 1 to 4 months before the formal implementation.
Major Process Steps
1: Pre-Implementation Planning
Establish and prepare team members, resources, and project control structure for the pre-implementation planning project.
- Configure Engleman Associates, Inc. (EAI) methods, tools, and project management structure based on company-specific factors.
- Deliver project start-up education and establish project management and coordination rules with key project participants.
Develop top-level company visualization; conduct detailed business process investigation; identify and organize existing tools that support current business process. The process includes:
- Assess and leverage previously conducted top-level visualization and business process investigation/planning from the ERP selection project.
- Discuss executive objectives and concerns for the ERP software initiative. Leverage similar work from the selection process and other process planning.
- Establish what business processes should be supported by the new business software based on the company’s needs and capabilities of the software being implemented. Leverage similar work from the ERP selection process and other process planning.
- Identify and organize current process support tools (paper forms, spreadsheets, databases, point applications, procedures, email templates, etc.) that support business processes contemplated to be supported by the new ERP.
- Building on the ERP selection business process interview results, conduct detailed interviews of managers/workers in the affected business process areas with a focus on detecting (1) process problems, (2) improvement ideas, (3) unusual processes and process exceptions, and (4) relevant better/best practices. Record and organize interview results using EAI project tools and building upon the hundreds of observations from the prior selection interviews.
- Discuss vision and the process for developing and using management information (feedback from operational transactions). This takes the form of automated key performance indicators (KPIs), dashboard-type interfaces, electronic notifications based on process exceptions, and classic reports.
Further develop and organize findings of the business process interviews, organizational culture, vision, and the list of business process support tools, which forms background detail crucial for higher levels of ERP implementation success. EAI consultants work to develop this comprehensive ERP planning detail, with input from the buying company’s team. This process includes:
- Review, clarify, augment, and organize observations from the business process interviews near the time they are conducted.
- Conduct a full review of all business process observations after the interviews to (1) further organize the findings by topics in Business Process Categories (BPCs), (2) further develop the findings, (3) reduce redundancy, and (4) develop and enhance all business process and company observations according to enterprise process flows.
- Conduct the preliminary review of the business process support tools collected in step #1b. Establish the tool’s purpose and list the tool in the appropriate topic (which are organized by Business Process Category).
Review and modify the ERP implementation consulting firm's standard plans and assumptions, which presume the buyer is unprepared and cannot lead. This includes:
- Initial phone meetings with implementer's management on planning and preparation, before the implementer arrives, and the potential or necessity to change some standard implementation methods, assumptions, and project management structure.
- Develop the draft implementation plan with a focus on changes to typical ERP implementer's approach for (1) business process investigation and design, (2) ERP data development and migration, (3) training, and (4) project management.
- Conduct a one-day onsite meeting to introduce and solidify the 'modified plan' going forward with the implementer, third-party consultants, and EAI team.
Using the discovery developed in Step #1c (Enterprise Discovery Development) review enterprise processes of the ERP buyer with a focus on process elements that have high value, are complex, or are subject to uncertainty as to how they will be achieved going forward. This immersion is conducted with the implementer’s lead business process consultant (AKA: anchor consultant) to build their familiarity and confidence, develop preliminary plans to meet process objectives, and locate potential problem areas.
- The results of this process are recorded in EAI project management tools.
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.