Statistical process control does not change when you point it at live data. Statistical process control (SPC) is the practice of plotting a measurement over time against limits the process itself produced, and reacting only when the pattern says something real happened; the math is what Walter Shewhart wrote down at Bell Labs in the 1920s. What changes is when you find out. On paper, the chart is a record of a shift that already ended. Against a live stream, the chart is a check that runs on every point, so you can act during the run instead of after it. A quality tech I worked with printed her charts at six every morning and taped them to the post beside the filler. She read them better than anyone in the building. She could tell you which points had gone out and roughly what the line was doing when they did. What she could not do was tell anyone before the pallets shipped. Her chart was accurate and it was late, and a late chart cannot change what already shipped. What statistical process control actually measures Two sets of limits get confused constantly, and the confusion is where most charts go wrong. Specification limits come from outside the process. The customer, the drawing, the recipe. They answer one question: will this part be accepted. Control limits come from inside the process. You compute them from the process’s own data, conventionally three standard deviations either side of the centre line. They answer a different question: is this process still behaving the way it behaves when nothing is wrong. The two have almost nothing to do with each other. A line can run dead centre inside spec and be badly out of control, drifting in a way that will put it outside spec next Tuesday. A line can be perfectly in control and still make parts nobody will buy, because the process is stable at the wrong place. The first question anyone asks when a chart goes on a live feed is why not just use the spec as the limits. Because then the chart only ever tells you what you already knew, that a part failed, and never tells you the thing you are paying it for, that the process changed. That distinction carries the other half of the discipline. Variation the process produces all the time, with no specific event behind it, is common cause. Variation with a findable event behind it is special cause. Chasing common cause makes things worse: every time an operator nudges a setpoint because one reading looked high, they add their correction on top of the noise, and the spread gets wider. The chart exists to tell people when not to touch it. What changes when you run SPC on live data Three things change when statistical process control runs against live data, and only the first is the one people expect. The time from detection to correction gets shorter. That gap is the only one worth shortening. A daily chart caps that interval at a day no matter how good the analysis is. A live chart makes it minutes, which is the difference between adjusting a run and dispositioning it. You have to choose subgroups on purpose. On paper you measured five parts an hour because somebody had to walk out and get them. With a live feed you have every part, every cycle, every head. If you throw the whole stream into one subgroup, the within-group variation collapses, the limits tighten to nothing, and every point becomes a violation. Rational subgroups still have to be chosen by a person who knows how the process actually varies: by head, by cavity, by lot, by shift. In a plant, that grouping is the difference between a chart that finds a bad cavity and one that only shows the line ran a lot that morning. The stream gives you data. It does not give you the grouping, and the grouping is the part a person has to decide. You are running the rules hundreds of times a shift. One chart with the standard run rules is quiet. Forty charts, each running the standard set of run rules, on every point, all shift, produce more alerts than anyone can read. Nobody told the paper chart to check itself two hundred times an hour. Two ways real-time SPC fails The first is alarm flooding, and within a month people stop looking at the chart. The fix is not fewer rules. It is routing. One point beyond three sigma on a critical characteristic pages the operator now. Seven points in a row on one side of the centre line describes a drift that has been building for hours, so it belongs in the shift lead’s queue rather than in an alarm. A pattern that persists across three shifts is an engineering problem and belongs in the weekly review with the data attached. Same chart, three audiences, three speeds. The second failure is harder to notice and worse. Limits that recalculate themselves. It feels responsible to keep the limits current on a rolling window, and every automated charting setup I have seen offers it as a default. Do not use it. Limits computed on a moving window widen to make room for whatever the process is doing, including the slow drift you built the chart to catch. A chart that recomputes its own limits every night will eventually certify any process as stable. Establish limits on a period when the process was behaving, write down the date and the reason on the chart itself, and recompute only when something real changed: new tooling, a different supplier lot, a rebuilt machine. Four questions to ask about any control chart on your floor This takes twenty minutes and one chart. Pick the one people look at most. Where did these limits come from, and when? You want a date and a reason. If the answer is that they came with the system, or that they update themselves, you are looking at a description of the last thirty days rather than a test against a period when the process was behaving. What is one point? A part, an hour, five parts pulled across three heads? If nobody can answer, nobody can tell whether a signal is about the process or about how the samples were taken. Who is told when a rule fires, and how quickly? Name the person and the number of minutes. A signal that reaches nobody is a log entry. What happened the last three times it fired? This is the question that shows whether the chart is controlling anything or only recording. If the answer is that it fired, and nobody can say what was found or what was done, the chart is not changing anything. Question four is the uncomfortable one, and it is the one worth taking to your next quality meeting. Most operations can produce the chart. Far fewer can produce the record of what the chart caused. What a live chart is worth A signal is only half of a decision. The other half is knowing what this pattern meant the last four times it appeared on this line, and what the person on shift did about it. That record is usually in somebody’s head, and it retires when they do. Your process produces a signal on every cycle, and it always has. The math for reading that signal has been settled for a hundred years. The open question was never whether the signal is there. It is whether anyone sees it while the run can still be fixed. This week: Pick one control chart on one line and find out where its limits came from, what one plotted point represents, and what happened the last three times a rule fired.