Using Risk Ranking Logic in FMEAs

As the Failure Mode and Effects Analysis (FMEA) methodology is continuously adopted within an ever growing range of diverse organizations
and industries, the related theory, standards and practices have evolved with this growth. One of the more common changes that has recently been
observed within many modern FMEA standards is the migration away from the traditional Risk Priority Number (RPN) scoring mechanism used within
FMEAs as a way to measure relative risk. As companies hone in on specific risk mitigation strategies, improved methods to identify risk become
more important and highlight the shortcomings of the RPN and Severity times Occurrence (SxO) approaches.
This article shows how you can use the tools provided in Xfmea to better use the RPN values.

Definition of RPN

RPNs are a numerical product from the following three rating scales, each of which are generally (but not always) on a 1-10 scale:

Severity rates the impact of the effect of the related failure mode based on a relative scale.

Occurrence rates the likelihood of the failure mode and its related cause to be encountered.

Detection rates the ability to detect a failure mode and related cause prior to it reaching the end user.

The primary issue with the RPN approach is that you end up with numbers that when reviewed as a threshold or sorting mechanism
do not have any specific risk meaning.

Example of Limitations in RPN

To illustrate this, consider the following example:

If we look at a failure mode that has a related effect with a severity of 9, with a cause that has been rated as a 3 for
the likelihood of occurrence and a 4 for the likelihood of detecting the cause, we end up with an RPN of 108 (9 x 3 x 4 = 108).
For most FMEA standards, this would indicate that there is a potential safety or regulatory issue that is expected to occur
sporadically and is often, but not always, detected before the end user experiences the issue.

However, if we look at a failure mode with a related effect with a severity of 3, with a cause that has been rated as
a 4 for the likelihood of occurrence and a 9 for the likelihood of detecting the cause, we end up with the same RPN
value (3 x 4 x 9 = 108). This is for an annoyance or inconvenience issue that is expected to occur regularly and, for most scenarios,
cannot be detected prior to the user experiencing it.

These two scenarios are quite different when related to potential risk mitigation. The first has the ability to result in a product
or process that results in immediate potential for safety or regulatory risk, whereas the second is a frequently experienced nuisance.
While both may have financial consequences and should be addressed, a threshold system that focuses solely on RPN will initially weight
and report them as equal.

Due to these types of overlaps, the ability to effectively compare RPN scores requires knowledge of the values that produce the score.
As a result, many steps have been taken to introduce a more logic-based scoring system for more accurately reflecting the underlying
potential risk based on the contributing variables.

Using Risk Ranking Logic and Risk Matrix

Xfmea has had the ability to utilize risk ranking logic for many years, and has recently seen an increase in the number of users adopting this feature
when performing their FMEAs. Within the risk ranking logic you can have as many ranking priority criteria as you need, meaning that you can
follow the general red/yellow/green stoplight approach, or you can have red (safety), orange (high risk), yellow (medium risk), green (low
risk), or any other combination or number of configurations. For example, you could create the ranking shown next, which starts by
defining all severity 9 and 10 issues as High risk, regardless of the occurrence and severity values. (To define
or modify the risk ranking logic in the current project, first choose Project > Management > Configurable Settings > Interface
Style to open the interface style. Then navigate to the FMEA > RPNs page and click the Risk Ranking Logic button.)

Beginning in Version 10, Xfmea introduced the ability to show a colorized logical risk matrix of the Severity x Occurrence and
Severity x Detection results. The Risk Matrix (System Hierarchy > Tools > Risk Matrix) highlights the ability to put an
increased focus and effort on those areas that are most important to the organization performing the FMEA. This allows the software to
assist the FMEA team to follow-up with appropriate action strategies.

Xfmea combines the two features of risk ranking logic and the risk matrix. With the risk ranking logic you can set as many criteria as you
need and then use the risk matrix to give you a visual heat chart of your risk, as well as a tally of the number of causes for each combination
of ratings.

Note that the standard approaches to identifying and prioritizing risk in FMEAs should be followed when establishing how to shape your risk
ranking logic matrix. While all high severity items should always be addressed and responded to, reasonably high severity with middling occurrence
or detection scores should also have appropriate levels of response. What the risk ranking approach is capable of doing is emphasizing the importance
of the potential severity of the effect and the related failure mode.

Conclusions

The approach for utilizing risk ranking logic along with a custom risk matrix does not revolutionize the FMEA process. However, when used properly
it does have the ability to streamline the process by helping to prioritize your risk mitigation responses into a methodology which can be useful for
both practitioners and management for identifying, acting on and following up on those failure modes and effects that present a specific risk profile
for your industry and products.