Startseite/ Blog/ 5 Whys vs. Fishbone

5 Whys vs. Fishbone: die richtige Methode zur Ursachenanalyse wählen

Wenn etwas schiefgeht, eine Verletzung, ein Beinahe-Unfall, ein Qualitätsmangel, der durchrutscht, ist das Ziel der Ereignisabklärung leicht zu benennen und schwer zu erreichen: die Ursache zu finden, die Sie tatsächlich beheben können, damit es nicht wieder passiert. Zwei Techniken dominieren diese Arbeit: die 5 Whys und das Fishbone-Diagramm (Ishikawa). Oft werden sie als Rivalen behandelt. Besser versteht man sie als Ergänzungen.

So funktioniert jede Methode, wo sie scheitert und wie Sie entscheiden, zu welcher Sie greifen.

Die 5 Whys: tief in eine Kette gehen

Die 5 Whys sind eine lineare Technik. Sie benennen das Problem, fragen «Warum ist das passiert?», beantworten die Frage, fragen dann «Warum?» zu dieser Antwort und wiederholen das, bis Sie eine Ursache erreichen, deren Behebung ein Wiederauftreten verhindert. Ein durchgespieltes Beispiel:

  • Ein Bediener rutschte in der Nähe von Förderband 3 aus und stürzte.
  • Auf dem Boden war Hydrauliköl.
  • Eine Schlaucharmatur an der Presse war undicht.
  • Die Armatur wurde nicht im vorgesehenen Intervall ausgetauscht.
  • Die vorbeugende Wartungsaufgabe wurde nicht ausgelöst.
  • Der Wartungsplan für diese Presse wurde beim Ersatz des CMMS nie übernommen.

Beachten Sie: Die Grundursache ist eine Systemlücke (eine versäumte Datenmigration), nicht «der Bediener war nachlässig». Genau darum geht es, fragen Sie weiter nach dem Warum, bis Sie am menschlichen Fehler vorbei sind und die Bedingung erreichen, die ihn ermöglicht hat.

Wo die 5 Whys gut funktionieren

  • Einfache bis mittelschwere Probleme mit einer klaren, einzelnen Ursachenkette
  • Schnelle Abklärungen, bei denen Sie rasch eine belastbare Ursache brauchen
  • Teams, die neu in der Ursachenanalyse (RCA) sind, sie braucht weder Ausbildung noch Vorlagen

Wo die 5 Whys scheitern

  • Tunnelblick. Die Methode folgt einem einzigen Pfad und kann parallele Ursachen übersehen, die meisten echten Ereignisse haben mehrere beitragende Faktoren, nicht nur einen.
  • Hört zu früh auf. Teams begnügen sich mit «menschlichem Versagen» und hören auf, und geben der Person die Schuld statt dem System.
  • Die Antwort hängt davon ab, wer fragt. Je nachdem, wer abklärt, ergeben sich vom selben Problem aus unterschiedliche Ketten.

Das Fishbone-Diagramm: in die Breite über Kategorien gehen

Das Fishbone-Diagramm (auch Ishikawa- oder Ursache-Wirkungs-Diagramm) ist eine Verzweigungstechnik. Sie schreiben das Problem an den «Kopf» des Fisches und sammeln dann mögliche Ursachen entlang der «Gräten», jede für eine Kategorie. Die klassischen Kategorien in der Fertigung sind die 6 Ms:

KategorieLeitfragen
MethodeVerfahren, Arbeitsanweisungen, die Gestaltung der Aufgabe
MaschineAusrüstung, Werkzeuge, Wartung, Schutzeinrichtungen
MaterialRohstoffe, Verbrauchsmaterial, Ersatzstoffe
Mensch / PersonenAusbildung, Kompetenz, Personalbesetzung, Ermüdung, Aufsicht
MessungInspektion, Kalibrierung, Überwachung, Datenqualität
UmgebungLayout, Beleuchtung, Lärm, Wetter, Ordnung und Sauberkeit

Für einen Dienstleistungs- oder Sicherheitskontext können Sie die Kategorien austauschen (People, Process, Policy, Place usw.). Der Wert ist strukturell: Wenn Sie sich zwingen, jede Kategorie zu betrachten, bringen Sie Ursachen ans Licht, die eine einzelne «Warum»-Kette nie erreichen würde.

Wo Fishbone gut funktioniert

  • Komplexe Probleme mit mehreren beitragenden Faktoren
  • Gruppen-Workshops, eine natürliche Brainstorming-Fläche
  • Wenn Sie vermuten, dass Ihnen etwas entgeht, und Breite vor Tiefe wollen

Wo das Fischgräten-Diagramm scheitert

  • Breite ohne Tiefe. Es listet mögliche Ursachen auf, sagt aber von sich aus nicht, welche real sind oder wie tief sie reichen.
  • Kann zu einer Wand aus Vermutungen werden. Ohne Belege füllen sich die Gräten mit Spekulation.
  • Keine Priorisierung eingebaut. Sie brauchen weiterhin eine Möglichkeit, die Kandidaten zu prüfen und zu ordnen.

Im direkten Vergleich

 5 WhysFischgräten-Diagramm
FormLinear, eine Kette, tiefVerzweigt, viele Kategorien, breit
Am besten fürEinfache Probleme mit einer einzigen UrsacheKomplexe, multifaktorische Probleme
TeamgrösseEinzelperson oder kleine GruppeWorkshop / Gruppe
HauptrisikoTunnelblick, hört bei der Schuldzuweisung aufSpekulation, keine Tiefe
ErgebnisEine GrundursacheEine Karte möglicher Ursachen
Die beste Antwort lautet meist «beides». Beginnen Sie mit einem Fishbone, um die ganze Bandbreite möglicher Ursachen über alle Kategorien hinweg abzubilden. Nehmen Sie dann die wahrscheinlichsten Gräten und gehen Sie mit den 5 Whys jeder einzelnen nach, bis Sie die Grundursache auf Systemebene erreichen. Das Fishbone gibt Ihnen die Breite, damit Ihnen kein Faktor entgeht; die 5 Whys geben Ihnen die Tiefe, ihn zu beheben. Erst die Breite, dann die Tiefe.

Von der Grundursache zur Korrekturmassnahme

Eine RCA lohnt sich nur, wenn sie etwas verändert. Egal welche Methode Sie nutzen, das Ergebnis sollte in eine Korrektur- und Vorbeugemassnahme (CAPA) münden, die auf die Grundursache zielt und nicht auf das Symptom. Das Öl aufzuwischen behebt das «Warum 1». Die Lücke bei der CMMS-Migration zu schliessen behebt die eigentliche Grundursache und verhindert jedes künftige Leck, das dieselbe Lücke verdeckt hätte.

Gute Praxis: Jede bestätigte Grundursache erhält mindestens eine Massnahme mit Verantwortlichem und Fälligkeitsdatum, und die Wirksamkeit der Massnahme wird nach ihrem Abschluss überprüft. Dieser letzte Schritt, hat die Massnahme tatsächlich gewirkt?, unterscheidet eine Papierübung von echter Verbesserung, und genau das prüft ein Auditor nach ISO 45001 oder ISO 9001 bei den Korrekturmassnahmen.

RCA durchführen und den Kreis an einem Ort schliessen

Das Modul Ereignisse von ENSURE begleitet Ereignisabklärungen mit 5 Whys und Fishbone und macht bestätigte Grundursachen dann zu nachverfolgten CAPAs mit Verantwortlichen, Fälligkeitsdaten und Wirksamkeitsprüfungen, damit nichts bei «Boden wischen» aufhört. Sehen Sie es in einer 30-Minuten-Demo an einem echten Ereignis.

Demo buchen Modul Ereignisse ansehen

Lesen Sie weiter

So erstellen Sie eine Risikobeurteilung pro Tätigkeit (JHA): Schritt-für-Schritt-Anleitung → ISO 45001 Abschnitt 6.1.2 erklärt: Gefährdungsermittlung und Risikobeurteilung →