Query on Capability of Stdev Specifications

[garbagex]

Hi All,
I would like to seek advice on how to assess process capability for the following situation. Search online for guidance but so far all methods are for individual data points or subgroups of individual data points but none for individual mean and stdev data points.

1. My factory is producing printers

2. A final testing process prints 50 pages and a scanner measures and summarizes parameter X’s mean and standard deviation of the printer as X_Avg and X_Stdev

3. There is no specification on the mean of X as the mean can be calibrated by user

4. There is a Pass/Fail specification on the spread of X for each printer, that X_Stdev < 0.25

5. I can calculate Yield as (No. printers with X_Stdev < 0.25 / Total), but how do I start to assess whether my process is capable of producing printers to meet X_Stdev?

a. To check if process is in control, do I perform SPC on X_Avg or X_3Stdev values?​

b. To check normality, do I run Anderson-Darling on X_Avg or X_3Stdev values? Or X value of every individual printed pages?​

c. Is each printer’s 50 pages considered a rational subgroup? I’m thinking no, as my smallest unit of production is the printer and the set of 50 pages just represents 1 printer.​

i. Should I estimate sigma(within) using pooled standard deviation or average moving range?​

d. What should I set as my USL and LSL for the process? USL = 0.25 and no LSL?​

Here are some sample data for illustration. Currently I have tried different ways of calculating capability but so far the predicted DPMO value I have got from the Cp or Cpk is very far from the actual failure rates of the data.

Hope someone can show me the proper way to calculate my process capability that is linked to the failure rate!

 

[Stijloor]

A Quick Bump!

Can someone help?

Thank you very much!!

Stijloor.

 

[Marc]

Another quick "Bump". My Thanks in advance to anyone who can help with this one.

 

[Bev D]

you do capability on the standard deviation because it is the parameter that has a spec limit.
do NOT multiply it by anything. your spec is a single SD so use the 1SD value.


standard deviations do not have a Normal distribution, so running a test of Normality is not valuable.

are you trying to report a Cpk value? if so, to who?
the best way to get a 'meaningful' Cpk is to coutn the number of out of spec events and work backwards from the defect rate to the Z score. Divide the Z score by 3 and you have your Cpk value.


It is best to use a standard deviation control chart.

yes a subgroup size of 50 sheets seems logical.
the sample size is good for minimal sampling error of the standard deviation
and each printer should have a homogenous distribution of errors for any given set of 50 sheets.

I have posted an example of what you can do with your sample data.

 

[garbagex]

Stijloor & Marc, thanks for the bump!
Bev, thanks very much for your pointers, it is indeed logical to look at these data as attribute pass/fail and get the equivalent Cpk despite having the continuous data...

We are trying to report 2 items for this process: what is the yield (answered by pass/fail % or your method) and how much design margin do we have if we stick to the current USL (trying to answer by 'Cpk'). Hopefully the 2 index can be used to summarise the past data AND predict future production.

Right now we are limited in ways to further reduce the standard deviation, but we have an option to increase the USL with calculated tradeoffs. I need to calculate how much wider the specs need to be to make the appropriate request. So here I'm using Cpk as a metric to assess 'improvement'.

Method 1 (Bev)
- Calculate defect rate and Cpk based on current USL and proposed USL
- However, Cpk calculated from defect rate relates to pass/fail only, does not tell me how much margin I have
- In your attached data if I increase USL to 0.33, the 'Cpk' hits a ceiling even after I removed the outliers. Or will looking at the data as percentage failed and percentage out of control be more meaningful?

Method 2 (mine)
- Treat printer Stdev data as a normal parameter, perform transformation and calculate Cpk=Cp(upper)=(USL-mean)/(3*sigma_overall)
- Tweak USL until I get Cpk=1.33, so I know 99.73% of my printers are now within the new USL
- Statistically I cannot convince my self, as this is actually 3sigma of Stdev and it just seems wrong!

 

[Bev D]

just to keep this on the 24 hour list.
I will be able to answer tomorrow...

 

[garbagex]

Thanks Bev, your effort very much appreciated!

 

[Bev D]

well the Cpk index is not a good tool as you are finding out. In fact I'd suggest asking yourself why you are using the Cpk index - is it just because it's there? what will make the most sense to your target audience?

you could transform the data to calcuate a Cpk - but htat is a lot of work for what end? it's a bit like using a chain saw to trim your toenails.

one thing you can do is to simply divide the the range of SD values by the 'tolerance' range and get a straightfoward ratio - you can even call it a Cpk index since that is essentially what it is. (even with a realtivley Normal distribtuion the ppm 'prediction' of a Cpk index isn't reliable - you are better off reporting the actual defect rate.

Now I do have to ask: where did the SD specification come from? typically, specifications come from the user requirement and function of the device. (they originate from physics). Capability comes form the process's actual perfromance against those specs. product performance specs should not come from capability.

The only time capability should drive tolerances is when a subcomponent dimension, property of function can't be maintained and the design requires that level of performance to meet the final specifications. In these cases we REDESIGN the product so that a looser tolerance cna be applied to the input parameter so that teh final specs can be met...does that make sense?

 

[garbagex]

Hi Bev,
the index serves 2 purposes: for us workers to assess our current performance (defect rate is not enough, we also wish to know whether production can be sustained or we will run out of control), plus a simple weekly reporting tool to management that they can understand. Having gone through the frustrating exercise, I understand and fully agree with you that Cpk is not an ideal all-in-one index that describes that whole process.

Earlier I did try the tolerance/process sigma method suggested where I got the sigma by pooling all the SD values. Unfortunately all it did was to 'average' the SD values with sigma being understated and Cp overstated with totally no relevant link to the actual failure rate. So my method was wrong.

For the SD specs, since the user is able to adjust the mean value by calibration, all we had to ensure was the spread of data was within an acceptable range. This range was a legacy from previous similar products that had no complaints but we also realised that previously we had set the specs too tight after checking acceptability levels with end users. Now when our realistic process performance is known we want to set the specs right so as not to stress the production. Cart-before-horse situation indeed...
This is the first time that the company is checking process capability so my job is to make sure it's not being blindly implemented without any actual relevance to production.

Thanks for your patience thus far, I learned much from the our exchange. This is what I plan to do for my process:
1. Assess and report Yield
2. Assess and report 'Capability' with the caveat that Cpk PPM does not accurately predict true failure rate, hence it is more for past performance rather than future yield.
3. Run SPC to monitor for potential out-of-control situations, get real time picture how much margin we have to the Spec limits as well.

 

[Bev D]

as you are discovering Cpk is a psuedo statistic that obfuscates what is happening rather than adding any real informative value.

in my organization we do not use them. my suppliers do not send them.
we simply plot the data in time series. sometimes we use control charts but mostly we use a straightforward multi-vari chart. these charts show all of the information needed to understand the capability of the process. it enables us to engage in valuable discussion about how to improve the process - or not. we do not waste time on de-constructing or misinterpreting the index (try plottign confidence intervasl around them - teh sampel sizes used are typiclaly too small for the index to have any accuracy so you just end up chasing noise). managers here understand these charts - all the way up to our CEO. (in fact at our first ISO registration audit, he told one of the auditors who was trying to 'impose' Cpk that it was a waste of time and he wouldn't allow it) just because it is currently 'popular' doesn't mean it has value or must be used. you can choose to not use it.