5 Why vs. Ishikawa – In vielen Unternehmen werden Probleme „gefixt“, aber nicht nachhaltig gelöst. Das Ergebnis: wiederkehrende Störungen, unzuverlässige Prozesse, Frust in Teams und unnötige Kosten. Methoden wie die 5-Why-Analyse und das Ishikawa-Diagramm gehören zu den wirkungsvollsten Werkzeugen der Ursachenanalyse – werden aber oft oberflächlich oder falsch eingesetzt.
In diesem Beitrag erfahren Sie, wie 5 Why und Ishikawa funktionieren, worin die Unterschiede liegen, welche Methode sich in welcher Situation eignet und wie Sie beide sinnvoll kombinieren. Mit praxisnahen Beispielen und klaren Schritten, die Sie direkt in Projekten, Linienorganisation und IT anwenden können.
Warum systematische Ursachenanalyse unverzichtbar ist
Wer nur Symptome bekämpft, verliert Zeit, Budget und Glaubwürdigkeit. Gerade für Entscheider, Projektmanager und Führungskräfte gilt:
- Jeder wiederkehrende Fehler bindet Ressourcen.
- Qualitätsprobleme gefährden Kundenzufriedenheit und SLA-Erfüllung.
- IT-Incidents und Prozessstörungen eskalieren schnell in politische Themen.
Systematische Ursachenanalyse (Root Cause Analysis) sorgt dafür, dass Probleme nicht nur „weg eskaliert“, sondern an der Wurzel gelöst werden. Methoden wie 5 Why und Ishikawa helfen dabei, strukturiert vorzugehen, Hypothesen sauber zu prüfen und Verbesserungen abzusichern.
Was ist die 5-Why-Methode? – Kurz erklärt
Die 5-Why-Methode ist eine einfache Technik der Ursachenanalyse, bei der man wiederholt die Frage „Warum?“ stellt, um von der sichtbaren Symptom-Ebene zur eigentlichen Kernursache vorzudringen.
Kurzdefinition:
Die 5-Why-Methode ist eine iterative Fragetechnik, bei der ein Problem durch mindestens fünf aufeinanderfolgende „Warum?“-Fragen bis zur Grundursache zurückverfolgt wird, um nachhaltige Maßnahmen abzuleiten.
Typische Einsatzfälle:
- Störungen in Prozessen und Abläufen
- Qualitätsprobleme in Produktion oder Service
- wiederkehrende IT-Incidents
- Projektverzögerungen oder Planungsfehler
Wie funktioniert 5 Why? – Vorgehen Schritt für Schritt
So können Sie 5 Why in Projekten oder im Tagesgeschäft anwenden:
- Problem klar beschreiben
- Konkrete, beobachtbare Formulierung („Der Kunde X erhielt die Rechnung Y doppelt“ statt „Unser Rechnungsprozess ist schlecht“).
- Erste Warum-Frage stellen
- „Warum ist das passiert?“ – Antwort so konkret wie möglich, faktenbasiert.
- Weitere Warum-Fragen stellen
- Jede Antwort wird zum Ausgangspunkt der nächsten Frage.
- Ziel: sich nicht mit der ersten plausiblen Erklärung zufriedengeben.
- Bei tiefer Ursache stoppen
- Nach etwa fünf Iterationen gelangt man häufig an eine systemische Ursache (z. B. fehlende Standards, unklare Verantwortlichkeiten, unpassende KPIs).
- Maßnahmen ableiten und verankern
- Korrigierende und vorbeugende Maßnahmen definieren.
- Verantwortliche, Fristen und Erfolgskennzahlen festlegen.
Einfaches 5-Why-Beispiel aus dem Projektalltag
Problem:
Der Go-Live eines IT-Systems verzögert sich.
- Warum verzögert sich der Go-Live?
→ Weil die Integrationstests nicht rechtzeitig fertig wurden. - Warum wurden die Integrationstests nicht rechtzeitig fertig?
→ Weil Testfälle fehlten und nachträglich erstellt werden mussten. - Warum fehlten Testfälle?
→ Weil die Fachbereiche ihre Anforderungen nicht vollständig dokumentiert hatten. - Warum waren die Anforderungen nicht vollständig dokumentiert?
→ Weil es kein verbindliches Template und keine Schulung für die Anforderungsaufnahme gab. - Warum gibt es kein Template und keine Schulung?
→ Weil im Projektmanagement-Framework der Organisation das Thema „Requirements Engineering“ nicht standardisiert ist.
Kernursache: Fehlende Standards im Requirements Engineering, nicht „zu wenig Fleiß“ im Testing.
Wirksame Maßnahme: Einführung verbindlicher Templates und Schulungen, Anpassung des Projektvorgehensmodells – nicht nur mehr Druck auf Tester.
Was ist das Ishikawa-Diagramm? – Kurz erklärt
Das Ishikawa-Diagramm (auch Fischgräten- oder Ursache-Wirkungs-Diagramm) visualisiert alle potenziellen Ursachen für ein Problem in strukturierter Form. Es wurde von Kaoru Ishikawa entwickelt und ist ein Klassiker im Qualitätsmanagement.
Kurzdefinition:
Ein Ishikawa-Diagramm ist ein grafisches Werkzeug, das mögliche Ursachen eines Problems in Kategorien (z. B. Mensch, Methode, Maschine, Material, Management, Umfeld) darstellt, um Zusammenhänge sichtbar zu machen und systematisch zu prüfen.
Typische Einsatzfälle:
- komplexe Qualitätsprobleme
- Abweichungen in KPIs (z. B. Durchlaufzeit, Fehlerquote)
- Ursachenanalyse in Lean- und Six-Sigma-Projekten
- Workshops mit mehreren Stakeholdern
Wie funktioniert das Ishikawa-Diagramm? – Vorgehen Schritt für Schritt
So erstellen Sie ein Ishikawa-Diagramm in Ihrem Team:
- Problem klar definieren
- Das Problem (Wirkung) als „Kopf“ des Fisches formulieren, z. B. „Hohe Fehlerquote im Monatsabschluss“.
- Hauptursachenkategorien festlegen
Häufig verwendet (Produktion/Service):- Mensch
- Methode
- Maschine/Technologie
- Material/Daten
- Management/Organisation
- Umgebung/Umfeld
- Prozesse
- Systeme
- Daten
- Rollen & Verantwortlichkeiten
- Steuerung & KPIs
- Kultur & Kommunikation
- Brainstorming zu möglichen Ursachen
- Im Team pro Kategorie Ursachen sammeln.
- Jede Ursache als „Gräte“ an den jeweiligen Hauptzweig schreiben.
- Ursachen präzisieren und ggf. vertiefen
- Einzelne Gräten können Untergräten erhalten („Unterursachen“).
- Bei wichtigen Ursachen ggf. zusätzlich mit 5 Why tiefer gehen.
- Bewertung und Priorisierung
- Welche Ursachen sind wahrscheinlich, beeinflussbar, relevant?
- Zusammenhänge diskutieren, Daten hinzuziehen.
- Maßnahmen ableiten
- Klare Maßnahmenpakete pro priorisierter Ursache definieren.
- Verantwortliche, Termine und Erfolgsindikatoren festlegen.
5 Why vs. Ishikawa: Gemeinsamkeiten und Unterschiede
Beide Methoden gehören zur Root-Cause-Analysis. Trotzdem erfüllen sie unterschiedliche Rollen.
Gemeinsamkeiten:
- Ziel: wirkliche Ursachen statt Symptome identifizieren
- Fokus auf Struktur statt spontanen Schuldzuweisungen
- fördert faktenbasierte Diskussion im Team
- Grundlage für nachhaltige Verbesserungen
Unterschiede in der Anwendung:
- 5 Why
- linear, fragend, eher verbal
- gut für einzelne Problemlinien
- sehr schlank und schnell einsetzbar
- braucht Disziplin, um nicht beim ersten „plausiblen“ Warum stehenzubleiben
- Ishikawa
- visuell, breit, kategorienbasiert
- ideal für komplexe oder diffuse Probleme
- besonders geeignet für Workshops mit mehreren Bereichen
- erfordert etwas mehr Vorbereitung und Moderation
Kurz gesagt:
5 Why geht in die Tiefe einer Ursachekette.
Das Ishikawa-Diagramm geht in die Breite möglicher Ursachenfelder.
Wann eignet sich 5 Why besonders?
Die 5-Why-Methode passt vor allem, wenn:
- das Problem klar abgrenzbar ist (z. B. „Ticket konnte nicht fristgerecht bearbeitet werden“),
- Sie schnell von der Symptomebene zu einer Ursache kommen wollen,
- ein kleineres Team oder eine Person analysiert,
- es um eher lineare Ursache-Wirkungs-Zusammenhänge geht.
Typische Beispiele:
- Ein KPI rutscht kurzfristig ab (z. B. SLA einmalig gerissen).
- Ein Arbeitsschritt wurde vergessen oder falsch ausgeführt.
- Eine wichtige Information wurde nicht rechtzeitig übermittelt.
Für kontinuierliche Verbesserung im Tagesgeschäft (z. B. im Shopfloor-Management, im Service Desk, in agilen Teams) ist 5 Why ein sehr praxistaugliches, leicht vermittelbares Werkzeug.
Wann ist das Ishikawa-Diagramm die bessere Wahl?
Das Ishikawa-Diagramm spielt seine Stärken aus, wenn:
- das Problem komplex ist oder viele Beteiligte hat,
- Ursachen über mehrere Bereiche, Systeme oder Organisationseinheiten verteilt sind,
- es bereits viele Hypothesen und Meinungen gibt („Wir wissen genau, woran es liegt …“),
- Sie ein gemeinsames Verständnis über Ursachen entwickeln wollen.
Typische Beispiele:
- dauerhaft hohe Bearbeitungszeiten in einem End-to-End-Prozess
- wiederkehrende Fehler im Monatsabschluss oder in Reports
- Qualitätsprobleme im Produkt- oder Serviceportfolio
- hohe Fluktuation in einem Bereich (als Symptom einer tieferen Ursache)
In Lean-, Kaizen- oder Six-Sigma-Initiativen ist das Ishikawa-Diagramm oft das zentrale Werkzeug, um Ursachenfelder systematisch zu explorieren.
Praktisches Beispiel: 5 Why vs. Ishikawa im IT- und Projektkontext
Beispiel 1: 5 Why im Incident-Management
Problem:
Ein zentrales CRM-System war zwei Stunden nicht verfügbar.
Mit 5 Why könnte der Verlauf so aussehen:
- Warum war das CRM-System nicht verfügbar?
→ Weil die Datenbankverbindung abgebrochen ist. - Warum ist die Datenbankverbindung abgebrochen?
→ Weil der Datenbankserver überlastet war. - Warum war der Datenbankserver überlastet?
→ Weil mehrere unerwartet ressourcenintensive Reports gleichzeitig liefen. - Warum liefen mehrere ressourcenintensive Reports gleichzeitig?
→ Weil das Reporting-Fenster nicht begrenzt und kein Scheduling definiert ist. - Warum gibt es kein definiertes Scheduling?
→ Weil es keine abgestimmte Governance für Reports und Abfragen gibt.
Ergebnis:
Maßnahmen zielen auf Reporting-Governance und technische Limits, nicht nur auf „bessere Hardware“.
Beispiel 2: Ishikawa im End-to-End-Prozess
Problem:
Die Durchlaufzeit vom Auftragseingang bis zur Faktura ist dauerhaft zu hoch.
Im Ishikawa-Workshop werden mögliche Ursachen u. a. in folgenden Kategorien gesammelt:
- Prozesse:
- redundante Prüfschritte
- fehlende Standardpfade für einfache Aufträge
- Medienbrüche zwischen Systemen
- Systeme:
- Schnittstellenprobleme zwischen CRM und ERP
- langsame Batch-Jobs
- manuelle Exporte/Importe als Workarounds
- Daten:
- unvollständige Kundendaten
- unterschiedliche Datenmodelle in CRM/ERP
- fehlende Pflichtfelder
- Rollen & Verantwortlichkeiten:
- unklare Zuständigkeiten bei Rückfragen
- kein klarer Owner für den End-to-End-Prozess
- Steuerung & KPIs:
- keine Transparenz über Engpässe
- KPI-Fokus nur auf Einzelabteilungen, nicht auf Gesamtprozess
Der Wert des Ishikawa-Diagramms liegt hier darin, dass alle relevanten Ursachenfelder sichtbar werden und sich Muster erkennen lassen – z. B. dass sich viele Probleme um unklare Verantwortlichkeiten und fehlende End-to-End-Sicht drehen.
Typische Fehler bei 5 Why und Ishikawa – und wie Sie sie vermeiden
Häufige Fehler bei 5 Why
- Nur drei Mal „Warum“ fragen
→ Man bleibt an der Oberfläche. Empfehlung: Diszipliniert mindestens vier bis fünf Stufen anpeilen. - Schuldige statt Ursachen suchen
→ Antworten wie „Weil Mitarbeiter A unaufmerksam war“ bringen nicht weiter. Besser: „Weil es kein Vier-Augen-Prinzip gibt.“ - Hypothesen mit Fakten verwechseln
→ „Weil vermutlich …“ ist ein Hinweis, dass Daten fehlen. Maßnahmen auf Vermutungen sind riskant. - Mehrere Probleme vermischen
→ Zu Beginn ein Problem klar eingrenzen und benennen.
Häufige Fehler beim Ishikawa-Diagramm
- Zu grobe oder zu viele Kategorien
→ Das Diagramm wird unübersichtlich. Besser: 5–7 sinnvolle Kategorien für den jeweiligen Kontext. - Brainstorming ohne Priorisierung
→ Eine Wand voller Post-its ist kein Fortschritt, wenn nichts priorisiert wird. - Keine Verbindung zu Daten
→ Nur Meinungen zu sammeln, reicht nicht. Wo möglich, sollte man Ursachen mit Kennzahlen oder Beobachtungen abgleichen. - Kein klarer Abschluss
→ Am Ende müssen konkrete Maßnahmen definiert werden – sonst bleibt das Diagramm ein „schönes Bild“.
Welche Methode ist besser – 5 Why oder Ishikawa?
Die Frage „Welche Methode ist besser?“ lässt sich so beantworten:
- Für schnelle, fokussierte Analysen bei klar definierten Problemen ist 5 Why oft die effizienteste Wahl.
- Für komplexe, bereichsübergreifende Fragestellungen mit vielen möglichen Einflussfaktoren ist das Ishikawa-Diagramm das geeignetere Werkzeug.
Hilfreiche Leitfragen:
- Wie komplex ist das Problem?
- Eher linear und konkret → 5 Why
- Eher vernetzt und diffus → Ishikawa
- Wie viele Stakeholder sind beteiligt?
- 1–2 Personen → 5 Why
- mehrere Bereiche/Teams → Ishikawa (ggf. ergänzt durch 5 Why an wichtigen Gräten)
- Wie viel Zeit steht zur Verfügung?
- wenige Minuten bis eine Stunde → 5 Why
- geplanter Workshop → Ishikawa
Am Ende geht es nicht darum, sich für eine „Fraktion“ zu entscheiden, sondern beide Methoden bewusst und situationsgerecht einzusetzen.
5 Why und Ishikawa sinnvoll kombinieren
Besonders wirkungsvoll wird Ursachenanalyse, wenn Sie 5 Why und Ishikawa kombinieren:
- Start mit Ishikawa:
- In einem Workshop alle potenziellen Ursachenfelder sammeln.
- Sicht auf das Problem verbreitern, Silos aufbrechen.
- Fokus setzen:
- Die wichtigsten Ursachen (z. B. nach Einfluss und Beeinflussbarkeit) markieren.
- Einige wenige „kritische Gräten“ auswählen.
- Vertiefung mit 5 Why:
- Für diese kritischen Gräten jeweils eine 5-Why-Analyse durchführen.
- So gelangen Sie von der visuell-breiten Sicht zur tieferen Kernursache.
- Maßnahmenbündel ableiten:
- Technische, prozessuale und organisatorische Maßnahmen kombinieren.
- Sicherstellen, dass Sie nicht nur „Symptom-Flächenbrandbekämpfung“ betreiben.
Diese Kombination ist besonders im Qualitätsmanagement, im Prozessmanagement und in größeren Transformations- oder IT-Projekten empfehlenswert.
So verankern Sie Ursachenanalysen nachhaltig in Ihrer Organisation
Damit 5 Why und Ishikawa nicht als einmalige „Methodenübung“ verpuffen, sollten Sie einige Prinzipien beachten:
- In Standards integrieren
- Ursachenanalyse als festen Schritt in Incident-, Problem- und Change-Management verankern.
- In Projektmethodiken (z. B. Gate-Reviews, Retrospektiven) standardisieren.
- Einfach zugängliche Templates bereitstellen
- Kurze Leitfäden und Vorlagen für 5-Why-Analysen und Ishikawa-Diagramme.
- Beispiele aus dem eigenen Unternehmen nutzen.
- Führung unterstützt Ursachen statt Schuldige
- Führungskräfte müssen klar signalisieren: Es geht um Systemverbesserung, nicht um individuelle Schuld.
- Erfolge sichtbar machen
- Zeigen Sie, welche wiederkehrenden Probleme durch strukturierte Root-Cause-Analysen verschwunden sind.
- Das motiviert Teams, die Methoden konsequent zu nutzen.
- Kompetenz aufbauen
- Schulungen für Projektleiter, Teamleiter und Key User.
- Praxisnahe Übungscases aus dem eigenen Kontext statt abstrakter Beispiele.
Fazit: 5 Why vs. Ishikawa – zwei Werkzeuge, ein Ziel
5 Why und Ishikawa sind keine konkurrierenden, sondern komplementäre Methoden der Ursachenanalyse:
- 5 Why hilft Ihnen, bei konkreten Problemen schnell und schlank zur Kernursache vorzudringen.
- Das Ishikawa-Diagramm ermöglicht es, komplexe Ursachenlandschaften sichtbar zu machen und im Team strukturiert zu diskutieren.
Wer beide Ansätze beherrscht und situativ einsetzt, reduziert wiederkehrende Störungen, verbessert Prozessqualität und stärkt eine Kultur des Lernens statt des Schuldzuweisens. Gerade in Projekten, IT-Organisationen und fachbereichsübergreifenden Prozessen ist das ein entscheidender Hebel für nachhaltige Leistungsfähigkeit.
Wenn Sie Ursachenanalysen professionell in Ihrem Unternehmen verankern, Methoden wie 5 Why und Ishikawa in Ihre Projekt- und Prozesslandschaft integrieren oder konkrete Problemstellungen begleitet bearbeiten möchten, lohnt sich der Blick von außen: Erfahrene Berater, etwa von PURE Consultant, unterstützen dabei, die passenden Werkzeuge auszuwählen, Teams zu befähigen und Verbesserungen nachhaltig umzusetzen.