SAP Value Realisation Starts Before Go-Live

A value-ledger workbook for turning delivered capability into accepted business results

Altivate | Published 19 July 2026 | Updated 26 July 2026

1. Give every benefit a state

Most SAP value reporting fails before measurement begins. The business case contains a total, the programme contains a scope, and the operating business contains dozens of process changes. No durable record connects the three.

Use five states:

A benefit can move backward. Adoption can fall after hypercare. A workaround can restore an old cycle time. A supplier change can invalidate the baseline. A contract thought to be retired can renew. The ledger must show current state, not the most flattering state ever reached.

The SAP Implementation Business Case creates the first version of this ledger. Value realisation begins when scope, baseline and ownership are still changeable, not when the first post-go-live report is due.

Keep two result classes separate throughout the ledger:

• realised financial value, accepted by Finance under an agreed cash-flow, budget, margin, working-capital or risk-loss rule; and
• validated nonfinancial outcome, evidenced in service, quality, resilience, control, employee or customer measures without being presented as booked return.

2. Write the value hypothesis before design

For each material benefit, complete one sentence:

If the sentence cannot be completed, the benefit is not ready for the model.

Do this before design because it changes design. A working-capital benefit may require a different exception process, data field and operating cadence from a generic inventory improvement. A decommissioning benefit requires migration, archive, access and contract-exit work. A faster close requires the new close behaviour, not merely a new finance system.

3. Establish the baseline while the old process still exists

A baseline reconstructed after go-live is vulnerable to selective memory, changed definitions and missing data.

For each measure, preserve:

• its business definition;
• source system and extraction logic;
• eligible population and exclusions;
• observation window and seasonality;
• data-quality limitations;
• owner and validation date;
• events likely to change it independently of SAP.

Use more than one measure where the behaviour can be gamed. Faster order entry is not value if corrections increase. Lower inventory is not value if service falls. Fewer manual controls are not value if exceptions move outside the control environment.

Baseline test

• ☐ Can the number be reproduced?
• ☐ Is the comparison population stable?
• ☐ Does the period include normal operational variation?
• ☐ Is there a counter-metric for quality, service, risk or workload transfer?
• ☐ Has the process owner accepted the definition?
• ☐ Has Finance accepted how any monetary effect will be recognised?

SAP Signavio Process Insights can support baselines, performance indicators, blockers and process flow analysis when the required source data and metric are available. It is a measurement aid, not a substitute for a local definition or owner.

4. Build the benefit calculation from operating mechanics

The calculation should be simple enough to challenge and detailed enough to expose double counting.

Realised benefit in a period

verified unit change x actual eligible volume x adoption x recognition factor

Eligible volume is the total pre-adoption population meeting the agreed scope criteria in the period. Adoption is the measured fraction of that population using the intended process. Separating them prevents the same adoption reduction being counted twice.

Then subtract:

disbenefits + incremental run cost + sustaining change cost

The terms answer different questions:

1. Did the unit outcome change?
2. How much real business volume was eligible?
3. How much of that volume followed the intended process?
4. What portion meets the agreed recognition rule?
5. What did the result cost to sustain?

Efficiency

eligible volume x verified effort reduction x loaded rate x adoption x recognition

Released capacity is not automatically a cash saving. State whether it was removed from budget, redeployed to named work, used to absorb growth, or remains only a capacity indicator.

Working capital

validated change in inventory, receivables or payables x approved financial treatment

Separate a balance-sheet release from recurring profit. Confirm seasonality, growth and policy effects.

Avoided run cost

retired contract + retired infrastructure + avoided support - replacement run cost

Do not recognise it while the contract, interface or retained platform is still active.

Revenue or margin

qualified incremental volume x attributable effect x contribution margin x recognition

When several initiatives contribute, agree attribution before the result appears.

Use a pre-agreed attribution method: a matched process or site where practical, phased rollout, before-and-after analysis adjusted for volume and seasonality, or an explicit contribution share approved by Finance. Record concurrent initiatives and external changes. Correlation after go-live is not enough.

No formula should contain a hidden SAP benchmark or an assumed industry improvement. Start with local blank inputs and record the source beside every number.

Worked example: faster close without double counting

Suppose close falls from eight to five working days for twelve entities, but only nine use the new reconciliation process and two simultaneously add finance staff. Report the five-day outcome for the full close population, measure adoption on the nine eligible entities, and isolate or disclose the staffing effect. Recognise financial value only for an accepted mechanism such as avoided overtime or redeployed capacity; retain the faster close itself as a validated nonfinancial outcome if no booked financial effect exists.

5. Use four views, not one dashboard total

Adoption

Is the intended population using the new process, role and decision path?

Process performance

Did cycle time, quality, service, exception rate, control effort or throughput change?

Financial recognition

Has Finance accepted a cash-flow, budget, margin, working-capital or risk-loss effect?

Sustainability

Is the result holding after stabilisation, releases, organisational change and operating cost?

A red adoption measure can explain a flat process measure. A green process measure with no financial recognition can reveal an enabled operating benefit rather than a booked return. A green financial result with a deteriorating counter-metric can reveal value transfer, not value creation.

The executive view should show the chain, the break and the owner. A single green percentage hides all three.

6. Treat vendor tools as instruments, not adjudicators

SAP Signavio value analysis can help teams identify potential value, calculate scenarios and monitor progression. SAP’s own documentation says monetary values may depend on configured cost assumptions rather than monetary values collected from a connected source. Validate those assumptions with the business and Finance.

SAP Cloud ALM adoption potential can help identify unused, outdated or high-value SAP S/4HANA capabilities. That can create a useful investigation list. It does not prove adoption, process movement or financial value.

Use platform diagnostics to ask better questions:

• Which capability is available but unused?
• Which process blocker is visible in operational data?
• Which population or region is not following the target path?
• Which expected value depends on an unvalidated cost assumption?
• Which result can be reproduced outside the presentation layer?

Programme closure does not close the ledger. Transfer each open benefit, baseline extract, recognition rule, review date and decision right to the relevant operational process owner, data owner and Finance approver. The transformation office may facilitate the cadence; operations owns the continuing result.

Download the editable SAP value-realisation ledger.

The value ledger remains the governing record because it carries local ownership, definitions, recognition and decisions.

7. Run a value cadence from design through steady state

Before design sign-off

• complete benefit hypotheses;
• lock baseline definitions and data sources;
• map benefits to process and design decisions;
• identify counter-metrics and disbenefits;
• agree Finance recognition rules.

Before each rollout wave

• confirm the eligible population;
• confirm measurement and adoption instrumentation;
• validate local process and statutory differences;
• assign first-review dates;
• refresh assumptions affected by scope or delay.

During hypercare

• protect service, quality and controls;
• distinguish stabilisation from value movement;
• log workarounds that undermine the target process;
• avoid declaring a benefit from an incomplete comparison window.

Thirty to ninety days after stabilisation

• validate adoption and process movement;
• investigate the break in each value chain;
• recognise only results meeting the agreed rule;
• reopen actions, timing or the benefit estimate.

Quarterly

• review realised, at-risk and retired benefits;
• reconcile double claims across programmes;
• update sustaining cost;
• close benefits that no longer have a credible mechanism;
• identify the next improvement cycle.

This cadence turns value management into part of the operating model, not a programme-close ceremony.

8. Put named people around the ledger

The programme manager can coordinate the ledger. The programme manager should not own every benefit. If the business owner disappears after approval, the number was sponsorship theatre.

9. Challenge the value claim

For every benefit reported as realised, ask:

• ☐ Is the baseline dated, reproducible and still comparable?
• ☐ Is the eligible volume actual rather than forecast?
• ☐ Is adoption measured at the behaviour level?
• ☐ Did the process result move, with a counter-metric?
• ☐ Is attribution separated from other initiatives?
• ☐ Are transition effects and disbenefits included?
• ☐ Is incremental run and sustaining cost deducted?
• ☐ Has Finance accepted the recognition treatment?
• ☐ Is the result durable after the last release or wave?
• ☐ Is there an owner and next decision?

If one answer is no, report the earlier state. An enabled or measured benefit is still useful. It just is not realised yet.

10. Make scope decisions with value evidence

The value ledger is not only for reporting. It should influence the backlog.

When a design choice changes, show which benefit mechanism moves. When a rollout slips, show which value and cost move with it. When adoption stalls, direct investment at the process constraint. When a benefit becomes implausible, retire it instead of lowering the evidence threshold.

This is the deeper discipline: the SAP programme is not finished when all capabilities are delivered. It is finished when the business has either realised the intended result or made a conscious decision to stop pursuing it.

Altivate provides SAP advisory and implementation services and therefore has a commercial interest in SAP transformation. Finance should own recognition, test attribution independently and retain the right to retire a benefit that the evidence no longer supports.

Build the investment case with The SAP Implementation Business Case, or return to White Papers.

Sources and verification status

Checked 26 July 2026. SAP sources are vendor documentation. No SAP benchmark, suggested improvement or Altivate client result is treated as a guaranteed outcome.

• SAP Help Portal, Getting Started with Value Analysis – current vendor guidance on identifying potential value and monitoring progression.
• SAP Help Portal, Calculation Formulas for Value Analysis – current vendor documentation for value-analysis calculations and cost assumptions.
• SAP Help Portal, Process Flow Visualization – current vendor documentation for process-flow and performance investigation.
• SAP Help Portal, Adoption Potential – current vendor documentation for diagnosing SAP S/4HANA capability adoption potential.
• SAP, Business Transformation Management – current vendor overview of process, enterprise architecture and transformation capabilities.