5-Why-Methode: Ablauf, Beispiel und Grenzen in der Produktion

Die 5-Why-Methode fragt bei einem Problem so lange nach dem Warum, bis die Grundursache erreicht ist. Sie ist in zehn Minuten erklärt und wird trotzdem oft falsch angewendet – meist, weil die Kette nach der ersten plausiblen Antwort abbricht.

Woher die Methode kommt

Die American Society for Quality führt die Technik auf Sakichi Toyoda zurück. Beschrieben hat sie Taiichi Ohno, der Architekt des Toyota-Produktionssystems. In seinem Buch Toyota Production System: Beyond Large-Scale Production (Productivity Press, 1988) steht das wiederholte Fragen nach dem Warum als Grundlage des wissenschaftlichen Vorgehens bei Toyota: Erst das mehrfache Nachfragen führe zur wirklichen Ursache, die sich hinter den offensichtlichen Symptomen verberge.

Sein bekanntes Beispiel ist eine Maschine, die stehen bleibt. Warum steht sie? Es gab eine Überlast, die Sicherung brannte durch. Warum die Überlast? Das Lager war nicht ausreichend geschmiert. Warum war es nicht ausreichend geschmiert? Die Schmierpumpe förderte zu wenig. Warum förderte sie zu wenig? Ihre Welle war verschlissen und schlug. Warum war die Welle verschlissen? Es war kein Sieb eingebaut, und Metallspäne gelangten hinein. Wer bei der ersten Antwort stehen bleibt, tauscht die Sicherung aus. Die Späne gelangen weiter in die Pumpe, und der Stillstand wiederholt sich.

Der Ablauf in der Praxis

1. Problem beschreiben. Konkret, mit Ort, Zeit und Ausmaß. „Montagelinie 2 steht seit 30 Minuten wegen eines fehlenden Gehäuseteils“ ist ein brauchbarer Ausgangspunkt. Mit „Materialprobleme“ kommt das Team keinen Schritt weiter.
2. Erste Warum-Frage stellen. Warum ist das Problem aufgetreten? Die Antwort muss ein Fakt sein. Wenn niemand es weiß, ist das Ergebnis dieser Runde eine Aufgabe: nachsehen.
3. Nach jeder Antwort weiterfragen. Die Antwort der ersten Frage wird zur Frage der zweiten. So entsteht eine Kette.
4. Aufhören, wenn die Ursache im Prozess liegt. Die letzte Zeile sollte etwas benennen, das dein Team ändern kann: einen Arbeitsablauf, eine Regel, eine fehlende Prüfung. Endet die Kette bei „jemand hat es vergessen“, fehlt noch ein Schritt. Die nächste Frage lautet dann, warum das Vergessen überhaupt bis zum Stillstand durchkommen konnte – etwa weil eine Rückmeldung fehlt oder ein Arbeitsschritt ohne Kontrolle bleibt.
5. Gegenprobe machen. Die Kette rückwärts mit „deshalb“ lesen. Klingt ein Schritt dabei konstruiert, sollte er noch einmal geprüft werden.
6. Maßnahme ableiten und Wirksamkeit prüfen. Für jede Maßnahme Verantwortlichkeit und Termin festlegen und nach einigen Wochen nachsehen, ob das Problem seitdem ausgeblieben ist.

Ein zweites Beispiel, aus der Montage

Problem: Montagelinie 2 steht seit 30 Minuten wegen eines fehlenden Gehäuseteils.

1. Warum ist das Problem aufgetreten? Der Routenzug hat das Material nicht rechtzeitig an die Linie geliefert.
2. Warum ist das geschehen? Der Fahrauftrag wurde im Lager nicht ausgedruckt.
3. Warum ist das geschehen? Das System führte den Bestand auf einem anderen Lagerplatz – am Bereitstellplatz galt das Teil damit als nicht vorhanden.
4. Warum ist das geschehen? Der Wareneingang hat die Palette manuell umgelagert, im ERP-System aber nicht umgebucht.
5. Warum ist das geschehen? Das Scangerät am Wareneingang war defekt, und der Prozess sah keine sofortige Erfassung auf anderem Weg vor.

Als Hauptursache steht damit ein fehlender Fallback-Prozess beim Ausfall mobiler Datenerfassungsgeräte. Die Maßnahme gehört an den Wareneingang: ein festgelegter Ersatzweg für die Erfassung, solange ein Gerät ausfällt. An der Montagelinie selbst hätte keine Maßnahme etwas geändert.

Warum ausgerechnet fünf?

Weil es sich als Faustregel bewährt hat. Ein Gesetz ist es nicht. Das Lean Enterprise Institute stellt in seinem Lean Lexicon ausdrücklich klar: „The specific number five is not the point. Rather it is to keep asking until the root cause is reached and eliminated.“ Manche Ketten sind nach drei Fragen zu Ende, andere brauchen sieben. Wer die fünfte Zeile füllt, weil das Formular fünf Zeilen hat, betreibt Formularpflege.

Wo die Methode an Grenzen stößt

Zwei Einwände hört man in der Praxis immer wieder:

• Die Antworten sind subjektiv. Zwei Teams kommen beim selben Problem zu verschiedenen Ketten, wenn niemand die Antworten am Prozess prüft.
• Fünf Fragen sind keine Garantie. Die Kette kann enden, bevor die Grundursache erreicht ist.

Keiner der beiden Punkte spricht gegen die Methode. Sie sind der Grund, warum eine 5-Why-Analyse ohne Verifikation nichts wert ist: Wenn fünf Leute nicken und niemand nachgesehen hat, war es keine Analyse.

Typische Denkfehler am Shopfloor

• Ein Name in der Zeile. Steht in einer Antwort eine Person, ist die Kette dort zu Ende gedacht: Ein Name erklärt nicht, warum der Fehler möglich war. Weiter geht es mit der Frage, welcher Schritt im Ablauf ihn zugelassen hat – eine Einweisung, die fehlt, eine Prüfung, die niemand vorgesehen hat, zwei Teile, die sich verwechseln lassen.
• Springen zwischen Ebenen. Eine Kette, die von der Maschine zur Unternehmenskultur springt, hat eine Lücke. Als Probe hilft die Frage, ob zwischen Antwort und Folgefrage noch eine weitere Antwort passt. Passt eine, gehört sie eingefügt.
• Mehrere Stränge in einer Kette. Wenn zwei Ursachen zusammenwirken, brauchst du zwei Ketten – oder ein Ishikawa-Diagramm davor, das die Breite sortiert.
• Die Analyse verschwindet. Auf Papier notiert, im Ordner abgelegt, beim nächsten Mal nicht auffindbar. Dann beginnt das Team wieder von vorn.

Wohin die Analyse gehört

Im 8D-Report ist die Ursachenanalyse ein eigener Schritt vor den Abstell- und Vorbeugemaßnahmen, im PDCA-Zyklus steckt sie im „Plan“, und in der täglichen Shopfloor-Routine gehört sie an die Stelle, an der das Problem sichtbar wird. Wichtig ist, was danach passiert: Die Maßnahme braucht einen Verantwortlichen und einen Termin, nachzuhalten etwa im Shopfloor-Teammeeting-Board.

Dokumentieren, damit Muster sichtbar werden

Der größte Hebel liegt in der Sammlung: Liegen zum Beispiel zwanzig Analysen nebeneinander, fällt auf, wenn dieselbe Grundursache mehrfach auftaucht. Genau dafür ist die digitale 5-Why-Analyse gebaut: Problem, Warum-Kette und Hauptursache werden am Display erfasst, abgeschlossene Analysen bleiben mit Datum in einer Übersicht.

Im Template liegen alle Analysen in einer Liste im Peakboard Hub. Genauso lassen sich andere Datenquellen anbinden, etwa SQL, Oracle oder ODBC.