I am going to make a prediction. If you manufacture anything, you probably have SPC charts somewhere in your plant. They are either on paper, pinned to a board near the machine, or on a screen that nobody looks at. The operators fill them in because the procedure says they have to. The quality engineer reviews them once a week, signs the bottom, and files them. The auditor looks at the signed charts and checks the box that says "SPC is implemented." Everyone is satisfied. Nobody is controlling anything.

I have audited SPC implementations in over forty plants. In about 80% of cases, what I see is not statistical process control. It is statistical process documentation. The charts exist, the data is recorded, the calculations are performed, and the output is filed. What is missing is the part that makes SPC actually work: the control.

What SPC is actually for

SPC was invented by Walter Shewhart in the 1920s at Western Electric. His insight was simple and profound: a process has two kinds of variation — common cause variation, which is inherent to the process and can only be reduced by changing the process itself, and special cause variation, which is caused by a specific, identifiable factor and can be eliminated by finding and removing the cause.

The control chart is a tool for distinguishing between the two. When a point falls outside the control limits, or when a non-random pattern appears, it signals a special cause. The operator investigates, finds the cause, removes it, and the process returns to its normal state. This is process control — not monitoring, not documentation, but active intervention to maintain stability.

The entire system depends on one thing: the response to the signal. If the signal triggers no response, the chart is decoration. And in most factories I have audited, the signal triggers no response.

A control chart without an out-of-control response procedure is not a control chart. It is a history chart. It tells you what happened. It does not control anything.

The chart nobody reads

In one aerospace machining plant, I found a control chart for a critical bore diameter that had been in use for three years. The chart showed the last thirty subgroups. Twelve of the thirty points were outside the control limits. The operator had dutifully plotted every point, initialled every entry, and noted the time and material lot. Nobody had responded to any of the twelve out-of-control points.

I asked the operator what they do when a point falls outside the control limits. "I write it on the chart," they said. I asked the shift supervisor. "I review the charts at the end of the shift," they said. I asked the quality engineer. "I check them every Monday," they said. I asked the quality manager. "The auditor checks them during the surveillance audit," they said.

The chart had twelve signals — twelve opportunities to detect a special cause and eliminate it. Twelve opportunities were missed. The process had been producing out-of-control parts for at least the last thirty subgroups, and the information was right there, in ink, initialled and filed.

The over-control problem

The opposite problem is equally common and equally damaging. In some plants, operators respond to every point as if it were a special cause. A point moves up slightly — still within control limits, still consistent with common cause variation — and the operator adjusts the machine to bring it back to target. Then the next point moves down — also within control limits — and they adjust again.

This is called over-control, and it actually increases variation. The process was stable. The operator's adjustments made it unstable. The chart looks like a sawtooth pattern, and the operator feels busy and productive, believing they are "keeping the process on target." In reality, they are injecting variation that would not exist if they did nothing.

Shewhart's insight was that you should only respond to special cause signals. Reacting to common cause variation is a mistake. It is the statistical equivalent of a doctor prescribing antibiotics for a viral infection — the treatment makes the patient worse, not better.

What real process control looks like

Real process control — SPC as it was meant to be used — looks like this:

The operator plots the point. If the point is within control limits and the pattern is random, the operator does nothing. The process is stable. If the point is outside control limits, or if a non-random pattern appears (a run of seven points on one side of the centre line, a trend of six consecutive increasing or decreasing points, or any of the Western Electric rules), the operator stops.

They do not adjust the machine. They investigate. They check the material lot, the tool condition, the machine settings, the ambient temperature, the fixture, the coolant. They look for something that changed. If they find it, they correct it. If they do not find it, they call the quality engineer. The investigation is documented — not as paperwork, but as a problem-solving exercise. The root cause is identified, the corrective action is implemented, and the process returns to stability.

The entire cycle — from signal to resolution — takes minutes, not days. The operator has the authority to stop the process. The quality engineer has the authority to escalate. The system is designed for speed because the cost of an out-of-control process compounds with every part produced.

The capability question

Once the process is stable — once special causes are being detected and eliminated promptly — the next question is capability. Is the common cause variation small enough that the process consistently produces within specification?

This is measured by the capability indices — Cp, Cpk, Pp, Ppk. A Cpk of 1.33 means the process is capable. Below 1.33, the process will produce nonconforming parts at a predictable rate. I have seen plants where the Cpk was 0.8 and the scrap rate was 0%. How? Because the nonconforming parts were being reworked, not reported. The capability index said the process was incapable. The quality report said everything was fine. The truth was in the rework cost, which nobody had connected to the capability data.

Improving capability requires reducing common cause variation, and this means changing the process — new tooling, better maintenance, improved fixtures, tighter material specifications, environmental controls. These are engineering investments, not operator adjustments. And this is why so many SPC programmes stall: they identify the need for process improvement, but the organisation is not willing to invest in the improvement. The chart shows the problem. The budget does not fund the solution.

How to fix your SPC programme

If your SPC charts are decoration, here is how to make them work:

— Pick the right characteristics. Do not chart everything. Chart the characteristics that matter — critical-to-quality dimensions, safety-related parameters, customer-reported issues. Ten characteristics with real control are worth more than a hundred characteristics with paperwork.

— Train operators to respond. Not just how to plot points. How to recognise out-of-control signals. What to check first. When to stop the process. When to call for help. The response is the skill; the plotting is mechanics.

— Define the escalation path. Operator finds signal. Operator investigates for five minutes. If no root cause, shift leader investigates for ten minutes. If still no root cause, quality engineer investigates. The clock starts at the signal and the resolution comes within the shift.

— Measure response time. Track the time from out-of-control signal to resolution. If it is more than one shift, your SPC programme is not controlling the process. It is documenting it.

— Review capability quarterly. If Cpk is below 1.33 on any critical characteristic, there should be an improvement project. If there is no project, the organisation has accepted the variation. That acceptance should be a conscious decision, not a default.

— Audit the response, not the chart. When you audit SPC, do not check whether the charts are filled in. Check whether out-of-control points were investigated. Check whether the investigation found a root cause. Check whether the corrective action was implemented. The chart is evidence. The action is the system.

The bottom line

SPC is not a compliance requirement. It is a process control tool. If your charts are not driving action on the shop floor — stopping processes, triggering investigations, identifying root causes, and improving capability — they are not doing their job. And the cost of that failure is not just the time spent plotting points. It is the defects you could have prevented, the rework you could have avoided, and the customer complaints that would never have happened if someone had read the chart and responded.

Shewhart gave us the tool a hundred years ago. The tool works. The question is whether you are using it — or just decorating your walls with it.