Will your current change management help you achieve business readiness?
Change management can make or break an ERP implementation. Even so, it will never be a priority for your systems integrator. System integrators are paid to implement software. Don’t take our word for it; review the contract that your legal department spent months negotiating. Payments are for software milestones, not for ensuring your end-users understand or can use the software to work in new ways.
When we talk to clients implementing ERP systems, we stress the benefits of using a firm other than their chosen system integrator for their change management. Why? It’s not enough to believe that “if you build it, they will come.” The only way to achieve lasting change is to contract a change management firm with a holistic view of the project. This will answer the questions about who is being affected, and how to tailor your plan to meet specific user groups’ needs.
At go-live, it doesn’t matter how many resources you invested in the implementation’s technical aspects. Not unless you also have users prepared to deliver the benefits of your investment.
Watch for these warning signs that your system integrator is executing a plan that meets their success criteria but fails to meet yours.
Has your System Integrator:
- Articulated the project business case in a manner your executive team and management team support?
- Claimed that documented business requirements weren’t needed because their “does everything”?
- Told you that your new workflows will be based on their system flows?
- Explained the upstream and downstream process implications of system design decisions?
- Described the impact of your upcoming change on each affected role in the organization?
- Developed a user adoption strategy, targeted communication plans, and a training strategy?
- Communicated audience-specific information to end-user groups in non-technical terms?
- Suggested designing the new system and processes with a single user group and introducing the system to all other groups at go-live?
- Eliminated or reduced time allotted for user-acceptance testing or suggested they can perform the user- acceptance testing?
- Developed training materials that teach standard system navigation but are not role-based?
- Reduced end-user training time to meet go-live dates or conducted end-user training before the code was “frozen”?
- Planned training more than two weeks in advance of when users need to apply new skills to do their jobs?
If you answered “yes” to any of these questions, you are not alone. We see these mistakes often enough to know how common they are. Any one of them can derail your successful go-live. We also know how to help you avoid these problems or solve them if you see them in your future. It’s never too late to get your project back on the right track, but every project is unique.