Need Root Cause Verbiage - What to say when it's Operator Error?

[JRKH]

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

[M Greenaway]

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]

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.

[M Greenaway]

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

Most definatly should, but is it realistic?

[M Greenaway]

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]

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?