PFMEA (Process Failure Mode and Effects Analysis) is a structured approach that assigns quality risk levels to each step in a process – download a PFMEA excel template here.
PFMEA is a powerful prevention tool, since it does not wait for defects to occur, but rather anticipates them and implements countermeasures ahead of time.
The risk level for each process step is quantified using a Risk Priority Number (RPN) that typically ranges from 1 to 1,000, with 1,000 being the highest possible risk level.
PFMEA RPN Value – Calculated in the Excel Template
The RPN is a product of three risk factors, all ranked on a scale of 1 to 10 –
RPN = Severity x Occurrence x Detection
| Risk Factor | Description |
|---|---|
| Severity | How severe a given defective condition would be to the customer |
| Occurrence | The best estimate of how often the defective condition will occur in the process |
| Detection | The likelihood that the defective condition will be detected prior to reaching the customer. The current or proposed control plan should be referenced when assigning detection values. |
Prior to conducting a PFMEA, the facilitator should have a set of ranking criteria for Severity, Occurrence, and Detection, which should be shared with the team ahead of time. An example of Severity, Occurrence, and Detection ranking criteria would be as follows –
PFMEA Severity Scale
| Severity Rank | Description |
|---|---|
| 10 | Hazardous, without warning |
| 9 | Hazardous, with warning |
| 8 | Very High |
| 7 | High |
| 6 | Moderate |
| 5 | Low |
| 4 | Very Low |
| 3 | Minor |
| 2 | Very Minor |
| 1 | None |
Severity levels of 9 and 10 are typically reserved for hazardous situations, with a severity of 10 reserved for hazards that the customer is not warned about ahead of time. For example, an electrical shock hazard would typically be rated with a severity of 10.
PFMEA Occurrence Scale
| Occurrence Rank | Description |
|---|---|
| 10 | >100 Per 1,000 |
| 9 | 50 Per 1,000 |
| 8 | 20 Per 1,000 |
| 7 | 10 Per 1,000 |
| 6 | 5 Per 1,000 |
| 5 | 2 Per 1,000 |
| 4 | 1 Per 1,000 |
| 3 | 0.5 Per 1,000 |
| 2 | 0.1 Per 1,000 |
| 1 | < 0.01 Per 1,000 |
Keep in mind that the Occurrence value represents how often a given problem can occur in the first place, and has nothing to with whether or not the problem is detected in the process (this is where the Detection ranking comes into play).
PFMEA Detection Scale
| Detection Rank | Description |
|---|---|
| 10 | Absolutely Impossible |
| 9 | Very Remote |
| 8 | Remote |
| 7 | Very Low |
| 6 | Low |
| 5 | Moderate |
| 4 | Moderately High |
| 3 | High |
| 2 | Almost Certain |
| 1 | Certain |
So a Detection level of 10 indicates that is virtually impossible to detect a given defect once it occurs, and a Detection level of 1 indicates that the process is absolutely guaranteed to catch the defect should it occur.
PFMEA Example
While PFMEA’s are most often applied to production processes, they can be applied to any process that follows a sequence of steps to achieve a desired outcome. The attached PFMEA example shows two steps in a process that most people are familiar with – refueling an automobile. Additional comments are noted in red font.
PFMEA Countermeasures
Countermeasures are actions planned by the team to lower high-RPN (high risk) process steps, and are considered to be the “value added” outputs of PFMEA’s. The best countermeasures utilize error proofing, which is an important step in the Control phase of DMAIC. Let’s look at another process that takes place millions of times around the world each day: homeowners using their automatic garage door openers. A few years ago, it was possible to lower an automatic garage door onto a vehicle. Let’s use PFMEA logic on the process step: ” Lowering the automatic garage door” –
Process Step: Lowering the Garage Door
Potential Failure Mode: Garage door lowers onto and damages vehicle
Effect: Significant damage to vehicle
Severity: 9 (hazardous with warning)
Occurrence: 6 (approximately 5 out of every thousand times the homeowner will start to close the garage door when the vehicle is underneath)
Detection: 3 (high – in most cases the homeowner will realize what they have done and click the remote again to stop the door)
RPN = 9 X 6 X 3 = 162
RPN’s over 100 are generally considered unacceptable, and given the severity of lowering a garage door onto a car, a solid countermeasure is needed in this case. Garage door manufacturers might get some benefit from adding warning labels to the garage door remote (the equivalent of training an operator in a manufacturing plant), which might lower the Occurrence rate a point but wouldn’t significantly lower the overall risk of damaging a vehicle. A truly effective countermeasure in this case, and the one actually implemented with most garage door systems, would be a photoelectric sensor to detect the presence of anything underneath the door. If the door is being lowered and the sensor detects an object in the door’s path, the circuit that powers the garage door will be automatically opened, causing the door to stop.
Planned countermeasures are noted in the far-right columns of the PFMEA, and there is also a place for the anticipated RPN values following countermeasure implementation. In this case, the adjusted RPN values might be:
Process Step: Lowering the garage door (photoelectric sensor implemented)
Potential Failure Mode: Garage door lowers onto vehicle
Effect: Significant damage to vehicle
Severity: 9 (the effect of a garage door lowering onto a car doesn’t change)
Occurrence: 6 (homeowners will be just as likely to press the “down” but on the remote at the wrong time)
Detection: 1 (certain)
RPN = 9 X 6 X 1 = 54
The team has successfully lowered the risks associated with garage doors damaging vehicles, and can know that they have made a true difference for their customers and their company’s product liability costs.
Conducting a PFMEA
Just like team selection is crucial to a successful Six Sigma project, it is equally important to holding an effective PFMEA session. The following preparation steps can make all the difference conducting a worthwhile PFMEA session –
- Find a good facilitator who can keep the process moving. Teams tend to get bogged down deciding on Severity, Occurrence, and Detection values – this can make the PFMEA process painfully long and cause the participants to avoid future sessions. Our rule of thumb is to go with the higher Severity, Occurrence, and Detection values when the team is in doubt – it’s better to assume the risk is higher and therefore address it with countermeasures.
- Bring design engineering and process engineering knowledge to the PFMEA session – design engineering to help with Severity levels, and process engineering to help with occurrence and detection levels.
- Pass out hard-copies of the Severity, Occurrence, and Detection criteria (as noted above) at the start of the meeting and review these criteria with the team.
- Make sure a Process Flow Diagram is done prior to the PFMEA.
PFMEA spreadsheets are typically sorted in descending order of Risk Priority Number (RPN) at the end of the session, and time is spent brainstorming and planning countermeasures for the high RPN values. Many businesses have a maximum allowable RPN value for any process, such as 100 or 200, and process development teams (or Six Sigma Teams for existing processes) are charged with implementing effective countermeasures on all high-risk process steps. Most PFMEA spreadsheets include additional columns that show revised risk levels based on planned countermeasures.
Lastly, the PFMEA should be maintained as a “living document” and kept up to date as more knowledge is gained around true Severity-Occurrence-Detection values and countermeasure effectiveness.
How to Assess the “Quality” of a PFMEA
For those assessing the quality of PFMEA’s submitted to them (i.e. from suppliers), here are a few guidelines that will help –
1. The team has done something about the high RPN’s: countermeasures and updated RPN values are documented.
2. The steps in the PFMEA are matched up with a detailed process flow diagram. This is a sign that the team was thorough, and did not lump several process steps together to get through the exercise.
3. Severity, Occurrence, and Detection values are realistic. Ask the team how they came up with the values, and make sure they have not biased the values to the low end to get through the exercise to avoid countermeasure work.