Definition: Was ist IT-Change-Management?
Änderungen an der IT-Infrastruktur treten regelmäßig auf. IT-Change-Management bildet den Prozess, um diese strukturiert und kontrolliert umzusetzen. Dadurch reduzieren sich potenzielle Störungen im Betrieb und die IT-Ziele sind besser auf die Unternehmensziele abgestimmt. Ein adäquates IT-Change-Management basiert auf bewährten Standards wie ITIL und trägt dazu bei, den kontinuierlichen Betrieb kritischer Systeme zu gewährleisten.
Change Management vs. IT-Change-Management
Change Management bezieht sich allgemein auf die strukturierte Umsetzung von Veränderungen in Organisationen, um Menschen, Prozesse und Systeme erfolgreich anzupassen. IT Change Management ist ein spezifischer Teilbereich, der sich auf das Management von Änderungen in IT-Systemen konzentriert, um deren Stabilität und Sicherheit zu gewährleisten.
Während Change Management den gesamten organisatorischen Wandel umfasst, fokussiert sich IT Change Management auf technische Veränderungen und deren Auswirkungen auf die IT-Infrastruktur.
IT-Change-Management und Release Management
Der Fokus bildet den entscheidenden Unterschied zwischen IT-Change-Management und Release Management: Beim IT-Change-Management geht es darum, einzelne Änderungen in IT-Systemen kontrolliert zu leisten, ohne dass es dabei große Beeinträchtigungen gibt.
Das Release Management befasst sich dagegen damit, Software-Releases – oft bestehend aus mehreren Änderungen– zu planen, koordinieren und bereitzustellen und einen erfolgreichen Rollout zu erreichen.
„Wo das IT-Change-Management Änderungen prüft und genehmigt, liefert das Release Management fertige, getestete Änderungen an die Produktionsumgebung.“
Beispiele für IT-Change-Management
IT-Change-Management tritt in Organisationen häufig und in verschiedenen Kontexten in Kraft. Immer wieder sind unter anderem Unternehmen gefragt, neue Software zu implementieren, relevante Updates einzuspielen und bestehende Prozesse zu optimieren.
Beispiel #1: Einführung eines kritischen Software-Updates
Zunächst gibt es einen Antrag, in dem das Update selbst und seine (potenziellen) Auswirkungen ersichtlich werden. Im zweiten Schritt erfolgt eine Risikobewertung, auf Basis derer eine Analyse von Folgen für die IT-Infrastruktur erfolgt. Schließlich prüfen die Verantwortlichen das Update in einer Testumgebung, um Fehler in der Live-Umgebung möglichst zu verhindern.
Nach der Genehmigung des Updates auf dem Live-System erfolgt die detaillierte Planung: Zeitfenster, Backup-Strategien und potenzielle Rollback-Verfahren werden festgelegt, um bei Problemen schnell reagieren zu können. Während des Updates überwacht das IT-Team die Systeme, um Störungen zu vermeiden. Nach erfolgreicher Durchführung dokumentiert es das Ergebnis – und informiert alle Beteiligten über den aktuellen Status.
Beispiel #2: Umstellung auf eine Cloud-basierte Infrastruktur
Ein Unternehmen möchte von lokalen Servern auf eine Cloud-basierte Infrastruktur umstellen. Das Change-Management beginnt damit, den Bedarf genauer zu analysieren sowie die Vorteile und Risiken der Cloud-Migration zu evaluieren. Schließlich erfolgt ein Change-Plan, der den schrittweisen Übergang beschreibt – samt Mitarbeiterschulungen und Preisanpassungen.
In der Folge werden die IT-Services schrittweise in die Cloud übertragen. Durch eine adäquate Kommunikation sind dabei alle Beteiligten – vom IT-Teammitglied bis zum Endanwender – ausreichend informiert und vorbereitet. Auch hier erfolgt ein Monitoring, damit die neuen IT-Services reibungslos funktionieren und etwaige Probleme schnell gelöst werden können.
Wichtige Bestandteile des
IT-Change-Managements
Das IT-Change-Management setzt sich aus einigen Bestandteilen zusammen. Hier finden sich einige Informationen zu den wichtigsten Begrifflichkeiten aus diesem Kontext.
Request for Change (RfC)
Eine Änderungsanforderung (Request for Change, abgekürzt RfC, oder auch Change Request, abgekürzt CR) bildet die Grundlage für einen entsprechenden Prozess. Auslöser dafür können zum Beispiel ein erfolgtes Problem-Management, ein simples IT-Problem oder gleich eine Prozessoptimierung sein.
Bei einem Request for Change handelt es sich um eine formale Anfrage, etwas an einem IT-System oder einem Prozess zu ändern
„Das Ziel: Geplante Änderungen sollen adäquat evaluiert, samt möglicher Risiken analysiert und mit einer Zustimmung versehen sein.“
Zu einem RfC können unter anderem diese Informationen gehören:
- Beschreibung der Änderung
- Gründe dafür
- betroffene Systeme oder Produktversionen
- erforderliche Schritte
- Datum für spezifische Umsetzungen
- Ressourcen zur Umsetzung
- Zeitaufwand
- Kostenschätzung
Forward Schedule of Change (FSC)
Hinter diesem Begriff verbirgt sich ein Kalender beziehungsweise ein Plan, in dem alle geplanten Änderungen für einen bestimmten Zeitraum erfasst sind. Durch einen Forward Schedule of Change entsteht ein probater Überblick zu bevorstehenden Schritten, um Konflikte zu vermeiden und Änderungen schematisch, mit den nötigen Freigaben und einem minimalen Risiko durchzuführen.
Post Implementation Review (PIR)
Als Bewertung einer abgeschlossenen Änderung erfolgt ein Post Implementation Review, nachdem eine bestimmte Änderung erfolgt ist. Seine Bedeutung ist nicht zu unterschätzen, da in diesem Schritt eine Evaluierung darüber entsteht, ob der Change-Prozess erfolgreich war und die gewünschten Ergebnisse ersichtlich werden. Oft bedarf es einer Nachjustierung an IT-Änderungen und viele Prozesse sind – gemäß der kontinuierlichen Verbesserung – nie wirklich abgeschlossen. Mögliche Probleme oder Optimierungspotenziale sollten dabei möglichst früh zum Vorschein kommen.
Klassifizierung von Changes
Zu erfolgende Änderungen erhalten üblicherweise eine Klassifizierung nach ihrer Wichtigkeit und Dringlichkeit. So definiert die IT Infrastructure Library (ITIL) – De-facto-Standard für Best Practices im IT Service Management (ITSM) – die folgenden Kategorien.
Standardmäßige Veränderung (Standard Change)
Bei einem Standard-Change handelt es sich um eine vorab genehmigte, risikoarme und häufig durchgeführte Änderung, die nach einem festgelegten, wiederholbaren Prozess abläuft. Solche bekannten Änderungen erfordern keine detaillierte Genehmigungs- und Risikobewertung, so dass sie schnell und unkompliziert zu leisten sind. Häufige Beispiele bilden das Zurücksetzen eines Passworts oder das Hinzufügen eines Benutzers.
Normale Veränderungen (Normal Change)
Diese Form von Änderung erfolgt planmäßig, wiederholt sowie standardisiert. Je nach Umfang und Risiko können die Changes gering, signifikant oder schwerwiegend sein. Naturgemäß erweisen sie sich als weniger dringend als Notfall-Changes. Beispiele stellen Software-Updates, ein Hardware-Austausch, Rechte-Anpassungen, Konfigurationsänderungen oder das On- und Offboarding von Mitarbeitern dar.
Notfall-Changes (Emergency Change)
Hier wird es brisant: Notfall-Changes kommen – wie es der Name bereits sagt – unerwartet und müssen in der Regel sofort implementiert werden. Es geht darum, negative Situationen und Bedrohungsszenarien umgehend zu entschärfen und schwerwiegende Auswirkungen zu vereiteln. Ein Beispiel ist die Wiederherstellung nach einem Angriff, wenn infizierte Geräte schnell isoliert und gesäubert werden müssen, damit sich Malware oder Ransomware nicht weiter ausbreiten.
Der IT-Change-Management-Prozess
Ein Change-Management-Prozess in der IT zielt darauf ab, Änderungen in der IT-Infrastruktur kontrolliert und effizient umzusetzen, um den wachsenden Anforderungen und Marktveränderungen gerecht zu werden. Dabei sollen Changes möglichst automatisiert geschehen.
Ziele sind unter anderem eine verbesserte Kontrolle und Nachverfolgbarkeit von Veränderungen, klare Verantwortlichkeiten und eine stetige Optimierung. Dies fördert Transparenz, Effizienz und minimiert Störungen im IT-Betrieb.
Insgesamt trägt der IT-Change-Management-Prozess zur Wettbewerbsfähigkeit des Unternehmens bei, indem er es ermöglicht, an Trends zu partizipieren und Veränderungen reibungslos zu implementieren.
Rollen und Zuständigkeiten
Mit einem adäquaten Veränderungsmanagement in der IT gehen einige wichtige Aufgaben einher, für die sich Einzelne verantwortlich zeichnen müssen. Dabei existiert keine universell gültige Liste von Rollen und Zuständigkeiten, da jeweils viele verschiedene Personen beteiligt und die jeweiligen Prozesse unterschiedlich ausstaffiert sind.
Trotzdem lassen sich einige Rollen ausmachen, die üblicherweise zum IT-Change-Management gehören:
Change Advisory Board (CAB)
Ein Change Advisory Board (CAB besteht üblicherweise aus Vertretern unterschiedlicher IT- und Business-Teams, die vor allem komplexe und risikobehaftete Änderungen evaluieren sowie genehmigen. Dabei geht es um mögliche Auswirkungen und darum, ob ein anvisierter Change tatsächlich zur Umsetzung kommt. Mitunter kommt für Notfall-Changes auch ein sogenanntes Emergency Change Advisory Board (ECAB) – ein verkleinertes, schnell reagierendes Gremium – zum Einsatz.
Change Manager
Diese Funktion koordiniert sowie überwacht den gesamten Change-Prozess und verwaltet das Change Advisory Board. Sie prüft die entsprechenden Anträge, entscheidet sich für oder gegen geplante Änderungen und leitet die entsprechenden Implementierungen. Oft ist dabei auch von einem Change Owner die Rede.
Change-Initiator
Betitelt sind damit Personen oder Teams, welche Änderungen vorschlagen oder beantragen. Oft handelt es sich dabei zum Beispiel um Entwickler oder Systemadministratoren, die Verbesserungsmöglichkeiten oder Fehlerbehebungen identifiziert haben.
Change Implementer
Gemeint sind damit IT-Mitarbeiter oder Administratoren, welche die entsprechende Änderung schließlich umsetzen, also zum Beispiel Software installieren, Updates fahren oder Konfigurationen anpassen.
Change Tester
Aufgabe der Verantwortlichen ist hier, mögliche Änderungen zu überprüfen, damit es nicht zu Komplikationen infolge der Änderungen kommt.
Konfigurationsmanager
Diese Rolle zeichnet sich dafür verantwortlich, dass Änderungen an der Systemkonfiguration dokumentiert sind und die Configuration Management Database (CMDB) aktualisiert ist, damit sich diese nachverfolgen und Learnings ableiten lassen.
Die wichtigsten Ziele
des IT-Change-Managements
Man könnte konstatieren, dass die Ziele eines IT-Change-Management-Prozesses denkbar simpel sind – nämlich geplante, notwendige und wünschenswerte Änderungen umzusetzen.
Dies beschreibt allerdings nur die Ausführung, den Change-Prozess selbst, wohingegen die übergeordneten Ziele – Stichwort: Management – vielfältig sein können.
Hier finden sich die wichtigsten Ziele aufgeführt:
1. Hohe Kontrolle
Änderungen brauchen die richtigen Prozesse, um erfolgreich zu verlaufen. Mit einem dedizierten IT-Change-Management können Organisationen sie besser kontrollieren und jeden Schritt effektiv steuern. Indem Änderungen sorgfältig geplant sind, lassen sich zum Beispiel Fehler und Störungen im Betrieb vermeiden. Nur was konsequent unter einer guten Kontrolle ist, liefert die gewünschten Ergebnisse.
2. Kontinuierliche Verbesserung
Bei IT-Änderungen steht viel auf dem Spiel. Man muss nur mal daran denken, was fehlgeschlagene Updates oder Implementierungen auf Unternehmens-Level für Konsequenzen haben können.
„Insbesondere für großangelegte Changes bewirkt ein gutes Management kontinuierliche Verbesserungen, um Fehltritte mittel- bis langfristig zu vermeiden, mit Trends Schritt zu halten und eine hohe Qualität zu erreichen.“
3. Schnellere Umsetzungen
Durch ein probates IT-Änderungsmanagement lassen sich Maßnahmen wie Implementierungen schneller leisten, was gleichermaßen Kosten, Zeit und Ressourcen spart. So bildet eine funktionale IT für viele Mitarbeiter die Grundvoraussetzung, um effektiv arbeiten zu können. Wichtige Errungenschaften bilden zum Beispiel zügige – aber dennoch – vollständige Genehmigungen und effiziente Umsetzungsprozesse.
4. Zusammenführung von IT-Teams
Der DevOps-Ansatz macht es vor: IT-Teams müssen zielführend zusammenarbeiten und interdisziplinär agieren, um ein passendes Gesamtbild vor Augen zu haben und konsequent ergebnisorientiert vorzugehen. ITSM-, ITOM-, Development- und Operations-Teams müssen gut koordiniert sein und miteinander kollaborieren, um relevante Änderungen schnell und effektiv implementieren zu können.
5. Kommunikation, Dokumentation und Transparenz
Gute Kommunikation bildet die Grundvoraussetzung dafür, dass IT-Teams und Stakeholder wichtige Change-Projekte erfolgreich abschließen können. Geleistete Arbeitsschritte zu dokumentieren und Transparenz herzustellen, schafft eine ideale Basis für Teamarbeit – eine wichtige Voraussetzung für Change-Projekte. Ein adäquates Prozessmanagement ist genauso entscheidend wie ein intakter Informationsfluss, um ein gutes IT-Änderungsmanagement zu leisten.
Checkliste für
IT-Change-Management
Damit Änderungen möglichst präzise geplant und Fortschritte im Blick sind, kann es sich als nützlich erweisen, mit einer Checkliste zu arbeiten.
Folgende Inhalte können sich dafür als sinnvoll erweisen:
Anforderung und Dokumentation
- Change-Antrag eingereicht und dokumentiert
- Stakeholder informiert
- Anforderungen erfasst
Kategorisierung und Priorisierung
- Change-Kategorie festgelegt
- Priorisierung erfolgt
- Ressourcen und Anforderungen geprüft
Rollen und Verantwortlichkeiten
- Verantwortlichkeiten zugewiesen
- Aufgaben delegiert
- Kommunikationsplan für Stakeholder erstellt
Risiko und Auswirkungen
- Risiken analysiert
- Auswirkungen evaluiert
- Notfall- und Wiederherstellungspläne erstellt
Planung und Genehmigung
- Erforderliche Genehmigungen eingeholt
- Compliance geprüft
- Zeitplan erstellt
- Projekt-Plan erstellt
- Rollout-Plan entwickelt
- Kommunikation geplant
- Ressourcen gesichert
Umsetzung und Überprüfung
- Änderung getestet
- Änderung automatisiert
- Funktion und Feedback geprüft
- Umsetzung überwacht und kommuniziert
- Dokumentation
Abschluss und Monitoring
- Change abgeschlossen
- Systemdokumentation aktualisiert
- KPIs und Change-Performance ausgewertet
- Bericht und Verbesserungen dokumentiert
Fazit: ein umfassender, entscheidender Prozess
Bei Änderungen wird es oft kritisch – und die IT tangiert Unternehmen oft auf ganzheitlicher Ebene. Somit steht es also außer Frage, ein adäquates IT Change Management zu betreiben. Änderungsprozesse wie die Implementierung neuer Software sollten dabei standardisiert und strukturiert ablaufen. Als entscheidend erweist es sich auch, relevante Informationen sowie Arbeitsschritte adäquat zu kommunizieren und zu dokumentieren.
Im Zentrum sollten die Zwecke und Ziele der jeweiligen Änderungen sowie deren (voraussichtliche) Folgen im Vordergrund stehen. Fest steht: Changes müssen nicht nur mit möglichst umfangreichen positiven Effekten, sondern auch mit einem geringen Risiko und möglichst wenigen negativen Auswirkungen versehen sein.
Für ein adäquates Änderungsmanagement müssen viele Eventualitäten bedacht, Ziele gesetzt, Strategien skizziert, Stakeholder informiert und passende Tests geleistet sein. So richtig hört ein IT-Change nie auf, sondern sollte im “Daily Business” – durch ein konsequentes Monitoring und daraus abgeleitete Maßnahmen – immer wieder in den Fokus geraten.
Erfahren Sie, wie OTRS Sie beim IT-Change-Management unterstützen kann.
