Having an ERP isn't a transformation

There was cake. After fourteen months of project work, three consultancies and two changes of implementation lead, the ERP went live on a Monday and the team celebrated in the meeting room. Six months later, bank reconciliation is still done in spreadsheets, purchases are approved over email and the monthly report is built by hand, exporting data from the new system.

The scene is a composite, but the pattern is common enough to deserve its own name. The company bought an ERP. It didn't buy a transformation, because nobody sells those.

What an ERP does very well, and what it doesn't promise

A good ERP can be a solid system of record for accounting, inventory, invoicing and purchasing. Many also include approvals, reconciliation and integrations. The actual scope depends on the product, configuration and processes implemented. Trouble starts when company-specific decisions and exceptions sit outside it and nobody designs how to connect them.

That gap, between what the ERP records and how the company really operates, fills up with the usual: spreadsheets, email and people who know “how it's really done”. It's the same phenomenon as the previous episodes, now with a six-figure system at the center.

The ERP is the foundation. The transformation is what's built on top of it and around it.

Four symptoms of an under-used ERP

• Data is exported from the ERP to be worked elsewhere and then loaded back.
• The team knows the system by its data-entry screens, not by the information it provides.
• Every small change needs an external consultant and a purchase order.
• There are critical processes the ERP never sees, because they happen before or after it.

You don't always need to change it

Faced with those symptoms, the temptation is to blame the ERP and start evaluating the next one. Often that's an expensive mistake. The way out is usually to let the ERP do what it does well, connect it to the other sources and build on top of it the processes that live outside today: reconciliation, approvals, follow-up. Each with its own rules, writing to the ERP only what it should, approved by whoever should approve it.

And when some part of the ERP creates more friction than value, you assess with data whether to replace it. What works gets connected. What gets in the way gets changed.

The scenes in these episodes are composites of common situations, not customer cases. Any figures in them are illustrative.