Method · Digital transformation
Transformation sequencing: what execution data changes about prioritisation
Enterprises have moved workloads to cloud, modernised ERP, automated repetitive tasks and invested heavily in data. Whether any of it improved how the business operates is a question that only has an answer if execution is measured.
In brief
- Technology modernisation and process improvement are not the same thing. Automating a documented process without understanding its variants automates the inefficiency.
- Prioritisation is the hardest part of most programmes. Large organisations have no shortage of candidates, only no basis for ranking them.
- Four measurable properties — volume, frequency, cycle time impact and rework — convert prioritisation from a judgement call into an ordering problem.
- Simulation allows a proposed change to be tested against observed volumes before it is funded, which moves the evidence earlier in the decision rather than after it.
- Processes drift after go-live. A programme that ends at implementation has no mechanism to detect that its own result decayed.
1The measurement gap in transformation
Most large enterprises do not run on one system or one cleanly defined workflow. A single customer order may pass through CRM, ERP, finance, inventory, fulfilment and payment systems before completion. Along the way people intervene, exceptions occur, approvals take longer than expected, and work sometimes moves backward.
Consider a company automating an approval workflow. On paper: a request is submitted, reviewed, approved and completed. In practice some requests return for missing information, some require additional approval, some sit untouched for days, and staff use email or spreadsheets outside the official workflow to keep things moving.
Cloud migration, application replacement, integration and analytics can all create value. None of them guarantees a better process, because none of them requires anyone to establish how the process currently behaves.
2Observation rather than description
Process intelligence uses operational data to reconstruct and analyse real process behaviour. Rather than relying solely on interviews, workshops and static maps, teams observe where transactions slow, where work repeats, where exceptions occur, and how different paths affect outcomes.
A process map describes how a purchase order should move through the organisation. Execution data shows how thousands of purchase orders did.
For transformation leaders the difference is the starting point. One begins from a shared account of the process, which is a hypothesis. The other begins from a record of it, which is a measurement — and only the second can be wrong in a way that is detectable.
3Prioritisation as an ordering problem
Prioritisation is the hardest part of any transformation strategy. Large organisations rarely lack ideas; there may be hundreds of opportunities to automate, redesign, standardise or modernise. The difficulty is deciding which deserve attention first, and the usual tiebreakers — seniority of the sponsor, recency of the complaint — are not correlated with value.
A bottleneck affecting a small number of transactions with little financial consequence and one affecting thousands of orders monthly with direct revenue impact are both process problems. They are not equally important. Four properties make that distinction measurable.
| Property | Question it answers | Why it changes the ranking |
|---|---|---|
| Volume | How many cases pass through this step? | Determines the multiplier on any per-case saving |
| Frequency | How often is the problematic path taken? | Separates a structural issue from a memorable exception |
| Cycle time impact | How much delay does it add per case? | Makes candidates comparable in a single unit |
| Rework | How often does work have to be repeated because of it? | Captures cost that never appears as a line item |
4Automation candidacy
Automation remains central to transformation, particularly as AI-powered automation matures. One question precedes it: should this process be automated in its current form? The answer is sometimes no.
A process may contain redundant approvals, unnecessary handoffs, repeated data entry, or exceptions that should be eliminated rather than encoded. Making those patterns visible allows teams to distinguish work that should be automated from work that should first be redesigned or removed.
The same dependency applies to AI more broadly. An anomalous transaction means little in isolation: whether it was part of an exception, whether similar transactions behaved the same way, whether it increased cycle time or created downstream work are all questions about context. Process data supplies that context by connecting individual activities to the process they belong to.
5Testing decisions before committing to them
Transformation projects are expensive. Changing workflows, implementing systems, integrating applications and training staff all consume time and capital. Conventionally, organisations make the investment and then measure whether it worked — which places the evidence after the irreversible decision.
Suppose an approval stage is identified as consistently delaying order processing. Rather than removing or automating it immediately, five questions can be answered from existing data first.
- How many transactions pass through this approval?Which establishes the scale of any change.
- How much delay does it introduce?Per case and in aggregate across the period.
- Which transactions actually require it?Rather than assuming the control is necessary for all of them.
- What would happen to cycle time if it changed?Modelled against observed volumes rather than estimated in a workshop.
- Which downstream activities are affected?Because approval steps frequently serve a purpose elsewhere that nobody has documented.
What simulation can and cannot establish
Simulation projects the effect of a change against historical behaviour. It cannot anticipate how people will adapt to the change — and behavioural adaptation is frequently what determines the actual result. Treat a simulated outcome as a bounded estimate that improves a business case, not as a prediction that removes the need to measure afterwards.
6Drift after go-live
Historically many transformation programmes had a defined end: analyse, implement, go live, measure, move on. Processes do not respect that boundary. Staff adapt, customer expectations shift, volumes grow, regulations change, systems are updated, and workarounds develop.
A process performing well today may be inefficient within six months, and a programme that concluded at implementation has no mechanism for detecting that its own result decayed. Continuous observation allows teams to establish whether expected improvements were realised and where new bottlenecks are forming — which turns transformation from a sequence of discrete projects into a standing capability.
The practical consequence is a change in the opening question of a transformation conversation. Instead of asking what technology to implement next, the question becomes what the operational data indicates should be improved next — and the second question has a verifiable answer.
Related reading
RE-ViVE provides the execution data this method depends on, from read-only access to systems already in production. To test the approach on one workflow,request a walkthrough.