Finance Transformation
Why Your ERP Implementation Will Fail (And How to Stop It)
1 August 2025
Most ERP implementations fail. Not catastrophically: they go live, the system works, the invoices get processed. But they fail the ambition that justified the investment in the first place. The business case promised transformation. What arrived was a more expensive version of the previous system, with better reporting nobody reads.
I have implemented ERP systems in businesses I founded and run. I have also watched implementations from the outside, as an advisor and as a finance leader inheriting the consequences. The failure modes are consistent, and almost none of them are technical.
The three reasons implementations fail
First: the process goes in unchanged.
ERP implementations are treated as IT projects when they are actually process redesign projects with a technology component. The instinct is to map the existing process and replicate it in the new system. This is understandable: it feels lower risk. It is not. It preserves every inefficiency, every workaround, every manual step that should have been eliminated. You spend six figures on a system and end up with the same process, slightly faster. This is why automation projects miss the point so often.
Before you touch a system, you need to understand what the process should be. Not what it is. What it should be. That requires someone who understands finance operations deeply enough to challenge what already exists.
Second: the people are an afterthought.
System training is not change management. Handing staff a manual and running a two-hour demo does not produce adoption. People revert to what they know under pressure, and in finance, there is always pressure. Month-end does not pause for adjustment.
Effective implementation requires the team to understand not just how the system works, but why it works that way: what problem it solves, how it makes their job easier, what happens if they work around it. Managing the people side of implementation is where most projects are won or lost. That understanding has to be built before go-live, not after.
Third: nobody owns the outcome.
ERP implementations typically have a project owner and a go-live date. What they rarely have is a named person responsible for ensuring the system delivers the business case six months after go-live. The project closes. The measurement stops. The system drifts.
What good looks like
I have run implementations where the system delivered what the business case promised. The pattern is consistent.
The process was redesigned before the system was configured, not after. This meant the implementation had clear requirements, not a replication exercise.
Staff were involved before go-live: not just trained on the system, but consulted on the design. The people who use a process every day understand its failure modes better than any consultant. That knowledge is free if you ask for it.
A mirror environment ran in parallel for long enough that issues surfaced before they affected live operations. Go-live happened when the team was confident, not when the project timeline demanded it.
And someone owned the outcome beyond go-live. Not the IT team. The finance function.
The question worth asking before you start
Before any ERP project begins, ask this: if we implemented nothing and instead redesigned every process in our current system, how much of the problem would we solve? Sometimes deciding between ERP and spreadsheets is less important than getting the process right first.
The answer is usually uncomfortable. And usually useful.
Maebh Collins is a Chartered Accountant (FCA, ICAEW) and finance transformation specialist with Big 4 training and twenty years of operational experience as a founder and senior finance leader.
Maebh Collins is a Chartered Accountant (FCA, ICAEW), Big 4 trained, with twenty years of experience building and running international businesses. She specialises in finance transformation, ecommerce operations, and digital strategy.