Every failed ERP programme has a post-mortem, and the post-mortems are remarkably consistent. The software worked. The data migrated. The integrations ran. The problem was that people did not use it the way the design assumed. That sentence gets written as though it were an unfortunate afterthought. It is actually the finding. A system nobody uses correctly is indistinguishable, in business outcomes, from a system that was never installed — except that it cost several million and consumed two years. By 2011 there was enough implementation history to see the pattern clearly. Functional fit, which consumed most of the selection effort, explained very little of the variation in outcomes. Adoption explained most of it. And adoption was consistently the first budget line cut when a programme ran late.
What Routing Around the System Looks Like
Users rarely refuse to use a new system. They use it minimally and rebuild their real working process beside it, which is considerably harder to detect. The symptoms are familiar to anyone who has looked. Data is entered late and in bulk, so the system reflects a state of the business that ended last Tuesday. Key fields are populated with whatever passes validation rather than what is true. Parallel spreadsheets appear — the "real" numbers, maintained by one person, circulated informally, trusted more than the system. Workarounds develop for steps the process designers thought were mandatory. And reports are politely ignored, because the people who know the data know it is wrong. Each of these looks like a training issue. Mostly they are not. They are rational responses to a system that made someone's job harder without making anything they care about easier.
Why Adoption Fails, Specifically
Six causes account for the overwhelming majority of cases, and only one of them is about training. The process changed and nobody explained why. Implementation almost always redesigns work. When the reasoning behind a new step is never communicated, users experience it as arbitrary bureaucracy and route around it — correctly identifying that nobody has told them what it is for. The new way is slower for the person doing it. A step that takes ninety seconds instead of twenty may be entirely justified by downstream benefit, but the cost falls on one person and the benefit lands somewhere they cannot see. Without acknowledging that trade, you are relying on goodwill. Training taught navigation, not work. Two days of screen-by-screen instruction, weeks before go-live, delivered generically. Users learn where the buttons are and not how to do their actual job, including the exceptions that constitute half of it. Nothing was retired. The old system stays available "just in case", or the spreadsheet is tolerated during transition. Given a choice between the familiar and the unfamiliar under deadline pressure, people choose the familiar, permanently. Supervisors did not change what they inspect. If a manager still asks for the spreadsheet, the spreadsheet is the system. Adoption is set by what leadership actually looks at, not by what they endorse in a town hall. Early problems went unanswered. The first weeks generate genuine defects and confusion. If questions disappear into a ticket queue, users conclude the system is not supported and revert. That impression forms in about a fortnight and is very difficult to reverse.
The Budget Dynamic That Makes It Worse
There is a structural reason adoption work is under-funded, and it is not that anyone doubts its importance. Change management is scheduled late in the plan, because it logically follows configuration and testing. Programmes run late — almost all of them do — and pressure concentrates on the go-live date. The items that can be compressed without moving that date are the ones scheduled last. Training days get halved, floor support is reduced, communication is replaced by an email, and the post-go-live stabilisation period is shortened. So the component most predictive of success is systematically sacrificed to protect a date, and the organization then spends two years and considerably more money remediating the result.
Practical Guidance on ERP Adoption
- Ring-fence the change budget. Make it structurally unavailable for reallocation to configuration overruns. If it can be raided, it will be.
- Train on real work, close to go-live. Role-specific scenarios using the organization's own data, including the exceptions and error paths. Generic navigation training delivered a month early is forgotten by the time it matters.
- Name and support super-users. People in each team who know both the system and the job, with protected time to help colleagues. Peer support resolves more problems faster than any help desk, and it builds credibility that central teams cannot.
- Retire the alternatives deliberately. Decommission the old system, withdraw the spreadsheet, and set a date. Optional adoption is not adoption.
- Change what management inspects. If leaders review system reports rather than side-channel numbers, the organization follows within weeks. This is the highest-leverage and cheapest intervention available.
- Measure adoption, not go-live. Transaction volumes against expectation, data entry timeliness, workaround prevalence, report usage. These are observable, and they tell you whether the investment is working while you can still act.
- Fund a real hypercare period. Visible floor support for the first weeks, with fast escalation and rapid fixes. The perception formed in the first fortnight determines the next two years.
- Explain the reason for every changed step. Not the benefit to the organization — the reason this step exists and what breaks without it. People comply with rules they understand and subvert rules they do not.
| Signal | Question to investigate |
|---|---|
| Transaction volumes | Does recorded activity match the work expected in the system? |
| Data-entry timeliness | Is the system updated when the work happens or later in batches? |
| Workarounds | Which spreadsheets and side processes remain in routine use? |
| Report usage | Do managers inspect system reports or request separate numbers? |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The Honest Trade
One conversation, repeated often enough, does more for adoption than most of the formal change programme: acknowledging out loud that the new system makes some jobs harder. It frequently does. Stronger controls mean more fields. Better data means more discipline at entry. Integration means someone can no longer fix a problem locally without telling anyone. Pretending otherwise destroys the credibility of everything else the programme says, because users can see it plainly. Saying it directly — this step costs you ninety seconds and here is what it prevents — converts an imposition into a trade. People accept trades. They resist impositions, and they are very good at it.
The Same Test, Applied to AI
AI tooling is currently failing for these exact reasons, at speed. A platform is procured, access is granted, an announcement is made, and usage is measured by licence activation. Some people find it transformative, most try it twice, and the organization concludes either that AI is revolutionary or that it is overhyped — when what it has actually measured is the absence of adoption work. The pattern is identical. No explanation of which specific tasks it should change. No role-specific training on real work. No retirement of the process it was meant to replace. No change in what managers inspect. No support in the first fortnight when people hit something that does not work. The technology is different. The failure mode is the one that has been documented in ERP post-mortems for thirty years, and it is still the cheapest one to fix.
Common Questions
Why do ERP implementations fail despite working software?
Because users route around systems rather than refusing them — entering data late, populating fields with whatever validates, maintaining parallel spreadsheets and developing workarounds. The software functions while the business outcomes do not materialise.
What are the main causes of poor ERP user adoption?
Process changes explained poorly, new steps that are slower for the individual doing them, training that teaches navigation rather than work, failure to retire old systems, supervisors continuing to inspect side-channel data, and unanswered problems in the first weeks.
Why is change management usually underfunded in ERP projects?
Because it is scheduled late in the plan, and when programmes run late the items that can be compressed without moving the go-live date are the ones scheduled last — so training, floor support and stabilisation get cut to protect a date.
How should ERP adoption be measured?
By transaction volumes against expectation, data entry timeliness, prevalence of workarounds and spreadsheets, and report usage — not by go-live completion or licence counts.
Change Management Review — Outpace finds where your people are working around the systems you paid for, fixes the reasons they do it, and builds adoption into the plan where it cannot be cut.