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.
Wir überlegen in der Firma auch einen FMEA Moderator zu engagieren. Ein guter Punkt ist, dass das Unternehmen nur profitieren kann, da es die unternehmensweite Kommunikation und die Interaktion mit Kunden und Lieferanten fördert. Das sage ich meinem Vorgesetzten.
Viele Buzzwords, das Problem besteht meiner Meinung jedoch darin, daß auch in „in hybriden, durchaus auch komplizierten Produkten und Organisationen mit nicht zu schnelllebigen Zyklen und hochfrequenten Beta-Releases“ die starre, 25 Jahre alte Funktions- und Fehlernetz-Vorgehensweise gnadenlos zum Scheitern verurteilt ist. Sie gilt aber als heilige Kuh, die niemals geschlachtet werden darf.
Funktions- und Fehlernetze werden deduktiv ‚top down‘) aufgebaut, somit sind Endfolgen-Szenarien bereits abgesteckt und überraschende Erkenntnisse systemimmanent ausgeschlossen. Es werden nur externe Funktionen untereinander verknüpft und nicht in Haupt-, Neben- und Unterstützungsfunktionen auseinanderdifferenziert.
Um nur zwei aus Dutzenden von Schwachpunkten zu benennen.
[Träumen ein]
Was nötig wäre, ist eine Befreiung aus diesen überkommenen Denkmustern, ein mutiges ‚think out of the box‘. Multifaktorielle Fehlerbilder können nicht durch primitive Pfeildiagramme – die sich zudem lediglich auf unterbrochene Sollfunktionsketten beziehen, anstatt auf Gefahrenszenarien – herausgearbeitet werden. Hier ist ein Paradigmenwechsel zu flexibleren Ansätzen erforderlich.
[Träumen aus]
Ein ‚agiles‘ System, welches auf dem morbiden VDA 96er Lobby-Modell basiert, erinnert mich an einen venezianischen Villen-Neubau, der auf faulenden Holzpfählen errichtet wird.
„Damit hat das Unternehmen aber freie Hand, die offiziellen Regeln zu modifizieren. Agile heißt eben hier auch flexibel und adaptiv.“ ….. Team-Entscheidung. Und die gilt. ….. „Auch die 7 Schritte sind für mich nicht bindend“.
—->
Auszug aus (dem für Audits verpflichtenden) FMEA-Lieferantenleitfaden eines (namentlich hier nicht genannten) OEM :
„The DFMEA is performed in seven steps.“ …..
„The analysis object shall be processed using a software tool. The software tool shall realize
more than three structure levels, function networks and failure networks.“
„[OEM] may access the status of the DFMEA and the accompanying documents at the supplier’s location at any time ….. For each failure mode of a structure element, the failure chain with failure mode, failure cause and failure effect shall be created and logically linked in hierarchical failure networks ……“
„The severity of the failure effect shall be agreed between [OEM] and the supplier, whereby the initial severity evaluation is specified by [OEM]. This also applies to sub-suppliers of all TIER levels …..“
usw. usf.
Große Freiheiten erkenne ich hier nicht. Vielmehr wird der Zulieferer dazu vergattert,
– die 7 Schritte streng einzuhalten
– Funktions- und Fehlernetze in jedem Falle anzuwenden (obwohl lt. VDA/AIAG 2019 alternativ
auch P-Diagramm + Funktionsanalyse-Arbeitsblatt erlaubt ist …)
– Ursachenelemente zu definieren
– Bewertungsvorgaben des OEM zu übernehmen und an eigene LF weiterzureichen (spez. BPZ)
– eine ‚Compliant Software‘ einzusetzen, die dies alles unterstützt und dem OEM genehm ist
Nicht zuletzt aus diesem Lobby-Druck heraus läßt sich der ‚Siegeszug‘ der fragwürdigen VDA 96 ‚reloaded‘ erklären.
Das Fehlernetz ist ein angenehmes Instrument im Rahmen eines ‚Verschiebebahnhofes‘ Fehlerverantwortungen von oben nach unten ‚durchzureichen‘, bis zum TIER xy auf der untersten Stufe. Warum Fehler im eigenen Baugruppen-Konzept (=interne Funktionen) suchen, wenn man über’s Netz bequemerweise das Einzelteil des Lieferanten verantwortlich machen kann?
Kürzlich bejahte mir ein FMEA-Koordinator von Siemens Energy die Frage, ob eine Baugruppe fehlerfrei funktionieren würde, falls alle Einzelteile 100% i.O. wären …..
Selbst moderiert habe ich übrigens nur in meiner ‚Anfangsphase‘, in letzter Zeit eher selten.
„Wenn der OEM gern eine „regelkonforme“ pseudo-FMEA erzwingen möchte, bekommt er eine.“
—> Mit Sympathie nehme ich zur Kenntnis, daß Sie die streng AIAG/VDA-konforme FMEA für nicht „tatsächlich wirksam“ halten ….. 😉
„Ich rate dem Lieferanten dann, sich Gedanken zu machen, ob eine tatsächlich wirksame, agilere, parallel dazu gebaut werden sollte.“
—>
Unrealistisch. Welches Zuliefer-KMU hat dafür die personellen und zeitlichen Ressourcen? Da kommt doch sofort die Replik: „Doppelarbeit mit 2-fach erstellten FMEAs können wir uns nicht leisten. Wir machen’s jetzt so, wie’s der Kunde verlangt, dann bekommen wir keine Scherereien …“
„….. eigentliche Hauptfunktion als Prio 1 einigen. Oder die wichtigsten Sicherheitsfunktionen.“
—>
Finde ich sehr gut. Leider fehlt diese Kategorisierung/Priorisierung in der AIAG/VDA 2019. Nicht zu vergessen ist darüberhinaus das häufig stiefmütterlich behandelte Feld der Anforderungen/Requirements, die auch nicht-funktionaler Natur sein können (Baugröße, Gewicht etc.).
„Das Netz entsteht durch die Software quasi automatisch.“
—>
Gerade eben die starren, monolithischen Funktions- und Fehlernetze behindern kreatives Denken und sind ein sperriges Konstrukt für Variantenfertiger …
„… die entscheidenden Ursachen zu finden. Nicht alle im kleinsten Detail. Da, wo der Schuh am meisten drückt, wird zuerst optimiert …“
—>
D’accord. Allerdings führen Netze aufgrund ihrer systemimmanenten Bewertungsinkonsistenzen (z.B. Pauschalisierung von Endfolgen-BPZ für zahlreiche Unteräste) häufig zu falschen Schlußfolgerungen, auch hinsichtlich der Ursachen-Priorisierung. Das Funktionsnetz verleitet außerdem dazu, im darauf aufsetzenden Fehlerbereich nur in der Dimension unterbrochener Sollfunktionsketten zu denken.
„Anpassungsbedarf… Agiles Manifest der Qualität … Die FMEA wird das auch tun müssen oder sie verschwindet.“
—>
Ihr Wort in Gottes Ohr. Gerade waren wir alle Zeuge, wie die USA (AIAG) am deutschen FMEA-Wesen genesen durften (FMEA Papst Richard Harpster: „It was an adoption and not a harmonization“). Vllt. bin ich ja zu sehr Pessimist, aber: dank Lobby-Arbeit „interessierter Kreise“ avanciert das Zwangskorsett der VDA 96 „reloaded“ inzw. zum Exportschlager, bis nach Indien und China.
Ich bin aber sofort Ihr Weggefährte, wenn’s um das Einreißen von Denkmauern und Abschaffung „veralteter Regeln“ geht.