Symphony Technologies

Failure Mode & Effects Analysis:
A Technique to Effectively Mitigate Risks  

The Process of FMEA

In this article:

Why perform FMEA?

FMEA helps you to reduce failures in things that you make and the work that you do. It is a scientific way to ensure that things don’t fail and work gets done the way you want it. Things that you make are products, work that you do is a process. FMEA thus assures you failure-free products and processes.

FMEA is done in the following two steps:

  • Identify potential failures; identify their impact, and all the causes that are leading to such failures.
  • Take proactive steps to prevent the failures from occurring.
It is useful to understand the scientific way to carry out Failure Mode & Effects Analysis (FMEA), and to understand the technical terminology that goes with it. It makes the FMEA process easy, effective and oriented towards real risk mitigation.

Understanding the FMEA process

The figure shown above explains what Products and Processes do. It also explains the role of Design FMEA and Process FMEA.

The two major implementations of FMEA are:

  1. Design FMEA: To assure that the product works for the customer in a failure-free manner.
  2. Process FMEA: To assure that a process is able to create the product in a failure-free manner.

There are instances where you offer a service to your customer rather than a product. In such you could perform a PFMEA directly addressing customers’ requirements.

There are several other variants of FMEA. They all are similar in implementation to DFMEAs or the PFMEAs.

FMEA is looked upon by many, as a document that you need to prepare. This is either to comply with a Quality Standard or a checklist of a customer. However, the benefits of FMEA will come home if it is practiced towards making products and processes defect-free and not prone to failures.

This part of the article addresses the following:

  1. When and where is FMEA used? - Understanding the scope and timing of FMEA.
  2. How should FMEA progress? - Understanding the FMEA work-flow and team implementation
The Scope and timing:

Looking at potential problems

There are two important aspects of FMEA that make a good starting point of discussions. These are the what and the who of FMEA.

  • Referring to FMEA you would be right to call it potential FMEA. The phrase potential emphasizes that while performing the analysis you need to focus on failures that can potentially happen rather than limiting yourselves to failures that have actually occurred. Leanings from failures observed in the past are also important, and must be brought into FMEA, so that recurrence of similar failures in the future is contained.
  • The team of analysts working on FMEA must use their technical knowledge to assess what can potentially go wrong. The deeper the team of analysts goes into what can potentially go wrong, the richer and more effective the FMEA process becomes. Identification of how failures could potentially occur comes from a good understanding about the process mechanics or the product physics. FMEA is thus done by persons who have expertise of some facet or other of the product or process under analysis. A generalist ‘FMEA expert’ cannot replace the product or process expert. Remember, FMEA is the means of achieving failure-free systems, not the end.

A word of caution on pre-defined libraries

There is often a practice of using pre-defined library of failures created by some expert for systems similar to the one under analysis. Predefined libraries for electronics and automotive failures are known to be available for reference. Using predefined libraries may lead to a very quick preparation of a FMEA, but would defeat the purpose of doing a FMEA towards effectiveness. You would not be doing FMEA on your system, but on the system that belongs to someone else who supplies you with canned libraries. You are then doing a FMEA only towards creating a document and not towards solving a potential problem. An in-depth analysis and understanding of the potential hazard is then missing from such implementation.

While saying this, I do not discount the importance of learning from past FMEAs and deriving future failure modes from them. These reference FMEAs need to be yours and ones where you have a clear understanding of what has happened in the past.

To keep terms simple, in this article, we shall generically refer to the product or process under analysis as the system being analyzed.

Applications and Scope

You need to perform FMEA under the following circumstances:

  1. When introducing a completely new system.
  2. When modifying an existing system.
  3. When an existing system is to be used under a new environment or for new application.

FMEA needs to be done to assess the impact of any change in the design or application, and to make sure that the system remains suitable and useful to the customer after the changes are made.

A product or a process never works in isolation. It has interactions with the environment in which it functions. Such interactions may lead to failures even though the product or process by itself may be robust. It is essential to identify failures due to “knock-on” effects caused by peripheral devices failing. A system that is designed to function in isolation does not take into account peripheral devices and interaction with other processes. Change in stresses and working environment induced by peripheral systems may also lead to failures.

We shall also explore how a Design FMEA is related to a Process FMEA. A risk of failure identified in a Design FMEA triggers a risk-identification in Process FMEA.

FMEA work-flow and Team implementation

Work-flow

FMEA starts with Failure Mode identification. In FMEA terms, this means looking at the Design or Process at

  1. Design or Process Functions that satisfy the customer
  2. Technical requirements that are stipulated for the function
  3. Failure Modes that negate the Requirements

Subsequent to identifying the Failure Mode, each failure mode should be then taken individually for discussions and the following aspects addressed:

  1. Several effects of potential failure and the severity of each effect.
  2. Several causes of the potential failure and the probability of occurrence of each cause.
  3. Assigning Risk priority to each cause identified.
  4. Plan and schedule of actions to mitigate the potential risks.

The focus of the FMEA process is on preventing the failure from occurring at all, and not on fighting fires to dampen the impact of undesirable effects - should the failure occur.

Team implementation

FMEA is meant to be a team process, and should be done by a team. Each member of the team should bring her specific view to the hazard mitigation process. A diversified set of views looking at each problem makes the FMEA process richer in quality and oriented better to problem resolution.

The team needs to meet, discuss and address the problem in a collective manner. A practice where each member of the team sits in virtual isolation and punches in his view into a computer screen will hamper the richness a discussion and brings to the FMEA process. Isolation of team members also prevents exchange of ideas within the team and the analysts understanding remains limited to his own scope.

A computerized FMEA system can be used to log the results of the analysis, and effectively track progress. The discussion leading to analysis and actions however needs to be real.

The next article in this series explains the terms associated with FMEA and discusses the correct structure of the FMEA document.

Readers are welcome to interact, make suggestions and discuss the article with the author.

Author: Ravindra Khare is a Founder and Director of Symphony Technologies. He is a qualified Mechanical and Industrial Engineer and a keen student of Quality & Productivity Technology for the past 25 years. He can be contacted at e-mail address: ravi@symphonytech.com or through us at webmaster@symphonytech.com


  Share on Facebook Share on Linkedin Share on Twitter Email to Friends

 
In this series of articles on FMEA
by Ravindra Khare:

Article 1: Understanding the FMEA Process

Article 2: Structure of FMEA

Article 3: FMEA Priorities and Actions

Published July 2013.


Software from SymphonyTech

FMEA Executive

 

FMEA Executive software helps you perform Design and Process FMEA.

Thoughtfully designed features help you take your FMEA effort beyond mere documentation.

Your FMEA initiative becomes Effective and a Result oriented.

More information & Demo Download...


Privacy Policy | © Symphony Technologies Go to Top of PageTop