Did Your SPC Software Forget about the Process?

This article describes the problems encountered when using a single SPC file to collect data from a part that is run on different machines. This situation may create an SPC deployment that unintentionally reports invalid Cp/Cpk ratios and generate shop floor control charts with incorrect control limits. Failing to recognize the problem, most SPC software companies promote methods that place their customers' SPC program at risk. This major blunder may invalidate the SPC software you are currently using. After you finish reading this exposé, we invite you to call your SPC software's degreed industrial statistician to find out what they have to say.

If you think your SPC deployment is at risk, please read on...

Let's say that you've set up a part profile within your SPC software. A profile is the front-end setup routine used to specify elements of an SPC data file. Not all SPC software calls their setup routines "profiles". Within that profile you specify the following primary items:

• part number
• characteristic(s) to be measured
• specification limit(s)
• subgroup size
• tag fields (machine serial number, lot, operator name and so forth)

Once these fields are defined you begin collecting and charting data.

The run is over and everything is fine, you've got your raw data and control charts. Now, lets change the situation. A few days pass and the part needs to be run again, except this time the part is setup on a different machine (lathe 225). Switching to a different machine is no problem because you anticipated this. That is why the machine number was set up as a tag field. Collecting more data (starting with sample 13). Resulting control chart showing both processes:

Something's Not Right...
At this point, the control chart contains data from both machines. Is this control chart correct.one control chart displaying data across more than one process? Something doesn't feel right. Being a good quality engineer, you do a little research. You go to your old SPC text books to look for control chart examples containing data from more than one machine. Much to your disappointment, all the examples assume the data came from the same process. If you were lucky enough to find a multiple machine example, the data were probably kept separate. That is, the differences between the two machines were illustrated using two control charts, two histograms or two box and whisker plots. You see, the professors know that different processes produce different statistical results. Therefore, mixing their data on the same control chart is not acceptable. Here is the root of the problem - shared control limits. If the data from two processes are plotted on the same control chart, both processes would be sharing the same control limits. The range chart must assume that the variability between the two machines are similar and the xbar chart must assume that the central tendencies are similar. Under certain conditions, these assumptions may hold true, but should be verified using only appropriate statistical tests such as the KW (Kruskall-Walis) test.

At this point, you have to make a choice - do you go ahead and keep collecting data from different machines in the same part file, or do you bite the bullet and set up separate files for each different part/machine combination. Here is the tradeoff: mixing machines in the same part file is good in a way because all the data from the same part is in one place, but this approach makes your control charts suspect and compromises the validity of the resulting Cp/Cpk ratios. On the other hand, setting up separate part files for each part/machine combination is very time-consuming and could potentially confuse the data entry users when trying to locate the correct file. But worst of all, the data from one part would reside in multiple files. Running customer Cpk reports would become a daunting recurring task.

Both choices have problems. This dilemma exists for one reason, the software developers simply forgot about the process. Yes, even though SPC stands for Statistical Process Control, the traditional SPC file organization logic ignores the statistical effect of the process. If you step back a little and look at the traditional SPC file organization, you will realize they are Part/Test based. That is, the specification limits and control limits are unique for each part/test combination. Within the same part file, you specify the specification limits and control limits for each unique part/test combination. If the process changes, the control limits do not reflect this change. Surprisingly, the process used to create the item being measured is relegated to the tag field level. Basically, forgotten. Yes, you can sort the data by these tag fields, but the control limits are not specified at the tag field level. We all know that a different machine will produce different results. From a statistical perspective, different machines will generate different means and different levels of variability (sigma). Why then would an SPC software company manufacture and promote a product that ignores the process effect in the control limits? Without the process, SPC becomes Statistical Part Control. These so-called SPC software companies have some explaining to do!

Any auditor that has certified an SPC deployment that uses a software where the process is not an integral part of the control limits should re-think that certification. Any SPC software company that advises their customer to mix different processes in the same file by specifying the process as a tag field is providing advice that could lead to false conclusions about the outgoing product quality.

Is There a Work-around?
Yes. You could work around this problem by establishing a different set of control limits when ever the machine is changed. Although statistically correct, this approach has strings attached, 1) someone will actually maintain these control limit updates and 2) the software is capable of establishing different control limits effective at each machine change interval. Even though this may "fix" a given control chart, still little is known about a given machine because machine-specific data is interspersed among several part files. This approach is not statistical process control.

How could this blunder have occurred?
Here it is, the middle of 2000 and most SPC software still stores data using flat file mentality (a legacy carried over from their DOS roots). The solution (a software that provides both part control and process control) is too complex for flat files. Its not that they don't want to fix their problems, they simply cannot with their existing code. They're faced with a total re-write.

Is There a Real Solution?
Yes. The programmers and industrial statisticians that designed InfinityQSi SPC software have always understood the importance of the process. For this reason, InfinityQSi has never stored data using flat file logic and because of this, control limits are part/process/test based. That is, a different set of control limits can be stored to the database for each different part/process/test combination. For example the Outside Diameter from Part A run on Lathe 167 can (and probably will) have a different set of control limits from the same Outside Diameter from Part A run on Lathe 225.

Let's take another look at the two-process dataset, InfinityQS allows you to display both processes on the same chart. If the two processes are similar, the same control limits can be shared. Otherwise, InfinityQS will automatically change the control limits whenever the process changes.

Notice that the KW test (a non-parametric statistic used to verify if the variability across both processes is similar) states to reject with a probability value of 0.009. This means that there is a 99.1% chance that the two process' variability is different. Therefore, the correct way to display this data is to use separate control limits for each process.

In the above chart, you clearly see the differences between Lathe 167 and Lathe 225. This chart, however, is not a process control chart. It is merely a part control chart. To see process control, you need a way to display all the parts run on a single machine, regardless of feature size. This type of chart is easily managed within InfinityQS because of the way data gets stored to the database (see the article, Dirty Little Secret for more details).

The below figure is a standardized control chart which plots data in units of standard deviations. It shows how two parts, with different nominal sizes, ran on Lathe 167. There are hundreds of specialized control charts supported by InfinityQS.

With InfinityQS, customers get the best of both worlds; they get part control analysis for their customer reports and process control analysis for themselves. No more dilemma, no more compromise.