methodatlas
Session Builder

Meine Session planen

Plane einen konkreten Arbeitsblock mit Agenda, Rollen, Vorbereitung und kopierbarem Ergebnisartefakt.

Methoden-Session2-4 h für initiale RCA, danach Folgesitzungen je nach KomplexitätWorkshop oder asyncProblem Statement

Session: Root Cause Analysis

Der Plan übersetzt die Methode in einen konkreten moderierten Arbeitsblock. Die Eingaben fließen direkt in Session Brief und Arbeitsartefakt.

Automatisch abgeleitet

Methoden-Session mit 3-8. Der Plan nutzt die vorhandene Methodenlogik und das Runsheet.

Runsheet
Beteiligungslogik
Teamrunde, gemeinsames Arbeiten und Alignment

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

Ergebnislogik
Artefakt fertigstellen

Die Session arbeitet direkt auf Problem Statement hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

  1. 1

    Phase 1: Problem präzisieren

    20-30 min

    Symptom konkret beschreiben: was, wann, wo, wie oft, welcher Effekt. Impact quantifizieren (Nutzer, Umsatz, Datenintegrität). Abgrenzung gegen ähnliche Probleme. Hinweis: Wenn Problem-Statement bereits Ursachen enthält („weil X nicht funktionierte“), gehört das in Hypothesen-Phase. Sauberes Symptom ist Basis für nicht-vorgeprägte Suche.

    FacilitatorProblem Statement
  2. 2

    Phase 2: Hypothesen-Fächer

    30-45 min

    Brainstorming möglicher Ursachen entlang relevanter Kategorien (z. B. Code, Konfiguration, Infrastruktur, Daten, Prozess, Mensch). Fishbone oder Mind Map als Strukturierung. Vermutungen und belegbare Ursachen trennen. Hinweis: Wenn nur zwei oder drei Hypothesen auftauchen, ist Suche zu eng. Pro Kategorie mindestens eine Hypothese erzwingen, auch wenn unwahrscheinlich. Confirmation Bias vermeiden.

    FacilitatorUrsachenhypothesen
  3. 3

    Phase 3: Hypothesen prüfen

    45-90 min

    Pro Hypothese Daten suchen: Logs, Metriken, Konfigurationsdiffs, Zeugen. Verifizieren oder Falsifizieren. Verbleibende plausible Hypothesen sind Kandidaten für Root Cause. Hinweis: Wenn pro Hypothese keine Datenquelle benannt werden kann, ist sie spekulativ. Hypothesen-Test ist Kern der Methode. „Plausibel klingen“ ist keine Verifikation.

    FacilitatorBestätigte Ursachen
  4. 4

    Phase 4: Root Cause(s) festlegen

    30-45 min

    Aus verifizierten Hypothesen Root Cause(s) identifizieren. Häufig mehrere Ursachen plus auslösender Faktor. Für jede Ursache prüfen: ist sie steuerbar, ist sie systemisch oder Einzelfall. Hinweis: Ein einziger Root Cause ist verdächtig. Komplexe Systeme haben meist mehrere zusammenwirkende Ursachen. Häufige Endpunkte „menschliches Versagen“ sind kein Root Cause, sondern Indikator für fehlendes Sicherheitsnetz.

    FacilitatorMaßnahmenplan
  5. 5

    Phase 5: Gegenmaßnahmen und Lessons Learned

    30-45 min

    Pro Root Cause Gegenmaßnahme mit Owner und Datum. Trennen: Symptom-Behebung (Hotfix), Wiederholungsverhinderung (strukturell), Detection (Monitoring). Lessons Learned dokumentieren. Hinweis: Wenn alle Gegenmaßnahmen Monitoring oder Schulung sind, fehlt strukturelle Veränderung. Pro Root Cause mindestens eine Maßnahme, die Wiederholung verhindert, nicht nur Sichtbarkeit verbessert.

    OwnerProblem Statement
  6. 6

    Artefakt veröffentlichen

    10 min

    Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.

    OwnerProblem Statement
Nutzbares Artefakt

Session Brief

Für Einladung, Board, Ticket, PR-Beschreibung oder Workshop-Notiz.

session-brief.md

Session Brief: Root Cause Analysis

Ziel

Artefakt: Problem Statement

Arbeitsfrage

Welche systemischen Ursachen haben das Problem verursacht oder ermöglicht, und welche Gegenmaßnahmen verhindern Wiederholung statt nur Symptom-Behandlung?

Kontext

Incident-Timeline; relevante Logs und Metriken; verfügbare Postmortems ähnlicher Vorfälle; Symptom-Beschreibung als 1-2-Sätze-Statement; betroffene Kunden oder Systeme.

Setup

  • Format: Methoden-Session
  • Dauer: 2-4 h für initiale RCA, danach Folgesitzungen je nach Komplexität
  • Modus: Workshop oder async
  • Teilnehmende: Ein Facilitator mit Postmortem-Erfahrung; 4-8 Personen mit direktem Systemkontakt aus Entwicklung, Ops, Support; ein Scribe; bei größeren Incidents zusätzlich ein neutraler Investigator.
  • Owner: Ein Facilitator mit Postmortem-Erfahrung
  • 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 Problem Statement hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

Input

Whiteboard oder digitales Board mit RCA-Vorlage (Problem, Symptome, Hypothesen, Daten, Ursachen, Maßnahmen); Logs, Metriken, Konfigurationsstände; Postmortem-Vorlage; Methodenwerkzeuge wie 5 Whys, Fishbone, Fault Tree zur Auswahl.

Vorbereitung

Symptom oben am Board als ein Satz. Verfügbare Methoden auflisten (5 Whys für lineare Kausalität, Fishbone für breite Hypothesenfächerung, Fault Tree für sicherheitskritische Systeme). Postmortem-Vorlage mit Sektionen Problem, Impact, Timeline, Root Cause, Gegenmaßnahmen, Lessons Learned.

Agenda

  1. Phase 1: Problem präzisieren (20-30 min) Owner: Facilitator Aktion: Symptom konkret beschreiben: was, wann, wo, wie oft, welcher Effekt. Impact quantifizieren (Nutzer, Umsatz, Datenintegrität). Abgrenzung gegen ähnliche Probleme. Hinweis: Wenn Problem-Statement bereits Ursachen enthält („weil X nicht funktionierte“), gehört das in Hypothesen-Phase. Sauberes Symptom ist Basis für nicht-vorgeprägte Suche. Output: Problem Statement

  2. Phase 2: Hypothesen-Fächer (30-45 min) Owner: Facilitator Aktion: Brainstorming möglicher Ursachen entlang relevanter Kategorien (z. B. Code, Konfiguration, Infrastruktur, Daten, Prozess, Mensch). Fishbone oder Mind Map als Strukturierung. Vermutungen und belegbare Ursachen trennen. Hinweis: Wenn nur zwei oder drei Hypothesen auftauchen, ist Suche zu eng. Pro Kategorie mindestens eine Hypothese erzwingen, auch wenn unwahrscheinlich. Confirmation Bias vermeiden. Output: Ursachenhypothesen

  3. Phase 3: Hypothesen prüfen (45-90 min) Owner: Facilitator Aktion: Pro Hypothese Daten suchen: Logs, Metriken, Konfigurationsdiffs, Zeugen. Verifizieren oder Falsifizieren. Verbleibende plausible Hypothesen sind Kandidaten für Root Cause. Hinweis: Wenn pro Hypothese keine Datenquelle benannt werden kann, ist sie spekulativ. Hypothesen-Test ist Kern der Methode. „Plausibel klingen“ ist keine Verifikation. Output: Bestätigte Ursachen

  4. Phase 4: Root Cause(s) festlegen (30-45 min) Owner: Facilitator Aktion: Aus verifizierten Hypothesen Root Cause(s) identifizieren. Häufig mehrere Ursachen plus auslösender Faktor. Für jede Ursache prüfen: ist sie steuerbar, ist sie systemisch oder Einzelfall. Hinweis: Ein einziger Root Cause ist verdächtig. Komplexe Systeme haben meist mehrere zusammenwirkende Ursachen. Häufige Endpunkte „menschliches Versagen“ sind kein Root Cause, sondern Indikator für fehlendes Sicherheitsnetz. Output: Maßnahmenplan

  5. Phase 5: Gegenmaßnahmen und Lessons Learned (30-45 min) Owner: Owner Aktion: Pro Root Cause Gegenmaßnahme mit Owner und Datum. Trennen: Symptom-Behebung (Hotfix), Wiederholungsverhinderung (strukturell), Detection (Monitoring). Lessons Learned dokumentieren. Hinweis: Wenn alle Gegenmaßnahmen Monitoring oder Schulung sind, fehlt strukturelle Veränderung. Pro Root Cause mindestens eine Maßnahme, die Wiederholung verhindert, nicht nur Sichtbarkeit verbessert. Output: Problem Statement

  6. 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: Problem Statement

Abschluss

  • Ergebnisartefakt aktualisieren: Problem Statement
  • Ablageort, Version und Review-Empfänger festlegen.
  • Owner, nächster Schritt und Reviewtermin festlegen.
Nutzbares Artefakt

Arbeitsartefakt

Vorgefüllter Startpunkt auf Basis der passenden Vorlage.

arbeitsartefakt.md

Problem Statement: Root Cause Analysis

Arbeitsfrage

Welche systemischen Ursachen haben das Problem verursacht oder ermöglicht, und welche Gegenmaßnahmen verhindern Wiederholung statt nur Symptom-Behandlung?

Kontext

Incident-Timeline; relevante Logs und Metriken; verfügbare Postmortems ähnlicher Vorfälle; Symptom-Beschreibung als 1-2-Sätze-Statement; betroffene Kunden oder Systeme.

Beteiligte

  • Owner: Ein Facilitator mit Postmortem-Erfahrung
  • Teilnehmende: Ein Facilitator mit Postmortem-Erfahrung; 4-8 Personen mit direktem Systemkontakt aus Entwicklung, Ops, Support; ein Scribe; bei größeren Incidents zusätzlich ein neutraler Investigator.

Input

Whiteboard oder digitales Board mit RCA-Vorlage (Problem, Symptome, Hypothesen, Daten, Ursachen, Maßnahmen); Logs, Metriken, Konfigurationsstände; Postmortem-Vorlage; Methodenwerkzeuge wie 5 Whys, Fishbone, Fault Tree zur Auswahl.

Vorlage

Root Cause Analysis Arbeitsvorlage

Ziel

Strukturierte Analyse, um hinter Symptomen die wirksamen Ursachen eines Problems zu finden.

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

  • Problem Statement:
  • Ursachenhypothesen:
  • Bestätigte Ursachen:
  • Maßnahmenplan:

Annahmen und offene Fragen

  • ...

Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Fertigstellungscheck

  • Problem Statement 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
Vorlagenbasis

Root Cause Analysis Arbeitsvorlage

Vorlage ansehenKompakte Arbeitsvorlage für Root Cause Analysis mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
markdown

root-cause-analysis-working-template.md

Kompakte Arbeitsvorlage für Root Cause Analysis mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

Root Cause Analysis Arbeitsvorlage

Ziel

Strukturierte Analyse, um hinter Symptomen die wirksamen Ursachen eines Problems zu finden.

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

  • Problem Statement:
  • Ursachenhypothesen:
  • Bestätigte Ursachen:
  • Maßnahmenplan:

Annahmen und offene Fragen

  • ...

Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu Problem Statement.
  • Datum, Incident-ID, Autor und Decider im Header. Spätere Erkenntnisse als Update-Sektion am Ende anhängen, nicht überschreiben. Wenn Root Cause sich später als falsch erweist, Status auf `revised`, ursprüngliche Analyse erhalten.
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.
SteckbriefRunsheet