Was vorher fertig sein muss
Das Problem ist als beobachtbares Symptom mit Datum, Häufigkeit und Auswirkung in einem Satz formuliert.
Bei eng abgegrenzten Symptomen mit klarer Kausalkette wurde geprüft, ob 5 Whys ausreicht und Fishbone den Mehrwert breiterer Kategorisierung bringt.
Was vor Start vorliegen muss
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.
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.
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.
30-60 min
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.
Die eine Frage, die diese Methode beantwortet
Welche möglichen Ursachen über alle relevanten Kategorien hinweg verdienen eine datenbasierte Tiefenprüfung als nächste Aktion?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Problem-Schärfung | 5 min | Problem-Satz lesen, prüfen, ob er ein beobachtbares Symptom mit Zeit und Auswirkung enthält. Wenn nicht, neu formulieren. | „Performance ist schlecht“ ist kein Symptom. „P95-Latenz API /orders >800 ms seit 10.05.“ ist eines. Ohne Symptom kein Fishbone. |
2Phase 2: Kategorien wählen | 5 min | 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. | Mehr als 6 Kategorien überfordern. Wenn eine Kategorie immer leer bleibt, war sie für dieses Problem irrelevant und wird gestrichen. |
3Phase 3: Ursachensammlung | 20-30 min | 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. | Wenn alle Ursachen in einer Kategorie landen, ist die Gruppe einseitig besetzt oder hat ein vorab geformtes Bild. Andere Kategorien explizit befragen. |
4Phase 4: Priorisierung | 10 min | Ursachen markieren nach (a) Wahrscheinlichkeit, (b) Datenverfügbarkeit zur Prüfung. Top 3-5 Ursachen mit Owner und Untersuchungsmethode versehen. | Top-Auswahl nach Wahrscheinlichkeit, nicht nach Lieblings-Hypothese. Wenn keine Daten verfügbar sind, wird die Ursache zur Untersuchungsaufgabe, nicht zur Maßnahme. |
5Phase 5: Followup | 5-10 min | Untersuchungs-Backlog erstellen: pro Top-Ursache eine konkrete Prüfaktion (Log-Query, Experiment, Interview) mit Frist. Reinzeichnung als Artefakt ablegen. | Fishbone ohne Untersuchungs-Backlog bleibt eine schöne Skizze. Mindestens drei Prüfaktionen mit Datum, sonst war die Session diagnostisch wertlos. |
Was am Ende rauskommt
Reingezeichnetes Fishbone-Diagramm mit Problem-Satz im Kopf, beschrifteten Gräten pro Kategorie, allen gesammelten Ursachen und Unter-Ursachen, Markierung der Top 3-5 und separatem Untersuchungs-Backlog mit Owner, Methode und Frist.
Pro Untersuchungsfall ein Eintrag mit Datum und Problem-ID. Folgesitzungen nach Datenprüfung als Version 2 anlegen, neue Erkenntnisse ergänzen, widerlegte Ursachen markieren statt löschen.
Kompakte Arbeitsvorlage für Fishbone Diagram mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# 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.Konkret gefülltes Szenario
## Fishbone — P95-Latenz API /orders > 800 ms seit 10.05.2026
**Problem**: Seit 10.05.2026 P95-Latenz auf /orders durchgehend >800 ms (vorher 220 ms), Auswirkung: 4% Checkout-Abbruch zusätzlich.
**Kategorien (6Ms angepasst)**:
- **Methods**: Query-Plan-Änderung durch ORM-Update; fehlende Indexnutzung.
- **Machines**: DB-Instanz noch auf t3.large statt t3.xlarge.
- **Materials (Daten)**: Orders-Tabelle seit Black Friday auf 14M Zeilen gewachsen.
- **Manpower**: Neuer Developer hat 09.05. Query-Refactor deployt.
- **Measurement**: Slow-Query-Log war 6 Wochen aus.
- **Milieu**: AWS-Region eu-central-1 hatte am 10.05. erhöhte Network-Latenz (laut Status-Page kurzzeitig).
**Top 3 Ursachen (priorisiert)**:
1. Query-Refactor 09.05. (Methods) — Prüfung: Git-Blame + EXPLAIN ANALYZE. Owner: @ben, bis 19.05.
2. Fehlende Index-Nutzung auf orders.customer_id (Methods/Data) — Prüfung: pg_stat_user_indexes. Owner: @anna, bis 19.05.
3. Tabellenwachstum ohne Partitionierung (Data) — Prüfung: Größenanalyse + Partitionierungs-Plan. Owner: @lisa, bis 26.05.Symptome erkennen, gegensteuern
Im Kopf des Fishbones steht „App ist langsam“ oder „Kunden unzufrieden“, ohne Zeit, Häufigkeit oder Metrik.
Workshop pausieren und Symptom mit Datum, Häufigkeit und Messgröße neu formulieren. Ohne Symptom keine Ursachenanalyse, sondern Spekulation.
Stickies enthalten Maßnahmen („Index hinzufügen“) statt Ursachen („fehlender Index auf customer_id“).
Ursache und Gegenmaßnahme trennen. Ursache an die Gräte, Lösung in separate Liste. Fishbone analysiert das Warum, nicht das Wie.
Gruppe zwingt Ursachen in unpassende Kategorien, um alle Gräten gleichmäßig zu füllen.
Leere Gräten sind erlaubt, sie zeigen relevante Kategorien. Falsche Zuordnung verzerrt Priorisierung. Kategorien sind Hilfe, nicht Quota.
Die Top-Ursache ist die, die am leidenschaftlichsten verteidigt wurde, nicht die wahrscheinlichste.
Stilles Dot-Voting nach Wahrscheinlichkeit. Datenverfügbarkeit als zweites Kriterium. Beide Kriterien getrennt voten, dann kombinieren.
Workshop endet mit Top 3, niemand prüft sie mit Logs oder Experimenten, Diagramm wandert ins Archiv.
Untersuchungs-Backlog ist Pflichtartefakt. Pro Top-Ursache eine konkrete Prüfaktion mit Owner und Datum. Folgetermin in 1-2 Wochen für Ergebnis-Review.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.