Ishikawa-Diagramm: Aufbau, Kategorien und Anwendung in der Produktion

Das Ishikawa-Diagramm ordnet die möglichen Ursachen eines Problems nach Kategorien und macht sichtbar, wo im Prozess noch niemand nachgesehen hat. Es gehört zu den ältesten Werkzeugen des Qualitätsmanagements und ist im Shopfloor-Alltag immer noch eines der nützlichsten – solange am Ende eine Maßnahme daraus folgt.

Was ist ein Ishikawa-Diagramm?

Das Ishikawa-Diagramm, auch Fischgräten- oder Ursache-Wirkungs-Diagramm genannt, geht auf den japanischen Qualitätsforscher Kaoru Ishikawa zurück. Die American Society for Quality führt es bis heute unter den sieben elementaren Qualitätswerkzeugen und verweist darauf, dass Ishikawa diese sieben Werkzeuge in seinem Buch Guide to Quality Control erstmals gebündelt dargestellt hat. Ein Entstehungsjahr nennt die ASQ nicht, und die Literatur datiert es unterschiedlich.

Der Aufbau ist in einem Satz erklärt: Am Kopf der Gräte steht das Problem, von der Mittellinie zweigen die Hauptkategorien ab, und an diesen Ästen hängen die möglichen Ursachen. Darin liegt auch die wichtigste Eigenschaft der Methode: In einem Ishikawa-Diagramm stehen Hypothesen. Bewiesen ist damit noch nichts. Es ordnet, was das Team für möglich hält. Welche Ursache tatsächlich wirkt, entscheidet sich danach – an Daten, am Prozess, im Versuch.

Die Kategorien: von 4M bis 8M

Die Basis bilden vier M: Mensch, Maschine, Material und Methode. Im deutschen Sprachgebrauch wird schrittweise erweitert – um Mitwelt (auch Milieu oder Umwelt), dann Management, dann Messung, zuletzt Money – bis zur 8M-Variante. Die American Society for Quality zählt anders: Dort gehören Messung und Umwelt („Mother Nature“) schon zu sechs Kernkategorien.

Welche Variante die richtige ist, entscheidet der Prozess. Das Beispiel weiter unten und die Peakboard-Anwendung auf dieser Seite arbeiten mit der ASQ-Zählung, also mit Messung und Umwelt in den sechs Kategorien. Wer Messung weglässt, verlagert Messfehler unbemerkt in andere Äste.

In sechs Schritten zum Diagramm

1. Problem eindeutig formulieren. Konkret, messbar und ohne Schuldzuweisung. „Schicht B arbeitet schlecht“ führt in die Irre; „die Linie erreicht die geplante Ausbringungsmenge pro Schicht nicht“ beschreibt, worum es geht.
2. Kategorien festlegen. Vier, sechs oder acht – je nachdem, was den Prozess abbildet.
3. Ursachen sammeln. Mit denen, die den Prozess fahren, und am besten dort, wo er läuft. Erst sammeln, dann diskutieren.
4. Nachhaken. Zu jeder gesammelten Ursache mindestens einmal fragen, warum sie auftritt. So entstehen Unteräste, an denen sich weiterarbeiten lässt.
5. Lücken prüfen. Ein fast leerer Ast heißt entweder, dass es dort nichts gibt, oder dass niemand im Raum diesen Bereich kennt. Beides ist wichtig zu wissen.
6. Bewerten und verifizieren. Die wahrscheinlichsten Ursachen markieren und prüfen – mit Daten aus der Anlage, mit Beobachtung, mit einem gezielten Versuch.

Beispiel aus der Fertigung

Problem am Kopf der Gräte: Die Produktionslinie erreicht die geplante Ausbringungsmenge pro Schicht nicht. Was in den sechs Ästen landen kann:

• Mensch: Bediener sind für die erforderliche Taktzeit nicht ausreichend geschult; die Personalbesetzung ist während Teilen der Schicht zu gering.
• Maschine: wiederkehrende Kleinstillstände; die Anlage läuft unterhalb der vorgesehenen Produktionsgeschwindigkeit.
• Material: Materialengpässe unterbrechen den Prozess.
• Methode: Der Standardarbeitsablauf enthält unnötige Handhabungsschritte; Rüst- und Reinigungsaktivitäten sind nicht optimiert.
• Messung: Kurzstillstände werden in den Produktionsdaten nicht konsequent erfasst – die Linie sieht auf dem Papier besser aus, als sie läuft.
• Umwelt: Das Arbeitsplatzlayout verursacht lange Laufwege; beengte Platzverhältnisse verlangsamen die Materialversorgung.

Typisch ist dabei: Die spannendste Spur liegt selten dort, wo die Diskussion beginnt.

Vier Fehler, die den Nutzen kosten

• Symptome in den Ästen. „Zu viel Ausschuss“ ist eine Wirkung. In die Äste gehört, was ihn erzeugt.
• Namen in den Ästen. Sobald es um Personen geht, endet die ehrliche Ursachensuche.
• Keine Bewertung. Ein Diagramm mit vierzig Einträgen ohne Priorisierung ist eine Materialsammlung. Analysiert hat damit noch niemand.
• Keine Wiedervorlage. Tritt dasselbe Problem in drei Monaten erneut auf, beginnt das Team von vorn, weil niemand weiß, was beim letzten Mal schon geprüft wurde.

Und eine Grenze der Methode sollte man kennen: Bei komplexen Problemen mit vernetzten Ursachen wird die Fischgräte schnell unübersichtlich, und Rückkopplungen zwischen Ursachen kann sie nicht darstellen. Dann sind Pareto-Analyse, Fehlerbaum oder ein statistischer Versuchsplan die besseren Werkzeuge.

Ishikawa, 5-Why und Pareto: Wer macht was?

• Mit Ishikawa sammelt das Team mögliche Ursachen in der Breite, über alle Kategorien.
• Mit 5-Why verfolgt es eine Ursache in die Tiefe, bis zum Kern. Mehr dazu im Artikel zur 5-Why-Methode.
• Pareto priorisiert: Welche Fehlerart kostet am meisten Häufigkeit, Zeit oder Geld?

Eine bewährte Reihenfolge im Shopfloor-Meeting: Pareto zeigt, welches Problem es wert ist, mit Ishikawa sammelt das Team die Kandidaten, mit 5-Why gräbt es an der wahrscheinlichsten Stelle nach.

Vom Diagramm zur Maßnahme

Die Ursachenanalyse ist ein Schritt in einem größeren Ablauf – im PDCA-Zyklus ebenso wie im 8D-Report, wo sie als eigener Schritt vor den Abstell- und Vorbeugemaßnahmen steht. Drei Dinge entscheiden, ob aus der Analyse etwas wird: eine verifizierte Ursache, eine Maßnahme mit Verantwortlichem und Termin, und eine Wirksamkeitsprüfung nach ein paar Wochen. Wer was bis wann umsetzt, gehört in die tägliche Routine – etwa auf ein Shopfloor-Teammeeting-Board.

Was nach dem Meeting übrig bleibt

Am Flipchart entsteht eine gute Analyse in zwanzig Minuten – und verschwindet danach im Handy-Foto eines Teilnehmers. Ein digitales Board ändert daran zwei Dinge: Die Analyse bleibt auffindbar, und beim nächsten Auftreten desselben Problems lässt sie sich fortsetzen. Wie das am Shopfloor aussieht, zeigt das interaktive Ishikawa-Board: Ursachen werden am Display eingegeben, den sechs Kategorien zugeordnet und gespeichert.

Im Template liegen Problemstellung und Ursachen in Listen im Peakboard Hub. Genauso lassen sich andere Datenquellen anbinden, etwa SQL, Oracle oder ODBC.

Der Rest bleibt Handarbeit im besten Sinn: hingehen, nachsehen, nachfragen. Das Werkzeug strukturiert die Diskussion – führen muss sie das Team.