Operations Analyse-Methode

5 Whys

5 Whys führt vom Symptom zu einer belegten und bearbeitbaren Ursache.

5 Whys untersucht die Ursachen eines klar eingegrenzten Problems anhand aufeinander aufbauender Warum-Fragen. Die Zahl fünf dient als Merkimpuls. Die Analyse reicht so weit, bis eine belegte und im eigenen Einflussbereich bearbeitbare Bedingung sichtbar wird.

Kernfrage

Welche steuerbare Ursache hinter dem Symptom kann das Team mit einer konkreten Gegenmaßnahme beheben?

Session planen Methodenanleitung

Vergleich starten

Feedback gebenHilft dir diese Methode?

Teilnehmende: 2-6
Zeit: 15-30 min

Eine 5-Whys-Arbeitsfläche verbindet ein beobachtbares Problem mit belegten Ursachen, einer markierten Unsicherheit und konkreten Gegenmaßnahmen mit Verantwortlichkeit.

Frame
Problem und Standard klären
Das Symptom so konkret machen, dass die Analyse am tatsächlichen Fall startet.
Evidence
Punkt des Auftretens belegen
Arbeit, Systemzustand und Daten prüfen, bevor eine Kausalbehauptung entsteht.
Trace
Kausalkette verfolgen
Mit Warum-Fragen von der belegten Abweichung zu tieferen Bedingungen gehen.
Challenge
Erklärung prüfen und Grenze setzen
Die stärkste Erklärung gegen Belege, Alternativen und den eigenen Handlungsspielraum testen.
Act
Gegenmaßnahmen und Lernen festlegen
Ursache adressieren, Wirkung prüfen und Verantwortung in den Alltag bringen.

Behandle jede Antwort als überprüfbare Hypothese. Kehre zu früheren Schritten zurück, verzweige bei mehreren Pfaden und aktualisiere die Analyse, wenn neue Belege die Erklärung verändern.

Geeignet, wenn

Passt, wenn ein konkretes, wiederkehrendes Problem mit direktem Zugang zu Arbeit, System und Belegen untersucht werden kann. Bei mehreren unabhängigen Ursachenpfaden ist eine verzweigte Analyse oder eine andere Methode geeigneter.

Ideal für

Incidents
Quality Issues
Process Breakdowns

Nicht gut für

Komplexe Systeme ohne Daten
Blame-orientierte Sessions

Ergebnisse

Cause & Evidence
Eine nachvollziehbare Kausalkette mit Belegen, Unsicherheiten und Einflussgrenze.
Countermeasures
Konkrete Ursachenmaßnahmen mit Owner, Termin und überprüfbarer Wirkung.

Struktur

5 Whys · UrsachenanalyseVom sichtbaren Symptom zu einer steuerbaren Ursache und Gegenmaßnahme

Erster Schritt

Formuliere ein beobachtbares Problem mit Zeitpunkt, Auswirkung und Abweichung vom erwarteten Zustand. Sichere vor dem ersten Warum die relevanten Daten und Personen mit direktem System- oder Prozesskontakt.

Zur Methodenanleitung

Davor sinnvoll

Das Scrum Team untersucht Menschen, Interaktionen, Prozesse, Werkzeuge und Definition of Done und vereinbart wenige überprüfbare Verbesserungen.

Agile

Sprint Retrospective

Liefert das wiederkehrend genannte Problem als Ausgangspunkt der Fragenkette.

Wie geht es weiter?

Papier-Fischgrätendiagramm mit einem messbaren Effekt am Kopf und sechs beschrifteten Ursachenästen.

Operations

Fishbone Diagram

Öffnet bei mehreren plausiblen Ursachenpfaden eine breitere Ursachensuche.

DevOps

Blameless Postmortem

Bettet die gefundene Ursache in eine systemische Vorfallanalyse ein.

Vertiefung

Zweck

Bei einer einzelnen, schwer erklärbaren Abweichung legt die Methode die kausale Kette hinter dem sichtbaren Symptom frei. Sie hält die Ursache so lange offen, bis eine steuerbare Bedingung statt einer bloßen Beschreibung vorliegt.

Funktionsweise

Jede Antwort wird als neuer Ausgangspunkt geprüft und gegen die Realität des Falls gespiegelt. So wandert die Betrachtung von der ersten Vermutung zu einer tieferen Ursache mit Handlungsspielraum. Die belastbarste Erklärung wird in konkrete Gegenmaßnahmen übersetzt und auf Plausibilität geprüft.

Im Detail

Die 5 Whys sind nützlich, wenn eine sichtbare Abweichung auf eine steuerbare Bedingung zurückgeführt werden soll. Jede Antwort muss gegen Fakten geprüft werden und darf nicht bei Personen, Zufall oder abstrakten Sammelbegriffen enden. Aus einer bloßen Warum-Kette wird Ursachenarbeit, sobald die gefundene Ursache eine konkrete Gegenmaßnahme sinnvoll macht.

Durchführung

Halte das erste beobachtbare Problem als klaren Satz fest und prüfe jede Antwort sofort gegen bekannte Fakten aus dem Fall. Die Methode kippt ins Beliebige, sobald Warum Fragen bloß Meinungen verlängern statt steuerbare Bedingungen freizulegen. Beende die Analyse dort, wo eine veränderbare Ursache erreicht ist, und formuliere daraus eine konkrete Gegenmaßnahme.

Die Methodenanleitung führt mit 5 Phasen, Zeitrahmen, 5 Stolperfallen und klaren Abbruchkriterien durch die Umsetzung.

Methodenanleitung öffnen

Deine Einschätzung

Hilft dir diese Methode für dein Vorhaben?

Mit deinem Feedback hilfst du, den Methodatlas weiterzuentwickeln.

Quellen und Themen

Themen

Ursachenanalyse Incident Lean Problemlösung

Quellen

5 Whys - What is it? | Lean Enterprise Institutelean.orgLean Enterprise Institute; erklärt 5 Whys anhand von Taiichi Ohnos Originalbeispiel zur Ursachenanalyse bei Toyota.The Simple Yet Powerful 5 Whys Method for Effective Problem-Solving - isixsigma.comisixsigma.comiSixSigma-Beitrag von Lori Kinney; beschreibt Ursprung bei Sakichi Toyoda und den dreistufigen Ablauf der 5-Whys-Methode.

In Playbooks

Ursachenanalyse durchführenVon Symptom zu beitragenden Ursachen, Mustern und wirksamen Gegenmaßnahmen.

Artefakt-Vorlagen

5 Whys: ArbeitsvorlageBereite einen ausgewählten Schritt oder den gesamten Ablauf vor. Rechts entsteht dein Plan zum Mitnehmen.

markdown

5-whys-working-template.md

Bereite einen ausgewählten Schritt oder den gesamten Ablauf vor. Rechts entsteht dein Plan zum Mitnehmen.

5 Whys: Arbeitsvorlage

Fragestellung

Noch zu klären

Gewünschtes Ergebnis

Noch zu klären

Rahmen

Gesamte Analyse Zeit: 15–30 Minuten für einen begrenzten Fall; Belegbeschaffung und Wirkkontrolle zusätzlich.

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

Vorbereitung für diesen Umfang

Methodische Grundausstattung

Materialien: Whiteboard oder Miro-Board mit vertikaler Kette aus sechs Boxen (Problem + 5 Whys); Stift; Timer; Link zum auslösenden Ticket oder Incident-Report.
Rollen: Ein Facilitator, der die Kette führt und neutral nachfragt; zwei bis fünf Personen mit direktem Systemkontakt (mindestens ein Engineer, ein Operator); ein Scribe, der jede Antwort wörtlich mitschreibt.
Vorab-Infos: Incident- oder Ticket-Link, Timeline vom ersten Symptom bis zur Stabilisierung, Standard, relevante Zustände und bekannte Workarounds zusammentragen. Belege, Deutungen und offene Annahmen vorab trennen.
Gesamter Zeitbedarf: 15-30 min
Setup: Problem und Standard oben auf Board oder Papier notieren, darunter freie Felder für die Kausalkette, Belegstatus, Gegenhypothesen und Maßnahmen anlegen. Keine Namen als Ursachen verwenden; Detection, Containment und Ursachenmaßnahme getrennt halten.