My capability data fails normality, what do I do?
A failed normality test does not mean bad parts. Standard Cpk assumes a bell curve, and flatness, position and runout are non-normal by nature. How to tell an inherent shape from an unstable process, and what to do about each.
An engineer runs a capability study on a flatness callout, pulls a clean set of readings straight off a good process, and the software hands back a Ppk of 0.7 with a normality test that fails hard. The parts are fine. Every one of them sits comfortably inside the tolerance. So why does the capability number read like the process is in trouble? Nothing is wrong with the parts or the gauge. The trouble is that the standard capability formula was built for a bell curve, and a flatness value has no business being one.
The bell curve is doing more work than you think
Standard Cp, Cpk, Pp and Ppk all lean on one quiet assumption, that the data follows a normal distribution. The index takes the process spread and compares it to the tolerance, and to turn that spread into a defect rate it assumes the readings pile up symmetrically around the average and thin out evenly on both sides. When that is true, the maths is honest. When it is not, the formula still returns a number, it just returns the wrong one. A distribution with a hard floor at zero and a long tail on one side, which is exactly what flatness, roundness, position and runout look like, gets read by the formula as a wide, badly centred process, because the tail drags the calculated spread out. The number is not lying about the data. It is answering a question about a bell curve you never had.
Before you decide the data is non-normal, rule these out
- An unstable process. A special cause moving the average around during the study makes the data look non-normal when the real problem is that it is not one process but several taking turns. Check stability on a control chart first, because a transform will not fix an out-of-control process, it will only hide it.
- Mixed streams. Two cavities, two spindles or two shifts pooled into one dataset can show up as a lumpy, non-normal shape. Separate them and each stream may be perfectly normal.
- A resolution problem. A gauge reading to too few decimal places stacks the data onto a handful of values and fails normality for a reason that has nothing to do with the process.
- Too few readings. Small samples pass and fail normality tests almost at random, so a fail on thirty points is not the same evidence as a fail on three hundred.
Some characteristics are non-normal on purpose
Once you have ruled out the impostors, you are often left with a distribution that is non-normal because the characteristic itself cannot be anything else. Flatness, position, roundness, perpendicularity and total runout are all bounded at zero and can only run one way from there, so a healthy process bunches up near zero with a tail reaching out toward the tolerance. That is not a defect to be corrected, it is the natural shape of the measurement. Forcing a normal-based Cpk onto it and then chasing the ugly number is how teams end up reworking a process that was fine all along. The honest move is to recognise the shape, not to fight it.
What to actually do about it
There are two defensible roads once you know the non-normality is real and inherent. One is to transform the data, most commonly with a Box-Cox transformation, which stretches the scale so the readings become approximately normal, then compute capability on the transformed values against transformed limits. The other is to drop the normal assumption entirely and use a non-normal capability method, fitting a distribution that suits the characteristic, often a Weibull, and reading capability from its actual percentiles rather than from three sigmas of a bell curve. Both give a capability number that means something for that characteristic. What matters is that you choose the method deliberately and record which one you used and why, because an auditor who knows their statistics will ask, and a Ppk with no note about how a bounded characteristic was handled invites exactly that question.
Keep the readings honest enough to investigate
None of this is possible if the capability number is all you kept. The moment you need to ask whether a fail is instability, mixed streams or an honest bounded shape, you need the individual readings, in order, with the characteristic, the gauge, the part revision and the specification limits still attached. That is the context a spreadsheet quietly loses, and the reason a bare index cannot be interrogated after the fact. The free Cp, Cpk, Pp and Ppk calculator gives you the standard indices as a first read, useful precisely because a number that disagrees with the parts in front of you is the prompt to go and look at the distribution. In VoraControl, capture stays tied to the released characteristic and its limits, so the readings behind any capability figure are still there to examine rather than summarised away.
A failed normality test is a prompt to investigate, not a verdict on the parts. Confirm the process is stable, split any mixed streams, and only then decide whether the shape is inherent to the characteristic. If it is, transform the data or use a non-normal method on purpose, write down which you chose, and stop chasing a bell-curve number the characteristic was never going to give you.
Released control plans, inspection capture and SPC trends in one governed flow.
Talk to someone who understands manufacturing control and audit evidence. We do not do generic demos.