Business process reengineering means redesigning a process from the root rather than tuning its steps, to achieve a step change in time, cost, quality or customer service. Your company needs it when the flaw is in the design itself, and the best moment is before you automate, because automating a muddled procedure speeds up the waste instead of removing it.
This guide, for company leaders and operations teams in Saudi Arabia, explains what reengineering is, how it differs from process improvement and automation, the signs you need it, how to run it, why it stalls, and how to choose who leads it.
What is business process reengineering?
Business process reengineering (BPR) was set out by Michael Hammer in the early 1990s in a Harvard Business Review article, then in a book with James Champy. His argument: companies shouldn't automate their old processes; they should rethink them first.
The idea is one question: if we designed this process today, from scratch, how would we build it? The answer is usually fewer steps, fewer approvals, fewer handoffs and one owner accountable for the result.
At SELA, we lead business process reengineering within our operations management track, alongside organisational structure, authorities and KPIs. A redesigned process changes roles and decision points, and it doesn't hold if the structure and authorities stay as they were.
Three related ideas are often confused, although each answers a different question and starts from a different place:
| Process improvement | Business process reengineering | Process automation | |
|---|---|---|---|
| The question | How do we make the current procedure better? | How would we design the process from scratch? | How can systems carry out the steps instead of people? |
| Starting point | The existing steps | The outcome the customer wants | A designed, documented process |
| Scale of change | Gradual and limited | Fundamental, in design and roles | Technical, in how the work is executed |
| Fits when | The design is sound and performance needs tuning | The design itself causes the problem | The process is clear, repetitive and its rules are written |
The three aren't competing options; they can be stages in the life of one process: redesign, then automation, then continuous improvement after launch. The mistake is jumping to automation because it's the quickest purchase, before knowing whether the design deserves to be automated at all.
When does your company need business process reengineering?
Not every process needs a fundamental redesign; most are fine with targeted improvement. But some problems don't respond to improvement, because they come from the way the process was designed in the first place, or from a company that has grown into a size its procedures were never built for.
The clearest sign is waiting that outlasts the work. Follow one request from start to finish, compare the time someone worked on it with the time it sat waiting, and you'll see the problem. Improvement shortens the work; reengineering shortens the waiting, by removing the handoffs that create it.
Accumulated approvals often signal something deeper: undefined authorities, so every decision is escalated just in case. Removing signatures isn't enough; you need to define who decides what, within which limits, as we explain in our guide to organisational structure and the authority matrix.
The need also shows up at moments of major change. A company preparing for a new accounting system, a new branch or automated customer service has a rare chance to redesign the process once, now, rather than carry its flaws into the new system.
When don't you need it? When the process has a reasonable design and needs tighter execution, or when the issue is the team's skills rather than the procedure. In those cases process improvement and tracking a few KPIs are enough, and a redesign is a bigger change than the problem.
Why reengineer before you automate?
Hammer's famous line was: don't automate, obliterate. Automation carries out a process exactly as described, only faster. If the process is full of detours and extra approvals, automation runs the same detours faster, and makes them harder to change, because they are now rules built into a system.
Take a purchase request with five approvals, three added after old mistakes that no longer happen. Automate it as it is and you get five electronic approvals instead of five paper ones. Redesign it first and a clear spending limit with one approval may be enough, and automation is then built on a shorter path.
The difference shows in three ways. First, rules: a redesigned process has fewer steps and exceptions, which are what push up process automation cost the most. Second, ownership: one owner knows when to step in if the automation stops. Third, measurement: a baseline recorded before the change proves its effect.
So we treat redesign as a step before the tool decision, not after it. Once the target process is designed, the automation question is simpler: which steps remain repetitive with clear rules? Only those are candidates. We cover how to pick the first in our guide to what business automation is and how to choose your first process.
AI adds a question to the redesign: if reading documents and sorting requests no longer needs a person, do we need this step in its current form at all? That question belongs in the design phase, with clear limits on what the system decides alone, in line with the principles of the Saudi Data and AI Authority (SDAIA).
How to run a business process reengineering project, step by step
Reengineering doesn't start by drawing the new process. It starts by understanding the current process as it really runs, not as it was written down. Then you challenge every step in it, before designing the alternative and piloting it on a small scale.
- 1Choose the process, define the outcomeOne process that matters to the customer, and a measurable outcome: time, errors or cost.
- 2Map the current stateFollow a real request from start to finish and record the baseline.
- 3Challenge every stepWhy does it exist? What happens if it's removed? Who should really decide?
- 4Design the target processFewer steps, one owner of the outcome, new roles and authorities.
- 5Pilot on a small scaleOne branch or team for a short period, measuring the same outcome.
- 6Roll out, automate, measureDocument the design, automate what is still repetitive, and review the indicators regularly.
The most important step is challenging every step. Many exist to solve a problem that has gone, or because an old system allowed nothing else. One question exposes them: what would happen if this step disappeared tomorrow? If the answer is "nothing much", it is waste with an official stamp.
The design team needs three parties: the people who run the process daily, because they know its exceptions; someone representing the customer who receives its outcome; and a decision-maker who can approve a change across department lines. Without any one of them, the design comes out incomplete or blocked.
These steps follow our method on every project: diagnose, design the model and plan, execute, then follow up and improve, with one party accountable to you. The pilot protects the company from rolling out a design never tested against reality.
Once the design proves itself, it is written in the language of those who will run it and formally replaces the old procedure, so nobody works from two versions. We explain how in our guide to preparing a policies and procedures manual.
If the process handles personal data, the new design must comply with the Personal Data Protection Law: who sees the data at each step, where it is stored and when it is deleted. A redesign is the chance to get that right from the start.
Why reengineering projects stall
Reengineering has a mixed reputation, because many projects carrying its name grew beyond what companies could absorb, or became cover for cost-cutting alone. The causes of failure are well known, and you can avoid them if you know them before you start:
- Scope beyond capacity: redesigning every process at once drains the team and scatters management attention. Start with one process and prove its effect.
- Designed in the office: a new process drawn up without the people who run it collides with cases nobody thought of.
- No senior sponsor: the project crosses department lines, and only someone with authority above them can settle disagreements between them.
- Neglecting people: changing roles without explanation and training creates resistance that defeats the best design.
- No measurement: without a baseline before the change, nobody can prove the new design is better.
- Tool before design: buying a new system and then cutting the process to fit it, which is the wrong way round.
What these share is that the project was treated as a technical or paper exercise, not a change in how people work. However clever the design, it is worth nothing if the team drifts back to the old way a month later.
That's why operations management after launch needs regular follow-up: a few KPIs tied to the outcome you chose at the start, and a periodic review showing where waiting has crept back. That follow-up turns a redesign from a one-off event into continuous improvement.
And remember that successful business process reengineering isn't measured by the number of steps removed, but by the result the customer and the team can feel: requests completed faster, fewer errors, and a clear owner when something goes wrong.
Who should lead it: your team or a consultant?
You have three options for leading the project: your internal team, the vendor of the system or automation tool, or a consulting firm working with you. Each has its place, depending on the size of the process, how many departments it crosses, and your team's time and neutrality.
| Option | Fits when | What to watch for |
|---|---|---|
| Internal team | A process within one department, and a team with time and a method | Hard to challenge procedures it built itself, or to challenge other departments |
| System or tool vendor | The design is agreed and needs technical delivery | Tends to shape the process around its own tool |
| Consulting firm | A process that crosses departments, a major change ahead, or past improvements with no effect | Choose one that diagnoses and stays through implementation, not one that hands over maps |
Neutrality is usually what tips the balance towards an outside party. A process that crosses sales, finance and operations needs someone who can ask each department why it does what it does without being party to the disagreement. Your team remains a core partner, because it will work with the new design.
An example of the value of diagnosis before change is our organisational diagnosis of a plastics manufacturer that turned its findings into three targeted interventions: the diagnosis exposed a broken decision-making mechanism between the partners before any development decision was taken.
If you choose an outside party, ask about five things:
- Starting point: do they trace the real process with the people who run it, or start from a template?
- Scope: do they propose starting with one process whose effect is measured, or a broad programme all at once?
- Connection: does the design cover roles, authorities and KPIs, not just the steps?
- Tool neutrality: do they choose the tool after the design, or are they tied to a particular tool?
- Support: do they stay with your team through the pilot and rollout, or does their role end at handover?
Ask for a written scope: the process covered, the outcome to be measured, what is delivered at each stage and who signs it off. For comparing firms generally, see our guide to how to choose a management consulting firm.
Frequently asked questions
What is the difference between business process reengineering and process improvement?
Process improvement adjusts the existing procedure step by step: removing a redundant step, shortening an approval, standardising a form. Reengineering starts from the outcome the customer wants and asks how the process would be designed if you started today from scratch. The first fits a sound design; the second fits a design that is itself the problem.
Does reengineering mean cutting staff?
Not necessarily. The aim is for the process to reach its outcome in less time with fewer errors, and usually the team's time moves from copying, chasing and waiting to higher-value work. Roles may genuinely change, so the project needs a clear change management plan that explains what will change and why, before it starts rather than after.
How long does a business process reengineering project take?
It depends on how many processes are in scope, how many departments and systems they pass through, how much data on the current state exists, and how quickly the company makes decisions. The safest approach is to start with one important process, redesign and pilot it on a small scale, then plan the next ones from what you learned.
Is reengineering suitable for small and mid-sized companies?
Yes, and it can be easier there, because there are fewer processes and decisions sit closer together. A mid-sized company that grew quickly often carries procedures built for its old size. The scope should match the company: one or two core processes redesigned in depth, rather than a broad programme that drains the team without a clear result.
Can reengineering and automation be done in one project?
Yes, provided the design comes first. Within one project, the target process is designed and piloted manually or with simple tools, then automation is built on the design that has proven it works. Starting the automation before the design is agreed sends the project back to automating the old process, mistakes and all.
Next step: start with one process
Business process reengineering isn't a vast project that turns the company upside down. It's a decision to redesign the process that hurts your customers and team most, before you automate it or add a system to it. Choose one process, record its baseline, design its replacement with the people who run it, and pilot it before rolling it out.
If you want to know which of your processes need a redesign and which only need a targeted improvement, talk to SELA about business process reengineering in your company and we'll start by diagnosing the first process with you.
