Betrieb läuft wieder, Ursache noch offen
Die eine Practice holt den Betrieb zurück, die andere sorgt dafür, dass er nicht wieder wegbricht. An der Grenze dazwischen entscheidet sich, ob dein Team lernt oder nur löscht.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer beides gleichzeitig macht, macht am Ende nur Incidents
Der Anruf kommt kurz vor neun, ein Fachbereich kann nicht arbeiten, alles andere wird zur Seite gelegt. Das ist richtig so. Falsch wird es erst danach, wenn niemand die Frage nach dem Warum stellt, weil die nächste Störung schon in der Leitung hängt.
Der Preis dieser Reihenfolge fällt nicht sofort an. Er zeigt sich ein halbes Jahr später an einem Ticketaufkommen, das nicht sinkt, obwohl das Team schneller geworden ist. Kapazität, die in immer denselben Störungen verbrennt, fehlt an jeder Stelle, an der etwas Neues entstehen soll.
Dazu kommt ein Vertrauensschaden. Wenn dieselbe Störung zum dritten Mal auftritt und die Fachseite dieselbe Erklärung hört, wird jede Zusage aus dem Service Level Agreement zur Formsache.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der direkte Vergleich
Incident Management
die Practice, die den vereinbarten Betrieb so schnell wie möglich wiederherstellt
Problem Management
die Practice, die Ursachen analysiert und Fehlerbilder dauerhaft beseitigt
| Entscheidungsfrage | Incident Management | Problem Management |
|---|---|---|
| Was hilft, während der Betrieb gerade steht? | Stärke Greift sofort, arbeitet auf Wiederherstellung hin und darf dafür auch eine Umgehung einsetzen, deren Ursache noch unklar ist. | Schwäche Liefert in dieser Minute nichts, weil eine belastbare Ursachenanalyse Daten, Vergleichsfälle und Zeit braucht. |
| Wer verhindert, dass dieselbe Störung nächsten Monat wiederkommt? | Schwäche Schließt das Ticket, sobald der Service wieder nutzbar ist, und hat keinen Auftrag, das Muster über mehrere Fälle hinweg zu erkennen. | Stärke Nimmt Häufungen auf, arbeitet an der Ursache und schließt den Fall erst, wenn das Fehlerbild beseitigt oder die Entscheidung dagegen dokumentiert ist. |
| Wie wird die Reihenfolge der Arbeit bestimmt? | Stärke Auswirkung und Dringlichkeit ergeben die Priorität, das lässt sich in einer hinterlegten Matrix ohne Diskussion entscheiden. | Kommt darauf an Häufigkeit, Risiko und Aufwand müssen gegeneinander abgewogen werden, dafür braucht es eine feste Runde statt einer Regel im Werkzeug. |
| Was bleibt danach im Ticketsystem stehen? | Kommt darauf an Ein geschlossenes Ticket mit einem Lösungstext, der meist nur für genau diesen einen Fall taugt und selten wiedergefunden wird. | Stärke Ein Problem Record mit dokumentiertem Workaround und, nach abgeschlossener Analyse, ein Known Error mit benannter Ursache. |
| Wie leicht lässt sich der Erfolg zeigen? | Stärke Wiederherstellungszeiten und der Anteil der Störungen innerhalb der Zielzeit sind direkt ablesbar und werden ohnehin erhoben. | Schwäche Der Erfolg besteht aus ausbleibenden Störungen, also aus etwas, das nicht passiert und deshalb in keiner Standardauswertung auftaucht. |
Was hilft, während der Betrieb gerade steht?
Greift sofort, arbeitet auf Wiederherstellung hin und darf dafür auch eine Umgehung einsetzen, deren Ursache noch unklar ist.
Liefert in dieser Minute nichts, weil eine belastbare Ursachenanalyse Daten, Vergleichsfälle und Zeit braucht.
Wer verhindert, dass dieselbe Störung nächsten Monat wiederkommt?
Schließt das Ticket, sobald der Service wieder nutzbar ist, und hat keinen Auftrag, das Muster über mehrere Fälle hinweg zu erkennen.
Nimmt Häufungen auf, arbeitet an der Ursache und schließt den Fall erst, wenn das Fehlerbild beseitigt oder die Entscheidung dagegen dokumentiert ist.
Wie wird die Reihenfolge der Arbeit bestimmt?
Auswirkung und Dringlichkeit ergeben die Priorität, das lässt sich in einer hinterlegten Matrix ohne Diskussion entscheiden.
Häufigkeit, Risiko und Aufwand müssen gegeneinander abgewogen werden, dafür braucht es eine feste Runde statt einer Regel im Werkzeug.
Was bleibt danach im Ticketsystem stehen?
Ein geschlossenes Ticket mit einem Lösungstext, der meist nur für genau diesen einen Fall taugt und selten wiedergefunden wird.
Ein Problem Record mit dokumentiertem Workaround und, nach abgeschlossener Analyse, ein Known Error mit benannter Ursache.
Wie leicht lässt sich der Erfolg zeigen?
Wiederherstellungszeiten und der Anteil der Störungen innerhalb der Zielzeit sind direkt ablesbar und werden ohnehin erhoben.
Der Erfolg besteht aus ausbleibenden Störungen, also aus etwas, das nicht passiert und deshalb in keiner Standardauswertung auftaucht.
Was passt wann
- Wenn gerade Menschen nicht arbeiten können
- läuft Incident Management, und die Ursachenfrage wartet bis nach der Wiederherstellung.
- Wenn dieselbe Störung zum dritten Mal im Quartal auftaucht
- eröffne einen Problem Record und verweise die weiteren Tickets darauf, statt sie erneut einzeln zu lösen.
- Wenn ein Workaround länger als ein paar Tage trägt
- gehört er als Known Error dokumentiert, damit der Service Desk ihn findet, ohne die Ursache zu kennen.
Sechs Stationen zwischen Störung und Ursache
- 01 Der Service Desk nimmt die Störung auf und stellt den Betrieb wieder her.
- 02 Eine Häufung oder ein schwerer Ausfall löst einen eigenen Problem Record aus.
- 03 Die Analyse sucht die Ursache, während der Betrieb bereits wieder läuft.
- 04 Der Workaround wird dokumentiert und gilt ab sofort für alle gleichen Fälle.
- 05 Aus dem analysierten Fehlerbild wird ein Known Error mit benannter Ursache.
- 06 Die dauerhafte Beseitigung läuft als Change und schließt den Problem Record.
Was du mitnimmst
Nach dieser Seite kannst du in einer konkreten Situation entscheiden, welcher Weg greift, und du weißt, welche Spur im Ticketsystem entstehen muss, damit die Entscheidung morgen noch nachvollziehbar ist.
Die Auslöser kennen
Du erkennst an Häufung, unklarer Ursache oder Schadenshöhe, wann ein Problem Record fällig ist, statt das dem Bauchgefühl zu überlassen.
Sauber übergeben
Du weißt, welche Angaben aus einem Incident in den Problem Record gehören, damit die Analyse nicht mit einer Rückfrage beginnt.
Workarounds auffindbar machen
Du hängst Umgehungen an den Problem Record statt in einen Abschlusskommentar und machst sie damit für den Service Desk nutzbar.
Getrennt priorisieren
Du trennst die Matrix aus Auswirkung und Dringlichkeit von der Risikobewertung, die über die Reihenfolge der Problem Records entscheidet.
Sinnvoll messen
Du ersetzt die Zahl geschlossener Problem Records durch Kennzahlen, die zeigen, ob wiederkehrende Störungen tatsächlich verschwinden.
Die Nachbetrachtung verankern
Du verlässt ein Major Incident Review nicht ohne einen angelegten Datensatz und eine Person, die ihn weiterführt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Zwei Ziele, die sich gegenseitig im Weg stehen
Die Wiederherstellung steht unter Zeitdruck, die Ursachenanalyse braucht Ruhe und Daten. Wenn dieselbe Person beides gleichzeitig macht, gewinnt immer der Incident, weil jemand am Telefon wartet. Genau deshalb trennt ITIL 4 die beiden Practices, und nicht, weil zwei Tickettypen ordentlicher aussehen.
Der sichtbare Preis dieser Vermischung ist ein Ticketsystem voller einzeln gelöster Störungen mit demselben Muster. Der Lösungsweg steht im Abschlusskommentar eines Tickets, das nach dem Schließen niemand mehr durchsucht. Beim nächsten Auftreten beginnt die Analyse wieder bei null.
Der Übergabepunkt liegt beim Workaround
Problem Management arbeitet in drei Phasen. Problem Identification erkennt, dass hinter einer Häufung oder einem schweren Ausfall ein Fehlerbild steckt, Problem Control analysiert es, und Error Control verwaltet die bekannten Fehler samt Umgehungen über die Zeit. Ein Known Error ist dabei ein Problem, dessen Ursache analysiert, aber noch nicht beseitigt ist.
Der Workaround ist das Bindeglied zwischen beiden Welten. Sobald er dokumentiert am Problem Record hängt, kann der Service Desk ihn beim nächsten gleichartigen Incident anwenden, ohne die Ursache verstehen zu müssen. Fehlt diese Verbindung, wird der Workaround nicht wiedergefunden, sondern jedes Mal neu erarbeitet.
Priorisiert wird nach unterschiedlichen Regeln
Die Priorität eines Incidents ergibt sich aus Auswirkung und Dringlichkeit, also aus der Frage, wie viele Menschen betroffen sind und wie lange es warten kann. Das ist in Minuten entscheidbar und gehört als Matrix ins Ticketsystem, damit nicht jede Meldung neu verhandelt wird.
Ein Problem wird anders bewertet: nach Häufigkeit, nach dem Risiko eines erneuten schweren Ausfalls und nach dem Aufwand der Beseitigung. Diese Abwägung passt in keine Matrix, sie braucht eine Runde, die regelmäßig tagt, und eine Person, die die offene Liste verantwortet. Ohne diese Runde wird die Problemliste zum Ablagefach.
Woran die Trennung im Alltag scheitert
Der häufigste Grund ist ein fehlender eigener Datensatz. Wo es nur Incidents gibt, wird das Problem als Incident geführt und irgendwann mit dem Vermerk geschlossen, dass es nicht mehr auftritt. Ein Problem Record hat aber eine andere Lebensdauer, er darf Wochen offen bleiben, ohne dass deswegen eine Kennzahl rot wird.
Der zweite Grund ist die Messung. Wer Problem Management an der Zahl geschlossener Datensätze misst, bekommt viele kleine Probleme und keine großen. Tragfähiger ist die Frage, wie viele wiederkehrende Störungen im letzten Quartal verschwunden sind und wie viele Known Errors ohne dauerhafte Lösung mitlaufen.
Der dritte Grund ist die Nachbetrachtung schwerer Ausfälle. Ein Major Incident Review, aus dem kein Problem Record hervorgeht, endet als gut gemeintes Protokoll und verändert nichts.
Dazu passende Kurse
Beide Practices liegen im selben Modul Monitor, Support & Fulfil, und wer sie im eigenen Ticketsystem sauber trennen will, kann sich dazu die Practice-Manager-Trainings ansehen .
Wenn dich interessiert, wie die fünfte ITIL-Generation den Servicebetrieb ordnet , lohnt ein Blick auf die neuere Modulreihe mit demselben Zuschnitt.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Katharina war eine super Dozentin mit sehr viel Wissen. Sie ist auf alle Fragen eingegangen und konnte alle klären.
Ein sehr anspruchsvolles Training welches von einer sehr kompetente Trainerin geleitet wurde.
Alles in allem bin ich sehr zufrieden, da der Trainer sich viel Mühe gegeben hat und alles sehr gut erklären konnte.
Häufige Fragen
Wird aus jedem Incident irgendwann ein Problem?
Darf ein Incident geschlossen werden, solange das Problem offen ist?
Wer macht Problem Management, wenn es dafür keine eigene Stelle gibt?
Was unterscheidet einen Known Error von einem Workaround?
Passt thematisch dazu
Wenn du für eine Besprechung nur die Definition und die Priorisierungslogik brauchst, reicht die Kurzfassung zur Störungsbearbeitung .
Was ein Problem von der Störung selbst trennt, fasst die Begriffsklärung zur Ursachenanalyse in wenigen Sätzen zusammen.
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem ITIL & PRINCE2-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die Trennung hält nur, wenn das ganze Team sie mitträgt
Wie sich Incident und Problem Management im laufenden Betrieb wirklich auseinanderhalten lassen, erarbeiten die Practice-Manager-Module an durchgespielten Fällen.