# This Month's Theme is Is there a better way than RPN?

Note from the author:

I began writing the FMEA Corner series of articles in October 2013. I have long had a passion for the subject of FMEA, and wanted to share my experiences with readers. The idea was each month to highlight one FMEA concept, add application information and tips, and end with a selected Q and A from a reader. I sincerely hope it has been helpful to you as FMEA practitioners.

This month marks the 51st and final article written for HotWire in this series. It has been a joy sharing information about FMEA fundamentals and applications with the readership of HotWire.

I will continue to answer any and all questions on the subject of FMEA. If you have questions or comments, please send them to carl.carlson@effectivefmeas.com.

As I say to my FMEA students at the conclusion of each FMEA course, "Best wishes for effective FMEAs!"

Carl Carlson

"Any goal worth achieving involves an element of risk." - Dean Karnazes

Risk [risk, noun]
The ISO 31000 (2009) Risk Management document says that "risk is the effect of uncertainty on objectives." Another definition is "the possibility that something unpleasant will happen." (Oxford English Dictionary)

Pri·or·i·ty [prai-awr-i-tee, noun]
Priority is defined as "the fact or condition of being regarded or treated as more important than others." (Oxford English Dictionary)

Num·ber [nuhm-buhr, noun]
Number is defined as "a quantity or amount."

## What is RPN?

SAE J1739 (2009) page 12 states:

The risk priority number (RPN) is the product of the severity (S), occurrence (O), and detection (D) ranking.

Risk priority number is one of many tools available to a team for evaluating potential risk.

Applying RPN thresholds assumes that RPNs are a measure of relative risk (which they often are not) and that continuous improvement is not required (which it is).

AIAG v4 page 57 states:

One approach to assist in action prioritization has been to use the Risk Priority Number:

RPN = Severity (S) x Occurrence (O) x Detection (D)

The use of RPN threshold is NOT a recommended practice for determining the need for actions.

MIL-STD-1629A does not use RPN. It uses Criticality, which is comprised of severity and occurrence. Note that MIL-STD-1629A was cancelled in November 1984.

Although the VDA publication Product and Process FMEA has a section titled "Risk Priority Number" and defines it similarly to SAE and AIAG, it says, "In many cases inspection of the absolute value of risk priority number is misleading, and not appropriate as the basis for further actions."

## What are the limitations of RPN?

The FMEA Corner article in Issue 161 describes the limitations of RPN. They are repeated here.

There are limitations to the usefulness of RPNs, and FMEA teams need to understand the limitations. These include:

1. High severity by itself – High severity is high risk, regardless of the RPN value. Therefore, it is always necessary to address high severity in addition to high RPN.
2. Subjectivity of RPN - Since the components of RPN (severity, occurrence and detection) are each subjective ratings, the RPN value is subjective in nature. It has application only in helping the FMEA team prioritize issues for corrective action within a given FMEA, and cannot be used to assess risk across different FMEAs.
3. Limitations of detection – The detection scale is controversial for some companies and practitioners, and as a result, some have chosen not to use the detection ranking at all. Some companies use the severity and occurrence scales (without detection) and then prioritize issues by the product of SxO, called "criticality." If the FMEA team chooses to use SxO instead of RPN, then the team needs to consider how to address the risk associated with detection.
4. Duplicate RPN numbers - All possible products of S, O and D include many duplicate numbers. For example, a severity of 1, occurrence of 8 and detection of 8 has the same RPN value as a severity of 8, occurrence of 4 and detection of 2. Clearly, there is very different risk associated with each of these examples.
5. RPN thresholds - It is enticing for management to use thresholds for RPN values and require defined action if the RPN value exceeds the given threshold. In most cases, this is a flawed approach, as it can easily become a numbers game.

The most critical limitation is the first one discussed above. High severity, low RPN, can be very serious. For this reason alone, FMEA practitioners should be cautious of relying on RPN as the sole measure of risk prioritization.

## Is there a better way than RPN?

One of the problems with RPN is that it purports to be a single number representing the prioritization of risk in an entire FMEA. There is no single number that can represent the entirety of risk in an FMEA.

An alternative to RPN is prioritizing actions based on the various combinations of severity, occurrence and detection. This has sometimes been called Action Priority, or in the case of Xfmea, Risk Ranking Logic.

Individual companies can review the various combinations of S, O and D, and assign red, yellow, green (or other variable designations) to the combinations. This can be done to each of the SOD combinations (a lengthy task) or to ranges of S, O and D combinations (a shorter task). There is no set combination of S, O and D (and corresponding red, yellow, green), that applies uniformly to all companies. It should depend on company policy and priorities.

## How can Xfmea support Risk Ranking Logic?

To enable Risk Ranking Logic in Xfmea, choose Project > Management > Configurable Settings > Interface Style. Then navigate to the FMEA > RPNs page.

Click the Risk Ranking Logic button, then for each row enter criteria for SOD combinations according to company policy. You can also edit which colors you want associated with the levels of risk.

## FMEA Tip

If you are using RPN to prioritize risk, always address high-severity issues first, regardless of RPN. Once high-severity issues are addressed, you can take up high RPNs.

## Something I’ve always wanted to know about FMEAsThe important thing is not to stop questioning. - Albert Einstein

A reader submitted the following question to Carl Carlson. To submit your own question about any aspect of FMEA theory or application, e-mail Carl at carl.carlson@effectivefmeas.com.

How do you know when an FMEA is complete?

Carl: That is a very good question. Here's my answer.

An individual FMEA is completed when the recommended actions for that FMEA are implemented, and the risk is reduced to an acceptable level.

This brings up the subject of "living FMEA." What do you do with subsequent test and/or field problems that occur after the current FMEA has been implemented? Can the current FMEA become a "living FMEA," and act as a repository for post-analysis test and/or field problems?

Some FMEA references refer to the phrase "living document" or "living FMEA." The intent is to make the FMEA a repository for the latest failure information within the scope of the FMEA. When this strategy is used, the FMEA is updated with test or field failures that occur after the product has been tested and launched, so that future FMEAs will benefit from this information.

The "living FMEA" strategy can work for product lines with a single primary design. It does not work as well for product lines with multiple design variants. Take a hypothetical example of ABS brakes. The ABS subsystem for the model X is not the same as the ABS subsystem for the model Y or Z. If a DFMEA is performed on the ABS subsystem for model X, and there is a subsequent field problem that was not addressed in this DFMEA, using the "living FMEA" strategy, the DFMEA for model X ABS brakes is modified to incorporate the field issue. The problem is that the DFMEAs for the ABS subsystem for model Y and Z were not modified. When the next versions of the model Y and Z are being designed, the ABS subsystem for the model Y and Z will not benefit from the latest field information.

One solution for ensuring test and field problems are captured in future FMEAs is to use a "generic FMEA." Here is an excerpt from chapter 11 of my book:

Generic FMEAs are FMEAs that contain both historical (empirical) and potential failure modes, causes, controls, etc. They are done at the generic level of the system, subsystem or component, not at the program-specific level. Most often, they are done once; then they are updated when needed from test and field data and/or new technology. The purpose is to support a learning organization, retain the lessons learned from test and field, and make it easier to generate program-specific FMEAs in the future.

Regardless of whether a generic FMEA is used, known field problems must be input to future DFMEAs as part of the preparation process. Reference the paragraph on "Field History" as part of preparation for new FMEAs, in my FMEA Corner article written for Issue 167 of HotWire.

### About the Author

Carl S. Carlson is a consultant and instructor in the areas of FMEA, reliability program planning and other reliability engineering disciplines. He has 35 years of experience in reliability testing, engineering and management positions, and is currently supporting clients from a wide variety of industries, including clients of HBM Prenscia. Previously, he worked at General Motors, most recently senior manager for the Advanced Reliability Group. His responsibilities included FMEAs for North American operations, developing and implementing advanced reliability methods and managing teams of reliability engineers. Previous to General Motors, he worked as a Research and Development Engineer for Litton Systems, Inertial Navigation Division. Mr. Carlson co-chaired the cross-industry team that developed the commercial FMEA standard (SAE J1739, 2002 version), participated in the development of SAE JA 1000/1 Reliability Program Standard Implementation Guide, served for five years as Vice Chair for the SAE's G-11 Reliability Division and was a four-year member of the Reliability and Maintainability Symposium (RAMS) Advisory Board. He holds a B.S. in Mechanical Engineering from the University of Michigan and completed the 2-course Reliability Engineering sequence from the University of Maryland's Masters in Reliability Engineering program. He is a Senior Member of ASQ and a Certified Reliability Engineer.

Selected material for FMEA Corner articles is excerpted from the book Effective FMEAs, published by John Wiley & Sons, ©2012. Information about the book Effective FMEAs, along with useful FMEA aids, links and checklists can be found on www.effectivefmeas.com. Carl Carlson can be reached at carl.carlson@effectivefmeas.com.