FMEA your designs. Not because it’s bad, but to make it even better
Quick start to create a Failure Mode Effect Analysis (FMEA)
When you are designing products, installations or processes, its key to think ahead. Asking yourself questions like: “If the end-user does this, will our design hold?”, “Will our design work in a situation like this?” and “If this situation occurs, what are the consequences?”.
In hindsight, we can utilize machine logs, root cause analysis and user feedback to improve our designs. However, this data isn’t available when designing new products, installations or processes.
Although, there is a way to proactively prevent designs from failure and it’s called FMEA. Failure Mode Effect Analysis. And the best part! Every company can quickly create this kind of analyses by making use of low code.
How Failure Mode Effect Analysis (FMEA) works
Many engineers and product designers use FMEA analyses to evaluate processes for possible failures and to prevent them by correcting the processes proactively. The basics of the Failure Mode Effect Analysis are relatively simple, although it quickly becomes more advanced and complex when organizations start using it more frequently. Let’s start with the basics.
First, what are you designing? DFMEA vs. PFMEA
Failure Mode Effect Analysis can roughly be divided in two types: DFMEA and PFMEA. DFMEA stands for Design FMEA and is the term used for failure analyses of tangible goods like machines, products and installations. FMEA can also be utilized to proactively analyze potential failures in processes. This type of FMEA is named Process FMEA or PFMEA. So, if you’re designing processes use PFMEA and when you’re designing machines, products or installations use DFMEA.
The functions and potential failures
Let’s say you’re designing an industrial oven for bakeries and decided to use DFMEA to analyze the risks of failure. Then, the first step is to describe all functions of the oven. For PFMEA we are describing steps instead of functions. These items describe the functionalities of your machine or steps within the process. For example, in the case of a bakery oven the functions are: “Pre-heating”, “Heat distribution” and “Baking timer”.
The next step is to come up with possible scenarios that could go wrong per function. This is called the failure mode. In a lot of FMEA examples failure modes are linked to one function. This doesn’t represent the real world in which multiple function could have the same failure mode. Therefore, we recommend using a low-code platform to build FMEA, but more on that later this article. Back to the failure modes. Try to come up with all possible failures. Small or big errors and common or uncommon. All the failures modes are useful to register.
Below a brief example of the functions and failure modes of our bakery oven:
Causes, their potential impact and the detection mode
When your team succeeded in summing up al potential failure modes its time to think critically about your design. What can cause failure modes and how will this impact your product, the end user, or your brand. Try to think with an open mind and be critical on your own design. Not because it is bad, but to make it even better. Again, one cause can correspond with multiple failure modes.
To calculate the risk score per function or failure mode we add two parameters to the causes and potential impact. For the potential causes we estimate the probability that this cause occurs. And for the potential impact we estimate the severity of the failure.Direct contact opnemen
Besides the potential impact of a cause, it is also recommended to think about how to detect certain causes. This is what we call the detection mode. Does your system have the right sensors to detect potential failure modes? Especially, for new product designs it is key to think about the detection mode. Maybe you do not know the potential impact yet, but at least if you are able to detect failures you are able to investigate the impact later.
An example of causes and their impact on our bakery oven:
Further investigation and mitigations
It’s nice to know what could go wrong, but it’s worthless if we do not take action on this. Therefore, the last step is to assign tasks to prevent these potential faults. In a FMEA there are two types of tasks. The “further investigation” and the “Mitigation”. The former is meant to deep dive into the failure mode and potential causes. The bigger the risks, the more time you should address to investigate the potential fault. The latter, “Mitigation”, refers to the actions your organization can take to prevent the fault from happening or to minimize the impact.
An example of the tasks arising from the FMEA:
Why low code is the key to successful FMEA
Some software programs already contain FMEA functionalities. Although, those software packages tend to be rather expensive, overcomplicated, and too standardized. Especially, the standardization of these FMEA’s are a big problem. Which can be solved by utilizing low code. Some small organizations, or bigger organizations that work around their software landscape, try to build their FMEA in excel. This works for very simple FMEA. However, using Excel for FMEA leads to:
- Decentralized, and therefore not up-to-date, product information;
- A lack of cardinalities;
- And, overcomplicated UI when the FMEA becomes more comprehensive and complex.
Use Many to Many cardinalities instead of nested items
Lots of FMEA templates contain the same issue regarding cardinalities. The FMEA is presented as an nested table and therefore we analyze the potential causes, potential impacts and the detections per failure mode. This creates doubles in the data or causes fragmentation of the risk score. Since the risk score is a sum of the severity and probability of its items.
In less technical terms. It is wise to build your FMEA in software that enables you to use Many to Many relations. Like low code does. And we can help you out with this, just contact fill out the form below or directly contact our sales.
Get the freedom to incorporate custom parameters
A big issue of big ERP and PLM systems is the lack of customization. Every organization is unique, and the software should offer the organization the freedom to customize processes like FMEA. Unfortunately, this is hardly the case.
For example, in the case of the bakery oven we want to incorporate the knowledge of the marketing department to estimate the potential impact of failure modes on our brand. With a low code platform, we can build-in an assign button to notify the marketing department to do their job. Or let’s say we want to iterate on our FMEA and include other data (e.g. user feedback) from other systems like SAP, the CRM or other tooling. Good luck with duplicating old FMEA analyses correctly in the ERP or PLM system. With low code this functionality can easily be build-in. tailored to the needs of your organization.