Six Sigma DMAIC-Ursachenanalyse
Kurzbeschreibung
Das Six Sigma DMAIC-Ursachenanalyse-Template ist ein strukturiertes, fünfphasiges Problemlösungs-Framework, das von links nach rechts über fünf Spalten angeordnet ist: Definieren, Messen, Analysieren, Verbessern und Kontrollieren. Jede Phase enthält oben Leitfragen und darunter einen eigenen Arbeitsbereich zum Festhalten von Erkenntnissen. Das Template schreibt eine datengesteuerte Reihenfolge vor—wechsel nicht zu „Verbessern“, bevor „Analysieren“ mit Daten verifiziert wurde.
Für wen ist es geeignet
Qualitätsingenieure, Teams für Prozessverbesserung, Produkt- und Entwicklungsteams, Operations-Manager und Six-Sigma-Praktiker (Green Belt/Black Belt). Anwendbar in der Fertigung, der Softwareentwicklung, im Gesundheitswesen, im Finanzwesen und in jeder Branche, die darauf abzielt, Fehler oder Prozessabweichungen zu reduzieren.
Anleitung
Von links nach rechts durch die fünf Phasen vorgehen:
Define – Problem beschreiben, Kunden identifizieren, Ziel und Umfang festlegen.
Measure – Basiskennzahl 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 – Maßnahmen entwickeln, die auf verifizierte Ursachen abzielen; vor der vollständigen Umsetzung pilotieren.
Control – Lösung standardisieren, Ergebnisse überwachen und einen Reaktionsplan festlegen, um die Verbesserung zu sichern.
Beispiel
Ein Produktteam, das Softwarefehler, die in die Produktion gelangen, angeht:
Define: Zu viele Defekte erreichen die Endnutzer; Ziel ist, die in Produktion gelangten Defekte bis Ende Q4 um 50% zu reduzieren; Umfang ist das Checkout- und Payments-Squad.
Measure: Ausgangswert: 14 in Produktion gelangte Defekte pro Monat (Mai–Jul); 60 % lassen sich dem Checkout‑Modul zuordnen; Support verbringt etwa 90 Stunden/Monat mit Fehler-Tickets.
Analyze: 5 Whys bei den Top‑10-Defekten zeigten, dass keine automatisierte Regression-Suite vorhanden war und Pre‑Release-Reviews gehetzt wurden; 8 von 10 Defekten hätten durch Regressionstests entdeckt werden können.
Improve: Eine automatisierte Regression-Suite mit 120 Tests erstellt; eine PR-Review-Checkliste sowie ein 24‑stündiges Release‑Freeze hinzugefügt; Pilot mit dem Checkout‑Squad im September.
Control: Wöchentliches Defect-Dashboard; Alarmgrenze bei 5 in Produktion gelangten Defekten pro Monat festgelegt; Regression-Suite ab Oktober in der CI für alle Squads verpflichtend. Ergebnis: Nach dem Pilot sanken die in Produktion gelangten Defekte von 14 auf 6 pro Monat.
Prost!
Khawaja Rizwan
