What Is Six Sigma? A Practical Guide to DMAIC

What is Six Sigma? It is a target and a method: define what counts as a defect, measure how often it happens, find what causes the variation, remove the cause, and keep watching so the gain holds. DMAIC, short for Define, Measure, Analyse, Improve and Control, is the loop that carries that work from a problem statement to a process that stays fixed.

Six Sigma has earned its reputation, and most people who practise it are not looking for an argument about whether the method works. They want the improvement to be provable, and they want proving it to take weeks rather than a year. This guide answers that practical question: what Six Sigma is, what DMAIC does at each step, and where process intelligence makes the loop faster to run without weakening it.

What is Six Sigma?

Six Sigma is a method for reducing variation so defects become less frequent and outcomes more predictable. Where a process produces the same result in the same way, quality is easier to hold. Where similar cases end differently, that difference is what the method goes after.

Motorola developed the approach in 1986 and General Electric adopted it in the 1990s. It spread through manufacturing, healthcare, financial services and shared services because it turned “quality” into something you could count.

The name comes from the statistical symbol for standard deviation. The six sigma meaning is a performance target: when the natural spread of a process sits six standard deviations inside its specification limits, defects become rare.

Those figures are standard for the method, and they carry a warning: a defect rate is only as good as the definition of an opportunity and the completeness of the data behind it. That is why the first phase of DMAIC is about clarity, not statistics.

What does the DMAIC process look like?

DMAIC is a five-phase loop for improving an existing process. Each phase answers a different question and produces evidence the next one uses, which is what makes six sigma process improvement repeatable instead of a one-off project.

Read as a loop rather than a waterfall, the five phases are the shape of almost any improvement cycle: understand the process, measure it, explain what you measured, change something, and hold the change. The letters matter less than the discipline of not skipping a phase because it is inconvenient.

Why does documentation come before the data?

Define is where a DMAIC project is won or lost, and it is less about statistics than about clarity. Before you can measure a defect, you have to say what the process is, where it starts and ends, who owns it, and what good looks like.

Projects skip that step more often than anyone admits. The team agrees on a problem in a workshop, jumps straight to a data extract, and only then finds that the systems do not record the step everyone assumed was the bottleneck, or that three departments each describe a different process under the same name. Measurement cannot fix a process nobody has agreed on.

Documentation is the work that makes the rest of the loop possible:

• A process model that shows the steps, decisions and handoffs as the team understands them today, in BPMN 2.0 rather than on a slide.
• A defect definition tied to that model, so Measure counts the same thing Define agreed.
• Roles and ownership for the activities, so Improve has someone who can approve a change.
• The documents the work actually uses: procedures, policies, templates and screen steps attached to the activity they describe.

What ProcessMind does here is keep that documentation alive next to the model instead of in a folder that ages. Teams can draft a first version with AI-assisted process generation, refine it on the modeling canvas, attach the relevant procedure or screen step as an artifact, and move the process through review with version history. The published version is visible to the people who do the work in the Process Portal, so the process the project measures is the process everyone can see. Keeping process documentation and the model in one workspace is what stops the two from drifting apart.

What happens in each DMAIC phase?

Each phase has a defined output, and the honest version of the table also names where the work usually burns time. That last column is the one process intelligence changes.

The bottleneck in most programmes is Measure. When the baseline is built by hand it takes weeks, it samples the cases someone had time to review, and it ages before Analyse begins. That is the part of DMAIC that process mining changes.

How does process mining support DMAIC?

Process mining reconstructs how cases actually moved through a process from the event data your systems already write. A log with a case identifier, an activity and a timestamp is enough to show the real paths, the variants, the waiting time and the rework.

Because that evidence is measured rather than described, it does three specific things for the loop:

• Measure: build the baseline from every recorded case, not from a sample of the ones someone had time to review.
• Analyse: compare the variants to see where delays and rework concentrate, then test the explanations against the data instead of the loudest opinion in the room.
• Control: keep the same measurement running after the project closes, so a drift back to the old way of working shows up early.

Process mining does not replace Six Sigma, and it is no substitute for the thinking in Define or Improve. It replaces the manual collection and review that makes Measure slow and Control fragile. You can see the capability on the process mining page, or read how it reconstructs the flow in the process mining documentation. For the analysis itself, process variants and conformance checking are the two views a DMAIC team reaches for first.

How do process analytics and dashboards sustain the gain?

The Control phase is where improvement dies quietly. A change that is not measured after the project ends is a change nobody can defend, and a dashboard nobody opens is not a control.

Process analytics turn measurement into something a process owner can act on: cycle time and defect trends against the baseline, conformance against the documented model, and thresholds that say when a number needs attention rather than just reporting it. In ProcessMind, bookmarks hold the filters and measures of a review, process health gives each indicator a reference range, and dashboards and KPIs put the result where the owner will see it. The custom dashboards documentation covers how those views are built.

The test is the one a belt would apply to any control chart: can the owner tell, from this view and this threshold, whether the process has changed since last month? If not, the Control phase is a document rather than a control.

What do the Six Sigma belt roles mean?

Belt names describe roles in a Six Sigma programme, and they are a useful shorthand for who can lead which project. Responsibilities vary between organisations, but they commonly break down like this:

• Champion or sponsor: the manager who secures resources and clears obstacles.
• Master Black Belt: an experienced practitioner who coaches project teams and guards the method.
• Black Belt: a project lead who runs the DMAIC work.
• Green Belt: a practitioner who leads a project alongside a day job, often inside one department.
• Yellow or White Belt: a team member who contributes process knowledge or data.

Nothing in a data-driven DMAIC loop depends on the colour of a belt. A project needs a process owner who can approve a change, someone who can read the evidence, and a team willing to look at the measurements honestly. A title is a proxy for that; the work is the work.

How are Lean and Six Sigma different?

Lean and Six Sigma answer different questions, and most of the confusion between them is a naming problem.

• Lean removes waste and improves flow. It looks at waiting, handoffs, over-processing, inventory, motion and defects in the flow of work.
• Six Sigma reduces variation and defects. It uses measurement and analysis to understand why two similar cases end differently.

Lean Six Sigma, also written lean 6 sigma, combines the two: lean to make the work flow, Six Sigma to make the result predictable. Confusingly, “lean and six sigma” and “six sigma and lean six sigma” are often spoken of as separate methods, when they describe the same combination and the order you apply it in depends on the problem. A process that is slow but stable needs lean thinking first. A process that is fast but inconsistent needs the variation work first. The value stream mapping guide covers the lean side, and the list of process improvement techniques compares both with process mining and simulation.

Why is DMAIC the flywheel we build around?

Because the loop is the reusable part. The belts, the statistics and the project charters all serve a cycle any team can run on any process, and every turn of that cycle makes the next one cheaper.

Our view is not that Six Sigma is the only way to improve a process, and it is not that the method needs defending. It is that DMAIC is the flywheel, and the tools should turn it faster.

That is the shape of the platform: not a bet against Six Sigma, but a bet that the loop is what teams actually need, and that the measurement inside it should come from data the organisation already has. It is also why the Lean Six Sigma and DMAIC guide puts a data artefact under every phase.

When is Six Sigma not the right fit?

Six Sigma is at its best when you can define a defect, measure it reliably, and find enough variation to be worth reducing. That is a real fit in high-volume, repetitive processes and in industries where the quality bar is set by regulation. It is a poorer fit when the main problem is flow rather than variation, when the process is new, or when the data is not there yet.

None of that is a reason to abandon DMAIC. The loop still applies: define the problem, measure what you can, look for causes, change something, hold the change. What changes is how much statistical machinery you add. A team improving onboarding, a sales pipeline or a service desk may never need a design of experiments; a team reducing defects on a production line almost certainly will. If the process is new rather than broken, Design for Six Sigma (DMADV) is the variant to look at. If the problem is waiting rather than variation, lean tools will get you further.

How can you start a Six Sigma project?

The fastest start is the one that produces evidence in weeks rather than months.

1. Write down what the process is

   Name the start, the end, the owner and the defect you care about. A model is a better place to argue about the process than a meeting is.

2. Find the data before the sample

   Check whether your systems already record a case identifier, an activity and a timestamp for this process. If they do, Measure starts from the log.

3. Measure the real flow, variants included

   Count the cases that take the unexpected path. Variation is the subject, and averaging it away hides the reason you are here.

4. Test one change at a time

   Use a simulation to compare options before rollout, then pilot the one the evidence supports and measure what changed.

5. Hand control to an owner

   Put the baseline, the measure and the threshold where the process owner works, and stop when a review confirms the gain held.

The principle underneath all of it is unchanged from the first Six Sigma project: measure a process before you decide how to improve it. What has changed is that the measurement no longer has to be manual. For the full method, read the data-driven DMAIC guide, and for the monitoring half, see how to continuously monitor your process.