The ERP Rollout That Stalled

The evidence rules out a technology failure. The system is processing orders; tickets are about how to use it, not about it being down. What the evidence shows is a change-management and data-readiness failure.

• Ability gap. Order entry time up 35% and 22% of orders on a personal spreadsheet means people cannot yet perform their jobs in the new system. A one-off classroom session during peak season, with 78% attendance and no reinforcement, produces recognition of screens, not competence. Workarounds are the classic signal: people invent a route that works because the designed one does not yet fit their capability.
• Data quality blocking adoption. 1,900 open item master errors mean the system gives wrong answers, which destroys user trust faster than any training deficit. This should have been a go-live gate.
• No reinforcement. Super-users, the mechanism meant to provide on-the-job coaching, were dismantled within a month. Nothing is sustaining the new behaviour, so the old behaviour returns.
• Absent sponsorship. The sponsor has attended one steering meeting in five months and the IT director chairs. That tells the organisation this is an IT project, not an operating priority, and gives the two vocal branch managers cover.
• Symptom of the diagnosis: OTIF down seven points is the commercial cost; order rework and inventory inaccuracy are the mechanisms.

What it does not show: that the software was the wrong choice, or that a return to the old system is feasible. Recommend against any rollback narrative until the ability and data gaps have been addressed for 60–90 days.

Days 1–10 - stabilise and re-establish leadership. Move the sponsor role back to the COO in practice: a fortnightly thirty-minute steering meeting that she chairs, with a one-page dashboard (order entry time, workaround rate, item master errors, ticket volume, OTIF). Name a business-side change lead with authority to make decisions, not a coordinating committee. Publish a short, honest message: the go-live was under-supported, here is the fix, here is what we need from you.

Days 1–30 - fix the blockers in the order users feel them.

• Freeze and clean item master data: assign a named data owner, triage 1,900 errors by commercial impact, target the top 200 that cause most rework first, publish weekly error count.
• Rebuild super-users: twelve restored with a written role description, 20% protected time, a weekly peer call, and escalation rights. If the branch administrator who built the spreadsheet is willing, make her a super-user - she has demonstrated exactly the problem-solving the role needs.
• Replace classroom training with floor-walking and short task-based clinics at shift start, in the users' own screens with their own orders.

Days 15–45 - retire the workaround deliberately. Do not confiscate the spreadsheet; give a date, train the people who depend on it, fix the three specific gaps that made it necessary, then switch it off. Track workaround rate weekly, with a target of zero by day 60.

Days 30–60 - embed and prove. Publish two visible wins with numbers (order entry minutes, OTIF by branch). Add the new process steps to job descriptions and to the first-line supervisor's check routine so it is reinforced, not just trained.

Success measures at day 60: order entry at or below 3.1 minutes, workaround rate under 5%, item master errors under 200, tickets under 50 per week, OTIF back above 94%. If those are not moving, escalate before declaring success.

Assume part of what they say is true, and separate the valid complaint from the behaviour.

Meet each one individually, without an audience. Ask what specifically is failing in their branch: which transactions, which reports, which customers. There is a strong chance they are naming real defects that headquarters has been filtering out, and if you dismiss them you will turn a quality complaint into a permanent opposition. Where they are right, fix it fast and credit them publicly - that converts a critic into evidence that the process listens.

Then be direct about the line. They may disagree with the decision in meetings; they may not instruct their teams to work around a system the company runs on, because the cost lands on order accuracy and customer delivery, not on the argument. Restate the expectation in behavioural terms: what their supervisors must enforce, what data they must report, by when.

Give them a stake. Assign each a specific recovery item with a deadline - one owns item master accuracy for his branch, the other owns order entry time. Ownership converts grievance into accountability, and it also produces a fair test of whether the objection was about the system or about being excluded.

Escalate only on behaviour, with evidence, and only once. If either continues to actively encourage workarounds after a clear, documented conversation, that goes to the COO with specifics - dates, statements, impact. Do not escalate a difference of opinion; that is a legitimate management view. Do escalate sabotage of a system the business depends on.

Watch for the pattern across the organisation. Two vocal resisters are often a symptom of a wider silence. Ask in the next pulse check: 'do you know who to ask when the system blocks you?' If the answer is no, the problem is the support model, not the two managers.