How To Reduce Defects And Variation In Business Processes
Article

How To Reduce Defects And Variation In Business Processes

Published 22 Jun, 2026

The Process That Worked Last Year Is Producing Defects This Year. Here's Why That's Expected.

 

Your process wasn't broken when you built it. The problem is that you stopped treating it as something that could break.

Most operations leaders make their peace with a certain level of defects. Not because they accept failure, but because the variation feels manageable — within tolerance, within budget, within what the last audit called acceptable. And then something shifts. A product line scales. A second shift gets added. A supplier changes a component. And the defect rate that was sitting quietly at 2% becomes 6%, seemingly overnight.

It didn't happen overnight. The variation was always there. You just stopped measuring what was driving it.

The Difference Between Fixing a Defect and Fixing the Process That Created It

This is the distinction that separates organisations that improve from organisations that just react.

When a defect surfaces, the instinct is to address it at the point of failure — rework the unit, retrain the operator, tighten the inspection step. That response isn't wrong. It's just incomplete. It addresses the symptom without touching the system that produced the symptom.

The more useful question is: what in the process allowed this defect to occur, and would occur again, regardless of which operator was running it that day? That question shifts the conversation from blame to design. It forces you to look at the inputs — materials, machines, methods, measurements, environment, and people — rather than just the output that failed.

In Six Sigma language, this is the difference between special cause variation and common cause variation. Special cause variation has a specific, identifiable trigger — a machine that ran hot on a Tuesday, a batch of substandard raw material, an operator who wasn't trained on the revised procedure. Common cause variation is built into the process itself. It will produce defects predictably, at a predictable rate, until the process is redesigned. Treating common cause variation with special cause fixes is one of the most expensive habits in operations management. You end up solving the same problem twelve times a year instead of once.

Explore: Operational Excellence Training Courses

 

The Measurement Gap Most Organisations Don't Realise They Have

Before any reduction in defects or variation is possible, you need to know what you're actually measuring — and whether you're measuring it consistently.

This sounds obvious. It rarely is in practice.

A manufacturer running three shifts may find that what counts as a defect on the morning shift is handled differently on the night shift, not because of negligence, but because the inspection criteria were communicated verbally, interpreted differently, and never standardised in writing. The measurement system is itself a source of variation. If two operators measuring the same part get different readings, the problem isn't the part — it's the measurement process.

Statistical process control exists precisely to surface this. Control charts distinguish between a process that is stable but producing defects within its natural limits — which means the limits themselves need to change — and a process that is unstable, lurching in and out of control, which requires a different intervention entirely. Running a control chart for a week and then archiving it isn't process control. The chart is only useful if someone is reading it continuously and empowered to act on what it shows.

Also check: Achieving Operational Excellence in Multishift Management Course

 

What Multishift Operations Add to the Variation Problem

Process variation doesn't stay flat when you add a shift. It compounds.

Each shift transition is a handover point — and handover points are where information degrades, standards drift, and process knowledge gets informally modified by whoever is running the line that night. A setting that was adjusted three weeks ago and never updated in the official procedure becomes "how we actually do it" on the night shift. A compensating workaround that an experienced operator developed becomes invisible tribal knowledge when that operator moves to days.

The result is that a process which looks stable in aggregate is actually running as two or three slightly different processes, each producing its own variation, and the combined output masks the individual drift until the drift becomes a defect rate nobody can explain.

The organisations that manage this well do two things. They treat shift handovers as formal process events — documented, structured, and audited — not informal conversations at the locker room door. And they standardise at the level of the process step, not the level of the experienced operator. The standard should produce consistent output regardless of who is following it.

This is not a small undertaking. It requires that the people closest to the work are genuinely involved in writing the standards, not handed a document from above and told to comply. Standards written without operator input tend to describe what management thinks the process is. Standards written with operator input tend to describe what the process actually is — including the workarounds, the exceptions, and the informal adjustments that have accumulated over time.

 

Where Lean and Six Sigma Work Together — and Where They Don't

There is a common misconception in operations improvement that Lean and Six Sigma are interchangeable tools for the same problem. They are not.

Lean is primarily about eliminating waste — unnecessary steps, waiting time, overproduction, excess inventory, unnecessary motion. It works fastest when the problem is structural inefficiency: too many handoffs, too many steps that add cost but not value, too much time spent moving materials that should be positioned differently.

Six Sigma is primarily about reducing variation in processes that are already structurally sound. It works best when you have a process that is doing roughly the right things in roughly the right order, but producing inconsistent output because of variation in inputs, measurement, or execution.

The mistake is applying Lean tools to a variation problem, or applying Six Sigma tools to a waste problem. A process that has significant defects because of poor raw material consistency won't be fixed by mapping the value stream and eliminating non-value-added steps. A process that is running at low efficiency because of excessive waiting time won't be fixed by tightening specification tolerances.

Getting clear on which problem you actually have — waste or variation, or both — before choosing the methodology is the first decision, and it's frequently skipped.

Also check: Manufacturing Operational Excellence Course

 

3 Things to Do This Week

First, pick one process that is producing recurring defects and map the inputs against the DMAIC framework — Define, Measure, Analyse, Improve, Control. Don't start at Improve. Start at Measure. If your measurement system isn't validated, everything downstream is built on uncertain ground.

Second, if you run multiple shifts, audit the last three months of defect data and break it out by shift. If you see a pattern — consistently higher defect rates on specific shifts, specific days, or after specific handovers — the source of variation is almost certainly in the handover process, not in the operators themselves.

Third, audit your standard operating procedures against what your most experienced operators are actually doing. The gap between the written standard and actual practice is the map to your common cause variation. It tells you what has been informally changed, what hasn't been updated since the last process revision, and where the tribal knowledge lives that has never been captured in writing.

Defects don't persist because people aren't trying. They persist because the process is designed — or has drifted — to produce them. The organisations that understand that distinction are the ones that stop solving the same problem repeatedly. They solve it once, at the level of the system, and move on.