KI-Einsatz bei Erstellung von FMEAs - Teil 2
Ein Beitrag von Dr. Uwe-Klaus Jarosch, Juli 2026
Dies ist die Fortsetzung des Blog-Beitrags zu „Aufgaben und Eigenschaften der verglichenen KI-Tools“.
Im ersten Teil habe ich die Aufgaben gesammelt, die Moderator:in und Teammitglieder bei der Erstellung und Pflege einer FMEA bearbeiten müssen, um eine Entwicklung, egal ob Produkt- oder Prozess-Entwicklung, wirkungsvoll zu unterstützen.
Bei diesen Aufgaben sollen KI-Tools mitwirken, Zeit sparen und die Qualität der Ergebnisse verbessern.
Außerdem habe ich in Teil 1 drei KI-unterstützte FMEA-Tools in ihren Eigenschaften verglichen.
In Teil 2 der Blog-Reihe sind die 7 Schritte nach AIAG-VDA dran.
Jeder der Schritte ist notwendig, um von einer Beauftragung zu einem – zumindest vorläufigen – Abschluss der FMEA zu gelangen.
Und ergänzend betrachte ich die Pflege der FMEA, die Aktualisierungen aus unterschiedlichen Gründen bedeutet.
Nicht näher betrachtet wird die Bewertung von FMEAs.
Anzumerken ist auch, dass das behandelte Beispiel ein Produkt betraf, das es in vielfältiger Ausführung seit vielen Jahren im Markt gibt. Daher kann das Beispiel nicht repräsentativ für die Entwicklung von etwas Neuem betrachtet werden.
In Teil 3 möchte ich einen persönlichen Ausblick auf die nächsten Jahre wagen, in dem es nicht nur um heutige Methode und neue Tools geht, sondern um Wenn-Dann-Bedingungen für erfolgreiche Nutzung KI-unterstützter Systeme im Vergleich zu den konventionellen Tools.
Dazu möchte ich einige „Herausforderungen“ benennen, die ich dabei sehe.
Teil 2: Erledigung der Aufgaben in 7 Schritten
Schritt 1 behandelt die Vorbereitung der FMEA.
Im Expertenkreis herrschte Einigkeit, dass in der Vorbereitungsarbeit ein wesentlicher Schlüssel zum Erfolg der gesamten FMEA-Arbeit liegt.
Dies betrifft unabhängig vom Tool die Sammlung aller verfügbaren Vorinformationen.
Die ersten beiden vorgestellten Tools verwenden das Weltwissen von Large Language Modellen, um daraus Vorschläge abzuleiten. Das dritte Tool verfügt über eine Art RAG[1]. Die Projektdaten werden vorab eingespeist und bearbeitet. Dieser Vorgang stellt zunächst die Basis zum Beginn der Arbeiten zur Verfügung und kann im Laufe des Projekts aktualisiert werden.
[1] RAG = Retrieval Augmented Generation : Large Language Modelle erhalten vorgegebene Daten, die sie so aufbereiten, dass ein gezielter Zugriff und eine Verwendung dieser Daten möglich wird. Die Daten werden in Semente zerlegt, indiziert und damit für einen gezielten Zugriff vorbereitet. Neben dem Weltwissen der LLMs können damit spezifische Daten oder Sachinformationen aus verlässlichen Quellen genutzt werden.
Unabhängig vom FMEA-Tool ist es nötig, eine Startabstimmung mit dem Team durchzuführen.
Empfohlen wird, dies anhand einer eindeutigen Kickoff-Checkliste durchzuführen.
Ein solches Teamevent muss nicht langwierig sein. Vorab zum Teamevent lassen sich eine Reihe von Checklistenfragen beantworten. Diese Infos sollten im Teamevent allen Teammitgliedern mitgeteilt werden.
Die restlichen Punkte der Checkliste sollten möglichst zügig im Team beantwortet werden.
Für die Protokollierung gibt es KI-Unterstützungen zum einen, um den Teamevent aufzuzeichnen und automatisch zu verschriftlichen, zum anderen, um aus der Mitschrift der gesprochenen Worte ein befülltes Protokoll zu erzeugen, das alle Inhalte wiedergibt und auch die Lücken ausweist, die im Nachgang zu klären sind.
Mit entsprechender Vorauswahl von KI-Tools aus einem recht vielfältigen Angebot UND geeigneter Prompts lassen sich eine wörtliche Mitschrift und eine bewertete Zusammenfassung in wenigen Minuten erstellen.
Beides ist wichtig, um die KI-generierte Zusammenfassung nochmals gegen die gesprochenen Worte abzugleichen und qualifiziert freizugeben.
Das Dokument FMEA im Tool besitzt üblicherweise Kopfdatenfelder. Zumindest Teile der Checklisteneinträge werden in Felder der FMEA-Kopfdaten übertragen. Auch das ist mit Anlage der FMEA über einen vorbereiteten Prompt gut vorstellbar, aber heute nicht gezeigt.
Ein wichtiger Punkt ist dabei der Betrachtungsumfang. Da dies eine Entscheidung des Auftraggebers zusammen mit den beteiligten Personen ist, liegt es nahe, den Betrachtungsumfang im Kickoff zu beraten, zu beschließen und aus der verschriftlichten Zusammenfassung in die FMEA zu übernehmen. Dabei ist die allgemeine Empfehlung, eine Ist-IstNicht-Beschreibung zu nutzen. Durch grafische Darstellungen wie eine Block-Boundary-Diagramm oder die Darstellung der Prozessschritte in einem Prozess-Ablauf-Diagramm kann die Ist-IstNicht-Beschreibung widerspruchsfrei ergänzt werden.
Schritt 2 Strukturanalyse
Die saubere Abgrenzung in Schritt 1, was betrachtet, was nicht betrachtet werden soll, welche externen und internen Schnittstellen zu berücksichtigen sind und bis zu welcher Tiefe in den Details der Systemstruktur die Betrachtung erfolgen soll, stellt zugleich die Vorarbeit für Schritt 2 – Strukturanalyse dar.
Im Design wird empfohlen, hierzu ein Block-Boundary-Diagramm zu verwenden, in dem das Wurzelelement, dessen Unterelemente, die Schnittstellen nach außen und die internen Schnittstellen zwischen den Unterelementen ersichtlich sind.
Sowohl aus verfügbaren Bildern des Entwicklungsgegenstands als auch aus vorliegenden Boundary-Diagrammen kann mit KI-Tools ein Code erzeugt werden, der einerseits Elemente und Bezeichnungen des Betrachtungsumfangs, andererseits deren Verbindungen ausweisen, zur automatischen Umwandlung in Diagramme und als codierte Information für die Struktur der FMEA genutzt werden können.
In allen 3 Tools lässt sich diese externe Vorarbeit zum Import nutzen, sodass der Strukturbaum im ersten Entwurf fertig ist.
In der Prozess-FMEA ist das vergleichbare Vorgabe-Dokument ein Prozessablaufplan.
Darin sind die zu betrachtenden Prozessschritte in ihrer Reihenfolge, ggf. mit Unter-Arbeitsschritten aufgeführt.
Je nach Vorgabe sind Schritte wie der Wareneingang, logistische Transfers oder Prüfschritte enthalten oder aus der Betrachtung ausgespart.
Analog zum Design erlauben spezialisierte KI-Applikationen die Übersetzung von Grafik in einen Code, der dann zum Aufbau der FMEA-Struktur verwendet werden kann.
In allen Tools ist der manuelle Eingriff möglich.
Schritt 3 : Funktionsanalyse
Die Funktionsanalyse ist der anspruchsvollste Schritt bei der FMEA-Erstellung.
Jedes Element der Struktur muss mindestens 1 Funktion enthalten, ansonsten wird dieses SE nicht benötigt.
Ausnahme 1: Das Systemelement ist zwar benannt, soll aber nach Entscheid im Betrachtungsumfang nicht analysiert werden.
Ausnahme 2: Das Systemelement ist benannt, stellt aber eher eine Gliederungshilfe dar. In Prozess-FMEAs habe ich das vielfach genutzt, um zwischen Anlagen und den integrierten Teilschritten unterscheiden zu können, ohne die Nomenklatur der Anlagenentwicklung verlassen zu müssen.
Alle 3 Tools bieten die Möglichkeit, zu einem gewählten Systemelement Vorschläge für Funktionen zu generieren und diese wahlweise zu übernehmen.
Wie in Teil 1 für die 3 Alternativen ausgeführt, ist die nahtlose Einbindung der KI in das Tool unterschiedlich ausgeprägt.
Im ersten Beispiel wird Weltwissen aus einem LLM genutzt. Als Hilfestellung für die KI wird ein kleiner Auszug aus dem Strukturbaum geliefert und das Element gekennzeichnet, für das Vorschläge gesucht werden. In einem Prompt wird die Aufgabe formuliert, für die die KI eine Antwort finden soll. Im einfachsten Fall bestand die Verbindung zwischen FMEA-Tool und KI-Tool nur aus dem genannten Auszug.
Das Ergebnis ist dann auch eher eine plakative Liste von Stichworten. Aus dieser Stichwortliste kann mit dem Team eine Auswahl getroffen und diese in das Tool übernommen werden. Im Beispiel wurden unter dem Systemelement entsprechend der Auswahl Knotenelemente vom Typ Funktion angelegt und mit den Texten der KI befüllt.
Im zweiten Beispiel-Tool wird ebenfalls das nähere Umfeld der Struktur mit an die KI übermittelt. Zusätzlich ist aber ein Prompt für die Abfrage von Funktionen hinterlegt, der nicht händisch ergänzt werden muss, sondern im Tool spezifisch hinterlegt ist.
Auch hier liefert die Abfrage eine Liste von Vorschlägen, die im gewählten Beispiel als sinnvolle Liste erschien, wofür dieses Subsystem oder Bauteil benötigt wird. Die Auswahl-Funktion ist im Tool integriert und nach Bestätigung wird die Auswahl ohne Copy-Paste an der richtigen Stelle in die Struktur ergänzt.
Im dritten Beispiel-Tool wird in der tabellarischen Übersicht der verfügbaren Inhalte – hier im vorliegenden Strukturbaum – das Element oder die Ebene ausgewählt, für die Funktionsvorschläge erarbeitet werden müssen.
Der Auftrag an die KI wird ausgelöst und im Hintergrund abgearbeitet. Im Prinzip ist das Prozedere identisch mit dem 2. Beispiel-Tool. Die wesentlichen Unterschiede sind jedoch, dass hier nur ausnahmsweise Weltwissen aus dem LLM verwendet wird, sondern vorrangig wird auf die Wissensbasis zurückgegriffen, die zuvor als gesichert ok aus dem Wissensfundus des Unternehmens als projektrelevant eingespeist wurde.
Die Ergebnisse der KI bestehen jetzt aus drei Teilen:
- einem Kurztext, in dem Funktionen semantisch korrekt und auf die Physik, Chemie, Logik bezogen beschrieben sind,
- einen Bemerkungs-, Ergänzungs- oder Notiz-Text von ca. 100 Worten, in dem die vorgeschlagene Funktion in ihrem Projektkontext beschrieben wird. Dies soll ein späteres Verständnis der Einträge (2-3-4-Regel[2]) unterstützen.
- Über einen Zusatzbutton werden Ergebnisse im Titel und Bemerkung in Teilinformationen zerlegt und deren Referenzen werden zitiert. Falls aus den Referenzdaten keine Antwort abgeleitet werden konnte, so wird das Ergebnis als KI-generiert ausgewiesen.
[2] 2-3-4-Regel: Schreibe es so auf, dass ein Zweiter es einem Dritten in vier Jahren erklären kann.
Diesem Ergebnis liegt zum einen das oben erwähnte RAG und zum anderen ein ausgefeiltes Prompting zugrunde.
Die Ergebnisse müssen – wie bei den beiden anderen Integrations-Lösungen – gelesen, bewertet und gewählt werden. Das kann u.U. allein schon wegen der umfangreichen Ergebnistexte anstrengend sein. Aber die Qualität der Ergebnisse ist in den gezeigten Beispielen sowohl aus Methoden- als auch aus Ingenieurs-Sicht beachtlich gut.
Auch hier werden bestätigte Vorschläge direkt in der Struktur korrekt eingebunden und es werden Verbindungen im Funktionsnetz erzeugt.
Schritt 4: Fehleranalyse
Zur Fehleranalyse ist aus meiner Sicht anzumerken, dass sinnvolle Einträge überwiegend nicht darin bestehen, das funktionale Ergebnis zu negieren. Sinnvoller und der Realität der Produkt- und Prozessentwicklung angemessen sind Fehlerbilder, die sich deutlich danach unterscheiden,
- ob System-, Design- oder Prozess analysiert wird,
- ob es um das Design von Mechanik, Mechatronik oder von Software geht,
- ob wir Fehler bei Folgen, auf der Fokus-Ebene oder bei Ursachen betrachten,
- ob mitgeltende Randbedingungen oder Spezifikationen zu konkreten Fehlerfällen führen und in die FMEA einfließen sollen.
Entsprechend muss einer KI darüber Information mitgegeben werden, um verwendbare Fehlerbeschreibungen als Vorschlag zurückzuerhalten.
Die Fehlerbilder führen zudem zu möglicherweise mehrdeutigen Verknüpfungen zwischen Fehlern auf Ursachenebene, Fokus-Fehlern und Folgen.
Wir müssen der Tatsache Rechnung tragen, dass KI nicht über Verständnis verfügt, wie wir es als Entwickler über Jahre erworben haben. Die Vorschläge sind daher entweder Übernahmen aus zuvor strukturiert aufbereiteten Beziehungen (siehe RAG und Wissensgraphen[3]) oder Vorschläge aufgrund von Statistik.
[3] Wissensgraphen zeigen Beziehungen zwischen Elementen auf, z.B. Ursache-Wirkungs-Beziehungen zwischen Funktionen oder Fehlernmöglichkeiten. Diese Beziehungen können dann wieder gezielt abgerufen und genutzt werden.
Schritt 5: Maßnahmen zum Stand jetzt und deren Bewertung
Mit Schritt 5 wechselt die FMEA-Methode aus der Analyse ins Handeln.
Schritt 5 könnte mit Maßnahmen gefüllt werden, die im Rahmen des Projekts schon gesichert durchgeführt wurden, z.B. entschiedene Übernahmen aus Vorprojekten für bestimmte Teilsysteme, Baugruppen, Komponenten, Verbindungen oder die Festlegung von Regeln für das Projekt.
Manche Unternehmen schreiben praktisch alles, was irgendwann in der FMEA als Maßnahme der Entwicklung erwähnt wird hier auf. Eine Verfolgung von Maßnahmen findet in solchen Fällen nicht statt, auch wenn das mit der Intention der FMEA-Methodik nicht mehr viel gemein hat.
Im Rahmen der Veranstaltung wurden keine Beispiele gezeigt, dass, ob und wie man solche Maßnahmen aus den verknüpften KI-Systemen abfragt und einbindet.
Die Anlage der Schnittstelle war in den Tools sichtbar. Und ich gehe davon aus, dass die drei Beispiel-Applikationen ähnliche Rückmeldungen für solche Maßnahmen generieren können, wie sie es für Strukturelemente, Funktionen und Fehler machen konnten.
Was in allen drei Beispielen ohne KI stattfand, war die Erstellung von Bewertungen.
Wie sie sicher wissen, werden in der klassischen FMEA-Methodik drei Bewertungen benötigt:
- Die Bedeutung (DE: B, EN: S =Severity) bewertet von 1-10, wie hoch im Fehlernetz aufwärts verknüpft die potentiellen Folgen im ungünstigsten Fall sein könnten.
Die Bewertung findet daher ganz oben bei den Auswirkungen zum Endkunden, zum Kunden in der Lieferkette, zum firmeninternen Kunden, bei den Auswirkungen auf den Fertigungsablauf im Werk oder den Auswirkungen auf das eigene Unternehmen statt. Diese Bewertung wird dann top-down durch das (durchgängige) Fehlernetz nach unten zu den Ursachen durchgereicht.
- Das Auftreten (DE: A, EN: O = Occurrence) bewertet von 1-10, wie gut die benannten Vermeidungsmaßnahmen gemeinsam den Fehler auf Ursachenebene verhindern.
Die Wirkung aller Vermeidungsmaßnahmen zu diesem Fehler zusammen drückt sich in einer Auftretenswahrscheinlichkeit aus. Die Maßstäbe können von Branche zu Branche unterschiedlich sein. O=3 , 2 oder 1 bescheinigt sehr wirkungsvolle Maßnahmen und i.d.R., dass das Entwicklungsziel erreicht wurde.
- Die Entdeckung (DE: E, EN: D=Detection) bewertet von 1-10, wie gut die benannten Entdeckungsmaßnahmen den konkreten Fehler auf Ursachenebene oder den Folgefehler auf Fokus-Ebene entdecken und melden können. Hier wird nicht bewertet, wie oft der Fehler wirklich aufgetreten ist (das ist dann das beobachtete A), sondern „nur“, wie wirksam die gelisteten E-Maßnahmen zusammen diesen Fehler finden können.
Alle drei Werte werden ganz „unten“ in der FMEA, auf Ursachen-Ebene, zusammengeführt. Daraus kann man einen weiteren Handlungsbedarf in Schritt 6 ableiten.
Die Bewertung in Schritt 5 wird immer subjektiv sein. Die Bewertung muss meist auf Annahmen beruhend für die Zukunft geschätzt werden. Konkrete Ergebnisse, speziell für Auftreten A, aber auch für Erkennung E, liegen in der frühen Planungsphase noch nicht vor. Bestenfalls gibt es Erfahrungswerten aus früheren Projekten. Vielfach sind die Zahlen aber auch Hoffnungen und Wünsche.
Bei den vorgestellten FMEA-mit-KI-Unterstützungs-Beispielen war die Bewertung klare Domäne des Menschen und nicht KI-generiert.
Schritt 6: Optimierung und Minderung erkannter Risiken, Neubewertung
Von der Bewertung im Zusammenspiel von B, A und E lassen sich für die Details der Ursachen lokale Risiken abschätzen. Die FMEA-Methode spricht von Handlungsempfehlungen und führt die drei Werte traditionell über Multiplikation (BxAxE) zu einer Risiko-Prioritäts-Zahl RPZ zusammen. Vor 2-3 Jahrzehnten wurde Verfahren vorgestellt, die das Vermeiden höher bewerten als das Entdecken. Mit BxA, BxE und AxE-Matrizen konnte eine Kombination von 2 Werten in das Zentrum der Bewertung genommen werden.
Aktuell präferiert wird die AP-Matrix[5]
[5] AP = Aktions-Prioritäten : Die 10 x 10 x 10 = 1000 Kombinationen von B-, A- und E-Werten werden individuell meist mit einem Wert aus Rot – Gelb – Grün belegt. Grün: Soweit alles Wesentliche ist getan, aber mehr geht immer; Gelb: Dem Team wird empfohlen, mit weiteren Maßnahmen das lokale Risiko zu mindern, es zu begründen wenn nicht; Rot: Das Team ist gefordert, weitere Maßnahmen zu definieren, um das erkannte lokale Risiko zu mindern. Wenn nicht -> Begründung und z.B. Managementfreigabe
Auch hier wurde in allen 3 Beispielen KI-Vorschläge nicht oder nur für Maßnahmen verwendet. Der Entscheid über weitere Maßnahmen, die Neubewertung und das Verfolgen von Maßnahmen bleibt beim Menschen im FMEA-Team.
Schritt 7: Kommunikation von Ergebnissen
Dieser Schritt greift auf Informationen zu, die zuvor in das System FMEA eingespeist wurden. Es wird dazu weder eine Kreativleistung noch eine neue Bewertung benötigt. Dies ist eine der Domänen von Large Language Modellen. Gib mir Daten und ich mache daraus eine kompakte, schöne und prägnante Zusammenfassung. Sag mir, wer der Adressat ist, und ich formuliere es mundgerecht für diese Zielperson.
Der KI müssen dazu drei Sachen gegeben werden:
- Die bestehenden Inhalte der FMEA.
- Die Aufgabe, was wie zusammengefasst und dargestellt werden soll.
- Das Format der Darstellung, z.B. ein Vorlagedokument, das befüllt werden soll.
Die gezeigten Beispiele gingen hier meist den Weg, die Inhalte in einem neutralen, für KI gut lesbaren Format zu exportieren. Das ist typisch kein Excel, kein Word mit seinem für den Menschen aufbereiteten Grafikformat, sondern eher eine strukturierte Textdatei (z.B. XML[6] ) .
[6] XML = Extensible Markup Language. Das ist reiner ASCII-Text, von Maschine für Maschine geschrieben. Für Menschen, die Programmiercode verstehen, ist auch XML durchaus lesbar, aber Zusammenhänge, die wir gerne grafisch erfassen, sind dort durch Referenzen (Zahlen, Namen) hergestellt, die an notwendig anderer Stelle im Text wieder auftauchen.
Auch hier können sich die KI-Ergebnisse sehen lassen und sparen dem Moderator viel Zeit für manuelles Erstellen. Allerdings sind auch die FMEA-Tools heute schon mit algorithmischen Werkzeugen ausgestattet, um die vorliegenden Inhalte in eine Berichtsform zu bringen.
Pflege der FMEA
Nicht in den 7 Schritten beinhaltet ist eine automatische Pflege der Inhalte. Und sie wurde im Workshop auch nicht behandelt.
Eine solche Pflege ist zukünftig denkbar bei
- Änderungen für den Entwicklungsgegenstand
- Einarbeitung von Verbesserungen und Reklamationen
- Die automatische Bewertung des A-Wertes aus realen Daten, seien es die Prüfergebnisse bei Verifikation und Validierung für das Design, seien es die Schrott- und Nacharbeits-Zahlen aus der laufenden Produktion für die P-FMEA.
All solche äußeren Einflüsse könnten auf den Stand der FMEA angewendet und als Delta zum letzten Stand aufgezeigt werden. Was das FMEA-Team, der Experte für ein Produkt oder einen Prozess oder das Werksteam für die laufende Fertigung damit dann macht, bleibt eine andere Frage. Aber die Änderung wären dann schon mal erfasst.
Diese Frage wurde in der Veranstaltung zwar gestellt, aber nicht als Teil der FMEA-Erstellung betrachtet.
Fazits:
- Sowohl Offline-Vorarbeiten als auch die aktive Zeit im Team lassen sich durch einen Cocktail unterschiedlicher KI-Applikationen sinnvoll unterstützten und beschleunigen.
- Was gezeigt wurde ist für mich noch keine durchgängige KI-für-FMEA. Dazu wird speziell am Anfang und am Ende der Kette zu stark auf Tools außerhalb der Benutzerführung des FMEA-Tools zugegriffen.
- Wird den KI-Sprachmodellen spezifisches Datenmaterial zum Projekt gezielt zur Verfügung gestellt und werden die Abfragen per Sprachmodell dazu mit präzisen, fallspezifischen Anweisungen ausgeführt, so sind erstaunlich verlässliche und qualitativ hochwertige Ergebnisse zu erzielen – soweit nur auf schon abgelegte Wissenselemente zurückgegriffen wird.
- Aber wir stehen mit großer Wahrscheinlichkeit erst am Anfang der Entwicklung.
Bleiben sie neugierig
Uwe Jarosch