Ein Bauteil versagt. Das Team reagiert sofort. Innerhalb von Stunden diskutiert man Geometrieanpassungen, alternative Materialien, engere Toleranzen. Drei Monate später taucht dasselbe Problem auf, diesmal an einer anderen Stelle im System. Weil niemand gefragt hat, was die eigentliche Ursache war.

Dieser Reflex ist menschlich. Er ist auch teuer.

Warum Entwicklungsteams zu schnell zur Lösung springen

Lösungsstolz ist in Ingenieurteams eine echte Kraft. Wer schnell eine Lösung präsentiert, wirkt kompetent. Wer erst Daten sammeln und Ursachen strukturieren will, wirkt zögerlich. Dieser soziale Druck ist real, auch wenn er selten ausgesprochen wird.

Hinzu kommt Zeitdruck. Reklamationen, Rückläufer, Produktionsstillstand. Die Erwartung lautet: Lösung jetzt. Die Konsequenz: Man behandelt das Symptom, das sichtbar ist, und hofft, dass die Ursache damit ebenfalls verschwindet. Manchmal stimmt das. Oft nicht.

Was Root-Cause-Analyse bedeutet

Root-Cause-Analyse ist der strukturierte Prozess, die eigentliche Ursache eines Fehlers zu identifizieren. Nicht das sichtbare Symptom, nicht die nächstliegende Erklärung, sondern die Wurzelursache.

Ein Beispiel: Ein Riss an einem Bauteil ist das Symptom. Die Ursache ist mechanische Überlastung durch eine Fehlkonstruktion. Die Wurzelursache ist, dass im Entwicklungsprozess keine vollständige Lastfallanalyse durchgeführt wurde. Wer nur den Riss behebt, also das Material wechselt oder die Wandstärke erhöht, löst das Symptom. Die fehlende Lastfallanalyse bleibt.

Wer die Fehlerursache systematisch finden will, muss aufhören, beim Symptom zu denken.

RCA ist die eigentliche Ingenieursarbeit

Root-Cause-Analyse ist kein bürokratischer Zwischenschritt. Sie ist die Kernarbeit, die vor jeder Lösungsfindung stehen muss. Sie produziert keine eleganten Renderings, keine neuen Konzepte, keine Patentanmeldungen. Sie produziert Klarheit über das eigentliche Problem.

Genau das ist der Grund, warum dieser Schritt so oft übersprungen wird. Er ist nicht sichtbar. Er erzeugt keinen unmittelbaren Output. Aber er entscheidet darüber, ob die spätere Lösung am richtigen Problem ansetzt. Was RCA einspart: Rückläufer, Nacharbeit, Reklamationen und die Zeit, die ein Team damit verbringt, dieselbe Frage zum dritten Mal zu bearbeiten.

Die wichtigsten RCA-Methoden im Überblick

Methoden sind Werkzeuge. Keine Methode ersetzt sauberes Denken, aber gute Werkzeuge machen strukturiertes Denken leichter.

Die einfachste Methode ist das 5-Why-Verfahren: Man fragt fünfmal „Warum?", bis man auf eine Ursache stößt, die sich nicht weiter zurückverfolgen lässt. Geeignet für klar abgegrenzte, lineare Fehlerketten. Das Ishikawa-Diagramm, auch Fischgrätendiagramm genannt, strukturiert Ursachen in Kategorien und ist besser geeignet, wenn mehrere parallele Ursachenstränge möglich sind. Die Fehlerbaumanalyse arbeitet deduktiv: vom bekannten Fehler rückwärts zu möglichen Ursachenkombinationen, sinnvoll bei sicherheitskritischen Systemen. FMEA ist präventiv ausgerichtet und analysiert potenzielle Fehler, bevor sie auftreten, mit Bewertung der Auswirkungen und Eintrittswahrscheinlichkeit. Sie ersetzt keine RCA, ergänzt sie aber sinnvoll in der Entwicklungsphase. Die Pareto-Analyse hilft bei der Priorisierung, wenn viele Fehlerarten vorliegen: Die 80/20-Regel zeigt, welche Ursachen den größten Anteil am Fehlerbild haben.

Und dann gibt es die Ursache-Wirkungs-Analyse, im TRIZ-Umfeld Cause-Effect Chain Analysis oder kurz CECA genannt. Hierzulande deutlich weniger bekannt als Ishikawa, obwohl in der VDI-Richtlinie 4521 Blatt 2 als eigenständige Methode beschrieben. Und von allen genannten diejenige, die am weitesten trägt.

5-Why in der Praxis, und wo es endet

Ein Hydraulikzylinder in einer Fertigungsanlage verliert Öl. Das Team startet die 5-Why-Analyse.

Warum verliert der Zylinder Öl? Die Dichtung ist beschädigt. Warum ist die Dichtung beschädigt? Sie zeigt Abriebspuren durch Kontakt mit der Kolbenstange. Warum gibt es diesen Kontakt? Die Kolbenstange läuft nicht zentrisch. Warum läuft sie nicht zentrisch? Das Führungslager ist verschlissen. Warum ist das Führungslager verschlissen? Es wurde nicht im vorgesehenen Wartungsintervall getauscht, weil das Intervall in der Dokumentation fehlte.

Wurzelursache: fehlende Wartungsdokumentation. Die Lösung ist keine neue Dichtung, sondern ein vollständiges Wartungskonzept.

Sauber hergeleitet, und trotzdem unvollständig. Die 5-Why-Methode erzwingt genau einen Strang. Sie kann strukturell nicht abbilden, dass die Dichtung auch aus einem zweiten, unabhängigen Grund versagen könnte. Typische Fehler beim 5-Why: bei der ersten plausiblen Antwort stehenbleiben, Meinungen statt Messwerte verwenden, nur einen Ursachenstrang verfolgen.

Ishikawa-Diagramm: Ursachen strukturieren, aber nicht analysieren

Das Fischgrätendiagramm eignet sich, wenn ein Team viele mögliche Ursachen vermutet und diese erst ordnen muss, bevor es tiefer bohrt. Die klassischen Kategorien sind Mensch, Maschine, Material, Methode, Milieu und Messung, die sogenannten 6M. Das Team sammelt gemeinsam Hypothesen, ordnet sie den Kategorien zu und priorisiert danach, welche Äste weiter untersucht werden. Ishikawa ist damit kein Analysewerkzeug im engeren Sinne, sondern ein Strukturierungswerkzeug. Es verhindert, dass ein Team nur in die Richtung sucht, die es ohnehin schon vermutet hat, und ist für den ersten Workshop-Tag oft genau das richtige Format.

Nur hört das Diagramm dort auf, wo die Analyse anfangen müsste. Es ordnet Ursachen nebeneinander, zeigt aber nicht, wie sie zusammenwirken. Und es kennt keine Regel dafür, wann eine Ursache tief genug ist, um Wurzelursache genannt zu werden: Die Entscheidung fällt per Abstimmung im Team, nicht per Nachweis. Wer damit ein komplexes Systemproblem bearbeitet, bekommt eine gut sortierte Liste von Verdächtigen. Er bekommt kein Modell.

Die Ursache-Wirkungs-Analyse (CECA): Netz statt Liste

Genau hier setzt die Ursache-Wirkungs-Analyse als grafische Modellierung von Ursache-Wirkungs-Zusammenhängen mittels Knoten und Pfeilen an. Knoten sind ausschließlich Nachteile oder negative Effekte des Systems, die Pfeile machen sichtbar, welche Ursache zu welcher Wirkung führt. Ausgehend vom Ausgangsproblem fragt man „Warum?", hinterfragt die gefundenen Ursachen erneut und arbeitet sich nach unten. Die tiefste Detailebene sind die Grundursachen.

Der entscheidende Unterschied zu Ishikawa und 5-Why steckt in den logischen Operatoren. Im entstehenden Netz werden die Ursachen mit UND- und ODER-Verknüpfungen verbunden. Bei einer UND-Verknüpfung sind alle Ursachen nötig, damit der schädliche Effekt entsteht: Fällt eine weg, verschwindet der Effekt. Bei einer ODER-Verknüpfung genügt eine einzige Ursache; solange auch nur ein Ast besteht, tritt der Fehler weiter auf. Das klingt akademisch, entscheidet aber über die Investition. Bei UND reicht es, den billigsten Ast zu unterbrechen. Bei ODER muss jeder einzelne Ast beseitigt werden, und wer dort nur einen behebt, produziert exakt jene Wiederkehr des Problems, die drei Monate später auf dem Tisch liegt. Weder Ishikawa noch 5-Why können diese Unterscheidung darstellen. Die Fehlerbaumanalyse kennt UND- und ODER-Gatter zwar ebenfalls, bleibt aber auf das Fehlerereignis fokussiert; CECA liefert zusätzlich den Anschluss an die Widerspruchsformulierung.

Am Hydraulikzylinder sieht das so aus: Der Ölverlust hat zwei ODER-verknüpfte Eingänge, beschädigte Dichtung oder undichte Verschraubung. Der Dichtungsschaden entsteht UND-verknüpft aus einer einseitig überpressten Dichtlippe und abrasiven Partikeln im Öl: Erst beides zusammen erzeugt den Abrieb. Die einseitige Pressung geht auf eine außermittig laufende Kolbenstange zurück, diese auf verschlissene Stangenführung, diese auf ein überschrittenes Wartungsintervall. Und dieses Intervall wurde aus zwei ODER-verknüpften Gründen überschritten: Es fehlte in der Dokumentation, und die Wartung wurde bewusst verschoben, weil ein Stillstand die Anlagenverfügbarkeit gekostet hätte. Beides zusammen zeigt: Ein neues Wartungskonzept hätte nur einen ODER-Ast geschlossen, und die Ölfiltration wäre nie in den Blick geraten.

CECA ist trotzdem nicht in jeder Lage die bessere Wahl: Ishikawa ist in zwanzig Minuten erklärt, CECA braucht mehr Zeit, mehr Disziplin und meist einen Moderator. Der Unterschied zeigt sich beim Ergebnis. Ishikawa liefert eine geordnete Sammlung von Vermutungen. CECA liefert ein überprüfbares Modell, aus dem sich konkret formulierte Teilprobleme ableiten lassen, in der VDI 4521 Blatt 2 „Richtungen der Innovation" oder „Anweisungen zur Innovation" genannt. Aus einer Ursachenliste wird ein Arbeitsplan.

Wenn die Grundursache nicht abstellbar ist: der Wurzelwiderspruch

Der eigentliche Sprung kommt an dieser Stelle. Klassische Ursachenanalyse endet dort, wo eine Ursache nicht mehr veränderbar ist: ein Naturgesetz, eine gesetzliche Vorgabe, ein Muss-Teil der Spezifikation, oder eine Ursache, die neben dem Schaden auch etwas Nützliches erzeugt. Das Team notiert „nicht beeinflussbar" und springt zurück auf eine Symptomlösung.

Die Root-Conflict-Analysis (RCA+) als dritte Methode der Ursachen- und Situationsanalyse beschrieben, dreht diesen Moment um. Sie erweitert die Ursache-Wirkungs-Analyse um die positiven Effekte des Systems. Eine Ursache, die gleichzeitig einen negativen und einen positiven Effekt verursacht, ist laut Richtlinie ein „root conflict", ein Wurzelwiderspruch. Und ein Widerspruch ist kein Endpunkt, sondern ein Startpunkt: Er lässt sich als technischer oder physikalischer Widerspruch formulieren und mit den TRIZ-Werkzeugen bearbeiten.

Im Beispiel: Die verschobene Wartung erzeugt beides. Sie verursacht den Verschleiß der Stangenführung, und sie erhält die Anlagenverfügbarkeit. Das ist kein Knoten, den man abstellt, das ist ein Wurzelwiderspruch. Und genau dort liegt die Lösung, die weder eine neue Dichtung noch ein neues Wartungshandbuch je erreicht hätte.

Die häufigsten Fehler bei der Ursachenanalyse

Das häufigste Problem: das Symptom wird als Ursache behandelt. „Die Dichtung ist kaputt" ist kein Befund über die Ursache, sondern über den Zustand.

Ebenfalls verbreitet ist der Bestätigungsfehler. Man findet die Ursache, die man ohnehin erwartet hat, und hört auf zu suchen. Oder man beginnt mit der Lösung, bevor die Analyse abgeschlossen ist, und passt die Analyse rückwirkend an. Dazu kommt ein Fehler, den erst das Netzmodell sichtbar macht: einen von mehreren ODER-Ästen zu beheben und die Analyse für abgeschlossen zu erklären.

Das Ergebnis ist immer dasselbe: Das Symptom verschwindet, die Wurzelursache bleibt, und drei Monate später steht das Team wieder vor derselben Frage.

Von der Fehlerursache zur Lösung: Warum Ursachenanalyse und TRIZ zusammengehören

Wer diesen Schritt überspringt, kann noch so strukturiert mit TRIZ arbeiten. Die beste Lösung für das falsche Problem bleibt eine falsche Lösung.

Ein sauber identifizierter Wurzelwiderspruch lässt sich direkt als technischer oder physikalischer Widerspruch formulieren. Genau das ist der Einstiegspunkt für TRIZ-Werkzeuge wie die Widerspruchsanalyse. Die VDI 4521 verortet die Ursache-Wirkungs-Analyse dabei ausschließlich in der Problemdefinition; die Brücke in die Lösungssuche schlägt die darauf aufsetzende Root-Conflict-Analysis, die in der Richtlinie für beide Phasen markiert ist. Genau deshalb gehören die beiden zusammen: Wer die Ursache nur vage beschreibt, kann keinen präzisen Widerspruch benennen, und ohne präzisen Widerspruch bleibt auch TRIZ unscharf. Wie dieser Zusammenhang in der Praxis wirkt, erklärt unser Artikel zur Funktionsanalyse in TRIZ ausführlicher.

Bei Truinorva setzt systematische Innovation genau hier an: nicht bei der Ideensammlung, sondern bei der sauberen Klärung, was das eigentliche Problem ist.

Praktischer Ablauf: So geht man eine RCA konkret an

Zuerst das Problem präzise beschreiben: Wo tritt es auf, wann, wie oft, unter welchen Bedingungen? Dann Daten und Belege sammeln, bevor Hypothesen gebildet werden. Erst danach wählt man die passende Methode: 5-Why für lineare Fehlerketten, Ishikawa für die erste Sortierung, CECA, sobald die Stränge zusammenwirken.

Beim Aufbau des Netzes gilt: konsequent „Warum?" fragen und bei jeder Verzweigung ausdrücklich entscheiden, ob eine UND- oder eine ODER-Verknüpfung vorliegt. Ein Ast endet nach den Abbruchkriterien der Root-Conflict-Analysis: wenn eine Ursache erreicht ist, die nicht geändert werden kann oder darf, die nicht zielgerichtet beeinflussbar ist, oder die gleichzeitig einen positiven Effekt erzeugt. Der letzte Fall ist der Wurzelwiderspruch und geht an die TRIZ-Werkzeuge weiter.

Die Wurzelursache muss mit Messwerten verifiziert werden, nicht mit Plausibilität. Erst dann entwickelt man eine Lösung und prüft, ob die Wurzelursache tatsächlich behoben und jeder ODER-Ast geschlossen ist.

Erst verstehen, dann lösen

Systematisches Fehlerursache-Finden ist keine Verzögerung. Es ist die Investition, die verhindert, dass dasselbe Problem in drei Monaten wieder auf dem Tisch liegt. Der Unterschied zwischen einer Ursachenliste und einem Ursachennetz ist dabei kein methodischer Feinschliff. Er entscheidet darüber, ob ein Team die Hälfte des Problems löst oder das ganze.

Wer diese Denkweise in sein Team bringen möchte, findet bei Truinorva konkrete Formate dafür: vom Innovation Impulse Day über strukturierte Problemklärung bis zum TRIZ Basic Training. Der erste Schritt ist immer derselbe: das eigentliche Problem klären, bevor man anfängt, es zu lösen.

Quellen

  • VDI 4521 Blatt 2:2018-04, Erfinderisches Problemlösen mit TRIZ — Zielbeschreibung, Problemdefinition und Lösungspriorisierung. Verein Deutscher Ingenieure e.V., Düsseldorf. Insbesondere Abschnitt 5.3 „TRIZ-Methoden zur Ursachen- und Situationsanalyse" (5.3.1 Ursache-Wirkungs-Analyse/CECA, 5.3.2 Problemformulierung und Ursache-Wirkungsketten-Modell, 5.3.3 Root-Conflict-Analysis) sowie Tabelle 1. vdi.de/richtlinien
  • VDI 4521 Blatt 1:2016-04, Erfinderisches Problemlösen mit TRIZ — Grundlagen und Begriffe. Verein Deutscher Ingenieure e.V., Düsseldorf.
  • Lee, M.-G.; Chechurin, L.; Lenyashin, V. (2018): Introduction to cause-effect chain analysis plus with an application in solving manufacturing problems. The International Journal of Advanced Manufacturing Technology 99, S. 2159–2169. doi.org/10.1007/s00170-018-2217-1
  • Dobrusskin, C. (2016): On the Identification of Contradictions Using Cause Effect Chain Analysis. Procedia CIRP 39, S. 221–224. doi.org/10.1016/j.procir.2016.01.192
  • Souchkov, V.: A Guide to Root Conflict Analysis (RCA+). ICG Training & Consulting. xtriz.com
  • Souchkov, V.: Root Conflict Analysis (RCA+): Structured Problems and Contradictions Mapping. xtriz.com
  • TapRooT / System Improvements: Fishbone Diagram Root Cause Analysis — Pros & Cons. taproot.com
  • Patra, M.: Ursachen-Wirkungs-Analyse und Grundursachen, TRIZ-Kompendium. michael-patra.de