Go-Live Readiness Check

Could you show the evidence
behind a go-live decision?

Fifteen questions across the five things that decide whether an SAP go-live is defensible. You get a score and a position on each of the five straight away — no sign-up, nothing to install, and nothing sent to us unless you ask for the written report at the end.

15 questionsAbout 4 minutesScore shown immediatelyReport by email, only if you want it

01 · Scope and coverage How was your test scope defined?

From the business processes the organisation actually runs, checked against real usage From the requirements and design documents From the previous project’s test pack, updated We are not sure how the current scope was arrived at

02 · Scope and coverage Do you know which critical business processes have no test case against them at all?

Yes — there is a list, and each gap has an owner Roughly — we know the areas, not the specific processes No, but we assume coverage is broadly complete We do not know

03 · Scope and coverage Process variants — the same process run differently by another plant, country or customer — are they tested?

Yes, the significant variants are identified and covered Some are, mostly the ones somebody remembered We test the main flow only We do not know

04 · Test data readiness Where does your test data come from?

A refreshed, masked copy of production, plus deliberately constructed edge cases A refreshed copy of production Manually created, or a long-standing test set We do not know, or it varies by team

05 · Test data readiness Can you currently test the conditions that break things — volumes, month end, exceptions, blocked stock, returns?

Yes — they are constructed deliberately and tested Some of them No — we test clean paths We do not know

06 · Test data readiness When a test fails because of the data rather than the system, how long does it take to unblock?

Hours, with a named owner for test data A day or two Longer, or the test gets deferred We do not know — it happens often and we do not measure it

07 · Regression cycle time How many working days does one complete regression cycle take today?

We know the number, and it is under five days We know the number, and it is five to ten days More than ten days, or a full cycle has never been completed end to end We do not know

08 · Regression cycle time How many complete regression cycles will you finish before go-live?

Two or more, with time to fix between them Two, but back to back One Not decided, or we do not know

09 · Regression cycle time If a change lands late, can you re-run the affected regression scope and still hold the date?

Yes — and we have actually done it Probably, but we have not tried No — a late change means moving the date or accepting the risk We do not know

10 · Automation effectiveness What does your test automation cover today?

The regression scenarios that repeat every release, chosen deliberately A suite built during an earlier project, partly still relevant Very little, or a proof of concept We do not know what it covers

11 · Automation effectiveness When SAP changes, who maintains the automation?

A named owner, with maintenance in the plan and the budget Somebody does it alongside another job Nobody — it is repaired when it breaks We do not know

12 · Automation effectiveness On its last complete run, what proportion of your automated tests passed?

We know the number, and most of them passed We know the number, and a significant share failed or were skipped It has not been run in full recently We do not know

13 · Defects and business risk Are open defects tied to the business processes they affect?

Yes — we can say which business processes are at risk today Partly — by module, not by business process No — we have a list by severity only We do not know

14 · Defects and business risk What is happening to the age of your open defects?

We track ageing, and it is falling We track ageing, and it is flat or rising We do not track ageing We do not know

15 · Defects and business risk If you approved go-live today, could you show the evidence behind that decision?

Yes — a readiness position per business capability, with what is knowingly not ready and who accepted it Partly — test execution numbers and a defect list No — it would be a judgement call made in the room We do not know

Nothing is sent anywhere when you do this. The result is worked out in your browser.

What it measures

The five things a go/no-go decision rests on.

These are the same five we report on in a Go-Live Assurance engagement. Three questions each, and the check scores them separately — because a programme is rarely weak everywhere, and knowing which one is thin is the useful part.

01

Scope and coverage

Does the test scope reflect what the business actually runs?

Test scope is usually written from requirements and design documents, which describe what the system was asked to do rather than what the business does with it every day. The gap between the two is where go-live surprises live — a variant nobody listed, a process a single plant runs differently, a step that only matters at month end.

02

Test data readiness

Does your test data represent what production will throw at it?

A test that passes on clean data proves the code runs, not that the business will. Volumes, month-end conditions, blocked stock, partial deliveries, returns, tax and pricing exceptions — these are where SAP behaves differently, and they are the conditions test data is least likely to contain.

03

Regression cycle time

How long does one complete cycle take, and can you afford another?

Regression cycle time is the single number that decides how much room a programme has left. It governs how many full passes you can complete before the date, whether a late change can be absorbed, and whether the last cycle finishes with time to fix anything it finds.

04

Automation effectiveness

What is your automation protecting, and is anyone maintaining it?

Automation earns its place when it protects the scenarios that repeat every release and someone keeps it working as SAP changes. Unmaintained automation is worse than none: it reports green against a suite that no longer reflects the system, and the programme trusts it.

05

Defects and business risk

Can you say which business processes are at risk today?

A defect list ordered by severity tells leadership how many problems there are. It does not tell them which parts of the business will not work on Monday. The translation from defect to business consequence is the one a go/no-go decision actually needs, and it is usually made in the room, verbally, on the day.

What this is, and is not

A check, not an assessment.

This is fifteen questions and an honest arithmetic. It cannot look at your test pack, your defect data or your automation, and it does not pretend to — a real Go-Live Assurance engagement measures those directly and gives leadership a position per business capability with the evidence behind it.

What this will do is tell you which of the five you cannot currently evidence, which is usually the thing worth knowing first. Every answer stays in your browser until you ask for the report.

If you would rather just talk it through, write to us — there is no charge for a conversation, and if we are not the right fit we will tell you.