Ein Beitrag von Dr. Uwe-Klaus Jarosch, September 2025
Die Fehler-Möglichkeiten- und Einfluss-Analyse ist eine Analyse-Verfahren für technische Produkt und Abläufe (=Prozesse).
Ein zentrales Element dieser Methode ist das gemeinsame Verständnis von Aufgaben, Problemen und Lösungswegen im Team. Das kann über Illustrationen jeglicher Art unterstützt werden, aber im Kern geht es darum diese Aufgaben, Probleme und Lösungswege in Sprache auszudrücken.
Sprache ist ein ungemein starkes Werkzeug, mit dem wir Menschen gelernt haben, uns auszutauschen und unser Wissen and andere Menschen weiterzugeben. In Schriftform ist zudem der Faktor Zeit unwichtig geworden, da die Aufschreibung zu jedem beliebigen späteren Zeitpunkt erlaubt, die niedergeschriebenen Inhalte wieder zu lesen.
Voraussetzung: Das, was aufgeschrieben wurde, ist so verfasst, dass es verständlich und eindeutig ist.
Daher Tipp #1: Schreiben sie die Aussagen aus dem FMEA-Team auf und fragen sie konkret nach, ob die Formulierung für alle korrekt und eindeutig verständlich ist.
In der FMEA-Moderation wird eine Entwicklungsaufgabe zerlegt (Strukturanalyse). Für die Strukturelement werden Aufgaben beschrieben (Funktionen, Anforderungen, Mermale). Zu diese Aufgaben werden eine oder meist mehrere mögliche Fälle von Nichterfüllungen (Fehler) formuliert. Nach der Methode auf der untersten Ebene, der Ursachen-Ebene werden Maßnahmen für Vermeiden und Entdecken zusammengetragen.
Diese unterschiedlichen Bausteine der FMEA benötigen unterschiedliche sprachliche Formulierungen, Schemata.
Meine Behauptung: in einer gut geschriebenen FMEA kann man an der Formulierung der Beschreibung, eventuell durch Bemerkungen ergänzt, eindeutig erkennen, ob es sich um ein Systemelement, eine Funktion, einen Fehler oder einen der Maßnahmentypen handelt.
Gehen wir hier in Kürze die Knotenelemente der FMEA und ihre typischen Formulierungseigenheiten durch:
Titel der FMEA:
Hier sollte eindeutig erkennbar sein, um welchen Typ FMEA es sich handelt und was der Entwicklungsgegenstand ist. Unter Umständen ist es auch sinnvoll, den Entwicklungsstand zu erwähnen, wenn z.B. für Prototypenbau eine andere FMEA gemacht wird als für Vorserien- und Serienfertigung.
Systemelemente :
Systemelemente sind sprachlich unkritisch. Sie bezeichnen eindeutig das Teil der Produktentwicklung, das hier betrachtet werden soll oder den Schritt im Prozess.
Auf der Ursachen-Ebene sollten die Systemelemente eine Sortierhilfe sein. In der Design-FMEA, bei der bis zur Festlegung der Produktmerkmale auf der Zeichnung gearbeitet wird, wären für mich sinnvolle Kategorien auf Ursachen-Ebene einer mechanischen Komponente „Geometrie“, „Oberfläche“, „Material“, „Prozessanforderung aus dem Design“. In einem Fertigungsprozess sind die 4 Kategorien „Maschine/Anlage/Werkzeug“, „Mensch“, „Material“ und „Mitwelt/Umgebung“ entscheidend. Es gibt auch Kolleg:innen, die ein Systemelement auf unterster Ebene schlicht mit „Ursachen“ überschreiben und keine Aufteilung in Kategorien nutzen.
Aufgaben = Funktionen:
Der Begriff, der in der FMEA-Methodik für Aufgaben verwendet wird, ist die Funktion.
Ich tue mich etwas schwer mit dem Begriff der Funktion, speziell in der oftmals nicht-eindeutigen Form der Nutzung. Zur Beschreibung von Aufgaben gibt es sowohl unterschiedliche Herangehensweisen als auch in den Standards Unterschiede zwischen den FMEA-Typen.
Dies drückt sich natürlich auch in den Formulierungen aus, die für die Aufgabenbeschreibung genutzt wird.
Eine verbreitete Anleitung sagt: Die Funktion wird durch ein Nomen und ein Verb gebildet.
Das ist meist nicht falsch, aber aus meiner Sicht nicht hinreichend, um korrekt Aufgaben-Beschreibungen in die FMEA zu bringen.
Zunächst stellen sich 2 Fragen:
Zunächst zur ersten Frage.
Aus meiner Erfahrung macht es große Unterschiede, ob wir beschreiben, was ein Produkt oder ein Prozessschritt können soll (Funktion), ob wir eine ergänzende Anforderung beschreiben, die als Randbedingung bei der Entwicklung berücksichtigt werden muss oder ob wir über konkrete Merkmale sprechen.
Bei dem, was ein Produkt oder ein Prozess können soll, ist Frage 2 für die Formulierung zentral.
Wir können die Funktion als „Weg zum Ziel“ begreifen. Das entspricht dem mathematischen Funktionsbegriff. In der Mathematik ist die Funktion die Beschreibung, wie eine Eingangsgröße in eine Ausgangsgröße überführt wird.
Die Ausgangsgröße Y = Funktion von X und die Funktion wird z.B. formuliert als Y= 2,7 – 3X + 0,5 X2
Diesem Funktionsbegriff folgen Formulierungen, die vorrangig in der Design-FMEA genutzt werden, um physikalisch-technische Aufgaben im Produkt zu beschreiben:
Das Untersetzungsgetriebe wandelt eine hohe Drehzahl in eine niedrige Drehzahl und ein niedriges Drehmoment in ein hohes Drehmoment.
In diesem Satz übernimmt das orangene Wort die Bezeichnung des Systemelements, ist zum leichteren Verständnis der Funktion hilfreich, aufgrund der Zuordnung der Funktion zum Systemelement aber nicht zwingend erforderlich.
Die roten Wörter Drehzahl und Drehmoment sind die eigentlichen Objekte der Funktion. Und das Verb „wandeln“ erläutert den physikalischen Vorgang.
Dies beschreibt ohne Zweifel, wofür dieses Untersetzungsgetriebe gebraucht wird.
Diese Funktion beschreibt jedoch nicht, welcher Zustand den Kunden zufriedenstellen würde. Dazu sind zwei Wege möglich: Die erste Möglichkeit ordnet der Funktion ergänzende Informationen zu. Diese werden als „Anforderungen“, „Spezifikationen“ oder „Parameter“ bezeichnet und konkretisieren die Entwicklungsaufgabe. Dadurch werden auch zusätzliche Randbedingungen aufgerufen, die in der Entwicklung berücksichtigt werden müssen.
Das Untersetzungsgetriebe muss bei der Wandlung einen Wirkungsgrad >90% erreichen.
Die Auslegung muss für Maximal-Drehzahl am Eingang und Maxima-Drehmoment am Ausgang ausgelegt sein.
Der Betrieb des Untersetzungsgetriebes muss mit einmaliger Wartung pro Jahr über 20 Jahre ausgelegt sein.
Der Betrieb des Getriebes muss in einem Temperaturbereich von -40°C bis + 95°C unabhängig von der Luftfeuchtigkeit möglich sein.
Die Liste der Forderungen lässt sich noch erweitern.
Erst mit diesen Spezifikationen wird es möglich, den Unterschied zu schon bestehenden Geräten aufzuzeigen und die eigentliche Entwicklungsaufgabe zu klären.
Vielleicht soll das Getriebe genau das gleiche leisten, wie sein Vorgänger, lediglich mit 15% geringerem Gewicht – Challenge.
In den FMEA-Standards ist für Funktionen noch ein weiteres, wichtiges Kriterium benannt: Funktionen müssen bewertbar sein.
Der Grund ist einfach: Im nächsten Schritt der FMEA-Analyse sollen Fehler = Abweichungen von der geforderten Funktion beschrieben werden. Ein Fehler kann aber nur festgestellt werden, wenn eine bewertbare Eigenschaft nicht oder unzureichend erfüllt ist. Wie sollen wir Fehler ableiten, wenn wir nicht präzise ausdrücken, was das Ziel, was die Forderung ist?
Wenn wir uns die Funktion des Untersetzungsgetriebes oben anschauen, so ist es schwer bis unmöglich, aus dieser generischen Funktion eine Abweichung abzuleiten – abgesehen von einem „Kann nicht wandeln“. Aber diese grundsätzliche Negierung der Funktion bringt keinen Erkenntnisgewinn für die Risikoanalyse zu diesem Produkt.
Mit der Forderung der Bewertbarkeit komme ich zu dem Schluss, dass eine Funktion nicht den Weg zum Ziel, sondern den angestrebten Zustand beschreiben sollte.
Diesen Zustand kann ich dann bewerten und von diesem Zustand kann ich Fehler systematisch und folgerichtig ableiten.
Das Untersetzungsgetriebe wandelt Drehzahl und Drehmoment im Verhältnis 1: 3,5 bis zu einer Eingangsdrehzahl von 3000 U/min und bis zu einem Ausgangsdrehmoment von 200 Nm dauerhaft um.
Diese Funktionsbeschreibung ist dadurch konkreter und bewertbar, dass wesentliche (hier noch nicht alle) Spezifikationen mit in der Formulierung einbezogen wurden.
Es ist ein Stilfrage, kein inhaltlicher Unterschied, ob weitere Bedingungen als weitere Funktionen oder als ergänzende Parameter bzw. Spezifikationen erwähnt werden.
Das Untersetzungsgetriebe wandelt eine Drehzahl und Drehmoment mit einem Wirkungsgrad >90% um.
Wichtig ist nur, dass in dem Paket „Funktionen“ die Zielvorgaben der Entwicklung gegeben sind. Und diese Forderung gilt dann für die Funktionen auf allen Ebenen, von der übergeordneten Einbindung des Getriebes in eine größere Anlage bis zu den Details auf Merkmalsebene.
Zum Unterschied zwischen Funktion, Anforderung und Merkmal wird es zu einem späteren Zeitpunkt einen separaten Blog-Beitrag geben.
In der Formulierung der Ursachen- oder Merkmalsebene wird es einfacher: Ein Merkmal mit seinen Grenzbedingungen benötigt kein Verb. Was sich als wichtig für die Lesbarkeit der FMEA herausgestellt hat, ist das Mitführen von Aufgaben- oder Orts-Bezeichnungen.
Wenn es im Produkt oder Prozess 25 ähnliche, aber funktional unterschiedliche Verschraubungen gibt, dann sollten Gruppen gebildet und die Funktionstexte eindeutig nach ihrer Funktion unterschieden werden.
Daher mein Tipp #2: Formulieren sie die Funktion oder Anforderung als Zustand, der erreicht werden soll. Das sollte sich auch auf die verwendet Zeitform auswirken:
Die „Funktion ausführen“ beschreibt eine Tätigkeit. Die „Funktion ist ausgeführt“ beschreibt einen Zustand. Überlassen sie die Tätigkeiten den Maßnahmen und formulieren sie etwas Bewertbares.
Fehler
Nach der FMEA-Theorie sind die Fehler die Abweichungen, die für eine Funktion auftreten können. Sie müssen nicht auftreten, aber es ist weder unmöglich noch völlig unwahrscheinlich.
Der Text des Fehlers, egal auf welcher Ebene der FMEA, beschreibt daher eine Abweichung. Solche Abweichungen können sehr ähnlich sein. Daher ist es aus meiner Sicht zwingend, individuell für das Detail, das hier gerade betrachtet wird, eine eineindeutige Fehlerbeschreibung zu finden.
Es gibt Firmen und Moderatoren-Kollegen, die gerne auf Fehlerkataloge zurückgreifen.
Nach meiner Erfahrung ist das aber eine unzulässige Verallgemeinerung, ähnlich der Funktion, die nur generisch ohne Spezifikation eingetragen ist.
Liegt im Bestand ein zutreffender und passender Text vor, so spricht natürlich nichts dagegen, diesen auch zu verwenden. Aber wenn sie 5x den gleichen Fehler beobachten, dann ist es entweder wirklich der identische Fehler und braucht nicht 5x aufgeschrieben, sondern nur sinnvoll im Fehlernetz verknüpft werden, oder es sind 5 unterschiedliche Fehlerfälle, die dann auch unterscheidbar sein müssen. Andernfalls werden sie keine sinnvollen Unterscheidungen nach Folgen und Ursachen machen können, was auch wieder eine unzulässige Verallgemeinerung ist.
Wie sollte die Formulierung eines Fehlers lauten ?
Zunächst muss im Text des Fehlers ein eindeutiger Bezug auf die Funktion erkennbar sein.
Dann gibt es in der Design-FMEA unterschiedliche Fehlerfälle. Im AIAG-VDA-FMEA Handbuch werden 7 grundlegende Möglichkeiten von Design-Fehlern unterschieden. Es müssen nicht alle 7 relevant sein. Aber mehr als einer in aller Regel schon. So kann beispielsweise zwischen dem Totalausfall, der Nicht-Funktion oder der Funktionseinschränkung durch Funktionsminderung / Degradation bei mechanischen Systemen sinnvoll unterschieden werden.
Quelle: AIAG-VDA FMEA Handbuch (2019) Kap. 2.4.2
In den Formulierungen des Fehlers macht es auch einen wesentlichen Unterschied, ob es eine Design-FMEA (Konstruktions-, System-, MSR-, Maschinen-FMEA) oder eine Prozess-FMEA ist.
Tipp #3: Im Design ist die Aufgabe, etwas neu zu gestalten und festzulegen. Daher kann ein Fehler im Design nur bedeuten, dass etwas „nicht“, „unzureichend“, „nicht funktionsgerecht“, „nicht herstellbar“ festgelegt wurde.
Im Prozess ist die Aufgabe, eine Vorgabe in der Fertigung umzusetzen und innerhalb der Toleranz zu fertigen. Daher ist dort ein Ergebnis oder ein Prozessparameter „außer Toleranz“ eine sinnvolle Fehlerbeschreibung.
Maßnahmen
In unserer FMEA bleibt noch die sprachliche Gestaltung von Maßnahmen zu betrachten.
Dieses Thema ist aber einen eigenen Blog-Beitrag wert.
Fazits:
Bleiben Sie neugierig.
Uwe Jarosch