Business Process Re-engineering
When incremental improvement won't close the gap — start from scratch.
BPR is the radical redesign of core business processes to achieve dramatic performance improvements — not 10%, but orders of magnitude. Michael Hammer and James Champy defined it in 1993: "Don't automate. Obliterate."
BPR vs BPI
The choice between redesign and incremental improvement is a strategic decision, not a preference.
| Dimension | BPR (Redesign) | BPI (Incremental) |
|---|---|---|
| Scope | Fundamental rethink from scratch | Optimize what exists |
| Speed | Discontinuous leap | Gradual gains |
| Risk | High — 50–70% of BPR initiatives fail | Low — reversible steps |
| Trigger | Broken, obsolete, or structurally misaligned process | Functioning process with room to improve |
| Return | 10x improvement possible | 5–15% typical gains |
| Disruption | High — requires cultural change | Low — builds on existing practice |
Use BPR when the process itself is the problem. Use Checklists, Mapping, and the Improvement Loop when the execution is the problem.
The Six Steps
| Step | Action | Output |
|---|---|---|
| 1. Define goals | Senior leadership sets desired outcomes — cost, speed, quality thresholds | Success criteria that cannot be met by the current process |
| 2. Map current state | Document existing workflows, gather data, identify bottlenecks | Honest picture of what actually happens, not what should happen |
| 3. Identify gaps | Compare current performance against goals — find non-value-adding steps | Gap list: what is broken, redundant, or structurally wrong |
| 4. Design future state | Build new process from outcomes backward — ignore how it's done today | Process map that achieves goals with no legacy constraints |
| 5. Implement | Train people, deploy systems, execute the redesigned workflow | Running new process with change management embedded |
| 6. Monitor | Track KPIs against defined success criteria, refine | Closed feedback loop confirming the redesign worked |
The critical discipline: Step 4 must ignore Step 2. Designers who anchor to the current state replicate its failures at higher cost.
Hammer's Principles
Seven principles from Michael Hammer's original framework:
| # | Principle | What it means in practice |
|---|---|---|
| 1 | Organize around outcomes, not tasks | Interdisciplinary teams own an entire process end-to-end — not functional silos |
| 2 | Have output users perform the process | Empower the customer or end-user to execute steps themselves where possible |
| 3 | Have information producers process it | Those who collect data should process it — remove hand-offs that add latency and error |
| 4 | Integrate parallel activities | Coordinate concurrent work in real-time rather than reconciling at the end |
| 5 | Empower workers, embed controls | Shift decision-making to the people doing the work — controls built in, not bolted on |
| 6 | Capture information once, at source | Eliminate redundant data entry and reconciliation across systems |
| 7 | Treat distributed resources as centralized | Use technology to coordinate geographically dispersed operations as a single unit |
Real Examples
Both canonical cases share the same pattern: a process built around paper and hand-offs, redesigned around information and ownership.
| Company | Before | After | Result |
|---|---|---|---|
| Ford Motor | Accounts payable: 500 staff manually matching purchase orders, receipts, and invoices — 3-way paper process | Electronic database: goods received trigger payment automatically — no invoice required | 75% headcount reduction (500 → ~125), near-zero payment errors |
| IBM Credit | Loan approval: 5 sequential specialists over 7 days — each touching the file once | Single case manager supported by integrated information system handles the full cycle | Cycle time: 7 days → 4 hours (90% reduction), capacity increased 100× |
Both cases demonstrate Hammer's core insight: the process was not slow because people were slow. It was slow because the structure forced unnecessary waiting, hand-offs, and reconciliation.
Failure Modes
BPR has a documented failure rate of 50–70%. Most failures share common causes:
| Failure Mode | Why it happens | Prevention |
|---|---|---|
| Anchoring to current state | Designers optimize the existing process instead of replacing it | Step 4 must start from goals, not from the current map |
| Skipping change management | Redesigned process launched without preparing the people who run it | Treat cultural change as a deliverable, not a side effect |
| No executive ownership | BPR started by middle management without authority to dismantle structures | Senior leadership must sponsor and protect the redesign |
| Scope creep | Starting with one process, expanding to the entire organization mid-project | Define scope before starting; additional processes get separate initiatives |
| IT as the driver | Technology deployment treated as the goal instead of process redesign | Software implements the new process — it does not design it |
| No success criteria | Redesign launched without defined measurable outcomes | Define pass/fail thresholds before Step 1 is complete |
Context
- Improvement Method — The hub: when to use BPR vs the incremental tools
- Process Mapping — Visualize the current state before redesigning it
- First Principles — The intellectual foundation for starting from scratch
- Standards — Where the redesigned process eventually compresses into protocol
- Scoreboard — The gauge that confirms the redesign delivered
Questions
Is your process slow because your people are slow — or because the structure forces unnecessary waiting?
- Which steps in your current process exist only because they existed in the paper version?
- Where does information change hands more than once before anyone acts on it?
- What would this process look like if you built it today, for the first time, with current technology?
- Are you improving the process — or just automating the waste?