Is Operator Error Your Root Cause?

Operator errors do happen. Their minds wander; they get mentally fatigued performing the same task all day long; they’re talking with other employees; they take breaks. With all those distractions it’s amazing that they don’t make more mistakes! But is operator error your root cause?

In this example, your company receives a customer complaint that one layer of the product was incorrectly placed in the shipping containers. Per customer specifications, the metal box your company manufactures is to be placed into the shipping carton with the end hole to the right side of the carton. The red arrow on the carton indicates the direction of the boxes. This arrow is the result of a previous corrective action for the same problem. Examples of the box and the shipping carton are shown below.

At the customer facility, the boxes are robotically removed from the shipping cartons and placed in queue on a conveyor for assembly. Three rubber grommets are inserted into the front holes of the box and another grommet is inserted into the end hole. The box then continues to the painting module. There it is turned upside down for painting. The direction of the end hole is a critical component of error-proofing their manufacturing. If the box is placed in the shipping carton incorrectly, the customer’s machinery cannot insert the grommets and requires them to remove the incorrectly oriented box from the conveyor. The box is then returned to the beginning of the process, and any grommets are returned to the grommet collection hopper.

As a dedicated quality professional, you know that customer complaints regularly lead to corrective action. You also know that in any good CAPA (corrective action/preventive action) program the key to success is identifying the true root cause. The team investigates the current problem, and decides again that operator error is the root cause. An operator simply lost focus and incorrectly loaded the shipping container.

The team determines that the appropriate corrective action is to retrain all operators in the packing area. The training is conducted and the corrective action response is forwarded to the customer. The team continues to monitor this issue for an additional 2 weeks and finds no occurrence of a similar problem. The team then closes the corrective action after this verification.

Did the team really make the problem go away? Probably not, and maybe not for the reason you might believe. Any good internal quality auditor, customer representative, or third party auditor may comment upon a lack of true root cause identification. In many cases where operator error is considered to be the root cause, it is actually the fault of a process… not the operator! In fact, there’s nearly a 90% chance that a problem is a process issue.

Operator Error is being accepted as a root cause less frequently as more people begin to understand their processes and learn effective root cause identification tools. So let’s investigate this problem further.

If we assume that the root cause is indeed operator error, we’re also stating that our training program is insufficient. ISO9001 tells us in clause 6 to identify competency requirements for employees (what does the employee need to know to perform a specific job) and to provide training to meet those requirements. The clause also has a requirement to evaluate the effectiveness of training. This is where the breakdown appears.

If the training was evaluated and found to be satisfactory, then there is a problem in the training evaluation portion of your quality system. In this example, the training consisted of showing the packing department what the new box looked like, and reviewing a new work instruction that detailed the packing instructions in more detail. The operators signed the training document and indicated that the training was effective. The operators understood that the red arrow indicated the direction of the end hole.

Now you’re faced with developing a new method of training evaluation! An auditor or customer representative will suggest (or require) major revisions to your entire training program… all because the easy route to corrective action and root cause analysis was chosen. Is this a chance you want to take? I’m thinking it’s a bad idea.

If we consider this issue from a process perspective, we begin with the idea that the process failed to prevent the layer of incorrectly oriented boxes. The red arrow, as stated earlier, was the result of a previous corrective action from the same customer. The arrow was actually a very good idea. It was simple, inexpensive, and relatively easy to implement.

But the team failed in the implementation of this new packaging. The team used Deming Cycle or PDSA as their guideline for this process change. They were very successful in the Do stage, as they determined what they thought was the best solution and implemented it. The team’s downfall was either in the Plan or Study stage. The team didn’t have a short run using the new box where they would have seen the flaw in their new packaging design. Pilot runs are generally conducted during the Do Stage.

They determined their evaluation technique was to perform dock audits as a means of verifying the effectiveness of the corrective action (Study). And for a short period of time it was proven effective. Evaluation should have occurred at the location of the error, not a subsequent process step. Here’s why.

Recall the newly implemented cardboard box. Notice the location of the red arrow. When the operators begin to load the shipping containers with the manufactured boxes, the top container flaps were folded over the outside of the box… hiding the red arrow from view!

It is somewhat obvious that a mistake occurred in the Study phase of the improvement, but the larger issue is the failure of the Plan stage. It is apparent by a new customer complaint for a similar problem that the team conducted no risk assessment activities. In other words, the team failed to ask themselves “What Could Go Wrong” with the red arrow implementation. A simple brainstorming session could have determined that the placement of the arrow would eventually cause a similar problem.. Other methods such as Potential Failure Mode Effects and Analysis (PFMEA), or a risk matrix would have enabled the team to determine the risks of this implementation

So now, when you believe you have an operator error issue, remember to ask yourself…

Did the training fail, or did a process fail?