FMEA bedeutet, Failure Mode Effect Analysis und wird ins Deutsch fehlerhaft übersetzt mit Fehler Möglichkeiten Einfluss Analyse. Eine bessere Definition wäre Fehler Modi Auswirkungs-Analyse. Ganze Heerscharen von Moderatoren (wobei das kein geschützter Begriff ist), bringen die Entwicklungs-Kollegen regelmäßig zur Verzweiflung, wobei es, an sich so einfach wäre, weil FMEA das Normale eines ingenieurmäßigen Vorgehens ist. Stunden von Zeit werden typischerweise verbrannt ohne dass dies irgendeinen Nutzen für die Firma hat – außer Formalbefriedigung. Das spricht jetzt nicht wirklich für die Richtigkeit.
Es gibt nur Design und Prozess FMEA aber die Verwendbarkeit von FMEA ist nicht auf Design und Prozess beschränkt. Allerdings trifft das nur zu, wenn man verstanden hat, was FMEA ist.
Das typische Vorgehen (am Beispiel Design FMEA)
Ist z.B. im FMEA AIAG Handbuch beschrieben. Da wird dann ein (mechanisches / software- oder hardwaremäßiges ) Design oder ein Herstellungs-Prozess in die Einzelkomponenten oder in Prozessschritte zerlegt und „im Team“ wird betrachtet, welche Funktionen und Fehler es geben könnte, sowie welche Merkmale existieren. Dann wird ersonnen, wie man das Vermeiden, bzw. erkennen kann Auf gut Deutsch: Viele Leute sitzen um einen Moderator herum und scheuen zu, wie dieser etwas eintippt. Höchst ineffizient.
Da FMEA aber immer erst gemacht wird, wenn der Freigabetermin vor der Tür steht, bzw. „weil der Kunde es will“, ist der Nutzen der FMEA, wenn es ihn denn überhaupt gibt, eher marginal.
Methode der FMEA – mal etwas Anders
So steht es zwar nicht im Lehrbuch, aber so wie im Folgenden beschrieben, macht es Sinn, Spaß und ist erfolgreich.
Beginnen Sie die FMEA, bevor Sie etwas aufs Papier bringen – Das ist FMEA Standard und wird systematisch ignoriert
FMEA macht man nur für sich selbst.
FMEA ist keine Formalbefriedigung, Sie dient dazu selbst besser zu werden.
FMEA ist das Normale (sollte es sein)
Jedes Mal, wenn in einer technischen Entwicklung irgendetwas gemacht wird, betrachtet man:
Ein Systemelement gesamt (BSP.: Motor) , ein Systemelement Einzelkomponente (Bsp. Zylinder) oder ein Systemelement Zusammenbau (Bsp. Zylinder und Pleuel zusammen fügen)
Eine Funktion (des Systemelements) (Bsp.: Leistung nach Vorgabe zur Verfügung stellen) oder ein Merkmal (des Systemelements) (Bsp.: Leistung bei 5000 U/min > 150 kW)
Eine mögliche Fehlfunktion (des der Funktion ) (Bsp. Funktion: Leistung nicht nach Vorgabe) Eine mögliche Fehlfunktion (des Merkmals) (Bsp.: Merkmal: Kilowatt bei 5000 U/min < als spezifiziert)
Eine Vermeidungsmaßnahme (Nur auf der Merkmalsebene!) (mit der man auf theoretischer Ebene) verhindert, dass der Fehler auftritt. z.B.: Auslegung anhand von Erfahrungswerten, Theorie etc.)
Eine Entdeckungsmaßnahme = ein Nachweisverfahren (Nur auf der Merkmalsebene!) (mit der man nachweist, dass die Funktion, welche durch das Merkmal bereitgestellt wird korrekt erschaffen wird. z.B.: Messung der Leistung auf dem Motorenprüfstand (nach einem standardisierten Verfahren).)
Wenn man dies für jede Baugruppe und jedes Bauteil einer Entwicklung (mechanisch) beziehungsweise für jede Software oder Hardware Komponente tätigt, so ist das natürlich ein Riesenaufwand.
Die oben angegebenen Ziele einer FMEA sind jedoch meines Erachtens falsch definiert.
Die Richtige Definition
Die richtige Formulierung sollte lauten:
Kontrolle über das Design einer Entwicklung erhalten, so dass die gewünschte Funktionalität des Gesamtsystems, eines Zusammenbauschritts oder eines Bauteils erreicht wird.
Kontrolle über einen Produktionsprozess zu erhalten, so dass die Merkmale, welche vom Design festgelegt worden sind, prozessfähig erreicht werden.
Sie mögen nun einwenden, dass diese Formulierung mit der oberen identisch ist, allerdings ist ganz besonders hervorzuheben, dass die Zielrichtung in der von mir genannten Formulierung dahingehend ist, dass es darum geht etwas unter Kontrolle zu bekommen, während in der ursprünglichen Ausrichtung man sich darauf konzentriert Risiken in einem Produkt oder Prozess zu bewerten.
Der Unterschied ist jedoch gravierend: In der Fliegerei sagt man, dass man dorthin fliegt, wo man hinschaut. In der von mir verwendeten Formulierung geht die Aufmerksamkeit: Die Kontrolle über die Funktion eines Bauteils, einer Baugruppe und des Gesamtprodukts zu bekommen, während in der AIAG VDA Formulierung die Aufmerksamkeit auf die Risiken und Fehler gelenkt wird.
Die Aufmerksamkeit auf Risiken zu lenken, führt dazu, dass man die Zielrichtung Risiko bekommt und dementsprechend in übertriebener Darstellung sich andauernd vor potenziellen Angriffen schützt (Angriffe im Sinne von Fehlern / Risiken). Die Aufmerksamkeit auf die gewünschte Funktion zu lenken, führt zu einem anderen Herangehen.
Wenn Sie ihre Aufmerksamkeit darauf richten sicherzustellen, dass die Funktion erreicht wird, was das typische Vorgehen im Ingenieursbereich ist, folgen sie dem Vorgehen was man gelernt hat und welches sich erfolgreich erwiesen hat. Die Verlagerung der Aufmerksamkeit von der Fehlervermeidung hin zur Sicherstellung der Funktion ist ein gravierender Unterschied.
Verantwortung des Managements
Die Durchführung der FMEA kann sehr zeitaufwendig sein
FMEA Handbuch – Kapitel 1.3.2
Wenn sie eine FMEA durchführen, so kann diese extrem zeitaufwendig sein. Dies wird vom Management fast immer unterschätzt. Es ist eine wirkliche Herausfordefung, eine FMEA sauber durchzuführen, weil es wirklich Brain Power verlangt. Also genau das wofür sie ihre Ingenieure eingestellt haben.
Aufgaben (im Design)
Erstellung des Strukturbaums
Erfassen der zugehörigen Zusammenbauschritte
Erfassen der beteiligten Designelemente
Erfassen der Funktionen eines jeden Elements / Schritts
Definition der Merkmale, welche eine Funktion definieren
Erfassung möglicher Fehler einer Funktion und eines Merkmals
Dokumentation der Maßnahmen zur Vermeidung eines Fehlers
Dokumentation der Maßnahmen, mit denen die Entstehung des Fehlers und der zugehörigen Funktion erkannt und die Funktion sichergestellt wird.
Grundverständnis Design FMEA
Wie bereits oben angegeben. Die korrekte Zieldefinition wäre:
Kontrolle über das Design einer Entwicklung erhalten, so dass die gewünschte Funktionalität des Gesamtsystems, eines Zusammenbauschritts oder eines Bauteils erreicht wird.
Im Folgenden sehen Sie das Bild (eine beispielhafte Darstellung) einer FMEA zu einer Brille.
Bild: Beispiel einer FMEA
Auf der obersten Ebene habe ich ein einfaches Beispiel eingefügt: die Brille soll dafür sorgen dass eine optimale Sehschärfe da is. Optimal ist ein nicht definierter Wert, genau so wie schön, groß, klein et cetera. Auf der Ebene des Bauteils selbst werden die Funktion des Bauteils, genauso wie die Fehler der Funktion so beschrieben, dass sie universell einsetzbar sind (Wiederverwertbarkeit von erschaffenen Daten). Auf der Merkmalsebene werden nun die einzelnen Merkmale (Messfähigen Größen) dargestellt, welche die entsprechende Funktion definieren. Die angegebenen Merkmale, sind Merkmale, welche vom Augenarzt verwendet werden, um ihre Brille zu beschreiben.
Nun, da man jetzt einen Wert hat, welcher dafür sorgt, dass ein optimales Sehen stattfindet, kann man sich anschauen, welche Maßnahmen man ergreifen kann, um sicherzustellen, dass die entsprechende Funktion gewährleistet wird, beziehungsweise welche Maßnahmen man ergreifen kann um sicher zu gehen, das ein fehlerhafter Wert nicht vorhanden ist.
Die Funktion der optimalen Sehschärfe wird also durch messfähige Merkmal, hier im Beispiel mit dem sphärischen Brechwert, der Zylinderstärke und der Pupillendistanz definiert.
Wie Sie sehen, sind in dem Beispiel nun Maßnahmen zur Vermeidung eines Fehlers wie zum Beispiel dass Dioptrie> als spezifiziert aufgeführt. Ebenso ist eine Maßnahme zur Erkennung dargestellt.
In einer technischen Auslegung eines Bauteils oder eines Zusammenbauschritts, kommen jedoch teilweise mehr als 40 Merkmale auf einem Bauteil zusammen und um ihnen ein Beispiel zu geben was ich beim Kunden durchgeführt habe. Bei einer Lithiumionenzelle gibt es insgesamt 80 Systemelemente (Bauteile und Zusammenbauschritte), ca. 1000 Funktionen, ca. 1300 Merkmale, ca. 3000 mögliche Fehler und dementsprechend pro Fehler mindestens eine Vermeidungs- und eine Erkennungsmaßnahme.
All diese Maßnahmen müssen tatsächlich durchgeführt werden, um sicherzustellen, dass die Funktionalität des Objekts, welches man entwickelt, erreicht wird.
Im obigen Bild sehen Sie noch Verbindungspfeile vom Merkmal zur Funktion beziehungsweise vom Fehler des Merkmals zum Fehler der Funktion. Diese Abhängigkeit muss auch dargestellt werde, da Sie ansonsten keine Kontrolle erhalten können. (Wissen an welcher Schraube man dreht, um die Veränderung zu erhalten) Die Anzahl der Netzknoten (so heißen diese Verbindungungen) ist im Falle einer Lithium Ionen Zelle bei etwa 6000. Die Gestehung einer solchen FMEA, um die Kontrolle über ein Design zu erhalten, ist verständlicherweise aufwendig, wie bereits oben mit dem Zitat aus dem Handbuch dargestellt
Wenn Sie sich nun vorstellen, dass die Pflege der Inhalte in eine FMEA in einem Team von 5 Personen getätigt wird, so können sie sich den Zeitaufwand und ausmalen der mit dieser Aktivität einhergeht.
Fehler Vermeidung
Die Vermeidung von Fehlern in dem Falle in Bezug auf ein Merkmal macht man typischerweise mit Auslegungen wie im Folgenden beschrieben:
auf Basis von Erfahrung
auf Basis von Benchmark-Studie
auf der Basis analytischer Nachweisverfahren (FEM, Simulation, etc)
auf Basis von iterativen Verfahren
auf Basis zutreffender „normativer“ Vorgaben
Fehler Erkennung
Fehler erkennt man, in dem man einen Test durchführt, der sicherstellt, dass die Funktion, welche durch das Merkmal definiert wird, in der Anwendung, beziehungsweise in dem Zusammenbau Schritt überprüft. Hier muss tunlichst darauf geachtet werden, dass die Testverfahren standardisiert sind.
Nur das Normale
Das oben beschriebene, ist nur das Normale, was ein Ingenieur beziehungsweise ein Entwickler durchführt.
Wenn es aber das normale ist, wieso brauche ich dann einen Moderator, der mit vielen Kollegen gleichzeitig am Tisch sitzt, und bei dem alle zuschauen, wie er die Daten in ein Tool eingibt.
Die Lösung
Die Benutzung von IT Werkzeugen ist heutzutage sehr einfach geworden. Anstatt also mit vielen Leuten gleichzeitig zu sitzen und jemandem zuzuschauen, wie er Daten eingibt, sollte die Lösung doch darin bestehen, die normalen Verhaltensweisen des Ingenieurs direkt von diesem Ingenieur in das Tool eingeben zu lassen.
Natürlich wird es Dinge geben, bei denen man einen Moderator braucht. Also beim Brainstorming, und bei der Verkettung von Funktionen oder aber viel Funktionen mag es hilfreich sein, jemanden dabei zu haben, der hier unterstützt. Aber auch dieses Brainstorming findet typischerweise in der Gruppe der entsprechenden Entwickler statt, welche sich gemeinsam Gedanken darüber machen, wie man irgendwelche Herausforderungen lösen kann. Anstatt also nun im Nachhinein die ganzen Gedanken von einem Moderator in ein Tool eintragen zu lassen, ist es viel einfacher die ganzen Daten im Moment der Entstehung von den Ingenieuren selbst eintragen zu lassen. Sie müssen also nur hingehen und ihren Kollegen die Fähigkeit beibringen, das entsprechende FMEA Werkzeug zu bedienen und sie dahingehend zu trainieren, das Tool bei jeder Maßnahme, welche die Ingenieure ergreifen, sofort zu befüllen.
Zeit- und Informationsgewinn
Wenn Sie wie oben angegeben verfahren, und ihre Ingenieure dazu bringen, all ihre Gedanken und ihre Tests selbstständig direkt in das Tool einzutragen, sparen Sie sich Unmengen an Zeit, weil nun plötzlich nur noch eine Person, anstelle von 4 bis 7 Personen die Daten ins Tool eingibt und ebenso erzeugen Sie, dadurch dass die Kollegen es selber machen, ein viel besseres Verstehen der Ingenieure über das Produkt, welches sie entwickeln, gleichzeitig ist der Informationsgewinn für die Firma erheblich grösser. Dies trifft insbesondere dann zu, wenn die Routine etabliert wird, wirklich jeden Gedanken zu notieren und den entsprechenden Status des Gedanken, beziehungsweise der Umsetzung, anschließend in diesem Tool festzuhalten.
Damit sie eine Dimension haben:
mit der von mir vorgeschlagenen Änderung benötigen Sie in einem großen Projekt ca. 70% weniger Zeit für die Dokumentation. Also konkret, ca. 10.000 Stunden für eine große Fertigungsanlage gegenüber 30.000 bis 40.000 Stunden im althergebrachten Verfahren.
Also ohne Moderator
Nicht ganz ohne, aber anstatt im typischen Verfahren Daten im Nachhinein einzutragen, lassen Sie es Iihre Ingenieure selbst machen.
Sie müssen typischerweise nur 1 x die Struktur aufziehen und haben dann die Möglichkeit zur Wiederverwendung.
