Wenn dieselbe Störung zum dritten Mal auftritt, hat Ihr Team kein Maßnahmenproblem, sondern ein Methodenwahl-Problem. Wiederkehrende Probleme entstehen selten, weil ein Werkzeug fehlt. Sie entstehen, weil das gewählte Werkzeug nicht zur Komplexität des Problems passt.
Einfache Tools wie die 5-Why-Methode leisten bei linearen Ursachenketten gute Dienste; bei komplexen, intermittierenden Problemen führen sie in die Irre. Dieser Beitrag ordnet die etablierten Methoden der Ursachenanalyse ein, zeigt ihre Grenzen — und stellt mit der Kepner-Tregoe-Problemanalyse einen Ansatz vor, der mögliche Ursachen nicht sammelt, sondern gegen Fakten prüft.
Warum die Fehlerursachenanalyse oft an der Symptomgrenze endet
Die meisten Ursachenanalysen scheitern nicht am Werkzeug, sondern daran, dass sie auf der Ebene der Symptome stehen bleiben. Genau das zeigen Auditdaten aus der Automobilindustrie: Nach Zahlen des IAOB führt die Problemlösung die Liste der häufigsten Abweichungen in IATF-16949-Audits an — typischer Befund ist eine oberflächliche Ursachenanalyse, die beim Symptom endet, bevor die eigentliche Ursache, die Wurzel des Problems, identifiziert ist.
Die Folge kennt jede Qualitätsleitung: Schnelle Lösungen behandeln das Symptom, das Problem kehrt zurück, und mit jeder Wiederholung steigen die Kosten. Ausschuss, Nacharbeit und ungeplante Stillstände sind dann keine Einzelereignisse mehr, sondern Dauerzustand — und das Team verliert das Vertrauen in die eigene Ursachenanalyse. Der Grund ist selten fehlender Wille, sondern fehlende Systematik.
Ein zweiter Befund verändert die Stoßrichtung jeder Untersuchung: Probleme sind weit überwiegend system-, nicht personenbedingt. W. Edwards Deming schätzte 1986, dass 94 Prozent aller Probleme und Verbesserungsmöglichkeiten im System liegen — und damit in der Verantwortung des Managements, nicht einzelner Mitarbeiter.
Das ist eine Schätzung aus Erfahrung, keine Studie, aber sie trifft den Kern: Wer bei „menschliches Versagen” aufhört zu fragen, hat die Ursache fast nie gefunden. Eine belastbare Analyse braucht deshalb eine No-Blame-Kultur in der Organisation. Sie sucht die Schwachstelle im Prozess, nicht den Schuldigen am Arbeitsplatz.
Methoden der Ursachenanalyse im Überblick: Was die etablierten Werkzeuge leisten
Der RCA-Werkzeugkasten ist gut gefüllt: Die klassischen Werkzeuge der Ursachenanalyse sind normseitig etabliert, in vielen Unternehmen aus KVP und Six Sigma vertraut und leisten in ihrem Einsatzbereich gute Arbeit — zumal sie sich mit anderen Instrumenten kombinieren lassen. Entscheidend ist der Plural: Es gibt keine Universalmethode. Jede Methode hat einen definierten Geltungsbereich, und in der Durchführung unterscheiden sich die Verfahren erheblich.
5-Why-Methode: schnell, teamtauglich — und strikt linear
Die 5-Why-Methode stammt aus dem Toyota-Produktionssystem: Ein Team fragt, ausgehend vom Problem, iterativ „Warum?”, bis es bei einer tieferliegenden Ursache ankommt — als Faustregel fünfmal. Die Stärken sind real: Die 5-Why-Methode braucht keine lange Schulung, keine Tools und keine Datenbank; sie funktioniert im Shopfloor-Meeting und liefert als Einstieg in die Ursachenanalyse in Minuten eine erste Hypothese.
Ihr Geltungsbereich ist allerdings eng: 5 Why trägt bei einfachen, linearen Kausalketten, in denen ein Warum sauber zum nächsten führt. Sobald mehrere Faktoren zusammenwirken, bildet die Frage-Kette die Realität nicht mehr ab.
Ishikawa-Diagramm: Hypothesen strukturieren mit dem Ursache-Wirkungs-Diagramm
Das Ishikawa-Diagramm — auch Fischgräten- oder Ursache-Wirkungs-Diagramm — sortiert mögliche Ursachen entlang der 6M-Kategorien: Mensch, Maschine, Material, Methode, Milieu und Messung. Als Werkzeug der Zusammenarbeit ist das Diagramm stark: Es macht das Wissen eines Teams sichtbar und strukturiert Hypothesen zu Ursache-Wirkungs-Beziehungen. Seine Grenze: Es prüft nichts. Am Ende steht ein gut sortiertes Diagramm voller Vermutungen — welche zutrifft, muss ein anderer Schritt klären.
Pareto-Analyse: die wenigen Ursachen mit der größten Wirkung
Die Pareto-Analyse überträgt die 80/20-Logik auf Fehlerdaten: Ein kleiner Teil der Fehlerarten verursacht typischerweise den Großteil der Kosten. Im Pareto-Diagramm werden Ausschussarten nach Häufigkeit oder Kostenwirkung geordnet — so wird sichtbar, welcher Fehlerschwerpunkt die knappen Ressourcen der Ursachenanalyse zuerst verdient. Pareto findet keine Ursachen; die Methode priorisiert, wo die Suche beginnen sollte.
Fehlermöglichkeits- und Einflussanalyse (FMEA): präventiv statt reaktiv
Die Fehlermöglichkeits- und Einflussanalyse setzt vor dem Fehler an: Sie bewertet potenzielle Fehlerarten in Design und Prozess, bevor sie auftreten. Seit 2019 bündelt das gemeinsame AIAG-&-VDA-FMEA-Handbuch die Vorgehensweise für Design-FMEA und Prozess-FMEA in einer harmonisierten Referenz beider Verbände. Für die akute Störung ist die FMEA das falsche Werkzeug: Sie verhindert Fehler präventiv, findet aber keine Ursache für ein bereits eingetretenes Problem. Eine gepflegte FMEA liefert der laufenden Ursachenanalyse jedoch wertvolle Daten — als Ausgangspunkt der Suche.
Fehlerbaumanalyse (FTA) und der Methodenkatalog der DIN EN IEC 31010
Die Fehlerbaumanalyse arbeitet deduktiv: Vom unerwünschten Top-Ereignis aus werden logische Ursachenpfade als Baum verzweigt und mit UND-/ODER-Verknüpfungen verbunden — bis hin zur quantifizierten Ausfallwahrscheinlichkeit. Bemerkenswert ist der normative Rahmen: Die DIN EN IEC 31010 in der Fassung 2024-12 beschreibt 41 Verfahren zur Risikobeurteilung, darunter die Fehlerbaumanalyse, und gibt Entscheidungshilfen, welches Verfahren wann trägt. Schon die Norm behandelt die Methodenwahl als eigenen Arbeitsschritt — einen Schritt, der in der Praxis regelmäßig übersprungen wird.
8D: der Rahmenprozess für Reklamationen in der Automobilindustrie
8D ist keine Analysetechnik, sondern ein Rahmenprozess in acht Disziplinen — von der Teambildung über Sofortmaßnahmen bis zur Wirksamkeitsprüfung. Für 8D existiert seit November 2018 ein eigener VDA-Band; er betont, dass eine angemessene, nachhaltige Problemlösung nicht an den Zeitvorgaben der Reklamationsbearbeitung scheitern darf. Der kritische Punkt sitzt in der Mitte des Prozesses: Der Rahmen verlangt, dass die Ursache ermittelt wird — die Analysetechnik dafür bringt er nicht selbst mit.
Genau an dieser Stelle wird der VDA konkret. Für D2 (Problembeschreibung) und D4 (Ursachenanalyse) empfiehlt der Band ausdrücklich die vergleichende IST/IST-NICHT-Analyse von Kepner-Tregoe: Die Problembeschreibung soll mit IST- und IST-NICHT-Informationen aufgebaut und in der Ursachenanalyse konsequent fortgeführt werden. Für Zulieferer heißt das, dass die Methode für den kritischsten Schritt des 8D-Reports im Branchenstandard bereits benannt ist. Die Einordnung dazu liefert der Beitrag VDA empfiehlt Kepner-Tregoe IST und IST-NICHT. Wie Teams das im 8D-Kontext anwenden, vertieft das 8D-Root-Cause-Analysis-Training.
Wo 5 Why & Ishikawa an ihre Grenzen stoßen
Der Merksatz vorweg: Brainstorming-basierte Werkzeuge erzeugen Hypothesen — keine geprüften Ursachen. 5-Why-Ketten und Ishikawa-Diagramme dokumentieren, was das Team für plausibel hält; ob es stimmt, sagen sie nicht.
Diese Kritik ist publiziert und keine Verkaufsbotschaft: Eine Analyse im Fachjournal BMJ Quality & Safety (2017) kommt zu dem Schluss, dass die 5-Why-Methode trotz breiter Verankerung — propagiert unter anderem von WHO und NHS — ohne Wirksamkeitsnachweis auskommt und den Blick auf einen einzelnen linearen Ursachenpfad verengt; für komplexe Probleme ist sie ungeeignet. Die Untersuchung stammt aus dem Gesundheitswesen, ihr Kernargument ist domänenunabhängig: Wer nur einer Warum-Kette folgt, sieht genau einen Pfad — und übersieht Wechselwirkungen.
In der Produktion zeigt sich das an einem typischen Muster: Ein sporadischer Ausschussanstieg tritt zum Beispiel nur auf einer von drei Linien auf, nur bei bestimmten Chargen, nicht in jeder Schicht. Eine 5-Why-Runde produziert dann fünf plausible Antworten — und mit anderer Besetzung fünf andere. Das Ishikawa-Diagramm sammelt dieselben Vermutungen, nur besser sortiert.
Was fehlt, ist die Gegenprobe: Welche der vermuteten Ursachen erklärt das gesamte Fehlerbild — auch die Fälle, in denen das Problem nicht auftritt? So entstehen Ursachenanalysen, die formal sauber aussehen und trotzdem die falsche Baustelle bearbeiten.
Drei Grenzen lassen sich festhalten. Erstens erzwingt 5 Why Linearität, wo mehrfaktorielle Zusammenhänge vorliegen. Zweitens hängt das Ergebnis von der Erfahrung der Beteiligten ab, nicht von Daten. Drittens fehlt beiden Tools ein eingebauter Prüfschritt, der Hypothese von Evidenz trennt. Werkzeuge, die nur Vermutungen liefern, erzeugen im Zweifel Lösungen für die falsche Ursache. Für einfache Probleme bleibt 5 Why aus gutem Grund das Mittel der Wahl — nicht aber für komplexe, intermittierende Fälle mit hohem Risiko.
Die KT-Problemanalyse: Root Cause Analysis als prüfbarer Prozess statt Ratensammlung
Die Kepner-Tregoe-Problemanalyse ersetzt Raten durch Spezifikation. Sie ist Bestandteil der PSDM-Methodik (Problem Solving & Decision Making), die Kepner-Tregoe seit mehr als 65 Jahren entwickelt und weltweit in Unternehmen trainiert; RCA ist in dieser Systematik ein Derivat der Mutter-Methodik — nicht umgekehrt. Der Kern in drei Schritten:
IST/IST-NICHT-Spezifikation (IS/IS NOT). Das Problem wird in vier Dimensionen präzise eingegrenzt: Was ist betroffen — und was auffälligerweise nicht? Wo tritt die Abweichung auf, wo nicht? Wann, seit wann, wann nicht? Welches Ausmaß hat sie, welches nicht? Die IS-NOT-Seite ist der eigentliche Hebel: Sie schließt mögliche Ursachen aus, bevor jemand ihnen hinterherläuft.
Besonderheiten und Veränderungen (Distinctions & Changes). Aus der Spezifikation leitet das Team ab, was das Betroffene vom Nicht-Betroffenen unterscheidet (Distinctions) und was sich an diesen Merkmalen verändert hat (Changes). Mögliche Ursachen entstehen aus Daten und Erkenntnissen — nicht aus dem Gefühl der lautesten Person im Raum.
Ursachen testen. Jede vermutete Ursache muss die komplette Spezifikation erklären: jedes IS und jedes IS-NOT. Was das Fehlerbild nicht vollständig erklärt, scheidet aus — bevor Maßnahmen Geld kosten. Ziel ist nicht die plausibelste, sondern die belegte Ursache; erst die wahrscheinlichste wird am Objekt verifiziert.
Ein Beispiel aus der Fertigung: In einem Werk steigt der Ausschuss an einer Dichtfläche — aber nur auf Linie 2, nicht auf den baugleichen Linien 1 und 3; nur bei bestimmten Vormaterial-Chargen; erstmals in der Woche nach einem Wartungsfenster. Eine 5-Why-Runde hätte hier viele Startpunkte und keine Prüfinstanz. Die IS/IS-NOT-Spezifikation macht die Eingrenzung selbst zur Analyse: Was unterscheidet Linie 2 von den anderen? Was hat sich im Wartungsfenster geändert? Die Kombination aus Unterscheidungsmerkmal (dort getauschtes Anpresswerkzeug) und Veränderung (neue Werkzeugcharge mit abweichender Toleranz) erklärt das komplette Muster — inklusive der Linien, auf denen nichts passiert. Verifiziert wird am Werkzeug, nicht per Mehrheitsmeinung. (Das Szenario ist zur Illustration vereinfacht und beschreibt die Vorgehensweise, keinen konkreten Kundenfall.)
Der Unterschied zu 5 Why und Ishikawa liegt nicht im Aufwand, sondern in der Beweislogik: Die Problemanalyse behandelt jede mögliche Ursache als Hypothese, die gegen die Spezifikation bestehen muss — so wird die tatsächliche Problemquelle identifiziert statt der plausibelsten. Das macht die Problemlösung dokumentierbar und auditierbar — und es verhindert Lösungen, die auf ungeprüften Hypothesen beruhen. In der Produktion zahlt das direkt auf stabile Prozesse ein; wie sich die Systematik in bestehende Abläufe integrieren lässt, zeigt die Beratung zu Produktionsoptimierung.
Ausschuss reduzieren heißt Ursachen kennen: der Business-Case in der Produktion
Ausschuss und Nacharbeit sind Qualitätskosten — im Qualitätsmanagement als Cost of Poor Quality gefasst. Bemerkenswert ist, wie wenig Transparenz darüber herrscht: Laut dem ASQE-Cost-of-Quality-Report 2025 geben nur 31 Prozent der Befragten an, die Auswirkungen von Qualitätskosten auf die Finanzleistung ihrer Organisation vollständig zu verstehen. Ein Unternehmen, das die Kostenwirkung seiner Fehler nicht kennt, kann weder priorisieren noch den Erfolg von Maßnahmen belegen.
Der Weg zur Verringerung des Ausschusses folgt deshalb einer klaren Reihenfolge: erst Transparenz über die Fehlerdaten, dann Priorisierung per Pareto, dann die Identifikation der Grundursache am größten Fehlerschwerpunkt. Strategien zur Senkung der Qualitätskosten gibt es viele — tragfähig sind sie erst mit bestätigter Ursache. Wer stattdessen nur Symptome behandelt, zahlt wiederholt: für Nacharbeit, Sonderfahrten und gebundene Kapazität. Nachhaltige Lösungen setzen an der Ursache an; alles andere ist Symptompflege mit Budget.
Für Zulieferer der Automobilindustrie ist das keine Kür: Die IATF 16949 verlangt in Abschnitt 10.2.3 einen dokumentierten Problemlösungsprozess — einschließlich Methoden zur Ermittlung der Grundursache, systemischer Korrekturmaßnahmen und einer Wirksamkeitsprüfung. Eine belastbare Ursachenanalyse ist damit Normanforderung, nicht Zusatzaufwand. Und sie endet nicht mit der gefundenen Ursache: Die Umsetzung wirksamer Korrektur- und Vorbeugemaßnahmen ist ein eigener Prozess — dort setzt die Beratung zu Corrective and Preventive Actions an.
Fehler-Ursachen-Analyse jenseits der Fertigung: IT-Betrieb und Service
Dieselbe Logik trägt überall dort, wo das „Produkt” ein Service ist. Im IT-Betrieb sind Major Incidents und wiederkehrende Störungen der klassische Anwendungsfall: Gerade intermittierende Störungen — der Dienst fällt sporadisch aus, zum Beispiel nur in bestimmten Konfigurationen oder nur unter Last — sind das Terrain, auf dem 5-Why-Runden regelmäßig scheitern und Spezifikation gewinnt. Ein Incident, der „manchmal” auftritt, ist kein Mysterium, sondern eine unvollständige Problembeschreibung: Was ist betroffen, was nicht? Seit wann? Unter welchen Bedingungen? Monitoring-Tools liefern die Rohdaten dafür meist längst.
Für Incident- und Problem-Management heißt das: Die IST/IST-NICHT-Systematik strukturiert die Faktenlage in Echtzeit, während der Druck hoch ist — und trennt die Fehlerbehebung im Incident (Service wiederherstellen, MTTR senken) sauber von der Ursachenanalyse im Problem Management (Wiederholung verhindern). Das Gleiche gilt in der Softwareentwicklung und im technischen Support: Wer Störungen präzise spezifiziert, statt Vermutungen weiterzureichen, verbessert die Zusammenarbeit zwischen Teams — und kommt mit weniger Schleifen zu Lösungen, die die Störung dauerhaft beseitigen.
Ursachenanalyse durchführen: in fünf Schritten von der Abweichung zur bestätigten Ursache
Unabhängig von der gewählten Methode folgt jede belastbare Durchführung demselben Grundmuster. Das Ziel: von der Abweichung zur bestätigten Ursache. Wer eine Ursachenanalyse durchführen will, braucht fünf Schritte:
- Problem präzise beschreiben. Objekt und Abweichung benennen — einschließlich dessen, was nicht betroffen ist. Diese Definition ist die Grundlage aller weiteren Schritte.
- Daten erfassen. Fakten statt Meinungen: Wann, wo, wie oft, in welchem Ausmaß? Die Qualität der Erfassung entscheidet über die Qualität jeder späteren Bewertung.
- Mögliche Ursachen ableiten. Je nach Art des Problems und gewählter Methode: per Warum-Kette, 6M-Raster oder Distinctions & Changes.
- Hypothesen gegen Fakten testen. Jede mögliche Ursache muss das komplette Fehlerbild erklären — auch die Fälle, in denen das Problem ausbleibt.
- Maßnahme umsetzen und Wirksamkeit prüfen. Die Maßnahme ist eine gezielte Aktion gegen die bestätigte Ursache; ohne Wirksamkeitsprüfung sind Lösungen nur Wetten.
Entscheidend ist die Wahl der Methode nach Problemklasse — ganz im Sinn der DIN EN IEC 31010, die die Auswahl des Verfahrens als eigenen Arbeitsschritt behandelt:
| Problemklasse | Passendes Vorgehen |
|---|---|
| Einfach, lineare Ursachenkette, geringes Risiko | 5-Why-Methode |
| Mehrfaktoriell, Teamwissen vorhanden, Datenlage dünn | Ishikawa-Diagramm plus Datenerhebung |
| Viele Fehlerarten, Priorisierung nötig | Pareto-Analyse vorschalten |
| Präventive Absicherung von Design und Prozess | FMEA |
| Komplex, intermittierend, hohes Risiko oder hohe Kosten | KT-Problemanalyse |
Die Tabelle gibt Empfehlungen als Faustregel; sie ersetzt keine Bewertung im Einzelfall, verhindert aber den häufigsten Fehler: die eine Universalmethode für alles.
Häufige Fragen zur Ursachenanalyse
Welche Methoden zur Ursachenanalyse gibt es?
Zu den etablierten Verfahren — alle in diesem Artikel eingeordnet — zählen die 5-Why-Methode, das Ishikawa-Diagramm, die Pareto-Analyse, die Fehlermöglichkeits- und Einflussanalyse (FMEA), die Fehlerbaumanalyse (FTA), der 8D-Prozess und die Kepner-Tregoe-Problemanalyse. Die Werkzeuge unterscheiden sich weniger in der Qualität als im Geltungsbereich: einfache Tools für lineare Probleme, strukturierte Verfahren für komplexe und intermittierende Fälle.
Was ist die 6M-Methode für die Ursachenanalyse?
Die 6M-Methode bezeichnet die sechs Kategorien des Ishikawa-Diagramms: Mensch, Maschine, Material, Methode, Milieu und Messung. Sie dient als Suchraster, damit ein Team bei der Sammlung möglicher Ursachen keinen Einflussbereich übersieht. Eine Prüfung der Hypothesen leistet die 6M-Struktur nicht — dafür braucht es einen eigenen Testschritt.
Sind es 5 oder 7 Warum-Fragen?
Die Zahl ist Konvention, keine Regel. Entscheidend ist nicht, wie oft ein Team „Warum?” fragt, sondern ob die letzte Antwort gegen Fakten geprüft wurde und das gesamte Fehlerbild erklärt. Eine 5-Why-Kette mit ungeprüfter fünfter Antwort ist weniger wert als drei Warum-Fragen mit sauberer Gegenprobe.
Was ist die Ausschussquote in der Produktion?
Die Ausschussquote ist der Anteil fehlerhafter, nicht nacharbeitbarer Einheiten an der produzierten Gesamtmenge, angegeben in Prozent. Aussagekräftig wird die Kennzahl in Kombination mit einer Pareto-Auswertung der Fehlerarten — erst diese zeigt, an welchem Schwerpunkt eine Ursachenanalyse den größten Hebel hat.
Fazit: Die Methode muss zur Problemklasse passen
Einfache Werkzeuge für einfache Probleme, strukturierte Problemanalyse für komplexe: Wer diese Unterscheidung trifft, reduziert Wiederholungsfehler, statt Symptome zu verwalten — und kommt zu Lösungen, die halten. Denn selten sind die Tools das Hindernis — die ungeprüfte Hypothese ist es. Probleme an der Wurzel zu packen heißt: spezifizieren, ableiten, testen.
Wenn Ihr Team wiederkehrende oder intermittierende Probleme systematisch lösen soll, ist ein Root-Cause-Analysis-Training der nächste Schritt: Anwender lernen dort die Problemanalyse an eigenen Fällen — von der IST/IST-NICHT-Spezifikation bis zur bestätigten Ursache und ihrer Wirksamkeitsprüfung. Details zu Formaten und Terminen finden Sie beim RCA-Training von Kepner-Tregoe.
