August 24, 2007
True Process Control (Quality Insider)
by Douglas C. Fair
Just weeks after earning my industrial statistics degree, I hired on with a major aerospace company. It was my first "real job" and it entailed working with engineers and operators to deploy Statistical Process Control (SPC) in a large machine shop. However, I quickly found out that the warm, coddling confines of a university classroom had done little to prepare me for the complexities of a short-run, aerospace SPC deployment. Instead, I found myself confronted with a bewildering array of different machines, jigs, tooling aids, part numbers, and union rules. As a newly hired statistician, I was stunned to find that the aerospace world lacked a similarity to anything I had read in my statistical texts. Although I worked in this facility over 20 years ago, I remember a great deal about my experience because that shop floor taught me the practical applications of SPC.
The first thing I learned was very clear: traditional Xbar and Range control charts do not work in a high-mix, low-volume environment. Too bad, especially since that was what I studied in school. Instead, we learned to apply control charts which were process-specific. Rather create a separate control chart for each part/feature we measured, we had control charts that were unique to the machine and feature we were trying to control. Each of these machine-centric control charts showed how the process changed through time and across many part numbers. And believe me—it wasn't easy, especially since we were using paper and pencil. Even if each part had different engineering specifications, we placed them on the same chart. Doing this required that we apply data normalization techniques to account for the different specifications. Normalization is crucial for using true process control charts.
And when I mention true process control, I am not referring to the control of process-specific parameters such as speeds, feeds and temperatures. Those parameters are fairly straightforward: create a control chart for temperatures and see how they vary throughout the day or week. Instead, I want to focus this column on the complex practice of applying a process control chart that displays data across different parts with different engineering specifications.
Suppose we wish to use SPC at a lathe. The lathe is used to turn and cut stainless steel shafts. On each shaft we measure Outside Diameters (OD's) in three different important locations - OD Location A, OD Location B and OD Location C. Our shaft part numbers are generically identified by their color (such as Blue Part, Yellow Part or Green Part). Outside Diameters measured on each part at the same location have different target values from one colored part to the next. While each part's engineering target value is different, the tolerance of +/- .005" is identical.
Here is a summary of our example:
- A machine (Lathe 167) is the process we wish to control.
- A part feature (OD - Loc B) is common to our parts.
- Two different parts (Blue Part and Yellow Part) have been run on Lathe 167. Both parts are similar in configuration but have different target values for OD - Location B.
The chart's subgroup data values are displayed in time-order, while the part manufacturing sequence is highlighted with vertical blue lines (the Blue Part was made first, then the Yellow Part, then the Blue Part once again).
Figure 1's plotted data values have been normalized on the Xbar chart as Deviation from Target. That is, if the subgroup average for OD Location B was, say, 2.7497 and its target was 2.7500, then the value which is plotted on the Xbar chart is -0.0003 (2.7497 - 2.7500).
There is no normalization applied to Range values. The mathematical formula for Deviation From Target normalization follows:
Plotted Value = (Subgroup Average - Target)
By using this simple normalization technique, one can plot parts with different target values on the same chart. However, simple is not always correct.
You see, there is a catch. Isn't there always? Sometimes normalization techniques cannot be used for creating common control limits. When standard deviations are significantly different between parts, control limits cannot be shared. In Figure 1, notice that the control limits for the Yellow part look closer together on the Xbar chart as compared with the Blue part. This has happened because the average Range for the Yellow Part is much lower than the Blue Part. This is an indication that the Yellow Part has less variability. Is the variability significantly less? Yes, as confirmed by the Kruskal-Wallis non-parametric test for differences in variability.
Because the variability is significantly different, common, identical control limits cannot be used across parts. So what can be done? Well, we need a more robust means of normalizing the data such that the control limits can be shared. Calculating and plotting Z-values is a wonderful way of managing different standard deviations between parts. In fact, even if means, standard deviations and/or specification limits are different from part to part, Z-values can be used for fair comparisons between those parts. They also result in common control limits and give us what we really want: a control chart for assessing true process control.
An Xbar chart's Z-value plot points are the distance from a part's overall mean, expressed in standard deviations. The mathematical formula for calculating the Xbar chart's Z-values should be based upon each part's unique mean and standard deviation:
Plotted Z-value = (Xbar - Mean)/Standard Deviation
Figure 2 shows that the control limits are identical between the two different part numbers. Note that, like any Shewhart control chart, control limits are set at +/- 3 standard deviations. The Z-value control limits are actually +/- 3.0000, making it very simple to determine if a plotted value falls outside of the control limits. Since the plotted values have been converted to standard deviations, this common scale can accommodate any feature, or part, no matter how statistically different they might be. The Z-value normalization is very handy in a short-run situation, or, as in our case, if you just want to assess the consistency of your machine regardless of the parts it makes.
Enlarge this picture
Figure 2 is a display of the same data set as Figure 1, however, plot points have been normalized using the Z-value transformation.
Finally, here are some "watch-outs." If you choose to use normalization procedures for assessing true process control, make certain your software can:
- Display unique control limits for each part on the chart. This will help to highlight whether or not the variability or means are different by part.
- Determine if the variability is significantly different from part to part. This will help to identify the proper normalization technique.
- Change normalization techniques on-the-fly. There are many normalization techniques that can be used. Make sure that various techniques are available and that they can be changed and applied to pre-existing data at any time.
- Modify the normalization technique even after data have been collected. Some software products require you to know how the data is to be normalized before data collection occurs. Because the use of a particular normalization technique is typically based upon empirical evidence, you might not know which normalization is best in the beginning. Instead, collect some data to learn what you are up against. Then, change the normalization to suit your unique situation. The bottom line is, make certain the normalization technique can be modified at any time even after data have been collected. Otherwise, if you guess wrong, you might have to start over.
If you want to apply true process control, you need the right statistical tool to do it. Standard control charts where control limits are based upon just a single part will not suffice. Instead, consider using a control chart to control the process. The deviation from target and Z-value normalizations allows one to assess process control through time. And isn't that the point? Let's not forget that the "P" in SPC stands for "Process."