Session Brief: 5 Whys

Ziel

Artefakt: Root Cause Notes

Arbeitsfrage

Welche steuerbare Ursache hinter dem Symptom kann das Team mit einer konkreten Gegenmaßnahme beheben?

Kontext

Konkretes Problem als ein Satz mit Datum und Auswirkung; Incident-ID oder Ticket-Link; relevante Logs oder Graphen der letzten 24 Stunden; bekannte Workarounds.

Setup

• Format: Methoden-Session
• Dauer: 15-30 min
• Modus: Workshop
• Teilnehmende: Ein Facilitator, der die Kette führt und neutral nachfragt; zwei bis fünf Personen mit direktem Systemkontakt (mindestens ein Engineer, ein Operator); ein Scribe, der jede Antwort wörtlich mitschreibt.
• Owner: Ein Facilitator, der die Kette führt und neutral nachfragt
• Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
• Ergebnislogik: Artefakt fertigstellen

Beteiligungslogik

Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

Ergebnislogik

Die Session arbeitet direkt auf Root Cause Notes hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

Input

Whiteboard oder Miro-Board mit vertikaler Kette aus sechs Boxen (Problem + 5 Whys); Stift; Timer; Link zum auslösenden Ticket oder Incident-Report.

Vorbereitung

Problem-Satz oben in die erste Box schreiben. Fünf leere Boxen vertikal darunter. Timer auf 20 min. Regel ansagen: keine Namen, nur Mechanismen. Antwort jeder Box wird Ausgangspunkt der nächsten Why-Frage.

Agenda

1. 0-2 min (2 min) Owner: Facilitator Aktion: Problem als beobachtbares Symptom formulieren: was, wann, wie oft, welcher Effekt. Keine Vermutung über Ursache. Hinweis: Wenn der Satz schon eine Ursache enthält („weil X kaputt war“), neu schreiben. Sonst springt die Kette zu spät ein. Output: Root Cause Notes

2. 2-15 min (13 min) Owner: Facilitator Aktion: Why-Kette aufbauen: Pro Box eine Why-Frage, eine Antwort, durchgängig auf Mechanismen statt Personen. Nach jedem Why prüfen, ob die Antwort durch Logs oder Daten belegbar ist. Hinweis: Spätestens beim dritten Why sollte die Antwort technischer oder prozesshafter werden. Bleibt sie auf der Verhaltensebene, fehlt Datenzugang oder Systemkenntnis. Output: Gegenmaßnahmen

3. 15-22 min (7 min) Owner: Facilitator Aktion: Stoppkriterium prüfen: Ist die unterste Antwort durch das Team selbst änderbar? Wenn nein, einen Why zurückgehen oder den Pfad verzweigen. Hinweis: Häufig endet eine Kette zu früh bei „der Service ist alt“. Das ist keine steuerbare Ursache; entweder weiter oder zweite Kette parallel. Output: Root Cause Notes

4. 22-30 min (8 min) Owner: Owner Aktion: Eine bis drei konkrete Gegenmaßnahmen notieren, je mit Owner und Zieldatum. Gegenmaßnahme muss die identifizierte Ursache adressieren, nicht das Symptom. Hinweis: Wenn die Gegenmaßnahme „Monitoring verbessern“ lautet, ist es eine Detection-Maßnahme, keine Ursachenbehebung. Beides notieren, klar trennen. Output: Gegenmaßnahmen

5. Artefakt veröffentlichen (10 min) Owner: Owner Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen. Output: Root Cause Notes

Abschluss

• Ergebnisartefakt aktualisieren: Root Cause Notes
• Ablageort, Version und Review-Empfänger festlegen.
• Owner, nächster Schritt und Reviewtermin festlegen.

Root Cause Notes: 5 Whys

Arbeitsfrage

Welche steuerbare Ursache hinter dem Symptom kann das Team mit einer konkreten Gegenmaßnahme beheben?

Kontext

Konkretes Problem als ein Satz mit Datum und Auswirkung; Incident-ID oder Ticket-Link; relevante Logs oder Graphen der letzten 24 Stunden; bekannte Workarounds.

Beteiligte

• Owner: Ein Facilitator, der die Kette führt und neutral nachfragt
• Teilnehmende: Ein Facilitator, der die Kette führt und neutral nachfragt; zwei bis fünf Personen mit direktem Systemkontakt (mindestens ein Engineer, ein Operator); ein Scribe, der jede Antwort wörtlich mitschreibt.

Input

Whiteboard oder Miro-Board mit vertikaler Kette aus sechs Boxen (Problem + 5 Whys); Stift; Timer; Link zum auslösenden Ticket oder Incident-Report.

Vorlage

5 Whys Arbeitsvorlage

Ziel

Einfache Technik, um von Symptomen zu tieferliegenden Ursachen vorzudringen.

Kontext

Wann und wofür nutzen wir diese Methode?

Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

Durchführung

Kurze Notizen entlang des Runsheets.

Ergebnisartefakte

• Root Cause Notes:
• Gegenmaßnahmen:

Annahmen und offene Fragen

• ...

Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Fertigstellungscheck

• Root Cause Notes ist vollständig genug für Review:
• Ablageort:
• Version / Status:
• Review durch:
• Nächster Schritt:

Nächster Schritt

• Ergebnis prüfen
• offene Fragen markieren
• Review oder Entscheidung terminieren