Business Process Reengineering: Steps and Real Examples

Business process reengineering (BPR) means throwing out how a process works today and designing it again from a blank page, built around the outcome the customer actually needs rather than the department structure that grew up around it.

That sounds like ordinary process improvement until you look at what it replaced. The two textbook cases, IBM Credit Corporation and Ford’s accounts payable department, did not trim a process by 10 or 20 percent. They removed the process that existed and built a different one, and both cut turnaround time or headcount by roughly three quarters. That gap between incremental fixing and structural redesign is the whole point of BPR, and it is why the term gets used loosely today for anything from a new approval workflow to a full ERP-driven overhaul.

This article covers where the term came from, the two case studies every BPR discussion still refers back to, the steps and principles behind a redesign, the real benefits and failure risks including the widely repeated (and largely mythical) failure-rate statistic, and how BPR relates to ERP implementation and today’s AI-driven automation.

Business process reengineering definition

Business process reengineering is the fundamental rethinking and radical redesign of a core business process, aimed at dramatic improvement in cost, quality, speed, or service, rather than incremental improvement of the process as it already exists. The definition matters because it rules out most of what companies call “reengineering”: if you are automating the existing approval chain or trimming a step here and there, that is process improvement, not BPR. Reengineering asks a harder question first: does this process, or this handoff, need to exist at all, and if we designed it today with no legacy constraints, what would it look like?

In practice that usually means collapsing multiple specialist roles into one, removing hand-offs and approval queues, and replacing sequential steps with a single system (often an ERP or workflow platform) that gives one person or one automated flow everything needed to complete the job end to end.

Where the term came from

Business process reengineering was named and defined by Michael Hammer in his 1990 Harvard Business Review article, “Reengineering Work: Don’t Automate, Obliterate.” Hammer’s argument was that companies were spending heavily on computers to speed up bad processes instead of questioning why those processes existed in their current form. His prescription was blunt: obliterate the process and start over, rather than paving the cow path with software.

Hammer and consultant James Champy expanded the idea into the 1993 book Reengineering the Corporation, which turned BPR into the defining management fashion of the early 1990s and supplied the two case studies almost every BPR article, including this one, still cites.

Business process reengineering examples

IBM Credit Corporation: the credit approval process

IBM Credit financed the computers, software, and services IBM sold to customers. Approving a financing request took an average of six days and sometimes two weeks, long enough that sales reps would call in daily trying to speed things along, and long enough that some customers took their business elsewhere before approval came through.

The application passed through five specialists in sequence: a credit check, a check of the customer’s business terms, a pricer who set the interest rate, an administrator who compiled everything into a quote letter, and a clerk who logged and dispatched it. Two IBM Credit managers tried an experiment: they personally walked a financing request through all five steps themselves, timing only the actual work at each desk. The work took ninety minutes. Everything else, more than six days on average, was the request sitting in an in-tray waiting for someone to get to it.

IBM Credit did not try to speed up the hand-offs. It eliminated them. The five specialist roles were replaced with one generalist, a “deal structurer,” who processed the entire application from intake to quote letter, supported by a new computer system that gave that one person the tools and reference data all five specialists had previously used separately. For the roughly 90 percent of requests that were not unusually complex, one generalist could do what five specialists had done in relay. Turnaround fell from a typical seven days to about four hours, with no increase in headcount, and the smaller team handled roughly 100 times the volume of applications the old process could.

Ford Motor Company: accounts payable

Ford’s North American accounts payable department employed around 500 people matching purchase orders, receiving documents, and supplier invoices by hand before releasing payment, a three-way match that is standard procurement control. Ford benchmarked the equivalent department at Mazda, in which it held a stake, and found Mazda ran the same function with about five people. Even adjusting for the difference in company size, the gap was too large to explain away.

Rather than speeding up invoice matching, Ford redesigned the process to remove the invoice. When a purchase order was issued, it went into a shared database. When the receiving dock accepted goods, a clerk checked the delivery against that database; if it matched, the system triggered payment automatically. If it did not match, the goods were returned to the supplier, no invoice, no manual matching, no exception queue. Accounts payable headcount fell by about 75 percent, and control actually improved because the system, not overworked clerks, caught mismatches.

Both cases share the same shape: the old process was not sped up, it was removed, and a single integrated system replaced a chain of specialists checking each other’s work. That is the pattern to look for when you are deciding whether a project is really reengineering or just automation of the status quo.

Business process reengineering steps

1. Define the goal, not the fix

Start from the business outcome the process needs to deliver (a same-day credit decision, a three-way match with no manual invoice handling) rather than from the current org chart. IBM Credit’s goal was not “process applications faster,” it was “give the sales force a same-day answer.” Naming the outcome, not the department, is what keeps the project from turning into ordinary automation.

2. Map the current process, and time the actual work

Walk the process end to end the way IBM Credit’s managers did, and separate the minutes of real work from the days spent waiting in queues or in transit between departments. In almost every reengineering case study, the real work is a small fraction of the total cycle time; the rest is hand-off delay. That number, not a list of complaints, is the business case for redesign.

3. Design the new process around one owner, not a relay

Where the old process routed work through several specialists in sequence, the new process usually gives one person, one case team, or one automated flow end-to-end ownership, backed by a system that surfaces whatever data each of the old specialist roles needed. Test the redesign against real cases, including the awkward exceptions, before rolling it out, since a design that only works for the easy 90 percent of cases will fail on the hard 10 percent that specialists used to catch.

4. Implement, measure against the original cycle-time number, and hold the line

Roll out the new process, then measure it against the exact baseline from step two, not a vaguer sense of “smoother.” Expect pushback from anyone whose role the old process protected; that resistance is a normal part of the challenges below, not a signal the design is wrong.

Fundamental principles

• Organize around outcomes, not tasks: one person or team owns a whole process end to end instead of one step in a relay.
• Have those who use the output of a process perform the process: IBM Credit’s own sales and operations staff, not a separate department, ended up running the redesigned flow.
• Treat geographically or organizationally dispersed resources as though they were centralized: a shared database (as Ford used for purchase orders) can substitute for physically consolidating a function.
• Link parallel activities instead of integrating their results later: coordinate work as it happens rather than reconciling it at the end.
• Put the decision point where the work is performed, and build controls into the process: Ford’s system approved payment automatically at the point of match rather than routing it through a separate approval step.

How BPR differs from continuous improvement, Kaizen, and Six Sigma

These get confused because they all aim at better processes, but they differ in scale and pace. Kaizen and continuous improvement look at an existing process and make it incrementally better on an ongoing basis, with no defined end date; a Six Sigma project reduces defects and variation in an existing process using statistical methods, again without questioning whether the process should exist in its current form. BPR is a one-time project with a start and an end, and it explicitly permits questioning whether a process, or an entire department, should exist at all. If a project’s output is “the same process, done with fewer errors or in less time,” it is continuous improvement or Six Sigma. If the output is “a different process, with roles and hand-offs that did not exist before,” it is reengineering.

Benefits

• Step-change cycle time reduction: because reengineering removes hand-offs rather than speeding them up, the improvement is usually measured in multiples, not percentages, as in IBM Credit’s move from seven days to four hours.
• Lower headcount for the same or higher volume: Ford’s accounts payable case cut staff by roughly 75 percent while processing the same purchase volume, because the process needed fewer people to run it, not because remaining people worked harder.
• Fewer errors from fewer hand-offs: every hand-off between departments is a place where information can be lost, misread, or delayed; removing the hand-off removes that failure point along with the delay.
• A process that matches how the business actually works now: many processes still reflect constraints (paper routing, regional offices, batch computing) that no longer apply; reengineering is the mechanism for catching up.

Challenges, and the failure-rate statistic you’ll see everywhere

Nearly every article on this topic repeats a claim that 50 to 70 percent of reengineering projects fail. That number is worth tracing to its source before you repeat it, because Hammer and Champy themselves introduced it in their 1993 book as, in their own words, an “unscientific” estimate of how many reengineering efforts fail to achieve dramatic results, not a measured statistic from any study. Hammer later said the figure had been “widely misrepresented and transmogrified and distorted into a normative statement,” and that there is no inherent success or failure rate for reengineering as a method. Treat the 50 to 70 percent figure as a widely repeated guess by the term’s own inventors, not as data, and be skeptical of any source that cites it without that context.

The real, well-documented risks are more specific than a single failure-rate number:

• Redesigning the process while ignoring the people who run it: the roles that IBM Credit and Ford eliminated were real jobs; a redesign that treats headcount reduction as a side detail rather than the central change to manage will meet resistance that stalls or reverses the project.
• Confirming the new process actually works before scaling it: a redesign that only works for the easy cases and breaks on exceptions is worse than the process it replaced, because the safety net of specialists checking each other’s work is gone.
• Rolling out everywhere at once: a full-scale simultaneous rollout multiplies the impact of any data or process gap that a smaller pilot would have caught first.
• Losing controls along with the hand-offs: Ford’s redesign had to build the three-way-match control back into the automated system; removing a hand-off without replacing the control it happened to provide creates a compliance gap.

BPR, ERP, and today’s AI-driven redesigns

BPR and ERP are closely tied because implementing an ERP system forces exactly the question reengineering asks: does this process need to exist in its current form, or can the system’s built-in workflow replace it? Consultants generally recommend reengineering the process before configuring the ERP around it, not after, because configuring a new system to replicate an old, hand-off-heavy process just automates the same inefficiency Hammer warned about in 1990, at a much higher cost.

The technology available for the “new process” step has changed since Ford and IBM Credit built custom systems in the late 1980s. Where those projects needed bespoke case-management software, a modern reengineering project can lean on ERP-native workflow tools, RPA bots for the rule-based steps (matching a purchase order to a receipt is exactly the kind of task Ford would automate outright today), and AI models for the judgment calls that used to require a human specialist, such as flagging an anomalous invoice or scoring a credit application. The principle has not changed: remove the hand-off and give one system or one owner the whole job. Only the tools available to build that system have gotten cheaper and faster to deploy.

FAQs

Conclusion

Business process reengineering is not a faster version of the process you already have; it is a decision to remove that process and build a different one around the outcome you actually need. IBM Credit and Ford did not optimize a relay of specialists, they eliminated the relay. That distinction, and not a repeated failure-rate statistic, is the useful thing to take from thirty-five years of BPR case studies.

If you are considering it, start by timing your current process the way IBM Credit’s managers did: separate the minutes of real work from the days of queueing, and let that gap make the business case. Whether the redesign runs through project management discipline, an ERP rollout, or a smaller pilot first, the goal stays the same: one owner, one system, no hand-off.