Kommunikation durch FMEA?

Vor Kurzem wurde ich auf das Thema unternehmensweite Kommunikation durch FMEA angesprochen. Dazu fiel mir folgende Story ein:

Als Co-Moderator (und Coach) habe ich erlebt, wie der Fertigungsplaner, den ich zur Teilnahme an der D-FMEA überredet habe, nach wenigen Minuten des gemeinsamen Ausarbeitens des Block-Diagramms begann, mit großen Augen Fragen zu stellen.

„Ach so soll das funktionieren! Da könnte man an der Vorrichtung…“ „Wie stehen denn die beiden Teile in Verbindung?“ …

Nachdem dann der Strukturbaum analysiert war und noch ein Teil in der Stückliste aufgenommen war, ging der Kostenanalytiker noch mal ans Werk. Weil die Angebotsphase noch nicht abgeschlossen war und eine schlüssige Argumentation möglich, wurde der Preis erfolgreich nachverhandelt.

Schon in der ersten Runde der Optimierungsphase war klar, dass die Schraubverbindungen zwischen den Gehäuseteilen zusätzlich zum Drehmoment auch den Drehwinkel auf der Zeichnung haben muss und beides mit einem SC versehen. Die Fertigung hat ohne zusätzliche Kosten den Überwachungsschritt für den Schrauber frühzeitig integriert.

So führt unternehmensweite Kommunikation zu gutem gemeinsamen Systemverständnis. Und die regelmäßigen Besprechungen – mit Hilfe einer geschickten „agile“ Moderation ? – zu besserem Kennenlernen, Wertschätzung und Verständnis unter den Teammitgliedern.

Auch diese Erfahrung hat die FMEA-Moderation und Neu-Integration zu einem Hauptbestandteil meiner Selbständigkeit gemacht.

Mein Angebot:

Ich biete, wenn gewünscht, einen Coaching-Teil für alle Teilnehmer während der Moderation und auch reine Trainings-Sitzungen. Ich denke aber, die 70:20:10-Regel gilt auch und besonders bei der FMEA. ?

FMEA – Vorteile und zusätzliche Aspekte von Agile

Ich habe gerade auf LinkedIn eine Präsentation geteilt (https://bit.ly/3F4TOy4) und ein paar Aspekte ergänzt, die ich hier gern als Blog veröffentlichen möchte:

Very good overview of FMEA!

I want to add/underline some points.

  • ?Improves team- and company wide communication, including customer and suppliers.
  • ?Ensures common understanding of functions, requirements, specifications, input, outcome (wanted and unwanted), borders and limits of the system, technical solutions, processes, changes under focus.

I miss the handling and use of characteristics (Special, Critical)- contact me if you have questions about.
And the automotive industry should be aware of changes came with new handbook AIAG/VDA 2019.

Finally, success and acceptance of FMEA depends on the way how the people are lead and motivated and how the company can take most advantage of the process and every single outcome.

Agile thinking implements flexibility and adjustability. This is also an important aspect of FMEA implementation.
Think about the process, the used software and how you can take best profits from.
Agile principles give orientation in how to interact in the team and how to handle VUCA also in FMEA.
And more…

Die wirksame FMEA

Wer kennt es nicht: „Wir brauchen noch eine FMEA!“. Pflicht im Automobilsektor, empfohlen für risikoträchtige Produkte, manchmal notwendig zur rechtlichen Absicherung.

Von den betroffenen Ingenieuren wird sie meist als zusätzliche Last empfunden. Es ist nicht mehr als pure Pflichterfüllung. Die Moderation besteht aus Einzelinterviews mit den beteiligten Projekt-Verantwortlichen und Experten. Der Moderator ist der Einzige, der die Software bedienen kann etc.. Alles nicht nur einmal erlebt.

Eine Sichtweise der Optimierung hat zum Ziel, den Aufwand auf ein Minimum zu reduzieren. So viel wie nötig und sinnvoll heißt das Motto und bekommt den Namen „Lean“. Ich sehe das etwas anders. Ein wesentliches Prinzip bei Lean ist Kaizen – kontinuierliche Verbesserung und das ständige Streben nach Perfektion. Also wie nutze ich das mächtige aber auch flexible Werkzeug FMEA im Kontext meiner spezifischen Entwicklungsprozesse zwischen

  • Kundenwünschen
  • Anforderungsmanagement,
  • Spezifikation von Bauteilen und Produktionsmitteln,
  • Verifizierung und Validierung von Teilen und Herstellprozessen bis zu
  • Änderungs- und Variantenmanagement in der laufenden Produktion

für maximale Effizienz, effektive Fehlervermeidung und maximale Sicherheit meiner Produkte und Prozesse?

Wenn es schon sein muss, wie kann ich den möglichst größten Nutzen daraus ziehen?

Wenn FMEA als Risiko-Management-Tool nicht verwendet wird: Wann macht es für mein Unternehmen Sinn und wie setze ich es optimal und angepasst ein? Herr Sommerhoff stellt 2017 fest:

„Pro-forma Anwendung zur
Systembefriedigung auf Basis von Verpflichtungen zur FMEA schadet der Methode. Es diskreditiert sie, bringt sie in Verruf.“

https://www.dietz-consultants.com/system/public/file.php?file=afd8ec82910fed8MTgx

Herr Kapust (Agile FMEA Erstellung) beschreibt treffend die Wellenbewegungen von Phasen niedrigen Interesses zu Phasen von erhöhtem Interesse, immer wenn ein Audit ansteht, der Kunde kommt, Änderungen anstehen oder etwas rapide in die Hose gegangen ist und die GF fragt, warum die FMEA das nicht verhindert hat.

Der Jurist verlangt sinnvollerweise „Verständlich, vollständig, abgearbeitet und wahr.“ (Juristische Aspekte der FMEA). Ich ergänze: Durchgängig! Die Harmonisierung der FMEA im Automobilsektor zwischen AIAG und VDA zeigt die Basis hierfür.

Sobald die erste Stückliste, der erste Systementwurf, die erste Prozessfolge definiert ist, beginnt die FMEA.

Es können Block-Boundary- und Parameter-Diagramme erstellt werden und der Moderator kann mit dem Systemanalysten / Architekten die Struktur planen. Ein Negieren der Kunden-Spezifikation (functional requirements) bringt eine ungeordnete Liste von Fehlern.

Ein Stück Kaizen ist inklusive, da viele OEMs historische Fehler in ihren Spec’s verarbeiten. Hier beginnt auch die Verfolgung von Merkmalen (SC/CC/IC), die ohne ein gefundenes Poka-Yoke bis zum Control Plan in der Fertigung reicht. Es funktioniert nur mit konsequent verfolgten Charakteristika, die von der D-FMEA in die Zeichnungen und Spezifikationen der Einzelteile und Baugruppen Einzug halten (in Form von SPC z.B.).

Oder lückenlos in die P-FMEA eingehen und dann, sofern kein Prozess-Poka-Yoke gefunden wird, in den Control Plan finden.

Das klingt aufwändig und umfangreich und das ist es auch. Komplexe Systeme mit tausenden von Ursachen zu beherrschen, verlangt Überblick und Durchhaltevermögen. UND:

Eine Automation hierfür ist im Zeitalter der Digitalisierung angeraten. Gute Systeme sind am Markt (iQUAVIS z.B.). Anbieter von etablierten Systemen wie IBM Rational, Plato, Apis, SAP, IQM etc. sind gefordert, anforderungsgerechte Schnittstellen bereitzustellen.

Gute Template-Systeme oder sog. Familien-FMEAs reduzieren über längeren Zeitraum den Aufwand. Deren Erstellung verlangt enormen Ehrgeiz und Geduld, bis die ersten neuen Projekte davon profitieren. Wesentlich ist, dass Lessons Learned direkt in die Templates fließen, laufend und kontinuierlich. Genauso wichtig ist natürlich, dass Trivialitäten eliminiert werden. Fehler mit Auftretenswahrscheinlichkeit nahe Null kommen regelmäßig auf den Prüfstand und fliegen ggf. aus dem Template.

Noch wichtiger ist, dass neue FMEAs nie mehr aus alten kopiert werden sondern immer aus den Templates zusammengesetzt sind, die die neuesten Fehler, Ursachen und empfohlenen Maßnahmen enthalten. (Plato Template-Manager oder ähnlich).

Agilean – Aus „komplex“ mache allerhöchstens „kompliziert“, aus Kooperation wird interdisziplinäre Interaktion, aus Kundenorientierung wird Kundeninteraktion, aus Schienen werden Leit- und Schutzplanken, iterativ, menschenzentriert etc.

Dazu in einem weiteren Artikel mehr.

Was sind Eure Gedanken dazu?

Gruß Thomas Luft

Sie möchten die FMEA für Ihr Unternehmen als Tool für die Fehlervermeidung durch frühzeitige und systematische Analyse nutzen? Sie benötigen Unterstützung? Als erfahrener Entwickler mitten aus der Welt der Mechatronik und ausgebildeter FMEA-Moderator stehe ich Ihnen zur Seite.

Geht FMEA auch agil?

Agil (Scrum, agilean) ist ja schön und gut und hilft uns auch voran, doch wie soll nun die FMEA ablaufen? Auch in Sprints?

Nutzen wir andere agile Methoden? Passt dieses behäbige Ungetüm FMEA zu agil? Steht nicht das funktionierende Produkt vor der umfassenden Dokumentation?

Ist FMEA so fest mit traditionellem Risiko- und Anforderungs-Engineering verknüpft, dass eine andere Vorgehensweise keinen Sinn ergeben würde?

Ich glaube, dass die FMEA in agilen Umgebungen nur profitieren kann. Ebenso das agile Arbeiten von der FMEA. So fördert die FMEA die unternehmensweite Kommunikation und die Interaktion mit Kunden und Lieferanten.

Die immer begleitende System- und Risiko-Analyse sowie deren verständliche Darlegung befördert Klarheit und Transparenz und verringert die Komplexität.

Herr Kapust hat in seinem Artikel https://www.microtool.de/projektmanagement/agile-fehlermoeglichkeits-und-einflussanalyse/ treffend das „WOZU?“ beschrieben. Zu jedem Punkt, der eine agile FMEA auszeichnet, sind Problematik und ein Lösungsansatz benannt.

Die Frage nach dem sinnvollen Einsatz sollte natürlich geklärt sein. Es sei hier verwiesen auf das „Manifest für ein agiles Qualitätsmanagement“ der Deutschen Gesellschaft für Qualitätssicherung und die Ausarbeitung von B. Sommerhoff von 2017 „Agiles QM am Beispiel der FMEA“: „

Im agilen Umfeld (Sommerfeld schreibt von „Quickware“ – TL) ist die FMEA ein Störfaktor, setzt zu viel Planbarkeit und Prozessstabilität voraus, die nicht mehr gegeben sind. Die meisten heutigen Kombinationsprodukte aus Hard- und Software sind so komplex, interagieren so mannigfaltig in und mit Systemen, dass eine präventive FMEA nicht mit vertretbarem Aufwand möglich und eine begleitende FMEA nicht leistbar ist.

B. Sommerhoff „Agiles QM am Beispiel der FMEA“

Er kommt zu dem Schluss, dass die FMEA dort einzusetzen ist, wo sie die beste Wirkung erzielt und zwar möglichst digitalisiert und richtig angewendet. Das trifft aus meiner Sicht dort zu, wo auch agilean erfolgreich umsetzbar ist. Nämlich in hybriden, durchaus auch komplizierten Produkten und Organisationen mit nicht zu schnelllebigen Zyklen und hochfrequenten Beta-Releases. Nicht zu unterschätzen ist der Lessons-Learned-Effekt der FMEA für diese Organisationen. „Quickware“ benötigt dann andere Lösungen.

Spannend ist ebenso Frage nach dem „WIE?“.

Ist die Entscheidung pro-FMEA gefallen oder ist diese unumgänglich, folgt die Frage nach der Integration in die agilen Prozesse (SCRUM / Agilean).

Wie könnte „Agilität“ nun aussehen?

Unbestritten sollte sein, dass die FMEA als Ergebnis mit am Board hängt und in allen Events von Planung über Sprint-Übergänge, Retrospektive bis zur Celebration vorkommt. Es ist obligatorisch, dass die FMEA (Risiko-Bewertung) von den Stakeholdern als Voraussetzung für die Bewertung des Projektes, z.B. in Gate Reviews, abgefragt wird.

Zu Beginn sind die Ergebnis-Stickies verhältnismäßig klar:

  • „Scoping“ (Planung) erfolgt
  • Systemstruktur erstellt und aktuell
  • Funktionsanalyse erstellt und aktuell

Es sollten auch die erforderlichen Dokumente und sonstigen Voraussetzungen für erfolgreiche FMEA-Sitzungen abgefragt werden, z.B. :

  • Produktionsablauf-Plan
  • Block-Boundary Diagramme
  • Parameter Diagramme

Im weiteren Projektverlauf heißt das Sticky-Note:

„Die FMEA ist aktuell.“ (Nicht „fertig“!) , was gleichbedeutend sein muss mit „Verständlich, abgearbeitet und wahr.“ zum gegebenen Zeitpunkt.

Ein viertes Kriterium einer guten FMEA ist „vollständig“.  An dieser Stelle ergibt sich eventuell ein Ansatz für die iterative Abarbeitung. Es könnte ein Ziel sein, dass die FMEA, nachdem sie in Vorbereitung und moderierter System-Struktur – und Funktionsanalyse aufgebaut wurde, zum jeweiligen Zeitpunkt zu den anderen Sprint-Ergebnissen passt.

Im Deail:
  • Die Fehleranalyse entspricht dem Projektstand
  • Die Abarbeitung der Maßnahmen entspricht dem Projektstand
  • Änderungen in Struktur, Anforderungen und Funktionen sind eingearbeitet

Die Beurteilung erfolgt im Team und wird in den Retrospektiven berichtet. Der FMEA-Moderator – je nach Position und Integration im Unternehmen – gehört zu den Stakeholdern, ggf. ins Product Owner Team.

Richtigerweise ist der Moderator aber projektübergreifend und autonom unterwegs. Damit obliegt es den FMEA-Ownern aus R&D (S- und D-FMEA), Produktionsplanung (P-FMEA) und/oder Qualitätsvorausplanung (alle), den Status der FMEA als Stakeholder im Auge zu behalten.

Vermeidungs- und Entdeckungsmaßnahmen:

Der Umgang mit neuen Maßnahmen liegt auf der Hand. Sie wandern 1:1 in die agilen Artefakte (Sprint-Backlog, agilean Sprint-Task-Board), wenn sie nicht bereits dort zu finden sind. Idealerweise finden die FMEA-Sitzungen im Projektraum statt oder virtuell mit geöffneten Boards. So werden anders herum noch nicht bekannte Fehlermöglichkeiten und Ursachen einen kurzen Weg in die Analyse finden. Der Master unterstützt den Moderator beim systemischen Abgleich zwischen FMEA-Software und Boards.

Risiko-Bewertung:

RPZ oder neue Matrizen nach AIAG und VDA sind Maßstab für das jeweils verbleibende Risiko. Ziel ist natürlich die Minimierung.

Die agile Analyse und tägliche Verfolgung der Abarbeitung der Maßnahmen wird sich hier niederschlagen. Alle Teammitglieder und Product Owner wären in der Lage, die Zahlen korrekt zu interpretieren und zu begründen.

Sitzungen / Moderation:

Je nach Reife der Agilität im Unternehmen kann eine FMEA-Sitzung agil gestaltet werden. Ist die FMEA ein intrinsisch motivierter Bestandteil der Projekte, kommen auch die richtigen Personen zum Strukturanalyse-„Open Space“ oder zum „Failure-Coffee“ ;-). Den Versuch wäre es wert.

Wie ist Ihr Standpunkt dazu? Welche Rolle spielen nach Ihrer Ansicht Master, Product Owner und Coach?

Haben Sie eine Frage? Möchten Sie mit mir gemeinsam den Ansatz verfeinern, an Ihr Unternehmen anpassen und in der Praxis erproben?

Hinterlassen Sie Ihre Meinung.

Sie möchten die FMEA für Ihr Unternehmen als Tool für die Fehlervermeidung durch frühzeitige und systematische Analyse nutzen? Sie benötigen Unterstützung? Als erfahrener Entwickler mitten aus der Welt der Mechatronik und ausgebildeter FMEA-Moderator stehe ich Ihnen zur Seite.