Process Failure Mode and Effects Analysis (PFMEA) is used to identify and mitigate risks early in the design process. 

Manufacturing Process Design complements the Product Design.   

• Product Design determines what the product is, i.e., the makeup of the product, its components, organization, etc.  
• Manufacturing Process Design determines how the product is built, i.e., how the components are assembled and tested, and in what order.   

In most cases, the manufacturing is straightforward and if the steps are followed properly, good quality is the inevitable outcome.   

This is the goal of the process design, even more so for complicated products: a straightforward process that yields a good high quality  product.  Certainly, the engineer that designed the process believes it will be a good process, but how do you review it and challenge it?   

Pilot production is the obvious choice for challenging the initial manufacturing process.  If the process, used on an initial batch of product, gives the right results, this can confirm that the process is reasonable.  There is a difference between building 10 units (or whatever statistical sample is needed) and building 100 or 1000 units.  Pilot production is new, and personnel tend to follow the instructions step by step and ask questions.  Unit 743, however, will not have that advantage and may be built entirely from memory by personnel who are getting a little bored.  Testing will likely catch any anticipated errors, and issues being identified at test time should be used as process indicators to note problems before they get out of hand. 

There is another tool available that will help challenge the manufacturing process just as it is used to challenge product usage and design.  The Process FMEA is one of multiple Failure Mode and Effects Analyses that can be performed to help ferret out weaknesses and risk in aspects of a product.  These processes can seem abstract, and many are reluctant to try them.  With some companies, the FMEA is done reluctantly because it is part of the “design process” and a box needs to be checked to get through the next stage gate.  Someone is going to do an FMEA, the question is, are your engineers, manufacturing, and marketing personnel going to do it, or are your customers going to do it after launch? Keep in mind the later a failure mode becomes evident, the cost to fix increases, not to mention the damage to a product’s reputation. 

We routinely use (3) FMEAs during development: 

• Application FMEA – this is where Marketing evaluates how their customers will foul up their carefully crafted customer experience.  The assumption here is that users will be sloppy with operating instructions (if they read them at all) and looks at the effects on safety and reliability. 
• Design FMEA – this is a critical review of the design, looking for failure points which may cause warranty returns, user complaints, or harm to someone. 
• Process FMEA – this is a review of the manufacturing and quality plan for building the product.  We look at the effects of degradation in the assembly process procedures on quality and risk. 

For the PFMEA, we identify potential failures in the process, determine how likely those failures are to occur and the impact on customer and personnel safety and product reliability.  If the failure is likely enough and severe enough, we modify the process to mitigate the failure. 

There are three criteria to be considered for each failure mode identified within a PFMEA:

• Severity of occurrence – rate it 1 – 10. 1 for “no detectable damage or weakness” to 10 for “serious harm to personnel”.   
• Likelihood of an occurrence – rate it 1 – 10. 1 for “only a remote possibility, maybe 1 in 10,000” to 10 for “almost certainly, maybe 1 in 100”.  
• Detectability of occurrence – rate it 1 – 10.  1 for “easily and immediately detectable” to 10 for “no ability to detect the occurrence”. 

For each failure mode, a number is assigned for Severity, Occurrence, and Detectability which is multiplied together to generate an RPN (Risk Priority Number).  The higher the number, the more likely it will be to require mitigation. At the onset of conducting a PFMEA, stakeholders (Engineering, Quality, Production, end Customer etc.) will agree on an RPN that triggers the requirement for mitigating the potential failure mode. Given that the criteria above can yield RPN’s between 1-1000, a typical RPN trigger number is between 100 and 200. For some products, a failure mode with a Severity above a certain number may automatically require mitigation. A Medical Device with a Severity number of (say) 8, where 8 means “Harm to the Patient or Operator” is one example. The real value is to rank the process risks, so you know which ones to address first and continue until there is a comfort level that the overall risk is “low enough”. 

Clearly, if you had an issue (e.g., exposed live wires during an assembly step) which could be expected to seriously injure an employee, it happened often if someone was not paying close attention, and you couldn’t see it to know where or when it may happen – that would be a serious issue that would need to be mitigated.  This would be an RPN north of 500 and the process step would be flagged during the PFMEA for changes.  An extreme case and seriously, how could that be missed during the process design?  The process also looks at the severity as it pertains to injury and if above a certain level (someone could be seriously injured), requires mitigation to virtually eliminate the problem. 

This process can also be adjusted to assign a dollar value to the occurrence so you can judge the value of additional testing on all systems to catch a damaging issue with a single unit.  Be careful not to get caught assigning dollar values to employee safety. 

Don’t get caught up in justifying the difference between a 5 and a 6 for each item.  If you just use the same criteria and gut feel for each number, the problems will reveal themselves quickly.  Also be careful of “that engineer” who wants to use the FMEA to push their pet issue and assign outlier values to force design or process changes. Maybe a person can spontaneously burst into flames – but do we really need that fire suppression system? Ironically, forcing an expense like that makes it more likely someone will light you on fire, so issues like this are best handled by putting effort into describing the reasoning behind each of the numbers.  At the same time, don’t be too quick to dismiss problems and ideas without considering the context. 

The FMEA documents are really never finished until the design or process is complete and production is now routine.  There are good reasons to revisit the document if you think of something new to add, just to show that it was considered. 

Who should you invite to participate in a PFMEA?  The engineers responsible for the design are an obvious choice, but don’t forget the assembly personnel.  They have a unique view into what goes wrong during operations.  The idea here is that if there is an adverse occurrence, it is not anyone’s fault, it’s a system problem and the system should be adjusted to eliminate the problem.