Why teams go around the system after go-live

Nothing crashes. The system is live, the licences are paid, and the reports look plausible. Meanwhile the orders that matter are still being agreed in a chat thread, and someone is keying them in afterwards so the numbers reconcile.

This rarely gets reported as a failure, because everyone involved is being helpful. It surfaces months later, as a stock figure nobody trusts.

Most training covers the flow that works: a normal sale, a normal order, a normal delivery. Staff do not go around a system because they cannot do the normal thing. They go around it the first time something abnormal happens and the system has no obvious answer.

So training should be built from the awkward cases — the refund, the partial delivery, the customer who pays in two parts, the item that arrives damaged. If those have a path, the system survives contact with a real week.

A workaround exists because it is quicker for the person doing it. If entering a sale takes eleven clicks and a WhatsApp message takes one, the message wins, and no amount of policy will change that.

This is usually a configuration problem rather than a behaviour problem: too many required fields, a screen designed for the back office being used at a counter, an approval that adds a day for no benefit.

Requirements the team recognises, because they were written from how they actually work. A UAT they ran themselves, so go-live was their decision. Training on the difficult cases. And documentation — a runbook — so the answer to “how do I do this” does not depend on whoever implemented it still being reachable.

None of that is glamorous, and all of it is cheaper than an ERP nobody uses.