Incident Management, Problem Management und Change Management gehören zu den zentralen Prozessen im IT Service Management und greifen unmittelbar ineinander. Eine Störung muss zunächst möglichst schnell behoben werden. Wiederkehrende oder schwerwiegende Incidents können eine Ursachenanalyse erforderlich machen. Wird zur dauerhaften Beseitigung einer Ursache eine Veränderung an einem IT-Service oder seiner Infrastruktur notwendig, führt der Weg häufig weiter ins Change Management.
Die drei Prozesse verfolgen dabei unterschiedliche Ziele, nutzen aber gemeinsame Informationen und bauen in vielen Situationen aufeinander auf.
Diese Themensammlung gibt einen Überblick darüber, wie Incident Management, Problem Management und ITSM Change Management zusammenspielen und welche Rolle Service Desk, CMDB und Wissensmanagement dabei übernehmen.
Wie hängen Incident, Problem und Change zusammen?
Vereinfacht lässt sich der Zusammenhang so darstellen:
Störung → Incident → Service wiederherstellen → Ursache analysieren → Problem → dauerhafte Lösung planen → Change → kontrolliert verändern
Nicht jeder Incident führt zu einem Problem und nicht jedes Problem erfordert automatisch einen Change.
Die Prozesse werden dann miteinander verbunden, wenn dies fachlich sinnvoll ist.
Ein Beispiel:
Ein Anwender meldet den wiederholten Ausfall einer Geschäftsanwendung. Das Incident Management sorgt zunächst dafür, dass der Service möglichst schnell wieder verfügbar ist. Da ähnliche Störungen mehrfach auftreten, wird im Problem Management nach der zugrunde liegenden Ursache gesucht. Stellt sich beispielsweise heraus, dass eine Serverkomponente geändert oder eine Software aktualisiert werden muss, kann daraus ein Change entstehen.
Dadurch wird aus der reinen Störungsbearbeitung ein kontinuierlicher Prozess zur Stabilisierung und Verbesserung von IT-Services.
Incident Management – den normalen Servicebetrieb wiederherstellen
Ein Incident ist eine ungeplante Beeinträchtigung oder Unterbrechung eines IT-Service.
Das zentrale Ziel des Incident Managements besteht deshalb darin, den normalen Servicebetrieb möglichst schnell wiederherzustellen und die Auswirkungen auf Anwender und Geschäftsprozesse zu begrenzen.
Dazu werden Störungen erfasst, kategorisiert, priorisiert und dem zuständigen Bearbeiter oder Team zugeordnet. Abhängig von Auswirkung, Dringlichkeit und vereinbarten Service Levels können unterschiedliche Bearbeitungs- und Eskalationswege entstehen.
Dabei muss ein Incident nicht zwangsläufig sofort an seiner technischen Ursache gelöst werden. Für den Anwender steht zunächst die Wiederherstellung des benötigten Service im Vordergrund.
Incident Management mit EcholoN
Grundlagen und Einordnung:
Was ist Incident Management?
Service Desk & SPoC – wo Incidents und Anfragen zusammenlaufen
Viele Incidents beginnen am Service Desk als zentraler Anlaufstelle – dem Single Point of Contact (SPoC).
Dort werden Meldungen aufgenommen, Informationen ergänzt, Kategorien und Prioritäten bestimmt und die weiteren Bearbeitungsschritte koordiniert.
Dabei ist eine wichtige Aufgabe bereits die richtige Einordnung:
Handelt es sich um eine Störung, eine Serviceanfrage, ein Problem oder einen anderen Vorgang?
Der Service Desk bildet damit die operative Schnittstelle zwischen Anwender und den dahinterliegenden ITSM-Prozessen. Er muss einen Incident nicht zwingend vollständig selbst lösen, sorgt aber für eine strukturierte Aufnahme und Weiterleitung.
Service Desk Software für ITSM und Support
SPoC im IT Service Management: Aufgaben und Prozesse
Problem Management – Ursachen statt Symptome bearbeiten
Während das Incident Management möglichst schnell auf die Wiederherstellung eines Service ausgerichtet ist, verfolgt das Problem Management ein anderes Ziel.
Es untersucht die zugrunde liegenden Ursachen tatsächlicher oder möglicher Incidents und soll verhindern, dass dieselben Störungen immer wieder auftreten.
Hinweise auf ein Problem können beispielsweise entstehen durch:
- wiederkehrende ähnliche Incidents
- besonders schwerwiegende Störungen
- Auswertungen und Trendanalysen
- Monitoring-Ergebnisse
- bekannte technische Schwachstellen
- proaktive Analysen
Dabei können zunächst auch Workarounds entstehen. Sie ermöglichen eine schnellere Behandlung weiterer Incidents, solange die eigentliche Ursache noch nicht dauerhaft beseitigt wurde.
Problem Management mit EcholoN
Grundlagen und Prozess:
Was ist Problem Management?
Known Errors und Wissen wiederverwenden
Nicht jede bekannte Ursache kann sofort dauerhaft beseitigt werden.
Wurde ein Fehler analysiert und ein funktionierender Workaround gefunden, können diese Informationen für zukünftige Störungen bereitgestellt werden. Dadurch muss der Service Desk bei einem erneuten Incident nicht jedes Mal bei null beginnen.
Hier entsteht eine enge Verbindung zwischen Problem Management und Wissensmanagement.
Lösungen, bekannte Fehler, Workarounds und Erfahrungen aus bereits bearbeiteten Vorgängen können dokumentiert und bei späteren Anfragen erneut genutzt werden.
So wird aus einzelnen Incident- und Problem-Daten schrittweise nutzbares Servicewissen.
Change Management – notwendige Veränderungen kontrolliert umsetzen
Wurde die Ursache eines Problems identifiziert, kann für eine dauerhafte Lösung eine Veränderung an einem IT-Service oder seiner technischen Umgebung erforderlich sein.
An dieser Stelle kommt das ITSM Change Management ins Spiel.
Ein Change kann beispielsweise eine Änderung an:
- Software
- Hardware
- Konfigurationen
- Anwendungen
- Schnittstellen
- Infrastruktur
- oder anderen servicebezogenen Komponenten
betreffen.
Die Veränderung wird dabei nicht einfach unmittelbar umgesetzt. Abhängig von Art und Risiko können Auswirkungen bewertet, Zuständigkeiten definiert, Freigaben eingeholt, Termine geplant und die Umsetzung dokumentiert werden.
IT Change Management mit EcholoN
CMDB & Configuration Management – welche Komponenten sind betroffen?
Für Incident, Problem und Change Management ist nicht nur entscheidend, welcher Vorgang bearbeitet wird, sondern auch, welche technischen Komponenten und Services betroffen sind.
Hier liefern CMDB und Configuration Management den notwendigen Kontext.
Configuration Items können beispielsweise mit Incidents, Problems und Changes verknüpft werden. Beziehungen zwischen Anwendungen, Servern, Geräten, Services und weiteren Komponenten helfen dabei, Abhängigkeiten sichtbar zu machen.
Dadurch können unterschiedliche Fragen beantwortet werden:
Beim Incident:
Welche Komponente ist gestört und welche Services könnten betroffen sein?
Beim Problem:
Welche Configuration Items treten wiederholt im Zusammenhang mit Störungen auf?
Beim Change:
Welche Systeme, Services oder abhängigen Komponenten könnten durch eine geplante Veränderung beeinflusst werden?
Themensammlung: CMDB, Configuration Management und verbundene ITSM-Prozesse
SLA, Prioritäten und Eskalationen
Nicht jeder Incident besitzt dieselbe geschäftliche Bedeutung.
Auswirkung und Dringlichkeit helfen dabei, eine Priorität zu bestimmen. Gleichzeitig können vereinbarte Service Level Agreements (SLA) vorgeben, innerhalb welcher Zeiten auf eine Störung reagiert oder eine Lösung bereitgestellt werden soll.
Damit verbinden sich Incident Management und Service Level Management unmittelbar miteinander.
Droht eine vereinbarte Zeit überschritten zu werden oder handelt es sich um einen besonders kritischen Vorgang, können Eskalationsprozesse ausgelöst werden.
Das schafft eine zusätzliche Steuerungsebene zwischen fachlicher Bearbeitung und den gegenüber Anwendern oder Kunden vereinbarten Servicezielen.
Service Level Management und SLA
Vom Incident zur nachhaltigen Verbesserung
Der Nutzen der drei Prozesse entsteht besonders durch ihr Zusammenspiel.
Ein einzelner Incident liefert Informationen über eine konkrete Störung. Mehrere ähnliche Incidents können auf ein strukturelles Problem hinweisen. Die Problemanalyse identifiziert eine Ursache und möglicherweise einen Workaround. Ist eine technische Veränderung notwendig, kann daraus ein Change entstehen.
Nach erfolgreicher Umsetzung stehen wiederum neue Erkenntnisse zur Verfügung.
Incident-Daten → Muster erkennen → Problem analysieren → Ursache finden → Change durchführen → Ergebnis dokumentieren → zukünftige Incidents vermeiden
Damit entsteht ein Kreislauf, der nicht nur auf Störungen reagiert, sondern IT-Services schrittweise stabiler und besser steuerbar machen kann.
Zusammenspiel innerhalb des IT Service Managements
Incident, Problem und Change Management sind deshalb keine isolierten Module.
Sie verbinden sich mit weiteren ITSM-Bereichen:
Service Desk
→ zentraler Zugang für Anwender und Meldungen
Service Level Management
→ Prioritäten, Reaktions- und Lösungszeiten
Wissensmanagement
→ Lösungen und Workarounds wiederverwenden
CMDB & Configuration Management
→ betroffene Komponenten und Abhängigkeiten verstehen
Monitoring
→ Störungen und Auffälligkeiten automatisiert erkennen
Gemeinsam bilden diese Bereiche eine durchgängige Prozess- und Informationsbasis für den stabilen Betrieb und die kontinuierliche Verbesserung von IT-Services.
IT Service Management mit EcholoN
Kurz zusammengefasst: Incident Management sorgt dafür, dass ein beeinträchtigter IT-Service möglichst schnell wieder funktioniert. Problem Management untersucht die Ursachen und versucht, wiederkehrende Störungen dauerhaft zu vermeiden. Ist dafür eine Veränderung notwendig, sorgt Change Management für deren kontrollierte Planung und Umsetzung.
Service Desk, Wissensmanagement, SLA-Steuerung sowie CMDB und Configuration Management liefern dabei den organisatorischen und technischen Kontext.
So entsteht aus der Bearbeitung einzelner Störungen ein vernetzter ITSM-Prozess von der schnellen Wiederherstellung bis zur nachhaltigen Verbesserung des Servicebetriebs.