If you’re going to cite operator error, do it in the PFMEA

I have written often of my disdain for the tendency of some to blame the operator when things go wrong, and anyone who has worked with me or for me has heard me parrot exhortations ad nauseam to not blame operators for failure as to not rob yourself the opportunity to improve, but I think there are some times where it is appropriate to highlight what an operator has done wrong.  Or, namely, one, and in a hypothetical sense – the PFMEA.  Here, you can cite, “operator failed to…” as often as you’d like and you’re still keeping the responsibility for improvement where it belongs – with management.

For the uninitiated, the PFMEA is a Process Failure Modes & Effects Analysis, and, while FMEA is used in many industries, the PFMEA is a primary tool for assessing risks while planning and developing a production process in the automotive industry.  By identifying failure modes, their effects, and their causes through the FMEA process, risks can be quantified and prioritized so that management can effectively plan and take actions to either eliminate or mitigate them or their effects.

The idea behind PFMEA is that it is a proactive approach to identifying risks in a planned production process before it ever goes into mass production, or before those risks are realized in the way of the production of product that doesn’t meet specification, broken down equipment, etc.  But aside from PFMEA being used as a tool to identify and mitigate risks in a process before they occur, PFMEA documents are also meant to be live documents that are updated after problems do occur in a manufacturing process, in which they inevitably will, to rectify why those failure modes or causes were not appropriately considered before production and to give a benchmark from lessons learned so that management can be more well-prepared when planning future processes, having already learned their painful lessons with the last.  

If a problem does occur – say, thousands of parts are manufactured out of spec, are not detected, and are then shipped to a customer where they created downtime in their assembly process, or worse, made it to an end user and sparked warranty claims or recalls, it is evident that the failure modes that created that scenario had either a) not been considered, or b) were not appropriately assessed so that adequate controls could be put in place to eliminate the failure mode or detect it should it occur, or, unfortunately, c) had been considered and appropriately assessed, but management failed to take appropriate action to mitigate the risk.  

In this scenario – that being that thousands of non-conforming parts are out in the field and a customer is rightly complaining to your organization and demanding corrective action – there will often come defensive measures from the party at fault.  There are a set of rules that I’d established over time to teach to my quality engineers to ensure that they did not fall into common traps – deflections aimed at absolving themselves of responsibility but doing nothing to truly rectify the situation or improve their process.

  1. The first rule that I taught was simple, one that had been taught to me during my early years as a Tier-1 Honda supplier: it is never the operator’s fault.  This simple maxim was aimed to remind resolution leaders and teams during a 5P or 8D that problems always stemmed from systemic and management failures.  If an operator messed something up, there was some management reason for the fault, whether that was poor equipment, incomplete training, inadequate work instructions, etc.
  2. Second, during the earliest stages of an 8D investigation when I would hear someone move toward the dangerous path of noting what an operator did or did not do that caused a problem, I would stop the conversation and repeat: “Did we make the expectation clear?  Did we give them the tools, the training, and resources to meet the expectations?”  If any of my previous colleagues are reading this, they likely heard this quote in my voice and mockingly said it aloud in parallel.  This set of questions was aimed at helping people to remember the point being made in the first maxim – if an operator made an error, they likely did not understand the expectations, or they did not have the tools, training, and resources necessary to meet them.  This is not the operator’s fault.  This is a management problem.
  3. Lastly, I taught all of my engineers that there were three things that I would never allow them to do immediately as a problem was received from a customer: blame the customer, blame the supplier, or blame the operator.  I know it sounds crazy that someone might blame a customer for the complaint that they raised, but it happens more often than you might think.  These three forms of deflection are a reaction when a complaint is raised to try to absolve yourself of responsibility.  You might hear a reaction immediately after the receipt of a complaint that sounds something like, “that’s impossible!  That could not have happened here, we have controls in place for that.  That must have happened in their assembly process!”  And, with that, real problems are often dismissed and never resolved, only to recur again and further diminish customer confidence.  I always taught that it may be possible that the customer, supplier, or operator was at fault, but no one was allowed to say it on the day one when they should be using their energy to contain the problem and protect the customer.  Instead, if someone was going to make such a bold claim, they needed to allow for the root cause analysis to lead them to that conclusion.  Anything less is robbing yourself of the opportunity to improve.

Bringing us back to this failure mode that has caused all of this nonconforming material to be released into the field, because it was likely not already considered in the PFMEA and it did certainly occur without detection, the PFMEA needs to be updated to reflect the actual risk and to provide the opportunity for process improvement to ensure that either a) the failure mode cannot recur, and/or b) should it recur, it is detected to minimize the impact.  

Now is your chance to say, “the operator failed to…”  

Say it over and over again.  As you look at each process or product characteristic, throw out every possible scenario in which an operator might fail.  

And each time you do, take the next step and ask, “why?”