Es ist früh am Morgen, Sie sind gerade erst aufgewacht und bereiten Ihren Kaffee vor. Nebenbei schalten Sie das Radio an und hören, dass der Münchner Autobauer (BMW) weltweit 61.000 Autos in die Werkstätten zurückruft.
Der Grund für den Rückruf ist ein Softwarefehler, welcher zum Motorausfall und Drehmomentverlusten führen kann.
Ein Albtraum sowohl für die Betroffenen als auch für den OEM selbst. Doch wie kann man so einen Fehler verhindern? Eine gute Methode in diesem Fall ist sicherlich die Software FMEA.
Doch was bedeutet FMEA?
Die Abkürzung steht für „Failure Mode and Effects Analysis“ oder auf Deutsch: „Fehlermöglichkeits- und Einflussanalyse". Die zugrunde liegende Idee: Wir überlegen uns folgende Punkte, bevor wir handeln:- Welche möglichen Fehler könnten auftreten?
- Welche Ursachen könnten dazu führen?
- Welche Auswirkungen wird dieser Fehler haben?
Die größte Herausforderung einer Risikoanalyse liegt in der Wahl der richten Betrachtungsebene sowie der klaren Abgrenzung zwischen Ursache - Fehler - (Aus-)Wirkung.
Um das Ganze etwas zu verdeutlichen, stellen Sie sich einfach mal Folgendes vor. Sie sind Entwicklungsleiter eines Medizinprodukteherstellers. Sie sind damit beauftragt, eine neue Generation eines Herzschrittmachers zu entwickeln. Welche Risiken bestehen?
Wie werden die Risiken bewertet? Was ist zu tun? Knobeln Sie ruhig ein wenig über die Aufgabe. Es stehen immerhin Menschenleben auf dem Spiel. Wir gehen aber auch weiter unten noch mal darauf ein.
Wie geht man eigentlich bei der FMEA Methode vor?
Um ein FMEA Projekt vollständig abzuarbeiten, müssen 7 Schritte durchlaufen werden.
Dabei wird nicht zwischen P-FMEA (Prozess-FMEA) und D-FMEA (Design-FMEA) unterschieden.
Die Schritte sind dieselben. ➔ Der Fokus liegt in beiden Fällen auf den Funktionen. Bei der D-FMEA die Produktfunktionen und bei der P-FMEA die Prozessfunktionen - also die herzustellenden Spezifikationen abgeleitet aus der D-FMEA.
01. Planung und Vorbereitung:
Die fünf Z sind die Themenbereiche, die zu Beginn einer FMEA diskutiert werden sollten:- FMEA-Zweck
- FMEA-Zeitplanung
- FMEA-Teamzusammenstellung
- FMEA-Aufgabenzuweisung
- FMEA-Werkzeuge
02. Strukturanalyse
Der Zweck der Strukturanalyse ist die Identifizierung und Aufgliederung des Designs in System, Subsystem, Komponente und Bauteile für die technische Risikoanalyse.
03. Funktionsanalyse
Der Zweck der Funktionsanalyse ist es sicherzustellen, dass die in den Anforderungen festgelegten Funktionen den Systemelementen zugeordnet und betrachtet werden.
Die Ergebnisse der D-FMEA sind die ermittelten sogenannten "Besonderen (Zeichnungs-) Merkmale (Sicherheit, Zulassung und Funktion)" erfasst im DVP (Design Verifikation Plan).
Die P-FMEA dagegen ermittelt für die definierten besonderen Merkmale das Risikoniveau im Prozess und definiert Maßnahmen.
Diese werden im PLP (Produktionslenkungsplan) oder auch Control Plan festgehalten.
04. Fehleranalyse
Der Zweck der Fehleranalyse ist es, Fehlerfolgen, Fehlerarten und Fehlerursachen zu identifizieren. ➔ Ein Fehler ist immer die Nichterfüllung einer Funktion / Merkmals!- Funktionsverlust
- Eingeschränkte oder eine Verschlechterung der Funktion
- Überfunktion / Übererfüllung
- Schwankende Funktion
- Unbeabsichtigte Funktion
- Verzögerte Funktion
05. Risikoanalyse
Sobald die Fehler (nicht Funktion) definiert sind, werden in kleinen interdisziplinären Workshops alle möglichen Ursachen ermittelt und bestehende Maßnahmen zur Fehlerverhinderung aufgenommen.
Nachdem alle für die Risikobewertung nötigen Informationen bereitstehen, wird gemeinsam im Team die Risikobewertung durchgeführt.
Dabei wird der Reihe nach die Bedeutung, die Auftretenswahrscheinlichkeit sowie die Entdeckungswahrscheinlichkeit auf deiner Skala von 1 gering bis 10 hoch bewertet.
Aus unterschiedlichen Kombinationen dieser Bewertung ergeben sich sogenannten Aufgabenprioritäten. Priorität niedrig (grün) akzeptables Risiko. Aufgabenpriorität mittel (gelb) und hoch (rot) Risiko nicht akzeptabel.
Ein kleiner Ausschnitt aus unserem FMEA-Arbeitsblatt:
Interessiert? Noch mehr Vorlagen unserer FMEA-Quality App für Excel für Ihr Vorhaben finden Sie in unserem Shop.
06. Risiko-Optimierung
Auf Basis der Risikobewertung werden Maßnahmen ermittelt. Zur Reduzierung der Auftretenswahrscheinlichkeit müssen Abstellmaßnahmen erarbeitet werden (Poka Yoke Lösung).
Zur Verbesserung der Entdeckungswahrscheinlichkeit müssen automatisierte und hoch fähige Prüfungen eingeführt werden.
Nach vollständiger Umsetzung der definierten Maßnahmen sowie nachgewiesener Wirksamkeit werden die Risiken neu bewertet.
07. Dokumentation der FMEA-Ergebnisse
Zusammenfassung der wichtigsten Ergebnisse aus der FMEA. Alle Risiken mit hoher Aufgabenpriorität sowie definierte Maßnahmen an einen festgelegten Verteiler in der Organisation.
Prävention vor Reaktion mit der FMEA-Methodik - in der Software-Entwicklung
Bei Recherchen im Internet zum Thema Methoden zur "Risikoanalyse" in der Softwareentwicklung sind wir vom TQU auf sehr unterschiedliche Aussagen gestoßen.Von "FMEA ist die richtige Methode" bis "die FMEA macht in der Entwicklung von Software keinen Sinn".
Das hat uns im TQU neugierig gemacht und wir haben uns unser eigenes Bild gemacht.
Um auf das Problem im eingangs genannten Beispiel einzugehen. Der Münchner Autobauer, welcher seine Fahrzeuge in die Werkstätten rufen muss.
In genau so einem Fall wäre aus unserer Sicht eine Software-FMEA angebracht gewesen.
Doch was ist eine Software FMEA? Und womit unterscheidet Sie sich von den anderen?
Die Software FMEA ist eine Design-FMEA. Die D-FMEA dient der Entwicklung und Konstruktion dazu, die Funktionssicherheit eines Produkts über den gesamten Entwicklungsprozess begleitend zu bewerten und abzusichern.
Der Betrachtungsumfang beinhaltet alle möglichen Ursachen (Mensch, Maschine, Material, Methode), die im Feld zu Funktionsbeeinträchtigung oder gar zum Verlust dieser führen können.
Die Software ist zunehmend Teil eines Produktes. Sie hat definierte Funktionen und somit auch mögliche Fehler.
Die Ursachen für eine Fehlfunktion der Software liegen in den Programmcodes aber auch in möglichen Schnittstellen zur Hardware oder Sensorik.
Das Problem genauer betrachtet
Die Hauptfunktion einer Software besteht in der Erfassung und Verarbeitung von z. B. Eingabeinformationen oder Sensordaten sowie der Steuerung von Hardware.
Die Komponenten einer Software wiederum sind Code-Zeilen bzw. binär betrachtet Einsen und Nullen.
Diese schreibt doch der Software Entwickler oder? Somit liegen die Ursachen für Fehler im Programm immer beim Menschen.
Okay, Fall gelöst. Damit ist natürlich ganz klar - für die Fehlerursachen in der Software ist immer der Mensch verantwortlich.
Hieraus schlussfolgert man dann ganz plump, dass eine Software FMEA nicht zielführend ist. Doch schon dieser Teil ist irreführend.
Denn Software wird korrekterweise heutzutage teilweise von Menschen geschrieben, doch ebenfalls teilweise automatisiert generiert durch weitere Software oder KI.
Gerne wird Software modular verstanden und Bausteine werden wiederverwendet oder getauscht. Bereits hier lässt sich also ein fundamentaler Denkfehler erkennen.
Wir verstehen die Software FMEA anders
Die Software ist wie vielen bekannt häufig ein essenzieller Teil eines Produktes und in der Regel mindestens funktionsrelevant. Hier ändert sich die Betrachtungsweise bereits grundlegend.
Denn Software Entwicklung ist nicht leicht, umso wichtiger erscheint es, Sie als Teil eines Produktes zu begreifen. Auf einmal haben dann Fehlfunktionen klar erkennbare Auswirkungen.
Kommen wir noch einmal wie versprochen auf den Herzschrittmacher zurück.
Wenn zum Beispiel die Software des Herzschrittmachers ausfällt oder die Impulse zur falschen Zeit aussendet, passiert im besten Fall nichts - im schlechtesten Fall besteht Gefahr für Leib und Leben.
Hersteller von Medizinprodukten können hier ergänzend zu den bekannten Methoden ihr Risikomanagement mit einer Software FMEA komplementieren. Denn die Ursache für den fehlerhaften Impuls könnte in der Hardware an Faktoren der Umwelt, aber eben auch an Programmierfehlern liegen.
Bei Gefahr für Leib und Leben und einem Programm-Code, der neu geschrieben werden muss, ist das Risiko sehr hoch.
Abstellmaßnahmen wie validierte Code-Bausteine oder Prüfmaßnahmen wie Validierungsintervalle oder redundante Code-Bausteine können das Risiko deutlich reduzieren.
Die FMEA Methode unterstützt dabei, sich auf die wirklich kritischen Funktionen der Software und deren Auswirkungen zu fokussieren. Hierbei besonders wichtig erscheint die Betrachtungsebene für die Fehlerursachen.
Diese sollte von einem Hersteller so gewählt werden, dass diese nicht zu granular wird. Ein wahrer Spagat, der hier abverlangt wird. Denn zu gern tauchen Software-Entwickler ab in die tiefen der Programmcodes.
Sie verlieren den Fokus auf die Funktionen und das nicht Erfüllen eben dieser. Dennoch ist davon abzuraten, die Software-Entwickler nicht mit ins Boot zu holen.
Sie kennen die Software am besten, haben jedoch nicht die Expertise in der Risikobewertung. Deshalb sollte das Team mit bedacht zusammengestellt werden.
Wer ist davon alles betroffen?
Um es kurz zu machen, die meisten Branchen und Hersteller dürften in Zukunft sich mit diesen Fragen beschäftigen müssen. Denn natürlich sind hiervon nicht nur Medizinproduktehersteller betroffen.
Wie im Beispiel der Einleitung erkennbar ist auch die Automotive Industrie betroffen. Hier sehen wir immer stärker den Einzug von Unterhaltungsmedien, schönen touch Interfaces und Systemen zum autonomen Fahren.
Doch sind wir mal ehrlich. Selbst unser Toaster ist inzwischen mit Software ausgestattet, um unseren Toast noch knuspriger zu machen.
Das weist für uns ganz klar die Zukunft in eine Welt, in welcher sich auf Konsumgüterhersteller, Lebensmittel und alle weiteren Branchen mit dem Thema intensiv auseinandersetzen sollten.
Deshalb sollte besonders die Software FMEA in den Unternehmen diskutiert werden, statt abgehandelt zu werden und in einer Schublade zu vergammeln.
Fazit
Die FMEA ist einer sehr gute und mit einer hohen Erfolgsquote geführte Methode zur Minderung von Risiken.
Obwohl diese Methode sehr weit verbreitet ist, wird sie in den meisten Fällen doch sehr rudimentär umgesetzt.
Dies mag am hohen formalen Aufwand bei der Durchführung der FMEA liegen, aber unserer Meinung nach eher am nicht nachweisbaren Nutzen. Es ist nicht cool, vorsichtig zu agieren.
Cool ist es, den Karren aus dem Dreck zu ziehen und Qualitätskosten zu reduzieren. ABER wie die Zehnerregel schon sagt. Die Kosten für Nicht-Qualität steigen je Reifegrad der Entwicklung um den Faktor 10.
Kostet die Behebung eines Fehlers in der Planungsphase 10 Euro, wird der gleiche Fehler entdeckt im Feld 1000 Euro kosten.
Passend zu einem Problem gibt es immer einen geeignet Lösungsansatz, die bezahlbar ist. Mithilfe einer kostenlosen Kurzberatung finden wir das, was Sie in Ihrer Situation benötigen.
Hinterlassen Sie einen Kommentar