To mitigate the overall risks of an implementation, big corporations tend to phase in their ERP programs, often rolling out plans over a multi-year period. This is a sound approach, and in between phases of the implementation is an opportune time to engage in an ERP tune-up. Remember that it is much easier to correct your course after you’ve flown 5 feet than after you’ve flown a mile. Below is an 11 point plan that you can use to revive your program to ensure it is running as smoothly and economically as possible.
1. Program Execution Strength / Weakness Review – start by looking at your program from top to bottom. Identify what you know is working well and determine the areas that you know require a lot of improvement. This risk review can be conducted by your software provider, your system integrator, or an independent 3rd party. Paying somebody a few dollars to quickly identify where the potential gaps exist in productivity will be money well spent. You don’t want to spend a lot of energy chasing down small amounts of potential productivity gains, but you do want to know where the big elephants are that can provide tremendous paybacks to the program.
2. Business Case Alignment / Strategic Validation – make it a point to review the overall business case for the program and identify the critical components of the next deployment that support the business case. You will want to secure these components with the best talent. Review your company’s new product portfolio to determine if significant changes need to be made to the design to accommodate these products. Finally, examine recent acquisitions or planned divestitures to validate the expected deployment sequence.
3. Review the Program Methodology for Delivery – conduct a complete sweep of the previous wave to confirm that all documentation promised by the system integrator was delivered. Review the overall quality of the deliverables generated to determine if standards need to be modified to improve the content of what is delivered by adding to, enhancing, or subtracting from each. With a base system and documentation in place, revise the delivery processes put in place to leverage the previous delivery phase. Review processes for RICEF, training, process revisions, etc.
4. Review the Estimating Assumptions and Parameters – over the course of a multi-year project, teams should periodically review estimating parameters. Assumptions should be made regarding leverage of previously delivered work and the productivity that comes from experience gained on the program. These new productivity assumptions should be integrated into the next SOW you work out with the system integrator.
5. Vet Your Current Staffing Plans and Assumptions – with a revised deployment methodology, an experienced base of users from previous deployments, and seasoned program staff, program leaders should re-examine the experience level required on program staff and the assumed on-shore / off-shore mix. This is an excellent opportunity to take more risks in this space with the realization that opportunities to recover non-realized productivity assumptions are available by scaling up the talent. This is also an excellent opportunity to examine the possibility of deploying previous wave super-users or power users to lower the costs of system integrator onsite resources required during deployment. My experience says that the more experienced bodies on the ground at the deployment sites, the smaller the avalanche of problems after go-live.
6. Run a Cultural Environmental Check on the Future Deployment – for new deployments, a review of the holiday / vacation schedule, labor laws, and corporate culture will provide insight into deployment scheduling and change management requirements. You don’t want to be surprised with the 2 week Chinese New Year holiday period at the end of January or the 35 hour a week labor laws in Europe.
7. Revisit your System Integrator and Software Provider Contracts – it is likely that your SI promised to deliver several productivity assets to deploy as a part of your contract. Did you leverage them? If not, why not? Are there additional assets that your SI has developed over the last year that you should be implementing? It is likely they are not going to be the ones putting these tools on the table mid-engagement. You will need to drive them to pull them out. Did your software provider promise no charge help and assistance for deployment? Did you take advantage of it? If not, what prevented you from taking advantage of this service? Work with your system integrator and software provider to integrate the execution of these no charge services into your next schedule. Also examine the next SOW proposed to confirm that the costs presented have taken into consideration the productivity assumptions identified in Points 3 and 4. This is also a good time to review the current incentive structure… is it still effective and driving the right behavior? Is it consistent with best practices?
8. Test your Governance Structure & PMO Practices – the later sites in a geographic deployment (designing the entire system and rolling it out site by site), become more about raw operational execution than about strategic business process decision making. Ensuring you have the appropriate steering committee that can commit the required resource is essential to the future wave’s success. Project management processes should also be reviewed to confirm that all relevant points of view are considered during risk assessment. Improvements identified in Points 1, 3 and 4 should be structurally integrated into the tracking and program performance evaluation methodology.
9. Challenge your Technical Infrastructure Assumptions – with a couple of deployments in place, validate you have enough technical horse-power to handle future waves. Re-examine the total projected license picture to determine if more or less licenses will be required than anticipated. Depending on the answer, it may be to your advantage to start early negotiations with your software, hardware or SAAS providers. If the next wave is your 2nd deployment, give some consideration into the managing of the sandbox, development, and QA environments. With a production system in play you might not have the flexibility you enjoyed in the first wave. Development of techniques and processes to manage an increased number of development environments can cut weeks off of expected deployment times.
10. Renew your Internal Collaboration and Communication Procedures – with an installed base, communications of changes to process and technology need to flow to and from the project team. Business systems need to be put in place that allow the support teams to understand future deployments and for the current users to communicate process deficiencies and improvement requirements. While ad-hoc systems will work, developing a formal process of communications will provide assurances to all parties that their voices will be heard.
11. Reset the Program Risk Register – after you have determined the changes you will be making as a part of your program tune-up, you will need to address the risk register. The risk profile of the deployment of an established working design is decidedly different then an untested design. While process design risks will likely reduce with each successive deployment, business at stake risks increase as new deployments are added to the existing environment.
The ERP tune-up is a project within a project and should be managed on a tight timeline. Construct a project plan with a proven leader to drive execution and to ensure the structural incorporation of all the improvements are identified.