The Readiness You Defer Is the Readiness You Pay For

When deciding on an ERP solution, organisations often evaluate the system exhaustively and their own readiness barely at all. The questions that are often skipped don’t disappear, they resurface later, when the clock leaves no time to answer them well.

The asymmetry nobody questions

Watch a serious organisation run an ERP selection and you’ll see real rigour. Months of it. Structured requirements, weighted scorecards, scripted demos run against carefully built scenarios, reference calls, total-cost-of-ownership models built three ways. By the time a decision lands, the system has been examined from every conceivable angle.

Now ask a simpler question: how much of that rigour was pointed at the organisation doing the buying? Usually the honest answer is almost none. We spend six months interrogating whether the software is ready for us and barely an afternoon asking whether we are ready for it. The whole process is built around evaluating the solution and almost not at all around evaluating ourselves. That asymmetry feels normal because everyone does it. It shouldn’t. The system is rarely what sinks an ERP programme. The organisation’s readiness to absorb and run it almost always is.

What does ERP transformation readiness mean?

Readiness is not a feeling, and it is not a kick-off slide saying everyone is committed. It is having answers to a set of uncomfortable, concrete questions and many organisations have answered very few of them when they sign a contract.

Do you actually have the team - not on paper, but in reality? The people who understand how the business runs are almost always the people already running it and putting them on the transformation programme means taking them off the day job. Which leads to the question almost nobody asks in time: have you recruited backfills? A programme staffed by borrowing capacity from people who can’t spare it usually proves unsustainable before its halfway through.

Then there is data. Is yours governed, or are you about to migrate a mess and call it a fresh start? Master data with no owner, three definitions of “customer,” reconciliations held together by one spreadsheet and one person’s memory - none of that improves because a new system arrives. It just becomes visible at the worst time.

And who owns the processes? Who decides how something works end to end in design workshops? Is there a name, or a silence followed by three functions each assuming it’s someone else? When two divisions genuinely disagree, who has the authority to break the tie? If you don’t know that before the programme starts, you will be inventing it under pressure.

And the quietest question of all: who owns the benefits? The business case that unlocked the funding -is it still someone’s job after go-live, or did it stop being anyone’s the moment the money was released?

Why ERP readiness always loses the argument

The reason is not that anyone thinks readiness doesn’t matter. It’s that readiness assessment feels deferrable in a way system selection does not. Selection has a deadline, a budget line and a board waiting on a recommendation. It is concrete and urgent. Readiness, by contrast, looks soft, internal and like something you can pick up later. Once the vendor is chosen. Once the System Integrator (SI) is mobilised. Once the programme is real.

So it gets pushed. Not rejected, just postponed to a moment that feels more appropriate. The trouble is that the “more appropriate moment” is precisely the one where readiness has stopped being a question you can answer calmly and becomes one you have to answer in a hurry. Deferring readiness doesn’t make it smaller. It just moves it to the point on the timeline where you have the least room to deal with it well.

The ERP transformation programme will not wait for you for free

Here is what people often misunderstand about deferred readiness. They imagine that when the gap surfaces, when the workshop asks who owns master data and the room goes quiet, the programme simply pauses while the organisation works it out, calmly and at no cost. It does not. By that point the plan is moving and the meter is running. The team is stood up, the backfills are in place, the SI is on the clock. A decision still has to be made and now it must be made against a programme that is expensive to keep waiting.

This leaves you with two bad options and deferred readiness only ever lets you choose between them. You can make the decision fast - settle how a core process works, or who has the authority to resolve a dispute between two divisions by Thursday, because design closes on Friday and build cannot slip. Or you can stop the clock and take the time the decision actually deserves, while a fully mobilised programme sits idle or spins wheels at a snail’s pace, burning through day rates and goodwill for every week you think. Rush it and you get the decision wrong; pause it and you pay handsomely for the privilege of getting it right. There is no third door where the programme quietly waits for free.

Neither option is one you would choose on purpose and that is the point. A decision about core process design or decision rights is not one you want to make in a hurry and it is not one you want to make with a meter running either. It deserves debate, evidence and the right people in the room. Deferred readiness denies you the only version of that conversation worth having: the calm one, held early, before anything is on the clock at all.

And it compounds

The cruelty of timeline pressure is not that one hurried decision is bound to fail. Plenty turn out fine. It is that each one quietly raises the risk of a compromise further down the line. For example, a decision rushed in design call for customisation. That customisation is more expensive to build. It resurfaces in testing as a design that does not quite fit the way the business actually works, at the precise point where reopening the design or the build is no longer an option. So it gets absorbed the only way left - as a workaround the organisation now operates outside of the system.

A programme makes hundreds of these calls and deferred readiness means a disproportionate share of them get made in a hurry. Stack enough rushed decisions on top of each other and the odds stop being in your favour. Trace almost any painful go-live back far enough and you find the pattern: not one catastrophic mistake, but a long series of decisions made too fast, too late, by people who never had the time those decisions deserved. Even if the go-live goes well, rushed decision making can lead a new solution that doesn’t deliver the expected benefits.

Developing Readiness is not a post-selection task

Readiness is not something you assess after choosing a system. It is something you assess in order to choose well.

Knowing you are not ready is not a failure, it is one of the most valuable findings in advance of signing a contract. It might change what you should buy. It might change how you should phase it. It might tell you to scope the first phase more tightly, to fix the data ownership problem before you migrate anything, or to delay the start by a quarter and spend that quarter getting the organisation into shape.

Every organisation that buys an ERP system eventually settles the same questions: who owns the team, the data, the processes, the decisions, the benefits. That part is not optional - the system forces the issue whether you like it or not. The only thing you actually control is when those questions get answered and therefore how well.

Answer them early and you answer them on your own clock - with time to debate, to gather evidence, to change your mind cheaply on a whiteboard. Answer them too late and you answer them on the programme’s clock, which does not care that the decision is important and will not pause while you think.

This is what a proper mobilisation is for, and why it belongs before contracting rather than after it. Not the delivery ramp-up the word usually describes, but a deliberate piece of prep work - run while the selection is still live, before the ink is dry - that answers the team, data, process, decision and benefit questions while you still have the time to answer them well. Done at that point, mobilisation is how you arrive at contract signature ready. Done later, it is just the name you give to discovering, under pressure, everything you should have settled first.

At Lumenia we guide organisations through every stage of the ERP journey – from initial strategy development, system selection and readiness through to programme delivery support and assurance. We're independent and product-agnostic which means our advice is shaped entirely by what's right for your organisation, not by any relationship with a vendor or SI. If you're at the start of that journey and working through your options we can help you make the right choice. If you're already committed and want a second opinion on your approach before the hard work begins we'd be delighted to talk.

This blog was written by Mark McKeigue, Associate Partner with Lumenia Consulting. If you're interested in exploring how Lumenia could support your ERP project, contact Mark directly.