Meine Session planen

# Session Brief: Fault Tree Analysis

## Ziel
Artefakt: Fault Tree

## Arbeitsfrage
Welche logischen Kombinationen von Basisereignissen führen zum unerwünschten Top-Event, und welche minimalen Cut Sets sind so kritisch, dass sie Maßnahmen erfordern?

## Kontext
Top-Event als ein präziser, unerwünschter Zustand (z. B. „Falsche Dosierung in Patient verabreicht“); Systemdiagramm; verfügbare Ausfallraten oder Schätzungen pro Komponente; Standards oder Normen, falls regulatorisch relevant.

## Setup
- Format: Methoden-Session
- Dauer: Initial 4-8 h, danach iterative Refinements pro Subbaum
- Modus: Workshop oder async
- Teilnehmende: Ein FTA-Coach mit Erfahrung in Reliability oder Safety Analysis; 3-6 Experten aus betroffenen Domänen (z. B. SW, HW, Netz, Daten, Ops); ein Scribe für Annahmen und Quellen; bei sicherheitskritischen Systemen ein unabhängiger Reviewer.
- Owner: Ein FTA-Coach mit Erfahrung in Reliability oder Safety Analysis
- 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 Fault Tree hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
Großes Whiteboard oder digitales Diagramm-Tool (z. B. draw.io, Lucidchart, OmniGraffle); FTA-Symbolik (AND-Gate, OR-Gate, Basisereignis, Top-Event); Systemdokumentation; Vorlage für Wahrscheinlichkeiten und Sub-Ereignisse.

## Vorbereitung
Top-Event groß oben am Board als Rechteck. FTA-Symbolik als Plakat sichtbar. Sektion „Annahmen“ separat führen, jede Annahme nummeriert. Regel: AND-Gates verbinden Ereignisse, die gleichzeitig zutreffen müssen; OR-Gates verbinden alternative Ursachen.

## Agenda
1. Phase 1: Top-Event und Systemgrenze (30-45 min)
   Owner: Facilitator
   Aktion: Top-Event präzise formulieren: Zustand, Schwellwert, Zeitfenster, betroffenes System. Systemgrenze definieren: was gehört in den Baum, was wird als Black Box behandelt. Hinweis: Wenn Top-Event nicht eindeutig (z. B. „System fällt aus“ ohne Definition), ist Baum beliebig. Definition mit Akzeptanzkriterien, am besten testbar. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Fault Tree

2. Phase 2: Erste Verzweigungsebene (45-60 min)
   Owner: Facilitator
   Aktion: Welche unmittelbaren Vorbedingungen müssen zutreffen, damit Top-Event eintritt. Unterscheiden: AND (alle gleichzeitig) oder OR (eine reicht). Diese Ebene als Sub-Ereignisse unter Top-Event. Hinweis: Häufiger Fehler: zu schnelle Verfeinerung. Erste Ebene muss vollständig sein, sonst fehlt strukturelle Logik. Test: würde diese Ebene allein das Top-Event erklären, wenn voll geprüft. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Critical Paths

3. Phase 3: Iterative Verfeinerung (2-4 h)
   Owner: Facilitator
   Aktion: Jedes Sub-Ereignis weiter zerlegen, bis Basisereignisse erreicht sind (Komponentenausfall, Bedienfehler, externe Ursache). Annahmen und Datenquellen pro Ebene dokumentieren. Hinweis: Stoppen, wenn weitere Verfeinerung keinen Wert mehr bringt oder keine Daten verfügbar sind. Bäume können theoretisch unendlich tief werden; praktischer Stop bei 4-6 Ebenen oder bei messbaren Basisereignissen. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Ursachenhypothesen

4. Phase 4: Minimal Cut Sets (45-90 min)
   Owner: Facilitator
   Aktion: Minimal Cut Sets identifizieren: kleinste Kombinationen von Basisereignissen, deren gleichzeitiges Auftreten das Top-Event auslöst. Manuelle Ableitung oder Tool-basiert. Hinweis: Cut Sets der Größe 1 sind Single Points of Failure und meist kritisch. Cut Sets mit hoher kombinierter Wahrscheinlichkeit gleichermaßen. Priorisierung nach Wirkung mal Wahrscheinlichkeit. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Kontrollmaßnahmen

5. Phase 5: Maßnahmen und Review (45-90 min)
   Owner: Owner
   Aktion: Pro kritisches Cut Set Maßnahme(n) ableiten: Redundanz, Erkennung, Wiederherstellung, Vermeidung. Owner und Datum. FTA-Review durch unabhängige Person bei sicherheitskritischen Systemen. Hinweis: Maßnahmen ohne unabhängigen Review sind anfällig für blinde Flecken. Bei regulierten Systemen ist Review Pflicht, nicht Optionalität. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Fault Tree

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: Fault Tree

## Abschluss
- Ergebnisartefakt aktualisieren: Fault Tree
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# Fault Tree: Fault Tree Analysis

## Arbeitsfrage
Welche logischen Kombinationen von Basisereignissen führen zum unerwünschten Top-Event, und welche minimalen Cut Sets sind so kritisch, dass sie Maßnahmen erfordern?

## Kontext
Top-Event als ein präziser, unerwünschter Zustand (z. B. „Falsche Dosierung in Patient verabreicht“); Systemdiagramm; verfügbare Ausfallraten oder Schätzungen pro Komponente; Standards oder Normen, falls regulatorisch relevant.

## Beteiligte
- Owner: Ein FTA-Coach mit Erfahrung in Reliability oder Safety Analysis
- Teilnehmende: Ein FTA-Coach mit Erfahrung in Reliability oder Safety Analysis; 3-6 Experten aus betroffenen Domänen (z. B. SW, HW, Netz, Daten, Ops); ein Scribe für Annahmen und Quellen; bei sicherheitskritischen Systemen ein unabhängiger Reviewer.

## Input
Großes Whiteboard oder digitales Diagramm-Tool (z. B. draw.io, Lucidchart, OmniGraffle); FTA-Symbolik (AND-Gate, OR-Gate, Basisereignis, Top-Event); Systemdokumentation; Vorlage für Wahrscheinlichkeiten und Sub-Ereignisse.

## Vorlage
# Fault Tree Analysis Canvas

## Kontext

Wofür wird die Methode eingesetzt?

## Kernfrage

Welche Frage soll am Ende beantwortet sein?

## Input

Welche Daten, Beobachtungen oder Materialien liegen vor?

## Arbeitsfläche

- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:

## Ergebnisartefakte
- Fault Tree:
- Critical Paths:
- Ursachenhypothesen:
- Kontrollmaßnahmen:

## Offene Fragen

- ...

## Nächster Schritt

Owner, Datum, Erfolgssignal.

## Fertigstellungscheck
- Fault Tree 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