Process Capability Calculator — Cp, Cpk, Pp and Ppk from Raw Data

Why your Cpk and your customer’s disagree

Four reasons, in the order they actually bite. The figure names which one applies to your numbers.

Which family was quoted. NIST’s e-Handbook defines Cp and Cpk from the plain sample standard deviation and never mentions Pp or Ppk at all — so a number a textbook calls "Cpk" is what the software your customer uses calls "Ppk". Two people can quote the same arithmetic under two names and conclude they disagree.

Which within-subgroup estimator. The pooled standard deviation divided by c₄, R̄/d₂ and s̄/c₄ all estimate the same σ and all give different answers on real data, increasingly so as the subgroup grows. All three are offered here and the figure says which was used.

Whether the estimate was unbiased. The convention almost nobody states out loud is that within-subgroup sigma is unbiased by default and overall sigma is not. That asymmetry is not a mistake; it is what the incumbent does, so this tool reproduces it exactly and exposes both toggles. Turning "unbias the overall sigma" on will move your Pp and Ppk in the third digit and they will stop matching the report on your customer’s desk.

How precisely the constants were computed. A d₂ tabled at three decimals and a d₂ computed from the normal distribution differ in the fourth significant figure of the sigma. This tool computes them; the "Constant precision" option reproduces a published table’s printed value when you need to match an existing report exactly.

The two gates, before any index means anything

Stability. The special-cause tests run on your subgroup averages whether or not you asked for a control chart. Every capability index assumes the process is in a state of statistical control; on a process that is drifting or stepping, the index describes neither what happened nor what will happen, and in an audit it is worse than no number at all. If anything signals, that warning is the first thing under the figure.

Normality. Cp, Cpk, Pp and Ppk are all computed from normal tail areas. The Anderson-Darling statistic and its p-value are reported on every figure, and if normality is rejected and you have not transformed, the tool says plainly that the expected PPM is wrong by an amount nothing on the figure can tell you. Compare it against the observed PPM, which is counted rather than modelled — a large gap between the two is the fastest check there is.

Neither gate blocks the calculation. Both are printed, because a tool that silently refuses is a tool people work around, and a tool that silently proceeds is worse.

Non-normal data, and what a transformation can and cannot fix

The Box-Cox transformation finds the power λ that brings your data closest to normal, transforms the measurements and the specification limits and the target onto that scale, and recomputes every index there. The log-likelihood profile is drawn with λ̂ marked and its likelihood-ratio interval shaded, so you can see how tightly the data actually determine λ.

Two choices change the answer and are therefore printed. λ̂ by maximum likelihood is the best-fitting value; a λ rounded to 0.5 or 0 is the one you can explain to an auditor, and it gives a different Ppk. Check whether the interval on the figure covers the rounded value before preferring it — if it does, the two are not different claims about the process. And if the data are not all positive a shift constant is required; it changes λ̂ and therefore changes the capability answer, so it is reported rather than applied quietly.

A transformation cannot make one distribution out of two. If the histogram has two humps the data are a mixture — two cavities, two machines, two shifts — and no power of x will fix that. Find the mixture and analyse the streams separately.

What is on the figure, and what is deliberately not

Both index families with their confidence intervals, the expected PPM under each sigma beside the PPM actually observed, Z.bench, and Cpm when you give a target. Cpm is computed for both sigmas and labelled for each, because two published sources use two different sigmas for it — and the overall one is never abbreviated "Ppm", which on this same figure would collide with parts per million.

What is not here is a pass. The tool will say which conventional band a Cpk falls in and what the threshold is, because scorecards are written against 1.33. It will not print "PASS", because an index is one number from one sample of one period, the interval around a Cpk of 1.33 on thirty parts routinely reaches from 1.0 to 1.7, and this tool has no idea what your contract says.

Common questions

What is the difference between Cpk and Ppk?

The sigma. Cpk uses a within-subgroup estimate — the spread inside your rational subgroups, which is the process’s short-term capability. Ppk uses the overall sample standard deviation of every measurement, which includes drift between subgroups. Cpk is usually the larger of the two, and the gap between them is a measure of how much your process moves between subgroups. Both belong on a submission, and this tool prints both.

Which one does my customer want?

Usually Ppk for a submission on a new process and Cpk for ongoing monitoring, but the only reliable answer is the one written in their document. Quote both with the sigma named, which is what the figure exports, and the question stops being ambiguous.

Can I compute Cpk with a subgroup size of 1?

Yes, and this tool makes you choose how. With one observation per subgroup there is no within-subgroup variation, so the short-term sigma has to come from moving ranges — the average moving range ÷ d₂, or the median moving range ÷ d₄. They give different answers. What the tool will not do is fall back to the plain sample standard deviation, because that makes Cpk identical to Ppk and quietly answers a different question from the one on the form.

Why is my Cpk different from the one my statistical software reports?

Check the within-subgroup estimator first — pooled ÷ c₄ and R̄/d₂ differ on real data — then check whether the overall sigma is being unbiased. Those two account for nearly every disagreement. Every setting that changes the answer is printed on the figure precisely so that comparison takes a minute rather than an afternoon.

My data is not normal. Is the Cpk still valid?

No, and the tool says so on the figure rather than leaving you to discover it. The indices are computed from normal tail areas, so a skewed distribution makes the expected PPM wrong, sometimes by orders of magnitude. Either transform — Box-Cox is built in — or treat the expected PPM as unusable and read the observed one instead.

Do you support the Johnson transformation?

Not yet, and the reason is on the validation page. No public worked example printing the fitted family, its parameters and a resulting index could be found to pin an implementation against, and this project does not ship a number that reaches a customer submission through a code path nothing has ever reproduced. Box-Cox is implemented, and it is pinned to NIST’s published lambda profile.

Where can I check the numbers?

The validation page reproduces the capability analysis published with the R package qcc — nine printed values including a Cpm and two confidence intervals — and NIST’s own index formulas, recomputed at render time by the same code this tool runs. It also lists the two places where the published sources do not reproduce, and what this tool does instead.

Is my data uploaded anywhere?

No. The whole calculation runs as JavaScript in this browser tab. Capability data is part-level measurement data under a customer’s tolerance, which is exactly the kind of thing most quality agreements forbid putting into a cloud service, and nothing on this site accepts any of it.