Work keeps slipping, and you can’t say exactly where. Business process improvement fixes that: define the problem, measure it, find the root cause, test a fix, then lock the gain in.
This guide is part of our wider series on business process management, and it walks through the improvement cycle in plain steps.
| Item | Value |
|---|---|
| Common framework | DMAIC: define, measure, analyze, improve, control |
| Number of DMAIC steps | Five |
| Define step | State the business problem, goal, resources, project scope and timeline |
| Analyze step | Identify, validate and select a root cause for elimination |
| Improve step | Identify, test and implement a solution, with tests run as plan-do-check-act cycles |
| Control step | Embed the changes and ensure sustainability |
The step descriptions come from Wikipedia’s DMAIC entry. Frameworks and their wording can change, so check the source before you rely on them.
What business process improvement actually means
A process is a repeatable chain of work: an invoice is approved, an order is shipped, a request is answered. Improvement means making that chain faster, cheaper, more accurate or easier on the customer, using evidence rather than hunches.
The best-known structure is DMAIC. It is described as a data-driven improvement cycle used for optimizing and stabilizing business processes and designs, and it is the core tool of Six Sigma projects. It is not exclusive to Six Sigma, though, and you can use it as a plain framework for any improvement work.
Its aims are practical: reducing defects, errors and waste while raising efficiency, productivity and customer satisfaction, according to Quality Gurus.
Step 1: Define the problem and the goal
Most failed improvement projects fail here. A vague complaint such as “approvals are slow” cannot be fixed, while a defined problem can.
The define step is meant to state the business problem, goal, potential resources, project scope and a high-level timeline. Write these down before touching any data.
- Describe the problem in one sentence a customer would recognise.
- Name the process owner, the people who do the work and the customers of the output.
- Set the boundaries: where the process starts, where it ends, and what is out of scope.
- Agree on a target and a rough timeline.
Step 2: Measure how the process works today
You need a baseline. Without it you cannot prove that anything improved.
Start by making the current state visible. A clear picture of the steps, handoffs and waits is easiest with business process mapping, which turns a vague routine into a diagram the whole team can argue over.
Then choose a few measures that match the goal, such as:
- Cycle time from request to completion.
- Error or rework rate.
- Cost per transaction.
- Customer satisfaction or complaint volume.
If your systems log events, process mining can build these measurements from real records instead of interviews, which tends to show how work really flows rather than how people remember it.
Step 3: Analyze to find the root cause
The analyze step is about finding the cause, not the symptom. Its purpose is to identify, validate and select a root cause for elimination.
Look at where time is lost and where errors begin. Typical culprits are:
- Handoffs between teams where work waits in a queue.
- Duplicate data entry or repeated approvals.
- Unclear rules, so people escalate or guess.
- Rework caused by missing information at the start.
Ask “why” repeatedly until you reach something you can change, then check it against the data. A cause you cannot validate is only a theory.
Step 4: Improve by testing a solution small
The improve step is to identify, test and implement a solution, either in part or as a whole depending on the situation. Favour the simplest, easiest solution that removes the root cause.
Wikipedia’s description suggests testing solutions with the plan-do-check-act (PDCA) cycle. In practice that means trying the change on a small scale, such as one team or one product line, and checking the results against your baseline before you roll it out.
Before deploying, think through what could go wrong, write an implementation plan and tell the people affected. A good fix that surprises the staff who use it often gets quietly ignored.
Step 5: Control so the gains last
Processes drift back to old habits unless something holds them in place. The control step exists to embed the changes and ensure sustainability.
Useful controls are simple:
- Update procedures, checklists and training so the new way is the documented way.
- Keep tracking the same measures you used in the baseline.
- Give a named person responsibility for watching them.
- Decide in advance what result triggers a review.
When the results hold, start again with the next problem. Improvement is a loop, not a one-off project.
Who should be involved
Improvement works best as a shared effort. A small team with the right mix of people will outperform a lone analyst with a spreadsheet.
- Process owner: has the authority to change how the work is done and to approve the fix.
- People who do the work: know the workarounds, the exceptions and the real delays.
- A facilitator: keeps the project moving, records decisions and keeps the discussion tied to data.
- Customers or downstream users: tell you whether the output is actually useful.
Keep a short review point after each step. Present what you found to the owner, agree what happens next, and only then move on. This gate-style rhythm stops a project from racing ahead on a wrong assumption.
Choosing where to start
You will usually find more problems than you can fix. Choose the one that is painful, measurable and within the team’s control.
Ask a few simple questions of each candidate. Does it affect customers or revenue? Can you measure it today? Is the cause likely to be inside your own team, rather than in another company? Does the owner want it fixed?
A modest first win builds trust and gives you a template for the next project. Large, tangled processes can wait until you have practice, and they often split naturally into smaller improvements once mapped.
Common mistakes to avoid
- Skipping the baseline. Without measures you only have opinions about whether things improved.
- Automating a broken process. Software speeds up whatever it is given, including waste, so fix the flow first.
- Ignoring the people. Those who do the work usually know the real bottlenecks; involve them early.
- Declaring victory too soon. Without a control step the old habits return.
Frequently asked questions
Do I need Six Sigma to improve a process?
No. DMAIC is the core tool of Six Sigma projects, but it is not exclusive to Six Sigma and can serve as the framework for other improvement applications, per Wikipedia’s DMAIC entry.
What is the difference between DMAIC and PDCA?
DMAIC is a structured, multi-step project cycle. PDCA is a shorter plan-do-check-act loop that DMAIC’s improve step can use to test a solution before wider rollout.
Where should a first project start?
Pick a process with a clear, measurable pain, such as slow turnaround or frequent rework, and a willing owner. Define it tightly so the first run finishes and teaches you something.
How do I know the improvement worked?
Compare the same measures against your baseline, and keep tracking them after the change. If the numbers hold, the control step has done its job.
