ERP Implementations—Controlled by Buyer's Team
To ensure outstanding results, an ERP implementation project must adhere to the 10 Project Excellence Factors. Successfully formalizing these factors requires specific preparation, which can only be initiated and led by the ERP buyer.
Our Pre-implementation Planning advisory services—outlined in major step #1 below—is designed to provide this critical preparation. These services are fully configurable to support a variety of business software projects, including stabilizing projects already in progress.
Major Process Steps
1: Pre-Implementation Planning
a. Targeted Business Process Topic Discussions
Targeted Business Process Topic Discussions: This step identifies and records targeted business process topics based on the following criteria:
- Cost-Saving Potential: Business processes with the potential to generate significant savings when improved.
- ERP Boundary Processes: Business processes that exist at or cross the ERP boundary (orange boundary this sample diagram).
- Complex Processes: Business process areas requiring an involved review to better assess the path forward.
- Entrenched Legacy Thinking: Processes influenced by outdated practices and subject to potential significant changes.
- Change Management Challenges: New business processes likely to encounter substantial user resistance.
- Upstream or Downstream Dependencies: ERP business processes or metrics affected by, or that affect, other enterprise business processes.
This discover is highly organized by business process categories and topics. It is used during the formal implementation to influence the future-state business process and metrics design.
b. Assessment of Existing Business Process Support Tools
Existing tools, such as spreadsheets, paper forms, procedure lists, and commercial or custom point-applications, must be identified and evaluated. These tools currently support business processes and metrics that are known, or suspected, to be within the ERP’s scope.
These existing tools are critical to assess in the business process design phase of the ERP implementation. The potential is that most of these existing tools can be full, or partially, removed from use after the ERP go-live event.
c. Establishment of a Buyer Controlled Implementation Approach
This step involves setting-up comprehensive project controls for the buyer all based on the Project Excellence Factors described in this document. Setting up this implementation approach requires serious professional insight. This includes the sensitive exercise to adjust the selected implementer’s normal methods to scrub out elements not aligned. These adjustments mainly focus on:
- Project Detail Control: Ensuring all project details are tightly managed and in the firm control of the buyer.
- Implementation Methodology: Modifying and removing implementer methodologies to align and not conflict with the Buyer-Controlled Implementation Approach.
- Project Personnel: Ensuring clarity and synergy among project team members and necessary external partners. Full team roles shown here.
d. Immersion for Implementer
The immersion process prepares the ERP implementer’s lead business process consultants, along with other relevant consultants, for the formal implementation. This highly efficient exercise achieves the following objectives:
- Strategic Education: Provides ERP consultants with a broad understanding of the buyer’s business operations and strategic goals.
- Detail-Oriented Preparation: Delivers specific insights into high-value and complex business process objectives.
- Rapid Readiness: Builds the confidence and competence of ERP consultants on methods and tools being used, enabling them to move efficiently into the formal implementation project.
2: ERP System Implementation
a. Prepare
b. Hardware/Software Installation - as needed
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.
c. Business Process Design
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.
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 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 a development management tool of choice by the company. If there is no prior tool of choice, then the team can use the ERP Implementation Detail LibraryTM from EAI to manage development.
f. ERP Testing
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 can be managed in the development control tool of choice or the ERP Implementation Detail LibraryTM. 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.
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 using the ERP Implementation Detail LibraryTM. 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.
h. Hosting Environment Set
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 company-specific configuring, development and testing. Further, the expense for the full-strength formal hosting environment can be postponed. This diagram shows the typical and appropriate three key parties involved with the objective to deliver dependable access to ERP hosted and managed by others.
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 step, 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.
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 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