13.5 Zusammenspiel mit Incident, Problem, Service Configuration Management und Monitoring
Kurz erklärt
Change Enablement arbeitet eng mit vielen anderen ITIL Practices zusammen.
Änderungen entstehen häufig aus Incidents oder Problems, beeinflussen Configuration Items und werden durch Monitoring überwacht.
Erst das Zusammenspiel dieser Practices ermöglicht sichere Änderungen, stabile IT-Services und eine kontinuierliche Verbesserung der gesamten IT-Landschaft.
Warum das Zusammenspiel wichtig ist
Ein Change wird selten isoliert durchgeführt.
Vor einer Änderung müssen beispielsweise folgende Fragen beantwortet werden:
- Warum ist die Änderung notwendig?
- Welche Services sind betroffen?
- Welche Configuration Items werden verändert?
- Welche Risiken bestehen?
- Wie wird der Erfolg überprüft?
Diese Informationen stammen aus verschiedenen ITIL Practices.
Zusammenspiel der Practices
Incident
│
▼
Problem
│
▼
Change Enablement
│
▼
Service Configuration Management
│
▼
Monitoring
│
▼
Continual Improvement
Jede Practice liefert wichtige Informationen für die nächste.
Change Enablement und Incident Management
Viele Changes entstehen als Folge eines Incidents.
Beispiel:
Ein Server fällt regelmäßig aus.
Incident Management stellt den Betrieb zunächst wieder her.
Die eigentliche Ursache bleibt jedoch bestehen.
Zur dauerhaften Lösung wird ein Change geplant.
Incident Management arbeitet also häufig kurzfristig,
während Change Enablement eine nachhaltige Verbesserung ermöglicht.
Beispiel
Serverausfall
│
▼
Incident Management
│
▼
Service wiederhergestellt
│
▼
Hardware ersetzen
│
▼
Change Enablement
Der Incident endet mit der Wiederherstellung,
der Change beseitigt anschließend die eigentliche Ursache.
Change Enablement und Problem Management
Problem Management untersucht,
warum Incidents wiederholt auftreten.
Wird eine dauerhafte Lösung gefunden,
führt diese häufig zu einem Change.
Beispiele:
- Software aktualisieren,
- Hardware austauschen,
- Netzwerk erweitern,
- Architektur ändern.
Problem Management liefert also häufig den Anlass für einen Change.
Known Errors
Ein Known Error kann eine empfohlene Änderung enthalten.
Beispiel:
Bekannter Fehler:
Firmware-Version 5.2 verursacht Abstürze.
Empfohlene Lösung:
Firmware-Version 5.3 installieren.
Die eigentliche Umsetzung erfolgt anschließend über Change Enablement.
Change Enablement und Service Configuration Management
Vor jeder Änderung muss bekannt sein,
welche Configuration Items betroffen sind.
Die CMDB liefert beispielsweise:
- betroffene Server,
- Anwendungen,
- Datenbanken,
- Netzwerke,
- Verantwortliche,
- Beziehungen.
Dadurch können Auswirkungen besser bewertet werden.
Impact Analysis
Vor einem Change wird häufig geprüft,
welche Services betroffen sind.
Beispiel:
Firewall
│
├── VPN
├── Internet
├── VoIP
└── E-Mail
Ein Firmware-Update betrifft somit mehrere Services.
Diese Information stammt aus der CMDB.
CMDB aktualisieren
Nach erfolgreicher Umsetzung werden unter anderem aktualisiert:
- Versionen,
- Status,
- Beziehungen,
- Dokumentationen,
- Verantwortlichkeiten.
Dadurch bleibt die Configuration-Datenbasis aktuell.
Change Enablement und Monitoring
Monitoring überwacht,
ob Änderungen erfolgreich umgesetzt wurden.
Beispiele:
- Server erreichbar,
- CPU normal,
- Speicher ausreichend,
- Netzwerk stabil,
- keine neuen Alarme,
- Services verfügbar.
Monitoring bestätigt somit den Erfolg eines Changes.
Monitoring vor einem Change
Auch vor einer Änderung liefert Monitoring wichtige Informationen.
Beispiele:
- aktuelle Auslastung,
- bekannte Fehler,
- bestehende Alarme,
- Performance,
- Verfügbarkeit.
Diese Informationen unterstützen die Risikobewertung.
Monitoring nach einem Change
Nach der Umsetzung werden häufig überprüft:
- Erreichbarkeit,
- Antwortzeiten,
- Fehlermeldungen,
- Auslastung,
- Benutzeranmeldungen,
- Dienste.
Erst wenn diese Prüfungen erfolgreich sind,
gilt der Change als abgeschlossen.
Change Enablement und Release Management
Ein Release kann mehrere Changes enthalten.
Beispiel:
Ein Software-Release umfasst:
- neue Funktionen,
- Fehlerbehebungen,
- Sicherheitsupdates,
- Konfigurationsänderungen.
Change Enablement bewertet und genehmigt die Änderungen,
Release Management plant und verteilt das Gesamtpaket.
Change Enablement und Deployment Management
Nach der Genehmigung erfolgt häufig die technische Bereitstellung.
Deployment Management übernimmt beispielsweise:
- Software verteilen,
- Container aktualisieren,
- Images bereitstellen,
- Anwendungen installieren.
Change Enablement steuert den organisatorischen Rahmen,
Deployment Management die technische Umsetzung.
Change Enablement und Information Security Management
Viele Changes dienen der Verbesserung der Sicherheit.
Beispiele:
- Sicherheitsupdates,
- Firewallregeln,
- MFA einführen,
- Zertifikate erneuern,
- Verschlüsselung aktivieren.
Dabei müssen Sicherheitsanforderungen und Serviceverfügbarkeit gleichermaßen berücksichtigt werden.
Change Enablement und Continual Improvement
Erfahrungen aus abgeschlossenen Changes fließen in Continual Improvement ein.
Beispiele:
- Planung verbessern,
- Testverfahren erweitern,
- Dokumentation optimieren,
- Genehmigungen vereinfachen,
- Standard Changes definieren.
Dadurch entwickelt sich der Change-Prozess kontinuierlich weiter.
Praxisbeispiel
Ein Unternehmen stellt fest,
dass nach jedem Betriebssystemupdate ähnliche Probleme auftreten.
Problem Management analysiert die Ursache.
Es zeigt sich,
dass wichtige Regressionstests fehlen.
Change Enablement ergänzt daraufhin den Testplan.
Monitoring bestätigt,
dass zukünftige Updates deutlich störungsärmer verlaufen.
Die neue Vorgehensweise wird anschließend als Standardprozess dokumentiert.
Typische Fehler
Fehler 1
Changes werden unabhängig von Incidents geplant.
Fehler 2
Configuration Items werden nicht aktualisiert.
Fehler 3
Monitoring überprüft Änderungen nicht.
Fehler 4
Problem Management wird nicht einbezogen.
Fehler 5
Release und Change werden verwechselt.
Fehler 6
Deployment erfolgt ohne Genehmigung.
Fehler 7
Auswirkungen auf andere Services werden unterschätzt.
Fehler 8
Erfahrungen aus früheren Changes werden nicht genutzt.
Fehler 9
CMDB und Monitoring liefern widersprüchliche Informationen.
Fehler 10
Verbesserungsmaßnahmen werden nicht dokumentiert.
Checkliste Zusammenspiel
- Incident analysiert
- Problem bewertet
- Change genehmigt
- Configuration Items geprüft
- Monitoring vorbereitet
- Dokumentation aktualisiert
- Erfolg überprüft
- Verbesserungen dokumentiert
Checkliste erfolgreicher Change
- Risiko bewertet
- Tests erfolgreich
- Rollback vorbereitet
- Monitoring aktiv
- CMDB aktualisiert
- Benutzer informiert
- Post Implementation Review durchgeführt
- Lessons Learned dokumentiert
Bedeutung für Fachinformatiker für Systemintegration
Fachinformatiker begleiten nahezu den gesamten Lebenszyklus eines Changes.
Typische Aufgaben:
- Incidents analysieren,
- Ursachen dokumentieren,
- Configuration-Daten pflegen,
- Monitoring überwachen,
- Änderungen durchführen,
- Rollback vorbereiten,
- Dokumentationen aktualisieren,
- Verbesserungen ableiten.
Dadurch leisten sie einen wesentlichen Beitrag zu einem sicheren und stabilen IT-Betrieb.
Zusammenfassung
Incident erkennen
↓
Ursache analysieren
↓
Change planen
↓
Auswirkungen bewerten
↓
Änderung umsetzen
↓
Monitoring prüfen
↓
CMDB aktualisieren
↓
Verbesserungen übernehmen
Merksätze
Viele Changes entstehen aus Incidents oder Problems.
Die CMDB liefert die Grundlage für Impact-Analysen.
Monitoring bestätigt den Erfolg eines Changes.
Deployment setzt Änderungen technisch um – Change Enablement steuert sie organisatorisch.
Erfahrungen aus abgeschlossenen Changes verbessern zukünftige Änderungen.
Verwandte Seiten
- 13.1 Ziele und Grundlagen des Change Enablement
- 13.2 Change-Typen und Risikobewertung
- 13.3 Genehmigungen, Change Authority, CAB und Change-Kalender
- 13.4 Umsetzung, Tests und Rollback
- Incident Management
- Problem Management
- Service Configuration Management
- Monitoring and Event Management
- Release Management
- Deployment Management
- Continual Improvement
Quellen und Versionsstand
Offizielle Grundlagen
- PeopleCert – ITIL Practice Guide: Change Enablement
- PeopleCert – ITIL Practice Guide: Incident Management
- PeopleCert – ITIL Practice Guide: Problem Management
- PeopleCert – ITIL Practice Guide: Service Configuration Management
- PeopleCert – ITIL Practice Guide: Monitoring and Event Management
- ITIL Foundation – Version 5
Einordnung
Die dargestellten Zusammenhänge entsprechen den Empfehlungen der ITIL-Practices. Change Enablement koordiniert Änderungen organisatorisch und arbeitet dabei eng mit Incident Management, Problem Management, Service Configuration Management, Monitoring sowie weiteren Practices wie Release und Deployment Management zusammen.
Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026