Die Ishikawa-Falle: Warum das Fischgräten-Diagramm am Anfang der Problemlösung der falsche Weg ist

Skizze: Links ein mit Haftnotizen überladenes Fischgräten-Diagramm und ratlose Personen, rechts erst die Problembeschreibung und dann ein aufgeräumtes Ishikawa-Diagramm.

Es ist der Klassiker in fast jedem Problemlösungs-Workshop: Ein Prozess hakt, die Fehlerquote steigt oder ein Projekt droht zu scheitern. Das Team kommt zusammen, der Moderator greift motiviert zum Marker, zeichnet eine lange Linie an das Whiteboard, setzt schräge Striche an und schreibt darüber die berühmten 6 Ms: Mensch, Maschine, Material, Methode, Milieu, Messung. Das Ishikawa-Diagramm steht bereit. Die Botschaft an die Runde lautet: „So, wo liegen die Ursachen? Lasst uns brainstormen!“

Was in der Theorie nach einem strukturierten, methodischen Einstieg klingt, ist in der Praxis der perfekte Startschuss für ein ineffizientes, teures und oft frustrierendes Treffen. Das Ishikawa-Diagramm (auch Fischgräten-Diagramm genannt) ist ein mächtiges Werkzeug der Ursachenanalyse – aber es ist ein denkbar schlechtes Werkzeug für den Beginn eines Problemlösungsprozesses.

Wer mit einem Ishikawa anfängt, wählt eine viel zu hohe Flughöhe. Man verliert den Fokus, verzettelt sich im kollektiven Raten und blockiert den direkten Weg zur Lösung. Erst wenn eine messerscharfe, saubere Problembeschreibung vorliegt, entfaltet das Diagramm seine wahre Stärke.

Das Problem der zu hohen Flughöhe: Einladung zum organisierten Brainstorming-Chaos

Warum scheitert der direkte Einstieg mit einem Ishikawa-Diagramm so zuverlässig? Das liegt an der Natur des Werkzeugs selbst. Das Fischgräten-Diagramm ist extrem offen gestaltet. Es bietet Kategorien, aber keine inhaltlichen Leitplanken. Wenn das zugrundeliegende Problem vorab nicht exakt eingegrenzt wurde, agiert das Team auf einer gigantischen Flughöhe. Man schaut aus zehntausend Metern Höhe auf ein vages Symptom und versucht, die gesamte Welt darunter zu erklären.

Ohne konkreten Fokus passiert am Whiteboard Folgendes:

  • Symptome werden zu Ursachen deklariert: Da das Problem vage ist, werfen die Teilnehmer alles in den Ring, was ihnen im Alltag missfällt. „Die IT-Systeme sind zu langsam“ (Kategorie: Maschine) oder „Die Kollegen sind nicht richtig geschult“ (Kategorie: Mensch). Ob diese Punkte überhaupt etwas mit der aktuellen Krise zu tun haben, bleibt völlig offen.
  • Abteilungs-Hickhack statt Fakten: Das Ishikawa wird zur Bühne für politische Baustellen. Jede Abteilung versucht, die Gräten der anderen Teams zu füllen, um von den eigenen Baustellen abzulenken.
  • Die Informationsflut erschlägt das Team: Nach zwei Stunden kleben einhundert Haftnotizen am Board. Das Team hat ein monumentales Abbild aller theoretisch denkbaren Probleme des Unternehmens geschaffen. Doch wo fängt man jetzt an? Welcher dieser Punkte ist der Hebel, der das aktuelle Problem löst? Das Ergebnis ist kein Durchblick, sondern Handlungsunfähigkeit durch Komplexität (Analysis Paralysis).

Das Einsteigen mit einem Ishikawa-Diagramm gleicht dem Versuch, ein Leck in einem riesigen Rohrleitungssystem zu finden, indem man eine vollständige Liste aller Bauteile ausdruckt und darüber spekuliert, welche Schraube theoretisch rosten könnte. Es fehlt die Erdung. Es fehlt der Fokus.

Der Retter: Die exakte Problembeschreibung als Gravitationskraft

Um nicht in den Wolken des Ishikawas zu schweben, muss ein radikaler Schnitt vorangestellt werden: die methodische Problembeschreibung. Sie zwingt das Team, die Flughöhe massiv zu verringern, auf den Boden der Tatsachen zurückzukehren und den Blickwinkel extrem zu verengen.

Eine saubere Problembeschreibung speist sich nicht aus Meinungen oder Hypothesen, sondern aus beobachtbaren Fakten. Sie beantwortet die harten Fragen: Was genau weicht vom Standard ab? Wo tritt es auf (und wo explizit nicht)? Wann wurde es das erste Mal beobachtet (und wann nicht)? Wie groß ist das Schadensausmaß?

Nehmen wir ein konkretes Beispiel, um den Unterschied zu verdeutlichen:

Vager Einstieg (direkt ins Ishikawa): „Die Fehlerquote in der Produktion ist zu hoch.“ Folge: Das Team diskutiert im Ishikawa über die Hitze in der Halle (Milieu), die Motivation der Leiharbeiter (Mensch) und die Qualität des Stahls (Material). Der Suchradius ist unendlich groß.

Mit sauberer Problembeschreibung vorab: „Die Bohrung an Bauteil X weist seit dem 01. Juni bei der Spätschicht auf Maschine 3 eine Maßabweichung von plus 0,2 mm auf. Betroffen sind ausschließlich Chargen des Lieferanten A. Die Früh- und Nachtschichten sowie andere Maschinen sind fehlerfrei.“

Siehst Du, was hier passiert? Durch diese präzise Beschreibung stürzt die Flughöhe schlagartig ab – im positiven Sinne. Wir haben den Suchradius von einer kompletten Produktionshalle auf ein messerscharf definiertes Szenario zusammengestrichen.

Wenn das Fundament steht: Erst JETZT macht das Ishikawa Sinn

Erst an diesem Punkt – wenn das Problem isoliert und der Noise (das Grundrauschen irrelevanter Probleme) herausgefiltert ist – schlägt die große Stunde des Ishikawa-Diagramms. Jetzt wird es nicht mehr als ungerichtetes Brainstorming-Werkzeug missbraucht, sondern dient als chirurgischer Leitfaden für die Detailanalyse.

Wenn wir das oben präzise beschriebene Problem an die Spitze der Fischgräte setzen, verändert sich die Dynamik im Raum komplett. Die Kategorien der 6 Ms wirken plötzlich wie Präzisionswerkzeuge statt wie Auffangbecken für Frust:

  • Mensch: Wir fragen nicht mehr allgemein: „Sind die Mitarbeiter unmotiviert?“, sondern ganz gezielt: „Gibt es eine Besonderheit in der Arbeitsweise der Spätschicht an Maschine 3 beim Einspannen des Bauteils?“
  • Maschine: Wir untersuchen nicht die gesamte IT-Landschaft, sondern fragen: „Verhält sich Maschine 3 nach mehreren Betriebsstunden (während der Spätschicht) thermisch anders als die anderen Maschinen?“
  • Material: Die Frage lautet nicht: „Ist unser Material schlecht?“, sondern: „Wie unterscheidet sich die Materialhärte der Chargen von Lieferant A spezifisch bei dieser Bohrung von anderen Lieferanten?“

Das Ishikawa-Diagramm wird durch die Vorarbeit der Problembeschreibung von einer unendlichen Ideensammlung zu einer zielgerichteten Hypothesen-Matrix. Das Team rät nicht mehr ins Blaue hinein, sondern formuliert überprüfbare Vermutungen, die direkt im Anschluss mit Daten untermauert oder widerlegt werden können. Man spart Tage, wenn nicht Wochen an zielloser Recherchearbeit.

Fazit: Respektiere die Reihenfolge der Methode

Das Ishikawa-Diagramm ist ein großartiges Werkzeug, um Ursachen-Wirkungs-Zusammenhänge sichtbar zu machen – aber jede Wirkung braucht vorher einen glasklar definierten Körper. Wer den Schritt der Problembeschreibung überspringt und sofort die Fischgräte zeichnet, baut ein instabiles Kartenhaus aus Meinungen, Mutmaßungen und Nebenkriegsschauplätzen.

Für den Projekterfolg gilt eine eiserne Hierarchie in der Methodik: Erst wird das Problem isoliert, beschrieben und fixiert. Erst wenn jeder im Raum exakt denselben, eng eingegrenzten Fehler vor Augen hat, wird die Fischgräte gezeichnet. Wer diese Reihenfolge einhält, verhindert den Kontrollverlust auf zu hoher Flughöhe, nimmt das Team durch messbare Fakten mit und kommt nicht nur schneller, sondern vor allem nachhaltiger zur echten Problemlösung.

Methoden in der richtigen Reihenfolge einsetzen

Lerne, wann welches Werkzeug wirkt – von der Problembeschreibung bis zur Ursachenanalyse.

Beratung anfragen
← Symptom vs. Problem Nächster Artikel: KI braucht den Menschen →