Business Process Transformation
Definition
Business Process Transformation
Business process transformation is the coordinated redesign of many processes at once, usually alongside changes to the systems, roles and working locations. Scale is what distinguishes it — one redesigned process is reengineering, and a portfolio of them is this.
Doing several at once is not a matter of running redesigns in parallel. Processes share systems, data and people, so the sequence in which they change determines whether the later ones are cheap or impossible.
Most of the difficulty is therefore in ordering, not in design. Teams that start with the most visible process usually find it depends on three others that nobody had scheduled.
The word attracts inflation, and buyers should be wary of it. A programme that replaces one system and renames some roles is a technology project wearing a larger label.
Governance is heavier than on a single redesign. A programme board able to stop a wave, and willing to do it, is the only control that reliably prevents a transformation outrunning its business case.
Key takeaways
- Many processes change together, with shared systems and data as the binding constraint.
- Sequencing decides cost; design quality decides benefit.
- Technology replacement alone is not transformation, whatever the programme is called.
- Benefits arrive in waves, not at a single go-live date.
How it works
The programme starts by grouping processes into waves that share a system or a data set. Each wave gets its own design, build and adoption cycle, and later waves are deliberately left unspecified until earlier ones have run.
Dependency mapping comes before scheduling. A process that reads a data set another process owns cannot change first, and discovering that during build is the most expensive way to learn it.
Adoption is budgeted separately from build. Training, support and the temporary drop in productivity after every go-live are real costs — and programmes that omit them report benefits that never appear.
Standards reduce the coordination load. The UK government’s Technology Code of Practice is “a cross-government agreed standard used for the Cabinet Office spend control process”, covering user needs, open standards and cloud.
| Wave element | What it fixes | Why it comes in that order |
|---|---|---|
| Shared data | The records every process reads | Everything downstream depends on it |
| Core transaction | The process carrying most volume | Proves the design at scale |
| Adjacent processes | Work that feeds or consumes the core | Cheap once the core is stable |
| Reporting | Measures across the new design | Meaningless until the data settles |
Product thinking is now the standard framing for this work. The US federal digital community publishes guidance on product management for teams running services continuously rather than as one-off deliveries.
Examples
The programmes worth studying are the ones where sequencing was the visible decision rather than an afterthought. The three cases below show the same pattern at very different scales of ambition.
A bank moves customer data first, then lending, then collections. Each wave is a digital transformation in miniature, and the third costs a fraction of the first.
A manufacturer pairs process change with a provider move. Its transformational outsourcing contract ties provider payment to the redesigned measures rather than to headcount.
A retailer runs the whole programme on quarterly increments. That agile transformation approach trades a firm end date for the ability to stop when returns fall.
Benefits are claimed differently in each case. A wave that misses its numbers should be visible on its own, not absorbed into a programme total nobody can take apart afterwards.
Related terms
Transformation overlaps with sourcing, technology change and the commercial terms that fund it. The entries below cover the adjacent decisions a programme has to make.
- IT transformation outsourcing: the technology half, contracted to a provider.
- Digital transformation outsourcing: the same scope framed around digital channels.
- Change management fees: what providers charge when scope moves mid-programme.
- Knowledge transfer outsourcing: moving the operating knowledge the new design depends on.
FAQ
How is this different from reengineering?
Reengineering redesigns one process. This changes a portfolio of them together, which adds sequencing, shared data and programme governance to the problem.
How long does a programme run?
Two to four years for a substantial one. Anything shorter is usually a single wave that has been given a programme name.
What decides the sequence?
Data ownership. The process that owns a shared record moves first — because everything reading that record inherits whatever shape it is left in.
How are benefits tracked?
Per wave, against measures baselined before that wave started. Programme-level benefit claims made at the end are almost impossible to attribute.
When should a programme be stopped?
When a wave delivers materially less than its business case and the next wave depends on the same assumption. Sunk cost is the usual reason that does not happen.
Does it require new technology?
Often, but not always. Removing handovers, merging roles and consolidating data can deliver a great deal before any system is replaced.
Compare transformation partners in the Outsource Accelerator directory.
Independent
