Business Process Reengineering (BPR): Steps and Examples

Business process reengineering is what you do when tweaking a broken system just isn't enough anymore. Instead of patching problems one by one, BPR (business process reengineering) asks a harder question: if we were starting from a blank sheet today, how would we design this process?

That question sounds simple. But acting on the answer takes real courage, because the answer almost always means scrapping a lot of what already exists.

What is business process reengineering?

Business process reengineering is the fundamental, radical redesign of core business processes to achieve dramatic improvements in critical performance measures such as cost, quality, speed, and service. The definition comes from Michael Hammer and James Champy, who introduced the concept in their 1993 book Reengineering the Corporation.

Four words in that definition carry all the weight:

• Fundamental means questioning why things are done at all, not just how they're done.
• Radical means getting to the root of processes, not making surface-level tweaks.
• Dramatic means aiming for order-of-magnitude gains, not 10% improvements.
• Processes means focusing on the end-to-end flow of work, not individual tasks or departments.

BPR isn't about improving what exists. It's about replacing it.

Key Facts

• A 2019 review of BPR literature (Al-Mashari and Zairi, Business Process Management Journal) found that roughly 50 to 70 percent of large BPR initiatives fail to achieve their stated goals, most often due to poor change management and lack of executive sponsorship.
• Ford Motor Company's landmark BPR of its accounts payable function in the early 1990s cut headcount in that department by 75 percent, dropping from 500 employees to around 125, by eliminating the invoice entirely and switching to receipt-based payment.
• Hammer and Champy estimated that only 10 to 50 percent of the companies attempting BPR at the time succeeded in achieving the dramatic improvements they sought, underscoring that the redesign itself is the easy part.

BPR vs continuous improvement (kaizen) vs BPM

People often lump together three distinct approaches to changing how work gets done. They're not the same thing, and confusing them leads to choosing the wrong tool.

If your process needs major surgery, BPR is the right call. If it needs physical therapy, use kaizen. If you need a management system to govern all of it, that's business process management.

The principles of reengineering

Hammer and Champy laid out several guiding principles in Reengineering the Corporation. In plain terms, here's what each one means in practice:

Organize around outcomes, not tasks. Design the process to produce the result, not to keep individual roles busy. A single team should own the whole outcome, not hand work off across five departments.

Have those who use the output perform the process. If the procurement team needs financial data, let them access it directly rather than requesting a report from finance. Cut out the middlemen.

Treat geographically dispersed resources as centralized. Information technology lets you combine the scale benefits of central operations with the flexibility of local teams. You don't need a separate department in every office.

Link parallel activities instead of integrating their results. Rather than running two separate workstreams and reconciling their outputs at the end, coordinate them throughout. This shrinks cycle time and reduces rework.

Put the decision point where the work is performed. Give frontline workers the authority and information to make decisions on the spot. Don't route every exception up the chain.

Capture information once and at the source. If a customer fills in their details, don't ask another department to re-enter the same data. Shared databases and direct access eliminate re-entry errors.

Benefits of BPR

When BPR works, the results are hard to argue with:

Dramatic cost reduction. Eliminating redundant steps, handoffs, and rework can slash operating costs faster than any efficiency program. Ford's accounts payable redesign is the textbook case, but similar results show up in logistics, customer service, and order fulfillment.

Faster cycle times. Processes built around outcomes rather than departmental structure tend to complete far more quickly. Less waiting, fewer approvals, and fewer reconciliation steps all compound.

Better customer experience. When a single owner is responsible for an end-to-end outcome, the customer deals with one point of contact instead of being passed around. Response times drop and errors go down.

Competitive positioning. Some industries have players who've already redesigned their processes around IT. Companies that haven't are competing on an uneven field. BPR can close that gap in one move rather than through years of incremental effort.

Organizational clarity. The redesign process forces teams to confront the real logic of how work flows. Often, long-standing rules and handoffs turn out to have no rational basis at all. Getting rid of them simplifies reporting lines, reduces politics, and makes accountability clearer.

Risks and why BPR efforts fail

BPR carries a failure rate that no one should ignore. Hammer himself acknowledged it. Here's what actually drives failures:

Top management doesn't stay engaged. BPR needs executive champions who absorb political resistance from middle management, whose jobs and power bases are often threatened by redesign. When leadership delegates the project and moves on, resistance wins.

The scope creeps or shrinks. Starting too small keeps the initiative inside one department and produces marginal gains. Starting too large without enough resources or a clear pilot target produces nothing. Getting scope right is genuinely hard.

IT is treated as the goal, not the enabler. Installing new software is not BPR. Many organizations call an ERP implementation "reengineering" because it's expensive and disruptive. But if you just automate the old process, you get a faster version of the same broken system.

People are forgotten. Every process is run by people. Redesigning the flow without planning for training, role changes, and the emotional reality of job displacement creates active resistance.

No measurement before the fact. If you don't know your baseline metrics (cycle time, error rate, cost per transaction), you can't tell whether the redesign worked. Many BPR projects report "success" because nothing was measured upfront.

The pilot phase gets skipped. Deploying a redesigned process organization-wide without a controlled pilot is a recipe for cascading failure. Pilots expose assumptions that looked fine on a whiteboard.

How to reengineer a process

Step 1: Identify the process for redesign

Not every process deserves a BPR effort. Start by selecting a process that is both strategically critical and clearly broken. Good candidates have high cost, long cycle times, frequent customer complaints, or are directly tied to a competitive disadvantage. Avoid tackling too many processes at once.

Step 2: Form the reengineering team

A BPR team needs a cross-functional mix: people who actually run the process (they know where it breaks), IT representatives (they know what systems can do), and at least one senior leader with enough authority to make real decisions. This isn't a committee. It's a working group with a mandate to act.

Step 3: Map the current state

Before you can redesign anything, you need to understand the current flow in honest detail. Use business process mapping or value stream mapping to document every step, handoff, decision point, and delay. Don't skip this step because the process seems obvious. The current-state map almost always reveals surprises, including steps that exist for no current reason.

For structured documentation of the as-is versus to-be state, a current vs. future state map gives the team a shared visual anchor for the redesign conversation.

Step 4: Set a bold future-state vision

This is the blank-sheet step. Ignore current constraints and ask what the ideal outcome looks like. Define success in measurable terms: cut cycle time by 60%, reduce error rate to under 1%, reduce headcount in this function by 40%. A vague goal like "improve efficiency" won't drive the hard decisions the redesign will require.

Swimlane diagrams (see swimlane diagram) are useful here for mapping responsibilities across the redesigned roles before anything is built.

Step 5: Redesign and pilot

Build the new process design and test it in a controlled environment before full rollout. The pilot scope should be real enough to surface genuine issues, but contained enough that failures can be corrected quickly. Document what breaks and adjust the design.

Process standardization work happens here too: the redesigned process needs to be documented in standard operating procedures so it can be trained and enforced.

Step 6: Implement and measure

Roll out the redesigned process in phases if the scope is large. Measure against your Step 4 targets from day one. Report results transparently. Assign clear ownership for ongoing performance. And plan for the human side: communicate early with affected teams, provide real training, and have a plan for role changes before the go-live date, not after.

Business process reengineering examples

All three examples share the same pattern: the redesign wasn't about working harder or adding staff. It was about reconceiving who does what, in what order, and what information they need to do it.

Best practices

Do:

• Secure an executive sponsor before starting, not after you've run into resistance.
• Measure the baseline process rigorously before touching anything.
• Use a pilot to validate assumptions before full deployment.
• Design the new process around the customer outcome, not internal org chart logic.
• Plan the people transition (roles, training, communication) as carefully as the process design.
• Combine BPR with robotic process automation or workflow automation to lock in gains and reduce manual re-entry.

Don't:

• Call an ERP implementation "BPR." Installing software on top of a broken process gives you an expensive broken process.
• Let scope expand without a corresponding increase in resources and authority.
• Skip the current-state mapping because "everyone knows how this works." They don't. Not fully.
• Try to reengineer everything at once. Pick one critical process and prove the model.
• Treat BPR as a one-time project. The redesigned process still needs ongoing governance to stay healthy over time.

Frequently asked questions

What is business process reengineering in simple terms? BPR is starting from scratch to redesign how a core business process works. Instead of fixing problems in the current process, you ask how the process would look if you built it today with no legacy constraints. The goal is dramatic improvement, not incremental gains.

How is BPR different from process improvement? Process improvement (including kaizen and lean methods) works within the existing process structure and makes it better step by step. BPR throws out the existing structure and builds a new one. The scope and risk are fundamentally different. BPR is appropriate when the current process is structurally broken; improvement methods are appropriate when it's basically sound.

Who introduced BPR? Michael Hammer and James Champy popularized the concept in their 1993 book Reengineering the Corporation. Hammer had previously published the foundational article "Reengineering Work: Don't Automate, Obliterate" in the Harvard Business Review in 1990.

Why do so many BPR projects fail? Most failures trace back to one of three causes: leadership that loses interest or political will halfway through, underestimating the human change management required, or treating IT implementation as a substitute for genuine process redesign.

When should a company use BPR vs. a kaizen event? Use BPR when a process is fundamentally broken, delivers results far below industry benchmarks, or blocks a strategic objective that incremental improvement can't fix in a reasonable timeframe. Use a kaizen event when you need focused, fast improvement on a specific problem in a process that's structurally sound.

---

BPR isn't for every situation. But when a process is fundamentally broken and the competitive stakes are high, incremental improvement is just slow failure. The companies that redesigned their processes around outcomes rather than org charts in the 1990s built advantages that took competitors a decade to close. The same logic applies today, particularly as AI and automation raise the ceiling on what a redesigned process can achieve.

For teams looking to lay the groundwork, start with honest process documentation and a clear mapping of where the current flow breaks down. That's the foundation every successful BPR effort is built on.