15 Warning Signs That Your System Integrator Is Failing At Change Management
Experts agree that change management can make or break an ERP implementation. Unfortunately, change management will never be your system integrator’s top priority because they’re being paid to implement software, not to ensure that your end users successfully adopt it.
When we talk to clients that are implementing an ERP system, we stress the benefits of using a firm other than their chosen system integrator to do their change management work. Why? Of course, we want to offer Clerestory’s services, but we also want our clients to realize the value of having a partner with a relentless focus on the needs of the business and an objective view of project progress that includes more than software milestones.
At the end of the day, the number of resources invested in the technology aspects of an implementation geometrically outnumber those tasked with making sure your end users are ready to take advantage of the enormous investment your company is making. Below is a list of tell-tale warning signs that your system integrator is not effectively delivering Change Management and could cause your project to fail.
Has your System Integrator:
- Claimed that documented business requirements aren’t needed because “they are built into the system?”
- Tried to collect business requirements without process visions or future process flows?
- Told you that system flows are adequate replacements for business process flows?
- Been unable to concisely and compellingly describe, at the beginning of the project, their user adoption strategy?
- Articulated the project’s business case drivers in a manner your executive team can embrace?
- Described the impact of your upcoming change on each role in the organization?
- Expressed a preference not to get involved with user access design?
- Communicated infrequently, without targeting specific audiences or used terms that are meaningful to the system integrator but not to your executives and end-users?
- Suggested designing the new system and processes with a narrowly-defined user group and then introducing the system to all others at go-live?
- Explained the upstream and downstream process implications of system design decisions?
- Eliminated or reduced time allotted for user acceptance testing or advised you that they themselves should do the user acceptance testing?
- Reduced end user training time in order to meet go-live dates or conducted end user training before the code is frozen?
- Developed training materials that only instruct on standard system navigation and are not role-based?
- Delivered training too far in advance of the time when users will need to apply the newly learned skills to do their jobs with the new systems and processes?
- Negotiated a contract in which they are being paid solely according to software implementation milestones rather business readiness?
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. We also know how to solve them. It’s never too late to get your project back on the right track, but every project is unique. Let’s talk about yours.