After go-live: making the ERP stick when the consultants leave

There is a moment, four to eight weeks after go-live, that decides the real fate of an ERP program. The consultants have demobilized, the hypercare war room has been dissolved, and the first month-end under the new system has been survived. This is when the organization makes its quiet, collective decision: work through the system, or work around it.

The workarounds never announce themselves. They look like a purchasing officer keeping “his” Excel tracker beside the ERP “just to be safe.” A site engineer approving on WhatsApp and entering the transaction later. A finance team exporting to spreadsheets because the report “isn't quite right yet.” Each one is individually reasonable. Together they hollow out the system until, a year later, the ERP is an expensive data-entry backend for a business that still runs on spreadsheets.

Measure usage, not sentiment

Post-go-live surveys measure how people feel; they do not tell you whether the system is being used as designed. Build an adoption dashboard from the system's own data in the first month:

• Percentage of purchase orders created before the invoice date (a proxy for “the process runs in the system, not after the fact”).
• Time lag between physical goods receipt and system receipt.
• Number of transactions entered by the person who should enter them — versus batched by one “super user” on behalf of a whole department.
• Report downloads vs. spreadsheet uploads to shared drives.

These numbers surface the workarounds while they are still habits, not culture.

Fix the top ten irritations fast — and visibly

In the first sixty days, users judge the system on small things: a mandatory field nobody understands, an approval that routes to someone on leave, a report that takes eleven clicks. Collect these, pick the ten with the widest impact, fix them inside a month, and — critically — announce that you fixed them because users reported them. This single loop, done publicly, converts skeptics faster than any training campaign, because it proves the system responds to the people using it.

Keep a decision forum alive

During the project there was a steering committee to resolve disputes. After go-live those disputes continue — who owns a master record, whether a process exception is allowed, whether a department's change request is worth building — but the forum is usually gone. Keep a lightweight business process board: monthly, one hour, process owners plus IT, with the authority to approve changes and to say no. Without it, changes either stall (frustrating users) or leak in unmanaged (fragmenting the design).

Retire the old ways deliberately

Shadow systems die when their inputs die. Set explicit retirement dates: the legacy system goes read-only on a date, the shared-drive templates are archived, the parallel Excel report is discontinued by the manager who used to request it. That last point matters most — as long as a senior manager keeps asking for the old spreadsheet, an employee somewhere will keep maintaining it, whatever the policy says.

Train for the second wave

Six months in, the workforce is no longer the one you trained. New joiners learned the system from a colleague's shortcuts; promoted staff inherited approvals nobody explained. Build a standing onboarding path — short role-based modules, a searchable how-to library, named super users per department — so the system's knowledge lives in the organization, not in the memory of the go-live generation.

Protect the budget for the boring quarter

Most ERP budgets spend ninety-five percent of their money getting to go-live and treat everything afterwards as support. Yet the ninety days after go-live are when the return on the entire investment is decided. Ring-fence a genuine adoption budget from the start — typically five to ten percent of project cost — covering the irritation-fix sprints, the refresher training, the super-user time, and the reporting improvements users request once they see real data. When this money is not protected, the requests queue behind “business as usual” IT work, momentum dies quietly, and a year later the workaround culture is entrenched.

Executives have a role here that costs nothing: use the system's own outputs in their meetings. The month leadership starts asking questions from the ERP dashboard instead of the old spreadsheet is the month middle management stops maintaining the old spreadsheet. Adoption cascades downward faster than any training plan pushes it upward.

Implementation ends at go-live. Adoption is a management discipline that begins there — and it is the cheaper of the two, if you treat it as seriously.