Root causes - operator's actions

TPMB4

Quite Involved in Discussions
Tl:dr

What 4 reasons are there for operators to be at fault in a complaint? I'm guessing deliberate action to ignore procedures or sabotage are two, put in better wording obviously.

I'd like to put in another root cause related to management supervision but that's shooting myself in both feet doing that. Impolitic to say the least.

Further information if time rich!

Operator error has been discussed in relation to error causes many times on this forum. I don't really want to repeat that if possibly but I do need help on this.

Basically a complaint has had a corrective action approved in higher level discussions with a customer than I was party to but I'm the quality guy to finalise the paperwork in line with this resolution. I know it's not good corrective action procedure but we're a SME, the customer is bigger / more important to us than we are to them and it's not going to work going against this. It's what they want / are happy with. I'm trying to get a positive outcome by making sense out of this.

So I remember a thread on here where a respected member of this forum posted 4 accepted root causes involving humans. I can't find it or those 4 reasons. Can anyone help? I'm expecting one to apply here. Something related to operator not following procedure perhaps. It has been a kind of discipline issue with the operator being removed to a less critical operation. It's not training root cause because the operator understands the process and has been doing it OK for a year. It can't have an inspection afterwards because it's meant to be part of the final inspection operation. We're not a big enough company to operate with multiple levels of final inspections. Spot checks are not guaranteed to prevent this issue.

Basically this is a backwards corrective action. The root cause that's acceptable for the issue being assigned to the decision made by the operator to go against in place procedures. The procedures the operator should have done does prevent the complaint. It's proven a good procedure that's widely in place with similar products.
 

Jean_B

Trusted Information Resource
I know seeing it but I don't have access to my index for handy posts (of which I know this is on it).

However: aerospace also has a nice categorization:
The Human Factors "Dirty Dozen" - SKYbrary Aviation Safety

1. Lack of communication​
2. Distraction​
3. Lack of resources​
4. Stress​
5. Complacency​
6. Lack of teamwork​
7. Pressure​
8. Lack of awareness​
9. Lack of knowledge​
10. Fatigue​
11. Lack of assertiveness​
12. Norms​
 

TPMB4

Quite Involved in Discussions
Numbers 5 and 11 apply. Possibly 6 and 7 but less likely. Also there was an argument that the reason the defect got through was because supervision allowed for operators to take shortcuts or just miss out on doing actions needed. If you can get away with making your life easier you often find that people will. Operators don't see the implications of their actions at time. We've emphasised the implications of customer rejections plenty of times before.

Thanks for the list. Good information to try and use in the CA report. Although I think the 4 reasons would help too.
 

John Predmore

Trusted Information Resource
Another framework for discussing Human Error is the work by James Reason in his book "Human Error". The subtle distinction between slips, lapses and mistakes is the operator's intent - was a process step skipped thinking he already did it, or did he skip the step thinking that was the proper action. Because the root cause in these two examples is different, the appropriate corrective action would be different. Violations is a separate category; they are willful disobedience of a rule, maybe for what was considered good reason.

Here is one link, using driving an automobile as an example: http://www.hse.gov.uk/construction/lwit/assets/downloads/human-failure.pdf
 

Jean_B

Trusted Information Resource
Recalled a keyword to look for. They're in essence in the list mentioned before.

You can use the four causes listed by the IAQG themselves: CAR from 3rd party AS9100D auditor - Root cause dilemma
  • Lack of attention or concentration
  • Pressure and stress
  • Distraction
  • Fatigue

In response to John. The 2007 edition of IEC 62366 had a nice taxonomy with those terms in its Figure B.1. The new one (2015) doesn't have it in the same manner, though its Figure A.1 shows equivalent (though differently worded, see also figure D.1) items in an in-use flow sheet which could also be enlightening for who needs a more concrete example to distinguish them.
 
Last edited:

Steve Prevette

Deming Disciple
Leader
Super Moderator
There is this list used in the nuclear industry for human performance "error precursors". https://training.lbl.gov/ehs/training/assets/docs/Error-Precursors.pdf

Error-Precursors.jpg

I do find it interesting you say "Also there was an argument that the reason the defect got through was because supervision allowed for operators to take shortcuts or just miss out on doing actions needed." That implies the onus isn't entirely on the operators - that management was complicit and/or failed to set and enforce expectations.
 

TPMB4

Quite Involved in Discussions
I shouldn't have typed that really. There is an issue with a supervisory position a few of us believe but as ever you need good, strong evidence before anything gets done. Not got that...yet!

Operator error isn't my option for root cause in this situation but that's been decided. IMHO there's deeper issues being kept from the customer or being ignored. I'm not putting them in the report but tried to get them covered internally.

Issues with operator could be HF2 & HF4 in the IAQG listed in the reply Sidney made that was quoted above. Also MG3 inadequate organizational governance (management I guess). Training is fit for purpose. Inadequate resources such that the operator needed to do consistent overtime to catch up and keep up. A tight deadline too didn't help, late to provide additional labour resources.

Basically there's a load of things that went wrong but operator error, or more accurately operator violation, is the only one politically acceptable for the customer to find out about.

Sorry but you can tell I'm not really happy about things. I want to do things right. With this case I can only try to make operator error sound acceptable. Well it's been accepted by the customer so I just need to frame it in a way that's as acceptable as possible from a quality standpoint. If that makes sense.
 

Mike S.

Happy to be Alive
Trusted Information Resource
From the sound of it I think you could be one of my suppliers...... j/k :giggle:
 

TPMB4

Quite Involved in Discussions
From the sound of it I think you could be one of my suppliers...... j/k :giggle:
If you're auto aftermarket this wouldn't be an issue. OE work via another tier intermediary. I don't know what the higher ups said but they got operator error past the customer's BS detector.

There's worse in the claim report too but that's not for an open forum. Trust me on that.

I've a decent working relationship with their assistant qm which I don't want to affect by spinning BS. There is an issue with this operator but it could have been managed better IMHO which means it's not the root cause. Removing the operator from that function doesn't prevent any replacement doing the same.
 

Steve Prevette

Deming Disciple
Leader
Super Moderator
I guess that I'll just invoke that Dr. Deming did come to the conclusion that 94% of all problems are process related (and management owns the process) and 6% of the problems are from the workers. A good demo of that is the Red Bead Experiment.

Now, in your case, has any one talked with the operators? Observed the work being performed?

I like your last two sentences above. You have realized that replacing the operator that messed up with another operator would not affect anything. Red Beads at work!
 
Top Bottom