By Ritvars Mētra, Founder of ReadinessCompassSix weeks after go-live, a planner opens the new ERP, runs the report, looks at it for a moment, exports it to Excel, and finishes the job in a spreadsheet she built herself.
Somebody notices. It gets raised at the hypercare stand-up. And the reflex response is almost always the same: remind people that the ERP is the single source of truth, restrict the export, and add a line to the comms plan about not using spreadsheets.
That response destroys the most useful piece of information the programme has received since go-live.
This article is not an argument that Excel is bad. Excel is an extraordinary tool, and in plenty of situations it is genuinely the right one. The argument is narrower and more useful: when someone rebuilds part of a brand-new ERP process in a spreadsheet, they are telling you something specific about your implementation — and the spreadsheet is usually a precise description of where the system failed to fit the work.
Read it as evidence, and it becomes a diagnostic instrument. Ban it, and you keep the problem and lose the instrument.
A workaround is not misbehaviour. It is data.
There is a serious research literature on this, and it is more sympathetic to your users than most hypercare conversations are.
Steven Alter’s Theory of Workarounds, published in Communications of the Association for Information Systems, treats workarounds as goal-driven adaptations that people create to keep work moving when they hit an obstacle in the system as they experience it. The key phrase is as they experience it. A workaround is generated by a perceived barrier, and perception here is not a synonym for imagination — it is what the system actually looks like from the chair the user is sitting in, under the deadline they are actually facing.
Ferneley and Sobreperez made a related point in the European Journal of Information Systems, identifying workaround activity as a phenomenon distinct from resistance. That distinction matters enormously in practice. Resistance means someone does not want the change to succeed. A workaround usually means the opposite: someone is trying hard to deliver their work, and the sanctioned path is not letting them.
Treating the second as the first is the most common diagnostic error made after go-live. It converts your most conscientious people into a compliance problem, and it teaches everyone that reporting a difficulty is unsafe.
It is also expensive at scale. Gartner expects that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business goals, with as many as a quarter failing catastrophically. Note the precise wording — not that the systems stop working, but that the goals do not arrive. Systems that are technically live while the expected value quietly does not materialise is exactly the pattern that benefit leakage after go-live describes, and persistent spreadsheets are one of its clearest early signals.
Why banning the spreadsheet makes things worse
Suppressing the workaround without diagnosing it produces three predictable outcomes.
- The workaround goes underground. It does not stop; it stops being visible. You have removed your telemetry, not the behaviour.
- The underlying obstacle survives. Whatever made the ERP path unusable is still there, now with a compliance instruction layered on top of it.
- The reporting channel closes. People who get told off for a workaround do not bring you the next one. You lose the early warnings that would have let you fix problems cheaply.
The better instinct is the clinical one. A spreadsheet is a symptom. Symptoms are worth understanding before they are suppressed, and pushback of this kind is information about capability, capacity and trust.
Nine reasons people go back to Excel
In ERP programmes, spreadsheet reversion almost always traces back to one of nine causes. They are ordered roughly by how deep the fix has to go — the first few are design problems, the last few are habit and reinforcement problems.
For each one: what it looks like, the question that confirms it, and what actually fixes it.
1. Process misfit
Looks like: the spreadsheet handles a case the system has no clean path for — a split delivery, a consignment return, a customer who is also a supplier, a project billed across two entities.
Confirm it by asking: “Walk me through a normal case, end to end, in the system.” If they cannot complete one without leaving the ERP, this is misfit, not user error.
Fix: configuration or process redesign, not communication. This is the most expensive cause on the list, which is precisely why programmes are tempted to diagnose something else. Capture the affected roles and the severity in a change impact and mitigation register so the misfit has an owner and a date rather than a rumour.
2. Capability gap
Looks like: the person can do it in the ERP, but it takes four times longer, so under deadline they revert to what is fast.
Confirm it by asking: nothing. Watch instead. Sit with them and time the same task in both tools. Self-reported confidence is unreliable here; observed speed is not.
Fix: targeted practice on their real transactions, not a repeat of the original course. This is the distinction between exposure and proficiency — and training completion is not adoption. Prosci’s framing is useful for the business case: ROI depends on speed of adoption, ultimate utilization and proficiency, and a capability gap suppresses all three at once.
3. Data distrust
Looks like: the spreadsheet exists to check the system, not to replace it. Often it holds a parallel calculation used to validate the ERP number before anyone will act on it.
Confirm it by asking: “If the system report and your spreadsheet disagree, which one do you believe — and why?” The why is the diagnosis. Usually it names a specific field, feed or migration batch.
Fix: find the actual defect rather than campaigning for confidence. A 5 Why root cause analysis is well suited here, because distrust almost always traces back through two or three steps to an upstream process that nobody flagged as in scope. Then publish the reconciliation. Trust returns when people watch a discrepancy get explained, not when they are told the data is fine.
4. Missing functionality
Looks like: something was descoped late, deferred to “phase two,” or never built — and the spreadsheet is the only thing covering it.
Confirm it by asking: “Is there a documented gap for this?” If a decision record exists, this is a known trade-off. If nobody can find one, the scope decision was made informally and its consequence is now sitting in someone’s spreadsheet.
Fix: legitimise it. Put the gap in a transformation RAID log as a named issue with an owner and a review date. A spreadsheet covering a known, tracked gap is a controlled interim measure. The same spreadsheet covering an untracked gap is how a temporary fix becomes permanent infrastructure.
5. Approval friction
Looks like: the system route is technically fine but takes three days because of a workflow queue, so urgent cases go round it and get reconciled later.
Confirm it by asking: measure elapsed time, not clicks. Compare the sanctioned path and the workaround path end to end, including waiting.
Fix: redesign the decision rights, not the software. Approval friction is nearly always a governance choice that made sense in a design workshop and does not survive real volume. Watch for the tell: when leaders themselves bypass the workflow for urgent cases, and then every case becomes urgent.
6. Unclear ownership
Looks like: a field or master record that everyone consumes and nobody maintains, so each team keeps its own trusted copy.
Confirm it by asking: “Who owns this field?” If it takes more than about ten seconds to answer, or you get two different names from two teams, you have found it.
Fix: name owners for the contested data objects, and make sure the people who maintain the data are engaged, not just the people who consume it. This is where stakeholder analysis pays off after go-live rather than before it: upstream data providers are routinely left out of impact assessments because they are not thought of as system users.
7. Manager tolerance
Looks like: the team would use the system, but their manager still asks for the old spreadsheet format in the weekly meeting.
Confirm it by asking: “What does your manager look at in their own review?” If the answer is a spreadsheet, the team is being rational.
Fix: change the manager’s routine, not the team’s instructions. As long as the old artefact is what gets asked for, the old artefact will get produced — which is why middle management makes or breaks go-live. This one is cheap to fix and routinely ignored.
8. Inadequate reporting
Looks like: the standard reports are accurate but answer a different question from the one the person is actually asked in their job.
Confirm it by asking: “What question are you answering with this spreadsheet?” This is the single highest-yield question on the list. The answer is usually a specific, legitimate management question that nobody wrote a report for.
Fix: build that report, and retire the spreadsheet deliberately once it exists. Reporting gaps are common because report design tends to be scoped from the data model outwards rather than from the decision backwards.
9. Insufficient practice
Looks like: people were competent in training and reverted under the first real month-end.
Confirm it by asking: “When did you last do this in the system without help?” Skills learned in a clean sandbox with tidy data decay fast and collapse under time pressure.
Fix: rehearsal under realistic conditions — real data, real volume, real deadline, with support standing by. If this cause is widespread, it usually means the change was harder than the plan assumed; a change complexity assessment would likely have predicted it before go-live.
The quick diagnostic
Most of the diagnosis can be done in a single conversation with the person who built the spreadsheet, provided you go in curious rather than corrective.
| What you observe | Most likely cause | First move |
|---|---|---|
| Cannot complete a normal case in the system | Process misfit | Log the impact; treat as design work |
| Can do it, but far too slowly | Capability gap | Observed practice on real transactions |
| Spreadsheet is used to check the system | Data distrust | Root-cause the discrepancy, publish the reconciliation |
| Nothing in the ERP does this at all | Missing functionality | Raise as a tracked issue with an owner |
| System path works but takes days | Approval friction | Redesign decision rights |
| Every team keeps its own copy of the data | Unclear ownership | Name data owners, engage upstream providers |
| Manager still asks for the old format | Manager tolerance | Change the management routine |
| Reports are right but not useful | Inadequate reporting | Build the report the decision needs |
| Fine in training, reverted at month-end | Insufficient practice | Rehearse under realistic load |
One caution. These causes rarely arrive alone. A single spreadsheet often carries a reporting gap, a data-trust problem and a tolerant manager at the same time, and arguing about which one is the cause wastes the meeting. When several plausible causes are in play, map them before choosing actions — a fishbone analysis across people, process, data, technology and reinforcement is a faster route to agreement than debate.
Turning it into a repeatable routine
Ad hoc curiosity does not scale past the first few spreadsheets. Four steps make it systematic.
- Inventory, without blame. Ask teams to list the spreadsheets they rely on. Say plainly that nothing will be removed as a result of declaring it — and mean it, because you only get one chance at that promise.
- Classify each one against the nine causes, plus a tenth category: legitimately better in a spreadsheet.
- Root-cause the top three by volume or risk. Do not attempt all of them.
- Decide keep, fix or close for each, with a named owner and a date. Then track the closure rate as a metric in its own right.
That last measure is worth more than most adoption dashboards. Workaround closure rate tells you whether the organisation is genuinely converging on the new way of working or simply running two operating models in parallel and paying for both. Login counts will not tell you that. This is the same distinction that separates real adoption evidence from milestone measures that give false assurance.
When the spreadsheet is the right answer
Not every spreadsheet is a defect, and a programme that treats every one as a failure will burn credibility fast.
Modelling, scenario work, one-off analysis, genuinely exploratory questions, and low-volume edge cases that would cost more to configure than they will ever save — these are reasonable places for a spreadsheet to live, permanently. The test is not whether Excel is involved. The test is whether the spreadsheet has become an undeclared part of a core process: something a controlled transaction depends on, maintained by one person, with no owner, no version control and no audit trail.
That is the line worth policing. A spreadsheet used for thinking is fine. A spreadsheet that has quietly become a system of record is a risk that should be named, owned and scheduled — and it is a business-continuity exposure, not just an adoption issue, because it usually lives on one laptop.
What it tells you about adoption
Step back from the individual spreadsheet and the pattern across them is a fairly precise readout of adoption quality.
- Where workarounds cluster tells you which roles were under-served by design and training.
- Which causes dominate tells you whether you have a design problem, a data problem or a reinforcement problem — three very different remediation budgets.
- Whether they are declining tells you if adoption is still moving or has settled into a stable compromise.
- How safely people talk about them tells you whether your feedback channels are working at all.
That last one is worth dwelling on. A programme where nobody admits to using spreadsheets is not a programme without spreadsheets. It is a programme that has lost visibility of its own adoption, which is a considerably worse position to be in — and a much harder one to detect.
So when the planner exports to Excel six weeks after go-live, the useful response is not a reminder about the single source of truth.
It is a question: what does the spreadsheet do that the system does not?
She almost certainly knows the answer. Whether anyone asks her is the actual adoption problem.
The nine causes above sit across design, data, capability and reinforcement, which is why single-tool answers rarely resolve them. The AI-assisted diagnostic toolkit covers complexity, impact, stakeholders, RAID, 5 Why and fishbone analysis in one place, and the ERP readiness resources set out how these signals connect to readiness evidence before and after go-live.