Human Error vs Technique Root Cause (Categories)

[Tyler C]

I don't know if this is the right forum for this thread, so please forgive me if it would fit better elsewhere.

In the company I work for, we have about 9 key words for root causes of nonconforming product (to make it possible to filter by root cause for data analysis). So far, every nonconformance has fit into one of these 9 key words (categories).

Well, we recently had one that I am struggling with fitting into one of our key words. It was argued that this is a true case of human error, but I am trying very hard to keep human error out of our root causes.

Basically, we use punches to punch holes in certain materials. What happened was, the employee was getting ready to punch, but the punch slid a little as he hammered so the hole is not in the right location.

Would technique be an appropriate root cause? Or, is this too similar to human error? I asked myself "why did it slip?" and I'm thinking if he was gripping the punch too tight it could move, or he wasn't paying attention and it moved, etc.

Let me know your thoughts!

 

[Kronos147]

I asked myself "why did it slip?"

Don't classify it until you have completed the root cause analysis. You are well on your way with the above question.

Ask the other operators how it can.

 

[hogheavenfarm]

While categorizing root cause issues is a great tool, I would be concerned that you are 'forcing' a root cause in many cases. The idea is for a open solution, and trying to fit it into a category slot limits those solutions. As for your example, just because the tool slipped does not mean 'human error', for instance, could a "locator" device or jig be used to prevent slipping? I am sure some type of template could eliminate this condition, and as such it seems you may have a process issue or technique concern. For example, it should not be possible to mispunch this, and you are relying on human technique to prevent it, which is not always perfect.

 

[Bev D]

the reason the punch slid is "because it could".
while we this is a form of human error, hogheavenfarm is correct that the difficulty with human error is not in it's existence as a cause, but in our corrective action of the cause. Whenever human error is legitimately the cause the corrective action to prevent recurrence is to error proof the process or design.

So add a category for human error if you want...

As for categorizing non-conformances by cause, I have personally never found this to be useful. I have found categorization by problem statement (or failure) to be quite useful as it is actionable.

I would challenge you to describe how you will use cause categories to actually improve your system

 

[Tyler C]

Thanks Kronos147. I haven't categorized it yet as I am trying to find the root cause, I am only struggling with the next "why" and getting away from human error. I have asked a few operators why this could happen and I always get, "we're human, we make mistakes". That's why I was questioning if technique is different than human error or not.

Thanks hogheavenfarm, process issue is one of our categories and that was the best choice for this one out of my options, but I hesitated because this is not a common issue and I have a hard time questioning the process when it works 99% of the time. I get what you are saying about forcing a root cause, but I want this categorization to help show our weak spots, plus get extra practice in root cause analysis from our supervisors for when the big issues happen.

Thanks Bev D, that is an interesting point. So human error could be an acceptable root cause so long as the corrective action is sufficient in eliminating the possibility of human error?

Our reject report is done in excel and categorizes several things, such as what the failure was, what production area caused it, etc. The intent of the cause categories was focus on the biggest culprit and work on eliminating it. We run TOC (Theory of Constraints) and this methodology requires focusing on one constraint at a time and improving it, then moving to the next because focusing on more than one thing at a time is the same as not focusing on anything. For example, if we have a lot of rejects with a root cause of the individual not reading the production traveler, then we shine the light on reading the traveler as we are custom and this is an extremely important step.

You have all given me some good things to think about. I really appreciate your responses.

 

[Tyler C]

I also want to clarify that our root cause results can be of a wide variety to allow for an open solution, however they get categorized in a broad system to make finding all of the different root causes easier. For example, if something gets rejected because of a piece of equipment, we look at why (lack of maintenance, capabilities, fluke, breakdown, etc.), then it gets categorized as "equipment" so I don't have to look through thousands of lines when analyzing the reject report.

 

[Bev D]

Of course human error is a legitimate cause. We just don't want it (and it's ineffective corrective actions: retrain, train, discipline, etc) to be the reflex response. Not only do these actions not improve things, they make things worse as they decrease morale and divert us from getting to true causes.

I also want to clarify that our root cause results can be of a wide variety to allow for an open solution, however they get categorized in a broad system to make finding all of the different root causes easier. For example, if something gets rejected because of a piece of equipment, we look at why (lack of maintenance, capabilities, fluke, breakdown, etc.), then it gets categorized as "equipment" so I don't have to look through thousands of lines when analyzing the reject report.

I still don't understand these highly aggregated cause categories are helpful. 'equipment' is quite vague - what do you do to improve 'equipment'? I would wager that you still need to look at the details of the actual causes.

I fully understand the theory of constraints and I agree with prioritizing actions based on the severity of the effect. I have simply never seen highly aggregated categories help...certainly my organization ahs 'fixed' systemic issues because we understand the underlying themes of the specific causes.

 

[Tyler C]

Thanks Bev D, I was just a little surprised because through my research and straight from my registrar, I was told "Human error is not an acceptable root cause because the failure happens because it is allowed to". But, looking at it in this context helps me understand this much better. I really appreciate that, and I totally agree that "retraining", etc. will only make things worse.

In regard to the general categorization, we use an excel spreadsheet for our reject report. Everything we ship gets put on this sheet which adds up to tens of thousands of lines to analyze (I know this is not the best practice and I am working on a proposal to change this). As the travelers are processed after the product is shipped, an employee inputs any reject data on this spreadsheet. So, when it is finished I have to analyze it for our KPI regarding product conformance. Instead of searching through these thousands of lines, I do a simple filter and break down each root cause category individually.

For example, I filter everything out except "equipment", I then look through just the equipment issues to identify if we have a maintenance issue, capability issue, training issue, breakdown issues, or whatever else may be the case as the actual root cause is also listed, to determine any corrective actions. If I filter to just see "equipment" issues, and within this category I identify a large portion of our equipment issues came from lack of maintenance, then I can issue a corrective action regarding the maintenance processes and why schedules aren't being followed.

I can see how this would muddy the water in a some companies, but it helps us because we are totally custom and can have thousands of different root causes, so this just helps me narrow down what I'm looking at to be more effective. In the initial question above, I am struggling with getting an answer to the "why" questions to identify the actual root cause and whether or not it fits into the "process issue" category.

 

[Ninja]

...I am only struggling with the next "why" and getting away from human error.

You're already getting great advice...I just feel like chiming in...

Don't "get away from human error"...handle it.

answer to Why #4: Operator error

Why#5: Why was is possible for the operator to make this mistake?

answer to Why#5:
Sufficient prohibitions not installed in the process to block this error from being possible.

CA to consider: What can you do to make it physically impossible for the operator to make this error?

 

[Miner]

My experience is that all human errors are caused by an underlying condition. I always insist on asking one more Why if you get an operator error as an intermediate cause.

As Ninja stated: Why is it possible for the operator to make this mistake? Did the tool slip because the punch was dull? Could a jig have been provided to secure the punch and prevent it from slipping?