Why Users Go Back to Excel After an ERP Go-Live (and How to Stop It)

Six months after go-live, someone in finance shares a spreadsheet in a meeting. It has the real margin per customer, because “the ERP report isn’t right”. Sales has its own price list in Excel. The warehouse keeps a shadow stock count. Nobody decided to abandon the new system. It just happened, one workaround at a time.

This is one of the most common ways an ERP project disappoints without anyone calling it a failure. Gartner predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals, and links these failures to gaps between what users expected and what was delivered. [1] Spreadsheets creeping back are often the first visible sign of that gap.

Why the spreadsheets come back

The system does not answer the question people actually ask

Users rarely go back to Excel because they like it. They go back because they need an answer the system does not give them easily: a margin view, a planning overview, a list filtered the way they think. If the report they need was never built, or takes ten clicks, a spreadsheet wins.

The data is not trusted

One wrong price, one stock figure that does not match the shelf, and trust drops fast. Once users believe the data is wrong, they start keeping their own version “to be safe”. Two versions of the truth then guarantee the ERP looks wrong more often.

Training covered the screens, not the work

Most go-live training shows how to create an order or post an invoice. It rarely covers the unusual cases that make up a large part of real work: the partial delivery, the price exception, the customer with special terms. When those cases come up and nobody knows how to handle them in the system, users improvise outside it.

Key users went back to their day jobs

During the project, key users were the bridge between the business and the system. After go-live, they are often pulled back into full-time operations, and the questions have nowhere to go.

Nobody owns the processes after the project

The project team disbands. The partner moves on. Small configuration problems that would take an hour to fix stay unfixed for months, because no one is responsible for collecting and prioritising them.

Warning signs to watch

• Exports to Excel that are run every day or every week, by the same people.
• Reports presented in management meetings that do not come from the ERP.
• Users asking “where do I find...” for things that were covered in training.
• Manual corrections at month-end that repeat every month.
• Master data changes made by whoever needs them, without a clear owner.

How to win users back

1. Find out what each spreadsheet is for. Treat every shadow spreadsheet as a requirement. Ask what question it answers and whether the ERP could answer it with a report, a view or a small configuration change.
2. Fix the trust problems first. Clean the data people complain about most, and make it visible that you did. Start with prices, stock and customer data.
3. Train on scenarios, not screens. Short sessions on the real exceptions each team handles. Record them so new staff can use them later.
4. Give users a place to ask. A clear first-line support channel, with fast answers, prevents workarounds from becoming habits.
5. Name a process owner per area. Someone in finance, sales, purchasing and operations who decides how the process works in the system and approves changes.
6. Collect and fix small issues continuously. A monthly improvement list, prioritised with the business, does more for adoption than a large phase-two project a year later.
7. Retire the spreadsheets deliberately. Once the ERP answers the question, agree a date after which the spreadsheet is no longer used in meetings.

Adoption is a post-go-live job

None of these fixes are about the software. They are about the months after go-live: support, data quality, training and ownership. That is also the period most budgets and project plans cover least. If the project ended at go-live, adoption has nobody working on it.

Two things help most. A business application architect who can look at the shadow spreadsheets, see what the system should be doing, and get it fixed. And steady day-to-day support that keeps data clean and answers user questions quickly, so the system stays the easiest place to do the work.

The bottom line

Users go back to Excel when the ERP is harder to trust, harder to use or slower to answer than a spreadsheet. Fix the data, answer the real questions, support users after go-live and give each process an owner, and the spreadsheets will lose the argument on their own.

Sources

1. Gartner, “What IT Leaders Must Do to Avoid Disappointing ERP Initiatives”