Lesson 3 of 7
Delivery measures for SAP change
9 min
Listen to this lesson
Testing sits on the critical path of every SAP change. If regression takes three weeks, no change reaches production in less than three weeks, however small. The DORA research program, now part of Google Cloud, offers a well-tested set of software delivery measures that show the combined effect of building, testing and deploying. They were designed for teams that deploy software continuously, so they need translating for SAP, where changes move through a transport landscape into production in planned windows. Translated carefully, they show the TCoE's effect on the whole delivery system, not only on testing.
The five DORA measures
| DORA measure | DORA definition (summarized) | SAP translation at Contoso |
|---|---|---|
| Change lead time | Time from a change being committed to version control until it is deployed to production | Days from transport release in CMD to import into CMP, per change (median) |
| Deployment frequency | How often deployments to production happen | Number of CMP import events per month: release windows plus emergency imports |
| Change fail rate | Share of deployments that need immediate intervention, such as a rollback or hotfix | Share of CMP import events followed by an emergency correction or manual repair within 7 days |
| Failed deployment recovery time | Time to recover from a failed deployment that needs immediate intervention | Hours from the incident caused by an import to the correcting import or workaround |
| Deployment rework rate | Share of deployments that are unplanned and result from a production incident | Emergency imports that fix production incidents ÷ all CMP import events |
DORA's software delivery measures and their SAP translation. DORA replaced mean time to restore with failed deployment recovery time in 2023 and added deployment rework rate in 2024.
DORA groups these into throughput (lead time, frequency, recovery time) and instability (change fail rate, rework rate). Its research has consistently found that the two are not a trade-off: teams that deliver faster also tend to fail less, because small, well-tested changes are easier to get right. That finding matters for an SAP TCoE, because the usual objection to faster delivery is risk. The measures let you show whether faster regression and smaller releases made production more stable or less.
Where the lead time goes
When Priya first broke down the 34-day median lead time, about 6 days were project testing in CMQ, 13 days were waiting for the next monthly window, and 15 days were the release regression in CMR. Testing and waiting together were most of it. The TCoE could not change the monthly window alone, but it could shrink regression, which is the step it owns. With regression down to 6 days (inside the 10-day year-1 service level) and Luis's agreement to close the release scope a week later, the median fell to 21 days within a year.
| Measure | First quarter after hypercare | Same quarter a year later |
|---|---|---|
| CMP import events | 12 (3 release windows, 9 emergency imports) | 6 (3 release windows, 3 emergency imports) |
| Change lead time (median) | 34 days | 21 days |
| Change fail rate | 3 of 12 (25%) | 1 of 6 (17%) |
| Deployment rework rate | 7 of 12 (58%) | 2 of 6 (33%) |
| Failed deployment recovery time (median) | 60 hours | 24 hours |
Contoso's delivery measures, one year apart. Figures are illustrative course data.
Read them with SAP sense
- Deployment frequency is not a goal in itself. Contoso's import events fell from 12 to 6 because there were fewer emergencies. Fewer, planned imports are good news here; read frequency together with the rework rate.
- SAP rarely rolls back. Transports are not usually reversed, so a "failed deployment" is one followed by an emergency correction or a manual repair. Define the window (Contoso uses seven days) and keep it fixed.
- Emergency changes are rework. Each emergency import that fixes a production incident is unplanned work caused by an escape. The rework rate is therefore a delivery-level view of the TCoE's protection goal.
- Count per change, not per transport. One change may need several transports; counting transports inflates every measure.
What would you do?
Deployment frequency at Contoso has fallen by half in a year, and a council member calls it a step backward. How should Priya explain it?
- DORA's five delivery measures show the TCoE's effect on the whole delivery system, translated to transports and import events.
- Break change lead time into stages; at Contoso regression and waiting for the window dominated it.
- Read frequency with rework rate: fewer emergency imports lower frequency and are good news.
- Delivery measures are shared outcomes; the TCoE reports its contribution, not sole ownership.
Check your understanding · not graded
Lesson check
1. How does Contoso translate DORA's change lead time to SAP?
2. Which DORA measure was added in 2024?
3. What does a high deployment rework rate tell a TCoE?
4. Why should SAP delivery measures count per change rather than per transport?