Skip to main content
GullySystem

Why Employees Continue Using Excel After ERP Implementation

By Ganesh HS, Strategy and Technology, GullySystem

Employees keep using Excel after an ERP rollout because the spreadsheet still does something the new system doesn't — a missing report, an awkward workflow, a permission they don't have, or simply more trust in numbers they control themselves. The fix usually isn't banning the sheet; it's finding out exactly which of those reasons applies.

Find Out What the Side Spreadsheet Is Actually Doing

Before deciding a spreadsheet is a problem, find out precisely what it's for. Pull a copy and walk through it with the person who maintains it: which numbers come from the ERP, which are entered by hand, and why. Most shadow spreadsheets aren't duplicating the whole system — they're solving one specific, narrow problem the ERP doesn't cover well.

Common purposes are surprisingly consistent across businesses: a forecast or pipeline view the ERP's reporting can't produce, a working draft before data is 'final' enough to enter formally, or a personal cross-check because a past ERP number was wrong once and nobody trusts it since.

Tell Apart a Genuinely Missing Feature From a Clunky One

Two different problems get blamed on 'the ERP doesn't do this,' and they need different fixes. Sometimes the ERP genuinely cannot produce what's needed — no report, no field, no workflow for it. Other times it can, but doing it inside the ERP takes eleven clicks across four screens, while the spreadsheet takes thirty seconds, so people default to the easier tool even though the ERP could technically do the job.

The second case is a usability problem, not a capability gap, and it usually has a cheaper fix — a saved report template, a dashboard view, a small configuration change — than replacing or heavily customising the ERP.

Investigate Permissions, Trust and Training Before Blaming the Software

Sometimes the spreadsheet exists because the ERP genuinely can do the job, but the person doing the work was never given the access, or the training, to use that part of the system. Check permission levels against what a role actually needs to do — a common cause of shadow spreadsheets is someone building their own workaround because nobody ever gave them a working login for the module they need.

Trust is the harder one to diagnose, but ask directly: has an ERP number been visibly wrong before, in front of this team, without a clear explanation afterward? One unresolved bad number can outlast the fix that corrected it, and a spreadsheet the person controls personally becomes the safety net they build instead.

Fix the Gaps That Are Actually Worth Fixing

Imagine a mid-sized furniture manufacturer that implemented an ERP two years ago, but the sales team still runs its pipeline in a personal spreadsheet, updating the ERP only at month-end for the accounts team's sake. Investigating shows the ERP has no view that shows deals by expected close date across a rolling six weeks — sales genuinely needs that and the system genuinely can't show it without a report built specifically for it.

That's a validated gap worth fixing — a small configuration or report addition, not a re-implementation. Not every spreadsheet earns that investment; if a sheet turns out to be redundant, personal preference, or genuinely covered by an existing ERP report nobody was shown, that's a training or communication fix instead, and far cheaper.

Retire the Spreadsheet Through a Controlled, Not Sudden, Transition

Once the real gap is fixed, don't switch off the spreadsheet by decree the next day. Run both in parallel for a defined period — a few weeks is usually enough — so the person who owns the spreadsheet can confirm the ERP now produces numbers they trust, on their own timeline, rather than being told to trust it.

Set a specific retirement date in advance, and check in on it rather than assuming it happened. A spreadsheet that quietly reappears six months later is almost always a sign the underlying gap wasn't actually closed, not a sign the person didn't listen.

Root-cause tree for shadow spreadsheets

A decision tree that walks from 'staff still use a spreadsheet after go-live' down through four branching checks — genuine capability gap, usability friction, permissions or training, and trust in past numbers — ending in a different recommended fix for each branch, so the same symptom doesn't get the same generic response every time.

Frequently asked questions

Should we ban spreadsheets?

No — banning the spreadsheet without fixing what it was compensating for just pushes the problem out of sight, or into a personal file nobody can see at all. Close the actual gap first; the spreadsheet usually stops being necessary on its own once there's no real reason left to keep it.

Can reporting gaps be fixed without replacing the ERP?

Often, yes. Most reporting complaints trace back to a missing view, dashboard or saved report rather than a structural limitation of the ERP itself, and those are typically a configuration or small development task — well short of a re-implementation.

Next step

Have a specific situation to work through?

This article covers the general case. Tell us what you're actually dealing with and we'll respond directly.

Discuss Your Requirement