Team bespricht Incident- und Problem-Management als Symbol für Ticketübergabe, Ursachenarbeit und Service-Desk-Steuerung
Problem Management vs Incident Management ist keine Begriffspflege für Prozesshandbücher. Die Trennung entscheidet im Alltag, ob ein Team den akuten Ausfall schnell stabilisiert oder dieselbe Störung immer wieder im Ticketstau landet.
Incident Management kümmert sich zuerst um die Wiederherstellung eines betroffenen IT-Service. Problem Management sucht dagegen nach Ursache, Muster und dauerhafter Gegenmaßnahme. Für ITSM-Generalisten ist die saubere Grenze wichtig, weil beide Arbeitsweisen unterschiedliche Ziele, Rollen und Takte haben. Wer sie vermischt, erzeugt leicht neue Ticketbürokratie: Das Incident-Team diskutiert Ursachen, während Nutzer noch warten, oder ein Problem-Record wird angelegt, obwohl nur eine einzelne Anfrage falsch klassifiziert war.
Kurz erklärt: Incident Management ist der Ablauf für akute Störungen und Serviceunterbrechungen. Ziel ist eine schnelle, nachvollziehbare Wiederherstellung. Problem Management untersucht wiederkehrende oder schwerwiegende Ursachen hinter solchen Störungen. Ziel ist nicht das schnellste Schließen eines Tickets, sondern die Verringerung künftiger Ausfälle, Rückfragen und Umgehungslösungen.
Warum die Trennung im Tagesgeschäft schwierig wird
Auf dem Papier klingt die Trennung klar. Im Service Desk sieht sie oft anders aus. Ein Nutzer meldet, dass eine Fachanwendung nicht startet. Der erste Blick zeigt einen bekannten Fehler. Gleichzeitig tauchen ähnliche Meldungen aus einem zweiten Standort auf. Jetzt entsteht die typische Reibung: Soll das Team weiter an der einzelnen Störung arbeiten, sofort einen Problem-Record eröffnen oder erst abwarten, ob der Fall größer wird?
Die falsche Antwort kostet Zeit. Wird zu früh alles als Problem behandelt, füllen sich Arbeitslisten mit Untersuchungen, die keine erkennbare Wirkung haben. Wird zu spät ein Problem eröffnet, wiederholen sich Workarounds, Wissensartikel und Provider-Rückfragen. Das Incident-Team arbeitet dann zwar fleißig, aber es räumt immer denselben Schaden weg.
Incident Management braucht klare Stabilisierungsziele
Ein Incident fragt zuerst: Wer ist betroffen, welcher Service ist gestört, welche Auswirkung hat der Ausfall und welche Wiederherstellung ist jetzt realistisch? Diese Fragen müssen schnell beantwortet werden. Dafür helfen eine passende Priorisierung, ein sichtbarer Kommunikationsstand, ein eindeutiger Owner und eine dokumentierte nächste Handlung.
Bei schweren Ausfällen gehört diese Logik in eine Lageführung. Der Beitrag schwere IT-Störungen führbar halten zeigt, warum Rollen, Kommunikationsrhythmus und Entscheidungswege schon im Incident sitzen müssen. Problem Management darf diesen Ablauf nicht verlangsamen. Es darf ihn aber mit einer sauberen Übergabe vorbereiten, sobald klar wird, dass Ursachenarbeit nötig ist.
Problem Management startet erst mit einem begründeten Auslöser
Ein Problem-Record braucht mehr als das Bauchgefühl, dass etwas „komisch“ ist. Sinnvolle Auslöser sind wiederkehrende Incidents mit ähnlichem Muster, ein schwerer Incident mit ungeklärter Ursache, auffällige Service Desk KPI, bekannte Workaround-Ketten oder ein Provider-Hinweis auf eine technische Schwachstelle. Der Auslöser muss im Ticket nachvollziehbar bleiben, sonst wird Problem Management zur Sammelstelle für ungelöste Vermutungen.
Gerade Kennzahlen helfen nur, wenn sie mit Rohdaten geprüft werden. Ein Anstieg der Wiedereröffnungen kann auf schlechte Erstlösungen hinweisen, aber auch auf eine neue Klassifikationsregel oder auf ein Formularproblem. Deshalb ist die Verbindung zu Service Desk KPI mit Rohdaten prüfen wichtig: Erst die Ticketbeispiele zeigen, ob ein Problemprozess wirklich starten sollte.
Die einfache Entscheidungsregel für den Service Desk
Eine pragmatische Regel lautet: Der Incident bleibt führend, bis der Service stabil ist oder eine akzeptierte Umgehungslösung steht. Ein Problem-Record startet parallel oder danach, wenn mindestens eines von vier Signalen sichtbar ist. Erstens wiederholt sich ein Fehlerbild. Zweitens ist die Ursache nach der Wiederherstellung weiter unklar. Drittens entsteht ein hohes Risiko, wenn der Workaround länger bleibt. Viertens zeigen Tickets, Monitoring oder Kundenrückmeldungen, dass derselbe Fehler mehrere Services oder Nutzergruppen treffen kann.
Diese Regel verhindert, dass jedes komplizierte Ticket automatisch zum Problem wird. Gleichzeitig stoppt sie das Gegenteil: akute Tickets werden nicht endlos geschlossen, ohne dass jemand die Ursache verfolgt. Entscheidend ist die dokumentierte Schwelle. Das Team muss später erkennen können, warum genau hier Ursachenarbeit begonnen hat.
Was in die Übergabe vom Incident zum Problem gehört
Die Übergabe sollte kurz, aber belastbar sein. Nötig sind der betroffene Service, die betroffenen Nutzergruppen, der Zeitraum, die sichtbaren Symptome, der aktuelle Workaround, die vermutete Ursache, offene Belege und die Entscheidung, wer weiterführt. Wenn ein Provider beteiligt ist, gehört außerdem die Rückmeldefrist in die Übergabe. Sonst bleibt der Service Desk im nächsten Ausfall wieder ohne steuerbare Antwort. Der Artikel Provider-Aufgaben mit Rückmeldefrist übergeben zeigt diese Steuerungslogik aus Sourcing-Sicht.
Hilfreich ist eine feste Übergabezeile im Ticket oder Problem-Record: „Incident stabilisiert durch …, Problem-Auslöser …, offene Ursache …, nächster Prüfschritt …, Owner …, Frist …“. Mehr braucht es im ersten Schritt oft nicht. Wichtig ist, dass diese Zeile nicht als Formularballast wirkt, sondern echte Folgearbeit auslöst.
CMDB und Servicebezug machen Ursachenarbeit genauer
Problem Management wird schwach, wenn es nur an technischen Komponenten hängt. Ein Datenbankfehler ist für den Betrieb erst dann vollständig eingeordnet, wenn klar ist, welcher Service, welche Kundengruppe und welche Abhängigkeit betroffen sind. Dafür braucht der Problem-Owner zumindest eine brauchbare Servicezuordnung. Eine perfekte CMDB ist dafür nicht nötig, aber ein sichtbarer Bezug zwischen Komponente, Service und Auswirkung schon.
Der Beitrag CMDB-Änderungen mit sichtbaren Servicefolgen passt dazu, weil Ursachenarbeit oft an fehlenden Abhängigkeiten scheitert. Wer nach jedem Ausfall erst sucht, welche Änderung welchen Service berührt hat, verliert die eigentliche Lernchance. Problem Management sollte deshalb nicht nur technische Ursache und Fix notieren, sondern auch die betroffene Servicekette korrigieren.
Welche Rollen nicht verwechselt werden dürfen
Der Incident Manager oder Service Desk Lead schützt den Wiederherstellungsfokus. Diese Rolle entscheidet, welche Kommunikation nötig ist, welche Priorität gilt und welche Sofortmaßnahme tragbar ist. Der Problem Manager oder Problem-Owner schützt dagegen die Ursachenarbeit. Diese Rolle achtet darauf, dass wiederkehrende Fehler nicht als Einzelfälle verschwinden, dass Workarounds ein Ablaufdatum bekommen und dass dauerhafte Maßnahmen bewertet werden.
In kleinen Organisationen kann dieselbe Person beide Rollen übernehmen. Dann braucht sie eine bewusste Umschaltung. Während der akuten Störung zählt Stabilisierung. Nach der Stabilisierung zählt Lernen. Ohne diese Trennung entsteht ein gefährlicher Mischmodus: Das Team sucht noch Ursachen, obwohl Nutzer warten, oder es schließt Tickets, obwohl die Ursache weiter offen ist.
Eine kurze Prüfliste für die Praxis
- Ist der betroffene Service wiederhergestellt oder gibt es eine tragfähige Umgehungslösung?
- Gibt es mehr als ein Ticket, einen wiederkehrenden Fehler oder eine schwere Auswirkung?
- Ist dokumentiert, warum ein Problem-Record eröffnet oder bewusst noch nicht eröffnet wird?
- Steht im Incident, welcher Workaround gilt und bis wann er überprüft wird?
- Ist klar, wer die Ursachenarbeit besitzt und wann der nächste Prüfstand fällig ist?
- Wird die Servicekette aktualisiert, wenn die Ursache eine Abhängigkeit sichtbar macht?
- Erkennt der Service Desk beim nächsten ähnlichen Ticket, ob es zum bestehenden Problem gehört?
FAQ
Wann wird aus einem Incident ein Problem?
Ein Incident wird nicht automatisch zu einem Problem. Ein Problem-Record ist sinnvoll, wenn die Ursache unklar bleibt, sich das Fehlerbild wiederholt, ein schwerer Ausfall nachbereitet werden muss oder der Workaround ein dauerhaftes Risiko erzeugt.
Darf Problem Management schon während eines Major Incidents starten?
Ja, aber nur als parallele Ursachenaufnahme, nicht als Bremse für die Wiederherstellung. Die akute Stabilisierung bleibt führend, solange Nutzer oder Services noch direkt betroffen sind.
Welche Kennzahl zeigt, dass Problem Management nötig ist?
Eine einzelne Kennzahl reicht selten. Wiedereröffnungen, Wiederholstörungen, lange Lösungszeiten und viele Workaround-Tickets werden erst mit Rohdaten und Servicebezug aussagekräftig.
Quellen und Einordnung
Die Abgrenzung orientiert sich an ITSM-Grundlagen zu Incident Management und Problem Management sowie an praxisnahen ITSM-Einordnungen von Atlassian, Atlassian Problem Management, ServiceNow und PeopleCert ITIL 4. Stand der Quellenprüfung: 06.08.2026.
Die wichtigste Entscheidung lautet deshalb nicht, ob ein Ticket den richtigen Prozessnamen trägt. Entscheidend ist, ob der Incident schnell stabilisiert wird und ob wiederkehrende Ursachen danach wirklich aus dem Arbeitsstrom verschwinden. Genau an dieser Grenze zeigt sich, ob Problem Management den Betrieb entlastet oder nur eine weitere Warteschlange erzeugt.
Bildquelle: Pexels / Foto-ID 1181431 / https://www.pexels.com/photo/1181431/ / CC0-Lizenz
