Business Process Reengineering (BPR): A 4-Step Guide With Examples

Business process reengineering (BPR) is the radical redesign of a business process from scratch to achieve a step change in cost, quality, speed or service — as opposed to improving the existing process a few per cent at a time. Where continuous improvement asks "how do we do this better?", reengineering asks "if we were starting today, with today's tools and today's customers, would we do this at all, and if so, how?"

The term arrived with Michael Hammer's 1990 Harvard Business Review article "Reengineering Work: Don't Automate, Obliterate" and the 1993 book he wrote with James Champy, Reengineering the Corporation. It was the management idea of the decade, it was badly misused as a cover for lay-offs, and it fell out of fashion. But the core method — pick a broken process, map it honestly, redesign it around the outcome rather than the departments, and implement with proper change management — is as useful today for a 60-person MSP with a three-week client onboarding as it was for Ford's accounts payable department.

This guide is for operations, IT, HR and finance leads who own a process that is not going to be fixed by tweaking it. It covers what BPR is and where it came from, how it differs from continuous improvement and BPM, the signals that tell you a process needs reengineering rather than improvement, the classic cases and Hammer's principles, a four-step method with sub-steps you can run at a company without a transformation office, why reengineering efforts fail and how to avoid that, and what to do the day after the new process goes live.

What Is Business Process Reengineering?

Hammer and Champy defined reengineering around four words, each of which they insisted was load-bearing. It is fundamental: it starts by asking why the process exists and what it is for, with no assumptions carried over. It is radical: it goes to the root and redesigns, rather than patching what exists. It aims at dramatic improvement — a step change, not an increment. And its unit of work is the process: the end-to-end sequence that turns inputs into an outcome a customer values, cutting across departments rather than living inside one.

That last point is the one that matters most in practice. Most organisations are structured around functions — sales, finance, IT, HR, operations — but value is created by processes that run across them. A new client is onboarded by sales, then finance, then IT, then the account team, and the delays and errors live at the boundaries between them, where nobody owns the whole thing. Reengineering attacks those boundaries. It is the reason the discipline exists and the reason it is disruptive: a genuinely reengineered process usually changes who does what, which is uncomfortable for everyone whose job was defined by the old hand-offs.

Where the idea came from

Hammer's 1990 article was a reaction to a specific failure he saw repeatedly in the 1980s. Companies were spending heavily on information technology and getting disappointing results because they were using computers to speed up existing processes — automating the paperwork, the approvals and the hand-offs that a paper-based organisation had accumulated over decades. His argument was that the processes themselves were the problem, and that technology's real value was in enabling processes that had been impossible before: capturing information once at the source, letting one generalist do what five specialists had done, putting decisions where the work happened.

The 1993 book broadened this into a full management programme and made reengineering a boardroom word. What followed is well documented: many companies adopted the label without the discipline, "reengineering" became a euphemism for downsizing, and by the late 1990s the term was tarnished. Hammer himself spent much of the following decade arguing that the failures came from doing it badly — reengineering the wrong things, skipping the redesign, ignoring the people — rather than from the method. The method survived, mostly under other names: process transformation, operating model redesign, and, when done with software, business process management.

BPR vs Continuous Improvement vs BPM vs Digital Transformation

These four terms are often used interchangeably, and choosing the wrong one for a given problem is expensive in both directions: reengineering a process that needed a tweak wastes months and goodwill, while tweaking a process that needed reengineering produces a slightly faster version of something fundamentally broken. The table separates them by ambition, scope, risk and the situation each suits.

The relationship between them is sequential rather than competitive. Reengineering is what you do to a process once, when it is broken enough to justify the disruption. Continuous improvement is what you do to it forever afterwards. BPM is the management system that makes both possible: it gives you the measurements that tell you a process needs reengineering, and the operational platform that runs the new design and keeps it improving. Digital transformation is a strategic programme that will typically contain several reengineering projects inside it.

A useful mental test: if the people who run the process could describe a version that is twice as fast with fewer hand-offs, and the reason it does not exist is organisational rather than technical, you are looking at a reengineering candidate. If nobody can imagine a radically different version and the complaints are about specific steps, you are looking at continuous improvement.

When BPR Is the Right Tool: Seven Signals

Reengineering is expensive in attention, goodwill and calendar time, so it should be reserved for processes that genuinely need it. These seven signals, individually suggestive and collectively decisive, are the ones that reliably indicate a process is past improving.

1. Elapsed time dwarfs touch time. Measure how long the process takes end to end, then add up how long anyone actually works on it. When a client onboarding takes 18 working days but contains six hours of work, the process is 97 per cent waiting. No amount of speeding up the six hours will fix that; only removing the hand-offs that cause the waiting will.

2. Nobody owns the whole thing. Ask who is accountable for the process end to end and get five names, each responsible for their department's piece. Errors and delays cluster at the boundaries, and every attempt to fix them turns into a negotiation between teams.

3. The process exists to serve a constraint that has gone. Three-way invoice matching exists because paper purchase orders, delivery notes and invoices arrived separately and had to be reconciled. Weekly status meetings exist because there was no shared view of status. When the constraint has gone but the process remains, reengineering is the only way to remove it, because improvement will optimise the reconciliation rather than question it.

4. Improvement efforts have plateaued. The team has run several rounds of kaizen or fix-it projects and each delivers less than the last. The remaining waste is structural.

5. Workarounds are the real process. The documented process is not the one people follow. There is a spreadsheet, a group chat, a person who "just sorts it out". When the informal process is faster than the official one, the official one is the problem.

6. Customers or staff route around it. Clients escalate to the managing director rather than use the support process; managers hire contractors to avoid the procurement process. Avoidance at scale is a verdict on the design.

7. A change has made the old design obsolete. A merger, a new regulatory regime, a move to remote work, a new core system, or growth past the size where one person could hold the process in their head. The process was designed for a company that no longer exists.

Score your process against the seven signals before you commit a team to it. Tick every statement that is true today:

• End-to-end elapsed time is more than ten times the actual touch time
• No single person is accountable for the process from trigger to outcome
• At least one major step exists only because of a constraint that no longer applies
• The last two improvement rounds each delivered less than the one before
• The informal workaround is faster and more reliable than the documented process
• Customers or colleagues regularly escalate or route around the process
• A merger, new system, new regulation or growth spurt has changed what the process must do

If three or more of these apply, improvement will not get you there. If none applies, do not reengineer — it is the wrong tool, and the disruption will cost more than it returns.

The Classic BPR Examples: Ford and IBM Credit

Two cases from Hammer's writing have become the standard illustrations of reengineering, and they are worth telling carefully, because the versions that circulate online are often garbled. Both are as Hammer and Champy reported them; the numbers are theirs, and they are describing the early 1980s and late 1980s respectively.

Ford's accounts payable

In Hammer's telling, Ford's North American accounts payable department employed more than 500 people in the early 1980s. Management set out to reduce that by around a fifth through automation — a respectable target for a conventional improvement project. Then Ford looked at Mazda, in which it held a stake, and found that Mazda handled accounts payable with a team of about five. Even allowing for Mazda's smaller size, the gap could not be explained by efficiency. Something structural was different.

The old Ford process was built around matching. Purchasing raised a purchase order and sent a copy to accounts payable. Goods arrived at receiving, which sent a receiving document to accounts payable. The supplier sent an invoice to accounts payable. A clerk then matched all three, and when they disagreed — which, across fourteen data items, they frequently did — the clerk spent time chasing the discrepancy before payment could be released. Most of the department's effort went on mismatches.

The reengineered process, which Hammer called "invoiceless processing", removed the invoice from the loop. Purchasing entered the order into an online database. When goods arrived, receiving checked them against the database: if they matched an open order, receiving accepted them and recorded the receipt, and the system paid the supplier; if they did not, receiving sent them back. Suppliers were asked not to send invoices. The matching work disappeared because the process no longer produced anything to match. Hammer reported that head count in the department fell by around three-quarters, and that the accuracy of financial information improved because there was only one record of each transaction rather than three.

The lesson Hammer drew was not "use a database". It was that Ford's original automation plan would have made the matching faster and cheaper while leaving the matching in place — the mistake his article title warned against. The database mattered because it allowed a different process, one where information was captured once at the source and receiving, not accounts payable, made the decision.

IBM Credit

The second case, from Reengineering the Corporation, concerns IBM Credit, the subsidiary that financed the computers and software IBM's sales force sold. A financing request from a salesperson passed through five specialist steps in sequence: it was logged, sent to a credit specialist, then to a business-practices specialist who adjusted the standard contract, then to a pricer who set the interest rate, then to an administrator who assembled the quote letter. Hammer and Champy report the average turnaround as six days, and sometimes two weeks — long enough for customers to find other financing or for salespeople to lose the deal.

Two senior managers tested the process by walking a request through all five steps themselves, asking each specialist to handle it immediately. The actual work took around 90 minutes. The rest of the six days was the request sitting in queues between departments. The delay was not in the work; it was in the hand-offs.

The redesign replaced the five specialists with a single generalist — a "deal structurer" — supported by a new system that held the credit rules, contract clauses and pricing tables, so that one person could handle a standard request end to end. Genuinely difficult cases were referred to a small pool of specialists, but as exceptions rather than the default path. Hammer and Champy report that turnaround fell from six days to about four hours, and that the group went on to handle a far larger volume of requests with a small reduction in staff.

Hammer's Reengineering Principles

The 1990 article set out seven principles for redesigning a process. They have aged remarkably well — several read like a description of what good process software does today — and they make a useful checklist when you are staring at a clean sheet in step 3 of the method below. They are paraphrased here with a modern example for each.

1. Organise around outcomes, not tasks

Give one person or one team responsibility for the whole outcome, rather than splitting the process into task-sized pieces owned by different departments. The IBM Credit deal structurer is the canonical example. A modern one is an onboarding specialist who owns a new client from contract to first service review, rather than sales, finance, IT and account management each owning a slice.

2. Have those who use the output of the process perform the process

Where the customer of a process can do the work with the right tools, let them, and remove the department in the middle. Self-service equipment requests with pre-approved catalogues, managers provisioning standard software for their own teams from an approved list, and departments raising their own purchase orders within budget are all applications of this principle.

3. Fold information-processing work into the real work that produces the information

The person who does the work records it, at the time, in the system of record — rather than handing paper or a message to someone whose job is to enter it. This is the principle behind receiving accepting goods at Ford, and behind capturing evidence inside a checklist step rather than writing it up afterwards.

4. Treat geographically dispersed resources as though they were centralised

Shared systems let distributed teams work as one unit, with central visibility and local execution. For a company with offices in three cities or a fully remote team, this is the difference between three versions of a process and one process with a dashboard.

5. Link parallel activities instead of integrating their results

When several teams work on parts of the same outcome, coordinate them while the work is happening rather than reconciling their outputs at the end. A new-hire onboarding where IT, HR, facilities and the manager can each see the others' progress against the start date is this principle applied; the alternative is a frantic reconciliation on the Friday before.

6. Put the decision point where the work is performed, and build control into the process

Let the person doing the work make the routine decisions, with the rules embedded in the process rather than enforced by a supervisor afterwards. Threshold-based approvals, conditional logic that routes only exceptions to a manager, and required fields that make a step impossible to skip are all controls built into the process instead of layered on top.

7. Capture information once, at the source

Enter every piece of data one time, where it originates, and let every downstream step read it from there. Every re-keying step in a process is a place where errors enter and time leaves. Modern integrations and webhooks make this principle cheaper to apply than at any point since Hammer wrote it.

The Four Steps of Business Process Reengineering

Every reengineering method, from Hammer and Champy's onward, comes down to four phases: make the case, understand the current process, design the new one, and implement it. What separates the projects that work from those that stall is the discipline inside each phase. The eight numbered steps below are the four phases with the sub-steps that matter, scaled for a company that has no transformation office and needs the process owner to lead it part-time.

Phase 1 — Identify the process and make the case

Phase 2 — Assemble the team and map the as-is process

Phase 3 — Design the to-be process with KPIs

Phase 4 — Implement and stabilise

Why Many Reengineering Efforts Fail, and What to Do About It

Reengineering acquired its reputation as much from its failures as its successes, and the failures were widely reported. It is worth being precise about the numbers, because inflated ones circulate. Hammer and Champy themselves wrote in Reengineering the Corporation that, by their own admittedly unscientific estimate, something like 50 to 70 per cent of the organisations that undertook reengineering did not achieve the dramatic results they set out to get. That figure was their judgement, not a study, and later commentators quoted it as fact. Hammer's own subsequent writing was blunt about why the failures happened, and his diagnosis is more useful than the percentage.

The recurring causes

Fixing a process rather than changing it. The team maps the current process, tidies it, automates two steps and calls it reengineering. The result is a marginal gain sold as a transformation, which discredits both.

Not focusing on processes at all. The effort targets a department, a system or a cost line rather than an end-to-end process, so the hand-offs — where the waste lives — are never touched.

Ignoring everything except the process design. The new process needs new roles, new measures, new systems and sometimes a new attitude to who is allowed to decide what. Redesigning the flow while leaving job descriptions, incentives and management structures unchanged produces a design nobody can operate.

Settling for minor results. The sponsor loses nerve when the design turns out to be disruptive and accepts a smaller change. Hammer's view was that a reengineering effort that aims for 10 per cent will get 10 per cent at best, while paying the full disruption cost.

Quitting too early. The pilot exposes problems, the organisation's patience runs out, and the project is quietly shelved a month before it would have worked.

Trying to make it happen from the bottom up, or without the leader. Reengineering changes who does what across departments, and only someone senior to all of them can make that stick. Without visible, sustained executive sponsorship the departments simply wait it out.

Using it as a euphemism for lay-offs. When "reengineering" is announced and people lose their jobs, every subsequent process project is met with resistance, whatever it is called. The damage lasts years.

The change-management answer

Almost every cause on that list is about people rather than process design, which is why the phases above spend so much of their effort on sponsorship, team composition, pilots and role changes. Three practices make the biggest difference at a small or mid-sized company.

First, involve the people who do the work in designing the new process, and make sure they are the ones who run the pilot. People do not resist their own designs. Second, be honest from the start about what the change means for roles. If the new process needs fewer people in one team and more in another, say so early, and say what happens to the people affected; silence is filled with the worst assumption. Third, make the new process easy to follow and impossible to quietly abandon: run it as an executable checklist with named owners and a dashboard, so that the organisation can see it working and the process owner can see the moment anyone drifts back to the old way.

A Modern Illustration: Reengineering MSP Client Onboarding

The Ford and IBM cases are large-company stories from decades ago. Here is what the same method looks like at a company most readers will recognise. The example is illustrative — a composite of the pattern we see repeatedly rather than a single named client — but every element of it is ordinary.

The as-is process

A 45-person managed service provider onboards two or three new clients a month. On paper, onboarding takes two weeks. Measured over the last eight clients, the elapsed time from signed agreement to the client being fully monitored, documented and receiving its first service report averaged 23 working days, with a range from 14 to 41. Touch time — the actual engineering, documentation and account-management work — averaged about 14 hours per client.

The map showed why. Sales handed the signed agreement to the office manager, who created the client in the PSA tool and emailed the service desk lead. The service desk lead assigned an engineer when one was free, typically four to six days later. The engineer ran discovery, then handed a list of findings to the documentation specialist, who re-keyed them into the documentation platform and raised a ticket for the RMM deployment, which went back to a different engineer. Finance set the client up separately, from the same agreement, and frequently with a different site address. The account manager was told the client was "live" by whoever finished last, and scheduled a kick-off call for the following week. There were eleven hand-offs, three re-keyings of the same client details, and nobody who could say, on any given day, where a client's onboarding was.

The signals

Elapsed time was eleven times touch time. No one owned the whole process. The documentation hand-off existed because, five years earlier, engineers could not edit the documentation platform; that constraint was long gone. Two previous improvement efforts — a better spreadsheet, a weekly onboarding stand-up — had each shaved a couple of days and then plateaued. New clients regularly rang the managing director to ask what was happening. Five of seven signals.

The to-be design

The team — the service desk lead, an engineer, the documentation specialist, the account manager, a finance administrator and, as the outsider, a salesperson — produced two designs and chose the more radical one. It applied Hammer's principles almost line by line.

The signed agreement in the PSA tool became the single trigger. A webhook created the client record in the documentation platform, the RMM and the finance system from one source, so the client's details were captured once (principle 7). A named onboarding engineer owned each client from trigger to first service report (principle 1). The engineer recorded discovery findings directly into the documentation platform during discovery, eliminating the documentation hand-off (principle 3). The client completed a structured pre-onboarding questionnaire themselves, providing the site, contact and network details the office manager used to chase for (principle 2). Standard monitoring policies were applied by rule based on the questionnaire answers, with only non-standard environments routed to the senior engineer (principle 6). Every step ran inside a single onboarding checklist with due dates keyed to the go-live date, so the account manager, finance and the service desk could see each other's progress rather than reconciling at the end (principle 5). Hand-offs fell from eleven to three.

The result

After a four-week pilot on three clients and a further eight weeks at full volume, elapsed time averaged six working days, with the slowest client at nine. Touch time fell slightly, to about 11 hours, mainly from removing the re-keying. First-service-report accuracy, previously a recurring source of client complaints, stopped being one. The office manager's onboarding work disappeared and was replaced with owning the client questionnaire. Nobody lost their job; the documentation specialist became the owner of the documentation standards the engineers now followed. The MSP's broader process management then absorbed the new onboarding as one standardised, measured process among many.

Twenty-three days to six is the kind of result reengineering is for. It came from redesigning the hand-offs, not from working harder or buying a new tool — the PSA, RMM and documentation platforms were the same before and after. The checklist platform was new, and its role was to make the new design the only way the process could run.

Measuring the Results of Reengineering

A reengineering project without measurement is a reorganisation with better slides. The measures should be chosen in step 6, instrumented in the pilot, and reported for at least a year afterwards. Four categories cover most processes.

Time. Elapsed time from trigger to outcome is the headline measure for almost every reengineering, because hand-offs are usually what was removed. Report it as an average and a range; a process that averages six days but occasionally takes thirty has a design gap. Touch time is the secondary measure and often moves less than people expect.

Cost. Fully loaded cost per instance — per client onboarded, per invoice paid, per change deployed — including the time of everyone involved. This is the measure finance will ask for and the one most likely to be gamed, so define it once and keep the definition.

Quality. First-pass yield (instances completed without rework), error rate, and the customer-facing failures the process used to produce: wrong addresses, missed steps, unmonitored devices. Quality measures are the ones that show whether the process is genuinely better or merely faster.

Experience. A short, regular question to the customer of the process — the new client, the new hire, the requesting manager — and to the people running it. Reengineering that improves the numbers while making the work miserable will not survive its first staff turnover.

The practical requirement behind all four is that the process must generate its own data. If measuring it means someone collecting timestamps from emails every month, the measurement will stop within a quarter. Run the process on a platform that records every step, its owner and its completion time, and the KPIs become a dashboard rather than a project. That is the connection between reengineering and business process management software: the redesign is a project, but the measuring is permanent, and it needs a system.

After BPR: Standardise, Then Improve Continuously

The day the new process goes live at full volume is not the end of reengineering; it is the moment the process becomes ordinary, and ordinary processes need ordinary management. Two things have to happen in sequence.

Standardise the new design

A reengineered process is, by definition, unfamiliar. Left to memory and goodwill, it drifts back towards the old one within months, because the old one is what everybody knows. The defence is to make the new design the path of least resistance: a written procedure, an executable checklist that assigns each step to a named role with a due date, required evidence on the steps that matter, and one place where anyone can see the status of any instance. Our guide to process standardisation covers how to do that without smothering the process in documentation. The test is simple: could a competent person who joined last week run the process correctly, using only what is written down and the checklist?

Then improve it continuously

Once the new process is stable and measured, hand it over to continuous improvement. The reengineering team disbands; the process owner keeps the KPIs, reviews them monthly, and runs small PDCA cycles on the steps that the data shows are slowest or most error-prone. Expect a further steady gain over the following year from this — the reengineered process was designed on paper, and real use will find dozens of small refinements. Some of those refinements will be automations: now that the process is standardised and instrumented, it is a good candidate for business process automation of its rule-based steps, which is the right order — redesign, standardise, then automate. Trying to automate first is precisely the mistake Hammer's article was about.

Finally, keep the signals list from earlier in this guide in the process owner's review. When the elapsed-to-touch ratio starts to climb again, when workarounds reappear, when a system or regulation changes the constraints, it may be time for the next reengineering. Processes are not designed once.

Common Business Process Reengineering Mistakes

Beyond the programme-level failures above, these are the specific mistakes that recur inside otherwise well-run reengineering projects at small and mid-sized companies. Each is easier to avoid than to recover from.

Free Templates for Reengineering Projects

These three templates cover the points in a reengineering project where a structured checklist saves the most time: making the case at the start, controlling the changes to systems and roles during implementation, and running a reengineered onboarding process the same way every time afterwards. Each is an executable checklist you can assign, schedule and adapt.

Business Case Checklist

Baseline, problem statement, options, expected benefits, costs and risks — the one-page case for change that gets a reengineering project sponsored.

IT Change Management Checklist

Impact assessment, approval, implementation and post-change review for every system change a redesigned process needs — with a record of who approved what.

Simple Customer Onboarding Checklist

A single-owner onboarding run from signed agreement to first review, with due dates keyed to go-live — the shape most reengineered onboarding processes end up in.

How CheckFlow Fits Into Business Process Reengineering

Reengineering is a design activity; CheckFlow is where the design becomes the way the work is done. Its role starts in step 6, when the to-be process is written down, and continues for as long as the process runs. The features that matter are the ones that make a new design the only way the process can happen, and that give the process owner the measurements to prove it worked.

The to-be process becomes a template: one step per action in the new design, in the new order, with the old hand-offs simply absent. Each step carries a task assignment to a role, so "the onboarding engineer owns the client end to end" is a property of the process rather than an aspiration; when a run is created, the role resolves to the right person. Dynamic due dates are calculated from the run's anchor — the go-live date, the change window, the start date — so the design's timing holds on every instance. Conditional logic handles the exceptions the design identified, routing only the non-standard environment or the over-threshold spend to a specialist, which is Hammer's sixth principle built into the checklist.

Recurring schedules run the reengineered process on a cadence where it has one — a monthly service review, a quarterly access re-certification — and webhooks, Zapier and the REST API start runs from the trigger in your PSA, HR or ticketing system, so information is captured once at the source and the process begins without anyone remembering. The real-time dashboard shows every instance of the process, where it is and who holds it, which is the measurement step made permanent; the audit trail records who did each step, when and with what evidence, so the KPIs from step 6 and the compliance record come from the same place. Our business process management software page describes how those pieces combine across a whole process portfolio, and value stream mapping is a useful companion for the as-is analysis in step 4.

Pricing starts at $10 per user per month, and there is a 14-day free trial with no credit card required — long enough to build the to-be process as a template and run the first pilot instances on it.