In this article:
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:
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:
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:
There are two important aspects of FMEA that make a good starting point of discussions. These are the what and the who of FMEA.
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.
You need to perform FMEA under the following circumstances:
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
FMEA starts with Failure Mode identification. In FMEA terms, this means looking at the Design or Process at
Subsequent to identifying the Failure Mode, each failure mode should be then taken individually for discussions and the following aspects addressed:
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.
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: firstname.lastname@example.org or through us at email@example.com