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.
A worked example, stage by stage
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.
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.