Some interesting thoughts:
From: (Jon S.)
Newsgroups: misc.industry.quality
Subject: Re: In Process Insp. Sampling
Date: Tue, 18 Dec 2001 19:59:31 GMT
On Fri, 07 Dec 2001 09:46:32 -0600, Michael wrote:
>Can anyone shed some light on how to determine reasonable sampling rates
>for in-process inspections of CNC machining ops? Is the procedure any
>different for determining rates for manual machining ops such as drill
>press ops, manual mills etc?
>
>I realize that tolerances will have something to do with it, but I'm
>looking for a starting point. Up till now we've been more or less
>guessing but I would like to have a more scientific way.
>
>Thanks in advance.
>
>Mike Bielert
>Quality Assurance Manager
>Custom Castings Ltd
Mike,
I'm very late to this discussion (we just passed an ISO audit yesterday, so, I'd been away concentrating on that). I didn't see a lot of replies, and I feel like typing and babbling today, so my apologies upfront.
Some of this is "well, duh" stuff. But, I'm the only Quality guy here, and, since the audit, I've endured my boss telling me how it's all just for marketing and how the _auditors_ are generating the new ISO revision so they have job security. And how he doesn't like the new standard because he has to do work. So, I need to talk "real quality" to someone, anyone. *sigh*
Anyway...
It seems to me like the "scientific" way to set this up would be to first do some specific, detailed studies on your machine's capability.
Do a short-term study using what you obviously know is too many samples. This would give you a picture of what the true nature of your process variation is going to be, and would give you an idea of what sort of drifts are going on (i.e. is it a slow steady decline as cutting tools wear, or are you just waiting until something breaks or gets knocked out of alignment in a single event.) -To put it in quality science terms, this is essentially doing 100% inspection to determine process capability.-
After that, then you just have to apply your best judgement.
If it's a slow steady decline due to part wear or machine drift, then you can tackle it by predictive processes at a rate of sampling great enough to expose the nature and trend of the drift in time. (i.e., if the tool consistently loses 'y' units amount of cutting edge for each cycle, and you're only allowed via tolerances to be 'y * 100' units out and your natural variation is 'y * 10' units, you'd better be checking more frequently than every 100 pieces! Maybe every 20 or so.)
If it's a "wait until it breaks" type issue, then you've just got to ask yourself how many pieces you are willing to make out of spec until you catch it. (And, more importantly, you'd use this data to track and try to solve or predict whatever breaks.)
There are all kinds of inspection schemes to do these sorts of things (mil specs, spc, and on and on and on) with variations inside each, but, IMHO, because you essentially get to pick what scheme you want in each plan and your own tolerance for scrap, it's still just going to be trial and error and guess work. (The only exception I can think of is, if they aren't experienced in data tracking, making sure you've worked with the operators to understand what's needed. No data fudging, no machine fudging, no changing things because of 3 data points in the same direction, etc. etc.... These things become management and knowledge issues.)
In the end, it will boil down to Wayne's suggestion of just putting out a log sheet to collect the data and seeing what's happening. As you collect data, you'll be able to modify the frequency of sampling to meet your process's needs. (In fact, reviewing the sampling plans and data should be part of a PDCA cycle, IMHO, even if it's somewhat informal.)
As always, the first rule is to understand your machine's normal capability. Once you understand what's normal for your machine, then the sort of sampling you'll need to verify that capability becomes an academic matter. Then, all you need do is track the instances where your machine doesn't meet that capability (good or bad!) and make adjustments. If it's exceeding the previously calculated capability, then you need to recalc your control limits so you can continue to refine your process (and after congratulating your people, probably call marketing or engineering so they know your new capability). At this point, you could probably also determine a reduced inspection plan if improving process capability isn't your goal. If the process is not meeting the previously calculated capability, then you need to find out why.
IMHO, the biggest issue is training your operators so they aren't making common fallacies when trying to assess the data as they collect it. (Red/black bead examples and funnel drops are some of the classic tools. Deming's Out of the Crisis has classic discussions of some of the issues here.)
BTW, I've found that the easiest way to prevent knee jerk reactions when initiating new tracking is to collect the first few batch of data myself, and plot it before anyone else gets to it. Then, using the first plots, you can show them what normal variation is and how not to get excited at the wrong things. IMHO, false trends are the hardest thing to get people to back away from. Monte Carlo style fallacies are also a common issue, as well as false associations.
Operator: When I do "this", "that" usually happens... Me: but wait, "that" happens a lot without you ever doing "this". How does "that" happen without "this"?
I thought of another one to watch out for when initiating new machine tracking... "discovering" issues that were always there, but just ignored. This ends up being an upper management issue in my organization. A problem exists, and has generally been known about for a while by the operators, someone finally gets the notion to monitor that area, and immediately finds lots of problems.
Management assumed it was okay before (no previous data means no way to prove them wrong...), and goes off the deep end thinking someone's just started screwing up. The problem was their assumptions, but what ends up happening is the new plan you just put in place caused a bunch of pain for the people you just asked to help you. Education of the operators taking the data isn't enough. Sometimes you've got to figure out how to educate the managers around and above you of the same things.
Obviously, a good manager would look forward and see what could be done to improve. But, politics, IMHO, can be as big of a part of data collection and analysis as just using the proper technique.
Okay, I'm done with my random babbling now!
Jon
From: (Jon S.)
Newsgroups: misc.industry.quality
Subject: Re: In Process Insp. Sampling
Date: Tue, 18 Dec 2001 19:59:31 GMT
On Fri, 07 Dec 2001 09:46:32 -0600, Michael wrote:
>Can anyone shed some light on how to determine reasonable sampling rates
>for in-process inspections of CNC machining ops? Is the procedure any
>different for determining rates for manual machining ops such as drill
>press ops, manual mills etc?
>
>I realize that tolerances will have something to do with it, but I'm
>looking for a starting point. Up till now we've been more or less
>guessing but I would like to have a more scientific way.
>
>Thanks in advance.
>
>Mike Bielert
>Quality Assurance Manager
>Custom Castings Ltd
Mike,
I'm very late to this discussion (we just passed an ISO audit yesterday, so, I'd been away concentrating on that). I didn't see a lot of replies, and I feel like typing and babbling today, so my apologies upfront.
Some of this is "well, duh" stuff. But, I'm the only Quality guy here, and, since the audit, I've endured my boss telling me how it's all just for marketing and how the _auditors_ are generating the new ISO revision so they have job security. And how he doesn't like the new standard because he has to do work. So, I need to talk "real quality" to someone, anyone. *sigh*Anyway...
It seems to me like the "scientific" way to set this up would be to first do some specific, detailed studies on your machine's capability.
Do a short-term study using what you obviously know is too many samples. This would give you a picture of what the true nature of your process variation is going to be, and would give you an idea of what sort of drifts are going on (i.e. is it a slow steady decline as cutting tools wear, or are you just waiting until something breaks or gets knocked out of alignment in a single event.) -To put it in quality science terms, this is essentially doing 100% inspection to determine process capability.-
After that, then you just have to apply your best judgement.
If it's a slow steady decline due to part wear or machine drift, then you can tackle it by predictive processes at a rate of sampling great enough to expose the nature and trend of the drift in time. (i.e., if the tool consistently loses 'y' units amount of cutting edge for each cycle, and you're only allowed via tolerances to be 'y * 100' units out and your natural variation is 'y * 10' units, you'd better be checking more frequently than every 100 pieces! Maybe every 20 or so.)
If it's a "wait until it breaks" type issue, then you've just got to ask yourself how many pieces you are willing to make out of spec until you catch it. (And, more importantly, you'd use this data to track and try to solve or predict whatever breaks.)
There are all kinds of inspection schemes to do these sorts of things (mil specs, spc, and on and on and on) with variations inside each, but, IMHO, because you essentially get to pick what scheme you want in each plan and your own tolerance for scrap, it's still just going to be trial and error and guess work. (The only exception I can think of is, if they aren't experienced in data tracking, making sure you've worked with the operators to understand what's needed. No data fudging, no machine fudging, no changing things because of 3 data points in the same direction, etc. etc.... These things become management and knowledge issues.)
In the end, it will boil down to Wayne's suggestion of just putting out a log sheet to collect the data and seeing what's happening. As you collect data, you'll be able to modify the frequency of sampling to meet your process's needs. (In fact, reviewing the sampling plans and data should be part of a PDCA cycle, IMHO, even if it's somewhat informal.)
As always, the first rule is to understand your machine's normal capability. Once you understand what's normal for your machine, then the sort of sampling you'll need to verify that capability becomes an academic matter. Then, all you need do is track the instances where your machine doesn't meet that capability (good or bad!) and make adjustments. If it's exceeding the previously calculated capability, then you need to recalc your control limits so you can continue to refine your process (and after congratulating your people, probably call marketing or engineering so they know your new capability). At this point, you could probably also determine a reduced inspection plan if improving process capability isn't your goal. If the process is not meeting the previously calculated capability, then you need to find out why.
IMHO, the biggest issue is training your operators so they aren't making common fallacies when trying to assess the data as they collect it. (Red/black bead examples and funnel drops are some of the classic tools. Deming's Out of the Crisis has classic discussions of some of the issues here.)
BTW, I've found that the easiest way to prevent knee jerk reactions when initiating new tracking is to collect the first few batch of data myself, and plot it before anyone else gets to it. Then, using the first plots, you can show them what normal variation is and how not to get excited at the wrong things. IMHO, false trends are the hardest thing to get people to back away from. Monte Carlo style fallacies are also a common issue, as well as false associations.
Operator: When I do "this", "that" usually happens... Me: but wait, "that" happens a lot without you ever doing "this". How does "that" happen without "this"?
I thought of another one to watch out for when initiating new machine tracking... "discovering" issues that were always there, but just ignored. This ends up being an upper management issue in my organization. A problem exists, and has generally been known about for a while by the operators, someone finally gets the notion to monitor that area, and immediately finds lots of problems.
Management assumed it was okay before (no previous data means no way to prove them wrong...), and goes off the deep end thinking someone's just started screwing up. The problem was their assumptions, but what ends up happening is the new plan you just put in place caused a bunch of pain for the people you just asked to help you. Education of the operators taking the data isn't enough. Sometimes you've got to figure out how to educate the managers around and above you of the same things.
Obviously, a good manager would look forward and see what could be done to improve. But, politics, IMHO, can be as big of a part of data collection and analysis as just using the proper technique.
Okay, I'm done with my random babbling now!
Jon
