Ursachenanalyse in der Produktion: 5 Whys und Ishikawa-Diagramm in der Praxis

Von Mirko Peters · 2026-11-11

Ursachenanalyse in der Produktion Schritt für Schritt: wann Sie die 5 Whys oder ein Fishbone-Diagramm einsetzen, wie Sie eine Ursache verifizieren, und ein durchgerechnetes Beispiel zu Stillstandszeiten mit Zahlen.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Die Ursachenanalyse (Root Cause Analysis, RCA) findet die eigentliche Ursache eines Problems, damit die Behebung verhindert, dass es wiederkommt. In der Produktion sind die 5 Whys und das Fishbone-Diagramm die gängigen Werkzeuge. Dieser Artikel richtet sich an Produktionsleiter, die Linienprobleme heute lösen und dauerhaft gelöst halten müssen. Sie erhalten eine klare Routine, eine Orientierung zur Wahl zwischen beiden Werkzeugen, ein durchgerechnetes Beispiel zu Stillstandszeiten mit Zahlen und eine Liste typischer Fehler.

Die wichtigsten Punkte

• Die Ursachenanalyse findet die eigentliche Ursache eines Problems, sodass die Behebung ein erneutes Auftreten verhindert, statt nur ein Symptom zu behandeln.
• Verwenden Sie die 5 Whys für eine klare Ursache-Wirkungs-Kette und setzen Sie zuerst ein Fishbone-Diagramm ein, wenn mehrere Ursachen zusammenwirken könnten.
• Jedes Warum muss mit einer beobachteten Tatsache oder gemessenen Daten beantwortet werden, nicht mit einer Hypothese, und die Ursache muss vor der Maßnahme verifiziert sein.
• Beginnen Sie mit den größten Verlusten, anhand einer Pareto-Auswertung, und priorisieren Sie den Engpass, an dem verlorene Zeit die gesamte Linie kostet.
• Eine Maßnahme gilt erst als bewiesen, wenn die Kontrolle zeigt, dass das Problem nicht zurückgekehrt ist. Führen Sie sie daher als kleinen PDCA-Versuch durch.

Was ist Ursachenanalyse in der Produktion?

iSixSigma beschreibt die Ursachenanalyse als Weg, die eigentliche Quelle eines Prozess- oder Produktfehlers zu identifizieren. Empfohlen wird, mit einer sachlichen Problembeschreibung zu beginnen: das fehlerhafte Produkt oder der fehlerhafte Prozess, die Beobachtungen, die Anzahl der fehlerhaften Einheiten und die Beschreibung durch den Kunden. Den Artikel zu Ishikawa-Diagrammen und den 5 Whys finden Sie dort.

Drei Begriffe werden leicht verwechselt:

• Eindämmung schützt heute den Kunden oder die Linie, etwa durch Aussortieren verdächtiger Teile. Sie beseitigt die Ursache nicht.
• Korrekturmaßnahme ist die Änderung, die die Ursache beseitigt.
• Grundursache ist die Ursache, die, once beseitigt, ein erneutes Auftreten unter ähnlichen Bedingungen verhindert.

Wenn Sie nur eindämmen, kehren derselbe Fehler oder Stillstand zurück. Wenn Sie ohne verifizierte Ursache direkt zur Korrekturmaßnahme springen, beheben Sie möglicherweise das Falsche. Die Ursachenanalyse liegt dazwischen.

Wann verwenden Sie die 5 Whys?

Das ASQ-Glossar beschreibt die Five Whys als Technik, bei der wiederholt nach dem „Warum?“ gefragt wird. Sie wird typischerweise etwa fünfmal angewendet, weniger oder mehr ist aber akzeptabel. Als Entwickler wird Sakichi Toyoda genannt. Die Regeln sind praxisnah:

1. Formulieren Sie eine präzise Problembeschreibung, die durch Daten gestützt ist.
2. Fragen Sie, warum das Problem aufgetreten ist, und halten Sie die nächstliegende beobachtbare Ursache fest.
3. Fragen Sie bei jeder Antwort erneut nach dem Warum und bleiben Sie dabei bei den Fakten.
4. Hören Sie bei einer Ursache auf, auf die Sie handeln können, um ein erneutes Auftreten zu verhindern.
5. Verifizieren Sie die Grundursache: Führt sie tatsächlich zum Problem, und würde ihre Beseitigung das Problem verhindern?
6. Setzen Sie eine Gegenmaßnahme um und bestätigen Sie durch eine Nachmessung, dass das Problem nicht wiederkehrt.

Dieselbe Seite merkt an, dass jede Antwort „eine beobachtete Tatsache oder ein gemessener Datenpunkt, keine Hypothese“ sein sollte. Außerdem heißt es, die Methode funktioniere am besten bei linearen Ursache-Wirkungs-Ketten mit einer Grundursache, und für komplexe Probleme wird ein Fishbone-Diagramm empfohlen.

Wann ist ein Fishbone-Diagramm besser?

Ein Fishbone- oder Ishikawa-Diagramm ist eine Darstellung von Hypothesen. Der Effekt, etwa „Kurzschüsse an Presse 3“, steht am Kopf, und die Äste zeigen mögliche Ursachen. Teams gruppieren die Äste oft nach Maschine, Methode, Material, Mensch, Messung und Umwelt. Das Diagramm hilft dem Team, viele mögliche Ursachen gleichzeitig zu sehen und sich darauf zu einigen, welche es prüfen will.

iSixSigma empfiehlt eine klare Reihenfolge für den Einsatz der Werkzeuge: Zuerst formulieren Sie die Problembeschreibung und sammeln Daten. Dann erstellen Sie das Diagramm aus Hypothesen, die beobachtbare Effekte beschreiben. Anschließend wenden Sie die 5 Whys auf die wahrscheinlichsten Äste an und verfolgen jede Hypothese mit einem verantwortlichen Owner und einem Fälligkeitsdatum. Das Vorgehen warnt außerdem, dass im Brainstorming entstandene Diagramme oft Ursachen enthalten, die nichts beitragen, und dass vage Kategorien wie „Beleuchtung“ selten einen Weg zum Fehler aufzeigen.

Faustregel: Gibt es eine einzige, klare Kette, reichen die 5 Whys. Mehrere mögliche Einflussfaktoren oder ein Team, das sich uneinig ist, sprechen für ein Fishbone-Diagramm zuerst.

Viele Produktionsprobleme haben mehr als eine Grundursache. Ein kurzer Stopp kann gleichzeitig durch ein verschlissenes Teil, eine fehlende Prüfung und eine Lücke in der Schulung entstehen. Wenn Sie die Grundursache bestimmen, fragen Sie sich, ob Sie eine der Grundursachen oder alle gefunden haben. Ein Problem gut zu definieren ist die halbe Antwort: Eine enge Beschreibung wie „Stopps an Station 3 in der Nachtschicht“ führt zu weniger möglichen Ursachen als eine weite. Um die Grundursache eines wiederkehrenden Fehlers zu ermitteln, vergleichen Sie gute und fehlerhafte Läufe und listen auf, was sich unterscheidet. Setzen Sie anschließend Korrekturmaßnahmen für jede verifizierte Ursache einzeln um, damit Sie erkennen, welche wirkt. Das ist schlichte Problemlösung: erst Fakten, dann Hypothesen, zuletzt Maßnahmen.

Wie führen Sie eine RCA an der Linie durch?

1. Eindämmen. Schützen Sie zuerst den Kunden und die Linie. Sperren Sie verdächtiges Produkt und stellen Sie einen sicheren Zustand her.
2. Problem auswählen. Analysieren Sie nicht alles. Nutzen Sie eine Pareto-Auswertung, also eine Rangliste der Verluste von groß nach klein, und nehmen Sie den größten Posten. Schauen Sie zuerst auf den Engpass, den Schritt, der die Ausbringung begrenzt. Eine Minute, die dort verloren geht, fehlt der ganzen Linie. Eine Minute an einem Schritt mit freier Kapazität kostet dagegen unter Umständen nichts.
3. Mit Daten definieren. Was, wo, wann, wie viel, verglichen womit? Geben Sie dem Problem eine Zahl.
4. Hingehen und ansehen. Betrachten Sie den realen Prozess am Gemba, dem japanischen Wort für „den realen Ort“, also dem Shopfloor. Sprechen Sie mit den Bedienern, die dabei waren.
5. Mögliche Ursachen finden. Nutzen Sie die 5 Whys oder ein Fishbone-Diagramm mit einem bereichsübergreifenden Team aus Bediener, Instandhaltung, Qualität und einem Schichtleiter.
6. Verifizieren. Prüfen Sie die wahrscheinlichste Ursache. Ist sie real, muss ihre Beseitigung das Ergebnis verändern, und ihre Rückkehr muss das Problem wieder auslösen.
7. Umsetzen und prüfen. Führen Sie die Gegenmaßnahme als kleinen Versuch durch und messen Sie das Ergebnis. Der PDCA-Zyklus gibt diesem Schritt seine Struktur, und ein A3-Bericht kann die gesamte Geschichte auf einer Seite festhalten.

Beispiel: Stillstand auf einer Linie

Dieses Beispiel verwendet angenommene Zahlen.

Linie 4 läuft an 5 Tagen in zwei Schichten zu je 8 Stunden, also 80 geplante Stunden. Letzte Woche verlor sie 14 Stunden durch Stopps, das entspricht 14 ÷ 80 = 17,5 %.

Pareto der Stopps:

• Fehlerhafte Sensorerkennung: 6,3 h (45 %)
• Überschreitung beim Rüsten: 4,2 h (30 %)
• Warten auf Material: 2,1 h (15 %)
• Sonstiges: 1,4 h (10 %)

Die beiden größten Ursachen machen 75 % des Verlusts aus. Das Team beginnt mit den fehlerhaften Sensorerkennungen.

5 Whys.

1. Warum stand die Linie? Der Sensor hat die Position des Teils falsch erkannt.
2. Warum? Auf der Sensorlinse lag Staub.
3. Warum lag Staub darauf? Während der Schicht reinigt niemand die Linse.
4. Warum nicht? Die Reinigung gehört nicht zur Standardarbeit des Bedieners.
5. Warum nicht? Die Standardarbeit wurde geschrieben, bevor der Sensor installiert wurde.

Die Grundursache ist eine Lücke in der Standardarbeit, kein defekter Sensor. Die Gegenmaßnahme besteht darin, eine Linsenprüfung in die Routine zu Schichtbeginn aufzunehmen und eine kleine Abdeckung anzubringen.

Erwartete Wirkung. Entfällt dadurch 80 % der Sensorstopps, ergibt das 6,3 × 0,8 = 5,04 Stunden. Die neue Stillstandszeit beträgt 14 − 5,04 = 8,96 Stunden, also 8,96 ÷ 80 = 11,2 %. Die Prüfung nach zwei Wochen zeigt, ob das reale Ergebnis übereinstimmt. Falls nicht, kehrt das Team zum Diagramm zurück.

Wie stellen Sie sicher, dass die Ursache die richtige ist?

Testen Sie den Befund, bevor Sie in eine Lösung investieren. Zwei einfache Fragen helfen dabei:

• Wenn die Ursache, die Sie identifiziert haben, eine andere wäre, würde dann auch das Ergebnis anders ausfallen?
• Wenn Sie sie beseitigen, ist es dann unwahrscheinlich, dass sich derselbe Fehler unter ähnlichen Bedingungen wiederholt?

Erfassen Sie Daten vorher und nachher. Eine gute Ursachenanalyse endet mit einem gemessenen Ergebnis und einem geänderten Standard. Nur so fließt sie in kontinuierliche Verbesserung ein, statt in Feuerwehreinsätzen zu enden. Halten Sie außerdem Einflussfaktoren fest, die Sie nicht behoben haben, etwa Schulung oder Werkzeuge, damit sie nicht verloren gehen.

Seien Sie vorsichtig mit „menschlichem Versagen“. Es ist selten eine Grundursache. Wenn ein Bediener einen Fehler gemacht hat, fragen Sie, warum der Prozess diesen Fehler zugelassen hat: War die Anweisung klar, war das Werkzeug geeignet, war genug Zeit vorhanden? Die Antwort liegt fast immer im System.

Häufige Fehler

• Beim ersten Warum aufhören. Die erste Antwort ist meist nur das Symptom.
• Mit Meinungen antworten. Jedes Warum braucht einen beobachteten Fakt oder eine Messung.
• Menschen beschuldigen. Schuldzuweisungen beenden das Gespräch und verdecken die eigentliche Ursache.
• Zuerst kleine Probleme analysieren. Nutzen Sie eine Pareto-Betrachtung und beginnen Sie mit dem größten Verlust.
• Verifizierung überspringen. Eine ungeprüfte Ursache führt zu einer Maßnahme, die nicht wirkt.
• Den Standard nicht ändern. Bleibt die Standardarbeit gleich, kehrt das Problem zurück.

Wie Software helfen kann

Eine gute Analyse braucht gute Daten. Software kann den Grund für jeden Stillstand im Moment seines Auftretens erfassen, Pareto-Diagramme automatisch erstellen und zeigen, ob ein Problem nach der Maßnahme wiederkehrt. Das spart in den ersten Schritten der Ursachenanalyse Zeit und gibt dem Team Fakten statt Erinnerungen. Ein Werkzeug denkt allerdings nicht für Sie. Die Menschen müssen weiterhin an den Ort des Geschehens gehen und nach dem Warum fragen.

Nächster Schritt

Nehmen Sie den größten Verlust der letzten Woche auf Ihrer Linie, formulieren Sie eine Problembeschreibung mit einer Kennzahl und führen Sie die 5 Warum-Fragen mit den Bedienern durch, die dabei waren. Prüfen Sie die Ursache anschließend mit einem kleinen Versuch. So wenden Sie die Ursachenanalyse in Ihrer Produktion praktisch an.