The software was never the hard part

Talk to enough businesses about their ERP experience and a pattern emerges that has almost nothing to do with which system they chose. The software goes live, the data migrates, the training happens, and the go-live itself is judged a success. Then, six months or a year later, something feels incomplete — not broken, not failed, just short of the transformation everyone expected — and the diagnosis usually points at the software, when the actual cause is somewhere else entirely.

What a go-live actually proves, and what it doesn't

A successful go-live proves the system works: data flows correctly, reports generate accurately, the configured workflows execute as designed. That's genuinely hard to get right, and getting it right is a real achievement worth recognising.

What it doesn't prove is that the business's operating knowledge survived the transition intact. The configuration decisions made during implementation encode a huge amount of judgement — why this approval threshold, why this exception, why this workflow routes the way it does. That judgement is fully available during implementation, when the consultant and the business's own team are actively discussing every decision. It's rarely captured anywhere, because implementation projects are measured by whether the system works, not by whether the reasoning behind it survives past the project itself.

Why this gap shows up later, not immediately

Right after go-live, everyone involved still remembers the reasoning — the implementation team, the internal project lead, the department heads who were consulted. The system runs, questions get answered quickly because the people who know the answers are right there. The gap only becomes visible once those people move on: the consultant's engagement ends, a staff member who was closely involved leaves, and the next person who needs to understand a configuration decision discovers there's no record of why it exists, only that it does — see what a system of record cannot do.

Why this isn't a criticism of implementation projects specifically

It's a structural feature of how most implementations are scoped, not a failure of execution. A project is typically scoped around getting the system live, correctly configured, and the team trained to use it — a large, legitimate body of work on its own. Extending that scope to also formally capture the reasoning behind every configuration decision would meaningfully expand the project, and most businesses, reasonably, don't ask for that upfront, because the value of doing so is invisible until the specific moment it's needed.

What actually closes the gap, realistically

Treat the implementation period as the cheapest possible moment to capture reasoning, and use it deliberately. Every configuration decision made during implementation already requires someone to articulate why. Writing that reasoning down, attached to the setting it explains, costs very little extra at that exact moment and becomes expensive to reconstruct later — see what to capture before you configure a workflow.

Don't mistake a smooth go-live for a complete implementation. A go-live that runs without a hitch tests the system's correctness. It doesn't test whether the business retained the judgement embedded in its own configuration, and those are genuinely separate questions worth asking separately.

Build the habit of capturing reasoning into ordinary operation, not just implementation. The gap doesn't stop mattering once the project ends — every exception, every non-standard arrangement made afterward carries the same risk, and the same discipline that should have applied during implementation applies for as long as the business keeps making judgement calls, which is to say, indefinitely.

The actual measure of a complete implementation

Not whether the system works on day one — that's necessary and it's the easy part to verify. The more demanding, more useful test is whether someone who joins the business two years later, with no connection to the original project, can look at any given configuration decision and understand why it exists. Most implementations, judged by that standard rather than by go-live success, have more work left to do than anyone realised at the time.

Common questions

If an ERP implementation goes live successfully, why can it still feel incomplete a year later?

Because a successful go-live proves the system technically works — data flows correctly, workflows execute as configured — but says nothing about whether the reasoning behind those configuration decisions was ever captured. That reasoning is fully available during implementation and typically undocumented, so it disappears once the people involved move on.

Is this a failure of the implementation process itself?

Not really — it's a structural feature of how most implementations are scoped. Projects are measured by whether the system works and the team is trained, not by whether every configuration decision's reasoning is formally preserved, because the value of that capture is invisible until the specific later moment it's actually needed.

When is the cheapest time to capture the reasoning behind an ERP's configuration?

During implementation itself, since every configuration decision already requires someone to articulate why a setting is the way it is. Writing that reasoning down at that moment costs very little extra. Reconstructing it later, once the people involved have moved on, is far more expensive and often incomplete.

What's a better measure of a complete ERP implementation than a smooth go-live?

Whether someone joining the business years later, with no connection to the original project, can look at any configuration decision and understand why it exists. Judged by that standard, most implementations — however smooth their go-live — still have real work left to do.

Related: what a system of record cannot do · what to capture before you configure a workflow · configuration without a reason attached