FMEA / Agile – Konflikt

Manifest der Agilität im Qualitätsmanagement

Der wesentlichste Gedanke hinter allen „agile“ Aktivitäten liegt darin, durch Entschärfung der Komplexität in Prozessen und Produkten die Effektivität und Effizienz zu verbessern. Die Ideen und Werte, die daraus zuerst im Bereich Software-Entwicklung entstanden sind, möchte ich hier nicht wiederholen. Dazu gibt es eine Menge Abhandlungen im Web. Die starren Regularien der FMEA-Erstellung führen aber oft zur strikten Ablehnung selbiger.


Da wir uns im Bereich des Qualitätsmanagements befinden, hier noch einmal der Link zum  Agilen Manifest der Qualitätssicherung.


Ablehnung von FMEA im Agilen Umfeld


Ein wesentlicher Punkt, der zur Ablehnung der FMEA durch Agile Teams und Organisationen führen kann, ist der strikt prozessorientierte Ansatz. „Agile“ Prozesse sind jedoch immer evolutionär und iterativ. Bespiele hierfür sind die Frameworks Scrum und agilean. Traditionell wird ein anfangs spezifiziertes Produkt in einem kontinuierlichen Prozess umgesetzt. Änderungen sind eher störend und führen zu Verzögerungen und schlimmstenfalls halbherziger Umsetzung, was wiederum Risiken für die Qualität nach sich zieht.


Dagegen steht der iterative Ansatz (blau):

Darstellung des PDP bzw. klassischen Ansatzes vs. iterativ ala Agile
Klassisch vs Agile

Statt in quasi einem Zug ein vermeintlich konformes Produkt zu entwickeln, werden in jedem Loop Zwischenziele gesetzt und überprüft. Im klassischen Projektmanagement kann es passieren, dass man Überraschungen erst am Ende erlebt, weil man Erwartungen oder bestimmte Ziele nicht erfüllt hat.
Der iterative, evolutionäre Ansatz ist änderungswillig und in ständiger Verbesserung. Dies ist jedoch keine Abhandlung über „Agilität“. Das Netz ist auch voll davon. Eine Basis-Schulung bei agilean, speziell für Mechatroniker, möchte ich jedoch empfehlen.


FMEA evolutionär und iterativ?


Die VDA/AIAG – Harmonisierung hat uns leider den Wasserfall-Prozess noch tiefer in Stein gemeißelt. Es sind keine Schleifen vorgesehen. Erfahrungsgemäß wird die Umsetzung der Maßnahmen mit Neubewertung und ggf. neuen Maßnahmen weitergeführt.Ein erster Schritt wäre, die Schritte 6 und 7 als komplette Loops durchzuführen und mit den „Sprints“ zu synchronisieren:

Einbindung der Optimierung in Agile Schleifen - FMEA nach Handbuch VDA/AIAG 2019 mit iterativer Optimierung
FMEA nach Handbuch VDA/AIAG 2019 mit iterativer Optimierung

FMEA und Änderungen


Doch wie geht die FMEA mit Änderungen um, die in agilen Projekten häufig, ja sogar gewünscht sind?In permanenter Kommunikation mit dem Kunden, Dailies, zyklischen Retrospektiven kommen Anpassungen in Struktur und Funktionen. Eine vollständige Überprüfung in der FMEA dauert zu lange und stellt für agile Projekte eher ein Risiko dar.


Mögliches Vorgehen


Templates / Basis- und Mutter-FMEAs


Mit Hilfe von vorbereiteten Templates oder durch die Nutzung von Mutter-FMEAs ist ein kompletter Durchlauf aller Schritte 1 bis 7 in ein bis zwei Sprints machbar. Optimierung (6+7) erfolgt in jedem Sprint. Die Maßnahmenverfolgung erfolgt operativ am Scrum-Board. Änderungen treten in der Regel nur an Hauptfunktionen auf.

Gesetzliche und Sicherheits-Funktionen und -Anforderungen zum Beispiel werden sich selten ändern. Darum wird ein Prozess definiert, der nur für die Änderung oder nur für die geänderte Funktion die Schritte 2-7 oder 3-7 durchläuft. Reduziert auf Hauptfunktionen


Setze die FMEA nur da ein, wo sie dem größten Nutzen erzeugt!

Im Scoping zu Beginn des Prozesses werden bereits die Funktionen festgelegt, für die eine FMEA durchgeführt wird. Sind zum Beispiel bewährte Regeln und Vorschriften für die Umsetzung von Funktionen vorhanden, können diese ausgeklammert werden. Für Änderungen wird ein Prozess benötigt wie oben.


Einsatz von Alternativen


Eine Alternative ist z.B. DRBFM – Design Review Based on Failure Mode. Es werden die größten, schwersten bzw. wahrscheinlichsten Risiken betrachtet. Die Analyse fokussiert auf die Strukturen und Funktonen, die sich gegenüber dem Vorhergehenden oder Marktüblichen unterscheiden. Auch hierzu sollte ein Prozess für den Umgang mit entwicklungsbegleitenden Änderungen passend zum agilen Umfeld und dem eingesetzten Framework entwickelt werden.