Cost of Poor Quality reduzieren: Mit der FMEA

Autorin: Ursula Meseberg

Disruptive Innovationen sind heute gefragter denn je. In immer mehr Bereichen des menschlichen Lebens wird auf Maschinen und Künstliche Intelligenz (KI) gesetzt. Hierbei stellt sich die Frage nach der Sicherheit: Seien es autonom fahrende Autos, Pflegeroboter oder andere technische Entwicklungen — schon kleinste Systemfehler oder Fehler im Produktionsprozess können ein Produkt gefährden und eine massive Gefahr für Anwenderinnen und Anwender bedeuten.

Hersteller von sicherheitskritischen Systemen müssen nicht nur sicherstellen, dass ihre Produkte funktionieren. Sondern auch, dass sie unter allen Umständen richtig funktionieren. Wenn Fehler oder mögliche Fehler identifiziert werden, muss deren Ursache gefunden werden: Das bedeutet, die Reise zurück zu den Anforderungen anzutreten. Deshalb ist die Requirements-Traceability, also die Erfassung von Anforderungen während des gesamten Lebenszyklus in der Produktentwicklung, ein wichtiger Baustein bei der Einhaltung sicherheitsbezogener Normen. Die Fehler-Möglichkeits- und -Einfluss-Analyse (kurz: FMEA) übernimmt dabei eine zentrale Rolle bei der Qualitätssicherung.

Was ist FMEA?

Die Fehler-Möglichkeits- und -Einfluss-Analyse (kurz: FMEA) eine wichtige Methode zur Qualitätssicherung, die insbesondere im Automobilsektor Anwendung findet – aber auch in weiteren Entwicklungszweigen wie in der Robotik, Medizintechnik oder in der Luft- und Raumfahrt. Kurz gesagt findet FMEA überall dort Anwendung, wo präventiv Risiken minimiert werden müssen, weil sie fatale Folgen haben könnten.

Laut der Definition des FMEA-Handbuches, das gemeinsam von der Automotive Industry Action Group (AIAG) und dem Verband der Automobilindustrie (VDA) herausgegeben wurde ist die FMEA eine “teamorientierte, systematische, qualitative Methode zur Identifizierung, Analyse und Abschwächung technischer Risiken im Zusammenhang mit der Entwicklung von Produkten und Herstellungsprozessen”. Normen wie die ISO 26162 (Funktionale Sicherheit) oder APQP (Advanced Product Quality Planning) in der IATF 16949 können mithilfe der FMEA sehr gut unterstützt werden.

Use Cases für eine FMEA

Zweck der FMEA ist es, innerhalb der Produktentwicklung Fehler bei Produktfunktionen und Prozessschritten zu vermeiden – oder diese Fehler frühzeitig genug aufzudecken, sodass ihre Auswirkungen gering bleiben. Neben der Neuentwicklung eines Produkts und dem Einsatz neuer Fertigungsprozesse gibt es weitere typische Trigger für eine FMEA, zu denen folgende gehören:

• Systemänderungen
• Produktänderungen
• Geänderte Einsatzbedingungen für vorhandene Prozesse
• Neuentwicklung eines Systems

Abb. 1: Typische Trigger für eine FMEA, Quelle: microtool

Die FMEA leistet einen wichtigen Beitrag zur Erreichung der übergeordneten Ziele einer Entwicklungsorganisation. Zu diesen gehören:

• die Verbesserung der Qualität, Zuverlässigkeit, Herstellbarkeit, Funktionstüchtigkeit und Sicherheit von Produkten
• und natürlich auch die Steigerung der Kundenzufriedenheit.

Obwohl die FMEA zunächst Kosten verursacht, senkt sie im Idealfall weitere Kosten, denn sie hilft bei der Vermeidung von:

• Garantie- und Kulanzfällen wie Rückrufen etc.
• späteren Änderungen
• nachträglichen Realisierungen von nicht erfüllten Kundenanforderungen
• Imageverlust auf umkämpften Märkten

Außerdem dient eine durchgeführte FMEA im Produkthaftungsfall dem Nachweis, dass eine Produkt- und Prozess-Risikobewertung stattgefunden hat.

Wie funktioniert die FMEA?

Eine FMEA läuft in sieben Schritten ab. Zuerst wird ein interdisziplinäres Kernteam für die FMEA gebildet und der Umfang der Analyse festgelegt.

Die Beantwortung der 5-Z’s hilft dabei:

1. Zweck: Warum wird die FMEA durchgeführt?
2. Zeitrahmen: Bis wann muss die FMEA vorliegen?
3. TeamZuordnung: Welche Teammitglieder sind zuständig?.
4. AufgabenZuweisung: Welche Aufgaben sind durchzuführen?
5. WerkZeug: Womit wird die FMEA durchgeführt?

Dann werden Strukturen, Funktionen, Fehler und Risiken analysiert, anschließend wird die Optimierung geplant und zuletzt werden Ergebnisse dokumentiert.

Abb. 2: Die 7 Schritte der FMEA, Quelle: microtool

Grundsätzlich gibt es zwei Arten der Fehler-Möglichkeits- und -Einfluss-Analyse (FMEA): Die Design-FMEA (DFMEA) untersucht die funktionalen Zusammenhänge des betrachteten Systems bis in die Merkmale der Komponenten. Die Prozess-FMEA (PFMEA) analysiert die Abläufe zur Herstellung des betrachteten Systems.

Wird ein Produkt gänzlich neu entwickelt, ist der Fokus zunächst auf der DFMEA. Wenn die Fehler des Produktes ausgelotet sind, kümmert man sich um den Herstellungsprozess mit der PFMEA.

Visualisierung hilft bei der Analyse

Bei der Analyse von Struktur und Funktion helfen Diagramme, die Zusammenhänge, Abhängigkeiten und Verfeinerungen sichtbar machen. Führt man z. B. eine DFMEA für eine neue Scooter-Lampe durch, kann man mit einem Boundary-Diagramm den Systemkontext sehr gut abgrenzen:

Abb. 3: Das Systemkontextdiagramm zeigt das System, Kontextelemente, interagierende Akteure und einzuhaltende Regeln, Quelle: microtool

Ein Systems Modeling Language (SysML) Blockdiagramm hilft bei der Veranschaulichung der Zusammenhänge zwischen den Systemelementen, indem es physische und logische Beziehungen zwischen dem System, Baugruppen und Komponenten zeigt.

Abb. 4: Das Blockdiagramm zeigt den Strukturbaum des Designs, Quelle: microtool

Das Parameterdiagramm stellt wiederum grafisch die Umgebung eines Produkts dar und weist auf die Faktoren hin, welche die Umwandlung von Eingabe in Ergebnis beeinflussen. Es zeigt Funktionen, Störgrößen sowie die Anforderungen an das System, die durch die Funktion erfüllt werden. Auch das lässt sich mit einem SysML Blockdiagramm sehr gut umsetzen:

Abb. 5: Ein Parameterdiagramm zeigt Eingänge und Ausgänge vom System, Anforderungen, die es erfüllt und Störgrößen, Quelle: microtool

Im Idealfall ist die Struktur- und Funktionsanalyse für eine FMEA eng verzahnt mit dem Requirements Engineering. Je früher mögliche Fehler berücksichtigt werden, desto früher können auch Anforderungen entsprechend modifiziert werden.

Zur Wurzel des Fehlers

Sind Fehler erst einmal identifiziert, können sie weiter analysiert werden: Zunächst ordnet man sie einer Fehlerart (FA) zu und ermittelt anschließend die Fehlerfolgen (FF) und Fehlerursachen (FU).

Bei der Fehleridentifikation können gezielte Fragetechniken helfen. Eine Möglichkeit ist die „5-Why-Methode“. Indem man 5 Mal „Warum?“ fragt, gelangt man immer näher zur Fehlerursache.

Hier ein Beispiel:

1. Warum leuchtet die Scooter-Lampe nicht? Weil die LED kaputt ist.
2. Warum ist die LED kaputt? Weil sie falsch gelagert wurde.
3. Warum wurde sie falsch gelagert? Weil der Lagerraum keine Kühlung hatte.
4. Warum hatte der Lagerraum keine Kühlung? Weil nicht klar war, dass LEDs kühl lagern müssen.
5. Warum war das nicht klar? Weil sich keiner mit der richtigen Lagerung befasst hat.

Eine weitere Möglichkeit der Darstellung von Ursache und Wirkung ist das Ishikawa-Diagramm, das an eine Fischgräte erinnert.

Abb. 6: Darstellung eines Ishikawa-Diagramms, Quelle: microtool

Worst Case Szenarios vermeiden

Welche Risiken bringen nun die identifizierten Fehler mit sich? Um diese Frage zu beantworten, gibt es Bewertungszahlen — sowohl für den Ist-Zustand als auch für den Soll-Zustand. Aus der Bewertung ergibt sich dann eine Aufgabenpriorität (engl. Action Priority, kurz: AP). Die Bewertung wird per Multiplikation folgender Werte vorgenommen:

• B Bedeutung der Fehlerfolge (Wert 1 bis 10)
• A Auftreten der Fehlerursache (Wert 1 bis 10)
• E Entdeckung der aufgetretenen Fehlerursache (Wert 1 bis 10)

Die Aufgabenpriorität ergibt sich aus: B x A x E und kann folglich einen Wert von 1 bis 1.000 annehmen.

Je höher der Wert, desto größer ist der Optimierungsbedarf. Hohe Risiken werden mit Maßnahmen belegt, für die jeweils eine Abschätzung über deren Wirksamkeit erfolgt. Sollten sich Konzeptänderungen nach einer erfolgten Optimierung ergeben, werden alle sieben Schritte der FMEA neu durchlaufen. Als letzter Schritt werden Ergebnisse, Maßnahmen und Schlussfolgerungen dokumentiert und somit eine Wissensdatenbank der Fehler und Risiken erschaffen. Sie bildet die Grundlage für weitere FMEAs und dient generell der Kommunikation von Risiken.

Integration sorgt für Agilität

Aber wie passt eine lineare FMEA zu agilem Anforderungs- und Projektmanagement? Wie schnell hinken die sieben Schritte hinter Änderungen des Designs oder veränderten Abläufen hinterher?

Für die Frage gibt es eine einzige Lösung, um Schritt zu halten: Die Integration der FMEA in das Requirements Engineering und Projektmanagement.

Schon bei der Anforderungserhebung sollten Fehlermöglichkeiten in Betracht gezogen und erfasst werden. Ändert sich eine Anforderung, muss auch eine Neubewertung des Fehlerrisikos erfolgen. Erscheinen Fehler im Produktionsprozess, sollten sie mit einer End-to-End Traceability verfolgt werden. Wenn Maßnahmen zur Fehlervermeidung definiert werden, sollten sie am besten auch gleich eingeplant werden. Deshalb ist es wichtig, dass die Fehler-Möglichkeits- und -Einfluss-Analyse (FMEA) nicht losgelöst im eigenen Silo, sondern im regelmäßigen Austausch mit den Entwicklungsteams durchgeführt wird und die Ergebnisse für alle Beteiligten im Design- oder Herstellungsprozess transparent sind. Erst recht, wenn innovative Produkte mit hohen Sicherheitsauflagen entworfen werden.

Favorite