Praise the Internet and the invention of the smartphone. Once you have experienced how enormous the benefits of centralized data storage can be, desktop solutions lose their charm.
Due to the high goals we want to achieve through the use of FMEA's, it is absolutely necessary to support this method using an application that actively helps users to enter all system relationships simply and clearly and build corresponding networks.
We all know for sure: the FMEA is not alone in the development process. Due to the central role it plays in the system modeling process, an FMEA can only be a success when it's a team player. It needs to leave its methodical and somewhat monolithic comfort zone!
Here are my reasons why:
Appization as a model
With the "appization" of our world of data, we experience every day how simply the apps we use interact and work together without us having to put very much effort into the process.
A new generation of engineers
The generation that has grown up with these technologies and takes these web applications for granted is taking over the helm step by step. This generation does not understand why it should use individual, stand-alone applications.
Networked life
Our lives are becoming more and more networked. At the same time, it is becoming less and less important where we work or where our data is stored. All we need is access to the Internet and we can get to work. As a result, our jobs are becoming more and more independent of time, space, and "IT systems". Working together using secure web applications appears to be a natural way to work to us.
Nobody Ever Gets Credit for Fixing Problems that Never Happened
This is the title of an article written in 2001 by Nelson P. Repenning and John D. Sterman (http://web.mit.edu/nelsonr/www/CMR_Getting_Quality_v1.0.html). In the article, the two researchers from MIT apply system dynamics to study why prevention and improvement are generally very difficult to achieve. The following figure illustrates this:
This figure visualizes how the the "Work Harder" loop competes with the "Work Smarter" loop. The decisive factor is the "Delay" link in the upper left of the figure. This is the hurdle that everyone has to take if they really want to achieve improvement. The following figure shows the corresponding response of the system to the various behavioral patterns and strategies:
What does this have to do with FMEA? On the one hand, the FMEA is affected directly since it hunts for failures before they actually occur. Anyone who uses FMEA must first withdraw resources from the Working Harder loop… and performance apparently decreases. It takes time for the fruits of improvement to mature, and short-term success is usually rare.
At the same time, it seems to me that the FMEA is trapped in the Working Harder loop. More of the same, and piling even more methods into the FMEA should produce better results. The fact that each discipline (not only the FMEA) believes it is the supreme discipline leads to isolation and reduces the capability of the overall system.
Working smarter
I have a dream. For the FMEA, I see in this dream that it is networked at different levels through the Intranet or Internet to the system modeling process, requirements analysis, functional safety, and verification, as well as to the manufacturing processes and feedback from the field. These are all web apps that are perfectly able to network and communicate in an orderly manner. Everything is fed into a shared, distributed knowledge store (semantic net) and can be used by everyone involved in the development process. The FMEA would finally have arrived in the 21st century. Before this is reality, though, it needs to leave its island and its comfort zone.