Digital transformation
The system went live.Did the work change?
Programmes are measured in milestones, migrations and adoption dashboards. None of those confirm that the work itself moved — that the new path is the one being used, and that the old one has stopped.
What the programme reports
- Milestones delivered, scope closed
- Licences issued and users logged in
- Benefits modelled in the business case
What execution shows
- Which path the work is actually taking
- The workaround still running beside the new system
- Cycle time, rework and effort — before and after
A benefit case is a forecast. It stays a forecast until execution confirms it.
The realisation gap
Programmes can prove delivery.Few of them can prove change.
The business case was built on a baseline nobody measured directly — an estimate assembled from interviews, sampled timings and a reasonable assumption or two. When the programme closes, that same estimate is used to declare the benefit. Nothing dishonest happens; there was simply never a measured before to compare a measured after against. Execution data can supply both ends of that comparison, from records the enterprise was already writing on both sides of go-live.
What the evidence looks like
The same process, measured the same way, twice
Order to cash before and after a platform migration. Cycle time fell — but a share of the volume never moved off the path the programme was meant to retire.
Active workWaitingReworkStill on the legacy path
Both halves of this picture are useful. The programme did move the process, and the improvement is real and measurable. It is also two fifths short of its case, and the reason is visible rather than theoretical.
Before, during and after the change
Baseline, adoption, benefit
Three measurements of one process, taken at three points in a programme. The value comes from them being the same measurement — not three different methods producing three numbers that cannot be compared.
Baseline what runs today
What are we actually changing?Measure the current process from data already recorded, before the programme starts. No workshops, no estimates, and no need to wait for the new system to exist.
Watch adoption as it lands
Is the work moving?See which teams, sites and case types moved to the new path and which did not — while there is still budget and attention available to do something about it.
Report what actually changed
Did the benefit arrive?Re-run the baseline measurement on the same process and the same population. Report the delta, including the part of the case that did not land.
What transformation hides
Four things that survive a successful go-live
These are not implementation defects. They are ordinary consequences of changing a system underneath work that has to keep running, and they persist quietly because nothing is set up to look for them.
The old route still carries volume
A share of cases continues down the legacy path months after cutover, usually the harder cases the new configuration does not handle cleanly.
The spreadsheet between two systems
Manual bridges that appear where integration stopped short. They keep the process moving, which is exactly why nobody reports them.
Loops that survived the move
A correction loop that existed in the old platform, faithfully rebuilt in the new one because it was never visible as a loop in the first place.
The gap between modelled and executed
The distance between the saving in the case and the saving in the data — knowable during the programme, awkward to discover after it closes.
How RE-ViVE helps
Start with the execution evidence you already have
RE-ViVE measures the process on both sides of a change, using operational data the enterprise already produces — including the historical data that makes a real baseline possible.
A baseline from history, not from memory
Because the measurement comes from records already written, the before can be produced after the programme has started.
Works across old and new systems
Execution is reconstructed across whatever handled the case — legacy platform, target platform, or both at once during cutover.
Adoption you can see by segment
Break the move down by site, team, product or case type, so the teams that did not move are identifiable rather than averaged away.
Benefit evidence that traces back
Every figure in the realisation report opens to the individual cases behind it, which is what makes it defensible after the fact.
Where it applies
Programmes that change how work runs, not just where it runs
The harder the cutover, the more useful a measured baseline becomes — and the more likely it is that some of the old process is still quietly in service.
Platform migration
S/4HANA and equivalent moves, where the process is redesigned and re-platformed at once and the two effects are hard to separate afterwards.
Shared services and GBS
Work moving between sites, entities or providers, where the question is whether the transition changed the process or only its address.
RPA and workflow programmes
Understand the variants and exceptions before automating the next step, then confirm what the automation actually removed.
Post-merger integration
Two organisations running the same process differently. Execution data shows how differently, and which version is worth standardising on.
Next steps
Transformation is judged on outcomes.Execution is where outcomes are made.
If a programme is in flight, the baseline can still be recovered from historical data. Choose the process it touches most and we will measure it as it runs today.