Spätestens seit dem Erscheinen des VDA-Bandes 4, Teil 2, stellt sich dem FMEA-Anwender die Frage nach dem „Wie?“ der System-FMEA. Sicherlich geht der VDA mit dem Band zur FMEA den richtigen Schritt in Richtung einer strukturierteren FMEA-Methodik, aber vielen Anwendern der Methode FMEA stellt der Band mehr offene Fragen, als daß er in der Lage wäre, Antworten zu geben. Ziel dieses Artikels ist es, zu zeigen, daß die Fragen berechtigt, Antworten aber durchaus möglich sind.
Werfen wir gleich einen Blick in den VDA-Band. Die vorgeschlagene Systematik der „Systemanalyse“ fällt unvermittelt ins Auge und bedarf einer kritischen Betrachtung.
Tatsächlich verhält es sich so, daß zur Systemanalyse in den Beispielen fast ausschließlich eine Betrachtung der Stücklistenstruktur herangezogen wird. Hierfür gibt es zwei gute Gründe:
1. Stücklisten sind ein gutes ,,Inhaltsverzeichnis“ der Systemstruktur. Wird auf Vollständigkeit bei der FMEA-Erstellung Wert gelegt, geben die im System verwendeten „Stücke“ eine passable Checkliste ab. Daß damit bei weitem kein hinreichendes Kriterium für Vollständigkeit gegeben ist, soll im folgenden gezeigt werden.
2. Die Stückliste repräsentiert auf die einfachste Weise den ,,Aufbau“ eines Systems und damit auch einen Aspekt der Zulieferbezeichnung. Wird die Fehlerfortpflanzung immer vertikal betrachtet, dann haben wir innerhalb dieses „Systems“ auch ein sehr einfaches Prinzip der Ursachenverkettung.
Dieses Prinzip sagt, daß Fehlerursache bei den letzten „ Stücken“ im System liegen und grundsätzlich von unten nach oben wirken. Der Schuldige für Fehler ist damit tendenziell immer ganz unten im System zu suchen, den letzten (Zulieferer) beißen die Hunde.
Eines leistet die Stückliste aber auf gar keinen Fall: Sie beschreibt nicht das Verhalten eines Systems.
Daher wollen wir uns an dieser Stelle kurz dem Systembegriff zuwenden.
Der Systembegriff
„Ein System (Bild 1) besteht aus einer Menge von Elementen (Teilsystemen), die Eigenschaften besitzen und durch Beziehungen miteinander verknüpft sind. Ein System wird durch eine Systemgrenze von der Umgebung abgegrenzt und steht mit ihr durch Ein- und Ausgangsgrößen in Beziehung (offenes System). Die Funktion eines Systems kann durch den Unterschied der dem Zweck entsprechenden Ein- und Ausgangsgrößen beschrieben werden.“ [Ehrlenspiel, Integrierte Produktentwicklung]
Um es kurz zu machen: Verhaltensbeschreibungen sind funktional.
Auch der VDA-Band sieht Funktionszuordnungen vor. Diese haben folgendes Aussehen (Bild 2).
An die Stücke/Elemente werden als Verhaltensbeschreibungen Funktionenlisten geschrieben. Dies sind noch vollkommen ungerichtete Funktionen, die die Strukturelemente erfüllen sollen. Das systematische Negieren der Funktionen führt zu den potentiellen Fehlern des Systems.
Eine FMEA entsteht nun aus der Zusammenfassung der Systemkomponenten.
Wie kommt aber „Fehler 1″ dazu, daß „Fehler 2″ im „ übergeordneten“ System eine Folge ist und umgekehrt, wer sagt „ Fehler 1″: deine Ursache liegt in „Fehler 2″? Hierauf kann der VDA-Band keine inhaltliche Erklärung geben.
Schwieriger wird es, wenn das Fehlerverhalten auf einer Ebene des Baumes beschrieben werden soll oder sogar Ebenen übergreifend. Inzwischen wird vom VDA vorgeschlagen, daß für diese Fälle Schnittstellen-FMEA geschrieben werden sollen. Aber was in der Terminologie der Systemanalyse ist eine „ Schnittstellen-FMEA“?
Niemandem wird es, meine ich, schwer fallen, darin zuzustimmen, daß alle Teile eines Fahrzeugs, die keine Schnittstellen haben, nur von geringem Nutzen, damit zu teuer und letztlich überflüssig sind.
Szenarien der Systemanalyse
Im folgenden möchte ich einen Vorschlag für Systemanalyse unterbreiten, der einerseits die genannten Probleme löst und andererseits besser mit anderen Methoden des präventiven Qualitätsmanagements und der Kreativitätsförderung zusammenarbeitet.
Für diese Systembetrachtungsweise möchte ich den Begriff des Szenarios einführen. Szenarien beinhalten als Systemelemente die uns vom VDA-Band bekannten „Stücke“. Pfeile innerhalb des Szenarios beschreiben die Wirkzusammenhänge. Die Pfeile haben Namen für die funktionale Beschreibung oder Wirkungsweise. Man kann auch sagen, bei Szenarien handelt es sich um eine Art von Blockschaltbildern oder Systembeschreibungen mit der Besonderheit, daß das mehrfache Auftreten von Komponenten und Funktionen berücksichtigt und koordiniert wird. Ich spreche von Szenarien auch deshalb, weil wir vom Gesamtsystem idR. nur einen Ausschnitt mit einer bestimmten Zielsetzung sehen und selten in der Lage sind, das gesamte System zu betrachten.
Fluß- und Verhaltensstruktur
Jedes Element eines Szenarios kann Sub-Szenarien hervorbringen. Elemente können natürlich auch in mehreren Szenarien auftauchen bzw. eingesetzt werden. Sub-Szenarien generieren so etwas wie die aus VDA bekannte Baumstruktur, wenn die Ebenen übergreifende Aufbaustruktur betrachtet wird. Der entscheidende Unterschied zu VDA ist aber, daß Funktionen die gerichteten Bindeglieder zwischen den Systemelementen darstellen und damit eine Fluß- und Verhaltensstruktur gebildet wird. Nur auf diese Weise ist eine durchgängige Systembeschreibung, die gleichzeitig Aufbau- und Verhaltensbeschreibung ist, gewährleistet. Szenarien übergreifende Schnittstellen werden durch Pfeile von einem Szenario in das andere dargestellt. Sie können aber übersichtlicher und wesentlich einfacher dargestellt werden, indem ein neues Szenario eröffnet wird, worin die an der Schnittstelle beteiligten Elemente zusammengefaßt werden.
An die benannten Pfeile, die die funktionalen Beziehungen der Elemente repräsentieren, werden als Negation die potentiellen Fehler der FMEA geschrieben. Hier ist das Vorgehen dem des VDA sehr ähnlich. Der entscheidende Unterschied liegt aber darin, wie einfach innerhalb dieser Szenarien Fehlerursache und Fehlerfolge gefunden werden können. Um tiefere Fehlerursachen zu entdecken, muß den Pfeilen oder den Funktionsverknüpfungen nur in umgekehrter Richtung gefolgt werden, Fehlerfolgen pflanzen sich in Richtung der Pfeile fort.
Fehlerfolgen müssen bewertbar sein
Zurück zur FMEA bzw. zum bekannten Formblatt der FMEA.
Wir haben gesehen, wie sich Fehlerfolgen als eine oder mehrere Listen von möglichen Fehlern in Wirkungsrichtung der Funktionen darstellen. Die meisten dieser Fehlerfolgen sind aber für FMEA hinsichtlich der Bedeutung nicht bewertbar, da sie nur interne Fehlerfolgen sind: Sie sind nur Bestandteil der Kette der Ereignisse, die zu dem entscheidenden Ereignis führt, das den Kunden betrifft.
Was muß in der Spalte Fehlerfolge nun tatsächlich stehen?
Jedes Szenario erfüllt eine Menge von Kundenanforderungen. Für FMEA relevante Fehlerfolgen sind allein die Negationen von Kundenanforderungen, also nicht erfüllte Kundenanforderungen. Hier geht die FMEA nahtlos in QFD über oder umgekehrt: QFD ermittelt die Kundenanforderungen und setzt sie in Sollfunktionen des Systems um.
Mit Hilfe dieser Überlegungen können wir bei entsprechendem Informationsmaterial sehr einfach die Fehlerfolge ableiten. Ferner führt diese Vorgehensweise dazu, daß ein für allemal die Fragen und Streitereien hinsichtlich Fehlerursache und Fehlerfolge geklärt sind. Wer in diesem Sinne QFD anwendet, bekommt auch noch gleich die Bewertung der Bedeutung mitgeliefert.
Mit Fehlerbaumanalyse zur Systemanalyse
Eine andere, sehr „geradlinige“ Vorgehensweise ist es, mit Hilfe der Fehlerbaumanalyse zur Systemanalyse zu gelangen. Als das Top-Event, das unerwünschte Ereignis, wird die nicht erfüllte Kundenanforderung herangezogen. Der Ausfall auf der höchsten Ebene wird daraufhin systematisch heruntergebrochen, im Sinne von „was sind tiefere Ursachen für das Ereignis“. Dadurch erhält man eine negative Systembeschreibung. Diese Methode ist sehr gut für Teamsitzungen geeignet, da die Dynamik des Teams der „ detektivischen“ Vorgehensweise der Fehlerbaumanalyse bestens entspricht.
Die Bewertungen aus QFD liefern wieder den Leitfaden und Fahrplan mit dem die Fehlerbäume in der Rangordnung der Wichtigkeit der Kundenanforderungen erstellt werden. In einem weiteren Schritt wird der Fehlerbaum in die oben beschriebene Systemstruktur eingebunden, bzw. darin umgewandelt. Der Fehlerbaum verteilt sich dann idR. auf mehrere Szenarien.
Vollständigkeitskriterien
Wann ist nun eine FMEA vollständig? Nun, zwei notwendige Kriterien haben wir gefunden:
1. Wenn alle bewerteten „Stücke“ des Systems betrachtet wurden. (Was mit „Betrachten“ gemeint ist, wird gleich noch ausgeführt.)
2. Wenn alle Kundenanforderungen als Fehlerfolgen negiert worden sind.
Beide Vollständigkeitsanforderungen an eine FMEA sind nur zwei Seiten der gleichen Medaille. Warum?
Die beste Antwort darauf gibt QFD. Ein System sollte nur aus Elementen bestehen, die mittelbar oder unmittelbar Kundennutzen produzieren. QFD zeigt diesen Zusammenhang auf. Somit bedürfen Elemente, die nicht auf einen Kundennutzen verweisen, keiner Analyse bzw. Unterstützung. Sie können sogar aus dem System entfernt werden.
Die Forderung 1. hört sich sehr streng und unnötig umfangreich an. Aber nicht nur QFD liefert, wie wir gesehen haben, Möglichkeiten des „begründeten Ausschließens“ von Szenarien und Systemelementen. „Betrachten“ im Sinne von 1. bedeutet ebenso, daß gute Gründe gefunden und dokumentiert wurden, an bestimmten Stellen des Systems keine tieferen Analysen vorzunehmen. Gerade das vorgeschlagene Vorgehen ermöglicht es, Zusammenhänge kompakt darzustellen und eine Konzentration auf das Wesentliche vorzunehmen, ohne weite „Systembäume“ aufspannen zu müssen.
Fazit: Szenarien schaffen Durchgängigkeit der Wissensbestände
Nochmals zurück zum Begriff des Szenarios. Szenarien sind motiviert aus der Tatsache, daß ein und dasselbe Systemelement unter unterschiedlichen Anforderungen bei unterschiedlichen Kunden genutzt wird. FMEA System 2.0 ermöglicht es nun, daß jedes Systemelement die Obermenge aller dieser Verwendungen kennt. Damit können Fehler, die in einem Szenario entdeckt wurden, ihre Wirkung auf andere Szenarien melden und ggf. automatisch abgleichen.
Die Wiederverwertbarkeit und Durchgängigkeit der Wissensbestände ist sichergestellt.
FMEA System 2.0 erlaubt es jetzt schon, die Durchgängigkeit der genannten Systemanalyse zu nutzen.
An der Szenariotechnik sowie den genannten Schnittstellen zu QFD wird in aktuellen Forschungs- und Entwicklungsvorhaben gearbeitet. Die entscheidende Sichtweise, welche Funktionen als zentrales Element der Verhaltensbeschreibung eines Systems etabliert, war seit jeher der Angelpunk der Systemanalyse mit FMEA-System.
Weitere Informationen A QE 302
Marcus Schorn, Geschäftsführer, PLATO GmbH, Lübeck
