How to improve a business process
How to improve a business process: baseline the as-is, find the cause rather than the symptom, change one thing at a time, and verify the change worked before closing it out.
Improving a business process means baselining what happens now, finding the cause of the problem rather than its symptom, changing one thing, and verifying the change actually worked.
The short version
- Baseline the as-is first: you cannot show improvement against a process nobody agreed on.
- Containment stops the bleeding; it is not the fix, and should be recorded separately.
- Change one thing at a time or you will not know which change worked.
- Verify effectiveness after a defined period, against the measure you started with.
- Removing a step is an improvement. Adding an approver usually is not.
Most improvement fails at the diagnosis
Process improvement has a well-known failure mode and it is not laziness. It is diagnosing from the symptom: the invoices are late, so we add an approver; the tickets are reopened, so we add a checklist. Each of these is a plausible response to an observation and neither is grounded in why the thing happens. Six months later the metric is unchanged and the process has one more step in it, which is the actual, cumulative cost of skipping the diagnosis.
The alternative is not more analysis for its own sake. It is a specific sequence: establish what happens now in enough detail to be arguable, contain the immediate damage without pretending containment is a fix, find a cause the evidence supports, change one thing, and then check whether it worked before declaring it done. The last step is the one most often dropped, and it is the only one that distinguishes improvement from activity.
The example below is a root cause analysis process, which is the diagnostic engine underneath any improvement effort. It contains the two routes that make it honest: an insufficient-evidence branch that can close with a documented limitation rather than inventing a cause, and a verification loop that sends an unproven hypothesis back for re-analysis.
The diagnosis underneath the improvement
A root cause analysis process, from a raised problem to approved corrective actions. Watch where teams usually cut corners.
Define the problem before theorising
Describe as observed, agree a written problem statement, contain, then assemble the team. A problem statement written after someone has a theory tends to contain the theory, and the analysis then only confirms it.
Evidence, and the branch for when there is none
A sufficiency decision with three routes: proceed, extend collection, or close with a documented data limitation. That third route is what stops an investigation inventing a cause when the logs have already rotated.
Test the hypothesis, do not just pick one
Generate hypotheses, test them against the evidence, and loop back when the cause is not verified. Then separate root cause from contributing factors: a distinct step, because teams otherwise write actions against whichever factor is easiest to fix.
Actions, approved and resourced
Findings recorded, actions proposed, approval that can send them back, then a CAPA record with named owners. Improvement dies at the point where actions are agreed but nobody funded the time, which is why approval is drawn as a gate.
How it works
Baseline the process as it is
Map the as-is with the people who run it, exceptions and workarounds included, and record one or two measures: cycle time, rework rate, volume at each branch. Without a baseline that people agree with, any later claim of improvement is contestable, and it will be contested.
State the problem without a cause in it
"Invoices are paid late" is a problem. "Approvers are slow" is a theory wearing a problem's clothes, and any analysis that starts there ends there. Write the statement in terms of the observation and the measure, then let the evidence say who or what is involved.
Contain, and record it as containment
Where the problem is actively causing harm, stop it, but log it as a temporary measure with an owner and an end date. Containment that is quietly left in place becomes a permanent extra step, and it also removes the pressure to find the actual cause.
Find a cause the evidence supports
Collect data while it still exists, reconstruct the sequence, generate more than one hypothesis and test them. Stopping at the first plausible explanation is the single most common failure, and it is why the verification decision in the example loops back rather than proceeding.
Change one thing
Pick the smallest change addressing the cause, define what success looks like and by when, and implement it alone. Bundled changes make attribution impossible: when the metric moves you will not know which change to keep, and when it does not you will not know which to reverse.
Verify after a defined period, then update the map
Come back after enough cycles to see a signal and compare against the baseline. If it worked, update the process map and its approved version so the new way is the documented way. If it did not, reopen the analysis rather than adding a second change on top of the first.
Mistakes to avoid
Improving without a baseline
No agreed as-is means no way to show the change helped, and no way to notice that it did not.
Adding an approver as a fix
It is the most available response and it reliably makes the process slower without addressing why the error occurred. Most real improvements remove a step.
Bundling changes
Five changes at once produces one ambiguous result. Sequence them, even when that feels slow.
Never verifying
An improvement nobody checked is an assumption with a project plan attached. The verification step is what makes the difference between improvement and activity.
Improve your own process
Open the root cause analysis example as your own chart, or map your as-is process first and work from that.
Related guides
Frequently asked questions
How do I start improving a business process?
Map what happens now, with the people who do it, including the exceptions. Almost every improvement effort that stalls did so because it began from an assumed process rather than a documented one, and the assumed version is always the happy path. Once the as-is exists and people agree with it, the problems tend to identify themselves: unowned steps, rework loops, and handoffs where the receiver is not told are visible on the page.
What is the difference between a symptom and a root cause?
A symptom is what you observe: late invoices, reopened tickets, missed deliveries. A root cause is the thing you can remove so the symptom cannot recur. Improvement work fails when it treats the symptom, because the resulting change (another approver, another checklist) adds cost and does not affect the mechanism. The test for a root cause is whether removing it would have prevented the problem, and whether the evidence supports that rather than merely permitting it.
Do I need Lean or Six Sigma to improve a process?
No, though both offer useful vocabulary. The mechanics that matter are available without a methodology: document the current process, measure something, find a cause supported by evidence, change one thing, and verify. Formal programmes add rigour and a common language, which help at scale; they also add overhead that can exceed the value for a single process. Start with the sequence, adopt the framework if the volume of improvement work justifies it.
How do I make an improvement stick?
Update the documented process and its approved version, tell the people affected, and check again a quarter later. Changes that live only in a project report decay back within months because the documented process still describes the old way and new joiners are trained on it. The improvement is not finished when the change is made; it is finished when the map, the training and the practice all say the same thing.