Business process improvement techniques provide different ways to understand and change how work gets done. Lean examines waste and flow, Six Sigma examines variation, process mining examines recorded events, and reengineering considers a broader redesign. Choose the method from the problem and available evidence.
This guide preserves ten techniques, with a suitable starting point and an original illustrative example for each. The examples demonstrate how to use the methods; they are not reported business results or promised improvements.
Compare the ten techniques before choosing one
| Technique | Purpose to investigate | First useful artifact |
|---|---|---|
| Lean / Lean Six Sigma | Waste, flow and customer value. | Observed process and waste hypotheses. |
| Business Process Reengineering | A process requiring a fundamental redesign. | Outcome, constraints and alternative design. |
| Six Sigma | Variation and measurable quality problems. | DMAIC charter and trustworthy baseline. |
| Kaizen | Ongoing improvement involving the people doing the work. | Small change, review and updated standard. |
| Value Stream Mapping | End-to-end material and information flow. | Current-state and future-state maps. |
| 5S | Finding, using and maintaining work resources. | Shared organization standard. |
| Process Mining | Observed paths in suitable event logs. | Event dataset with definitions and quality checks. |
| Theory of Constraints | The constraint limiting the system’s goal. | Constraint evidence and focused action plan. |
| Root Cause Analysis | Causes and contributing factors behind a problem. | Evidence-backed causal hypotheses. |
| Agile Process Improvement | Iterative changes with feedback and adaptation. | Prioritized experiment backlog and review. |
These methods overlap. A value stream map can inform a Lean initiative; root cause analysis can sit inside DMAIC. The table is a selection aid, not a ranking of returns or implementation complexity. Define the process boundary, customer outcome, owner and evidence before choosing.
1. Lean Manufacturing and Lean Six Sigma
Lean focuses on customer value and the flow of work, including removing avoidable waste. The Lean Enterprise Institute’s principles connect value, the value stream, flow, pull and ongoing improvement. Lean Six Sigma combines this focus with variation-reduction methods.
Use it when: The process contains repeated entry, waiting, excess work in progress or unnecessary movement between teams. Observe the work with people who perform it and ask which activities contribute to the intended outcome.
Illustrative example: A purchasing request is copied into two trackers. Verify whether both records are necessary, identify who uses them and test a single authoritative entry with appropriate access. Review errors and total effort, including any work moved to another team.
Some checks support required controls even if they do not directly create customer value. Preserve their purpose while considering a better design. Select a bounded change and review the end-to-end effect.
2. Business Process Reengineering
BPR considers fundamental redesign instead of only accelerating existing tasks. Michael Hammer’s original article challenges automation of outdated ways of working.
Use it when: Evidence suggests the current structure cannot deliver the required outcome through local adjustments. Establish the desired service, important constraints and the authority needed for redesign.
Illustrative example: An account-opening request passes through separate teams that repeatedly request the same documents. A redesign proposal could establish one case owner and a shared evidence record while retaining required specialist decisions. Test the proposed journey, exception route and access controls before broad rollout.
Include leadership sponsorship, staff involvement, transition planning and a way to handle in-flight work. Assess operational disruption and required resources as well as the intended outcome. Redesign is a choice to evaluate, not an automatic route to dramatic savings.
3. Six Sigma
Six Sigma uses disciplined analysis to address process variation and quality problems. ASQ distinguishes variation reduction from Lean’s waste focus. Use trained analytical support appropriate to the problem and available data.
Use it when: You can define a defect or quality requirement and measure a recurring process reliably. Check measurement quality before interpreting variation.
The DMAIC framework covers Define, Measure, Analyze, Improve and Control: scope the problem, establish a trustworthy baseline, examine causes, evaluate changes and maintain a reaction plan.
Illustrative example: Invoices are returned because required fields are missing. Define which invoices and fields qualify, count affected invoices rather than every missing-field event as a separate invoice, and investigate where the information is lost. Pilot a suitable change and review quality over a stated period.
A headline defect rate alone does not establish process capability or prove the cause. Keep specifications, denominators and control arrangements explicit; avoid borrowing another company’s savings as a forecast.
4. Kaizen and continuous improvement
Kaizen supports ongoing improvement involving the people doing the work. The Lean Enterprise Institute’s guidance connects small changes, review and updated standardized work.
Use it when: A team can improve recurring work through bounded experiments and maintain what it learns. Make suggestions easy to submit and give them an owner, response and review.
Illustrative example: Staff repeatedly interpret a handoff checklist differently. Agree on a clearer wording, try it in a defined group of cases, review misunderstandings and update the standard if the change helps.
Give staff time and decision support. A suggestion count or number of workshops is activity, not an outcome. Keep useful learning from changes that do not work, and check that adopted improvements remain in practice. For support-focused applications, see our continuous improvement examples.
5. Value Stream Mapping
VSM examines the steps and material or information flow needed to deliver value. The Lean Enterprise Institute describes current-state and future-state mapping as a way to understand the actual flow and a proposed target.
Use it when: Multiple teams optimize their own tasks while the overall journey still takes too long. Observe the process and include queues, handoffs, information requirements and relevant quality checks.
Illustrative example: Map an order from receipt through fulfillment. Record processing and waiting separately; examine whether a batch release creates a queue before packing. Propose a future-state flow and identify the dependencies needed to test it.
Check the map against real cases and exceptions. An attractive diagram is not evidence that a proposed state will work. Assign delivery ownership and measure end-to-end outcomes, rather than only making one activity faster.
6. 5S workplace organization
5S organizes work resources through sorting, arranging, cleaning, standardizing and sustaining. It can be applied to physical spaces and adapted thoughtfully to digital work.
Use it when: People struggle to find the correct tool, document or current instruction. Involve the people using the space in setting the standard.
Illustrative example: A shared operations folder contains duplicate procedure files. Identify authoritative versions, arrange them by task, correct broken links, assign owners and review dates, and check whether colleagues can find the applicable instruction.
Archive or remove records only through the appropriate retention and access rules. A neat folder that loses required evidence is not an improvement. Use follow-up checks to maintain usefulness rather than treating cleanup photos or file counts as success.
7. Process mining
Process mining examines event logs to discover recorded paths, compare them with a model or investigate performance. The primary Process Mining Manifesto describes events linked to a case and activity, with additional information such as timestamps where available.
Use it when: Suitable system records cover the process question. Define case IDs, activities and event meaning; for timing questions, check timestamp completeness, time zones and ordering.
Here is an original illustrative log:
case_id,activity,event_time_utc EX-17,request_created,2026-10-01T09:00:00Z EX-17,review_started,2026-10-01T10:00:00Z EX-17,review_completed,2026-10-01T10:15:00Z
The records show 60 minutes between creation and review start, then 15 elapsed minutes until completion. They do not establish active work time or why the request waited.
Check missing events, duplicate records, manual work outside the system and the effect of multiple objects linked to one case. Review inferred paths with process owners. A discovered deviation may be a valid exception; event order does not establish causation.
8. Theory of Constraints
TOC focuses improvement on what limits the system’s goal. The five focusing steps are to identify the constraint, make better use of it, align other work to it, expand its capability when needed, and reassess as conditions change.
Use it when: Increasing local output fails to improve completed work across the whole process. Investigate capacity, demand, policies and queues instead of assuming the longest task is always the constraint.
Illustrative example: Three serial stages have capacities of 12, 6 and 10 items per hour. With sufficient demand and inputs, no rework and no other limitation, steady output cannot exceed 6 items per hour. Making the first stage faster does not raise that bound.
Inspect what interrupts the limiting stage and what upstream work it actually needs. Align release and preparation appropriately, preserve breaks and quality controls, and evaluate additional capacity only after the evidence supports it. Recheck the constraint after a change.
9. Root Cause Analysis
RCA investigates causes and contributing factors behind a defined problem. ASQ describes several evidence-based approaches, including event timelines, change analysis and examination of controls.
Use it when: A problem recurs or its cause is uncertain. Define what happened, when, where and under which conditions. Involve people who understand the work and those able to implement a corrective action.
Illustrative example: A shipment receives the wrong label. Build the sequence from records and observations, compare successful cases, and test whether a data mapping or workflow change contributed. Use a fishbone diagram or repeated “why” questions to generate hypotheses, then verify them.
Five questions do not guarantee one final cause. Separate evidence from assumptions, examine interacting factors and focus on systems rather than blame. Analysis needs an owned corrective action and later review of recurrence to become an improvement.
10. Agile process improvement
Agile process improvement adapts iterative delivery, feedback and reflection to operational changes. The Agile Manifesto principles originate in software development; applying them to other business work is an adaptation, not a single mandated method.
Use it when: The team can test bounded changes, learn from the result and adjust the next step. Maintain a prioritized backlog with an owner and an outcome for each experiment.
Illustrative example: Test a simpler request form with a defined audience. Review whether submissions contain the information needed for the next step, inspect problems and revise the form before expanding it.
Use a short, suitable cycle and a retrospective to decide what to keep, revise or stop. A two-week cycle is one option, not a requirement for every process. Preserve necessary approvals, quality checks and sustainable workload. Delivered changes count as activity until the customer or operational outcome is assessed.
Choose a method and turn it into owned work
Start from a defined problem. Use observation or mapping when the actual process is unclear; investigate causes when explanations are uncertain; evaluate broader redesign when local adjustments cannot meet the need. Combine tools when their purposes fit, while retaining one clear improvement owner.
Process improvement charter Process boundary, customer and intended outcome: Observed problem, sources and uncertainty: Selected method and reason: Baseline unit, denominator, timing and case mix: Proposed change, owner and resources: Dependencies, required controls and stopping conditions: Outcome, quality and capacity checks: Pilot/comparison approach and attribution limits: Review date, decision and maintenance owner:
Technology should serve the selected change. A suitable event-analysis tool can support process mining; a shared worksheet can hold an experiment backlog. For a support-specific communication bottleneck, first establish what information is missing and choose a suitable format. See agent productivity for that narrower workflow.
Compare relevant cases, account for other changes and include maintenance effort. Record whether the outcome improved and whether work or risk shifted elsewhere. Adopt a useful change with an updated standard and a review owner; revise or stop a change whose evidence does not support expansion.
