Projektmanagement & ITIL

Change Management

Overview

Change Management sorgt dafür, dass Änderungen an IT-Services, Infrastruktur und Anwendungen nachvollziehbar bewertet, freigegeben, geplant und dokumentiert werden. Ziel ist eine hohe Quote erfolgreicher Changes bei vertretbarem Risiko. ITIL 4 hat die Practice in Change Enablement umbenannt, um den Fokus von Kontrolle auf schnelle, sichere Ermöglichung von Änderungen zu legen. In ITIL (Version 5) bleibt der Name Change Enablement.

Typische Changes sind Firmware-Updates an Firewalls, neue Gruppenrichtlinien, Migrationen von Servern oder Änderungen an Firewall-Regeln. Auch Konfigurationsänderungen in Cloud-Diensten wie Microsoft 365 oder Azure gehören dazu.

Abgrenzung: Der einzelne Änderungsantrag im Ticket-System ist der Change Request, er ist das Objekt, das dieser Prozess bearbeitet. Organizational Change Management ist eine eigene ITIL-Practice und behandelt die menschliche Seite von Veränderungen (Kommunikation, Akzeptanz), nicht technische Changes.

How it works

ITIL unterscheidet drei Change-Typen mit unterschiedlichem Freigabeweg:

  1. Standard Change: vorab bewertet und genehmigt, wiederholbar und risikoarm, z. B. ein neues Postfach nach Vorlage.
  2. Normal Change: wird einzeln bewertet und von der zuständigen Change Authority freigegeben. Das kann je nach Risiko ein Teamleiter, ein Change Advisory Board (CAB) oder ein automatisierter Pipeline-Check sein.
  3. Emergency Change: dringend, etwa zum Schließen einer aktiv ausgenutzten Sicherheitslücke, mit verkürzter Freigabe und nachträglicher Dokumentation.

Zum Ablauf gehören Risiko- und Auswirkungsanalyse (mit Hilfe der CMDB), Rückfallplan, Terminierung im Change-Kalender (Change Schedule) und ein Post-Implementation Review. ITIL 4 betont, Freigaben zu dezentralisieren und zu automatisieren, etwa über Approvals und Checks in Azure Pipelines.

Benefits

  • Weniger Ausfälle durch Änderungen, weil Risiken und Abhängigkeiten vor der Umsetzung geprüft werden.
  • Nachvollziehbarkeit: Bei einer Störung siehst Du sofort, was zuletzt geändert wurde, das verkürzt die Diagnose.
  • Planbarkeit für Fachbereiche durch einen Change-Kalender mit Wartungsfenstern.
  • Audit-Nachweise für ISO/IEC 27001 und NIS2, da kontrollierte Änderungen an IT-Systemen dort gefordert sind.

Practical example

Ein Krankenhausverbund mit 2.000 Beschäftigten will die Firewall-Regeln zwischen Medizintechnik-VLAN und Verwaltungsnetz verschärfen. Der Netzwerkadministrator erstellt einen Normal Change mit Auswirkungsanalyse aus der CMDB, Rückfallplan und Testprotokoll. Das CAB gibt den Change für das Wartungsfenster am Samstag frei. Wiederkehrende Freigaben für neue Benutzerkonten wurden dagegen als Standard Change definiert und laufen ohne CAB.

Things to keep in mind

  • Definiere so viele Standard Changes wie möglich, damit das CAB sich auf riskante Änderungen konzentriert.
  • Verlange für jeden Normal Change einen getesteten Rückfallplan statt einer bloßen Absichtserklärung.
  • Dokumentiere Emergency Changes spätestens am nächsten Arbeitstag nach, sonst entsteht eine Schattenkonfiguration.
  • Miss die Change-Erfolgsquote und die Zahl der Incidents, die durch Changes ausgelöst wurden, um den Prozess zu verbessern.

Conclusion

Change Management ist die Stelle, an der IT-Betrieb und Sicherheit am stärksten zusammenhängen. Ein schlanker Prozess mit vielen Standard Changes und klaren Change Authorities bringt Tempo und Kontrolle zusammen.

Further reading

Related articles