Das Fischgräten-Diagramm setzt ein beobachtbares Problem an den Kopf des Fisches und ordnet mögliche Ursachen nach Kategorien auf Hauptgräte und Seitenäste an. Dieses Werkzeug zeichnet nicht nur Ursachennamen, sondern bewahrt auch Oberursache, Belegstatus, stützendes oder widerlegendes Material, den nächsten Prüfschritt und die verantwortliche Person auf. Der Export lässt sich so an die Untersuchungsarbeit anschließen und bleibt nicht beim Brainstorming stehen.

Die sechs Standardkategorien Mensch, Maschine, Material, Methode, Milieu (Umwelt) und Messung lassen sich für Service-, Lern- oder Alltagsfragen umbenennen. Sie sind Hinweise, um Übersehenes zu finden, keine Pflichtfelder. Jede Linie im Diagramm steht zuerst für eine zu prüfende Erklärung und nicht für einen bereits bewiesenen Ursache-Wirkung-Zusammenhang.

1. 01Formuliere am Fischkopf ein konkretes Problem mit Umfang, Beobachtungszeitraum und Abweichung, etwa „Die letzten drei Zwischenabgaben im Kursprojekt lagen jeweils nach dem vereinbarten Termin“. Vermeide Etiketten wie „Team arbeitet ineffizient“, die sich nicht überprüfen lassen.
2. 02Passe die Kategorien an das Szenario an. Für Lernprobleme eignen sich etwa Fähigkeiten und Unterstützung, Werkzeuge und Geräte, Material und Input, Lernablauf, Zeit und Umfeld sowie Rückmeldung und Messung.
3. 03Ergänze mögliche Ursachen und wähle bei Bedarf eine Oberursache, um eine Kette von Unterursachen zu bilden. Das Löschen einer Oberursache entfernt auch alle nachgeordneten Punkte; ein Schritt „Rückgängig“ macht das rückgängig.
4. 04Halte für wichtige Erklärungen den Belegstatus fest: zu prüfende Hypothese, bereits stützende Belege oder durch Belege widerlegt. Bei den letzten beiden Status sind Materialien verpflichtend; stützende Belege schließen andere Erklärungen nicht aus.
5. 05Notiere, wie sich eine Annahme prüfen oder widerlegen lässt und wer das gegenprüft. Exportiere das Fischgräten-Diagramm als PNG oder SVG und kombiniere es mit der Prüfliste in Markdown oder CSV; JSON dient der vollständigen Wiederherstellung.

Die Qualitätsmanagement-Literatur von Kaoru Ishikawa beschreibt das Ursache-Wirkungs-Diagramm systematisch als Werkzeug der Qualitätskontrolle. Auch die Methodenbeschreibungen von ASQ und IHI nutzen es, um mögliche Ursachen eines Ergebnisses zu erkennen und zu ordnen. Der Nutzen liegt darin, Erklärungen sichtbar zu machen und in verschiedenen Kategorien nach Lücken zu suchen; nicht darin, allein durch das Zeichnen die eine Ursache zu finden. ASQ-Methodenbeschreibung, IHI-Werkzeugbeschreibung

Die Hauptgräte trägt die Kategorien, die Äste tragen Ursachen oder feinere Unterursachen. Diese Umsetzung speichert die Struktur über Eltern-Kind-Verweise mit stabilen IDs; die Zeichenfläche behält die Karten je Kategorie und zeigt bei Unterursachen den Verweis auf die Oberursache. Kategorieübergreifende Verweise lösen einen Prüfhinweis aus, damit die Darstellung nicht fälschlich eine feststehende Zuordnung suggeriert. Zirkuläre Verweise sind nicht möglich und werden beim Import abgelehnt.

Im Vergleich zur Mindmap ordnet das Fischgräten-Diagramm Erklärungen rund um dasselbe beobachtete Ergebnis; im Vergleich zur 5-Why-Methode regt es dazu an, mehrere Kategorien quer zu betrachten, statt nur einer Kette weiter nachzufragen. Beides lässt sich verbinden: erst Kandidaten erweitern, dann die Kette auswählen, die Belege braucht. Anders als eine formale Fehlerbaumanalyse liefert dieses Werkzeug keine Ausfallwahrscheinlichkeiten, Logikgatter-Berechnungen, Sicherheitsintegritätsstufen oder Zertifizierungsaussagen.

Die Grenzen folgen aus der offenen Struktur: Beteiligte schreiben vertraute Ursachen eher auf, halten Autoritätsaussagen für Belege oder bleiben bei „Person X ist nicht sorgfältig“ stehen. Kategorien und Linien erzwingen kein Versuchsdesign, deshalb sind weiterhin Abläufe, Informationen, Ressourcen, Umfeld und Gegenbeispiele zu prüfen. Ein fertiges Fischgräten-Diagramm ersetzt keine Untersuchung von Vorfällen mit hohem Risiko.

Im Szenario „Nach dem Release schlägt die Wiederherstellung fehl“ lautet das Problem: Beim Öffnen eines alten Entwurfs erscheint eine leere Seite, und es lässt sich nicht unterscheiden, ob keine Daten vorhanden sind oder die Wiederherstellung fehlschlägt. Die Kategorie Methode nennt eine unzureichende Prüfung über Versionsgrenzen hinweg, die Unterursache ist fehlendes Probenmaterial im alten Format; die Kategorie Geräte denkt begrenzten Speicher mit; die Kategorie Messung erwägt eine zu schwache Fehlermeldung. Jede Hypothese ist mit einer Prüfaktion verbunden, etwa den Wiederherstellungsablauf mit einem Archiv der Vorversion nachzuspielen, statt sofort zu erklären, eine Entwicklerin oder ein Entwickler habe das Problem verursacht.

Das Szenario „Lernaufgaben verzögern sich immer wieder“ trennt Aufgabenaufteilung, Zeitpunkt des Materialeingangs, Arbeits- und Betreuungszeiten sowie Rückmeldungswege. Ein Abgleich mit verfügbarer Zeit und eingereichten Ergebnissen kann die Erklärung verändern; allein die Lernstunden zu zählen, zeigt nicht, ob der Stoff ausreichend verstanden wurde.

Problem: Nach dem Öffnen eines alten Entwurfs erscheint eine leere Seite
Kategorie: Methode
Hauptursache r1: Unzureichende Wiederherstellungsprüfung über Versionen hinweg
Unterursache r2 → r1: Fehlende Datenproben aus älteren Versionen
Status: Zu prüfende Hypothese
Prüfung: Historische Release-Proben sichten und den Wiederherstellungsablauf nachspielen
Verantwortlich: Testleitung

• Maximal 80 Ursachen, 20 Ebenen der Eltern-Kind-Struktur und sechs umbenennbare Kategorien.

• Die Standardkategorien passen nicht für jede Branche und lassen sich umbenennen; diese Seite bietet jedoch keinen beliebigen Grafik-Editor.

• Sehr lange Ursachen und Problemtexte vergrößern die Zeichenfläche, wodurch PNG eventuell herunterskaliert wird; SVG behält Vektordetails, JSON die bearbeitbare Struktur.

• „Durch Belege widerlegt“ ist eine vom Nutzer erfasste Einschätzung; das Werkzeug prüft Materialien nicht automatisch. Widerlegende Einträge sollten nicht gelöscht werden, nur damit das Bild aufgeräumter wirkt.

• Es erkennt keine Ursachen automatisch, schätzt keine Wahrscheinlichkeiten und weist keine Kausalität nach.

• Fragen zu Medizin, Arbeitssicherheit oder rechtlicher Verantwortung gehören zu qualifizierten Stellen und den jeweiligen förmlichen Verfahren.

Behandle Maßnahmen nicht direkt als Ursache: „Schulung nötig“ sagt nicht, welche Fähigkeitslücke beobachtet wurde. Beschreibe auch nicht das Symptom erneut als Erklärung, etwa „Die Verzögerung entstand, weil nicht pünktlich abgeschlossen wurde“. Formuliere zuerst einen konkreten Mechanismus, der durch Material gestützt oder widerlegt werden kann, und lege danach die Prüfaktion fest.

Fülle die sechs Kategorien nicht mit haltlosen Ursachen, nur um Ausgewogenheit herzustellen. Die Kategorie Mensch darf Unterstützung, Übergaben und Kompetenzbedingungen behandeln, sollte aber keine Schuldzuweisungsspalte werden. Behalte andere Erklärungen und Gegenbeispiele bei und notiere, welches Ergebnis die aktuelle Annahme stützen würde – und welches sie entkräftet.

• Geeignet für Fehlersuche bei Software-Regressionen, Wartezeiten im Service, Verzögerungen in Kursprojekten, wiederkehrende Nacharbeit und die Auswertung alltäglicher Abläufe.
• Wenn bereits klare Maßnahmen feststehen, nutze die Aktionsmatrix; wenn Lösungen verglichen werden sollen, die Entscheidungsmatrix.
• Vorfälle mit hohem Risiko dürfen nicht allein anhand der Ausgabe dieser Seite abschließend behandelt werden.

Ursachenordnung, Zeichnen und Export laufen im Browser; eine Kontosynchronisierung gibt es nicht. Die automatische Speicherung ist kein Backup und kann durch das Leeren des Browsers verschwinden. Ein Teilen-Link enthält das gesamte unverschlüsselte Dokument und ist für jeden Besitzer lesbar; ab 8 KB nutze besser eine JSON-Datei. Untersuchungsnotizen betreffen oft Personen oder Kunden – anonymisiere sie zuerst und lege keine rohen sensiblen Materialien in den Link. Schlägt ein Import fehl, bleibt die aktuelle Arbeit erhalten.

• Kaoru Ishikawa, Guide to Quality Control, Asian Productivity Organization, 1986: das Autorenwerk zu Qualitätskontrolle und Ursache-Wirkungs-Diagramm.
• ASQ: Fishbone Diagram: institutionelle Methodenbeschreibung zu möglichen Ursachen, Kategorien und Zeichenablauf.(abgerufen am 2026-09-22)
• IHI: Cause and Effect Diagram: Anwendung des Ursache-Wirkungs-Diagramms in Verbesserungsprojekten; die Ausgabe dieses Werkzeugs ist damit keine medizinische oder sicherheitstechnische Zertifizierung.(abgerufen am 2026-09-22)