Root Cause Analysis: Methoden der Ursachenanalyse im Überblick

Root Cause Analysis (RCA, deutsch Ursachenanalyse) bezeichnet das systematische Vorgehen, mit dem ein Team die eigentliche Ursache einer Störung findet, statt nur ihr Symptom zu beheben. Dafür gibt es eine Reihe erprobter Methoden: 5 Why, Ishikawa-Diagramm, Fehlerbaumanalyse, Pareto-Analyse, Kepner-Tregoe, Change-Analyse und Timeline-Analyse.

Keine dieser Methoden passt zu jeder Störung. Einige kommen mit dem Wissen des Teams und einem Whiteboard aus, andere setzen saubere Ticket-, Log- oder Änderungsdaten voraus. Dieser Artikel beschreibt jede Methode mit Zweck, Vorgehen, Grenzen und einem Beispiel aus der IT und schließt mit einer Auswahlhilfe. Wie die Ursachenanalyse in den Problem-Management-Prozess eingebettet ist, wer sie verantwortet und was in einen RCA-Bericht gehört, erklärt der Glossarartikel RCA im Problem Management.

Das Wichtigste in Kürze

• Drei Familien: Fragende Methoden (5 Why, Kepner-Tregoe) arbeiten mit gezielten Fragen, grafische (Ishikawa, Fehlerbaum) machen Zusammenhänge sichtbar, datenbasierte (Pareto, Change- und Timeline-Analyse) werten Tickets, Logs und Änderungen aus.
• Pareto ist ein Vorfilter: Die Analyse zeigt, wo sich Störungen häufen, aber nicht, warum sie entstehen.
• Selten nur eine Ursache: In verteilten Systemen wirken meist mehrere Faktoren zusammen. Ishikawa-Diagramm und Fehlerbaum bilden das ab, eine einzelne 5-Why-Kette nicht.
• Belege statt Vermutungen: Jede Ursache braucht einen Nachweis, etwa einen Logeintrag, einen Test oder einen reproduzierbaren Fehler.

Stand: November 2026 · Fachlich abgeglichen mit Lean Enterprise Institute, NASA Fault Tree Handbook, IEC 61025, Google SRE, Microsoft Learn und PeopleCert (Quellen am Ende des Artikels)

5 Why, Ishikawa, Pareto und Fehlerbaum

Die ersten vier Methoden decken ein breites Spektrum ab: von der schnellen Fragekette im Team bis zur formalen Analyse eines hochverfügbaren Systems.

5 Why: fragen, bis die Ursache greifbar wird

Zweck: Die Methode führt vom sichtbaren Symptom über eine Kette von Warum-Fragen zu einer Ursache, an der sich eine Maßnahme ansetzen lässt. Sie stammt aus dem Toyota-Produktionssystem. Taiichi Ohno beschreibt als Beispiel eine Maschine, deren Sicherung durchbrennt. Die Kette endet nicht bei der Sicherung, sondern bei einem fehlenden Sieb an der Schmierpumpe. Laut Lean Enterprise Institute kommt es auf die Zahl fünf nicht an. Gefragt wird, bis die Ursache erreicht ist.

Vorgehen: Formulieren Sie das Problem präzise: was, wo, seit wann. Belegen Sie jede Antwort mit Fakten, bevor Sie die nächste Frage stellen. Hören Sie auf, wenn eine Maßnahme an dieser Stelle das erneute Auftreten verhindert.

Grenzen: Das Ergebnis ist eine einzelne, lineare Kette. Mehrere zusammenwirkende Ursachen bildet sie schlecht ab, und das Ergebnis hängt stark vom Wissen der Beteiligten ab. Häufig endet die Kette beim „menschlichen Fehler“, ohne zu klären, warum der Fehler überhaupt möglich war.

IT-Beispiel: Angenommen, ein nächtlicher Datenexport bricht ab. Warum? Das Zielvolume ist voll. Warum? Die Logdateien eines Dienstes wachsen unbegrenzt. Warum? Für den Dienst ist keine Logrotation eingerichtet. Warum? Die Vorlage, aus der der Server erstellt wurde, enthält keine. Warum? Für die Vorlage ist niemand verantwortlich, sie wird nie geprüft. Die Maßnahme lautet daher: Vorlage korrigieren und einen Verantwortlichen benennen. Speicherplatz freizuräumen behebt nur das Symptom.

Ishikawa-Diagramm: Einflussfaktoren ordnen

Zweck: Das nach Kaoru Ishikawa benannte Ursache-Wirkungs-Diagramm, wegen seiner Form auch Fischgrätendiagramm genannt, sammelt mögliche Ursachen einer Wirkung und ordnet sie in Kategorien. Das Institute for Healthcare Improvement nennt als klassische Kategorien Material, Methoden, Ausrüstung, Umfeld und Menschen. Im deutschsprachigen Raum ist die 6M-Variante verbreitet: Mensch, Maschine, Methode, Material, Messung und Mitwelt. Für die IT passen eigene Gräten besser, etwa Menschen, Prozesse, Anwendungen, Infrastruktur, Daten und Lieferanten.

Vorgehen: Die Wirkung steht als Kopf rechts, die Kategorien bilden die Hauptgräten. Das Team sammelt je Kategorie mögliche Ursachen und verfeinert sie zu Unterursachen. Danach wählen Sie die plausibelsten aus und prüfen sie mit Daten.

Grenzen: Das Diagramm liefert Hypothesen, keinen Beweis. In großen Runden wird es schnell unübersichtlich, und es gewichtet die Ursachen nicht.

IT-Beispiel: Angenommen, die Anmeldung am ERP-System dauert seit Wochen jeden Morgen ungewöhnlich lange. Auf den Gräten landen unter anderem die Auslastung der Domain Controller (Infrastruktur), ein Anmeldeskript, das Netzlaufwerke verbindet (Anwendungen), stark gewachsene Benutzerprofile (Daten) und der gleichzeitige Arbeitsbeginn vieler Beschäftigter (Menschen). Erst die Messung zeigt, welcher Faktor tatsächlich die Verzögerung verursacht.

Pareto-Analyse: Schwerpunkte finden

Zweck: Die Pareto-Analyse sortiert Störungen nach Kategorien absteigend und zeigt mit einer kumulierten Linie, welche wenigen Kategorien den Großteil verursachen. Der Qualitätsexperte J. M. Juran übertrug das Prinzip auf die Qualitätssicherung und prägte den Begriff der „vital few“. Die Werte 80 und 20 sind laut Oregon State University Extension keine festen Größen.

Vorgehen: Legen Sie Zeitraum und Kategorien fest, zählen Sie die Fälle, sortieren Sie absteigend und berechnen Sie den kumulierten Anteil. Die Kategorien mit dem größten Anteil gehen in die eigentliche Ursachenanalyse.

Grenzen: Pareto zeigt, wo sich Störungen häufen, aber nicht, warum. Häufig heißt nicht schwerwiegend: Gewichten Sie bei Bedarf nach Ausfallminuten oder Zahl der Betroffenen. Eine große Kategorie „Sonstiges“ verzerrt das Bild.

IT-Beispiel: Angenommen, ein Service Desk wertet die Incidents eines Quartals nach Configuration Item aus. Wenige Anwendungen verursachen den größten Teil der Tickets. Für die oberste wird ein Problem eröffnet, die anderen folgen nach Kapazität.

Fehlerbaumanalyse: vom unerwünschten Ereignis rückwärts

Zweck: Die Fehlerbaumanalyse (Fault Tree Analysis, FTA) ist in IEC 61025 genormt. Laut NASA Fault Tree Handbook ist sie deduktiv: Sie beginnt bei einem unerwünschten Top-Ereignis und leitet über UND- und ODER-Verknüpfungen schrittweise dessen Ursachen bis zu Basisereignissen ab. Die wichtigsten Ergebnisse sind die minimalen Schnittmengen, also die kleinsten Kombinationen von Basisereignissen, die das Top-Ereignis auslösen. Mit Ausfallwahrscheinlichkeiten lässt sich der Baum auch quantitativ auswerten.

Vorgehen: Top-Ereignis eng definieren, Systemgrenzen festlegen, Ebene für Ebene die Ursachen mit Verknüpfungen ergänzen und die minimalen Schnittmengen bestimmen. Eine Schnittmenge mit nur einem Ereignis ist ein Single Point of Failure.

Grenzen: Die Methode ist aufwendig und setzt gute Architekturkenntnis voraus. Ein Fehlerbaum ist nach dem NASA-Handbuch kein Modell aller möglichen Ausfälle, sondern nur jener, die zum gewählten Top-Ereignis beitragen. Zeitliche Abfolgen lassen sich nur schwer abbilden.

IT-Beispiel: Angenommen, das Top-Ereignis lautet „Kundenportal nicht erreichbar“. Darunter stehen über ODER verknüpft: Ausfall der Namensauflösung, Ausfall des Load Balancers und, über UND verknüpft, Ausfall beider Anwendungsserver. Beim Ergänzen fällt auf, dass beide Server dieselbe Datenbank ohne Replikat nutzen. Diese Datenbank ist eine Schnittmenge mit einem einzigen Ereignis, obwohl die Anwendungsschicht redundant aufgebaut ist.

Kepner-Tregoe, Change- und Timeline-Analyse

Die folgenden drei Methoden arbeiten mit Fakten aus dem Betrieb: Abgrenzungen, Änderungen und Zeitstempel. Sie eignen sich besonders, wenn eine Störung plötzlich auftritt oder nur einen Teil der Umgebung betrifft.

Kepner-Tregoe-Problemanalyse: was ist und was nicht ist

Zweck: Die von Charles H. Kepner und Benjamin B. Tregoe entwickelte Problemanalyse trennt Fakten von Vermutungen. Kern ist eine Ist-/Ist-nicht-Spezifikation: Für die Dimensionen Was, Wo, Wann und Ausmaß wird festgehalten, wo das Problem auftritt und wo es auftreten könnte, aber nicht auftritt (siehe die Beschreibung der Kepner-Tregoe-Matrix der US-Behörde AHRQ).

Vorgehen: Aus dem Vergleich beider Seiten ergeben sich Unterscheidungsmerkmale. Zu jedem Merkmal prüfen Sie, ob eine Änderung damit zusammenhängt. Daraus leiten Sie mögliche Ursachen ab und testen sie gegen jede Zeile der Spezifikation. Die wahrscheinlichste Ursache erklärt alle Ist- und alle Ist-nicht-Einträge. Anschließend wird sie verifiziert, möglichst mit einem Test.

Grenzen: Die Methode ist zeitaufwendig, braucht präzise Angaben und eine geübte Moderation. Bei Störungen mit vielen verteilten Ursachen wird die Abgrenzung unscharf.

IT-Beispiel: Angenommen, seit Dienstag drucken Notebooks in einem Bürogebäude keine PDF-Anhänge mehr, Desktop-PCs im selben Gebäude schon. Andere Standorte sind nicht betroffen. Unterscheidungsmerkmal: Die Notebooks erhalten ihre Drucker über einen anderen Druckserver. Änderung: Dort wurde am Montag ein Treiberpaket aktualisiert. Diese Ursache erklärt jede Zeile. Der Test mit dem alten Treiber auf einem Gerät bestätigt sie.

Change-Analyse: Was ist anders als vorher?

Zweck: Die Change-Analyse vergleicht den gestörten Zustand mit einem vergleichbaren störungsfreien Zustand, zeitlich (vorher und nachher) oder parallel (betroffenes und nicht betroffenes System). Gesucht werden Unterschiede und Änderungen. Der Ansatz ist naheliegend: Google beziffert im Site-Reliability-Engineering-Buch, dass rund 70 Prozent der Ausfälle auf Änderungen an einem laufenden System zurückgehen.

Vorgehen: Referenzzustand bestimmen, Unterschiede auflisten (Konfiguration, Versionen, Last, Daten, Personal, Lieferanten) und alle Änderungen im fraglichen Zeitraum aus Change-Protokoll, Deployment-Historie und CMDB zusammentragen. Jede Änderung wird auf einen plausiblen Wirkmechanismus geprüft.

Grenzen: Die Methode ist nur so gut wie die Dokumentation der Änderungen. Nicht autorisierte Eingriffe fehlen in jeder Liste. Zudem findet sie eher den Auslöser als eine schlummernde Schwachstelle: Im Beispiel-Postmortem von Google löste ein Lastanstieg einen latenten Fehler aus, der schon lange im Code lag.

IT-Beispiel: Angenommen, E-Mails an einen bestimmten Geschäftspartner werden seit dem Wochenende abgewiesen. Die Change-Liste des Wochenendes enthält eine angepasste Firewall-Regel und den Austausch des TLS-Zertifikats am Mail-Gateway. Nur der Zertifikatstausch erklärt, warum ausschließlich Verbindungen zu diesem Partner scheitern.

Timeline-Analyse: den Ablauf rekonstruieren

Zweck: Die Timeline-Analyse rekonstruiert den Ablauf einer Störung minutengenau, vom ersten Auslöser bis zur Wiederherstellung. Sie ist das Gerüst eines Postmortems. Die Postmortem-Kultur von Google SRE beschreibt ein Postmortem als schriftliche Aufzeichnung von Vorfall, Auswirkung, Gegenmaßnahmen, Ursachen und Folgemaßnahmen. Das zugehörige Beispiel enthält eine Zeitleiste in UTC.

Vorgehen: Quellen sammeln (Monitoring-Alarme, Logs, Ticket-Historie, Change-Einträge, Chatverläufe), alle Zeitstempel auf eine Zeitzone bringen und die Schlüsselmomente markieren: erster Auslöser, erste Auswirkung, Erkennung, Eskalation, Gegenmaßnahmen und Wiederherstellung. Lücken werden ausdrücklich gekennzeichnet.

Grenzen: Eine Abfolge beweist keine Kausalität. Abweichende Systemuhren verfälschen die Reihenfolge, und ohne vollständige Logs bleibt die Zeitleiste lückenhaft.

IT-Beispiel: Angenommen, ein geplanter Datenbank-Failover führt zu einer deutlich längeren Unterbrechung als vorgesehen. Die Zeitleiste zeigt, dass der Alarm rechtzeitig ausgelöst wurde, die Bereitschaft aber erst eine halbe Stunde später reagierte, weil die Alarmierung an eine veraltete Rufgruppe ging. Die Ursache der langen Ausfallzeit liegt in der Alarmierungskette, nicht in der Datenbank.

Die sieben Methoden im Vergleich

Auswahlhilfe: welche Methode für welche Störung

Drei Fragen entscheiden über die passende Methode: Wie viele belastbare Daten liegen vor? Wie komplex ist das betroffene System? Und wie schwer wiegt die Störung für das Geschäft?

• Ausfall direkt nach einem Wartungsfenster oder Release: zuerst Change- und Timeline-Analyse.
• Fehler betrifft nur einen Teil der Nutzer, Geräte oder Standorte: Kepner-Tregoe, weil die Abgrenzung den Suchraum schnell verkleinert.
• Viele kleine, gleichartige Incidents ohne erkennbares Muster: Pareto zum Eingrenzen, danach Ishikawa für die größte Kategorie.
• Überschaubares System, Ursache scheint nahe: 5 Why, jede Antwort mit Beleg.
• Ausfall eines kritischen Service trotz Redundanz: Fehlerbaumanalyse, um gemeinsame Abhängigkeiten zu finden.
• Major Incident mit vielen Beteiligten: Timeline als gemeinsames Gerüst, ergänzt um Ishikawa für die beitragenden Faktoren.

Methoden kombinieren: ein durchgespieltes Beispiel

Angenommen, ein Industrieunternehmen mit drei Werken wertet seine Incidents quartalsweise aus. Die Pareto-Analyse zeigt eine Häufung von VPN-Abbrüchen im Außendienst. Die Timeline mehrerer Fälle ergibt ein Muster: Die Verbindungen brechen nach exakt acht Stunden ab. Die Change-Analyse findet eine geänderte Sitzungsbegrenzung am VPN-Gateway. Eine kurze 5-Why-Kette klärt, warum die Änderung ohne Test live ging: Sie war als Standard-Change eingestuft, obwohl sie das Verhalten für alle Nutzer ändert. Maßnahmen sind die Rücknahme der Einstellung und eine engere Definition dessen, was als Standard-Change gilt.

Einordnung im Problem Management

In ITIL 4 gliedert sich die Practice Problem Management in Problemidentifikation, Problemkontrolle und Fehlerkontrolle. Die hier beschriebenen Methoden gehören zur Problemkontrolle, in der ein Problem analysiert und gegebenenfalls als Known Error mit Workaround dokumentiert wird. Wann eine RCA ausgelöst wird, welche Rollen beteiligt sind und wie ein Bericht aufgebaut ist, beschreiben der Glossarartikel RCA und der Wissenswelt-Beitrag Problem Management nach ITIL.

ky2help^® bildet Problem Management als eine der 13 von PeopleCert akkreditierten ITIL^®-Practices ab. Incidents, Probleme und Changes lassen sich verknüpfen, Known-Error-Datenbank und CMDB gehören zum Funktionsumfang. Der KI-Supportagent zeigt bei einem eingehenden Incident bereits vorhandene Problem-Tickets an, die thematisch passen könnten.

Problem Management ansehen

Grenzen und typische Fehler der Ursachenanalyse

Auch eine gut gewählte Methode liefert schwache Ergebnisse, wenn die Analyse selbst schlecht geführt wird. Sechs Fehler kommen in der Praxis immer wieder vor:

1. Eine einzige Ursache erzwingen: Komplexe Systeme fallen selten aus nur einem Grund aus. Google SRE spricht ausdrücklich von beitragenden Ursachen im Plural.
2. Beim menschlichen Fehler aufhören: Ein Tippfehler in der Konfiguration ist der Anfang der Analyse, nicht ihr Ende. Entscheidend ist, warum Prozess und Technik ihn nicht abgefangen haben. Microsoft Learn empfiehlt deshalb eine Nachbetrachtung, die nach Erkenntnissen fragt und keine Schuld zuweist.
3. Hypothesen nicht prüfen: Im Rückblick wirkt die erste plausible Erklärung oft zwingend. Ohne Test oder Beleg bleibt sie eine Vermutung.
4. Auslöser und Ursache verwechseln: Ein Lastanstieg kann einen Ausfall auslösen, die Ursache liegt dann etwa in einem fehlenden Kapazitätslimit. Wer nur den Auslöser behandelt, erlebt die Störung beim nächsten Anlass erneut.
5. Daten zu spät sichern: Logs rotieren, Neustarts löschen Zustände. Sichern Sie Belege, bevor die Wiederherstellung sie überschreibt, soweit der Betrieb das zulässt.
6. Maßnahmen nicht nachverfolgen: Eine Analyse ohne umgesetzte und überprüfte Maßnahme ändert nichts.

Wirksamkeit messen

Ob die Ursachenanalyse wirkt, zeigen wenige Kennzahlen: die Zahl gleichartiger Incidents nach Umsetzung der Maßnahme, der Anteil der Probleme mit bestätigter Ursache, die Umsetzungsquote der vereinbarten Maßnahmen und die Dauer bis zur bestätigten Ursache. Steigt die Zahl der Wiederholungen trotz abgeschlossener Analysen, liegt der Fehler meist in der Wahl der Methode oder in fehlenden Belegen.

Regulatorischer Rahmen im Finanzsektor

Für Finanzunternehmen in der EU gilt seit 17. Januar 2025 die Verordnung (EU) 2022/2554 (DORA). Artikel 17 verlangt Verfahren, mit denen Ursachen IKT-bezogener Vorfälle ermittelt, dokumentiert und angegangen werden. Nach schwerwiegenden Vorfällen sind nach Artikel 13 nachträgliche Prüfungen vorgesehen, die die Ursachen untersuchen. Welche Methode dabei eingesetzt wird, lässt die Verordnung offen. Mehr zu den Anforderungen der Branche auf der Seite Finanzdienstleistungen und Banken.

Häufige Fragen zu den Methoden der Root Cause Analysis

Welche Methoden der Ursachenanalyse gibt es?

Verbreitet sind sieben Methoden: 5 Why, Ishikawa-Diagramm, Pareto-Analyse, Fehlerbaumanalyse, Kepner-Tregoe-Problemanalyse, Change-Analyse und Timeline-Analyse. Sie unterscheiden sich darin, ob sie mit Fragen, Diagrammen oder Betriebsdaten arbeiten und wie viel Vorbereitung sie brauchen.

Welche RCA-Methode eignet sich für komplexe IT-Störungen?

Wirken mehrere Ursachen zusammen, sind Ishikawa-Diagramm und Fehlerbaumanalyse besser geeignet als eine einzelne 5-Why-Kette. Bei Major Incidents hat sich eine Timeline als gemeinsames Gerüst bewährt, ergänzt um eine Change-Analyse für alle Änderungen im fraglichen Zeitraum.

Muss man bei der 5-Why-Methode genau fünfmal fragen?

Nein. Die Zahl fünf ist ein Richtwert aus dem Toyota-Produktionssystem. Entscheidend ist, so lange zu fragen, bis eine Ursache erreicht ist, deren Beseitigung das erneute Auftreten verhindert. Manchmal genügen drei Fragen, manchmal braucht es mehr.

Was unterscheidet Ishikawa-Diagramm und Fehlerbaumanalyse?

Das Ishikawa-Diagramm sammelt mögliche Ursachen in Kategorien und eignet sich für Brainstorming im Team. Die Fehlerbaumanalyse verknüpft Ursachen logisch über UND und ODER, zeigt, welche Kombinationen einen Ausfall auslösen, und lässt sich auch quantitativ auswerten.

Ist die Pareto-Analyse eine Ursachenanalyse?

Nicht im engeren Sinn. Die Pareto-Analyse zeigt, welche Kategorien die meisten Störungen verursachen, und hilft so bei der Priorisierung. Warum die Störungen entstehen, klären anschließend andere Methoden wie Ishikawa, 5 Why oder Kepner-Tregoe.

Bietet ky2help® Werkzeuge für die Ursachenanalyse?

ky2help® bildet Problem Management als PeopleCert-akkreditierte ITIL®-Practice ab, verknüpft Incidents, Probleme und Changes und bietet Known-Error-Datenbank und CMDB. Änderungen werden automatisch historisiert. Die Analysemethoden selbst wendet das Team an, die Ergebnisse bleiben im System nachvollziehbar.

Quellen und weiterführende Artikel

Quellen

• Lean Enterprise Institute: 5 Whys
• Institute for Healthcare Improvement: Cause and Effect Diagram
• Oregon State University Extension: Statistical Process Control, Part 3: Pareto Analysis and Check Sheets
• NASA Office of Safety and Mission Assurance: Fault Tree Handbook with Aerospace Applications (2002, PDF)
• IEC: IEC 61025:2006 Fault tree analysis
• AHRQ: Kepner-Tregoe Matrix
• Google SRE: Postmortem Culture, Example Postmortem und Introduction
• Microsoft Learn: Entwicklung einer Incident-Management-Praxis (Azure Well-Architected Framework)
• PeopleCert: ITIL 4 Foundation
• Amtsblatt der EU: Verordnung (EU) 2022/2554 (DORA)

Weiterlesen im Glossar und in der Wissenswelt

• RCA im Problem Management und Problem Management nach ITIL
• Incident und Was ist ITIL Incident Management?
• Change Management und CMDB
• Monitoring und KPI
• Continual Service Improvement und Kaizen