Quality Engineering: How to Create a PFMEA

Quality Engineering: How to Create a PFMEA

In the last blog from our Quality Engineering series, I talked about why people loathe PFMEAs (Process Failure Mode Effects Analysis) – because they’ve never seen a good one. Poor, mostly copied efforts aren’t satisfying to most Quality people. Sure, you checked the box, but deep-down you think you missed the boat, an opportunity. Why would the customer insist on performing such a ritualistic, simplistic, and generally worthless task? Surely, they know you have plenty of other things to do, so why would they divert you from those activities?

Well, many of those customer employees don’t know. They’ve had PFMEA training and had to endure a number of corrective action reports where “it wasn’t recognized as a failure mode” is mentioned. They were brought onto the carpet and told to “get their suppliers in line”. But, most of them don’t get it, either. They dislike the PFMEA, too (“so long, so detailed. How can you catch everything?”).

However, the PFMEA is a well-thought-out and integrated system for achieving world-class quality. It’s part of a logical sequence of linked documents (and efforts) that lead to a Quality Operating System (QOS). The PFMEA is the backbone of the QOS. If the QOS isn’t developed in a logical, specific order, then it’ll be weak.

How to Create a PFMEA

Column Considerations

The PFMEA is the foundation of a QOS; you need to start with it first and you need to start with it early.  OEM Management and their dedicated experts devised the systems a long time ago; they know it’s an integrated system, but they’ve created very superficial training curricula focused almost solely on the PFMEA’s columns, not how to prepare a robust PFMEA. In other words, they’ve showed us what it is, not how to do it.

Maybe you’re thinking, “I know what each of the columns mean and I‘m perfectly capable of filling out a form. In fact, I know more about my product than you ever will”. Correct, you do know more about your product than me. However, that isn’t necessarily an advantage, and your close familiarity with said product and how it’s manufactured contribute most of the shortcomings to weak PFMEAs. In fact, you’re so close to it and you have so much experience with it, that you take things for granted and don’t explore for hidden flaws and failure modes. And it’s the failure modes we’re interested in.

In the automotive industry, there’s so much emphasis placed on Severity, Occurrence, and Detection Ratings (the “numbers”), that people forget an obvious truth: if you don’t have a line for it in the PFMEA, you can’t fill out its columns. You can disagree about what the effect is, or brainstorm the causes, but if you don’t have a failure mode, then you don’t a have a place to write any of your product/process knowledge.

I’ll go out on a limb and say that the rest of the PFMEA – beyond failure modes – is marginally useful. Most of it’s just for prioritization, with the exception of Detection Controls, which are critical. In today’s automotive world, any defect or nonconformance can lead to stopship, yard-hold, major rework, or other costly containment actions, despite what the RPN rating or the Severity was. If the customer didn’t indicate what the Severity rating should be (via the DFMEA), he or she may say, “sorry”, and still charge you for his or her massive containment actions (at union prices). The point here being that you should have excellent controls for every potential process failure mode you can identify, but, you must identify them in the first place.

So, my PFMEA boils down to five columns:

  • Process Step No.
  • Process Step Description
  • Process Function Requirements
  • Process Failure Mode
  • Detection Controls
Process Flow Design

A QOS is an integrated system – a logical sequence of linked efforts. Here’s the sequence of development:

Quality Operating System PFMEA

As you can see, you need to start with the process.

In the world of the Automotive Industry Action Group (AIAG), the first document is the Manufacturing Process Flow Diagram (PFD). It’s a tour guide type of document that lays out a very high overview of your process. It describes the “tabs” or the sub-headings for sections of the PFMEA and Control Plan that are made, later. A PFD is a one-page orientation sheet for newcomers – and it names your Op numbers, too (Op 10, Op120, etc.) – that must be consistent (note: the above flow chart is not a PFD).

The PFD is the result of engineering your processes. Once, you’ve figured out how you’re going to make the product, you can put it all on a piece of paper for C-level and upper management personnel to look at. In some ways, the PFD is the last document, too. In between, a lot of engineering must occur. As mentioned before, the PFMEA is a tool to analyze engineering proposals for the quality risks in an iterative process. You may learn that that your product can’t be made a certain way because it wouldn’t be physically possible or because it would be too risky, in which case your PFD is going to change. So, AIAG starts with the PFD, though you should actually end with it.

The process engineers (IEs, process designers, vendors, etc.) possess the starting basis knowledge for the PFMEA. You need them to tell you about the micro-process flows – descriptions of the processes down to their smallest details, i.e. “what is every little step?”. This is where having tons of product/process knowledge hurts you when doing the PFMEA; you know how the process works and so you may leave out obvious details when performing the analysis. Consequently, you end up missing an opportunity to identify a failure mode and assure a control is in place to stop it.  So, here’s where “thorough” starts. Define what you’re going to analyze.

I’ve seen companies try to perform a PFMEA without having the process defined. For instance, a product’s print may have a dimension on it, like the diameter of a hole, but you must design the process that assures the correct hole gets there. Don’t analyze the print, dig into the process.

Each of these micro-processes are Process Step Descriptions. They’re individual steps that must be described in a subject-verb sequence like the following:

  • Place one o-ring on the shaft
  • Move the piece to the fixture
  • Turn the spindle at 1300 rpm
  • Use a 4.75mm drill
  • Press the leak-test start button

The reason we need this type of detail is because in order to uncover failure modes (i.e. ways of doing something wrong) we first need to describe how to do them right. I can’t emphasize this enough, “what did the Process Designers intend to happen?”.

Conclusion

Design, engineering, and quality professionals alike often dread performing, or interacting in any capacity with, PFMEAs because of the amount of time required, and because they’ve never seen a good one. However, quality teams could create their own versions tailored for their purposes, using a variant with as few as five columns, so long as it has superior controls for potential process failure modes to be identified.

Creating a proper PFMEA is the first step toward achieving world-class quality, so in the next part of our Quality Engineering series, I’ll talk about the second, and most critical, step of the PFMEA.

-Stephen