5 Whys – Ursachenanalyse
Kurz
Die 5 Whys – Ursachenanalyse ist eine strukturierte Problemlösungstechnik, bei der du mit einer Problembeschreibung beginnst und hintereinander fünfmal „Warum?“ fragst. Jede Antwort wird zur Grundlage der nächsten Frage. Ziel ist es, über die Symptome hinauszugehen und die zugrunde liegende Prozess- oder Systemstörung aufzudecken, die du tatsächlich beheben kannst.
Wer kann sie nutzen
Produkt- und Ingenieurteams
Operations- und DevOps-Teams
Kundensupport- und Serviceteams
Projektmanager
Teams der Qualitätssicherung
Alle, die wiederkehrende Probleme oder Vorfälle untersuchen
Anleitung
Formuliere eine klare Problembeschreibung — was passiert ist, wann und welche Auswirkungen es hatte.
Stelle die Frage "Warum ist das passiert?" und notiere die Antwort (Antwort 1).
Stelle die Frage "Warum ist Antwort 1 passiert?" und notiere die Antwort (Antwort 2).
Wiederhole dies für Antworten 3, 4 und 5.
Hör auf, wenn du eine Ursache findest, die du durch eine Prozess- oder Systemänderung beheben kannst — das ist deine Grundursache.
Definiere Korrekturmaßnahmen: weise jeder Maßnahme einen Eigentümer und ein Fälligkeitsdatum zu.
Tipp: Eine gute Grundursache deutet auf einen Prozess oder ein System hin, nicht auf eine Person. Wenn deine Antwort ein Name ist, frage noch einmal, warum.
Beispiel
Problembeschreibung: Die Checkout-Seite war am 12. Aug. für 3 Stunden ausgefallen — ca. 18.000 $ an verlorenen Bestellungen und mehr als 40 Support-Tickets. (Am 13. Aug. vom Plattformteam untersucht.)
Warum 1: Der Zahlungsserver hatte keinen freien Arbeitsspeicher mehr und stürzte ab.
Warum 2: Der Zahlungsdienst hat ein Speicherleck.
Warum 3: Das Release vom 8. Aug. schließt alte Datenbankverbindungen nicht.
Warum 4: Das Release wurde vor dem Livegang nie lastgetestet.
Warum 5: Die Release-Checkliste enthält keinen Schritt für Last-/Performance-Tests.
Grundursache: Im Release-Prozess fehlt ein verpflichtender Schritt für Last-/Performance-Tests.
Korrekturmaßnahmen:
Automatisierten Lasttest in die CI-Pipeline integrieren (DevOps-Lead, 30. Aug.)
Speicheralarme bei 80% Auslastung setzen (SRE-Team, 22. Aug.)
Release-Checkliste aktualisieren und Team schulen (Engineering-Manager, 20. Aug.)
Viele Grüße!
Khawaja Rizwan
