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 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 process identifies and documents business process topics that 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 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 and which are or may be in the ERP scope. These existing tools are critical to assess in the business process design phase of the ERP implementation, with the potential for most of these existing tools being removed from use after the go-live event.
Establish Buyer-Controlled Implementation Approach In this step, foundational project control protocols are firmed up and related buyer-controlled methods and tool requirements established and confirmed. This requires significant alignment exercises with the selected ERP implementer focusing on the following areas:
- Project control structure alignment: Implementers have developed various structures for controlling project details, such as tasks, issues, data migration, application development and more. However, implementer provided structure is nearly always inadequate for truly comprehensive and unified management of such details, and what they offer is not under proper control of the company purchasing services. This alignment work establishes various EAI control tools as having primacy on the project with the biggest example being the Implementation Control Framework (ICF) — a unified control structure directly managed by the company that will be using the new ERP.
- Implementation methodology alignment: The culture of the ERP implementation industry is to expect clients to largely defer to the implementer for project guidance. This dependence usually increases during the project, and the implementer’s methods routinely reflect this increasing dependence. Based on this, the buyer-controlled implementation needs various standard methodology from the ERP implementer to be changed and new details added. These adjustments are critical to identify and formalize in the project plan, otherwise there will be a persistent force to move the ERP buyer back to the standard methods built for companies unprepared for the ERP implementation.
- Project personnel alignment: The Buyer-Controlled Implementation Approach requires certain skills/experience, capacity and calendar timing for various internal and external project personnel. The quality and discipline of what is needed rarely aligns well with how implementers prefer to apply personnel and capacity.
At the core of the buyer-controlled implementation approach are these project control protocols that are critical for real success:
- Project scope control.
- Project momentum and continuity protection.
- ERP adaptation to native functionality to eliminate illegitimate legacy processes and metrics from coming forward.
- Comprehensive project management structure including unified management of the project details in the ICF.
- Implementation project team members required—internally and from implementer—with standards for skill, experience, capacity, and responsibility.
The level of effort required to design the buyer-controlled implementation approach and prepare all participants varies by client project. In some more complicated projects the buyer-controlled implementation approach is further trained, discussed, and formalized in a one to two day workshop with the client team and selected members of the implementer and other key third party consultants. The resulting ERP implementation project approach usually leverages a majority of the ERP implementer’s discrete processes and does not need to be disruptive to their approach or style.
Using selected discovery developed or refined 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:
Generally and strategically educate the ERP consultants about the company.
Provide consultants detail about the business process objectives with a focus on high-value and more complex business processes.
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 introducing typical implementation project techniques and assumptions that are counterproductive to the ERP buyer-controlled implementation approach detailed in this document.
2: ERP System Implementation
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 ERP vendors recommends hardware configurations for the new system.
This activity begins with the implementer advising about the order of business 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.
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 and the project rule to be adaptive to native functionality when possible, should result in more business processes being achieved overall, and more with native functionality than otherwise occurs.
From the prior major stage 2c called Business Process Design, non-standard business processes and metrics objectives were identified and some now can be authorized for pre-go-live development. For each of these, an ERP development specification is created. These development specifications can be held and managed in the ERP Implementation Control FrameworkTM from EAI.
The internal project team should run and execute the business process point testing and increasing more involved 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 are 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 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 using the ERP Implementation Control FrameworkTM. For example, operational data are current records on BOMs, customers, suppliers, routings, and many other sets of data that need to be available in the new ERP. Key points are:
- The results of the Business Process Design work (Major Stage #2c) will uncover many details which affect the operational data requirements and clean-up and migration activities. Therefore more complete data migration planning can only be produced after this process design, 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 clean-up 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 clean-up exercise close to the go-live event. The ICF has a data field for this purpose.
- The operational data which needs to be visible for use 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.
This comprises the work to establish a technically proper and manageable hosting 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. 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.
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.
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 overly use standard generic system training. The ERP sellers will have material that can usually be adjusted to reflect the installation-specific changes.
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.
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.
After an ERP go-live event there will always be processes or metrics not apparently working as planned. There will also be ERP adoption issues 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 new user enthusiasm and continuity are better protected.
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.