There is a moment that arrives somewhere between six and twenty-four months after an ERP go-live. The project team has disbanded. The consultants have left. And someone senior finally says out loud what several people have been privately thinking: "We spent all that money — why doesn't anything actually work better?"
If that sounds familiar, nothing unusual has happened to you. Industry research has been consistent on this for two decades: a substantial majority of ERP implementations run over budget, over schedule, or fail to deliver the benefits in their original business case — findings repeated across studies by the major analyst firms and implementation researchers year after year. The systems go live. The value, far more often than the industry likes to admit, does not.
Why go-live gets mistaken for the finish line
Implementations are run as projects, and projects need an end date. Go-live is the natural candidate: visible, binary, celebratable. The entire organisation's energy converges on that moment — and then, having "finished," attention moves on. Even the industry's own terminology gives the game away: the standard post-go-live support phase is called hypercare, and it typically lasts four to eight weeks. The implicit message is that after a month or two, the organisation should be fine. In our experience, the real work is usually just becoming visible at that point.
Go-live proves the system runs. It proves nothing about whether the operation improved. Those are different achievements, and the second one was never on the project plan.
The three gaps go-live leaves behind
The process gap. Established implementation wisdom — echoed in ASCM/APICS bodies of knowledge and every serious methodology — says processes should be mapped and rationalised before migration. In practice, timeline pressure means existing ways of working are carried across largely unchanged, workarounds and all. The system doesn't correct them. It formalises them.
The training gap. Standard implementation training is organised by module: users learn their screens and their transactions. Very few learn the logic of the end-to-end processes they participate in, or how their data lands on teams they never speak to. The result is functional competence with no shared understanding — which is exactly where cross-departmental disputes are born.
The discipline gap. An ERP silently assumes operating disciplines the business may never have built: cycle counting to industry-standard accuracy levels, master data governance, variance investigation, structured handoffs. Where the discipline is missing, the system's numbers drift from physical reality — and once people stop trusting the numbers, the shadow spreadsheets return.
A practical sequence for closing the gaps
Step 1 — Run an honest post-implementation review. Not a project retrospective — an operational one. Where is the system being worked around? Which reports does nobody trust? Where do the same disputes recur? This is standard post-implementation review practice; it is simply rarely done once the project budget closes.
Step 2 — Map actual process against designed process. Function by function, on the floor, across shifts. The gap between the blueprint and reality is your real work list.
Step 3 — Rebuild training around flows, not modules. Planners with warehouse teams, procurement with production. The question shifts from "how do I do my transaction" to "what does my transaction do to everyone else."
Step 4 — Install the missing disciplines. Cycle-counting cadence, master data ownership, variance root-cause review. These are documented industry standards, not innovations — they simply need to be built and owned.
Step 5 — Assign post-go-live ownership. Someone must own system-process alignment as a permanent responsibility, not a project role. When nobody does, drift is guaranteed.
Keeping it closed
The gaps above have a habit of re-opening — new staff arrive untrained on the flows, disciplines slip under pressure, workarounds creep back. This is why we structure ongoing support through the Kindred Programme: quarterly reviews that check whether the disciplines are holding, priority access when something starts to slip, and a standing relationship with someone who knows how the operation is supposed to run. The investment in the system is already made. The gap between a live system and a performing operation is closeable — and, once closed, keepable.