Business Process Reengineering
Definition
Business Process Reengineering
Business process reengineering is the radical redesign of a single process from a blank sheet, rather than the gradual improvement of the one already in place. The existing design is evidence, not a constraint — it explains today, and binds nothing.
The distinction is one of degree, and it is a large degree. Improvement work aims at ten or twenty percent; a reengineering effort that produces that much has usually failed, because the disruption was not worth the return.
Clean-sheet design starts from the outcome the process exists to produce. Every step is then justified from scratch, and steps that survive only because somebody once needed them do not survive.
Outsiders are often brought in for exactly this reason. Someone from outside can ask why an approval step exists — without the political cost that falls on whoever introduced it.
Inside a single process, the steps usually go live together. A half-implemented redesign combines the cost of the new design with the delays of the old one, which is the worst of both.
The failure rate is high and the reasons are consistent. Redesigns are approved on paper, then implemented against systems, contracts and job descriptions that nobody costed into the original case.
Key takeaways
- Redesign starts from the required outcome, not from the current sequence of steps.
- Targets are step changes rather than percentage improvements on today.
- Most failures are implementation failures, not design failures.
- Scope is one process; several at once becomes a transformation programme.
How it works
A team first agrees the outcome and the constraints that genuinely cannot move: legal obligations, safety requirements, and the customer commitment. Everything else, including the current system estate, is treated as negotiable.
The current process is documented only enough to establish its cost and its failure points. Spending months mapping something you intend to discard is the most reliable way to end up defending it.
Prototyping beats specification. Public service design uses the same logic — the UK government’s guidance on the alpha phase tells teams to “try out different solutions” and to expect to throw the code away afterwards.
That guidance is equally direct about incumbency, advising teams not to “be afraid to challenge the way things are done at the moment”. It also fixes a duration: alphas “tend to last between 6 and 8 weeks”.
| Stage | Output | Time it usually takes |
|---|---|---|
| Outcome and constraints | Agreed non-negotiables | 1 to 2 weeks |
| Clean-sheet design | Two or three candidate designs | 3 to 5 weeks |
| Prototype and test | One design with evidence behind it | 6 to 8 weeks |
| Implementation | The redesigned process in live use | 6 to 18 months |
Independent advisers often carry the method. The National Institute of Standards and Technology reports that its manufacturing partnership comprises “nearly 1,400 trusted manufacturing advisors and experts at more than 450 MEP service locations”.
Examples
Reengineering is worth the disruption only where the current design is the problem. The three cases below each replaced a sequence rather than tuning it.
A lender replaces a nine-handover mortgage approval with a single assessor and automated checks. The measure that moves is order fulfillment cycle time, from eleven days to two.
A telecoms operator rebuilds provisioning around the customer order instead of around its own departments. The exercise is not cost cutting, though cost falls once the rework disappears.
A utility hands the redesign itself to a specialist. Process reengineering outsourcing brings method and outside eyes, which is often what an internal team cannot supply.
Related terms
Reengineering sits at the radical end of a scale that runs from small corrections to portfolio-wide change. The entries below are either the tools it uses or the measures it moves.
- Intelligent document processing: a technology that often makes a redesign feasible.
- Agentic process automation: automation that decides as well as executes.
- Service improvement: incremental change within the existing design.
- Productivity index: one measure used to prove the redesign worked.
FAQ
How is this different from process improvement?
Improvement makes the current design work better. Reengineering replaces the design. The test is whether the new process would be recognisable to someone who ran the old one.
Why do so many attempts fail?
Because implementation is costed as an afterthought. Systems, contracts, job roles and training all have to change, and none of that appears in the design workshop.
How long does one take?
Design takes weeks; implementation takes months. Anything promising a redesigned process live within a quarter is describing a pilot, not a rollout.
Should the current process be mapped first?
Only briefly. Map enough to establish cost and failure points, then stop, because detailed maps of a doomed process anchor the redesign to it.
Can several processes be reengineered at once?
They can, but that becomes a transformation programme with programme governance. Treating it as several parallel redesigns is how the dependencies get missed.
Is technology required?
Usually, though not always. Some of the largest gains come from removing handovers and approvals rather than from any new system.
Find redesign partners in the Outsource Accelerator hubs.
Independent
