IT Change Management nach ITIL

Rollen und Verantwortlichkeiten im ITSM Change-Management-Prozess, Ziele, die 7 Rs sowie Unterschiede zwischen ITIL v3, v4 und v5 – eine Geschichte für mehr Durchblick im ITSM.

Inhalt:

• Was ist IT Change Management?
• Die zentralen Aspekte des IT Change Managements
• Wie lässt sich das IT Change Management in Unternehmen umsetzen?
• Erfolgreiche Implementierung: Organisatorisches Change Management (OCM)
• Die Evolution des Change Managements im ITIL-Kontext
• Die Unterschiede zwischen ITIL v3, v4 und v5 beim IT Change Management
• Best Practices und Fallstricke des IT Change Managements
• Erfolgsfaktoren im IT Change Management
• Beispiele aus der Wirtschaft

Was ist IT Change Management?

Änderungen in der IT können schnell zu Problemen führen: Sei es der simple Austausch eines Arbeitsplatzrechners, die Einführung einer neuen Software, der Wechsel in die Cloud oder gestiegene Sicherheitsanforderungen. Um solche Neuerungen im Unternehmen optimal umzusetzen, helfen definierte Prozesse. Mit dem Changemanagement lässt sich der gesamte Ablauf besser planen. Dies minimiert Risiken und vermeidet Unterbrechungen. Ziel ist es, Änderungen kontrolliert umzusetzen, Risiken zu minimieren und die Stabilität des IT-Betriebs sicherzustellen. 

Die zentralen Aspekte des IT Change Managements

Beim IT Change Management gibt es sieben relevante Aspekte die beim Erstellen und Bearbeiten eines Change Requests berücksichtigt werden sollten. Die sieben einfachen Fragen helfen dabei, Changes strukturiert auf den Weg zu bringen, die sonst wegen zu vieler Unklarheiten abgelehnt würden.

1. Wer hat den Änderungsantrag eingebracht?

In der Fülle von Abteilungen, Ansprechpartnerinnen und Mitentscheidern sind Change Requests auf Zuruf ein Garant für Chaos. Zunächst muss geklärt werden, woher die Anforderung kommt. Für wen tun wir das? Wo bekomme ich Antworten auf Rückfragen her? Das systematisch zu dokumentieren ist der erste Schritt für strukturiertes IT Change Management. 

2. Was ist der Grund für den Change?

Warum machen wir das? Aus welchem Grund wird der Change gebraucht? Eine gute Lösung ist nichts wert, wenn wir damit das falsche Problem lösen. Zum anderen werden mit einem Change häufig Lösungsansätze skizziert, die den Blick auf eine bessere Idee versperren. Wenn wir Klarheit über die Gründe für den Change bekommen, lassen sich Chancen und Risiken besser gegeneinander abwägen. Für wichtige Themen suchen wir dann nach der Lösung, die im Kontext am besten passt, während Änderungen mit hohem Risiko bei minimalem Geschäftsnutzen verhindert werden.

Bei der Klassifizierung hilft die Portfolio-Analyse entlang der Vierfeldermatrix, wobei sich die Changes ähnlich wie beim Incident Management entlang der zwei Achsen (1) Auswirkung (z. B. Anzahl der User und Devices) und (2) Dringlichkeit sortieren lassen. 

3. Welchen Ertrag versprechen wir uns von diesem Change?

Die Zukunft kennt niemand und dennoch ist es wichtig, verschiedene Szenarien durchzuspielen. Was soll die Änderung einbringen, damit wir anschließend sagen können: das hat sich gelohnt. Nicht jeder Change übersetzt sich direkt in Kundennutzen, der z. B. in Form eines Software-Features einen Aufpreis der Software rechtfertigt. Die Automatisierung von zeitaufwändigen händischen Tasks kann dagegen Kapazitäten im Development für Innovationen freilegen. Automatische Regressions- und Lasttests entlasten den technischen Support. Der Abbau von technischen Altlasten (Technical Debt) hält die Entwicklungsumgebung zukunftssicher, so dass auf Neuerungen am Markt schnell reagiert werden kann. Diese weichen Faktoren müssen, so gut es geht, in harte Kennzahlen mit Blick auf Kosten und Nutzen übersetzt werden, anhand derer sich priorisieren lässt.  

4. Welche Risiken sind mit dem beantragten Change verbunden? 

Jede Änderung in der IT birgt Risiken. Entscheidend ist daher, diese frühzeitig zu identifizieren, zu bewerten und gezielt zu steuern. Zu den typischen Risiken eines Changes zählen: Betriebsunterbrechungen – etwa durch Ausfälle oder Performance-Probleme –, Abhängigkeiten zu anderen Systemen, die unbeabsichtigte Auswirkungen nach sich ziehen können, Fehlkonfigurationen oder Integrationsprobleme sowie Sicherheitsrisiken, insbesondere beim Einsatz neuer Technologien oder Schnittstellen. Dabei ist zu beachten, dass Änderungen selten isoliert wirken: Selbst kleine Anpassungen können Auswirkungen auf andere Services, Prozesse oder Nutzergruppen haben. Die Konsequenzen sollte man daher vorab bestmöglich durchspielen. 

5. Welche Ressourcen werden benötigt, um den Change umzusetzen? 

Auf dem Makro-Level geht es hier immer um Zeit und Geld, auf der Mikro-Ebene des IT Change Managements um Mensch (Skills) und Maschine (Capabilities). Diese existieren – oder fehlen – nicht im Vakuum. Sind die Kräfte in einem Projekt gebunden, fehlen sie in einem anderen. Gehen wir trotzdem beide an? Gleichzeitig? Welche Verzögerungen treten an anderer Stelle auf, wenn wir einen Change umsetzen? Die Frage hört bei der internen IT-Organisation nicht auf, sondern umfasst die gesamte Wertschöpfungskette bis hin zum Kunden (Customer Value Chain). Auch Antworten auf diese Fragen müssen in die Priorisierung von IT-Projekten einfließen.  

6. Wer ist für Erstellung, Testen und Implementierung verantwortlich? 

Meist sind das für die einzelnen Teilschritte unterschiedliche Leute im Team oder sogar verschiedene Abteilungen. Umso wichtiger ist es, die Verantwortlichkeiten einerseits transparent und nachvollziehbar und somit um- und durchsetzbar zu machen. Dann ist unmissverständlich klar, wer für welche Aufgabe aktiv werden muss und im Falle eines Misserfolgs lassen sich unproduktive Schuldzuweisungen vermeiden. Generell gilt: Über das gesamte Change und Release Management hinweg muss die Verantwortung klar verteilt und allen transparent sein.  

7. Welche Beziehung besteht zwischen dem vorgeschlagenen Change und anderen Änderungen im Unternehmen?

IT-Umgebungen sind komplex und stehen in vielen Abhängigkeiten zu anderen Bereichen und Funktionen im System. Manchmal reicht es, auf Auswirkungen in anderen Bereichen hinzuweisen, in anderen Fällen ist man auf deren Vorarbeiten angewiesen. Im Idealfall sollte eine integrierte Konfigurationsmanagement-Datenbank (Configuration Management Database, CMDB) genutzt werden, welche gegenseitige Abhängigkeiten dokumentiert. Dies ermöglicht die gemeinsame Zeit- und Reihenfolgeplanung zur Umsetzung von Changes bei möglichst wenig Ausfallzeiten und Zeitverzögerungen. Wo keine vollständige CMDB vorhanden ist, können alternative Ansätze helfen – etwa die Abstimmung mit Fachexperten, die Nutzung von Monitoring- oder Asset-Daten oder die Auswertung von Erfahrungswerten aus vergangenen Changes. Entscheidend ist dabei nicht das Werkzeug, sondern die Transparenz der Abhängigkeiten: Nur so lassen sich Changes koordiniert und mit möglichst geringem Risiko umsetzen.

Wie lässt sich IT Change Management im Unternehmen umsetzen? 

Um das IT Change Management im Unternehmen optimal umzusetzen, müssen Veränderungen stets nach festgelegten Punkten erfolgen.

Servicemanagement Tools für einheitliche ITSM-Prozesse

Zunächst müssen der Ist-Zustand analysiert und der Soll-Zustand definiert werden. Danach wird ein Zeitplan für den Change erstellt. Ein Testmodell hilft, Problemen – zum Beispiel bei der Servicequalität – vorzubeugen. Läuft das Testmodell, wird die Veränderung wie geplant umgesetzt.

Einfacher funktioniert dies, wenn die ITSM-Prozesse mit einer Service Management Software unterstützt und vereinheitlicht werden. Dieses sollte folgende Anforderungen erfüllen:

• Bessere Prozesskontrolle über:

  • eine Tool-basierte Forward Schedule of Change (FSC),

  • eine organisationsübergreifende Kalenderplanung,

  • eine umfassende Ressourcenverwaltung sowie

  • eine Steuerung und Kontrolle aller Change-Management-Rollen und -Verantwortlichkeiten

• Berechtigungen für alle Prozessaktivitäten ausschließlich über die Integration mit dem unternehmensweiten LDAP-System
• Transparenz über Abhängigkeiten und mögliche Auswirkungen in der IT-Infrastruktur (durch vorhandene oder integrierte CMDB)
• Transparenz über alle Change- und Release-Management-Aktivitäten vom erstmaligen Request bis zum Post Implementation Review
• Bearbeitung und Dokumentation aller Change-Management- und Release-Management-Aktivitäten im Change Management Tool; vollständig basierend auf dem Inventar der Asset & Configuration Management Database (CMDB), ob nativ oder integriert
• Einfache, nachvollziehbare Kommunikation zu den Prozessschritten in allen Change-Management-Phasen – bestenfalls automatisch abgebildet innerhalb des Tools
• Umfassendes, transparentes Risikomanagement als Voraussetzung für die erfolgreiche Arbeit im Change Advisory Board (CAB) – insbesondere bei der Bewertung von Emergency Changes im eCAB
• Aufwandsarmes Messen und Berichten aller relevanten Key Performance Indikatoren (KPIs)
• Vereinfachung des ITIL-Change-Management-Workflows

Eine IT Management Software, die diese Anforderungen bewältigt, trägt erheblich zur Verbesserung der Change-Management-Prozesse bei.

Erfolgreiche Implementierung: Organisatorisches Change Management (OCM)

Nach erfolgreicher Implementierung wird der gesamte Vorgang bewertet. Was sollte beim nächsten Mal optimiert werden? Wurden alle gesetzten Ziele erreicht? Wurde der Zeitplan eingehalten? Am besten wird für diese Überprüfung ein eigener Change-Manager eingesetzt, der das gesamte Projekt des IT Service Management überwacht und stetig optimiert.

Menschen im Mittelpunkt

Bei aller technischer Unterstützung darf aber auch der Mensch dahinter nicht vergessen werden. 

Service Management findet nicht isoliert in Systemen statt, sondern in Organisationen mit gewachsenen Strukturen, etablierten Arbeitsweisen und unterschiedlichen Interessen. Veränderungen greifen stets in bestehende Routinen und Verantwortlichkeiten ein und können zu Unsicherheiten, Widerständen oder politischen Spannungen führen.

Moderne Service-Management-Ansätze tragen diesem Umstand Rechnung. Mit der Einführung von ITIL 4 wurde der Fokus bewusst von starren Prozessen hin zu Wertschöpfung, Zusammenarbeit und Anpassungsfähigkeit verschoben. Die nächste Evolutionsstufe stellt ITIL 5 dar – gemeint ist damit kein neues Framework, sondern eine Weiterentwicklung hin zu einem Service Management, das stärker auf Steuerung, Automatisierung und datenbasierte Entscheidungen ausgerichtet ist.

Mit zunehmender Integration von Automatisierung und Künstlicher Intelligenz (KI) verschiebt sich die Rolle des Menschen weiter: Im KI-gestützten Service Management wandelt sich die Aufgabe der Mitarbeitenden von der reinen Ausführung hin zu Steuerung, Entscheidungsfindung und kontinuierlicher Verbesserung.

Die Evolution des Change Managements im ITIL-Kontext

Mit ITIL 3 wurde Change Management als klar strukturierter, prozessorientierter Bestandteil der Service Transition verstanden – mit starkem Fokus auf Kontrolle, Standardisierung und Risikominimierung.

ITIL 4 hat diesen Ansatz weiterentwickelt, indem es Change Management als flexible Service-Management-Praktik („Change Enablement") neu positioniert und stärker in die gesamte Service-Wertschöpfungskette integriert hat. Der Fokus verschiebt sich dabei von starren Abläufen hin zu Anpassungsfähigkeit, Geschwindigkeit und Wertbeitrag.

Die aktuell diskutierte nächste Evolutionsstufe – vielfach als „ITIL 5" bezeichnet – geht darüber hinaus: Sie beschreibt kein neues Regelwerk, sondern einen Wandel hin zu einem daten- und KI-gestützten Steuerungsmodell. Changes werden nicht mehr primär geplant und sequenziell abgearbeitet, sondern zunehmend kontextbasiert, prädiktiv und teilweise automatisiert gesteuert. Der Schwerpunkt liegt damit nicht mehr allein auf der sicheren Umsetzung von Änderungen, sondern auf deren aktiver Rolle bei der kontinuierlichen Steuerung von Services, Wertströmen und Business Impact.

Die Unterschiede zwischen ITIL v3, v4 und v5 beim IT Change Management

Auch wenn sich Service Management aktuell stark weiterentwickelt, bleiben ITIL v3 und ITIL v4 weiterhin hochrelevant. Beide Frameworks bilden die Grundlage für etablierte Prozesse, Rollen und Strukturen in den meisten Organisationen. Sie haben über Jahre hinweg bewährte Methoden hervorgebracht, um Änderungen kontrolliert umzusetzen und den IT-Betrieb stabil zu halten.

Die aktuellen Entwicklungen rund um ITIL 5 bauen auf diesem Fundament auf. Da ITIL v5 sich noch in der Einführungsphase befindet, konzentrieren wir uns an dieser Stelle auf die etablierten Versionen, die in den meisten IT-Organisationen heute im Einsatz sind.

Best Practices und Fallstricke des IT Change Managements

An einem Anwendungsbeispiel möchten wir Ihnen den gesamten Prozess erläutern.

Nach einem folgenschweren Ausfall im IT-System seiner Firma ist der IT-Leiter aufgefordert, den Change-Management-Prozess zu überarbeiten. Den Fokus legt er dabei klar auf das Risikomanagement, eine der sieben Anforderungen im ITIL Change Management.

Änderungen am IT-Setup

Auslöser war eine kleine Änderung an der Hardware in einer regionalen Filiale. Die Störung hatte sich flächenartig ausgebreitet und am Ende die Kommunikations- und Videosysteme der gesamten Organisation stark beeinträchtigt. Mitarbeitende im Homeoffice waren abgeschnitten. Meetings zwischen der Geschäftsleitung und Kunden wie auch Lieferanten konnten nicht stattfinden. Drei Stunden arbeitete die IT, bis wesentliche Geschäftsprozesse wieder anliefen.

Als ITIL-Experte und Process Owner für das IT Change Management waren dem IT-Leiter die Zusammenhänge, die zu dem Ausfall geführt hatten, in ihrer Gesamtheit mittlerweile transparent.

Die Root Cause Analysis war durchgeführt worden, eine Post Implementation Review gab es dagegen nicht. Die Änderung in der Außenstelle war weder durch den Change Prozess genehmigt, noch war sie durch eine qualifizierte und autorisierte Person vorgenommen worden.

Risiko-Management

Der Change-Management-Prozess sah konkrete Schritte für das Risiko Management vor, um genau solche Ausfälle zu verhindern. Zudem hatte der IT-Leiter schon vor zwei Jahren gemeinsam mit dem IT Change Manager eine Policy verfasst, die die Best Practices des Change Managements nach ITIL definiert und für die eigene IT-Organisation abbildet. Regelmäßig fanden Schulungen für die Teams statt, in denen die Inhalte wiederholt und diskutiert wurden. Alle Vorgaben aus dem Risiko Management der Change Management Policy waren schlicht ausgehebelt – sie waren einfach nicht beachtet worden.

Erfolgsfaktoren im IT Change Management

Veränderung kann nur gelingen, wenn klar ist, wofür man es tut und alle Beteiligten Vertrauen fassen, dass die Anstrengung auch gelingen kann. Diese Transparenz und Zuversicht herzustellen, war die größte Herausforderung.

Dass man künftig Ausfälle wie den jüngsten der Kommunikationssysteme verhindern wollte, dafür musste der IT-Leiter keine große Überzeugungsarbeit leisten. Niemand wünscht sich Fehler und Widersprüche im Prozess-Workflow, gestörte Abläufe, Ausfälle und Eskalationen. Auf einfach geregelte, nachvollziehbare und gut dokumentierte Abläufe mit klaren Verantwortlichkeiten sowie ein kontrolliertes Risikomanagement konnten sich alle einigen, denen eine sauber funktionierende, performante IT-Infrastruktur am Herzen lag.

Anforderungsliste an das künftige ITSM-Tool

• Bedeutung einer integrierten Asset & Configuration Management Database hervorheben und die Zusammenhänge mit dem jüngsten Vorfall unterstreichen

• Request for Information (RfI) um die Aspekte zu ergänzen, die nicht allein den prozessualen, systemnahen Funktionalitäten dienen

• Tool-Funktionen, die Transparenz und Automatisierung ermöglichen und dadurch Routinearbeiten überflüssig machen, sollten mehr Gewicht bekommen

• Auch auf die einfache Bedienbarkeit über verschiedene Geräte und Kanäle hinweg sollte mehr Augenmerk gelegt werden

Nur dann, so war er sich sicher, würden sich die Kollegen und Kolleginnen schnell mit den Veränderungen anfreunden. Nur dann könnten die Veränderungen im IT Change-Management-Prozess schnell aktiviert werden. Und nur unter dieser Voraussetzung lassen sich Systeme optimieren, Prozesse verbessern und Großausfälle künftig zuverlässig verhindern. Geschäftsziele werden so besser erreicht und die Digitalisierung im Unternehmen vorangetrieben.

Beispiele aus der Wirtschaft 

Lufthansa (2023) 

Ein IT-Ausfall bei der Lufthansa im Februar 2023 führte zu erheblichen Störungen im Flugbetrieb. Ursache war die Beschädigung eines Datenkabels, wodurch zentrale Systeme wie Check-in und Boarding teilweise nicht verfügbar waren. Tausende Passagiere waren betroffen, Flüge mussten gestrichen oder umgeleitet werden. Der Vorfall zeigte, wie kritisch Abhängigkeiten und fehlende Redundanzen in komplexen IT-Systemen sein können.

(Quelle: ADAC)

Deutsche Bank / Postbank (2023)

Im Zuge der Migration von Postbank-Systemen auf die Infrastruktur der Deutschen Bank kam es 2023 zu massiven Einschränkungen für Kunden. Viele konnten zeitweise nicht auf ihre Konten zugreifen oder Transaktionen durchführen. Die Probleme hielten teilweise über Wochen an und führten zu erheblichem Vertrauensverlust. Die Migration verdeutlichte die Risiken großflächiger Systemumstellungen ohne ausreichende Stabilisierung im laufenden Betrieb.

(Quelle: Spiegel)

IT Change Management professionell umsetzen

Unsere Serviceware-Experten unterstützen Sie bei der Umsetzung Ihrer individuellen Anforderungen.

Live-Demo buchen