Root-Cause-Analyse
Auch: Ursachenanalyse · Root Cause Analysis · RCA · 5-Why-Methode
Die Root-Cause-Analyse (RCA) ist ein strukturiertes Vorgehen, um die eigentliche Ursache eines Fehlers oder einer Störung zu finden – statt nur die Symptome zu beheben. Bekannte Methoden sind die 5-Why-Methode und das Ursache-Wirkungs-Diagramm.
Die Root-Cause-Analyse (Ursachenanalyse) fragt so lange nach dem „Warum“, bis man bei einer Ursache ankommt, die sich abstellen lässt. Im Support ist sie das wichtigste Werkzeug des Problem Managements: Wer nur Symptome behebt, bearbeitet dieselben Tickets immer wieder.
Die 5-Why-Methode
Die einfachste Methode: Man fragt etwa fünfmal hintereinander „Warum?“. Die Zahl fünf ist ein Richtwert, kein Gesetz – manchmal reichen drei Fragen, manchmal braucht es mehr.
| Frage | Antwort |
|---|---|
| Warum haben sich so viele Kund*innen beschwert? | Ihre Bestellungen kamen zu spät an. |
| Warum kamen sie zu spät an? | Sie wurden einen Tag später verschickt als zugesagt. |
| Warum wurden sie später verschickt? | Die Packliste wurde erst am Folgetag gedruckt. |
| Warum wurde sie erst am Folgetag gedruckt? | Der automatische Export lief nach der Umstellung nur noch einmal am Abend. |
| Warum lief er nur noch abends? | Bei der Umstellung wurde der Zeitplan nicht übernommen, und niemand hat ihn geprüft. |
Die Ursache ist kein „Fehler im Lager“, sondern eine fehlende Prüfung bei Umstellungen. Die Maßnahme: Zeitpläne nach jeder Änderung kontrollieren (siehe Change Management).
Weitere Methoden
- Ursache-Wirkungs-Diagramm (Fischgräten- oder Ishikawa-Diagramm): Mögliche Ursachen werden nach Bereichen gesammelt, etwa Mensch, Methode, Material, Maschine, Umfeld. Gut für Workshops mit mehreren Beteiligten.
- Pareto-Analyse: Ursachen nach Häufigkeit sortieren. Oft verursachen wenige Ursachen einen Großteil der Tickets – dort lohnt sich die Arbeit zuerst.
- Zeitleiste: Bei einem Major Incident alle Ereignisse minutengenau aufschreiben. Lücken und Verzögerungen werden sichtbar.
Gute Praxis
- Nicht bei einer Person enden: „Kollege X hat vergessen …“ ist selten die Ursache. Die Frage ist, warum der Ablauf das Vergessen zugelassen hat.
- Mit Daten arbeiten: Tickets, Zeitstempel und Kategorien liefern Belege statt Vermutungen.
- Maßnahmen festhalten: Jede Analyse endet mit einer konkreten Aufgabe, einer verantwortlichen Person und einem Termin.
- Wirkung prüfen: Nach einigen Wochen nachsehen, ob die Tickets zu diesem Thema tatsächlich zurückgehen.
Wann sich eine RCA lohnt
- nach jedem Major Incident
- wenn dieselbe Störung mehrfach auftritt
- wenn eine Kategorie überdurchschnittlich viele Fristen reißt
- bei einer hohen Reopen-Rate in einem Thema
- bei wiederkehrenden Beschwerden
Wie Eskalationen und Ursachenarbeit zusammenhängen, beschreibt der Ratgeber Eskalationsmanagement.
Das Ergebnis festhalten
Eine kurze Zusammenfassung reicht: Was ist passiert, was war die Ursache, welche Maßnahme folgt, wer ist verantwortlich, bis wann. Gehört dazu ein Workaround, wandert er in die Wissensdatenbank.
Mehrere Ursachen
Nicht jede Störung hat genau eine Ursache. Oft treffen mehrere Faktoren zusammen: ein technischer Fehler, eine fehlende Prüfung und eine unklare Zuständigkeit. Die 5-Why-Methode kann in solchen Fällen mehrere Äste bekommen. Das ist kein Mangel der Analyse, sondern ein Hinweis darauf, dass auch die Maßnahmen an mehreren Stellen ansetzen müssen.
So hilft rapidFOX
Die Monatsauswertung in rapidFOX zeigt je Kategorie, wie viel hereinkommt und wo Fristen verfehlt werden – ein guter Startpunkt für die Frage nach dem Warum. Der Verlauf jedes Tickets steht als Zeitachse mit allen Ereignissen bereit, und die Mastersuche findet ähnliche Fälle auch über Text in Anhängen. Mehr unter Helpdesk-Reporting.
Häufige Fragen
Muss man bei der 5-Why-Methode genau fünfmal fragen?
Nein. Fünf ist ein Richtwert. Man fragt so lange, bis man bei einer Ursache ankommt, die sich durch eine konkrete Maßnahme abstellen lässt.
Was ist der Unterschied zwischen Root-Cause-Analyse und Problem Management?
Die Root-Cause-Analyse ist eine Methode, um Ursachen zu finden. Problem Management ist die Praxis, in der solche Analysen stattfinden und aus der dauerhafte Lösungen angestoßen werden.
Verwandte Begriffe
Problem Management ist nach ITIL die Praxis, die Ursachen von Störungen (Incidents) findet und dauerhaft besei...
Ein Major Incident ist eine Störung mit erheblichen Auswirkungen auf das Geschäft, die sofort und koordiniert...
Ein Known Error ist nach ITIL ein Problem, das analysiert, aber noch nicht gelöst ist. Ursache und meist ein W...
Change Management (in ITIL 4: Change Enablement) sorgt dafür, dass Änderungen an IT-Services kontrolliert gepl...
rapidFOX 7 Tage kostenlos testen
Ticketsystem & Helpdesk mit lokaler KI – DSGVO-konform, Serverstandort Deutschland. Ohne Kreditkarte, in 2 Minuten startklar.
Jetzt kostenlos starten