Go-live is treated like a finish line. Everyone gets a status email, the project team disbands, and the consultants roll off. Then, four to six weeks later, someone in ops builds a spreadsheet to track open jobs "just until the reports are fixed." A sales rep keeps a personal pipeline file because the CRM view is missing a field they need. Finance exports everything to Excel to close the month.
None of this shows up on a project dashboard. But it's the most reliable signal you have about whether your ERP actually went live — or whether you now run two systems and pay for one.
Nobody Reverts Out of Laziness
The instinct is to call this a training problem or a discipline problem. It's almost never either. People revert to spreadsheets for the same reason water runs downhill: it's the fastest path to a result they're accountable for.
A warehouse lead who needs to know what ships today doesn't care which system holds the truth. They care about getting the answer in under ten seconds. If the ERP screen takes six clicks and a page reload, and a spreadsheet takes one glance, the spreadsheet wins — every time, in every company, regardless of how good the training was.
So the useful question isn't "why won't they use the system?" It's "what is the system making harder than it used to be?"
Run a Shadow-System Inventory
Somewhere between 30 and 90 days after go-live, go find the spreadsheets. Not as an audit or a crackdown — as a discovery exercise. Sit with each role for twenty minutes and ask what they open in a normal day, in order. Then look at where files actually live: shared drives, desktops, email attachments, that one Google Sheet with a link everyone bookmarked.
For each shadow system you find, get to the specific reason it exists:
- A missing view or report. The data is in the ERP, but nobody can get it out in a usable shape.
- A speed problem. The information exists but takes too long to reach during real work.
- A field or status that wasn't configured. The process has a step the system doesn't recognize.
- A permission or approval wall. Someone can't do their job without waiting on another person.
Write down the reason, not just the file name. The reason is the fix.
Sort What You Find Into Three Buckets
Not every spreadsheet is a defect. Sort your findings before you start building.
Fix in the system. Missing reports, absent fields, clumsy screens, and over-restrictive permissions belong here. These are usually small configuration items that never surfaced during testing because testing used clean sample data and unhurried people.
Fix the process. Sometimes the spreadsheet exists because the underlying workflow was never really agreed on — two departments have different definitions of "complete," so each keeps their own tally. No amount of software solves a definitional disagreement. Get the decision made, then configure to it.
Leave it alone. Some spreadsheets are legitimate: one-off analysis, modeling, scenario work. ERPs are transaction systems, not thinking tools. Trying to absorb every analytical workbook into the platform is how you end up with an unmaintainable customization backlog. Let the analysts analyze.
Make the System the Cheaper Option
Once you know the causes, the goal is narrow: for each core daily task, make the ERP faster than the workaround. That usually means unglamorous work — default values so people aren't retyping the obvious, fewer required fields on high-volume screens, saved filters that match how a role actually thinks about their day, and the two or three reports people kept asking for during training.
This is also where integrations earn their keep. If a shadow spreadsheet exists because data lives in the website, the CRM, and the ERP with no connection between them, no amount of screen tuning fixes it. The spreadsheet is doing the integration work by hand.
Measure Adoption, Not Logins
Login counts prove nothing — people log in to look things up while doing the real work elsewhere. Better signals are specific and behavioral: what share of orders are entered directly into the system versus batched in later, how much time passes between a real-world event and its record appearing, and how often people export the same dataset every week. A recurring export is a report request in disguise.
The Window Closes Faster Than You Think
There's a period after go-live when everyone still expects change and will tell you what's broken. Miss it, and the workarounds harden into official process. New hires get trained on the spreadsheet. The next system you buy has to integrate with it. The ERP quietly becomes a place where data goes to be stored rather than the place where work happens — and the ROI case you built never arrives.
If you're a few months past go-live and suspect the spreadsheets are winning, that's a fixable situation, and usually a smaller fix than people assume. We do this work — post-go-live adoption reviews, configuration cleanup, and the integrations that remove the manual middle step. Reach out and let's look at what your team actually opens every morning.