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:

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.

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.

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.

Should the process be robust enough however to protect against what would be operator error ?

Most definatly should, but is it realistic?

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.

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?

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

Well said Mike.

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

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

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.

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

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?

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.

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

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.

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.

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.

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

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).