Five things to assess before starting an ERP transformation

In almost every ERP transformation programme I've seen, the biggest problems don't emerge during delivery. They're already there on day one — baked into the programme before a single line of configuration is written. They're just not visible yet.

On paper, everything looks ready. There's a business case. A roadmap. A system has been selected. A delivery partner is engaged. The programme launches with confidence, a clear timeline, and a steering committee full of supportive senior stakeholders.

And then, slowly, things start to drift. Decisions take longer than expected. Process design becomes negotiation. Data doesn't behave the way the new system expects. Testing exposes gaps nobody anticipated. By the time the programme team realises what's happening, they're no longer implementing a transformation — they're managing a recovery.

The five areas I describe in this article are the ones I've seen determine the outcome of ERP programmes more reliably than any other factor — not because they're unknown, but because they're almost always underestimated.

The readiness illusion

Most organisations believe they are broadly ready for ERP. And if you assess capability across governance, data, process, technology, and change, the picture usually supports that belief. Some areas are strong. Some are average. A few are weaker. Taken together, it feels manageable.

But ERP programmes don't succeed or fail based on the average. They fail at the weakest point. This is what I call the readiness constraint. An organisation that scores well across four out of five dimensions but has a serious weakness in the fifth isn't a "four out of five" organisation. It's an organisation with a constraint that will define the trajectory of the entire programme.

I've seen programmes with excellent technology platforms, strong project management, and engaged sponsors fail because their data was in worse shape than anyone was willing to admit. I've seen programmes with clean data and well-designed processes stall because governance couldn't make decisions at the speed the programme required. The readiness illusion is the belief that overall adequacy is enough. It isn't. ERP programmes break at their weakest point, and they break harder and more expensively the later that weakness is discovered.

1. Value without ownership

Every ERP programme starts with a business case. The strategic rationale is articulated, the benefits are quantified, and the investment is approved. But ask a simpler question — who is personally accountable for delivering each element of that value? — and things fall apart quickly.

In most programmes, the business case is developed collectively. A cross-functional team identifies the benefits. Finance validates the numbers. The steering committee signs off the investment. But collective development creates collective ownership, and collective ownership is no ownership at all. When value is agreed by a group but not assigned to individuals, there's no one whose reputation, performance objectives, or career progression depends on whether those benefits actually materialise.

This matters because ERP programmes are a continuous series of trade-offs. When there's no individual owner for a specific benefit, trade-offs are resolved in favour of delivery convenience rather than outcome delivery. Scope gets protected because it's visible. Value quietly erodes because nobody is tracking it at the level of specificity required.

The organisations that avoid this trap assign named individuals as owners for each major benefit line, make those individuals accountable through the governance structure, and track benefit realisation as a first-class programme metric from day one.

2. Process alignment that only exists on slides

During mobilisation, organisations often believe their processes are broadly aligned. Senior stakeholders describe the way the business operates in terms that sound consistent. The high-level process maps look similar across business units.

That impression is almost always wrong. What actually exists beneath the high-level view is a patchwork of variations, local workarounds, embedded exceptions, and undocumented practices that have accumulated over years. Different business units handle the same process differently. Regional teams have adapted global procedures to fit local requirements.

ERP doesn't fix process inconsistency. It exposes it. Design workshops become the first time these differences are surfaced — not in a theoretical sense, but in the very specific sense of "this business unit does it this way, that business unit does it that way, and the new system requires a single approach." What should be a design exercise becomes a negotiation.

The organisations that handle this well invest in detailed process discovery during mobilisation — not high-level process maps, but ground-level documentation of how work actually gets done, where variations exist, and what the impact of standardisation would be. They engage the right people early — the finance controllers, the warehouse supervisors, the procurement coordinators — and create space for them to describe reality rather than the version that appears on slides.

3. Data that works — until it's tested

I've written at length about data migration in a separate article, so I won't repeat the full argument here. But data deserves its place in this list because it remains the single most consistent point of failure in ERP programmes.

At the start of a programme, data is assumed to be "good enough." It's in the system. People use it every day. Transactions process. Reports run. So how bad can the data really be?

The answer is: bad enough to derail your programme. Legacy data survives because legacy systems are forgiving. Over years, businesses build workarounds that compensate for data quality issues without anyone needing to confront them. A new ERP doesn't have those workarounds. It enforces the rules. And when legacy data hits a system that actually validates what it receives, the result is a wave of failures during testing.

The critical mistake is treating data as a migration task rather than a design dependency. Data quality, data structure, and data ownership need to be assessed during mobilisation — not after process design is complete, and certainly not during the final weeks before go-live.

4. Governance that exists on paper

Every ERP programme has a governance model. Steering committees. Design authorities. RACI matrices. On paper, it looks robust. In practice, the question that matters is simpler: how long does it take to make a decision that cuts across functions?

ERP programmes generate cross-functional decisions at a rate that most governance models aren't designed to handle. Should a process be standardised globally or adapted locally? Should a chart of accounts be restructured? Should a data quality issue delay testing? These decisions require input from multiple stakeholders, involve genuine trade-offs, and often touch on political sensitivities.

If the governance model can't process these decisions at the speed the programme requires, the consequences cascade. Design workshops stall. Build timelines slip. Testing is compressed. By the time the programme reaches its most critical phase, it's already carrying the accumulated weight of every slow decision that came before it.

I've covered this in more depth in my article on governance in IT transformation. The essential point: governance doesn't fail because it's missing. It fails because it doesn't operate at the speed the programme requires.

5. Change capacity that gets tested too late

Every organisation believes it is capable of change. And at the start of an ERP programme, that belief is reinforced by all the evidence available. Senior stakeholders are supportive. A communication plan is in place. Training is scheduled.

But change capacity isn't tested at the start. It's tested when the change becomes real — when abstract transformation becomes tangible disruption to how people do their jobs.

ERP doesn't just replace a system. It changes roles, responsibilities, controls, approval flows, and ways of working. A finance controller who has run month-end close the same way for a decade is now expected to do it differently. A warehouse team that managed inventory through personal knowledge is now expected to trust a system they didn't choose and don't yet understand.

These aren't technology changes. They're changes to how people work, and in many cases, changes to how people understand their own roles and value. That kind of change generates resistance — not the visible, vocal resistance that programme teams are prepared for, but the quiet, passive resistance that manifests as disengagement, workaround-building, and a gradual retreat to familiar ways of working.

The organisations that manage this well assess change capacity honestly at the start — not optimistically — and engage operational staff early and meaningfully. People who have contributed to the decisions that shape the new system are significantly more likely to adopt it than people who have the outcome imposed on them.

The constraint that gets ignored

If you assessed all five of these areas at the start of a programme, you'd rarely see failure across all of them. What you'd see is imbalance. Governance might be strong. The technology platform might be solid. But data is weak. And change capacity is weaker than anyone wants to acknowledge.

On average, the picture looks acceptable. And this is precisely the trap. ERP programmes don't fail because everything is broken. They fail because one or two critical capabilities aren't strong enough to carry the weight of the transformation. The strong areas create confidence. The weak areas create risk. And because the weak areas are often the hardest to measure, least visible, and most politically sensitive, they're the ones that get assessed optimistically and left unaddressed.

What good looks like

The bottom line

ERP transformations don't reveal whether your technology is ready. They reveal whether your organisation is.

And organisational readiness is not about how strong you are overall. It's about whether your weakest capability is strong enough to carry the transformation. If it isn't — and if nobody is willing to say so before the programme starts — then the programme is carrying a risk that no amount of good technology, strong project management, or enthusiastic sponsorship will overcome.

The organisations that succeed are the ones that assess these five areas honestly, act on what they find, and design their programmes around the constraints rather than hoping delivery will fix them. The organisations that struggle are the ones that look at the average, decide it's good enough, and launch anyway.

By the time they realise it wasn't good enough, the cost of fixing it has multiplied.