What does “ready” actually mean in an SAP programme?

The question

“Are we ready?” gets asked in every programme and answered badly in most, because the question has a shape that invites a single answer to something with many.

Readiness is not a property of a programme. It is a property of each business capability the programme touches, and those capabilities are in different states at any given moment.

What we see in programmes

Three answers recur, and all three are unsatisfying.

The percentage. “We are at 94%.” Of what, against what denominator, and does the remaining six per cent contain anything that stops the business? Nobody in the room can tell, and the number ends the conversation rather than starting it.

The colour. “Amber, trending green.” This compresses everything interesting into a judgement made by someone who knows they will be asked to defend a red. Trend language does more work than it should.

The assurance. “The team is confident.” Which team, confident about what specifically, and on what basis? Confidence is a reasonable input and a poor artefact.

What all three have in common is that they answer at the level of the programme, when the risk lives at the level of the business capability.

A better way to think about it

Readiness is a judgement, made by named people, about specific business capabilities, on evidence. Each part of that sentence is doing work.

A judgement, not a measurement. No tool produces readiness. Tools produce inputs — coverage, execution, defects, evidence. Somebody has to look at those and decide. Pretending the number decides is how accountability goes missing.

By named people. Readiness for order-to-cash is a view held by the person accountable for order-to-cash, informed by testing. Not a view held by the test manager on their behalf. This single change improves the quality of the conversation more than any reporting improvement.

About business capabilities. Order-to-cash. Procure-to-pay. Period-end close. Warehouse operations. Statutory reporting. These are the units the business runs in, and they can legitimately be in different states.

On evidence. The judgement should rest on something examinable: what was covered, what was executed, what failed, what remains open, what could not be tested and why.

Readiness is not the absence of risk. It is the presence of somebody who can describe the risk and has decided to accept it.

What good looks like

A readiness view is a short table. One row per critical business capability. For each: covered, tested, open items, known exposure, the person whose judgement it is, and their position.

Three properties make it work.

Positions can differ. Order-to-cash ready, statutory reporting not ready, warehouse ready with a workaround. This is a healthy output, not a failure of alignment.

The exposure column is filled in. Empty exposure columns mean the exercise has not been done. Every capability going live carries something.

Names are attached. Not roles — names. This is the difference between a document that supports a decision and a document that will be re-read uncomfortably afterwards.

Alongside it, the most useful artefact in a go-live pack is often the shortest: a list of what is knowingly not ready, what will be done about it, and who accepted it. Programmes are rarely damaged by known gaps. They are damaged by gaps that were known to somebody and not to the person deciding.

Questions leadership should ask

Which business capabilities are we going live with, and what is the readiness position of each?

Whose judgement is each of those, by name?

What is knowingly not ready, and who accepted it?

What could we not test at all, and why?

If we discovered a serious problem in week one, which capability would it most likely be in? People usually know. The answer is worth hearing before rather than after.