Business Process Re-engineering
When incremental improvement won't close the gap — re-engineer "the dream" 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.
Map The Redesign
Use the four systems maps as one evidence chain. They support the redesign; they do not own the business process.
- Outcome Map — declare the result and measurable setpoint before studying the existing process.
- Value Stream Map — observe where value moves, waits, changes hands, or disappears today.
- Dependency Map — separate real constraints from inherited sequence and policy.
- Capability Map — test whether the people, agents, instruments, and controls needed by the future state actually exist.
The outcome map supplies the destination. The other maps explain whether the proposed redesign can reach it without carrying the old process forward under a new name.
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
- Systems Diagram Templates — The four-map evidence chain for outcome, flow, dependencies, and capability
- 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?