Six Sigma DMAIC Ursachenanalyse
Kurzbeschreibung
Das Six Sigma DMAIC Ursachenanalyse-Template ist ein strukturiertes, fünfphasiges Problemlösungs-Framework, das von links nach rechts in fünf Spalten angeordnet ist: Definieren, Messen, Analysieren, Verbessern und Steuern. Jede Phase enthält oben Leitfragen und darunter einen eigenen Arbeitsbereich zur Dokumentation der Erkenntnisse. Das Template erzwingt eine datengestützte Reihenfolge – Nutzer dürfen nicht zur Phase „Verbessern“ springen, bevor die Ergebnisse aus „Analysieren" durch Daten verifiziert wurden.
Wer kann es nutzen
Qualitätsingenieure, Teams für Prozessverbesserung, Produkt- und Engineering-Teams, Operations-Manager und Six-Sigma-Praktiker (Green Belt/Black Belt). Anwendbar in der Fertigung, Softwareentwicklung, im Gesundheitswesen, im Finanzwesen und in allen Branchen, die darauf abzielen, Fehler oder Prozessabweichungen zu reduzieren.
Anleitung
Von links nach rechts durch die fünf Phasen vorgehen:
Define – Problem formulieren, den Kunden identifizieren sowie Ziel und Umfang festlegen.
Measure – Eine Ausgangskennzahl festlegen und aktuelle Leistungsdaten erfassen.
Analyze – Ursachen mit 5-Whys oder einem Ishikawa Diagramm identifizieren; Ursachen mit Daten verifizieren. (Ein 5-Whys- oder Ishikawa-Rahmen kann an diese Phase angehängt werden.)
Improve – Lösungen entwickeln, die die verifizierten Ursachen adressieren; vor der vollständigen Einführung pilotieren.
Control – Die Lösung standardisieren, Ergebnisse überwachen und einen Maßnahmenplan definieren, um den Erfolg zu sichern.
Beispiel
Ein Produktteam, das sich mit Softwarefehlern beschäftigt, die in die Produktion gelangen:
Define: Zu viele Fehler erreichen die Endnutzer; Ziel ist, die Anzahl entwichener Fehler bis Ende von Q4 um 50 % zu reduzieren; Umfang ist das Checkout- und Payments-Squad.
Measure: Ausgangswert: 14 entwichene Fehler pro Monat (Mai–Juli); 60 % lassen sich dem Checkout-Modul zuordnen; der Support verbringt etwa 90 Stunden/Monat mit Fehler-Tickets.
Analyze: Eine 5-Whys-Analyse der Top‑10-Fehler ergab, dass keine automatisierte Regressionstest-Suite vorhanden war und Pre-Release-Reviews überstürzt wurden; 8 von 10 Fehlern hätten durch Regressionstests erkannt werden können.
Improve: Es wurde eine automatisierte Regressionstest-Suite mit 120 Tests aufgebaut; eine PR-Review-Checkliste und eine 24-stündige Release-Freeze eingeführt; der Pilot mit dem Checkout-Squad lief im September.
Control: Wöchentliches Fehler-Dashboard; Schwellenwert für Alarme bei 5 entwichenen Fehlern/Monat; Regressionstest-Suite ab Oktober verpflichtend in der CI für alle Squads. Ergebnis: Nach dem Pilot sanken die entwichenen Fehler von 14 auf 6 pro Monat.
Prost!
Khawaja Rizwan
