Efficiently Managing Knowledge with FMEA
Failure mode and effects analysis (FMEA) is primarily associated with technical risk management. This statement may be absolutely true when it comes to the objective, but it misleads one to overlook the real essence of risk management:
In an environment shaped by technology, ignorance is equated to risk. The generation of know-how or the access to expertise is the yellow brick road to minimizing risks.
I believe this relationship can be succinctly put as: “A knowledge gap is a risk – and a risk is a knowledge gap.”
FMEA’s structured approach and its seven defined steps are thus a highly efficient way to represent knowledge and ignorance and to close knowledge gaps in a targeted manner (prevention and detection controls).
The specific steps include:
Step 1: Planning and preparation
The aspects of knowledge covered in this step include:
- Boundary/block diagram (extraction of the analysis object)
- Identification of the analysis object’s internal and external interfaces
- Categorization of these interfaces (inter-exchange between energy, signals, materials; physical contact, man-machine interfaces)
Step 2: Structure analysis:
The analysis object is broken down into functional subsystems, components, and parts. A functional understanding of the system is to be developed here in a very particular knowledge-intensive process, especially in the case of the established notions surrounding department and BOM lists. Technical systems with extensive software capabilities and/or those which are driven by media in particular (air, water, etc.) have a very challenging time with the knowledge.
Step 3: Function analysis
Function analysis is the main focus of innovation, risk, and quality management. A model of the physical reality of a planned technical system is created.
Leaving out colloquial language is an essential requirement. For example: A pen doesn’t write, and a car is not filled up.
Linking functions across all levels of a technical system is the core of knowledge management.
Having a near-complete understanding of how all functions are broken down into subsystems is required. The challenge of dealing accurately with language is comparable to developing general technical specifications or specific performance specifications or design specifications within the scope of development projects. FMEA verifies the design specifications.
The strategic management of requirements poses a special challenge. Requirements don’t define functions; instead, they limit or specify them. If these requirements are treated as functions in the function analysis, then FMEA ends in disaster. Most of the time, things are deconstructed for no reason at all, thereby leading to meaningless cause, failure, and effect relationships in the next step.
The FMEA becomes huge and has no substance on the inside. Example: Ensuring non-corrosiveness.
This requirement can be associated with a large number of system elements and, in the worst case, is “looped through” over several levels. The next step often involves illogical reasoning: Cause: Corrosion of a part; type of failure: Corrosion of a component; effect: Corrosion of the entire system.
Please never deal with requirements and their invalidation in this way!
Step 4: Failure analysis
Based on a lot of knowledge, cause, failure, and effect relationships are established here by invalidating functions on all levels and their logical connections. This step is nowhere as difficult as the function analysis! Proper cause and failure relationships can be identified here as long as the functions are properly broken down on a physical basis. The invalidated requirements can be effectively utilized at this point: The failure is not merely about invalidating the function, but represents the knowledge under which conditions the function fails (e.g., by not realizing the required temperature range for the function).
Step 5: Risk assessment
Prevention measures are allocated to the causes in this step in a knowledge-intensive process and then they are assessed in terms of efficacy. The second variable of risk minimization is used to develop test cases to verify the functions and validate the requirements. The effectiveness of these measures is also evaluated. The prevention measures cover the entire spectrum of engineering.Typical examples include simulations, calculations, benchmark studies, and much, much more.All prevention strategies inherently involve generating knowledge to be used within the framework of the development project in order to make the system design robust.
Step 6: System optimization
This is an optional step. Based on the results of Step 5, it may be necessary to further minimize identified risks. Additional prevention and/or verification/validation measurements must also be developed. This step isn’t a challenge in terms of methodology, but is probably the biggest challenge for the development team when it comes to content.Additional safeguards that hadn’t yet been pursued must be developed. Finally, these measures must always include root-cause probabilities of occurrence and/or improved detection procedures during product development.
Step 7: Risk communication
This step involves bundling together the many detailed risks of FMEA into one overview of knowledge and preparing it for stakeholders (management, auditors, regulatory authorities, etc.)
In this case, graphic elements, such as two- and three-dimensional risk matrices, are the preferred form for presenting knowledge. Decision-makers can thus be provided with all the essential findings of the risk analysis on one page.In my opinion, this is also just another form of managing knowledge.
Lastly, I must point out that innovations are always associated with risks and it is obviously not an option to omit them. On the one hand, risk management generates knowledge so that effective decisions based on risk can be made to realize innovations and, on the other hand, to offer the user of the innovation and other stakeholders an expected level of security.