Lesson 5 of 5
Readiness reporting
9 min
Listen to this lesson
At the go/no-go meeting, "SIT is 94% passed" tells Grace and the process owners almost nothing. Which interfaces are in the 6%? Are they critical? Has any interface skipped a level? Readiness reporting answers those questions per interface, against exit criteria agreed in advance, so the decision is about known risks, not about a percentage.
Report per interface, by level
| Interface | Mapping and contract | Connected SIT | End-to-end | Error, volume, recovery | Operational | Open defects | Status |
|---|---|---|---|---|---|---|---|
| Supplier orders to Lakeside | Passed | Passed | Passed | Passed | Passed | None | Ready |
| Customer orders from Great Lakes Fleet Services | Passed | Passed | Passed | Volume passed; recovery retest due | Passed | 1 medium | Ready with condition |
| Bank payments | Passed | Passed with bank | Passed with Dan | Passed | Reconciliation not yet proven | None | Not ready |
| Product texts to web shop | Passed | One run passed | Not in scope | Not in scope | Monitoring proven | 2 low | Ready (light depth) |
Each cell links to evidence: test runs, message identifiers, defect records. The "not in scope" cells are as important as the passed ones; they show that reduced depth was a decision from the risk classification, not a gap. SAP Cloud ALM's test management can hold test plans and test cases by interface and process, which makes this view a report rather than a spreadsheet assembled the night before.
Exit criteria agreed up front
- Every interface has passed every level required by its risk class, with evidence linked.
- No open critical or high defects on critical interfaces; medium defects have an agreed workaround and fix date.
- Every critical interface has passed at least one connected test with the real partner in the final cycle.
- Monitoring, alerting, reprocessing and reconciliation proven for every critical interface.
- Partner confirmation of readiness recorded for each external interface.
- Cutover steps for interfaces rehearsed in the dress rehearsal within the planned times.
- Has the interface passed every level its risk class requires?Yes → next question · No → not ready; name the missing level and the date it will be run
- Are there open critical or high defects?Yes → not ready unless the process owner accepts a tested workaround in writing · No → next question
- Is it operationally proven: alerts, reprocessing, reconciliation?Yes → next question · No → ready with condition only if hypercare cover is named
- Has the partner confirmed readiness?Yes → ready · No → not ready for external go-live
Telling the story
Lead with risk, not volume. The go/no-go summary for interfaces should fit on one page: how many interfaces are ready, ready with conditions, and not ready; for each one not fully ready, the business impact, the workaround, the owner and the date. Process owners sign for their processes: Dan for finance interfaces such as bank payments, Maria for order-to-cash interfaces. Their sign-off accepts any stated residual risk; it is not a formality.
What would you do?
At the go/no-go, the bank payment interface has passed every level except proof that the daily payment reconciliation works; it is scheduled for Tuesday after go-live. The first payment run is Thursday. Dan asks how to sign. What should Priya recommend?
- Report readiness per interface and per level, not as one pass percentage.
- Agree exit criteria up front, including partner confirmation and operational proof.
- Show reduced depth as a decision from the risk classification.
- Process owners sign for residual risk; use conditional sign-off with named conditions when needed.
Check your understanding · not graded
Lesson check
1. Why is a single SIT pass percentage weak evidence for go-live?
2. What does a 'not in scope' cell in the readiness view represent?
3. Which is a reasonable exit criterion for critical interfaces?
4. When is a conditional sign-off appropriate?