FMEA-Maßnahmen – Consultancy Jarosch

Wie funktioniert das mit den Maßnahmen in der FMEA?

Classifying prevention and detection actions in product and process development

A feature by Dr. Uwe-Klaus Jarosch, updated October 2025

Warning: From here on, you should read carefully if you are quite familiar with FMEA.

For those who can spell FMEA but otherwise have no idea what it is, thank you for your interest.

Briefly, the basic idea of FMEA for proactive risk reduction:

Our team considered what exactly we wanted to look at and carried out a structural analysis in which the systems, subsystems, assemblies, connections, individual parts, process steps, and causes to be considered were broken down. Then we assigned tasks = functions to these system elements and considered what could go wrong in the fulfillment of these tasks. We call these two steps functional and failure analysis. Both end with us weaving a network between possible failure cases of the various system elements in order to build chains of causes and effects using the team’s knowledge.

Murphy: What can happen will happen

We are certain about the functions as targets.

The errors do not have to occur, but they will occur with a certain probability, and the less the development team does to prevent them, the more frequently they will occur.

Murphy: What can happen will happen.

What the development team does is reflected in the actions. We generally know of two types: preventive and detective actions.

If one of these potential errors occurs at one of the upper levels of the structure tree, i.e., if the product does not function as it should or if the process produces something that is not wanted, desired, or needed, then we see an effect of the error chain and consider a symptom, just as sneezing is a symptom of a possible cold or was triggered by another stimulus.

For the external or internal customer, this symptom represents the problem.

For the team of specialists, however, the task is to identify and eliminate the causes of the symptom.

If we want this symptom to stop occurring, we need to understand why it occurred. Only then can we take effective actions.

But what are effective actions?

1) Effective actions identify the root cause of the problem.

2) Effective actions are actions that prevent the root causes from taking effect. These can be preventive actions, e.g., a constructive change, protection against errors in the process, a poka-yoke.

3) However, they can also be detection actions that do not rule out a causal error but detect it with the highest possible certainty when it has occurred and then trigger a response.

4) Or it can be a combination of avoidance and detection, a control loop: Detection provides information about what the product can do and where the process stands, and the avoidance action uses this information to respond appropriately and act as a regulator. Such a control loop then has at least two actions, preferably of equal value, which together keep the cause, or perhaps only the result of the next stage, within the target range.

Against Root Causes

The term root cause is important for FMEA and requires a common understanding within the team:

If you use the why-why-why chain to search for causes, you can create a never-ending story. And the lack of a stamp becomes the cause of the company’s crash.

This is not conducive to solving a technical or procedural task, as is usually investigated with an FMEA.

When it comes to root causes, three cases can be clearly distinguished:

The system view deals with tasks at the next system level. I would like to categorize the lowest level with the term “specification sheet.” This is where the list of all functions and requirements that the next working group, possibly my development supplier, is to fulfill is written down. And it should be supplemented by the actions that only take effect or are possible during system integration, e.g., after all subsystems have been assembled.
The details of the product are developed in the design FMEA. The development is based on the specification of the product characteristics that appear on the drawing. The functional and manufacturable definition of the numerous product characteristics represents the lowest level of action. In individual cases, this may also concern process characteristics that were specified by the design.
In the process FMEA, the product characteristics are “manufactured.” They are the result at the focus level (second lowest level). The causes in the process can be categorized using the 4Ms (man, machine, material, environment). There, it is ALWAYS process features, influences in the process, that need to be controlled.

What are the possible errors at the root cause level?

In the system FMEA, the function or requirement for the next level may be incorrect, incomplete, incomprehensible, not specified, or not communicated.
The DFMEA is about the meaningful definition of product characteristics and, where necessary, some process characteristics. In my opinion, these cannot fulfill the overarching function and/or impair manufacturability/feasibility. What good is it if the product only works as a golden part or if the required tolerances cannot be met with the intended means and costs? In many areas, product development is a compromise that is expressed in these categories.
The error “feature out of tolerance” is irrelevant in design. This only occurs in the process.
In the process, we are in the implementation phase. All features, both those of the results and those of the process, are specified and may still be in the optimization stage. Then “feature out of tolerance” is relevant. However, it depends on the type of characteristic: characteristics limited on both sides can be too large or too small, while those limited on one side can be too large or too small. Attributive characteristics, where only OK and NOK are distinguished, are out of tolerance. But a lesson for maximum and minimum dimensions provides information about “too large” and “too small.”

This is important because “too large” and “too small” have different consequences and, at the focus level, different causes. And for the process characteristics, the response must be different depending on the boundary condition.

There is another aspect to consider for the process characteristics: in order to keep the process running permanently, the category of warning and intervention limits has been introduced. In this case, the result is not yet at risk. But with the necessary response time, the set warning limit or the dynamically determined intervention limit triggers response measures to remain within the specification limits of the process parameters.

Everything clear so far ?

According to the current FMEA methodology (1) , the preventive action must ALWAYS refer to the potential error at the cause level. No symptom control is permitted.

(1) refer to AIAG/VDA FMEA Manual (2019)

For the detection actions, i.e., measurements, human evaluations, tests (2), the methodology stipulates that the cause and/or result of the next level (focus level) be evaluated alternatively or additionally.
(2) The test is a combination of measurement or evaluation and comparison with a target value limit in order to distinguish between OK and not OK.

This is because not all influences may be known, considered, relevant, understood, or controlled. In such cases, it is not sufficient to consider all the identified causes. In addition, I must consider the result of the next level. In design, this is the required function, including its constraints (3). In the process, it is the product characteristic that is the result after the process step.
(3) These applicable requirements do not describe why I am doing or need something, but they do specify limits, the violation of which is also considered an error.

Several actions may be necessary for both prevention and detection. These actions work together, perhaps at different times, but if one action were missing, the result would be worse.

In today’s method description, an evaluation score is then formed.

The first evaluation number evaluates the effect of all prevention actions and is referred to as occurrence A.

The second evaluation number evaluates the effectiveness of all detection actions and is referred to as detection E.

When developing the FMEA, most actions are still in the planning stage (4). The evaluation of A and E is therefore an “educated guess,” an estimate based on experience.
(4) Otherwise, the FMEA is in progress at a point in time when all decisions have been made and it is advisable to save yourself the work.

There are criteria in the evaluation catalogs for estimating A and E between 1 for “absolutely certain” and 10 for “no effective action available.”

Personal experience and “political” considerations (5) always make this evaluation subjective.
(5) Do I want to look as good as possible, or do I want to realistically depict “worst-case scenarios,” or do I tend to systematically “paint a bleak picture”?

Some questions remain unanswered:

If the discovery of the consequence at the focus level and the cause are jointly evaluated by several discovery measures in the E value, what does this number evaluate?

The slip in the process characteristics or the slip in the product characteristics?

Don’t the discoveries of the causes always provide upstream assurance for the results, regardless of whether they are a function in the product or a product characteristic in the process? And aren’t these discoveries of the causes then rather avoidance measures for the next higher level (6)?
(6) This is a fundamental question. Teams intuitively assess the impact of the action and then no longer distinguish between the collection of information (EM) and the use of information (VM). However, this removes the definition of EM and VM, which is also practiced in some industries. For example, in medical technology, no distinction is made between EM and VM.

How is the effect in a control loop evaluated, i.e., the interaction of discovery and avoidance?
Would it not be necessary to consider and evaluate the quality of measurement/testing separately at the cause and focus levels?
How should this be handled if the identical discovery measure is applied to both cause and effect (7)?
(7) Personally, I have had good experiences with a strict separation. This allows me to precisely identify the set of actions necessary for preparation, detection, and response.

And how are the required tests included that are not performed at the cause or focus level, but higher up at the partial or overall system level? What details at the lower levels can still be discovered with these tests? And are such tests included in the E-assessment at the cause level?
How do we deal with random findings (8) ?
(8) This case is also simple: incidental findings are irrelevant for FMEA consideration. We only consider planned detection measures. If the boss’s rounds take place reliably every morning and are carried out by his deputy during his vacation, then yes: this is a planned EM.

How should audits be evaluated (9)?
(9) Opinions differ here, although there are clear recommendations: Audits are planned checks, but they are usually used to check working methods, not specific results. They are therefore not suitable as a specific quality assurance action that reduces the slippage of the detection measure.
How detailed must a test plan be in order to evaluate the effectiveness of the EM? What role do the origin of test samples, the sample size, and the frequency of testing play? The quality and suitability of test equipment and test systems also influence the probability of detection.
When is it justified to assign an E=1, i.e., to assume a flawless EM without any slip?

Conclusions:

As you can see, the method description provides guidance, but it does not answer all questions by any means.

Some things will remain unclear, as in addition to the description of the action, its evaluation also shows a significant range of variation.
Some things are simply unknown and are only entered and evaluated on the basis of assumptions or hopes.
But with the logic of FMEA, one must conclude that problems always have their cause in the details.

Stay curious.
Uwe Jarosch