Business process re-engineering (BPR) is the fundamental redesign of how work flows across an organization, from the first trigger to the final outcome, so that it is faster, better controlled and easier to measure. Instead of tweaking individual tasks, BPR asks whether each step, approval and handoff should exist at all. It should come before new software, because an ERP or workflow platform will faithfully automate whatever process you give it, including its waste and its gaps.
For Saudi companies preparing for an ERP or digital transformation, BPR turns a software project into a business project. It decides who owns each process, which controls are required and what the system actually needs to do. This guide explains how BPR differs from continuous improvement and how to run it step by step, so that system selection rests on a design you have already agreed.
What business process re-engineering is
BPR as a management discipline was popularized by Michael Hammer and James Champy in the early 1990s. Their central idea still holds: organizations are structured around functions, but outcomes are delivered by processes that cut across them. When each function optimizes its own piece, the end-to-end flow suffers.
A re-engineering effort therefore looks at a complete process, such as order-to-cash, procure-to-pay, hire-to-retire or record-to-report, and redesigns it around the outcome it is supposed to deliver. Typical results include fewer handoffs, approvals set by risk rather than habit, a single source of data entered once, clear ownership and controls built into the flow rather than bolted on at month-end.
BPR vs continuous process improvement
Both approaches are useful. The question is which one fits the problem in front of you.
| Dimension | Business process re-engineering | Continuous process improvement |
|---|---|---|
| Scope | End-to-end process across several departments | A task, step or sub-process within a team |
| Starting question | “Should we do this at all, and how would we design it from scratch?” | “How can we do this step a little better?” |
| Pace | Discrete program over weeks or months | Ongoing, in small cycles |
| Risk | Higher: changes roles, systems and controls at once | Lower: small changes, easy to reverse |
| Change management | Significant and planned | Light, mostly within the team |
| When to use | Before an ERP, after a merger, when a process is fundamentally broken or cannot scale | When the process design is sound but performance needs tuning |
In practice, the two work in sequence. BPR sets a new baseline design, and continuous improvement keeps refining it once it is live.
Signs you need re-engineering
The symptoms of a process that needs redesign rather than tuning are usually visible to anyone who works in it:
- Approvals by email. Purchase requests, discounts or payments are approved in inbox threads, with no consistent audit trail and no clear delegation of authority.
- Spreadsheet workarounds. Critical information such as pricing, stock positions or project costs lives in personal spreadsheets because the system does not support how work is actually done.
- Duplicate data entry. The same customer, supplier or item is keyed into two or three systems, and teams spend time reconciling differences.
- Unclear ownership. When something goes wrong, nobody can say who owns the process end to end, only who owns their step.
- Month-end fire-drills. Finance chases missing invoices, goods receipts and accruals every close because the upstream process does not capture them at the right time.
If several of these apply to the same process, incremental fixes are unlikely to be enough.
The BPR method, step by step
A practical re-engineering program follows seven steps: set goals and scope, map the as-is, diagnose, design the to-be, define KPIs and controls, pilot, and roll out. Each step has a clear output that feeds the next.
1. Set goals and scope
Name the process, its start and end points, and the outcome it should deliver. “Improve procurement” is not a scope. “Procure-to-pay, from purchase requisition to supplier payment, for all non-project purchases” is. Agree goals in business terms, such as faster cycle time or fewer invoice disputes, and appoint a sponsor and a named process owner.
2. Map the as-is
As-is mapping documents how the process really works today, not how the procedure manual says it works. Use three sources together:
- Workshops with the people who perform each step, walking through the process from trigger to outcome.
- Walkthroughs where you follow real transactions, documents and approvals end to end.
- Data from existing systems, such as timestamps, volumes, exception reports and rework loops, to confirm what people describe.
The output is a process map with every step, role, system, document and decision point, plus a list of pain points raised by the people doing the work.
3. Diagnose waste, handoffs, rework and control gaps
Analyze where value is lost: waiting time, handoffs that add nothing, approvals that exist out of habit, rework from poor data, and manual reconciliations. Equally, look for control gaps such as segregation-of-duties conflicts, bypassable approvals and steps with no audit trail. For Saudi businesses this includes checking that tax-relevant steps, such as e-invoicing under ZATCA requirements, are handled consistently rather than as an afterthought.
4. Design the to-be with process owners
The to-be design describes how the process should work. Design it with the process owners and key users, not for them, because they will run it and defend it. Challenge each step: can it be eliminated, combined, automated, moved earlier or handled by exception? Set approval rules by value and risk, define where data is captured once, and decide which decisions a system should make and which require human judgment. Keep the design system-neutral so it describes the business need, not one product’s screens.
5. Define KPIs, controls and RACI
A to-be process is not complete until it can be measured and governed. Define a small set of KPIs that reflect the outcome, such as cycle time, first-time-right rate or on-time payment. Document the controls embedded in the flow and who performs them. Build a RACI that shows, for every major step, who is Responsible, Accountable, Consulted and Informed. This is what turns a diagram into an operating model.
6. Pilot
Test the new design on a limited scope before scaling it: one business unit, one product line, one site or one category of spend. A pilot exposes missing data, unclear rules or unworkable approval chains while they are still cheap to fix. Measure the pilot against the KPIs you defined and adjust the design.
7. Roll out with change management
Rollout is where most of the effort goes. Update policies and delegation-of-authority matrices, train users on the process rather than only on screens, explain why the change is happening, and retire old workarounds. Track the KPIs after go-live and hand the process to its owner for continuous improvement.
Tools and notation
You do not need specialist software to do BPR well, but a shared notation helps everyone read the same map.
- BPMN 2.0 swimlane diagrams. Business Process Model and Notation is a widely used standard for drawing processes. Each role or department gets a horizontal lane, and the flow of tasks, decisions and events moves across the lanes. Swimlanes make handoffs visible at a glance: every time the flow crosses a lane, work changes hands and delay or error can creep in.
- RACI matrices. A simple table with process steps as rows and roles as columns, filled with R, A, C or I. The rule of thumb is exactly one “A” per step. If a step has no accountable owner or several, you have found an ownership problem.
- KPI trees. A KPI tree breaks a top-level outcome into the measures that drive it. For example, cash collection performance can be broken into invoice accuracy, invoice timeliness and dispute resolution time, each with an owner. This links the process design to the numbers leadership already watches.
Also keep a decisions log so every design choice is traceable to who agreed it and why.
Worked example: re-engineering order-to-cash
Consider a generic distributor whose order-to-cash process has grown organically.
As-is. Sales takes orders by phone and email and re-keys them into a spreadsheet. Credit checks are emailed to finance. Approved orders are keyed again into the inventory system. The warehouse ships and sends paper delivery notes to finance, which then raises invoices. Disputes arise because spreadsheet prices differ from the accounting price list, and collections staff hunt for proof of delivery.
Diagnosis. The same order is entered three times. Credit approval has no rules or audit trail. Pricing has two sources of truth. Invoicing waits for paper. Nobody owns the process end to end.
To-be. Orders are captured once, against a single customer and price master. Credit checks run automatically against defined limits, and only exceptions route to a named approver with a recorded decision. Confirmed orders release directly to the warehouse. Delivery confirmation triggers the invoice, including the required e-invoice, without re-keying. Proof of delivery is attached to the transaction for collections. A single process owner is accountable end to end, with KPIs for order-to-invoice time, invoice accuracy and dispute resolution.
The same logic applies to procure-to-pay: approvals by value and category, and three-way matching of order, receipt and invoice before payment.
How BPR connects to ERP selection and fit-gap analysis
The to-be process design is the most valuable input to ERP selection. It lets you write requirements in terms of business outcomes, controls and data, and then ask vendors to demonstrate your processes rather than their standard script.
It also makes fit-gap analysis meaningful. Each to-be requirement is compared with a candidate system’s standard capability and classified as fit, fit with configuration, workaround, or gap needing development or a process change. Without an agreed to-be, teams compare the system with the as-is and customize the ERP to reproduce old habits, adding cost, risk and upgrade pain.
The sequence that tends to work is: re-engineer the core processes, run fit-gap against shortlisted systems, choose the system, then implement and configure it against the agreed design. After go-live, the KPIs from the BPR phase become the baseline for ongoing optimization.
Common mistakes
- Automating a broken process. Moving an email-and-spreadsheet process into an ERP without redesign produces the same delays and errors inside a more expensive system.
- Skipping process owners. If designs are produced by consultants or IT alone, the business will not own them, and adoption will suffer.
- No KPIs. Without measures agreed up front, nobody can tell whether the new process is better, and the old workarounds return.
- Big-bang without pilots. Rolling out a redesigned process everywhere at once removes the chance to learn cheaply and increases operational risk.
- Ignoring controls and compliance. Segregation of duties, delegation of authority, audit trails and tax requirements must be designed in, not added after go-live.
Frequently asked questions
How long does a BPR program take?
It depends on the processes, entities and sites in scope. One core process can take weeks; several end-to-end processes ahead of an ERP can take a few months. Tight scoping controls duration.
Should BPR happen before or after choosing an ERP?
Before. The to-be design should drive requirements, vendor demonstrations and fit-gap analysis. Detailed design can then be refined during implementation, once the system’s standard capabilities are known.
What is the difference between as-is and to-be process mapping?
As-is mapping documents how a process works today, including workarounds and pain points. To-be mapping describes how it should work after redesign, with owners, controls and KPIs. The gap between the two defines the change program.
Does BPR mean job cuts?
Not necessarily. The aim is to remove waste and rework so people spend more time on valuable work. Role changes are common, so early staff involvement matters.
Can we do BPR in-house?
Yes, if you have people with process-design experience and time away from daily operations. Many organizations pair internal process owners with an external facilitator for method and an independent view.
Next steps
AIMLTS is a vendor-neutral consultancy based in Jeddah. We map and re-engineer processes, run fit-gap analysis, and then build, implement and optimize the systems that support them, from ERP Solutions and ERP Implementation through to Support & Optimization. To learn more about our approach, see Business Process Consulting, or book a discovery call to talk through the processes you want to redesign before your next system decision.