methodatlas
Session Builder

Meine Session planen

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

Methoden-SessionInitial 4-8 h, danach iterative Refinements pro SubbaumWorkshop oder asyncFault Tree

Session: Fault Tree 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 Fault Tree hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

  1. 1

    Phase 1: Top-Event und Systemgrenze

    30-45 min

    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.

    FacilitatorFault Tree
  2. 2

    Phase 2: Erste Verzweigungsebene

    45-60 min

    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.

    FacilitatorCritical Paths
  3. 3

    Phase 3: Iterative Verfeinerung

    2-4 h

    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.

    FacilitatorUrsachenhypothesen
  4. 4

    Phase 4: Minimal Cut Sets

    45-90 min

    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.

    FacilitatorKontrollmaßnahmen
  5. 5

    Phase 5: Maßnahmen und Review

    45-90 min

    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.

    OwnerFault Tree
  6. 6

    Artefakt veröffentlichen

    10 min

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

    OwnerFault Tree
Nutzbares Artefakt

Session Brief

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

session-brief.md

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. 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. 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. 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. 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. 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.
Nutzbares Artefakt

Arbeitsartefakt

Vorgefüllter Startpunkt auf Basis der passenden Vorlage.

arbeitsartefakt.md

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
Vorlagenbasis

Fault Tree Analysis Arbeitsvorlage

Vorlage ansehenKompakte Arbeitsvorlage für Fault Tree Analysis mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
canvas

fault-tree-analysis-working-template.md

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

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.

Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu Fault Tree.
  • Pro System und Top-Event eigene FTA. Versionsstand mit Datum, Autor und Reviewer. Bei Systemänderungen FTA-Update als neue Version mit Diff-Beschreibung, Vorgänger nicht löschen.
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.
SteckbriefRunsheet