5 Whys: Methode zur Ursachenanalyse (mit Beispielen)

Die 5-Whys-Technik ist eines der einfachsten und zugleich wirkungsvollsten Werkzeuge der Prozessverbesserung. Sie formulieren ein Problem, fragen "warum" es aufgetreten ist, fragen dann erneut "warum" zu Ihrer ersten Antwort und machen so lange weiter, bis Sie bei der eigentlichen Ursache statt beim Symptom ankommen. Die meisten Teams erreichen das nach fünf Durchgängen. Manche brauchen nur drei. Ein paar benötigen wirklich sechs oder sieben.

Das Bemerkenswerte daran ist nicht die Zahl. Es ist die Disziplin, sich nicht mit der ersten bequemen Antwort zufriedenzugeben.

Was sind die 5 Whys?

Die 5 Whys sind eine Technik zur Ursachenanalyse, die mit wiederholtem Nachfragen ein Problem bis zu seinem Ursprung zurückverfolgt. Sie beginnen mit einer klar definierten Problembeschreibung und fragen wiederholt "warum ist das passiert?", bis Sie das zugrunde liegende systemische Versagen aufdecken statt eines oberflächlichen Symptoms.

Die Methode wurde von Sakichi Toyoda, dem Gründer von Toyota Industries, zu Beginn des 20. Jahrhunderts entwickelt. Unter Taiichi Ohno wurde sie in den 1950er- und 1960er-Jahren fester Bestandteil des Toyota-Produktionssystems (TPS). Ohno bezeichnete die 5 Whys als eine der zentralen Praktiken, die es Toyota ermöglichten, Qualität direkt in den Fertigungsprozess einzubauen, statt Fehler erst im Nachhinein zu prüfen. Heute ist sie ein Standardwerkzeug in der Lean-Methodik, im DMAIC-Rahmenwerk von Six Sigma und praktisch in jedem System für kontinuierliche Verbesserung.

Die Technik erfordert keine Software, keine statistische Ausbildung und keine spezielle Zertifizierung. Genau diese Zugänglichkeit ist der Grund, warum sie sich seit über 70 Jahren sowohl auf Fabrikböden als auch in Vorstandsetagen gehalten hat.

Wichtige Fakten

• Taiichi Ohno, der Vater des Toyota-Produktionssystems, schrieb 1988 in seinem Buch Toyota Production System: Beyond Large-Scale Production, dass sich durch fünfmaliges Nachfragen nach dem Warum sowohl die Natur des Problems als auch seine Lösung klären. Diese Formulierung gilt beim Lean Enterprise Institute bis heute als die kanonische Beschreibung der Technik.
• Die American Society for Quality (ASQ) führt die 5 Whys in ihrem Body of Knowledge für Certified Quality Engineers und listet sie neben dem Fishbone-Diagramm und der Pareto-Analyse als eines der zentralen Werkzeuge für die Analyze-Phase.
• Eine Umfrage des Lean Enterprise Institute aus dem Jahr 2021 ergab, dass über 65 % der Organisationen, die Lean-Praktiken eingeführt haben, die 5 Whys nutzen, was sie zum am weitesten verbreiteten einzelnen Ursachenanalyse-Werkzeug im Operations-Management macht.

5 Whys vs. Fishbone-Diagramm vs. 8D

Diese drei Werkzeuge werden oft in einem Atemzug genannt. Sie sind verwandt, aber nicht austauschbar. Das falsche Werkzeug zu wählen, kostet Zeit und liefert oberflächliche Schlussfolgerungen.

Nutzen Sie die 5 Whys, wenn Sie schnell eine Antwort brauchen und das Problem klar eingegrenzt ist. Nutzen Sie ein Fishbone-Diagramm, wenn unklar ist, welche Ursachenkategorie das Problem treibt, und Sie eine Struktur zum Brainstorming brauchen. Nutzen Sie 8D-Problemlösung, wenn das Problem formale Dokumentation, Sofortmaßnahmen und eine Verifizierung über Abteilungsgrenzen hinweg erfordert.

Die 5 Whys und das Fishbone-Diagramm ergänzen sich tatsächlich gut. Viele Teams nutzen zunächst das Fishbone-Diagramm, um den Möglichkeitsraum abzustecken, und wenden dann die 5 Whys auf den wahrscheinlichsten Ast an.

Vorteile der 5 Whys

Geschwindigkeit. Ein kleines Team kann eine 5-Whys-Analyse in unter einer Stunde abschließen. Bei betrieblichen Problemen, die aktiv Geld kosten oder Verzögerungen verursachen, zählt diese Geschwindigkeit.

Zugänglichkeit. Sie brauchen keinen Statistiker und keinen zertifizierten Black Belt, um eine 5-Whys-Sitzung zu moderieren. Jede Teamleitung, die das Problem versteht, kann sie durchführen.

Fokus auf Systeme, nicht auf Personen. Richtig angewendet, lenkt die 5-Whys-Methode die Untersuchung weg von menschlichem Versagen als Ursache und hin zu dem Prozess, System oder der Richtlinie, die den Fehler überhaupt erst ermöglicht hat. Eine Person verantwortlich zu machen, verhindert keine Wiederholung. Einen kaputten Prozess zu reparieren schon.

Integration mit anderen Werkzeugen. Die 5 Whys fügen sich nahtlos in die Analyze-Phase von DMAIC, die Plan-Stufe von PDCA und in Kaizen-Events ein. Es ist eine modulare Technik, keine eigenständige Methodik.

Klarheit bei Gegenmaßnahmen. Weil die 5 Whys bei einer konkreten Grundursache enden, ist die Korrekturmaßnahme meist offensichtlich. Genau das ist der Sinn der Übung. Wenn Ihre Antwort vage bleibt, sind Sie nicht weit genug gegangen.

Häufige Fehler und Grenzen

Die 5 Whys sind einfach. Genau diese Einfachheit ist auch ihre größte Schwachstelle.

Zu früh aufhören. Der häufigste Fehler ist, ein Symptom als Ursache zu akzeptieren. "Die Maschine ist ausgefallen" ist ein Symptom. "Die Maschine ist ausgefallen, weil der Wartungsplan aus Kostengründen gekürzt wurde" ist eine Grundursache. Teams unter Zeitdruck akzeptieren die erste plausible Antwort und machen weiter. Das Problem kommt zurück.

Nur einem Pfad folgen. Reale Probleme haben oft mehrere Mitursachen, die sich auf jeder Ebene verzweigen. Eine strikte, einsträngige Analyse übersieht parallele Fehlerursachen. Zeichnen Sie bei komplexen Problemen die Kette als Baum, nicht als Linie.

Personen statt Prozesse verantwortlich machen. Wenn Ihre fünfte Warum-Antwort lautet "weil Bob den Bericht nicht geprüft hat", haben Sie keine Grundursache gefunden. Sie haben eine Person zum Sündenbock gemacht. Fragen Sie weiter. Warum gab es kein System, das die Prüfung automatisch sichergestellt hätte? Warum wurde Bob nicht geschult? Warum war Bob der einzige Ausfallpunkt?

Sich auf Erinnerung und Vermutung verlassen. Die 5 Whys funktionieren am besten mit Daten, nicht mit Erinnerungen. Wenn Teams Ereignisse aus dem Gedächtnis rekonstruieren, bringen sie Verzerrungen ein und übersehen, was tatsächlich passiert ist. Kombinieren Sie die Methode wann immer möglich mit Beobachtung, Datenprotokollen oder einem Prozess-Walkthrough.

Anwendung bei komplexen Ausfällen über mehrere Systeme hinweg. Wenn ein Problem fünf Abteilungen, drei Softwaresysteme und zwei Aufsichtsbehörden betrifft, erfasst eine 5-Whys-Sitzung im Besprechungsraum das nicht. Dafür braucht es ein Fishbone-Diagramm mit anschließender statistischer Analyse, kein iteratives Nachfragen.

So nutzen Sie die 5 Whys (Schritt für Schritt)

Schritt 1: Das Problem klar definieren

Formulieren Sie das Problem als konkrete, beobachtbare Aussage. Vage Problembeschreibungen führen zu vagen Grundursachen. "Der Umsatz ist gesunken" ist keine Problembeschreibung. "Fehler bei der Auftragsabwicklung stiegen im zweiten Quartal um 23 % und führten zu 48 Kundenbeschwerden" ist eine.

Halten Sie fest, was passiert ist, wo es passiert ist, wann es zum ersten Mal auffiel und wie groß die messbare Auswirkung ist. Dieser Schritt kostet fünf Minuten. Er spart später Stunden.

Schritt 2: "Warum ist das passiert?" fragen (Warum 1)

Konzentrieren Sie sich auf die Problembeschreibung. Notieren Sie die unmittelbare Ursache, die Erklärung der ersten Ebene für das Beobachtete. Bleiben Sie faktenbasiert. Diese Antwort sollte überprüfbar sein, nicht angenommen.

Schritt 3: Zur ersten Antwort erneut "Warum?" fragen (Warum 2)

Nehmen Sie die soeben dokumentierte Ursache und fragen Sie, warum diese aufgetreten ist. Sie fragen jetzt nicht mehr nach dem ursprünglichen Problem, sondern nach der in Schritt 2 identifizierten Ursache. Notieren Sie die Antwort.

Schritt 4: Weiter "Warum?" fragen (Warum 3-5)

Wiederholen Sie den Prozess mit jeder neuen Antwort. Fragen Sie sich auf jeder Ebene: Ist das wirklich die Ursache, oder immer noch ein Symptom? Machen Sie weiter, bis eine dieser Bedingungen zutrifft. Erstens: Die Antwort zeigt ein Prozess-, Richtlinien- oder Systemversagen, das sich tatsächlich beheben lässt. Zweitens: Sie haben einen Punkt erreicht, an dem Sie keinen Einfluss mehr auf die Ursache haben (externe Vorschriften, physikalische Gesetze, feste Rahmenbedingungen). Drittens: Die Antwort zeigt eine Ressourcen- oder Wissenslücke, die eine eigene Untersuchung erfordert.

Erzwingen Sie nicht genau fünf Durchgänge. Hören Sie auf, sobald Sie den wahren Ursprung erreicht haben. Gehen Sie über fünf hinaus, wenn Sie immer noch Symptome beschreiben.

Schritt 5: Die Grundursache identifizieren

Das letzte "Warum", dem Ihr Team zustimmt, dass es umsetzbar und systemisch ist, ist Ihre Grundursache. Halten Sie sie ausdrücklich schriftlich fest. Gehen Sie die Kette vom Problem bis zur Grundursache laut durch, um sicherzustellen, dass sie bei jedem Schritt logisch schlüssig ist.

Schritt 6: Eine Gegenmaßnahme festlegen und verifizieren

Weisen Sie der Grundursache eine konkrete Korrekturmaßnahme zu, nicht einem Symptom weiter oben in der Kette. Legen Sie ein Zieldatum fest. Bestimmen Sie einen Verantwortlichen. Prüfen Sie nach der Umsetzung, ob das ursprüngliche Problem nicht mehr auftritt. Tritt es erneut auf, war Ihre Ursachenkette unvollständig. Graben Sie tiefer.

Beispiele für die 5 Whys

Fertigung: Maschinenstillstand

Hier ein vollständig durchgerechnetes Beispiel aus einer Produktionsumgebung.

Den Motor auszutauschen (das Symptom) hätte 1.200 US-Dollar und zwei Wochen Lieferzeit gekostet. Die Checkliste zu aktualisieren dauerte 20 Minuten.

Softwareentwicklung: Systemausfall

Eine SaaS-Plattform erlebt einen kritischen Ausfall, der 2.000 Kunden betrifft.

• Warum 1: Dem primären Datenbankserver ging der Speicherplatz aus.
• Warum 2: Ein Batch-Job schrieb unkomprimierte Logdateien auf das Datenbankvolume.
• Warum 3: Der Batch-Job war standardmäßig so konfiguriert, und niemand hatte das geändert.
• Warum 4: Es gab keine Pflicht zum Code-Review für Batch-Job-Konfigurationen.
• Warum 5: Der Deployment-Prozess markiert Konfigurationsdateien außerhalb der Anwendung nicht für eine verpflichtende Prüfung.

Grundursache: Lücke im Deployment-Prozess. Konfigurationsdateien unterliegen nicht denselben Prüf-Gates wie Anwendungscode. Gegenmaßnahme: Deployment-Pipeline aktualisieren, sodass alle Konfigurationsänderungen ein Engineering-Review durchlaufen müssen. Speicherplatz-Warnung bei 70 % Auslastung einführen.

Kundenservice: Beschwerdespitze

Ein Abo-Softwareunternehmen verzeichnet in der ersten Woche des Monats einen Anstieg abrechnungsbezogener Support-Tickets um 30 %.

• Warum 1: Kunden sind über unerwartete Belastungen auf ihren Rechnungen verunsichert.
• Warum 2: Eine Änderung der Preisstufe ging live, ohne dass die In-App-Abrechnungsbeschreibung aktualisiert wurde.
• Warum 3: Produkt und Finanzabteilung aktualisierten die Preis-Engine, ohne das UX-Team zu informieren.
• Warum 4: Es gibt keine funktionsübergreifende Checkliste für Preisänderungen, die ein UX-Review einschließt.

Grundursache: Fehlender Schritt im Prozess für Preisänderungen. Gegenmaßnahme: Ein Runbook für Preisänderungen erstellen, das vor jeder Live-Schaltung eine Freigabe durch UX, Finanzabteilung und Customer Success verlangt.

Best Practices, um das Beste aus den 5 Whys herauszuholen

Die richtigen Personen einbeziehen. Beziehen Sie Personen ein, die dem Ausfall am nächsten standen, sowie Personen, die die vorgelagerten Systeme verstehen. Führen Sie die 5 Whys nicht nur mit Führungskräften durch, die nicht vor Ort waren.

Eine moderierende Person einsetzen. Jemand muss das Team ehrlich halten, vage Antworten hinterfragen und sicherstellen, dass jedes "Warum" logisch aus dem vorherigen folgt. Die moderierende Person sollte nicht diejenige sein, die am meisten an einem bestimmten Ergebnis hängt.

Die Kette visuell dokumentieren. Schreiben Sie jeden Schritt auf ein Whiteboard oder ein gemeinsames Dokument, damit die gesamte Kette sichtbar ist. Teams treffen bessere Entscheidungen, wenn sie den Logikfluss vom Problem bis zur Grundursache sehen können.

Jede Antwort hinterfragen. Fragen Sie bei jedem Schritt "Woher wissen wir, dass das stimmt?". Eine plausible Vermutung ist keine verifizierte Ursache. Wenn Sie eine Antwort nicht mit Daten oder direkter Beobachtung bestätigen können, markieren Sie sie als Annahme und validieren Sie sie, bevor Sie die Kette abschließen.

Gegenmaßnahmen an Grundursachen knüpfen, nicht an Symptome. Wenn Ihre Gegenmaßnahme bei Warum 2 statt bei Warum 5 ansetzt, haben Sie einen Workaround gebaut, keine Lösung. Workarounds verschleiern Probleme. Maßnahmen an der Grundursache beseitigen sie.

Nachverfolgen. Die 5 Whys sind nur nützlich, wenn die Gegenmaßnahme tatsächlich umgesetzt und überprüft wird. Planen Sie 30 Tage nach der Umsetzung eine Nachprüfung ein, um zu bestätigen, dass das Problem nicht erneut aufgetreten ist.

Weiterführende Inhalte

• Ursachenanalyse: Ein umfassenderer Leitfaden zu RCA-Methoden, wann welche eingesetzt wird und wie sie sich in Qualitätsmanagementsysteme einfügen.
• Pareto-Analyse: Priorisieren Sie mit dem 80/20-Prinzip, welche Probleme zuerst untersucht werden.
• Fishbone-Diagramm: Die visuelle Ergänzung zu den 5 Whys für die Zuordnung von Ursachenkategorien.
• DMAIC: Das Six-Sigma-Rahmenwerk, das die 5 Whys in seiner Analyze-Phase nutzt.
• SIPOC-Diagramm: Bilden Sie Ihren Prozess ab, bevor Sie mit den 5 Whys starten, damit Ihre Problembeschreibung richtig eingegrenzt ist.

Häufig gestellte Fragen

Warum fünf und nicht mehr oder weniger?

Die Zahl fünf ist eine Richtlinie, keine feste Regel. Sakichi Toyodas ursprüngliche Erkenntnis war, dass die meisten betrieblichen Probleme innerhalb von fünf Nachfragerunden eine erreichbare Grundursache haben. In der Praxis lösen sich manche Probleme schon bei drei "Warums", andere brauchen wirklich sieben. Entscheidend ist die Zahl, bei der Sie eine systemische, umsetzbare Ursache erreichen. Hören Sie dann auf. Bohren Sie tiefer, wenn Sie noch nicht so weit sind.

Sind die 5 Whys dasselbe wie eine Ursachenanalyse?

Nein, aber die 5 Whys sind eine Technik der Ursachenanalyse. Die Ursachenanalyse (RCA) ist die umfassendere Praxis, den zugrunde liegenden Ursprung eines Problems zu identifizieren. Die 5 Whys sind ein Werkzeug innerhalb dieser Praxis. Andere RCA-Werkzeuge sind das Fishbone-Diagramm, die Fehlerbaumanalyse und die Fehlermöglichkeits- und Einflussanalyse (FMEA). Viele RCA-Praktiker nutzen die 5 Whys als Ausgangspunkt, bevor sie strengere statistische Methoden hinzuziehen.

Können Sie die 5 Whys mit einem Fishbone-Diagramm kombinieren?

Ja, und das ist eine wirklich nützliche Kombination. Das Fishbone-Diagramm hilft dabei, herauszufinden, welche Ursachenkategorien am wahrscheinlichsten sind (Mensch, Prozess, Ausrüstung, Material, Umgebung, Messung). Sobald Sie sich auf einen konkreten Ast eingegrenzt haben, wenden Sie die 5 Whys an, um diesen Ast zu vertiefen und die Grundursache zu bestätigen. Das Fishbone-Diagramm weitet den Blick, die 5 Whys vertiefen ihn.

Wann sollte man die 5 Whys nicht einsetzen?

Verzichten Sie auf die 5 Whys bei Problemen, die statistisch komplex sind, mehrere miteinander verbundene Systeme betreffen oder eine formale Dokumentation für regulatorische oder kundenseitige Zwecke erfordern. Auch wenn das Team keinen Zugang zu den Personen und Daten hat, die dem Ausfall am nächsten stehen, ist es nicht das richtige Werkzeug. Greifen Sie in diesen Fällen auf ein Fishbone-Diagramm, 8D-Problemlösung oder eine vollständige Fehlermöglichkeits- und Einflussanalyse zurück.

Funktionieren die 5 Whys auch in Dienstleistungs- und Wissensarbeitsumgebungen, nicht nur in der Fertigung?

Absolut. Die Methode stammt aus der Fertigung, funktioniert aber überall dort, wo sich ein Prozess definieren und ein Fehler beobachten lässt. Softwareteams nutzen sie bei Post-Mortems. Customer-Success-Teams nutzen sie, um Abwanderung zu diagnostizieren. HR-Teams nutzen sie bei Ursachenanalysen nach Spitzen bei der Mitarbeiterfluktuation. Es gilt dieselbe Logik: Wer bei der ersten plausiblen Erklärung aufhört, erlebt das Problem erneut. Wer weiter nachfragt, findet heraus, was sich tatsächlich ändern muss.

Die 5 Whys erfordern keine besonderen Werkzeuge oder teuren Schulungen. Sie erfordern Ehrlichkeit darüber, was Sie nicht wissen, die Geduld, unbequeme Fragen weiter zu stellen, und die organisatorische Bereitschaft, das System zu reparieren, sobald Sie es gefunden haben. Teams, die sich diese Gewohnheit aneignen, hören auf, immer wieder dieselben Brände zu löschen. Das ist der eigentliche Gewinn.