ERP Implementation
The Four Pillars Every Growing Business Needs to Get Right
Most ERP projects don't fail. They just disappoint.
The system goes live. The old one gets switched off. The project team moves on. And six months later the business is running on a mix of the new system and a set of spreadsheets that somebody built to fill the gaps.
Nobody calls that a failure. But nobody would call it the transformation that was promised either.
We've been involved in ERP and finance system changes at businesses ranging from £5m to several hundred million in revenue. The pattern is consistent enough to be predictable. The projects that deliver what was promised get four things right before anyone looks at software. The ones that disappoint skip at least one of them.
Here's what those four pillars are and what getting them right actually looks like.
Pillar One: Processes
This is the one that gets skipped most often. It's also the one that causes the most damage.
An ERP system doesn't impose good process on a business. It builds itself around whatever process it finds. If your purchase approval route involves three people, two email threads and one person who knows to check something manually before it goes out, the system will faithfully reproduce that. It'll just do it faster.
The businesses that get this right do something uncomfortable before they start. They map how things actually work today, not how the process document says they work. Those two things are almost never the same.
What that exercise usually surfaces:
Steps that exist because of a problem that was solved two years ago. Approvals that nobody can justify. Handoffs where information gets rekeyed from one place to another. And at least one process that only works because a specific person knows to do a specific thing at a specific time.
Every one of those is a decision you need to make before the system is configured. Fix it. Keep it deliberately. Or design around it. What you can't do is leave it undecided and expect the software to resolve it for you.
The practical test: if you can't describe a process end to end without saying "and then Sarah usually checks it", that process isn't ready to be automated.
Pillar Two: Data
Every implementation we've been part of has hit a data conversation. The only variable is whether it happens before go-live or after.
Before go-live it's a project. After go-live it's a crisis.
The issue is that data problems are invisible until you try to move the data. Duplicate customer records that nobody noticed because two teams used two different systems. Product codes that changed format in 2019 and never got backfilled. Historic transactions coded to accounts that no longer mean what they used to mean.
None of this stops the business running today. All of it stops the new system delivering what you expected.
There's a more subtle version of the problem too. Plenty of businesses have clean, complete, accurate data and still can't get useful answers out of it. The data is right but it isn't structured in a way that supports the questions the business actually asks. You can produce a perfect trial balance and still be unable to tell which customers are genuinely profitable.
Getting this pillar right means three things. Audit what you hold and fix what's broken. Decide who owns data quality going forward, by name, not by department. And check that your data structure answers the questions your leadership team actually asks, not just the ones your auditors ask.
Do that before you select a system and the implementation gets faster. Do it after and you'll be paying consultancy day rates to sort out something you could have fixed internally.
Pillar Three: Structure
A new system changes who does what. That's usually the point. But it's rarely planned for properly.
When transactional processing gets automated, the people who were doing that processing don't disappear. Their role changes. If nobody has decided what it changes into, one of two things happens. Either they carry on doing manual work the system was meant to remove. Or they end up underused while the business still can't get the analysis it needs.
The structure question is really a question about capability. At £5m a business typically needs solid bookkeeping and good external accounting support. At £15m it needs someone who can own forecasting and business partnering. At £30m it needs genuine financial leadership with the capacity to shape decisions, not just report on them.
The inflection points differ by business. What doesn't differ is that the structure has to be decided deliberately rather than arrived at by accident.
There's also an ownership question that sits inside this pillar and gets missed constantly. Who owns the ERP project? If the answer is the software vendor or the IT function or an external consultancy, the project will be shaped around their delivery model rather than your operational reality.
The business has to stay in the driving seat. Not just for sign-off decisions. For every meaningful choice about scope, timeline and data.
A reliable warning sign: look at who sets the agenda for the weekly project meeting. If it isn't someone from your business, the balance has already shifted.
Four Pillar: Growth
The final pillar is the one that determines whether the system you choose is still right in three years.
Most ERP selections are made against the business as it exists today. That's understandable and it's a mistake. Implementation takes months. Payback takes years. If the system is sized for the business you are rather than the business you're building, you'll be having this conversation again far sooner than you'd like.
The questions worth answering before selection:
Where do you expect revenue to be in three years? Does the system handle that transaction volume comfortably rather than at its limit? Are you likely to add entities, currencies or countries? Is acquisition part of the plan? If so, how easily does the system absorb another business's data? Will the reporting still work when there are twice as many cost centres?
None of these require certainty. They require a view. A system chosen against a clear three-year view will be roughly right even if the plan changes. A system chosen against today's business will be wrong the moment anything moves.
The order matters more than the list
The four pillars aren't a checklist to work through in parallel. They're a sequence.
Processes first, because they determine what the system needs to do. Data second, because process changes often change what data you need to hold. Structure third, because it depends on what the first two have automated. Growth runs across all of them as the lens you apply to every decision.
Businesses that try to shortcut this usually start at the technology end. They run a selection process, pick a vendor, then discover the process and data work during implementation, when it's most expensive and most disruptive to fix.
The businesses that do it properly spend what feels like an uncomfortably long time on preparation and then implement quickly and calmly.
That's the whole difference. It isn't about budget or software or the quality of the implementation partner. It's about how much of the thinking was done before the project started.
An ERP implementation is a business change project that happens to involve technology. The businesses that treat it that way get what they were promised.
Where to start
If you're somewhere near this conversation, the most useful thing you can do isn't to book a demo. It's to get an honest picture of where you currently sit across the four pillars.
We're publishing an eBook in September that goes through all four in detail, with the specific questions to ask at each stage and the warning signs worth watching for. It comes out alongside a recorded conversation with two specialists in finance transformation.
Be the first to get the September video and eBook by signing up to The Insightful FD newsletter. We'll be sharing more information soon.