Session Brief: Fishbone Diagram

Ziel

Artefakt: Fishbone Diagram

Arbeitsfrage

Welche möglichen Ursachen über alle relevanten Kategorien hinweg verdienen eine datenbasierte Tiefenprüfung als nächste Aktion?

Kontext

Problem-Satz mit Zeit, Häufigkeit, Auswirkung; bekannte vorherige Hypothesen; Zugang zu Daten (Logs, KPIs, Incident-Reports); Liste der Personen, die die letzten 4 Wochen nah am Problem waren.

Setup

• Format: Methoden-Session
• Dauer: 30-60 min
• Modus: Workshop
• Teilnehmende: Ein Facilitator, der Kategorien und Bewertung trennt; zwei bis acht Teilnehmende mit direktem Bezug zum Prozess (Operations, Engineering, Quality, Support); ein Scribe für die Reinzeichnung.
• Owner: Ein Facilitator, der Kategorien und Bewertung trennt
• 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 Fishbone Diagram hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

Input

Whiteboard oder Miro-Board mit vorgezeichnetem Fishbone (Kopf rechts, Wirbelsäule horizontal, 4-6 Gräten); Stickies; Stifte; Timer; Link zu Logs, Tickets oder Daten, die Ursachen belegen können.

Vorbereitung

Problem in den Kopf des Fishbone schreiben. Kategorien wählen (klassisch 6Ms: Methods, Machines, Materials, Manpower, Measurement, Milieu; alternativ 4Ps für Services). Timer auf erste Sammelphase setzen.

Agenda

1. Phase 1: Problem-Schärfung (5 min) Owner: Facilitator Aktion: Problem-Satz lesen, prüfen, ob er ein beobachtbares Symptom mit Zeit und Auswirkung enthält. Wenn nicht, neu formulieren. Hinweis: „Performance ist schlecht“ ist kein Symptom. „P95-Latenz API /orders >800 ms seit 10.05.“ ist eines. Ohne Symptom kein Fishbone. Output: Fishbone Diagram

2. Phase 2: Kategorien wählen (5 min) Owner: Facilitator Aktion: 4-6 Kategorien als Gräten festlegen. Klassische 6Ms für Produktion, 4Ps (People, Process, Policy, Place) für Services, oder eigene Kategorien für den Kontext. Hinweis: Mehr als 6 Kategorien überfordern. Wenn eine Kategorie immer leer bleibt, war sie für dieses Problem irrelevant und wird gestrichen. Output: Cause Categories

3. Phase 3: Ursachensammlung (20-30 min) Owner: Facilitator Aktion: Pro Kategorie still 5 min sammeln, dann reihum vorstellen. Ursachen als Stickies an die jeweilige Gräte. Pro Hauptursache 2-3 Unter-Ursachen (Why) ergänzen. Hinweis: Wenn alle Ursachen in einer Kategorie landen, ist die Gruppe einseitig besetzt oder hat ein vorab geformtes Bild. Andere Kategorien explizit befragen. Output: Investigation Backlog

4. Phase 4: Priorisierung (10 min) Owner: Facilitator Aktion: Ursachen markieren nach (a) Wahrscheinlichkeit, (b) Datenverfügbarkeit zur Prüfung. Top 3-5 Ursachen mit Owner und Untersuchungsmethode versehen. Hinweis: Top-Auswahl nach Wahrscheinlichkeit, nicht nach Lieblings-Hypothese. Wenn keine Daten verfügbar sind, wird die Ursache zur Untersuchungsaufgabe, nicht zur Maßnahme. Output: Fishbone Diagram

5. Phase 5: Followup (5-10 min) Owner: Owner Aktion: Untersuchungs-Backlog erstellen: pro Top-Ursache eine konkrete Prüfaktion (Log-Query, Experiment, Interview) mit Frist. Reinzeichnung als Artefakt ablegen. Hinweis: Fishbone ohne Untersuchungs-Backlog bleibt eine schöne Skizze. Mindestens drei Prüfaktionen mit Datum, sonst war die Session diagnostisch wertlos. Output: Cause Categories

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: Fishbone Diagram

Abschluss

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

Fishbone Diagram: Fishbone Diagram

Arbeitsfrage

Welche möglichen Ursachen über alle relevanten Kategorien hinweg verdienen eine datenbasierte Tiefenprüfung als nächste Aktion?

Kontext

Problem-Satz mit Zeit, Häufigkeit, Auswirkung; bekannte vorherige Hypothesen; Zugang zu Daten (Logs, KPIs, Incident-Reports); Liste der Personen, die die letzten 4 Wochen nah am Problem waren.

Beteiligte

• Owner: Ein Facilitator, der Kategorien und Bewertung trennt
• Teilnehmende: Ein Facilitator, der Kategorien und Bewertung trennt; zwei bis acht Teilnehmende mit direktem Bezug zum Prozess (Operations, Engineering, Quality, Support); ein Scribe für die Reinzeichnung.

Input

Whiteboard oder Miro-Board mit vorgezeichnetem Fishbone (Kopf rechts, Wirbelsäule horizontal, 4-6 Gräten); Stickies; Stifte; Timer; Link zu Logs, Tickets oder Daten, die Ursachen belegen können.

Vorlage

Fishbone Diagram 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

• Fishbone Diagram:
• Cause Categories:
• Investigation Backlog:

Offene Fragen

• ...

Nächster Schritt

Owner, Datum, Erfolgssignal.

Fertigstellungscheck

• Fishbone Diagram 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