Root Cause Analysis für kleine IT-Teams: sieben Methoden mit Praxisbeispielen

Root Cause Analysis (RCA) heißt, bei einer Störung so lange nachzuforschen, bis klar ist, warum sie aufgetreten ist, und genau dort anzusetzen. Welche Methode dafür passt, hängt davon ab, wie viel Zeit, Daten und Erfahrung ein Team mitbringt.

Im kleinen IT-Team fehlt selten der Wille zur Ursachenforschung, meist fehlt die Zeit. Der Drucker läuft wieder, der Benutzer kann sich anmelden, das nächste Ticket wartet. Kommt dieselbe Störung zwei Wochen später zurück, hat sich die schnelle Lösung als teuer erwiesen. Die gute Nachricht: Mehrere Methoden der Ursachenanalyse brauchen weder eigenes Personal noch spezielle Software. Dieser Artikel stellt sieben davon vor, sortiert nach Aufwand, jeweils mit Einsatzzweck, Vorgehen, Stolpersteinen und einem Beispiel. Wie eine RCA formal im Problem Management abläuft, beschreibt der Glossarartikel RCA.

Das Wichtigste in Kürze

• Schnell starten: Zeitleiste, Change-Analyse und 5 Why gehen mit Bordmitteln und oft noch am selben Tag.
• Für hartnäckige Fälle: Ishikawa, Pareto, Kepner-Tregoe und Fehlerbaum brauchen mehr Vorbereitung, finden aber auch verdeckte Ursachen.
• Erst beim Anbieter nachsehen: Bei Störungen in Microsoft 365 zeigt die Dienstintegrität im Admin Center, ob Microsoft selbst ein Problem meldet.
• Dienstleister einbinden: Wer Netzwerk, Server oder Firewall extern betreuen lässt, braucht dessen Änderungen und Logs für die Analyse.

Stand: November 2026 · Fachlich abgeglichen mit Lean Enterprise Institute, Google SRE, Microsoft Learn, NASA und AHRQ (Quellen am Ende des Artikels)

Drei Methoden für den schnellen Einstieg

Diese drei Methoden kommen mit dem aus, was in fast jeder IT ohnehin vorhanden ist: Tickets, Logdateien, Kalender und das Gedächtnis des Teams.

Zeitleiste: Was ist wann passiert?

Wofür: Eine Zeitleiste ordnet alle Ereignisse rund um eine Störung chronologisch. Sie macht sichtbar, was vor dem ersten Ticket geschah, und verhindert, dass jede Person ihre eigene Version der Geschichte erzählt. Im veröffentlichten Beispiel-Postmortem von Google steht die Zeitleiste im Zentrum des Berichts.

So gehen Sie vor: Sammeln Sie die Uhrzeiten aus Tickets, Monitoring-Meldungen, Ereignisanzeigen, Mails und Teams-Chats. Schreiben Sie alles mit Datum, Uhrzeit und Quelle untereinander. Markieren Sie, wann die Störung begann, wann sie bemerkt wurde und wann sie behoben war.

Darauf achten: Gleichzeitig heißt nicht ursächlich. Achten Sie auf Zeitzonen und falsch gehende Uhren, etwa bei Geräten ohne Zeitsynchronisierung.

Beispiel: Angenommen, in einer Kanzlei friert jeden Montag gegen neun Uhr die Dokumentenablage ein. Die Zeitleiste über drei Wochen zeigt: Genau dann startet auf dem Dateiserver eine vollständige Virenprüfung, die jemand nach einer Neuinstallation falsch geplant hat. Erst als die Prüfung probeweise in die Nacht verschoben wird und das Einfrieren ausbleibt, ist der Zusammenhang belegt.

Change-Analyse: Was hat sich geändert?

Wofür: Hat etwas gestern noch funktioniert, liegt die Frage nach Änderungen nahe. Laut Google SRE gehen rund 70 Prozent der Ausfälle auf Änderungen an einem laufenden System zurück. Die Change-Analyse vergleicht systematisch den Zustand vor und nach der Störung oder ein betroffenes mit einem nicht betroffenen System.

So gehen Sie vor: Listen Sie alle Änderungen der letzten Tage auf: Windows- und Programm-Updates, neue Richtlinien, getauschte Hardware, geänderte Firewall-Regeln, neue Mitarbeitende mit anderen Rechten. Fragen Sie auch beim Dienstleister nach, was er geändert hat. Prüfen Sie dann für jede Änderung, ob sie die Störung erklären kann.

Darauf achten: Was nicht dokumentiert ist, taucht in keiner Liste auf. Und manchmal macht eine harmlose Änderung nur einen alten Fehler sichtbar.

Beispiel: Angenommen, seit Mittwoch können zwei Kolleginnen in der Buchhaltung keine Rechnungen mehr aus dem ERP drucken, alle anderen schon. Der Vergleich zeigt: Nur ihre Geräte haben am Dienstag ein Funktionsupdate erhalten, das einen älteren Druckertreiber nicht mehr unterstützt.

5 Why: nachfragen, bis die Ursache klar ist

Wofür: Die Methode aus dem Toyota-Produktionssystem fragt so oft nach dem Warum, bis eine Ursache erreicht ist, die sich beseitigen lässt. Das Lean Enterprise Institute betont: Die Zahl fünf ist nicht der Punkt, entscheidend ist das Weiterfragen.

So gehen Sie vor: Schreiben Sie das Problem als einen klaren Satz auf. Beantworten Sie jede Frage nur mit dem, was Sie wissen oder prüfen können. Reicht das Wissen nicht, wird die Frage zur Aufgabe.

Darauf achten: Die Methode verleitet dazu, bei einer Person hängen zu bleiben. „Kollege hat falsch geklickt“ ist keine Ursache, sondern die Frage, warum der falsche Klick möglich war.

Beispiel: Angenommen, das Backup einer Arztpraxis ist fehlgeschlagen. Warum? Die externe Festplatte war nicht angesteckt. Warum? Sie wird jeden Abend gewechselt. Warum wurde sie nicht gewechselt? Die zuständige Mitarbeiterin war auf Urlaub. Warum hat das niemand bemerkt? Es gibt keine Benachrichtigung bei fehlgeschlagenem Backup. Die Maßnahme ist eine Warnmeldung per Mail und eine Vertretungsregel, nicht ein Rüffel.

Vier Methoden für hartnäckige Fälle

Manche Störungen lassen sich mit einer Zeitleiste und ein paar Fragen nicht knacken: Sie treten sporadisch auf, betreffen nur einzelne Standorte oder haben mehrere Ursachen gleichzeitig. Dann lohnt sich mehr Struktur.

Ishikawa-Diagramm: alle Verdächtigen auf einem Blatt

Wofür: Das Fischgrätendiagramm nach Kaoru Ishikawa sammelt mögliche Ursachen in Kategorien. So denkt das Team nicht nur an die Technik, sondern auch an Abläufe, Menschen und Umgebung. Das Institute for Healthcare Improvement empfiehlt, die Kategorien an den eigenen Prozess anzupassen.

So gehen Sie vor: Zeichnen Sie das Problem als Fischkopf an ein Whiteboard oder in ein gemeinsames Whiteboard in Microsoft Teams. Gräten für die IT könnten sein: Hardware, Software, Netzwerk, Bedienung, Abläufe, externe Partner. Danach prüfen Sie die drei wahrscheinlichsten Ursachen.

Darauf achten: Das Diagramm sammelt Vermutungen. Erst die Prüfung macht daraus eine Ursache.

Pareto: die großen Brocken zuerst

Wofür: Die Pareto-Analyse zeigt, welche wenigen Ticketkategorien den Großteil der Arbeit verursachen. Der Qualitätsexperte J. M. Juran nannte sie die „vital few“. Das bekannte Verhältnis 80 zu 20 ist laut Oregon State University nur ein Richtwert.

So gehen Sie vor: Exportieren Sie die Tickets der letzten drei Monate, zählen Sie sie je Kategorie, sortieren Sie absteigend und tragen Sie den kumulierten Anteil in ein Balkendiagramm ein. Die obersten zwei oder drei Kategorien kommen auf die Liste für die nächste Ursachenanalyse.

Darauf achten: Die Auswertung ist nur so gut wie die Kategorien. Landen viele Tickets unter „Sonstiges“, lohnt es sich, zuerst die Kategorien zu bereinigen.

Kepner-Tregoe: genau abgrenzen

Wofür: Die Problemanalyse nach Kepner und Tregoe fragt nicht nur, wo ein Fehler auftritt, sondern auch, wo er auftreten könnte und es nicht tut. Die Ist-/Ist-nicht-Matrix (AHRQ) betrachtet dazu Was, Wo, Wann und Ausmaß.

So gehen Sie vor: Legen Sie eine Tabelle an: links, was betroffen ist, rechts, was vergleichbar wäre, aber funktioniert. Suchen Sie die Unterschiede und fragen Sie, was sich dort geändert hat. Jede Ursache muss alle Einträge beider Spalten erklären.

Darauf achten: Die Matrix kostet Zeit. Für einen einzelnen Arbeitsplatz ist sie zu viel, bei Störungen an mehreren Standorten spielt sie ihre Stärke aus.

Fehlerbaum: wenn trotz Ausfallsicherheit etwas ausfällt

Wofür: Die Fehlerbaumanalyse beginnt beim unerwünschten Ereignis und leitet über UND- und ODER-Verknüpfungen ab, welche Ausfälle allein oder in Kombination dorthin führen. Das NASA Fault Tree Handbook beschreibt sie als deduktives, rückwärts gerichtetes Verfahren.

So gehen Sie vor: Oben steht etwa „Kassen in der Filiale arbeiten nicht“. Darunter alles, was dazu führen kann: Internetleitung und Ersatzleitung (beide gemeinsam), Kassenserver, Stromversorgung, Zahlungsdienstleister. So zeigt sich, wo eine scheinbare Redundanz an einem gemeinsamen Bauteil hängt.

Darauf achten: Ein vollständiger Fehlerbaum ist Arbeit für Fachleute. Für kleine Teams reicht oft eine vereinfachte Skizze für den kritischsten Dienst.

Welche Methode passt zu welchem Fall?

So läuft eine Ursachenanalyse im kleinen IT-Team

Eine Ursachenanalyse muss kein Projekt sein. In vielen Fällen reicht ein fester Ablauf in fünf Schritten:

1. Auslöser festlegen: Zum Beispiel jede Störung, die mehr als einen Arbeitsplatz betrifft, oder jede, die innerhalb eines Monats wiederkommt.
2. Belege sichern: Logs, Screenshots und Fehlermeldungen speichern, bevor ein Neustart sie löscht.
3. Beim Anbieter nachsehen: Für Microsoft 365 zeigt die Dienstintegrität im Admin Center, ob ein bekanntes Problem vorliegt, an dem Microsoft bereits arbeitet.
4. Methode wählen und analysieren: nach der Tabelle oben, mit allen Beteiligten, auch dem Dienstleister.
5. Ergebnis festhalten und nachfassen: Ursache, Workaround und Maßnahme dokumentieren und nach einigen Wochen prüfen, ob die Störung weggeblieben ist.

Beispiel: abbrechende Teams-Besprechungen an einem Standort

Angenommen, ein Handelsunternehmen hat Standorte in Wien, Linz und Graz. Seit einer Woche brechen in Linz Teams-Besprechungen nach einigen Minuten ab, in Wien und Graz nicht. Die Dienstintegrität in Microsoft 365 meldet keine Störung. Die Zeitleiste zeigt, dass die ersten Tickets am Morgen nach einem Wartungsabend eingingen. Die Change-Analyse mit dem externen Netzwerkpartner ergibt: An diesem Abend wurde in Linz die Firewall getauscht. Die Kepner-Tregoe-Abgrenzung bestätigt das Bild: betroffen sind nur Audio und Video, nicht Chat und Dateien, und nur Geräte im Linzer Netz, nicht dieselben Notebooks im Homeoffice. Der Partner findet eine fehlende Freigabe für die Medienverbindungen von Teams. Die Ursache ist behoben, der Ablauf für künftige Firewall-Tausche um einen Teams-Test erweitert.

Mit dem Dienstleister analysieren

Gerade wenn Netzwerk, Server oder Microsoft 365 extern betreut werden, liegt ein Teil der Antworten beim Partner. Klären Sie deshalb vorab: Wer informiert wen über Änderungen? Wie schnell bekommen Sie Logs und Konfigurationsstände? Wer nimmt an der Analyse teil? Halten Sie Ergebnisse in Ihrem eigenen Ticketsystem fest, damit das Wissen bei einem Wechsel des Partners nicht verloren geht.

ky2help^® unterstützt solche Abläufe mit Workflows, die sich im Prozessdesigner per Drag-and-Drop anpassen lassen, mit Schnittstellen zu E-Mail und MS Teams im Standard und mit einer Known-Error-Datenbank für dokumentierte Ursachen und Workarounds.

ky2help® für IT-Teams

Checkliste: woran Ursachenanalysen im Alltag scheitern

Die meisten Analysen scheitern nicht an der Methode, sondern an kleinen Versäumnissen. Prüfen Sie vor dem Abschluss:

• Ist das Problem in einem Satz beschrieben? „Internet geht nicht“ reicht nicht. „Seit Montag brechen Teams-Anrufe in Linz nach fünf Minuten ab“ schon.
• Sind die Belege gesichert? Ereignisanzeige, Firewall-Log und Fehlermeldungen sind nach einem Neustart oft weg.
• Wurde der Dienstleister gefragt? Viele Änderungen passieren außerhalb des eigenen Sichtfelds.
• Erklärt die Ursache alle Beobachtungen? Bleibt ein Fall unerklärt, ist die Analyse nicht fertig.
• Ist die Ursache getestet? Ein Rückbau auf einem Testgerät oder eine gezielte Wiederholung schafft Gewissheit.
• Steht eine Person im Mittelpunkt? Dann fehlt die Frage, warum das System den Fehler zugelassen hat. Microsoft Learn beschreibt die Nachbetrachtung ausdrücklich als schuldfreien Prozess.
• Gibt es einen Termin zur Nachkontrolle? Erst wenn die Störung über Wochen ausbleibt, war die Maßnahme wirksam.

Eine Zahl, die sich lohnt

Wer nur eine Kennzahl verfolgen will, nimmt die Wiederkehrer: Tickets, die innerhalb von vier Wochen mit demselben Fehlerbild erneut eingehen. Sinkt ihre Zahl, wirken die Analysen. Mehr zu sinnvollen Messgrößen im Glossarartikel KPI, zu festen Abläufen für wiederkehrende Aufgaben unter Standard Operating Procedure.

Häufige Fragen zur Ursachenanalyse im IT-Team

Welche Ursachenanalyse eignet sich für kleine IT-Teams?

Für den Einstieg eignen sich Zeitleiste, Change-Analyse und 5 Why. Sie brauchen keine spezielle Software und lassen sich oft in einer kurzen Besprechung durchführen. Für Störungen an mehreren Standorten lohnt sich zusätzlich die Abgrenzung nach Kepner-Tregoe.

Was ist eine Change-Analyse?

Eine Change-Analyse vergleicht den Zustand vor und nach einer Störung oder ein betroffenes mit einem nicht betroffenen System. Sie listet alle Änderungen im fraglichen Zeitraum auf, etwa Updates, Richtlinien oder getauschte Hardware, und prüft, welche davon die Störung erklären kann.

Was ist der Unterschied zwischen Auslöser und Ursache?

Der Auslöser ist das Ereignis, das eine Störung sichtbar macht, etwa ein Update oder ein Lastanstieg. Die Ursache ist der Zustand, der die Störung erst möglich macht, etwa ein veralteter Treiber oder fehlende Kapazität. Wer nur den Auslöser behandelt, erlebt die Störung beim nächsten Anlass erneut.

Woran erkennt man, dass die Ursache wirklich gefunden ist?

Die Ursache erklärt alle Beobachtungen, auch die nicht betroffenen Fälle, und lässt sich mit einem Test bestätigen, etwa durch einen Rückbau auf einem Gerät. Zusätzliche Sicherheit gibt die Nachkontrolle: Bleibt die Störung nach der Maßnahme über Wochen aus, spricht das für die Analyse.

Braucht man für ein Ishikawa-Diagramm eine spezielle Software?

Nein. Ein Whiteboard, ein Flipchart oder ein gemeinsames digitales Whiteboard reichen aus. Wichtiger als das Werkzeug sind passende Kategorien und die anschließende Prüfung der wahrscheinlichsten Ursachen.

Wo hält ein Team in ky2help® Ursachen und Workarounds fest?

ky2help® hält Ursachen und Workarounds in der Known-Error-Datenbank und in der Knowledge Base fest und verknüpft Incidents, Probleme und Changes. Abläufe passen Sie im Prozessdesigner ohne Programmierung an. Die Testversion läuft im Browser, ohne Installation.

Quellen und weiterführende Artikel

Quellen

• Google SRE: Example Postmortem, Introduction und Postmortem Culture
• Lean Enterprise Institute: 5 Whys
• Microsoft Learn: So überprüfen Sie den Microsoft 365-Dienststatus und Entwicklung einer Incident-Management-Praxis (Azure Well-Architected Framework)
• Institute for Healthcare Improvement: Cause and Effect Diagram
• Oregon State University Extension: Pareto Analysis and Check Sheets
• AHRQ: Kepner-Tregoe Matrix
• NASA: Fault Tree Handbook with Aerospace Applications (PDF)

Weiterlesen im Glossar und auf kyberna.at

• RCA und Incident
• Helpdesk und Monitoring
• Standard Operating Procedure und Knowledge Base
• Microsoft 365 mit KYBERNA und ky2help® für IT-Dienstleister
• Problem Management nach ITIL