The Elsmar Cove Wiki More Free Files The Elsmar Cove Forums Discussion Thread Index Post Attachments Listing Failure Modes Services and Solutions to Problems Elsmar cove Forums Main Page Elsmar Cove Home Page
Google
  Web Elsmar.com
*Please be aware that SOME RECENT forum threads may not yet be indexed by Google.

View Full Version : Need Root Cause Verbiage - What to say when it's Operator Error?


JRKH
24th June 2002, 09:22 AM
OK, I know that we are not suppose to use operator error as a root cause, but I'm not sure how else to label it.

Here Goes:

Customer ordered copper parts 20 inches long with 4 punched holes in one end. The print calls for tin plating on approx 3" of each end to the part.
Parts were manufactured with plating only on the end with the holes.
Parts were cleaned and packed, and the job reviewed by the Fabrication Boss per SOP.

Customer Sent Me an NCR to which I must respond. Taking the "5 whys" approach I have:

1) Why Rejected: No tin one end

2) Why: Missed operation

3) Why: Operator did not read drawing correctly

4) Why: Operators often assume tin is only on ends with holes (most common occurance) So when he found the note on the end with the holes he quit looking.

5) Why: In a hurry, or tired, or...............

I would point out that this person is not a "Problem". He is a good operator who simply screwed up.

Any ideas on a good response to this?

James:confused:

M Greenaway
24th June 2002, 09:36 AM
Hmmm

You might stop at your 4th why above.

The operator made an assumption based on what he thought was required because of the repetative nature of the product (perhaps ?).

Your corrective action might therefore be to ensure that those things that are against the 'norm' in your manufacturing operation are clearly identified.

Just one thought.

This might lead you to look closely at the documentation that supports the manufacturing processes.

Rick Goodson
24th June 2002, 10:17 AM
Why number 5 should lead you down a path for corrective action involving a 'disciplinary' discussion with the operator regarding reading and following instructions. Probably involves some retraining. I don't have a problem with the concept of operator error as a root cause, but it needs to be qualified and have some proactive corrective action.

Al Dyer
24th June 2002, 10:56 AM
For whaat it is worth, I used to use operator error many times and at that time it was accepted. These days the "politically correct" term to use is insuffient training.

Sure it is a cop-out because we know people make mistakes but the powers that be don't want to hear it.

As an exaturated example, consider you bought a new car and a headlight was missing, is that a process error or an operator error? I would think the assembly person forgot to put the headlight in!

Of course this is based on the automotive edict that post production inspection does not provide any value added properties.

Like we have heard, Do As I Say, Not As I Do.

M Greenaway
24th June 2002, 11:18 AM
Should the process be robust enough however to protect against what would be operator error ?

Al Dyer
24th June 2002, 11:30 AM
Most definatly should, but is it realistic?

M Greenaway
24th June 2002, 11:36 AM
I personally think it should be our aim to Poke Yoke all processes. Is it realistic or achievable - maybe not, but it should be our never ending aim.

JodiB
24th June 2002, 11:40 AM
I like Martin's suggestion to have a way to flag "unusual" requests. Yes, it may involve more work (who would go around determining what would be "unusual" in any given scenario?) but it is the only way to really deal with operator error when it is not training or too much overtime or too high of a production rate. He's a human and has to have the process designed to accommodate that.

I'm kind of curious about how it passed inspection too. Yes, operator screwed up, but how in the world did it make it to the customer?

Mike S.
24th June 2002, 12:29 PM
I don't think any discipline is required -- anyone here who has not made such a mistake as mentioned in James' post is either a liar or is not doing much work of any kind. James said he is a good employee who just made a mistake, so I think discipline is inappropriate. A good workers already feels bad about it and will discipline himself. I'd stop at #4 and say it was discussed with the employee and the others in his job and is not expected to occur again, but you will watch for any repeats in regular reviews of CAR's just in case. So, no further action unless it happens again. JMHO

M Greenaway
24th June 2002, 12:40 PM
Well said Mike.

Again this goes back to Demings red beads doesnt it !!

JRKH
24th June 2002, 01:10 PM
Thanks guys and gals.

Glad to see we are all thinking along the same line.

It reinforces my feelings on how to deal with minusha(sp).

James

gpainter
24th June 2002, 01:33 PM
Most of our customers will not accept lack of training or operator error as a root cause. if it does boil down to operator error as in this case poka-yoke it.

JRKH
24th June 2002, 04:24 PM
gpainter said:

Most of our customers will not accept lack of training or operator error as a root cause. if it does boil down to operator error as in this case poka-yoke it.


In this case pok-a-Yoke is very difficult. These are, basically, one-off parts. The customer builds very large motors...I mean veeerrrry large. So their designs are pretty much customized.
We very rarely make the same part more than once, and the qty's are generally quite low -- In the 1 to 20 range.

I would be open to any suggestions on how to Poke-A-Yoke something like this.

James

Atul Khandekar
24th June 2002, 04:48 PM
Lucinda asked a pertinent question. How did it pass inspection?
Parts were cleaned and packed, and the job reviewed by the Fabrication Boss per SOP.
AFTER packing?

db
24th June 2002, 05:22 PM
Probably involves some retraining

I would be very careful when using retraining. Anytime there is a lack of performance there can only be one of two causes. Either there was deficiency in knowledge (DK), or a deficiency in execution (DE). We often place everything in the category of DK when the real problem DE.

In this case, if the operator either didn’t know to check for plating a both ends, then retraining is warranted. This could also apply if the operator has returned to this operation after a substantial absence.

If the operator knew “better”, but just slipped up, then retraining is useless! The question then is why did the operator fail? Error proofing may help, altering the procedure might help. Disciplinary action might help.

When answering a CAR or conducting the “5 Why”, I would use either DK or DE (non-abbreviated) as the final cause. You could go deeper, liking asking why the operator didn’t know, or what barriers to performance resulted in the lack of execution, but it would not always need to go that far. Most customers would accept that because of fear that you would discover they had no idea of what either term meant.

JRKH
24th June 2002, 06:48 PM
Atul Khandekar said:

Lucinda asked a pertinent question. How did it pass inspection?

AFTER packing?


Basically the same way as the error occured in the first place I would say. The Fabrication Boss is in the area, and oversees the various jobs. I can only say that he made the same type error that the operator did. Not reading the print completely.
While it is a valid question, I do not generally look to inspection in a root cause analysis. Inspection, after all, is not where one prevents errors from recurring.

James

Dean Frederickson
4th October 2006, 05:07 PM
I agree with Mike S. if it is a good worker there needs to be no action (discipline) taken, but when it is a borderline good/bad worker I think training and or discipline is necessary, but when the worker is continually making mistakes due to carelessness or inattentiveness, or lack of caring, I believe with appropriate disciplinary action ( verbal warning, written warning, loss of pay, and termination) should be taken.

Wes Bucey
4th October 2006, 06:52 PM
OK, I know that we are not suppose to use operator error as a root cause, but I'm not sure how else to label it.

Here Goes:

Customer ordered copper parts 20 inches long with 4 punched holes in one end. The print calls for tin plating on approx 3" of each end to the part.
Parts were manufactured with plating only on the end with the holes.
Parts were cleaned and packed, and the job reviewed by the Fabrication Boss per SOP.

Customer Sent Me an NCR to which I must respond. Taking the "5 whys" approach I have:

1) Why Rejected: No tin one end

2) Why: Missed operation

3) Why: Operator did not read drawing correctly

4) Why: Operators often assume tin is only on ends with holes (most common occurance) So when he found the note on the end with the holes he quit looking.

5) Why: In a hurry, or tired, or...............

I would point out that this person is not a "Problem". He is a good operator who simply screwed up.

Any ideas on a good response to this?

James:confused:
FWIW: I see the root cause going back at least to Contract Review where Supplier assures it has complete understanding of customer requirements and normally provides a FMEA and a Control Plan, including inspection protocol highlighting critical characterstics.

There just is no place for a supplier who takes each order for granted. I can tell you flatly I would not accept "operator error" in a corrective action report nor would I (as a customer) settle for anything less than a description of the revamp of the contract review and control plan process as the corrective action plan to assure me it would not likely recur.

Customer loyalty is earned, not bestowed as a gift.

Baldrick
5th October 2006, 07:41 AM
Wes is spot on.

Be wary of any system that allows an operator error to get to the customer. OF COURSE people make mistakes. An effective management system, (e.g. as per ISO9001) will ensure that when such mistakes are inevitably made, there are processes that detect them, analyse them, and prevent (or at least reduce the chances of) them happening again.

I used to regularly see responses from suppliers that stated that "an individual made a genuine error and there's nothing more we can do, because it's bound to happen from time to time". This is particularly infuriating when it comes from an ISO9001-approved company, because it demonstrates a complete lack of understanding of the fundamentals of a management system.

We can debate whether "operator error" is acceptable as a root cause - what surely CAN'T be debated is that there is almost always something that can be done to eliminate, or reduce, the chances of it happening again.

JRKH
5th October 2006, 08:26 AM
As the Origional Poster of this thread I can assure you that we do not take these errors lightly. At the same time it must be recognized (and is recognized by most companies) that there is only so much that can be economically done to prevent/errorproof/PokaYoke/ensure/detect/insure/guarantee/train/retrain/inspect/reinspect so that it won't happen again.

We can couch the error in all sorts of different terms, and we can do any number of things to try and prevent re-occurance, but as sure as the sun rises, some sort of random error is going to occur in the future. So if one chooses to term an error as "operator error" or some other more acceptable term such as a "process control error" means little. To me what is more important is how much error is driven out of the system as a whole.

Once error rates reach a certain level customers understand that even in the best systems there will be an occasional glitch.

James

Helmut Jilling
5th October 2006, 08:36 AM
In this case pok-a-Yoke is very difficult. These are, basically, one-off parts. The customer builds very large motors...I mean veeerrrry large. So their designs are pretty much customized.
We very rarely make the same part more than once, and the qty's are generally quite low -- In the 1 to 20 range.

I would be open to any suggestions on how to Poke-A-Yoke something like this.

James


If you do custom parts, then shame on operators for "assuming."

There needs to be a very methodical approach to reviewing and double checking potential failure points.

Maybe a double-check to verify (final inspection).

Is this potential failure point identified on the PFMEA?

Yes, people make errors, and if they are "good" operators, and they know how to do it correctly, it can be left as operator error.

Retraining is only effective if the training teaches something not already known and understood. Otherwise, it is just nagging, scolding or reminding (which may also work).

Hugo Ley
23rd April 2009, 12:19 PM
FWIW: I see the root cause going back at least to Contract Review where Supplier assures it has complete understanding of customer requirements and normally provides a FMEA and a Control Plan, including inspection protocol highlighting critical characterstics.

There just is no place for a supplier who takes each order for granted. I can tell you flatly I would not accept "operator error" in a corrective action report nor would I (as a customer) settle for anything less than a description of the revamp of the contract review and control plan process as the corrective action plan to assure me it would not likely recur.

Customer loyalty is earned, not bestowed as a gift.

Would you request a corrective action for 1 part reject out of thousands? If so, then in a hypothetical case where the root cause can not be attributed to anything but the operator lacking concentration on that one part, what would you accept?

In the original post, I took it to be that the whole order was incorrect. If that is the case then no, I wouldn't accept operator error neither. But what if one part was incorrect out of the order? Makes finding a root cause a bit more interesting.

Chris Ford
23rd April 2009, 12:33 PM
OK, I know that we are not suppose to use operator error as a root cause, but I'm not sure how else to label it.

Here Goes:

Customer ordered copper parts 20 inches long with 4 punched holes in one end. The print calls for tin plating on approx 3" of each end to the part.
Parts were manufactured with plating only on the end with the holes.
Parts were cleaned and packed, and the job reviewed by the Fabrication Boss per SOP.

Customer Sent Me an NCR to which I must respond. Taking the "5 whys" approach I have:

1) Why Rejected: No tin one end

2) Why: Missed operation

3) Why: Operator did not read drawing correctly

4) Why: Operators often assume tin is only on ends with holes (most common occurance) So when he found the note on the end with the holes he quit looking.

5) Why: In a hurry, or tired, or...............

I would point out that this person is not a "Problem". He is a good operator who simply screwed up.

Any ideas on a good response to this?

James:confused:

I would focus on Number 4.

"Operators often assume tin is only on ends with holes (most common occurance) So when he found the note on the end with the holes he quit looking."

I've found that if you're doing something that's not considered a "standard practice," you need to make it very clear in the documentation. I'd definitely agree that the root cause here is operator error. There isn't anything inherently wrong with the document; it contains the necessary information. But, the document could possibly be improved to mitigate or eliminate operator error, if the plating note were more prominent.

Wes Bucey
23rd April 2009, 04:04 PM
Would you request a corrective action for 1 part reject out of thousands? If so, then in a hypothetical case where the root cause can not be attributed to anything but the operator lacking concentration on that one part, what would you accept?

In the original post, I took it to be that the whole order was incorrect. If that is the case then no, I wouldn't accept operator error neither. But what if one part was incorrect out of the order? Makes finding a root cause a bit more interesting.Since I'm a Demingite, I understand about variation and one nonconforming piece out of a thousand would not trigger a corrective action request (unless we are talking about products that cost $1 million each!)

I still don't buy operator error as a reasonable cause, since it begs the question, "What corrective action will the organization implement?"

Retraining is not a sufficient CA, because it begs the question, "What was wrong with the first training and evaluation of the effectiveness of such training?"

Replacing the worker is not a sufficient CA, because it begs the question, "What was wrong with the selection and evaluation of the first worker?"

Closer inspection is not a sufficient CA, because it begs the questions, "What was wrong with the inspection plan in the first place? Who evaluated the plan? What criteria were used in the evaluation?"

Ultimately, what most folks call operator error is just more evidence of not looking deep enough for a root cause.

Here's just some of the things affecting operators which shortsighted folks blame on the operator, but are really under control of managers:


poorly calibrated production equipment or inspection instruments
poor lighting making it difficult to discern instrument readings
poor eyesight (if eyesight is critical, does organization test and provide corrective lenses?)
dirty equipment or machinery
ambient temperature too hot or cold
worker exhausted from long periods of work without break
worker ill - adequate medical care to prevent ill workers from injuring self, others, equipment, production?
poorly written work or inspection instructions, leaving them open to wrong interpretation
mis-identified materials or tools



Sometimes, just sometimes, workers actually sabotage (spoil on purpose) production or equipment or the work of other employees - the proximate reason may be mental imbalance, ideological differences, resentment over pay or working conditions, animosity between workers or between workers and boss[es], etc. etc.

Bottom line:
Regardless of the reason for one individual to commit an error or even sabotage, management must be able to come up with a CA to prevent or at least greatly reduce the probability of future nonconformances. Merely attributing the error to one individual and eliminating such individual is not sufficient, a SYSTEM is required to identify and prevent a similar occurrence from any other individual.

masterx
23rd April 2009, 05:06 PM
Human errors are an essential part of any human performance. They are most explored for human-operator activity in complex systems such as aviation, nuclear power, military and hospital systems, etc., where they are associated with severe consequences. Their analysis requires going beyond the limits of an operator’s error to the different facets of a situation to understand the underlying factors which led to the error. For the decision errors, which contribute to more than 60% of all accidents where crew behavior is a causal factor [1], need to be analyzed complex personal and social factors
related to conflicts of motives and goals which are hard torecognize and finally treat. In human reliability analysis, these factors are called performance shaping factors, which are outside the operator’s immediate control and indirectly influence system safety [2].



[1] J. Orasanu and L. Martin, “Errors in aviation decision making: a factor in accidents and incidents. In Proceedings of the 2nd Workshop on Human Error, Safety, and System Development, Seattle, 1998, pp. 100-107.
[2] A. Mackieh and C. Cilingir, “Effects of performance shaping factors on human error”, International Journal of
Industrial Ergonomics, vol. 22, 1998, pp. 285-292.

Chris Ford
23rd April 2009, 06:22 PM
Since I'm a Demingite, I understand about variation and one nonconforming piece out of a thousand would not trigger a corrective action request (unless we are talking about products that cost $1 million each!)

I still don't buy operator error as a reasonable cause, since it begs the question, "What corrective action will the organization implement?"

Retraining is not a sufficient CA, because it begs the question, "What was wrong with the first training and evaluation of the effectiveness of such training?"

Replacing the worker is not a sufficient CA, because it begs the question, "What was wrong with the selection and evaluation of the first worker?"

Closer inspection is not a sufficient CA, because it begs the questions, "What was wrong with the inspection plan in the first place? Who evaluated the plan? What criteria were used in the evaluation?"

Ultimately, what most folks call operator error is just more evidence of not looking deep enough for a root cause.

Here's just some of the things affecting operators which shortsighted folks blame on the operator, but are really under control of managers:


poorly calibrated production equipment or inspection instruments
poor lighting making it difficult to discern instrument readings
poor eyesight (if eyesight is critical, does organization test and provide corrective lenses?)
dirty equipment or machinery
ambient temperature too hot or cold
worker exhausted from long periods of work without break
worker ill - adequate medical care to prevent ill workers from injuring self, others, equipment, production?
poorly written work or inspection instructions, leaving them open to wrong interpretation
mis-identified materials or tools



Sometimes, just sometimes, workers actually sabotage (spoil on purpose) production or equipment or the work of other employees - the proximate reason may be mental imbalance, ideological differences, resentment over pay or working conditions, animosity between workers or between workers and boss[es], etc. etc.

Bottom line:
Regardless of the reason for one individual to commit an error or even sabotage, management must be able to come up with a CA to prevent or at least greatly reduce the probability of future nonconformances. Merely attributing the error to one individual and eliminating such individual is not sufficient, a SYSTEM is required to identify and prevent a similar occurrence from any other individual.

I was auditing at a very large manufacturing plant several years ago. It was a typical supplier surveillance audit, and was going smoothly, until I began reviewing the company's customer complaint files. The complaint procedure required that complaints be forwarded to an analyst for final closure, after the investigation was complete. The analyst would review the complaint, and make a number of determinations, before signing off on the complaint document. I found several complaint records with no signature in the closed complaints file. I expanded the sample set, and found more... further analysis indicated that the unsigned complaint records were forwarded to the analysts' department around the same ten-day time period. Further, I found that all of the unsigned records were forwarded to a particular analyst in the department.

The department supervisor brought the individual into the conference room. During an interview, she seemed very familiar with the procedures, and she understood complaint investigation, as well as regulatory requirements for Medical Device Reporting and Vigilance Reporting. She was genuinely shocked to find that she made such an error. In sum, 19 of 40-some odd records she reviewed were not signed.

I asked her what could have gone wrong... was she rushed? Something on her mind? Why only for this ten-day period of time? She blushed. "For the last couple of weeks, we... my husband and I..." Oh God, what can of worms did I just open? "we're trying to have a baby. He keeps me up all the time. It's non-stop; he's like a machine..."

OK I've heard enough. That's fine... Understood.

A true story.

While I agree that operator error isn't a true root cause most of the time, human error happens. Sometimes it is the root of a problem - someone simply not paying attention to what they're doing.

To determine if operator error is a true root cause - or a cop-out - you really need to look at a larger scope. In this particular case, a very large number of records in the sample set were nonconforming. However, they were isolated to a specific period of time and a specific person. In this case, operator error was clearly the cause of the nonconformity. Had I found numerous unsigned records by numerous people over the course of history, I'd find "operator error" to be an inadequate root cause.

Based on the severity of the issue, as well as cost involved, it's up to the organization to determine the appropriate preventative action to take to prevent or mitigate recurrence. In this case, I hope the gal took a few days off work, then returned as an expecting mother... But, I did warn her. If she thought that was bad, wait until she's dealing with morning sickness, mood swings, then after all of that, the year of sleepless nights ahead!

What I gathered from the OP was that a lot / batch of product was non-conforming because the operator didn't pay attention to the notes on the drawing. He isn't sure that "operator error" is an adequate root cause.

I'd analyze:

# Nonconforming product due to "operator error"
Types of nonconformities
Reason for operator error - i.e. didn't read the notes

If operator error is the root cause for many nonconformities by multiple operators, they are not properly trained or equipped - that includes proper tools and documentation.

The CAPA system is a very good measure of effectiveness of training. When operators are trained to be aware of nonconformities, yet nonconformities still occur, I'd say training was ineffective. If the situation involves repeated operator errors by multiple individuals, I'd venture to guess that the training system in general was ineffective.

If operator error is contained to a specific type of nonconformity, or a specific operator, the same could apply but the problem is not systemic. Perhaps training for that one individual or training for a particular part wasn't effective.

If the operator error is limited to one individual and one lot, or representative of an individual's performance during a specific period of time, other factors - most-likely, human factors - probably caused the individual to err.

In every situation, we'd expect preventative action, but the extent of action taken will vary dramatically, depending on the severity of the issue.

Miner
23rd April 2009, 09:37 PM
Regardless of whether there was operator error in this particular case, management can change the system to minimize the chance for error. For example, if there are families of parts with one end dipped and another with both ends dipped, the documentation for the two families could be color coded to indicate the difference. That is not to say that color coding is the best option, only that a system change can reduce the probability of an operator error.

Wes Bucey
24th April 2009, 01:35 AM
The complaint procedure required that complaints be forwarded to an analyst for final closure, after the investigation was complete. The analyst would review the complaint, and make a number of determinations, before signing off on the complaint document. I found several complaint records with no signature in the closed complaints file. I expanded the sample set, and found more... further analysis indicated that the unsigned complaint records were forwarded to the analysts' department around the same ten-day time period. Further, I found that all of the unsigned records were forwarded to a particular analyst in the department.

<SNIP>
I asked her what could have gone wrong... was she rushed? Something on her mind? Why only for this ten-day period of time? She blushed. "For the last couple of weeks, we... my husband and I..." Oh God, what can of worms did I just open? "we're trying to have a baby. He keeps me up all the time. It's non-stop; he's like a machine..."
<SNIP>
But, I did warn her. If she thought that was bad, wait until she's dealing with morning sickness, mood swings, then after all of that, the year of sleepless nights ahead!
<SNIP>Well .. . apart from the fact some organizations might have triggered a sexual harassment complaint for the morning sickness comment, all you have identified in MY eyes was a SYSTEM that didn't have adequate checks and balances for periodic review by in-house folks to continually evaluate the system for possible improvement and to assure it was running as planned. I'm rarely comfortable with a medium to large organization which will allow any employee be the funnel for the work of several others without periodic checks to assure "changes" (good or bad) which may have crept into the process are identified and evaluated.

Lack of such periodic checks is the primary reason we read about mail carriers who have several tons of undelivered mail stacked up somewhere, stemming from a one-time desire to knock off early and deliver the mail when the load was lighter. Once the free time was enjoyed, the mail carrier took more and more opportunities to knock off early, always with the intention of ultimately delivering the mail "tomorrow."

An embezzler at a local bank was recently caught and convicted merely because a bank client returned the auditor inquiry with factual info instead of discarding it as a "nuisance." The SYSTEM of checks and balances didn't prevent the embezzlement, but it was able to catch and correct the activity.

Good old Bernie Madoff was able to continue his nefarious activity (multi-billon dollar Ponzi scheme) for so long because the folks who should have been in charge of the system of checks and balances didn't act on the findings of complainants and investigators, dismissing them as "cranks" without investigating whether there was a legitmate basis for labeling them cranks.

A simple analogy would be an internal audit report identifying nonconforming processes, but never read, let alone acted upon, by the management review board. In such cases, the management review board doesn't bother to kill the messenger delivering bad news, they just ignore him!

Helmut Jilling
24th April 2009, 09:27 AM
Would you request a corrective action for 1 part reject out of thousands? If so, then in a hypothetical case where the root cause can not be attributed to anything but the operator lacking concentration on that one part, what would you accept?

In the original post, I took it to be that the whole order was incorrect. If that is the case then no, I wouldn't accept operator error neither. But what if one part was incorrect out of the order? Makes finding a root cause a bit more interesting.

1. Corrective action should be appropriate to the significant of the failure and issue. One part could be very significant or may not, that should determine whether it requires a formal CA, depending on how significant the issue was.

2. Contrary to popular belief, operator error could sometimes be the root cause, IMHO, but it should be determined after the systemic failure modes have been evaluated and eliminated. Some people tend to select first, then there is no real investigation.

3. btw, a failure of 1 pc out of a 1000, would equate to a ppm of 1000, which is not very good. 1 pc out of a 10,000 would still be 100 ppm, still a lot of room for improvement. Those CA's can help drive that improvment.

Jim Wynne
24th April 2009, 12:06 PM
1. Corrective action should be appropriate to the significant of the failure and issue. One part could be very significant or may not, that should determine whether it requires a formal CA, depending on how significant the issue was.

2. Contrary to popular belief, operator error could sometimes be the root cause, IMHO, but it should be determined after the systemic failure modes have been evaluated and eliminated. Some people tend to select first, then there is no real investigation.

3. btw, a failure of 1 pc out of a 1000, would equate to a ppm of 1000, which is not very good. 1 pc out of a 10,000 would still be 100 ppm, still a lot of room for improvement. Those CA's can help drive that improvment.

I was right there with you until #3, when the ugly specter of PPM appeared. If 10,000 represents 10 years of production, (it would take 100 years to make a million) I'd say one bad piece in that amount of time would be pretty good in most cases. PPM makes no sense unless you're actually making millions of things, and even then the desirable proportion is strictly relative to the work being done.

Caster
24th April 2009, 12:48 PM
Customer ordered copper parts 20 inches long with 4 punched holes in one end. The print calls for tin plating on approx 3" of each end to the part.
Parts were manufactured with plating only on the end with the holes.
Parts were cleaned and packed, and the job reviewed by the Fabrication Boss per SOP.

If I read this right, you do low volume, almost custom one of a kind work?

And each part is made by a skilled trade, millwright, crafstman?

It sounds like the operator works off a print and there is no traveller, control plan, inspection document, etc?

I see no need to create an elaborate system, could you just have the person take a green hi liter to the print and stroke off every dimesnion, note, feature, etc as a final inspection self check? This would be a form of poka yoke.

A missing feature is very much harder to inspect for than an incorrect feature. And more embarassing when the customer finds it.

Helmut Jilling
24th April 2009, 01:01 PM
I was right there with you until #3, when the ugly specter of PPM appeared. If 10,000 represents 10 years of production, (it would take 100 years to make a million) I'd say one bad piece in that amount of time would be pretty good in most cases. PPM makes no sense unless you're actually making millions of things, and even then the desirable proportion is strictly relative to the work being done.


Well, Jim, I would be happy to agree that in the very few cases where a company takes 10 years to make 10,000 parts, then ppm is not really a relevant metric for them. In the more common cases where companies make millions of parts, I would recommend applying corrective action aggressively to continue to improve performance to 100 or better.

Jim Wynne
24th April 2009, 01:12 PM
Well, Jim, I would be happy to agree that in the very few cases where a company takes 10 years to make 10,000 parts, then ppm is not really a relevant metric for them. In the more common cases where companies make millions of parts, I would recommend applying corrective action aggressively to continue to improve performance to 100 or better.

Why would you want to apply an arbitrary limit? What if a PPM level of 300 is the result of achieving a state of economic equilibrium (i.e., it's the state of an optimized process)?

C Logan
24th April 2009, 01:50 PM
Based on the #4 occurance that the operator assumed... You may want to add to the print to NOTE: Tin required on both ends.
You may want to have a QA checklist added to each job which lists critical factors to review.

Helmut Jilling
25th April 2009, 08:56 AM
Why would you want to apply an arbitrary limit? What if a PPM level of 300 is the result of achieving a state of economic equilibrium (i.e., it's the state of an optimized process)?

No intent to apply an arbitrary limit. It was just a benchmark number for discussion purposes. Personally, I don't consider 100 good. With my own clients I press for much lower numbers.

The intent was directed to the OP who proposed that one defective part out of "thousands" was so insignificant that it was not worthy of corrective action. I wanted to make the case that that level of performance may actually not be that great yet.

Jim Wynne
25th April 2009, 11:49 AM
Well .. . apart from the fact some organizations might have triggered a sexual harassment complaint for the morning sickness comment, all you have identified in MY eyes was a SYSTEM that didn't have adequate checks and balances for periodic review by in-house folks to continually evaluate the system for possible improvement and to assure it was running as planned. I'm rarely comfortable with a medium to large organization which will allow any employee be the funnel for the work of several others without periodic checks to assure "changes" (good or bad) which may have crept into the process are identified and evaluated.

Lack of such periodic checks is the primary reason we read about mail carriers who have several tons of undelivered mail stacked up somewhere, stemming from a one-time desire to knock off early and deliver the mail when the load was lighter. Once the free time was enjoyed, the mail carrier took more and more opportunities to knock off early, always with the intention of ultimately delivering the mail "tomorrow."


The scenario presented by Chris Ford is great illustration of the importance of understanding the interaction of processes, and a situation that quality manuals almost never address.

A distracted person failed to sign off on documents as required by the process documentation. This happens (regardless of the source of the distraction) very often because people don't understand why they're supposed to do things other than because "ISO says so." They don't understand that what they're supposed to do is important to someone else down the line, or at least allegedly important.

It's good in this kind of situation to ask an auditee why they're expected to sign off on something. If the answer is, "Because George can't do his work without the signature," you have a basis for believing that the auditee understands the interaction between her process and George's, and perhaps simple human error is the cause.

To take it a step further, it's a good thing in an internal audit to go to George and find out why he needs the signature. Once again, if the answer is "That's what the procedure says," you have evidence of someone not understanding The Big Picture. It's altogether possible that the signature isn't really necessary, and there's some simpler way of doing things that won't get derailed because of human error further up the line.

If audits (internal and external) don't examine the interactions of processes, something important is being missed.

Helmut Jilling
25th April 2009, 01:02 PM
...often because people don't understand why they're supposed to do things other than because "ISO says so." They don't understand that what they're supposed to do is important to someone else down the line, or at least allegedly important.

...If audits (internal and external) don't examine the interactions of processes, something important is being missed.


Very worthwhile point! The interactions of processes is a key foundation of the ISO 9001 and even 14001, and is much more than diagrams and process flowcharts.

Wes Bucey
25th April 2009, 03:36 PM
I suppose this means that if the signature was never meant to be seen by anyone again (file completed form and forget it) - then we should really be questioning why the signature was necessary in any case, as long as the form, itself, was completed.

If the signature was necessary for traceability, then perhaps the signature should be entered first or the form coded in some way to identify the individual completing the form, presuming the form is actually completed, not filed as a blank. The format and layout of the form are also significant factors if various portions of the form are not displayed in the sequential order in which they should be considered and completed.

My hunch is the process for completing the form was kind of loose goosey in the first place and the work instruction not very systematic.

I have been witness to some organizations, (customers and suppliers) where signatures were added to documents and forms without ever reading the document or form. Worse, the person adding a signature was incompetent to evaluate or assess the document he was signing (and thus tacitly approving the content, regardless of whether he read it.) This was most notable where buyers and clerks were on the approval list for engineering drawings who could not make any sense of what the drawing represented, let alone actually assess it for viability.

All in all, perhaps this was more of an opportunity for mistake proofing the form and process instead of assigning blame to a "relationship-distracted" employee.

trainerbob
25th April 2009, 04:19 PM
I am a strong proponent of vision systems and bar coding for operation to operation. If the previous operation does not show in the computer as having been completed when the part is scanned at the next operation then the operator is alerted not to proceed any further. It is even more important for large low volume items than for high production runs. Typically we have a lot of time and money in the large low volume items and a problem with just one of then can certainly affect both our customer base and our bottom line. Vision systems, bar code systems, and computers are not so expensive that we can afford to lose customers or end up with rework instead of spending a few bucks. We don't need a system that allows failure or sets up operators for failure. Retraining on a CAR does nothing for me but raise a red flag.