Business process reengineering (BPR) is the radical redesign of an end-to-end process when incremental fixes are no longer enough. It starts with the outcome the business needs, then rebuilds the work, roles, rules, and technology required to deliver it.
This guide explains what business process reengineering is, when to use it, the six-step BPR methodology, and what Google, Taco Bell, and Ford teach us about redesigning broken work. It also shows how governed documentation, workflows, and built-in AI can keep the new process from drifting after launch.
Read on to find out:
- What business process reengineering is
- Why and when you should use BPR
- How to use BPR with a practical six-step method
- How famous companies redesigned core processes
Use this Process Street workflow to structure the project:
Let’s dive in.
Business process reengineering defined
Business process reengineering means rethinking how an important result is produced and redesigning the process from the ground up. It asks a harder question than “How can we make this step faster?” The question is “If we built this process today, what work would still need to exist?”
That makes BPR different from ordinary business process improvement. Improvement is incremental. It removes waste, shortens a handoff, or clarifies an instruction inside the current model. Reengineering changes the model itself. It may collapse roles, remove whole activities, change where work happens, or replace a paper handoff with a shared system.
BPR is sometimes called process reengineering or business process redesign. Whatever term you use, the work should produce a clear current-state map, a redesigned process, accountable owners, measurable target outcomes, a controlled test, and a plan for adoption.
This article uses three famous business process reengineering examples, Google hiring, Taco Bell operations, and Ford accounts payable, because each changed the mechanism of work rather than polishing a weak step. The same principle applies to smaller organizations. The scale changes, but the decision does not.
When business process reengineering is the right move
Your company is
never too smallto consider business process reengineering. At its heart, BPR is something enterprises do. When an uptick of just 2% efficiency could mean a few million in extra profit next year, you better give that thing a title and formalize it as a field of study!
With
startups, however, it’s not so drastic. It might even be funny to call it BPR when it’s probably just a few people sitting in the same room agreeing to change the way they do things because they’re all sick of the extra work.
No matter what the company size, though, it’s never too early to start doubting the efficiency of the way you do things. Bad processes
create problemsthat wear people down, and in small businesses you don’t have employees you can afford to
beworn down , you don’t have the numbers.
The point is to question the operating model before the cost of a broken process compounds. Start while the process is still small enough to change safely.
In short, start now. Examine the way you do what you do, and start cutting out the work that doesn’t add value.
Start with a process if:
- the process is important
- the process is fundamentally broken
- the process can be feasibly changed
In fact, now is a
perfecttime to jump into exactly how to carry out a business process reengineering project.
A six-step business process reengineering method
You know why it’s important, and you know that something in your organization isn’t working. You may have tried improving your current processes but something isn’t quite right, information could be missing, shortcuts might be being taken or a tool adopted without the process being updated.
In any case, an update isn’t going to cut it. You need to start from the ground-up.
You need business process reengineering.
So, let’s dive into how to do just that. Here I’ll guide you through the stages of business process reengineering, including:
- Identify the process that needs reengineering
- Assign the task to key team members
- Read current process documents and identify KPIs
- Create a current process map
- Draft a new process map and SOP
- Test and deploy the process
Let’s get started.
Identify the process that needs reengineering
You don’t need me to tell you that it’s important to
create a process for everythingyou do more than once. Unfortunately, while vital, this can leave you with a mass of processes that are difficult to prise apart and inspect as individual items.
That’s why you first need to identify the process which you’re going to re-engineer. As mentioned above, this should ideally be one which is important, fundamentally broken, and can feasibly be changed.
This won’t always be possible. Thankfully, these aren’t rules, they’re recommendations.
One way to start analyzing your processes for candidates is to check for the areas where the most waste is being generated. This usually means employing techniques like value stream mapping or business process mapping, as they inherently display which processes (or sections of your company) are the most inefficient.
If you haven’t already analyzed for waste and inefficiency in your processes, don’t worry!
Instead, make a list of the various processes your business carries out and order them by importance, value, and the frequency with which they’re performed. Then work your way down the list until you find a process which you know to be outdated or performing badly.
Assign the task to key team members
Once you’ve selected the process to reengineer you need to assign the task of doing so to key team members. These should be people who are experienced with the process and understand the importance of it.
You don’t have to be a manager to reengineer a process, you just need to understand and be familiar with how the process is currently being carried out in its entirety.
To assist the main team member(s) you’ll also need to assign any managers who have the authority to review, approve, and/or reject any changes that are made.
Read current process documents and identify KPIs
Now we’re getting into the meat of the issue. Once the team is assigned they need to read through your process documentation and make sure they understand what it was meant to achieve, and how each step contributed to this.
The process won’t be perfect (no process truly is) but that’s what we’ll solve shortly. The most important thing for now is to make sure that you’re looking at the most recent documentation. After all, there’s no point in reengineering a process if it’s already been improved upon.
This is also the stage where you should search for records of the relevant KPIs or, if the process has not been measured before, define the metrics and benchmark the current process before creating the new one.
This is also where AI can help without taking ownership away from the team. It can summarize run evidence, group recurring exceptions, and expose repeated handoffs. Treat those outputs as leads to verify against the people and systems that perform the process.
Create a current process map
Next you need to put your resources together and create a map for the process you’re looking at. We’ve covered this in detail in our
process mappingpost but I’ll go over the basics here too.
To create a process map you need to meet with the team that regularly performs the process and get them to run through the span of the process with you. Use your existing process documents as a base and get input from the team to see where natural deviations from the process have occurred.
Once you’ve got an accurate idea of how the current process is performed, you can then map out the flow using a whiteboard, piece of paper, or a dedicated piece of process mapping software. You don’t have to use any fancy
business appsbut they will, generally, save you a lot of time here. Use symbols to denote different kinds of tasks and steps in the process.
This process map should further demonstrate which sections of the process are failing and thus need to be focused on when reengineering the process from scratch.
Draft a new process map and SOP
It’s finally time to draft the new process and
SOP template. Here’s where your creativity needs to come into play.
Start by thinking about precisely what the old process was designed to do or achieve and where it went wrong. Ask yourself questions to figure out how the new process needs to fundamentally differ in order to improve on the KPI results of the old process. Questions such as:
- Why was the old process inefficient?
- Did the team take shortcuts? If so, why?
- How can we make sure that no shortcuts are needed for the new process?
- How can we simplify the process without sacrificing results?
- How can we make sure that everyone understands why the change was important?
This last point is often the most difficult, as you can’t just tell the team who’ll be using the process that “we’re doing this now because it’s better”. They need to truly understand and appreciate why the old process wasn’t cutting it and what the changes they need to make will achieve.
Thankfully, you’ve already primed them by talking to them earlier when making your current process map. Including them there helps to give a sense of ownership over the process, and getting them to lay out their shortcuts is a great way to show how the old system was flawed at the same time.
Of course, if you’ve already got a solid
change management modelin place, you shouldn’t need to worry too much about your team adopting the process correctly.
So, once you’ve created your new process map (created from your own knowledge and their previous feedback) you should once again bring in the people who’ll be using the process and go through it with them. Give them a chance to tear it apart and give feedback.
You don’t have to do everything they suggest. The important thing here is to make sure that they know their voices are being heard and to make them comfortable with why every step in the new process is vital, thus helping to avoid shortcuts being taken in the future.
Only after all of the feedback has been considered and applied should you make a new
process documentfor your team to follow, taking care to make clear what the changes are and how to carry them out.
After all, you can’t expect someone to perform a task differently if you don’t tell them how to do it.
You could use this template below as a base from which to build your standard operating procedures:
Test and deploy the process
Now all that’s left to do is to test your new process before deploying it. While fairly self-explanatory, there are a few common trip-up points that can make all your efforts next to useless, so it truly does pay to be careful here.
The main thing to worry about is testing the process in as close to a live environment as possible. You need to be able to use the KPIs you identified towards the beginning of the business reengineering process to measure the relative success of your changes, without compromising your existing processes.
In other words, look before you leap.
Even isolating and testing single segments of your process at a time is preferable to completely overwriting your existing setup before you know for sure that the changes will lead to a better result. Not to mention that your tests should get your team more familiar with the new process before it’s fully in action, and the results of your tests will help to show them why the changes are for the better.
If your KPIs drop compared to your old process during the tests, it’s time to go back to the drawing board with your team. Otherwise, it’s time to deploy the new process!
There’s not too much to say here, other than that you need to check that everyone has access to the new process, knows exactly what they need to be doing, has access to any resources they might need, and is trained with any techniques or technology new to the process.
Famous BPR examples and what they changed
Business process reengineering becomes clearer when you can see the old mechanism and the redesigned one. Google changed how interview evidence was collected. Taco Bell moved preparation work out of individual restaurants. Ford removed invoices from accounts payable and connected purchasing with receiving data.
- Taco Bell
- Ford
Google redesigned parts of its hiring process after its own analysis found that interview scores did not predict how people later performed. In a 2013 New York Times interview, then-SVP of People Operations Laszlo Bock described the old relationship between interviewer scores and later job performance as “a complete random mess.”
The redesign moved away from brainteasers and inconsistent personal judgment toward structured interviews, consistent questions, and comparable evidence. The lesson is not that one interview format is universally correct. It is that Google changed the evidence-producing mechanism after measuring the old process instead of automating a method that did not work.
Taco Bell
Taco Bell’s K-Minus program changed where restaurant work happened. Rather than preparing every ingredient from scratch inside each location, more preparation moved to central commissaries. Hammer and Champy’s book on BPR describes how ingredients were prepared outside restaurants and assembled when customers ordered.
That was an operating-model redesign, not a faster kitchen checklist. It changed facility needs, labor, consistency, and the work expected at each restaurant. Taco Bell began in California, not Mexico, and its later growth came from many decisions. The useful BPR lesson is the relocation and simplification of preparation work, not an unsupported claim that one program caused every later result.
Ford
Michael Hammer’s Ford example focused on accounts payable. Instead of improving how invoices were keyed and reconciled, Ford connected purchasing and receiving data so the company could pay from a verified match. Hammer and Champy’s account explains how the storekeeper checked delivered goods against the purchase order in the database.
The redesign removed the invoice as the organizing artifact and reduced accounts payable staffing by about 75%. The important point is the mechanism: Ford eliminated reconciliation work by changing the information flow. It did not merely make invoice processing faster.
BPR best practices from the expert
American engineer, author, and computer science professor
Michael Hammerpioneered business process reengineering in the 1990s with his HBR article
Reengineering Work: Don’t Automate, Obliterate. The article was a rallying cry for businesses who were finding little help from traditional process rationalization and automation. The general message? You’re not going to get anywhere with small changes. Rip it up and start again.
His changes in just two example companies rendered the work of hundreds of customer-facing employees useless and made dramatic changes in the efficiency of the business.
If anyone’s the father of BPR, it’s Hammer. A few years later, however, it was formalized by another American academic ,
Tom Davenport. Davenport laid the groundwork for a proper process which companies can follow to reengineer their business processes:
- When identifying the process to be reengineered, pick the most important processes, or those that cause most conflict with business objectives. It’s less common for businesses to catalog all of their processes and reengineer every one.
- Before you start, understand and measure the existing processes using a method like business process mapping. This way, you won’t repeat your mistakes when drawing up a new process.
- Use technology to change the information flow, not to automate a broken task. Ford removed invoice reconciliation by connecting purchasing and receiving data.
- See the new process as a prototype, not a final copy. Treat the redesigned process as a prototype. Test it, gather feedback, and iterate in line with agile principles.
Perfect processes don’t exist
Business process reengineering can rescue an important process that incremental improvement cannot fix. It will not create a process you can ignore forever. Volume changes. Systems change. Regulations change. People find new shortcuts. A redesigned process needs an owner, evidence, and a review cadence.
AI can help teams analyze workflow runs, summarize exceptions, identify repeated handoffs, and draft alternatives. It does not remove the need for a baseline or accountable judgment. A model can suggest that two steps look redundant. The process owner still has to decide whether one of those steps is a control, test the redesign, and verify the result.
Process Street is one Compliance Operations Platform with Docs and Ops capability areas plus built-in AI. Docs gives teams a governed place to author, version, and approve policies and procedures. Ops turns those procedures into workflows with assignments, conditional logic, approvals, automations, integrations, and audit-ready evidence.
That connection matters after a business process redesign. The approved method, the work itself, and the evidence stay connected. Teams can see where runs stall, update the controlled procedure, deploy the change through the workflow, and monitor whether the result improves without relying on scattered documents and inbox history.
Process Street also has direct, universal integrations to 5,000+ systems. Need a new one? An AI agent builds it on the fly. That lets a redesigned process connect to the systems where finance, HR, customer, quality, and compliance work already happens.
Start with a process that is important, fundamentally broken, and feasible to change. Map the current state, define the outcome, redesign the mechanism, test it with the people who do the work, and keep measuring after launch. A functional process can still be a candidate for reengineering when the underlying model no longer serves the business.