Visure Solutions


Support
Register
Login
Start Free Trial

How to Efficiently Conduct an FMEA Process?

Table of Contents

What is FMEA?

The failure mode is how a specific thing might fail. Failures occur due to an error or mistake during development. Effect analysis is the study of the outcomes or consequences of those failures. They together make Failure Mode and Effect Analysis (FMEA). 

The main aim of FMEA is to take necessary actions to mitigate or minimize the failures as much as possible. The process begins with the ones of the utmost priority. It also prepares documentation that includes details like current knowledge, actions about risks of failures, and areas for improvement. This data is used to evaluate and prepare strategies for avoiding failures. Ideally, the process of FMEA commences during the early stages of designing and continues throughout the product life cycle. 

How to efficiently apply FMEA?

The following are the steps one could take to complete an FMEA efficiently:

  1. Enter the process input
  2. Identify the potential failure mode for each and every component and the equivalent functions
  3. Determine the potential failure effects with each mode of failure
  4. Now, determine the root cause for each failure mode. You can use some Root Cause Analysis Tools for this.
  5. Then for each cause, identify current process controls. These controls are mechanisms that you have in place to keep the failures from reaching the users
  1. Assign the severity rankings to each identified effect. The rankings can be divided into the followings:
    • Minor – Minor severity level means that it is unlikely for the failure to cause any real effect on the product or the users, for that matter. On a scale of 1 to 10, the minor severity level can be ranked as 1. 
    • Low – Low severity level means that the failure would end up causing some slight annoyance among the consumers through the reduced performance of the product while still being operable. On a scale of 1 to 10, the low severity level can be ranked as 2 or 3.  
    • Moderate – Moderate severity level is when there is about an average degree of dissatisfaction caused among the consumers via gradual performance degradation of the product. This severity level may cause reworks or damage to the product. If we are to depict the moderate severity level in numerical terms, it would stand to be between 4 and 6. 
    • High – High severity rate is when the level of dissatisfaction caused by the failure of the product among the consumers is high. Though it does not involve risks like the safety of people, products, or laws, it can cause disruption to various subsequent procedures and would require some rework. The high severity level can be depicted as 7 or 8 on a numerical scale of 1 to 10. 
    • Very High – Very high severity rate is when the product’s failure affects the safety of people, products, or laws. As a result, this type of failure can cause safety-related catastrophic effects. A very high level of severity would be ranked as 9 if there is a warning involved and 10 if there is no warning involved. 
  1. Assign the occurrence ranking to each identified cause. Occurrence in FMEA measures the likelihood of the failure mode caused will be present in the item being analyzed. Alike severity, the occurrence can be measured and categorized using numerals.
    • Minor – In the minor occurrence level, the likelihood of failure is least expected and the possibilities are zero. On a scale of 1 to 10, the minor occurrences are ranked as 1. 
    • Very Low – In the very low occurrence level, the likelihood of failure is very low. On a scale of 1 to 10, very low occurrences are ranked as 2. 
    • Low – In the low occurrence level, the likelihood of failure is isolated and lowly expected. On a scale of 1 to 10, the low occurrences are ranked as 3 or 4. 
    • Moderate – In a moderate occurrence level, the likelihood of failure is a bit more but not in very high quantity. On a scale of 1 to 10, the moderate occurrences are ranked as 5, 6, or 7. 
    • High – At a high occurrence level, the likelihood of failure is often and considerably affects the performance of the product. On a scale of 1 to 10, the high occurrences are ranked as 8 or 9. 
    • Very High – In a very high occurrence level, failure is determined to occur each and every time the product is being used. On a scale of 1 to 10, very high occurrences are ranked as 10. 
  1. Assign the detection ranking to each identified control. The ranking is done on the basis of the certainty of the failure detection. The numerical categorization is done as follows:
    • Very High – Very high detection level is measured as I or 2 which means that the failure will certainly be detected before reaching the next level of the process or the users. 
    • High – High detection level is when your system has a strong possibility of detecting the failure before it reaches the end-users. The measurement of high detection level is depicted as 3 or 4. 
    • Moderate – Moderate detection level is when the possibility that the existing system will detect the failure is moderate. They might be able to detect the failure but it is not certain that they would. The moderate detection level is depicted as 5 or 6 on a scale of 1 to 10. 
    • Low –  Low detection level is when the existing system has a low chance to be able to detect the failure. Such a level is measured as 7 or 8 on the detection scale of 1 to 10. 
    • Very Low – Very low detection level is when the existing system has a strong possibility that it won’t be able to detect the failures. It is depicted as 9 on the numerical scale. 
    • No Chance – This detection level is when there are zero chances that the existing would be able to detect the failure. Such detection level is rated as 10 on the numerical scale.
  1. Calculate the RPN (Risk Priority Number). Risk Priority Number, abbreviated as RPN, is a method for measuring the priority level of risk of the failure mode in FMEA. 
RPN = S * O * D

Where, 

  • RPN – Risk Priority Number
  • S – Severity
  • O – Occurrence
  • D – Detection
  1. Now, develop an action plan
  2. Now, decide the people who will be responsible for the deadlines
  3. Execute the action plan
  4. Finally, recalculate the RPN, and reassess the severity, occurrence, and detection rankings for the failure mode. 

Putting it all together…

FMEA is a must process among engineering teams. However, we strongly recommend for it be performed by an ALM Tool to help you remove the administrative overhead of maintaining multiple documents and sharing them between individual stakeholders.

An ALM platform helps in supporting any Requirements level mitigation of risks detection with built-in RPN calculation, putting one platform for all requirements-related activities.

It also should provide a risk dashboard with reports for all levels of the system, all easy to access with a couple of clicks and support for better quality, reduced risk, and avoiding possible failures.

At Visure, our modern ALM platform, seamlessly connects the FMEA and risk management with requirements, enabling you to follow the evolution of the Requirements over time and over the full Requirements lifecycle.

The ALM platform that your entire engineering team will love, helping them avoid project failures and automate repetitive tasks.

Visure is one of the most trusted modern ALM platforms that specialize in requirements management for organizations of all sizes across the globe. 

It’s a must-have tool for teams building complex products, systems, and software, which require end-to-end traceability from conception to testing and deployment, all the way to source code, along with standard certification compliance.

Visure integrates through the whole ALM processes including risk management, issue and defect tracking, traceability management, change management, and various other areas like quality analysis, requirements versioning, and powerful reporting. 

Don’t forget to share this post!

IBM Rational Doors Software
Top

The High Cost of Poor Requirements Management

June 06th, 2024

11 am EST | 5 pm CET | 8 am PST

Louis Arduin

Louis Arduin

Main Speaker

Impact & Solutions for Inefficient Requirements Management

Explore the significant impact that inefficient requirements management practices can have on project costs and timelines.