Run SheetOperationsUrsachenanalyse

Causal Factor Analysis

KomplexitätHigh

Zeit2-6 h

Teilnehmende3-10

FormatBoth

MaturityEstablished

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenIncident Timeline Analysis

Eine chronologische Rekonstruktion des Ereignisses mit Akteuren, Entscheidungen, Signalen und Reaktionen liegt vor.

Ohne: Ohne Timeline fehlt die Faktenbasis, beitragende Faktoren werden Vermutung.

Vorher abschließenBlameless Postmortem

Eine Kultur der schuldfreien Aufarbeitung ist etabliert, sodass beitragende Faktoren ehrlich benannt werden.

Ohne: Ohne diese Norm kippt Causal Factor Analysis in Schuldzuweisung, beitragende Faktoren werden zurückgehalten.

Vorbereitung

Was vor Start vorliegen muss

Materialien

Whiteboard oder digitales Board für Events-and-Conditions-Chart; Timeline-Vorlage; Symbol-Set für Ereignisse (Rechtecke) und Bedingungen (Ovale); Pfeile für Kausalbeziehungen; Logs, Interviews, Materialien als Quellen; Vorlage für Causal Factors und Root Causes.

Personen / Rollen

Ein erfahrener Investigator als Lead; 3-6 Personen mit System- und Prozesskontext; ein Scribe; bei sicherheitskritischen oder behördlich relevanten Vorfällen ein unabhängiger Reviewer.

Vorabinfos

Timeline mit Zeitstempeln; Liste betroffener Akteure; relevante Dokumente (Logs, Protokolle, Schichtpläne); Vorfall-Beschreibung mit Konsequenzen; bekannte Vorgängervorfälle.

Zeitbedarf

Initial 4-6 h, danach iterative Erweiterung mit zusätzlichen Quellen

Setup

Timeline horizontal als Rückgrat. Ereignisse als Rechtecke entlang der Zeitachse. Bedingungen (zustandsartige Faktoren wie „Personalengpass“) als Ovale oberhalb. Kausalpfeile zwischen Ereignissen und Bedingungen. Sektion Causal Factors separat. Symbolik als Plakat sichtbar.

Kernfrage

Die eine Frage, die diese Methode beantwortet

Welche Ereignisse und Bedingungen haben zum Vorfall beigetragen, welche dieser Faktoren sind kausal verbunden, und welche Root Causes liegen den beitragenden Faktoren zugrunde?

Ablauf

Marker: Phase

Schritt	Dauer	Aktion	Hinweis
1Phase 1: Ereigniskette aufbauen	60-90 min	Ereignisse chronologisch auf Timeline. Jedes Ereignis: was, wann, wer, welche Quelle. Lücken in der Kette markieren. Kausalpfeile zwischen Ereignissen ziehen, wo direkter Bezug besteht.	Ereignisse müssen beobachtbare Zustandsänderungen sein, keine Interpretationen. „Operator war müde“ ist Bedingung, „Operator deaktivierte Alarm um 03:12“ ist Ereignis.
2Phase 2: Bedingungen hinzufügen	45-60 min	Bedingungen (zustandsartige Faktoren) oberhalb der Timeline platzieren: Personalbesetzung, Schichtende, Wartungslücken, externe Umgebung, regulatorische Vorgaben. Mit Ereignissen verknüpfen, die durch die Bedingung beeinflusst wurden.	Bedingungen sind nicht weniger wichtig als Ereignisse. Häufiger Fehler: nur Ereignisse erfassen, Bedingungen ergeben aber das Erklärungsmuster, nicht die Reihenfolge allein.
3Phase 3: Causal Factors identifizieren	45-60 min	Pro Ereignis und Bedingung prüfen: wäre der Vorfall ausgeblieben oder weniger schwer gewesen, wenn dieser Faktor anders gewesen wäre. Wenn ja, Faktor als Causal Factor markieren. Beitragende Faktoren von zufälligen trennen.	Causal Factor ist nicht gleich Root Cause. Causal Factor sagt: dieser Punkt hat beigetragen. Root Cause sagt: dieser Punkt war Ursache und steuerbar. Trennung wichtig für Maßnahmen.
4Phase 4: Root Causes ableiten	45-60 min	Pro Causal Factor weiterfragen (z. B. mit 5 Whys): warum war dieser Faktor so. Root Causes sind systemisch und steuerbar. Mehrere Root Causes pro Vorfall sind normal.	Wenn Root Cause „Mensch versagte“ ist, fehlt eine Ebene. Frage: welches Sicherheitsnetz war nicht da, das Versagen aufgefangen hätte. Systemische Ursache liegt im Sicherheitsnetz, nicht im Versagen.
5Phase 5: Maßnahmen und Bericht	45-60 min	Pro Root Cause Maßnahme(n) mit Owner und Datum. Strukturelle Veränderungen, nicht nur Schulung. Bericht mit Timeline-Diagramm, Causal Factor List, Root Cause List, Maßnahmen-Tabelle.	Bei regulierten Vorfällen Bericht in Standardform (z. B. ICAO, NTSB, GMP). Bei nicht-regulierten Vorfällen Postmortem-Vorlage. Maßnahmen nachverfolgbar in Ticket-System.

Artefakt

Was am Ende rauskommt

Form

Events-and-Conditions-Chart als zentrales Diagramm, Causal Factor List mit Begründung pro Faktor, Root Cause List mit Verbindung zu Causal Factors, Maßnahmen-Tabelle mit Owner und Datum, Bericht im passenden Standardformat.

Tool-Alternativen

draw.io oder Lucidchart mit eigenem Stencil für Events und Conditions
Spezial-Tools wie TapRooT oder Cause Mapping Software
Markdown mit eingebetteter SVG und Tabellen im Repo
Confluence-Seite mit Diagramm-Embed und strukturierter Causal-Factor-Tabelle

Versionierung / Ownership

Pro Vorfall eigene Analyse mit Datum, Investigator und Reviewer. Updates als neue Version mit Diff-Beschreibung, Vorgänger erhalten. Bei Bestätigung neuer Causal Factors später Update-Eintrag.

markdown

Causal Factor Analysis Arbeitsvorlage

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

# Causal Factor Analysis Arbeitsvorlage

## Ziel

Rekonstruiert Ereignisse und beitragende Faktoren, um die wichtigsten Ursachen eines Problems zu verstehen.

## Kontext

Wann und wofür nutzen wir diese Methode?

## Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

## Durchführung

Kurze Notizen entlang des Run Sheets.

## Ergebnisartefakte
- Event Timeline:
- Causal Factor Chart:
- Ursachenliste:
- Corrective Actions:

## Annahmen und offene Fragen

- ...

## Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Beispielausgabe

Konkret gefülltes Szenario

causal-factor-analysis-beispiel.md

markdown

## CFA — Vorfall 2026-04-09 Logistik-Lager, Wareneinlagerung in falsche Klimazone

**Investigator**: @marlene. **Reviewer**: Dr. Schulze.

### Timeline (Auszug)
- 22:14 LKW-Anlieferung an Tor 3 (Ereignis E1).
- 22:18 Operator scant Packstück (E2).
- 22:21 System zeigt Bestimmungsort „Zone B kühl“ an (E3).
- 22:22 Operator verbringt Packstück in „Zone A trocken“ statt B (E4).
- 22:24 nächster Scan, keine Alarmmeldung (E5).
- 08:30 Temperaturalarm Logistik-Manager (E6).

### Bedingungen
- B1: Spätschicht, einzige Operator-Person, kein Vier-Augen-Prinzip.
- B2: Bildschirm-UI zeigt Zonenangabe in 10pt klein, kein Farbcode.
- B3: Zone A und B liegen direkt nebeneinander, baulich kaum unterscheidbar.
- B4: Klimazonen-Alarm prüft nur Endzustand, nicht Bewegung.

### Causal Factors
- CF1: Falsche Zonenwahl durch Operator (E4) ermöglicht durch UI-Problem (B2).
- CF2: Fehlende sofortige Erkennung (E5) ermöglicht durch System-Logik (B4).
- CF3: Personalbesetzung (B1) verhinderte Cross-Check.

### Root Causes
- RC1: UI-Design hat Anweisung nicht ausreichend hervorgehoben (CF1).
- RC2: Alarmlogik adressiert Endzustand, nicht Übergänge (CF2).
- RC3: Schichtplan toleriert Single-Operator-Setting für sensible Klimazonen (CF3).

### Maßnahmen
- UI-Redesign mit Farbcode und großer Schrift. Owner @ben, bis 15.05.
- Alarmlogik um Übergangscheck erweitert. Owner @anna, bis 30.05.
- Schichtplan-Policy: Klimasensible Einlagerung nur mit Doppelbesetzung. Owner Logistikleiter, ab 15.04.

Was tun

Maßnahmen als Issues im Ticket-System mit Owner und Datum. Quartals-Review der CFA-Maßnahmen Pflicht. Bei Wiederholungsvorfällen alte CFA aufrufen.

Abbruchkriterien

Done-Signale, in unter einer Minute prüfbar

Timeline lässt sich aus verfügbaren Daten nicht rekonstruieren, Faktenbasis fehlt.

Schlüsselzeugen oder Akteure sind nicht verfügbar oder nicht aussagebereit.

Blameless-Norm ist nicht etabliert, Methode kippt in Schuldzuweisung.

Zeit- oder Ressourcen-Budget unter 4 h, Methode kann nicht vollständig durchgeführt werden.

Bei regulierten Vorfällen kein zertifizierter Investigator oder Reviewer, Bericht ist nicht ablieferbar.

Vorfall ist trivial mit eindeutiger Einzelursache; einfache 5 Whys reichen, CFA überdimensioniert.

Run Sheet durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.

Zum Steckbrief Weitere Methoden