.svg){kind=logo}
Business Process Reengineering: What It Is, How It Works, and Why Most Programs Fail
What business process reengineering is, the stages of a program, how it differs from process improvement, and why most redesigns miss what matters.
.webp)
On this page
Measure the work, not the signal.
See productive time and utilization by team, not just what looks active.
Key takeaways
- Business process reengineering redesigns a process from a blank sheet, aiming for a step change in performance over incremental gains, and it suits a minority of cases.
- It differs from process improvement, which refines an existing process in small, ongoing steps and carries far less risk as a result.
- A program runs in five stages: define the scope and outcome, establish the current state, design the replacement, pilot it, then roll out and measure against the baseline.
- Most programs rush the second stage, and redesign away from the process people describe in workshops instead of the one they run, exceptions and all.
What is business process reengineering?
Business process reengineering, often shortened to BPR, is the fundamental redesign of a business process from a blank sheet, aimed at a dramatic improvement in performance instead of an incremental one. It replaces the current process outright, building the new one around the outcome the business needs and leaving the old steps behind.
What separates it from tuning a process is the starting point. Tuning takes the process as given and improves particular steps. Reengineering sets the process aside and asks what the ideal version would look like if nothing about the current one had to survive.
The trigger is usually a gap that incremental change can’t plausibly close: a process built for a scale or market the organization has outgrown, or a result the business now needs that the current steps were never designed to produce, however much they’re refined.
Three things are often mistaken for it:
Automating a bad process, making the same bad steps run faster. Automation alone isn’t reengineering.
A system implementation that wraps new software around an unchanged process, reproducing that process in a new interface.
"Reengineering" as cost-cutting under another name, because its target is the steps, handoffs and rework that no longer serve a purpose, while the people doing the work stay part of the redesigned process.
Where the idea came from
The idea came from Michael Hammer’s 1990 Harvard Business Review article, “Reengineering Work: Don’t Automate, Obliterate.”
He argued that companies were using new technology to speed up processes that shouldn’t have existed in the first place, and that automating a bad process only makes it run faster. That became the foundation of process reengineering as a discipline.
Among the principles he set out were organizing work around outcomes instead of tasks, and capturing information once, at the point where it’s created.
Hammer and James Champy expanded the argument in their 1993 book, Reengineering the Corporation.
Their case was that some processes needed rebuilding from scratch, because tuning them one step at a time would never turn them into something they weren’t designed to be. The idea spread quickly through the decade, and so did a reputation for being used as cover for cuts, which is part of why the term still carries that association. The method itself was always about the structure of the work.
The question hasn’t aged out. It comes back every time a new technology arrives, because the choice is the same one Hammer described: automate the process you have, or redesign it first and automate what’s worth keeping. It’s the question organizations are asking about AI now, in the same form.
Reengineering vs process improvement vs optimization
Reengineering, process improvement and process optimization sit at different points on the same range, from replacing a process outright to tuning one outcome within it.
Choosing between them comes down to the size of the gap between where the process is and where it needs to be. If a series of smaller improvements could plausibly close it, reengineering is the wrong tool, because it’s expensive and disruptive next to what those improvements would achieve. It earns its cost only when the gap is too large for tuning to close.
A practical test is to write down the target, then list the improvements that could plausibly get there. If that list runs out well short of the target, the gap is structural, and a redesign is worth serious consideration.
Lean, Six Sigma and Kaizen all sit on the incremental side of that line, refining a process through small, continuous steps. Reengineering sits opposite them, on the clean-sheet side.
Business process management is a different axis again: the ongoing discipline of running and governing processes, where reengineering is a one-time redesign. Finally, optimizing an existing process is the narrowest move of all, aimed at one measure in one process.
The stages of a reengineering program
A reengineering program runs in five stages, and each one produces something the next depends on. These business process reengineering steps hold whatever the process.
- Define the scope and the outcome the redesign has to deliver
- Establish how the current process actually runs
- Design the replacement
- Pilot it on a contained slice of the work
- Roll out, then measure against the original baseline
Here are these stages unpacked:
1. Define the scope and the outcome. Before anything is redesigned, set a clear boundary on what’s in scope and a specific outcome the new process has to deliver. “Faster” or “better” won’t do, because nobody can tell later whether it was reached. A scope that’s too broad turns the redesign into an open-ended project with no finish line.
2. Establish how the current process actually runs. This is where most programs move fastest and should move slowest. It’s tempting to treat it as a formality, a round of interviews and a process map before the real design work starts. The map is a useful input, but the exceptions, workarounds and rework loops that take the time only show up when you measure how the process ran, and the baseline captured here is what every later comparison depends on.
3. Design the replacement. With a measured current state in hand, design the new process against the real gaps and failure points. The test is whether the design closes the gap defined in stage one. Looking cleaner on paper than the old process is a much weaker test, and plenty of designs pass it that fail in use.
4. Pilot it on a contained slice of the work. Run the new design on a limited scope, such as one team, region or product line, before rolling it out. Skipping the pilot is what turns a design flaw into an organization-wide one, since a problem that would have surfaced in one team instead appears in every team at once.
5. Roll out, then measure against the original baseline. Once the pilot holds up, roll the redesign out and compare it with the baseline from stage two, measured the same way over a comparable period. Without that comparison, an expensive program ends with an opinion about whether it worked, and nobody can point to a result.
What reengineering looks like in practice
These business process reengineering examples are described by function, because the shape of the problem matters more than the organization it happened in. In each case the redesign removes handoffs, waiting and rework from the process.
- Claims handling. Old shape: a case passes through intake, triage, investigation and approval, each with its own team, queue and handoff before a decision. Redesign: the process is rebuilt around the case, so it moves through fewer queues with less waiting between them. Pushing it through the same queues a little faster would have left the structure untouched.
- Customer onboarding. Old shape: identity, credit and compliance checks run in sequence, each waiting for the last, even where one doesn’t depend on another. Redesign: independent checks run in parallel, cutting the time to a decision without changing what gets checked.
- Procure to pay. Old shape: a purchase request bounces between finance and the requesting team several times before approval, and each round trip adds delay and another chance to sit unclaimed. Redesign: approval is tiered by amount and risk, which removes the back-and-forth for low-risk requests and keeps full review where it’s warranted.
- Service desk triage. Old shape: requests are routed by hand, often to the wrong team first, and bounce around before landing in the right place. Redesign: intake captures the information the routing decision needs up front, which removes the rework of requests passed between teams.
None of these redesigns works by removing people. Each removes a structural cause of delay: a sequential dependency that didn’t need to exist, an approval loop, a queue, or a routing decision made on too little information.
Each redesign changed what runs in sequence, where decisions get made or when information is captured. Just speeding up the existing steps would have left all of that in place.
Why reengineering programs fail
Reengineering programs usually fail for four specific, avoidable reasons. The best-known failure figure comes from Hammer and Champy themselves, whose 1993 book described as an unscientific estimate that as many as 50 to 70 percent of organizations attempting reengineering didn’t achieve the dramatic results they intended.
Hammer later stressed, in 1995, that this was a description of what they had seen and that reengineering has no inherent success or failure rate. The reasons behind it are more useful than the number.
1. The current state was described, not measured. Workshops and interviews produce the process people believe they run, filtered through memory and some optimism about how consistently it’s followed. The real one has grown exceptions, workarounds and rework loops nobody records, so the redesign is built against the wrong starting point, and the real cost of workflows nobody has mapped surfaces once the new process is live.
2. The exception path was designed out on paper and not in practice. Redesigns are built around the clean case, the version of the process that runs as intended. In most operations the exceptions are where the time actually goes, so a new process that never planned for them meets them on the first day with no answer.
3. There is no comparable before-measurement. Without a baseline captured the same way as the after-measurement, over the same kind of period and at the same level of detail, the result can be asserted but not demonstrated. That’s how expensive programs end without a verdict.
4. The scope was the whole organization at once. Reengineering everything simultaneously removes any way to isolate what worked, and any way to stop when something goes wrong. A program that changes one process at a time can pause, learn and carry the lesson into the next one. A single process with a clear boundary and a measurable target is slower to start and far quicker to prove.
You cannot redesign your way out of a process you never measured. The replacement will carry the same exceptions, because nobody knew they were there.
Establishing the current state you are redesigning away from
Every failure mode above traces back to the same missing piece: a current state you can defend. That needs four things.
- It covers the path work actually takes. That includes the exceptions and rework as well as the intended path. A current state showing only the clean case describes the process as it was meant to run.
- It’s captured the same way before and after. If the before comes from a workshop and the after from a system report, any difference could reflect the change in method as easily as a change in the process.
- It covers a long enough period. The window has to include normal variation, since a single unusually smooth week can make the process look better than it is.
- It’s measured, not self-reported. Self-reports tend to describe the process as intended, for reasons that have nothing to do with anyone being dishonest.
Teams usually try to get there in one of two ways, and each falls short in its own way. Workshops capture intention, meaning what people believe the process is. System logs capture only the work that happens inside systems, and miss what happens in an inbox, a spreadsheet or a phone call between two steps that never generates a record.
Reconstructing how a process actually ran means seeing both what happened inside the systems and what happened around them. Anything less leaves the redesign working from part of the picture. In practice that usually means combining sources: the system record where one exists, and a measured view of the work done around it where it doesn’t.
Where the evidence comes from
Everything above depends on a current state that’s measured, and on measuring it the same way again after the redesign.
Insightful is a work data platform. Its Workflow Optimization product maps a process end to end and shows stage-level duration, movement between steps and repeat work. That gives a redesign a current state built from how the work actually ran, and a comparable measurement afterward to show what the redesign changed.
Insightful isn’t a redesign or consulting service. It doesn’t design processes, run transformation programs or implement systems, and it takes no part in deciding what the new process should look like. It supplies the evidence of how the current process runs at the start, and the same kind of evidence afterward. It's a trustworthy control for your reengineering efforts.
Because the same measurement applies both times, over a period long enough to include normal variation, the before and after can be compared directly. The redesign itself stays with the team doing it.
That matters most at two points in the program above:
At stage two, establishing how the current process actually runs, including the exception paths and rework loops a workshop tends to leave out.
At stage five, measuring the rollout against that same baseline. The pilot benefits too, because the same measurement shows whether the pilot group behaves as the design expected before anything goes wider.
Know the process before you replace it
A redesign is only as good as the picture of the current process it was designed away from. Take that picture from a workshop and the redesign inherits every exception and workaround nobody thought to mention. Take it from a measurement and the redesign is built against what happens.
The five stages, the choice between reengineering and improvement, and the four failure modes all rest on that one dependency. The current picture is either measured or assumed, and the result of the program follows from this choice. That makes stage two the cheapest place to protect the whole effort, since time spent measuring the current process is small next to the cost of redesigning around the wrong one.
Workflow Optimization is currently in beta. Request beta access to see how your processes actually run before you redesign them.
Frequently asked questions
What is business process reengineering?
Business process reengineering is the fundamental redesign of a business process from a blank sheet, aimed at a dramatic improvement instead of an incremental one. Tuning a process improves particular steps within it. Reengineering sets the whole process aside and designs a replacement around the outcome the business needs.
What are the steps in business process reengineering?
A reengineering program runs in five stages: define the scope and the outcome the redesign has to deliver, establish how the current process actually runs, design the replacement, pilot it on a contained slice of the work, and roll out while measuring against the original baseline.
What is the difference between business process reengineering and process improvement?
Business process reengineering replaces a process with a new design built from scratch. Process improvement refines the existing process in small, ongoing steps. Use reengineering when incremental change can’t close the gap between current and needed performance, and process improvement when it can, since improvement carries far less cost and risk.
What is an example of business process reengineering?
A common example is customer onboarding, where identity, credit and compliance checks traditionally run in sequence, each waiting for the last. A reengineered version runs the independent checks in parallel, which shortens the time to a decision without changing what gets verified or removing anyone from the process.
Why do business process reengineering projects fail?
Most fail because the current state was only ever described, never measured. Workshops produce the process people believe they run, without the exceptions and rework loops that take the real time. The redesign is built against that incomplete picture, so the new process meets the same exceptions and carries them forward.
When should a company reengineer a process instead of improving it?
Reengineer when the gap between current and required performance is too large for a series of improvements to close. If smaller changes could plausibly get there, improvement is the better choice, because reengineering is slower, more expensive and higher risk. The size of the gap is the deciding factor.
.webp)
.webp)
