Problem Review: Wiederkehrende Incidents finden
Finden Sie die Incidents, die Sie immer wieder lösen, klären Sie den wichtigsten per strukturierter Ursachenanalyse und legen Sie fest, wer für den Abschluss verantwortlich ist. Drei Tools, eine Sitzung, nichts wird hochgeladen.
- Findet wiederkehrende Muster
- Fünf strukturierte RCA-Durchgänge
- Nichts verlässt Ihren Browser
Ein Problem Review durchsucht aktuelle Incidents nach wiederkehrenden Mustern, wählt die aus, die eine Untersuchung lohnen, und legt für jedes einen Verantwortlichen fest. Das Dashboard markiert einen Kandidaten, wenn sich mindestens fünf Incidents Kategorie, Configuration Item und ähnliche Formulierung teilen, und stuft jene höher ein, die in den letzten 14 Tagen zugenommen haben. Gleichen Sie einen Trend mit Ramadan, Eid und Monatsabschluss ab, bevor Sie ihm trauen. Kandidaten sind für das Review gedacht, sie sind keine bestätigten Problems.
Die meisten Service Desks lösen denselben Incident viele Male. Problem Management ist die Praxis, die das verhindern soll, und sie wird am häufigsten übersprungen – nicht weil Teams sie ablehnen, sondern weil sie bewusst Zeit abseits der Queue braucht und weil die Übergabe vom Incident zum Problem meist als Bauchgefühl statt als Beleg ankommt.
Diese drei Tools schließen diese Lücke in einer Sitzung. Ihr Incident-Export verlässt nie den Browser.
1. Die Muster finden
Legen Sie einen Incident-Export ab. Incidents mit gleicher Kategorie, gleichem Configuration Item und ähnlicher Formulierung werden gruppiert und dann nach Volumen, nach dem Schweregrad der schwersten Tickets der Gruppe und danach gewichtet, ob die Rate in den letzten zwei Wochen gestiegen ist.
2. Den wichtigsten erklären
Übernehmen Sie einen Kandidaten direkt in den Analyser und unterziehen Sie ihn fünf strukturierten Durchgängen – Ist/Ist-nicht, Fishbone, Five Whys, Pareto und Change-Korrelation. Der Kandidat wird übernommen; Sie müssen ihn nicht neu eingeben.
3. Festlegen, wer abschließt
Ein wiederkehrendes Muster ohne Verantwortlichen bleibt ein wiederkehrendes Muster. Klären Sie, ob es zu Incident oder Problem gehört, wer für den Abschluss verantwortlich ist und mit welchen Worten ein Stakeholder zustimmt.
Ein Problem Review, das etwas verändert
- Bringen Sie Belege mit, keine Eindrücke. Ein Kandidat enthält seine Incident-Anzahl, seinen Zeitraum, die Verteilung der Prioritäten und Beispiel-Ticketnummern. Das macht aus „das passiert ständig“ etwas, worauf ein Change Advisory Board reagiert.
- Nehmen Sie einen Kandidaten, nicht fünf. Ein Review, das fünf Problem-Datensätze eröffnet und keinen schließt, ist schlechter als eines, das einen einzigen eröffnet und zu Ende bringt.
- Bevorzugen Sie steigende Muster gegenüber großen. Eine lang bestehende Gruppe von P4 ist oft ein bekanntes Ärgernis mit Workaround. Eine Gruppe, die in den letzten zwei Wochen stark gestiegen ist, geht meist auf eine kürzliche Änderung zurück – und was geändert wurde, lässt sich zurückändern.
- Prüfen Sie den Kalender, bevor Sie einem Trend trauen. Volumen schwanken rund um Ramadan, Eid und den Monatsabschluss. Der GCC-Geschäftszeitenkalender legt die Arbeitswochen und Feiertage fest, an denen jedes Lab-Tool misst.
- Halten Sie fest, was Sie bewusst nicht weiterverfolgen. Nächsten Monat sehen Sie sich dieselbe Liste an. Wer weiß, warum ein Kandidat zurückgestellt wurde, muss dieselbe Diskussion nicht zweimal führen.
Methode & Urheberschaft
Kandidaten stammen aus dem Service-Desk-Dashboard, das Incidents nach Kategorie, Configuration Item und ähnlichen Kurzbeschreibungen gruppiert, mindestens fünf Incidents pro Gruppe verlangt und die letzten 14 Tage mit bis zu 90 Tagen davor auf einen Anstieg prüft. Die Gewichtung berücksichtigt die schwersten Tickets einer Gruppe statt des Durchschnitts. Kandidaten sind Ausgangspunkte für eine Untersuchung, keine bestätigten Problems, und jeder Schritt läuft in Ihrem Browser.
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
Was ist ein Problem Review?
Eine regelmäßige Sitzung, die aktuelle Incidents nach wiederkehrenden Mustern durchsucht, die auswählt, die eine Untersuchung lohnen, und für jedes einen Verantwortlichen festlegt. Es ist die Praxis, die die meisten Service Desks auf dem Papier haben und nur wenige ernsthaft betreiben, weil sie Zeit abseits der reaktiven Queue braucht.
Wie wird ein Problem-Kandidat gefunden?
Das Dashboard gruppiert Incidents mit gleicher Kategorie, gleichem Configuration Item und ähnlicher Formulierung und gewichtet die Gruppen dann nach Volumen, nach dem Schweregrad ihrer schwersten Tickets und danach, ob die Rate in den letzten 14 Tagen gegenüber den Wochen davor gestiegen ist. Gruppen mit weniger als fünf Incidents werden ignoriert. Es sind Kandidaten für das Review, keine bestätigten Problems.
Welche Daten brauche ich?
Einen Incident-Export aus ServiceNow, Jira, Freshservice oder einem anderen Tool, das eine CSV-Datei mit Datum, Priorität, Kategorie und Kurzbeschreibung erzeugt. Etwa drei Wochen Historie sind das Minimum, damit der Trendtest aussagekräftig ist; mehr ist besser.
Verlassen meine Ticketdaten meinen Rechner?
Nein. Der Export wird in Ihrem Browser gelesen und nie hochgeladen. Es gibt kein Konto und keinen Server – genau deshalb läuft dies als Satz von Browser-Tools statt als Plattform. Schließen Sie den Tab, und der Export ist weg; das Dashboard speichert in diesem Browser den Dateinamen und die 12 häufigsten Kategorien mit Jahresvolumen für den Shift-Left-Rechner.
Warum braucht die Ursachenanalyse ein eigenes Tool?
Weil ein Muster zu finden und es zu erklären unterschiedliche Aufgaben sind. Der Analyser führt fünf strukturierte Durchgänge über Ihre Belege aus – Ist/Ist-nicht, Fishbone, Five Whys, Pareto und Change-Korrelation –, damit die Schlussfolgerung auf den Belegen beruht und nicht darauf, wer zuletzt gesprochen hat.
Wie oft sollten wir das durchführen?
Für die meisten Service Desks passt ein monatlicher Rhythmus. Die Musterdaten brauchen Zeit, um sich anzusammeln, und die daraus folgenden Maßnahmen brauchen Zeit, um vor dem nächsten Durchgang zu wirken.
Niemand hat Zeit für das Problem Review?
Das ist der übliche Grund, warum es nie stattfindet. Ein Fractional Service Delivery Manager kann es monatlich durchführen und die Maßnahmen bis zum Abschluss begleiten.