Method · Process optimization

Business process optimization: methods, measurement and failure modes

Ask how a task actually gets done, rather than how the manual says it should be, and the answer usually involves an unapproved spreadsheet, an email chain standing in for an approval, or a workaround that was meant to be temporary. Closing that gap is the whole discipline.

RE-ViVE Research·Published 8 September 2026·13 min read·Method guide

In brief

Optimization is diagnostic work that precedes a build-or-buy decision. It is not automation, and it is not a transformation programme, though it usually feeds one.
Four frameworks recur — Lean, Six Sigma, business process management and process mining. Mature teams mix them according to the process rather than committing to one.
Most successful projects follow the same six phases, and the phase most often skipped is the last: ongoing monitoring, without which the process drifts back.
Five metrics distinguish improvement from activity, and all of them require a baseline captured before anything changes.
Five failure modes recur, of which automating too early is the most expensive: the flaws move faster and become harder to unwind.

1Definition and boundaries

Business process optimization is the work of examining an existing workflow, establishing where it loses time, money or accuracy, and reshaping it so that it does not. Simple to state, harder to execute, largely because the documented process and daily practice diverge quickly once a team is under pressure.

Three boundaries are worth drawing, because conflating them causes most of the wasted effort in this field.

Not automation: Automation is frequently part of the outcome. It is not the method. Automating a broken process yields a broken process that runs faster and is harder to unwind afterwards.
Not digital transformation: Optimization usually feeds a transformation programme, but it is the diagnostic step that precedes deciding what to build or buy — not the programme itself.
Not reengineering: Optimization improves what exists incrementally. Reengineering redesigns from the ground up. Most organisations begin with the former and move to the latter only when incremental change stops being sufficient.

One question drives the whole practice, asked repeatedly and a little annoyingly: does this step add value for anyone, and if not, why does it still exist?

2Why demand for this rose

Several conditions converged. Costs rose across labour, compliance overhead and software licensing, so workflows that were previously absorbed without much thought became visible. Customer tolerance fell: a process that quietly takes five internal days now surfaces externally as a complaint or a one-star review.

Remote work exposed a substantial amount of undocumented process that had lived in physical proximity — two people sitting near each other, resolving exceptions by walking over. When that stopped being possible, many teams discovered how informal their process actually was.

Four signals indicate that a process warrants examination: work waits on a single approver for reasons nobody can articulate; staff maintain shadow spreadsheets because the system does not handle a step; the same error recurs regardless of retraining; and nobody can explain why a step exists in its current form.

The third is the most diagnostic. An error that survives retraining is usually a property of the process rather than of the people executing it.

3How projects usually run

There is no mandatory method, but successful projects across industries follow a consistent shape.

Map what actually happensDocument the process as it runs, not as the policy describes. Talk to the people doing the work, pull system logs, and reconstruct the real sequence from data. The distance between documented and actual is usually where the largest problems sit.
Locate the breakdownsApprovals that need not exist, data entered twice because systems do not interoperate, dead time between one person finishing and the next starting, rework caused by an error nobody caught earlier.
Decide what to fix firstWeigh impact, cost, time, customer experience and risk against implementation difficulty. Quick wins matter beyond their numbers: they build the credibility required for the harder changes later.
RedesignFewer handoffs, explicit ownership of each step, checks built in early rather than corrections appended at the end. This works materially better when the people who will run the process are in the room.
Roll out and automate selectivelyRobotic automation for repetitive rule-based tasks, workflow tooling for routing, models to flag anomalies early. The tooling should follow the redesigned process rather than determine it.
Keep measuringThe phase most often skipped, and the reason many efforts quietly unwind. Processes drift, exceptions accumulate, and new tools change what is possible.

4The four established frameworks

These are not mutually exclusive, and mature teams draw on all four depending on the process in front of them.

Framework	Core method	Best suited to
Lean	Eliminate waste; focus on what delivers customer value	Processes with visible non-value-adding steps
Six Sigma	Statistical reduction of variation and defects	High-volume processes where consistency is the issue
Business process management	Ongoing management discipline supported by BPM tooling	Processes requiring permanent governance rather than a project
Process mining	Reconstruction of behaviour from event log data	Establishing what actually happens before choosing any of the above

Table 1. Four established approaches to process improvement. Process mining differs from the other three in kind: it is a measurement method rather than an improvement philosophy, which is why it tends to precede them rather than compete with them.

Process mining surfaces findings that interviews miss, for a straightforward reason: people describe what they believe they do, which is not always what the logs record. The other three frameworks tell you what to do about a problem. Process mining tells you which problem you have.

On tooling, the categories are similarly distinct. Process mining platforms produce the picture. Workflow automation and low-code platforms shorten the distance between identifying a problem and shipping a fix. Robotic process automation handles high-volume repetitive movement between systems that were never designed to interoperate. Machine learning contributes on two fronts — predicting which cases will cause trouble later, and flagging instances behaving unlike the norm. Which combination applies depends heavily on sector: a bank redesigning loan approvals operates under audit constraints a retailer optimising fulfilment does not.

5A worked example: vendor invoices

Consider a mid-sized company handling vendor invoices. On paper: invoice arrives, is matched against a purchase order, is approved, is paid. Four steps.

In practice teams find invoices sitting for days with one specific approver, duplicate entries because two systems do not synchronise, and someone in finance chasing a missing PO number every week.

Timestamp	Activity	Elapsed	Note
02 Mar 08:40	Invoice received	—
02 Mar 09:15	Matched to purchase order	35 min
02 Mar 11:02	Sent for approval	1h 47m
09 Mar 16:28	Approved	7d 05h	single approver, no escalation configured
10 Mar 10:05	Scheduled for payment	17h 37m

Table 2. One invoice case reconstructed from event log timestamps. Over 90% of elapsed time sits in a single approval step — a distribution that is invisible in an average cycle time figure and obvious in a case-level record.

Very often a single approval step, not the workflow as a whole, accounts for most of the delay. Adding a backup approver and an automatic escalation after 48 hours reduces cycle time measurably without touching anything else.

6Measuring whether it worked

Five metrics separate genuine improvement from activity that resembles progress. All of them require a baseline captured before any change.

Cycle time. End-to-end duration, compared against the pre-change measurement.
Error and rework rate. How often work is redone because of an earlier mistake.
Cost per transaction. Particularly relevant in high-volume work such as claims or invoice handling.
Manual effort. Time spent on low-value manual tasks as a share of the total.
Customer-facing time. Response or resolution time, wherever the internal process surfaces externally.

The baseline problem

Programmes that hold up over time tie every claim back to a measurement taken before anything changed. Where the baseline was captured after work began — which is common, because the need for one becomes obvious only once results are being reported — the reported gain cannot be separated from normal variation. This is the most frequent reason an improvement claim fails under scrutiny, and it is entirely preventable at the start.

7Five recurring failure modes

Optimising a step that should be removedSometimes the correct answer is elimination rather than refinement. Worth asking before any redesign begins.
Relying on interviews alonePeople describe the process they believe they follow. System data frequently tells a different story, and the gap between the two is where the problems live.
Automating too earlyAutomate a flawed process and the flaws propagate faster and become harder to observe and reverse once encoded.
Excluding the people doing the workThey generally know precisely where the friction is. Omitting them produces a design that performs well in a presentation and fails in its first week.
Treating it as a one-time fixProcesses degrade as exceptions accumulate and workarounds become permanent. Without monitoring, last year's optimised process has already drifted back toward its original state.

Optimization is less a project with a completion date than a habit: paying attention to how work actually happens, and being willing to question steps that became tradition without anyone deciding they should. Organisations that sustain the habit tend to pull ahead of those that revisit it annually, because the gains compound rather than decay between reviews.

8Common questions

How long does a project take?

It depends heavily on the process, but a focused effort on one workflow — invoice approvals, customer onboarding — commonly runs four to twelve weeks from mapping through implementation, with monitoring continuing afterwards.

Is this only relevant for large companies?

Smaller businesses often realise gains faster, because a single inefficient process consumes a larger share of total capacity. The methods scale down; the tooling required is simply lighter.

Which sectors see the largest measurable gains?

High-volume, heavily regulated industries — banking, insurance, manufacturing — where a small percentage improvement represents material value at scale.

Where should a first project start?

With a process people already complain about, mapped as it currently runs, with the people doing the work involved. Target the two or three largest friction points rather than attempting comprehensive redesign, and measure the baseline before changing anything.