A completed ERP rollout is not a finished business

There's a natural tendency to treat an ERP go-live as a finish line — the project plan ends there, the celebration happens there, and attention understandably shifts to whatever comes next. This makes sense from a project-management point of view. It's slightly misleading from an institutional-knowledge point of view, because the go-live is closer to the starting point of a different, ongoing responsibility than the end of anything.

What actually ends at go-live, and what doesn't

What ends is the discrete, scoped project: configuring the system, migrating data, training the team, getting everything working. That's a real, bounded piece of work with a real, bounded completion point, and treating it as finished at go-live is entirely correct.

What doesn't end is the business's ongoing responsibility for its own operating knowledge. Every exception granted after go-live, every configuration change made six months later, every new workflow added as the business grows — all of it carries the exact same risk this cluster has described throughout, and none of it is covered by the original implementation project, because that project was scoped to end.

Why this distinction matters more than it sounds

Because if a business mentally files "capturing institutional knowledge" under "the implementation project," it treats the responsibility as complete once the project closes — when the actual need for that discipline never had an end date to begin with. The implementation project created the first wave of judgement calls needing capture. Ordinary operation keeps creating more, indefinitely, for as long as the business keeps making decisions.

This is the same gap in miniature that this cluster has returned to across many specific situations — see what your ERP does not record — here applied to the boundary of the implementation project itself, which is easy to mistake for a boundary on the underlying problem.

What a business often gets wrong after go-live

Assuming the documentation created during implementation is sufficient going forward. It covers the state of the business at that moment. Every change made afterward needs its own reasoning captured, using the same discipline, or the documentation slowly becomes a snapshot of a business that no longer quite exists.

Losing the habit once the implementation team's structure and rigour disappear. Implementation projects typically have dedicated project management holding people accountable for documentation. Ordinary operation rarely has an equivalent, unless a business deliberately builds one — see documenting exceptions as they happen not after.

Treating the system as "done" rather than as something that keeps accumulating configuration and judgement over time. A system in active use for years has usually drifted meaningfully from its original implementation state, in ways nobody tracked because nobody was still treating documentation as an active responsibility after the project officially closed.

What actually needs to continue past go-live

The habit of writing down the reason for exceptions and configuration changes, carried forward from implementation into ordinary operation, applied by whoever is making the decision rather than a dedicated implementation team that no longer exists.

Periodic review of what's changed since go-live, treating configuration drift as something worth checking deliberately rather than assuming the original documentation still describes current reality.

Ownership assigned specifically, not left implicit. If nobody is explicitly responsible for keeping institutional knowledge current after the implementation team disbands, it's reasonable to predict that nobody will, not out of negligence, but because responsibility that isn't assigned to anyone in particular tends not to get picked up by default.

Common questions

Why is a go-live date not really the end of the institutional-knowledge problem?

Because go-live marks the end of a scoped, bounded project — configuring the system, migrating data, training staff. The business's responsibility for capturing the reasoning behind its own decisions doesn't have a similar end point; every exception and configuration change made afterward carries the same risk, indefinitely, for as long as the business keeps operating and making judgement calls.

What mistake do businesses commonly make after a successful go-live?

Assuming the documentation created during implementation remains sufficient going forward, without recognising that every change made after go-live needs the same discipline applied to it. Without that continuation, the original documentation slowly becomes an accurate snapshot of a business that no longer quite matches current reality.

Why does the habit of capturing reasoning often fade after implementation ends?

Because implementation projects typically have dedicated project management actively holding people accountable for documentation, while ordinary day-to-day operation rarely has an equivalent structure, unless a business deliberately builds one into how it operates going forward.

How can a business keep this discipline going after the implementation project closes?

Assign explicit ownership for keeping institutional knowledge current, rather than leaving it as an implicit, unassigned responsibility. Carry the habit of documenting exceptions and configuration changes into ordinary operation, and periodically review what's changed since go-live rather than assuming the original documentation still reflects the business as it currently runs.

Related: what your erp does not record · documenting exceptions as they happen not after · why the best implementations still lose to turnover