Why so many ERP implementations revert to spreadsheets

The symptom: spreadsheets quietly come back

The launch went well. The system works, accounts are set up, training has happened. Then, a few months later, the first file reappears: an export “just to double-check”, a side tracker “for now”, a dashboard rebuilt by hand because the system’s one “doesn’t show the right numbers”.

Nothing crashed. Nobody decided to abandon the ERP. But little by little, the real work moves back outside the system, and the investment stops paying off the way it was supposed to.

An ERP doesn’t fail all at once. It gets worked around, one file at a time.

Five recurring causes

1. The operating model was never designed

The project started with configuration. Nobody first defined who does what, at which step, under which approval rules. The system then reproduces the existing ambiguity, and each team fills the gaps its own way.

2. The system is configured by default, not by process

Default settings are designed for an average company that doesn’t exist. When the screens don’t match how people actually work, users go back to the tool that does.

3. Nobody trusts the migrated data

A bulk import without reconciliation checks leaves duplicates, wrong balances and inconsistent stock. A few visible errors are enough for teams to start double-checking everything… in a spreadsheet.

4. Training is generic

Demonstrating every feature to everyone prepares nobody for their own job. Each role needs to know how to do its own tasks, in its own order, with its own edge cases.

5. Nobody owns the system after launch

The project ends, the project team moves on, and small change requests pile up unanswered. Without governance, the system freezes while the business keeps changing.

Warning signs

These signs usually show up well before the return to spreadsheets becomes obvious:

• Regular exports to Excel to “rework” the data.
• Meetings where everyone brings their own numbers.
• Data entered twice, in the system and somewhere else.
• Change requests that nobody owns.
• New hires taught by colleagues how to work around the system.

How to avoid it

The answer isn’t better software. It’s the order in which things are done.

1. Design before you configure. Map the real processes, decide on roles, steps and rules, and only then configure.
2. Validate the data before launch. Trial migration, reconciliation checks and sign-off by the people who know the numbers.
3. Train by role. Training paths built around each team’s tasks, with their own examples.
4. Name an owner. One person accountable for the system, adoption metrics and a regular review of requests.
5. Measure adoption, not just go-live. Track real usage in the weeks and months that follow, and correct early.

In short

The implementations that last aren’t the ones with the most features, but the ones where the operating model came first, the data is trusted, and someone keeps looking after the system after launch. That’s the approach we follow, in three phases: diagnostic, implementation and adoption, then continuous improvement. See our Odoo implementation method.