Tool für die Ursachenanalyse von IT-Incidents
Fünf strukturierte Durchgänge über Ihre eigenen Incident-Belege – Ist/Ist-nicht, Fishbone, Five Whys, Pareto, Change-Korrelation – dann eine gewichtete Liste der Ursachen und der Lücken, die Sie zuerst schließen sollten.
- Nach Belegen gewichtet
- Fünf Methoden in einem Durchgang
- Läuft in Ihrem Browser
Eine Grundursache muss erklären, was verschont blieb und was ausfiel: Wenn nur die Filialen in Riad keine Kartenzahlungen mehr annehmen konnten, muss die Ursache erklären, warum Dschidda nicht betroffen war. Dieses Tool bewertet jeden Kandidaten mit bis zu 100 Punkten anhand Ihrer Belege: Ist/Ist-nicht 35 Punkte, Change-Korrelation 20, Pareto 20, Five Whys 15 und Inversion 10. Ein Change, der nach dem Symptom datiert ist, wird ausgeschlossen.
Das Symptom
Wann es zuerst beobachtet wurde. Jeder Change, den Sie später eintragen, wird gegen diesen Zeitpunkt geprüft.
Mögliche Ursachen
Benennen Sie, was es sein könnte, in einer beliebigen Fishbone-Kategorie, und beantworten Sie dann, was Sie über jede tatsächlich wissen. Leere Antworten werden als Lücken gemeldet, nicht als Nein.
Der Inversionstest
Wenn Sie das morgen absichtlich herbeiführen wollten, wie würden Sie vorgehen? Benennen Sie die Hebel, die Sie ziehen würden, und haken Sie dann die an, die tatsächlich vorhanden waren.
Was die Belege stützen
Aktualisiert sich während der Eingabe. Die Punktzahlen gehen bis 100 und spiegeln nur wider, was Sie eingegeben haben.
Häufigkeit und Auswirkung sind Ihre Zahlen. Ein Kandidat ohne Anzahl und ohne Auswirkung hat kein Pareto-Gewicht — er ist nicht ausgeschlossen, nur nicht gemessen.
So erhalten Sie eine brauchbare Antwort
Die Rangfolge ist nur so gut wie die Belege dahinter. Deshalb bewertet das Tool getrennt, wie viel Sie beantwortet haben und wie stark der Fall ist. Ein Kandidat mit 30 Punkten und allen beantworteten Fragen ist eine schwache Ursache; ein Kandidat mit 30 Punkten und der Hälfte unbeantworteter Fragen ist eine ungeprüfte. Beide brauchen unterschiedliche Arbeit.
Arbeiten Sie quer über die Kandidaten statt einen nach dem anderen ab. Benennen Sie zuerst vier oder fünf in verschiedenen Fishbone-Kategorien, beantworten Sie dann das Ist/Ist-nicht-Paar für alle, danach die Anzahlen. Wer einen Kandidaten erschöpfend untersucht, bevor er die anderen ansieht, beweist am Ende eine Lieblingstheorie, statt sie zu prüfen.
Was jeder Durchgang beiträgt
- Ist / Ist nicht (35 Punkte). Kepner-Tregoe. Das stärkste Unterscheidungsmerkmal, das Sie haben: Eine echte Ursache erklärt die Grenze ebenso wie den Fehler.
- Change-Korrelation (20). Die meisten Incidents folgen auf einen Change. Ein Change, der nach dem Symptom datiert ist, wird ohne Weiteres ausgeschlossen.
- Pareto (20). Häufigkeit × Auswirkung, relativ zum schwersten Kandidaten, damit der Aufwand bei den entscheidenden wenigen landet.
- 5 Whys (15). Erreichte Tiefe, ohne sich zu wiederholen.
- Inversionstest (10). Der Sabotagehebel, der sich als real herausgestellt hat.
Methode & Urheberschaft
Fünf Durchgänge über die Belege, die Sie liefern: Kepner-Tregoe Ist/Ist-nicht (35 Punkte), Change-Korrelation (20, mit hartem Ausschluss für jeden Change, der nach dem Symptom datiert ist), Pareto nach Häufigkeit × Auswirkung (20), Tiefe der 5 Whys ohne wiederholte Antworten (15) und ein Inversionstest (10). Es werden keine externen Daten verwendet und nichts wird gespeichert.
Die hier verwendeten Formeln sind etablierte, veröffentlichte Methoden. Umsetzung, Oberfläche, Texte, Auswertungslogik und Richtwerte sind eigene Arbeit von ITSM Compass. Die Ergebnisse sind Schätzungen, keine professionelle Beratung. Siehe die Nutzungsbedingungen.
© 2026 ITSM Compass. Alle Rechte vorbehalten.
Fragen
Errät das Tool die Ursache für mich?
Nein. Es hat keine Datenbank typischer Ursachen, und nichts wird irgendwohin gesendet. Es nimmt die Kandidaten, die Sie benennen, und die Belege, die Sie für jeden angeben, wendet fünf etablierte Techniken an und zeigt Ihnen, welchen Kandidaten die Belege tatsächlich stützen — und welche Fragen Sie noch nicht beantwortet haben.
Warum fragt es immer wieder, was NICHT betroffen ist?
Weil genau diese Frage Ursachen voneinander trennt. Viele Erklärungen passen zum Fehler; sehr wenige erklären auch, warum die verschonten Standorte, Nutzer oder Transaktionen verschont blieben. Ein Kandidat, der den Fehler erklärt, aber nicht die Grenze, verbirgt meist einen Unterschied, den sich niemand angesehen hat.
Was ist der Inversionstest?
Sie fragen, wie Sie das Problem absichtlich herbeiführen würden, wenn Sie es wollten. Die Sabotage-Perspektive überwindet Abwehrhaltung — Menschen beschreiben bereitwillig einen fragilen Genehmigungsschritt oder ein gemeinsam genutztes Konto, das sie nie als Fehler ihres eigenen Teams nennen würden. Jeder Hebel, der sich als tatsächlich vorhanden herausstellt, wird selbst zu einer möglichen Ursache.
Warum wird ein Kandidat vollständig ausgeschlossen?
Wenn Sie ein Change-Datum angeben, das nach dem ersten Auftreten des Symptoms liegt, kann der Change es nicht verursacht haben, was auch immer er sonst erklärt. Das ist der einzige harte Ausschluss im Tool; alles andere ist gewichtet, nicht absolut.
Wie viele Warum-Fragen sollte ich erreichen?
Drei bis fünf. Das Tool zählt die Tiefe, ignoriert aber jedes Warum, das die vorherige Antwort nur umformuliert, denn genau dort bleiben Ketten normalerweise stecken: Die Worte ändern sich, das Denken nicht.
Werden meine Incident-Daten irgendwo gespeichert?
Nein. Es läuft vollständig in Ihrem Browser, es gibt kein Konto, und nichts wird auf einen Server oder in den lokalen Speicher geschrieben. Schließen Sie den Tab, und alles ist weg.
Ursachen kommen immer wieder?
Ein Problem Management Review findet die Muster hinter wiederkehrenden Incidents und legt die Verantwortung für die Lösungen fest, die sie stoppen.