5. Change Enablement

5.1 Change Enablement – Ziele, Begriffe und Abgrenzung

Kurz erklärt

Change Enablement beschäftigt sich damit, Änderungen an Services, Systemen, Prozessen oder Infrastruktur kontrolliert, nachvollziehbar und risikobewusst umzusetzen.

Ziel ist nicht, Änderungen zu verhindern.

Ziel ist, nützliche Änderungen zu ermöglichen, ohne unnötige Risiken für laufende Services, Benutzer oder Geschäftsprozesse zu erzeugen.

Warum Change Enablement wichtig ist

IT-Umgebungen verändern sich ständig.

Beispiele:

Jede Änderung kann Nutzen bringen.

Jede Änderung kann aber auch Störungen verursachen.

Change Enablement sorgt dafür, dass Änderungen:

werden.

Change Enablement ist kein Änderungsverbot

Ein häufiger Irrtum:

Change Enablement bedeutet, dass jede Änderung möglichst schwer gemacht wird.

Das ist falsch.

Change Enablement soll Änderungen ermöglichen.

Aber Änderungen sollen so durchgeführt werden, dass:

Merke

Gute Change-Steuerung schützt nicht vor Veränderung.

Sie schützt vor unkontrollierter Veränderung.

Was ist ein Change?

Ein Change ist eine Änderung an einem Service oder an einem unterstützenden Bestandteil eines Service.

Betroffen sein können beispielsweise:

Nicht jede Tätigkeit ist automatisch ein Change im engeren Sinn.

Die Organisation muss festlegen, welche Arten von Änderungen über Change Enablement gesteuert werden.

Beispiele für Changes

Change Beispiel
Software-Change Update einer Fachanwendung
Infrastruktur-Change Austausch eines Servers
Netzwerk-Change Anpassung einer Firewall-Regel
Cloud-Change Erstellen einer neuen Ressourcengruppe
Security-Change Aktivierung von MFA
Konfigurations-Change Änderung eines Dienstparameters
Datenbank-Change Schemaänderung
Prozess-Change neuer Genehmigungsworkflow
Monitoring-Change neue Alarmregel
Dokumentations-Change Aktualisierung eines Runbooks

Ziele von Change Enablement

Change Enablement verfolgt mehrere Ziele:

Change Enablement verbindet Stabilität und Veränderungsfähigkeit.

Risiken unkontrollierter Änderungen

Unkontrollierte Änderungen können zu schweren Problemen führen.

Beispiele:

Viele Incidents entstehen nicht durch völlig unbekannte Fehler, sondern durch schlecht geplante oder schlecht dokumentierte Änderungen.

Change Enablement und Incident Management

Change Enablement steht eng mit Incident Management in Verbindung.

Ein Change kann:

Beispiel:

Nach einem Update funktioniert eine Anwendung nicht mehr.

Incident Management stellt den Service schnell wieder her.

Change Enablement hilft anschließend zu klären:

Change Enablement und Problem Management

Problem Management liefert häufig den Anlass für Changes.

Beispiele:

Die dauerhafte Lösung eines Problems erfordert oft einen Change.

Problem Management beschreibt Ursache, Risiko und Lösungsvorschlag.

Change Enablement sorgt für kontrollierte Umsetzung.

Change Enablement und Knowledge Management

Änderungen erzeugen neues Wissen.

Nach einem Change müssen möglicherweise aktualisiert werden:

Ein Change ist nicht vollständig abgeschlossen, wenn die Technik funktioniert, aber das Wissen veraltet bleibt.

Change Enablement und Service Configuration Management

Service Configuration Management liefert Informationen über Configuration Items und Abhängigkeiten.

Für Changes ist wichtig zu wissen:

Ohne diese Informationen kann die Auswirkungsbewertung unvollständig sein.

Change Enablement und Information Security Management

Viele Changes haben Sicherheitsbezug.

Beispiele:

Solche Changes benötigen möglicherweise besondere Prüfung durch Informationssicherheit.

Dabei geht es nicht darum, jede Änderung zu blockieren.

Es geht darum, Risiken bewusst zu bewerten.

Change Enablement und Continual Improvement

Change Enablement unterstützt kontinuierliche Verbesserung.

Verbesserungen werden oft durch Changes umgesetzt.

Beispiele:

Continual Improvement erkennt Verbesserungsbedarf.

Change Enablement sorgt dafür, dass die Änderung kontrolliert umgesetzt wird.

Change Request

Ein Change Request beschreibt eine gewünschte Änderung.

Typische Inhalte:

Das konkrete Format hängt vom ITSM-Werkzeug und der Organisation ab.

Warum ein Change Request wichtig ist

Ein Change Request macht eine Änderung nachvollziehbar.

Er beantwortet zentrale Fragen:

Ohne diese Informationen kann eine Änderung schwer bewertet werden.

Auswirkung und Risiko bewerten

Vor einem Change sollte geprüft werden:

Die Bewertung muss zum Umfang der Änderung passen.

Eine kleine Standardänderung benötigt weniger Aufwand als eine kritische Produktionsumstellung.

Nutzen bewerten

Neben Risiken muss auch der Nutzen betrachtet werden.

Möglicher Nutzen:

Ein Change kann trotz Risiko sinnvoll sein, wenn der Nutzen wichtig genug ist und die Risiken kontrolliert werden.

Change Enablement und Geschwindigkeit

Nicht alle Changes dürfen gleich langsam oder gleich schnell behandelt werden.

Eine Organisation muss unterscheiden zwischen:

Zu viel Kontrolle verlangsamt notwendige Verbesserungen.

Zu wenig Kontrolle erzeugt Störungen.

Gutes Change Enablement findet ein passendes Gleichgewicht.

Typische Change-Arten

Viele Organisationen unterscheiden mindestens:

Die genaue Bezeichnung und Ausgestaltung kann je nach Organisation unterschiedlich sein.

ITIL gibt Konzepte vor, aber keine für alle Organisationen identische Prozessform.

Standard Change

Ein Standard Change ist eine vorab bewertete, wiederholbare und risikoarme Änderung.

Typische Merkmale:

Beispiele:

Ein Standard Change benötigt nicht jedes Mal eine vollständige Einzelgenehmigung.

Er muss aber sauber definiert und kontrolliert sein.

Normal Change

Ein Normal Change ist eine Änderung, die bewertet, geplant und je nach Risiko genehmigt werden muss.

Beispiele:

Normal Changes benötigen typischerweise:

Emergency Change

Ein Emergency Change ist eine dringende Änderung, die notwendig ist, um einen akuten Schaden zu vermeiden oder einen Service schnell wiederherzustellen.

Beispiele:

Emergency Changes dürfen nicht als Abkürzung für schlecht geplante Arbeit missbraucht werden.

Auch bei hoher Dringlichkeit sollten Entscheidungen und Maßnahmen dokumentiert werden.

Nachträgliche Prüfung ist besonders wichtig.

Change Authority

Eine Change Authority ist eine Person oder Gruppe, die Changes bewertet oder genehmigt.

Je nach Organisation und Change-Art können das sein:

Die Change Authority sollte zur Größe, zum Risiko und zur Auswirkung des Changes passen.

Nicht jede Änderung benötigt ein großes Gremium.

Change Advisory Board

Ein Change Advisory Board kann bei komplexeren oder risikoreicheren Changes beraten.

Mögliche Aufgaben:

Ein Change Advisory Board sollte nicht jede kleine Änderung ausbremsen.

Es sollte dort unterstützen, wo mehrere Perspektiven notwendig sind.

Kommunikation bei Changes

Betroffene Benutzer und Stakeholder sollten rechtzeitig informiert werden.

Zu kommunizieren sind je nach Situation:

Gute Kommunikation reduziert Unsicherheit und unnötige Tickets.

Wartungsfenster

Ein Wartungsfenster ist ein geplanter Zeitraum für Änderungen.

Es hilft, Risiken zu begrenzen.

Zu beachten:

Ein Wartungsfenster sollte nicht nur technisch bequem sein.

Es muss auch zur Nutzung des Services passen.

Rollback und Backout

Vor riskanten Changes sollte klar sein, wie die Änderung zurückgenommen werden kann.

Zu prüfen ist:

Nicht jeder Change kann einfach zurückgerollt werden.

Dann muss das Risiko besonders sorgfältig bewertet werden.

Testen vor Umsetzung

Tests reduzieren Risiken.

Mögliche Tests:

Der Testumfang muss zum Risiko passen.

Ein kritischer Change benötigt mehr Prüfung als ein kleiner Standard Change.

Erfolg eines Changes prüfen

Nach der Umsetzung sollte geprüft werden:

Ein Change ist nicht nur deshalb erfolgreich, weil die technische Änderung durchgeführt wurde.

Er ist erfolgreich, wenn der gewünschte Nutzen ohne unvertretbare Nebenwirkungen erreicht wurde.

Failed Change

Ein Failed Change ist eine Änderung, die nicht wie geplant erfolgreich war oder negative Auswirkungen verursacht hat.

Mögliche Ursachen:

Failed Changes sollten analysiert werden.

Ziel ist Lernen, nicht Schuldzuweisung.

Typische Fehler

Fehler 1

Änderungen werden ohne Bewertung direkt in Produktion durchgeführt.

Fehler 2

Change Enablement wird als reine Bürokratie verstanden.

Fehler 3

Risiken werden nur technisch, nicht geschäftlich bewertet.

Fehler 4

Abhängigkeiten zwischen Services werden nicht geprüft.

Fehler 5

Benutzer werden nicht informiert.

Fehler 6

Rollback fehlt oder ist unrealistisch.

Fehler 7

Tests sind unzureichend.

Fehler 8

Emergency Changes werden als Abkürzung genutzt.

Fehler 9

Nach dem Change wird der Erfolg nicht geprüft.

Fehler 10

Dokumentation und Knowledge Base werden nicht aktualisiert.

Fehler 11

Changes werden nicht mit Incidents oder Problems verknüpft.

Fehler 12

Failed Changes werden nicht ausgewertet.

Praxisbeispiel: Firewall-Regel

Ausgangslage

Eine neue Schnittstelle zwischen zwei Anwendungen soll freigeschaltet werden.

Change Request

Risiko

Falsche Regel kann Zugriff verhindern oder ungewollten Zugriff erlauben.

Erfolgskriterium

Die Schnittstelle funktioniert und es gibt keine unerwarteten Verbindungsfreigaben.

Praxisbeispiel: Zertifikat erneuern

Ausgangslage

Ein Zertifikat läuft bald ab.

Change

Zertifikat wird vor Ablauf erneuert.

Prüfung

Nutzen

Ausfall durch abgelaufenes Zertifikat wird verhindert.

Praxisbeispiel: Emergency Change

Ausgangslage

Eine kritische Sicherheitslücke wird aktiv ausgenutzt.

Maßnahme

Ein Sicherheitsupdate muss kurzfristig eingespielt werden.

Wichtig

Checkliste Change Request

Checkliste Umsetzung

Checkliste Nachbereitung

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker für Systemintegration führen im Alltag viele Changes durch oder bereiten sie vor.

Beispiele:

Wichtig ist dabei nicht nur die technische Umsetzung.

Wichtig ist auch:

Zusammenfassung

Änderungsbedarf erkennen
↓
Change Request erstellen
↓
Nutzen, Risiko und Auswirkungen bewerten
↓
Change-Art bestimmen
↓
Freigabe oder Vorabgenehmigung prüfen
↓
Umsetzung planen
↓
Benutzer und Stakeholder informieren
↓
Change kontrolliert durchführen
↓
Ergebnis testen
↓
Dokumentation, Knowledge und CMDB aktualisieren
↓
Lessons Learned übernehmen

Merksätze

Change Enablement verhindert nicht Veränderung, sondern ermöglicht sichere Veränderung.

Jede Änderung kann Nutzen und Risiko erzeugen.

Ein kleiner technischer Change kann große geschäftliche Auswirkungen haben.

Rollback muss vor der Umsetzung bedacht werden.

Emergency Changes sind kein Ersatz für schlechte Planung.

Ein Change ist erst erfolgreich, wenn der gewünschte Nutzen erreicht wurde.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

angepasst werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026

5.2 Change-Typen und Risikobewertung

Kurz erklärt

Nicht jede Änderung besitzt dasselbe Risiko.

Change Enablement unterscheidet deshalb verschiedene Change-Typen und bewertet Änderungen nach Risiko, Auswirkung, Dringlichkeit und Standardisierbarkeit.

Ziel ist, einfache und risikoarme Änderungen schnell durchführen zu können, während kritische Änderungen sorgfältig geplant und kontrolliert werden.

Warum Change-Typen wichtig sind

Eine kleine Standardänderung sollte nicht denselben Aufwand verursachen wie eine kritische Produktionsumstellung.

Beispiele:

Diese Änderungen unterscheiden sich stark in:

Change-Typen helfen dabei, den passenden Umgang mit einer Änderung festzulegen.

Grundidee der Change-Klassifizierung

Eine Organisation sollte festlegen:

ITIL schreibt keine für alle Organisationen identische Change-Matrix vor.

Die Einteilung muss zur Organisation, zu den Services und zu den Risiken passen.

Typische Change-Typen

Viele Organisationen unterscheiden mindestens:

Change-Typ Kurzbeschreibung
Standard Change vorab bewertete, wiederholbare und risikoarme Änderung
Normal Change Änderung mit individueller Bewertung, Planung und Genehmigung
Emergency Change dringende Änderung zur Abwehr akuter Schäden oder zur schnellen Wiederherstellung
Major Change besonders umfangreiche, geschäftskritische oder risikoreiche Änderung
Minor Change kleine Änderung mit begrenzter Auswirkung
Routine Change regelmäßig vorkommende Änderung nach definiertem Ablauf

Nicht jede Organisation verwendet alle Begriffe.

Wichtig ist, dass die Begriffe intern eindeutig definiert sind.

Standard Change

Ein Standard Change ist eine Änderung, die bereits vorab geprüft und genehmigt wurde.

Typische Merkmale:

Beispiele:

Ein Standard Change ist nicht ungeprüft.

Er wurde nur bereits vorab bewertet.

Normal Change

Ein Normal Change wird individuell bewertet, geplant und genehmigt.

Typische Merkmale:

Beispiele:

Normal Changes benötigen je nach Risiko unterschiedlich viel Prüfung.

Emergency Change

Ein Emergency Change ist eine dringende Änderung, die wegen eines akuten Risikos oder Schadens schnell durchgeführt werden muss.

Typische Auslöser:

Beispiele:

Emergency Changes dürfen nicht als Abkürzung für schlechte Planung genutzt werden.

Auch unter Zeitdruck müssen Maßnahmen nachvollziehbar dokumentiert und nachträglich überprüft werden.

Major Change

Ein Major Change ist eine Änderung mit besonders hoher Auswirkung oder hohem Risiko.

Beispiele:

Typische Merkmale:

Ein Major Change ist nicht automatisch ein Emergency Change.

Er kann lange geplant sein und trotzdem sehr risikoreich sein.

Minor Change

Ein Minor Change ist eine kleinere Änderung mit begrenzter Auswirkung.

Beispiele:

Auch kleine Changes können Risiken besitzen.

Beispiel:

Eine scheinbar kleine Firewall-Regel kann große Auswirkungen haben, wenn sie einen kritischen Service betrifft.

Change-Typen im Vergleich

Kriterium Standard Change Normal Change Emergency Change
Risiko gering und vorab bewertet individuell zu bewerten häufig hoch oder zeitkritisch
Dringlichkeit planbar planbar akut
Genehmigung vorab genehmigt je nach Risiko erforderlich beschleunigt oder nachträglich ergänzt
Ablauf standardisiert individuell geplant schnell, aber kontrolliert
Dokumentation standardisiert vollständig nach Bedarf mindestens entscheidungsrelevant
Beispiele Standardsoftware produktives Update kritischer Sicherheitspatch

Risikobewertung

Risikobewertung bedeutet, mögliche negative Folgen eines Changes vor der Umsetzung zu betrachten.

Typische Fragen:

Risiko entsteht aus Wahrscheinlichkeit und Auswirkung.

Auswirkung bewerten

Die Auswirkung beschreibt, wie stark Benutzer, Services oder Geschäftsprozesse betroffen wären.

Zu prüfen ist:

Je größer die mögliche Auswirkung, desto sorgfältiger muss der Change gesteuert werden.

Wahrscheinlichkeit bewerten

Die Wahrscheinlichkeit beschreibt, wie wahrscheinlich ein Fehler bei der Änderung ist.

Einflussfaktoren:

Eine Änderung mit geringer Auswirkung, aber hoher Fehlerwahrscheinlichkeit kann trotzdem relevant sein.

Dringlichkeit bewerten

Nicht jede dringende Änderung ist automatisch ein Emergency Change.

Zu prüfen ist:

Dringlichkeit darf nicht dazu führen, dass grundlegende Sicherheits- und Dokumentationspflichten ignoriert werden.

Nutzen bewerten

Neben Risiko und Dringlichkeit muss der Nutzen betrachtet werden.

Möglicher Nutzen:

Ein Change kann sinnvoll sein, obwohl er Risiko besitzt.

Entscheidend ist, ob Nutzen und Risiko bewusst bewertet wurden.

Typische Risikokriterien

Kriterium Beispiele
Servicekritikalität produktiv, geschäftskritisch, Testsystem
Benutzerimpact einzelne Person, Team, Standort, Kunden
Technische Komplexität einfache Konfiguration, Migration, Architekturänderung
Rollback-Fähigkeit einfach, schwierig, nicht möglich
Testabdeckung vollständig getestet, teilweise getestet, nicht getestet
Sicherheitsbezug Berechtigungen, Firewall, Daten, Logging
Zeitpunkt Geschäftszeit, Wartungsfenster, Monatsabschluss
Abhängigkeiten Datenbank, Netzwerk, Identität, Lieferant
Erfahrung häufig durchgeführt, neu, einmalig
Kommunikationsbedarf keine Benutzerinfo, interne Info, Kundenkommunikation

Einfache Risikomatrix

Eine einfache Matrix kann helfen.

Auswirkung Wahrscheinlichkeit niedrig Wahrscheinlichkeit mittel Wahrscheinlichkeit hoch
hoch mittel hoch sehr hoch
mittel niedrig mittel hoch
niedrig niedrig niedrig mittel

Diese Matrix ist nur ein Beispiel.

Die Organisation muss eigene Bewertungsstufen festlegen.

Beispiel für Change-Risikostufen

Risikostufe Bedeutung
Niedrig begrenzte Auswirkung, gut getestet, einfacher Rollback
Mittel mehrere Benutzer oder wichtiger Service betroffen, Rollback möglich
Hoch kritischer Service, viele Benutzer, komplexe Änderung
Sehr hoch geschäftskritisch, schwieriger Rollback, erhebliche Sicherheits- oder Datenrisiken

Die Risikostufe beeinflusst:

Change Authority passend wählen

Die Genehmigungsinstanz sollte zum Risiko passen.

Beispiele:

Change mögliche Change Authority
Standardsoftware installieren vorab genehmigter Standardprozess
kleine Konfigurationsänderung Team Lead oder Service Owner
produktives Anwendungsupdate Change Manager oder Change Advisory Board
sicherheitskritische Firewall-Regel Informationssicherheit und Service Owner
Emergency Security Patch Emergency Change Authority
große Plattformmigration Management, Service Owner, Change Board

Nicht jede Änderung benötigt ein großes Gremium.

Aber risikoreiche Änderungen brauchen ausreichend Perspektiven.

Wann ein Change Advisory Board sinnvoll ist

Ein Change Advisory Board kann sinnvoll sein, wenn:

Ein CAB sollte beraten und Risiken sichtbar machen.

Es sollte nicht jede Routineänderung unnötig verzögern.

Emergency Change Authority

Für Emergency Changes kann eine kleinere, schnell erreichbare Entscheidungsgruppe sinnvoll sein.

Mögliche Beteiligte:

Wichtig ist:

Standard Change richtig definieren

Ein Standard Change sollte nicht leichtfertig als Standard eingestuft werden.

Vorab zu klären:

Wenn ein Standard Change häufig fehlschlägt, muss er neu bewertet werden.

Emergency Change Missbrauch vermeiden

Emergency Changes sollten nicht genutzt werden, nur weil:

Ungeeignet:

Wir machen daraus einen Emergency Change, damit wir keine Freigabe brauchen.

Besser:

Es liegt kein akuter Schaden vor. Der Change wird als Normal Change mit beschleunigter Planung behandelt.

Risiko durch Nicht-Handeln

Nicht nur Durchführung kann riskant sein.

Auch Nicht-Handeln kann Risiko erzeugen.

Beispiele:

Eine gute Bewertung betrachtet deshalb:

Rollback und Backout in der Risikobewertung

Ein Change ist weniger riskant, wenn ein zuverlässiger Rollback möglich ist.

Zu prüfen ist:

Wenn kein Rollback möglich ist, muss besonders sorgfältig getestet und kommuniziert werden.

Testumfang nach Risiko

Der Testumfang sollte zur Risikostufe passen.

Risiko möglicher Testumfang
niedrig Standardprüfung, kurzer Funktionstest
mittel Testsystem, Review, definierter Smoke Test
hoch ausführlicher Testplan, Abhängigkeitstest, Rollback-Test
sehr hoch Pilot, Lasttest, Sicherheitsprüfung, Managementfreigabe

Tests sollten nicht nur prüfen, ob die Änderung technisch durchgeführt wurde.

Sie sollten prüfen, ob der Service danach wie erwartet nutzbar ist.

Kommunikationsbedarf nach Risiko

Je höher Risiko und Auswirkung, desto wichtiger wird Kommunikation.

Zu informieren sind je nach Change:

Inhalt der Kommunikation:

Wartungsfenster bewerten

Ein Wartungsfenster sollte passend gewählt werden.

Zu berücksichtigen sind:

Ein technisch bequemes Wartungsfenster ist nicht automatisch geschäftlich sinnvoll.

Abhängigkeiten und Change-Kollisionen

Mehrere Changes können sich gegenseitig beeinflussen.

Beispiele:

Change Enablement sollte prüfen:

Change Freeze

Ein Change Freeze ist ein Zeitraum, in dem Änderungen eingeschränkt werden.

Beispiele:

Ein Change Freeze verhindert nicht zwingend jede Änderung.

Emergency Changes oder wichtige Sicherheitsmaßnahmen können trotzdem notwendig sein.

Dann muss besonders bewusst entschieden werden.

Sicherheitsrisiken bewerten

Besonders sorgfältig zu bewerten sind Changes an:

Fragen:

Datenschutz und Compliance

Manche Changes betreffen Datenschutz oder Compliance.

Beispiele:

Dann können zusätzliche Prüfungen erforderlich sein.

Beispielsweise durch Datenschutz, Informationssicherheit, Compliance oder Rechtsabteilung.

Lieferantenrisiken

Bei Changes mit Lieferantenbezug zu prüfen:

Auch externe Changes müssen intern nachvollziehbar gesteuert werden.

Change-Erfolgskriterien

Vor der Umsetzung sollte klar sein, wann ein Change erfolgreich ist.

Beispiele:

Ohne Erfolgskriterien ist die Nachprüfung unklar.

Failed Change und Lessons Learned

Ein Change kann fehlschlagen.

Wichtig ist dann:

Ziel ist Lernen, nicht Schuldzuweisung.

Praxisbeispiel: Standard Change

Änderung

Standardsoftware aus genehmigtem Katalog wird installiert.

Bewertung

Umgang

Der Change kann als Standard Change über das Serviceportal ausgeführt werden.

Praxisbeispiel: Normal Change

Änderung

Eine produktive Fachanwendung erhält ein Versionsupdate.

Bewertung

Umgang

Der Change wird geplant, getestet, genehmigt und nach Umsetzung geprüft.

Praxisbeispiel: Emergency Change

Änderung

Eine aktiv ausgenutzte Sicherheitslücke muss kurzfristig geschlossen werden.

Bewertung

Umgang

Emergency Change wird kontrolliert durchgeführt, dokumentiert und nachträglich reviewed.

Praxisbeispiel: Falsch eingestufter Change

Situation

Eine Firewall-Regel wird als kleine Routineänderung behandelt.

Problem

Die Regel betrifft eine zentrale Schnittstelle zur Warenwirtschaft.

Nach Umsetzung kann der Versand keine Aufträge mehr übertragen.

Lerneffekt

Der Change war technisch klein, aber geschäftlich kritisch.

Künftig werden Firewall-Changes nach betroffenen Services und Geschäftsprozessen bewertet, nicht nur nach technischem Aufwand.

Typische Fehler

Fehler 1

Jede Änderung wird gleich behandelt.

Fehler 2

Ein riskanter Change wird fälschlich als Standard Change eingestuft.

Fehler 3

Emergency Change wird als Abkürzung genutzt.

Fehler 4

Nur technische Risiken werden bewertet.

Fehler 5

Risiko des Nicht-Handelns wird ignoriert.

Fehler 6

Rollback wird erst während der Störung überlegt.

Fehler 7

Tests passen nicht zum Risiko.

Fehler 8

Benutzer und Service Desk werden nicht informiert.

Fehler 9

Abhängigkeiten und parallele Changes werden nicht geprüft.

Fehler 10

Sicherheits- und Datenschutzrisiken werden zu spät erkannt.

Fehler 11

Change-Erfolgskriterien fehlen.

Fehler 12

Failed Changes werden nicht ausgewertet.

Checkliste Change-Typ bestimmen

Checkliste Risikobewertung

Checkliste Emergency Change

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker müssen Change-Typen und Risiken praktisch einschätzen können.

Im Arbeitsalltag bedeutet das:

Gerade kleine technische Änderungen können große Auswirkungen haben, wenn sie einen kritischen Service betreffen.

Zusammenfassung

Änderung erkennen
↓
Change-Typ bestimmen
↓
Auswirkung und Wahrscheinlichkeit bewerten
↓
Risiko des Changes und Risiko des Nicht-Handelns vergleichen
↓
Test, Rollback und Kommunikation planen
↓
passende Change Authority einbinden
↓
Änderung kontrolliert durchführen
↓
Erfolg prüfen
↓
Lessons Learned übernehmen

Merksätze

Nicht jede Änderung benötigt denselben Prozessaufwand.

Ein Standard Change ist vorab bewertet, nicht ungeprüft.

Ein Emergency Change ist kein Ersatz für schlechte Planung.

Technisch klein bedeutet nicht automatisch risikoarm.

Risiko entsteht aus Auswirkung, Wahrscheinlichkeit und Kontext.

Auch Nicht-Handeln kann riskant sein.

Der Change-Typ muss zur tatsächlichen Auswirkung passen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

angepasst werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026

5.3 Genehmigung, Planung und Umsetzung von Changes

Kurz erklärt

Ein Change sollte nicht nur technisch durchgeführt werden.

Vor der Umsetzung müssen Ziel, Risiko, Auswirkungen, Verantwortlichkeiten, Freigaben, Kommunikation, Tests und Rückfallmöglichkeiten geklärt sein.

Gute Change-Planung sorgt dafür, dass Änderungen kontrolliert, nachvollziehbar und mit möglichst geringem Risiko für laufende Services umgesetzt werden.

Warum Genehmigung und Planung wichtig sind

Viele Störungen entstehen nicht durch die Änderung selbst, sondern durch unklare Vorbereitung.

Typische Ursachen:

Change Enablement soll solche Risiken reduzieren.

Grundprinzip

Ein Change sollte nur dann umgesetzt werden, wenn mindestens klar ist:

Je höher Risiko und Auswirkung, desto gründlicher müssen Planung und Genehmigung sein.

Typischer Ablauf

Änderungsbedarf erkennen
        ↓
Change Request erstellen
        ↓
Risiko und Auswirkung bewerten
        ↓
Change-Typ bestimmen
        ↓
Genehmigung oder Vorabgenehmigung prüfen
        ↓
Umsetzung planen
        ↓
Kommunikation vorbereiten
        ↓
Change durchführen
        ↓
Ergebnis testen
        ↓
Dokumentation aktualisieren
        ↓
Change abschließen oder nachbereiten

Dieser Ablauf ist ein Praxisbeispiel.

Die konkrete Umsetzung hängt von Organisation, Risiko und Change-Modell ab.

Change Request erstellen

Ein Change Request beschreibt die gewünschte Änderung.

Typische Inhalte:

Ein Change Request sollte so formuliert sein, dass eine andere Person die Änderung bewerten kann.

Gute und schlechte Change-Beschreibung

Ungeeignet:

Update Server.

Besser:

Update des produktiven Webservers APP-WEB-01 von Version 2.4.57 auf 2.4.60, um bekannte Sicherheitslücken zu schließen. Betroffen ist der interne Service „Mitarbeiterportal“. Umsetzung im Wartungsfenster am 14.08.2026 von 20:00 bis 21:00 Uhr. Rollback durch Wiederherstellung der vorherigen Paketversion und Konfiguration möglich.

Eine gute Beschreibung macht Ziel, Umfang und Risiko sichtbar.

Genehmigung

Genehmigung bedeutet, dass eine berechtigte Person oder Gruppe der Umsetzung zustimmt.

Dabei wird geprüft:

Genehmigung ist keine reine Formalität.

Sie soll eine bewusste Entscheidung ermöglichen.

Change Authority

Die Change Authority ist die Person oder Gruppe, die eine Änderung bewertet oder genehmigt.

Mögliche Change Authorities:

Die passende Change Authority hängt ab von:

Nicht jeder Change benötigt dieselbe Genehmigungsstufe.

Genehmigung nach Risiko

Risiko mögliche Genehmigung
niedrig vorab genehmigter Standardprozess
mittel Team Lead oder Service Owner
hoch Change Manager, Service Owner oder CAB
sehr hoch Management, Informationssicherheit, CAB oder spezielle Change Authority
akut kritisch Emergency Change Authority

Diese Tabelle ist ein Beispiel.

Die Organisation muss ihre Genehmigungswege selbst festlegen.

Change Advisory Board

Ein Change Advisory Board kann bei umfangreichen oder risikoreichen Changes unterstützen.

Mögliche Aufgaben:

Ein CAB sollte nicht jede kleine Änderung ausbremsen.

Es ist besonders dann sinnvoll, wenn mehrere Perspektiven benötigt werden.

Emergency-Genehmigung

Bei Emergency Changes muss oft schneller entschieden werden.

Trotzdem sollten mindestens geklärt werden:

Auch ein Emergency Change braucht Kontrolle.

Nur der Genehmigungsweg ist beschleunigt.

Planung der Umsetzung

Ein Umsetzungsplan beschreibt, wie der Change praktisch durchgeführt wird.

Er sollte enthalten:

Je kritischer der Change, desto genauer sollte der Plan sein.

Schrittfolge definieren

Eine gute Schrittfolge vermeidet Unsicherheit während der Umsetzung.

Beispiel:

  1. aktuelles Backup prüfen
  2. Konfiguration exportieren
  3. Benutzerinformation bestätigen
  4. Dienst in Wartungsmodus setzen
  5. Update installieren
  6. Dienst starten
  7. Funktionstest durchführen
  8. Monitoring prüfen
  9. Fachbereichstest bestätigen
  10. Wartungsmodus beenden
  11. Abschlussmeldung senden
  12. Dokumentation aktualisieren

Wichtig ist, dass jeder Schritt ein klares Ergebnis besitzt.

Vorbereitung

Vor der Umsetzung sollte geprüft werden:

Eine gute Vorbereitung verhindert Hektik während des Change-Fensters.

Wartungsfenster

Ein Wartungsfenster ist ein geplanter Zeitraum für Änderungen.

Zu berücksichtigen sind:

Ein Wartungsfenster sollte nicht nur technisch bequem sein.

Es muss zur Nutzung des Services passen.

Kommunikation vor dem Change

Betroffene Personen sollten rechtzeitig informiert werden.

Je nach Change können beteiligt sein:

Eine Vorabinformation kann enthalten:

Beispiel einer Benutzerinformation

Am 14.08.2026 zwischen 20:00 und 21:00 Uhr wird das Mitarbeiterportal aktualisiert. In diesem Zeitraum kann der Zugriff kurzzeitig unterbrochen sein. Bitte speichern Sie offene Eingaben vorher. Nach Abschluss informieren wir über die erfolgreiche Umsetzung.

Die Kommunikation sollte verständlich und nicht unnötig technisch sein.

Service Desk informieren

Der Service Desk muss vor wichtigen Changes wissen:

Sonst entstehen unnötige Incidents und Rückfragen.

Tests planen

Ein Testplan beschreibt, wie geprüft wird, ob der Change erfolgreich war.

Mögliche Tests:

Der Test muss zum Risiko des Changes passen.

Bei kritischen Services reicht ein oberflächlicher Test oft nicht aus.

Smoke Test

Ein Smoke Test ist eine kurze Grundprüfung nach der Umsetzung.

Beispiele:

Ein Smoke Test ersetzt keine vollständige Abnahme.

Er hilft aber, grobe Fehler sofort zu erkennen.

Rollback und Backout planen

Rollback oder Backout bedeutet, den Change zurückzunehmen oder in einen sicheren Zustand zu bringen.

Zu klären ist:

Ein Rollback muss vor der Umsetzung geplant werden, nicht erst während der Störung.

Rollback ist nicht immer möglich

Manche Changes lassen sich nicht einfach zurückrollen.

Beispiele:

Wenn kein einfacher Rollback möglich ist, müssen Risiko, Testtiefe und Kommunikationsplanung besonders sorgfältig sein.

Abbruchkriterien

Abbruchkriterien legen fest, wann ein Change gestoppt oder zurückgerollt wird.

Beispiele:

Abbruchkriterien verhindern, dass ein Change trotz deutlicher Warnzeichen weitergeführt wird.

Durchführung

Während der Durchführung sollte konzentriert und nachvollziehbar gearbeitet werden.

Wichtig:

Ungeeignet:

Während des Updates ändern wir zusätzlich noch ein paar andere Einstellungen.

Besser:

Nur der freigegebene Change wird umgesetzt. Zusätzliche Auffälligkeiten werden dokumentiert und separat bewertet.

Umgang mit Abweichungen

Während eines Changes können unerwartete Situationen auftreten.

Dann sollte geklärt werden:

Nicht jede Abweichung darf spontan gelöst werden.

Sonst entsteht ein ungeplanter Change im Change.

Monitoring während des Changes

Monitoring sollte aktiv beobachtet werden.

Zu prüfen sind:

Monitoring zeigt nicht alles.

Es ergänzt technische und fachliche Tests.

Kommunikation während des Changes

Bei längeren oder kritischen Changes sollten Zwischenstände kommuniziert werden.

Beispiele:

Kommunikation verhindert Unsicherheit.

Sie muss aber sachlich und abgestimmt bleiben.

Erfolg prüfen

Nach der Umsetzung sollte geprüft werden:

Ein Change ist nicht automatisch erfolgreich, nur weil die technische Tätigkeit abgeschlossen ist.

Fachliche Abnahme

Bei wichtigen Services kann eine fachliche Abnahme erforderlich sein.

Beispiele:

Technische Erreichbarkeit allein genügt nicht immer.

Wichtig ist, ob der Service aus Sicht der Benutzer funktioniert.

Abschlussmeldung

Nach erfolgreicher Umsetzung sollte eine Abschlussmeldung erfolgen.

Sie kann enthalten:

Beispiel:

Das Update des Mitarbeiterportals wurde erfolgreich abgeschlossen. Der Service ist wieder verfügbar. Bitte melden Sie Auffälligkeiten über das Serviceportal unter Angabe des Services „Mitarbeiterportal“.

Dokumentation aktualisieren

Nach dem Change müssen relevante Informationen aktualisiert werden.

Mögliche Inhalte:

Ein Change ist unvollständig, wenn die technische Umgebung geändert wurde, die Dokumentation aber den alten Zustand zeigt.

CMDB aktualisieren

Wenn Configuration Items betroffen sind, sollte die CMDB aktualisiert werden.

Beispiele:

Fehlende CMDB-Aktualisierung kann spätere Incidents, Problems und Changes erschweren.

Knowledge Base aktualisieren

Nach einem Change können Knowledge-Artikel falsch oder veraltet sein.

Zu prüfen ist:

Wissen muss zum aktuellen Servicezustand passen.

Problem Record aktualisieren

Wenn ein Change eine dauerhafte Lösung für ein Problem war, muss der Problem Record aktualisiert werden.

Zu prüfen ist:

Ein Problem sollte nicht automatisch geschlossen werden, nur weil ein Change umgesetzt wurde.

Failed Change

Ein Change gilt als fehlgeschlagen, wenn:

Ein Failed Change sollte nachvollziehbar ausgewertet werden.

Ziel ist Verbesserung, nicht Schuldzuweisung.

Post Implementation Review

Ein Post Implementation Review prüft nach der Umsetzung, wie der Change verlaufen ist.

Mögliche Fragen:

Nicht jeder kleine Standard Change benötigt ein ausführliches Review.

Bei risikoreichen oder fehlgeschlagenen Changes ist es besonders wichtig.

Praxisbeispiel: Anwendungsupdate

Change

Produktive Fachanwendung wird aktualisiert.

Planung

Umsetzung

Update wird im Wartungsfenster durchgeführt.

Prüfung

Abschluss

Dokumentation und Knowledge-Artikel werden aktualisiert.

Praxisbeispiel: Firewall-Regel

Change

Neue Verbindung zwischen Anwendung und Partner-API wird freigeschaltet.

Planung

Umsetzung

Firewall-Regel wird im genehmigten Zeitfenster gesetzt.

Prüfung

Schnittstelle überträgt Testdaten korrekt.

Logs zeigen keine unerwarteten Verbindungen.

Praxisbeispiel: Rollback notwendig

Change

Datenbanktreiber einer Anwendung wird aktualisiert.

Problem

Nach dem Update schlägt der Export von Berichten fehl.

Entscheidung

Abbruchkriterium ist erfüllt.

Rollback wird eingeleitet.

Nachbereitung

Typische Fehler

Fehler 1

Change wird ohne klaren Plan umgesetzt.

Fehler 2

Genehmigung wird als reine Formalität behandelt.

Fehler 3

Service Desk wird nicht informiert.

Fehler 4

Benutzer erfahren erst durch eine Störung vom Change.

Fehler 5

Rollback ist nicht vorbereitet.

Fehler 6

Tests prüfen nur Technik, nicht Benutzer-Outcome.

Fehler 7

Abweichungen werden spontan und undokumentiert behoben.

Fehler 8

Mehrere zusätzliche Änderungen werden nebenbei durchgeführt.

Fehler 9

Change wird abgeschlossen, obwohl Erfolgskriterien nicht geprüft wurden.

Fehler 10

Dokumentation, CMDB und Knowledge Base bleiben veraltet.

Fehler 11

Problem Record wird nach dauerhafter Lösung nicht aktualisiert.

Fehler 12

Failed Change wird nicht ausgewertet.

Checkliste Genehmigung

Checkliste Planung

Checkliste Umsetzung

Checkliste Abschluss

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker setzen Changes häufig technisch um.

Dabei reicht es nicht, nur den Befehl oder die Konfiguration zu kennen.

Wichtig ist auch:

Gute Change-Umsetzung verbindet technisches Können mit sauberer Planung.

Zusammenfassung

Change Request prüfen
↓
Genehmigung und Change Authority klären
↓
Umsetzungsschritte planen
↓
Tests, Kommunikation und Rollback vorbereiten
↓
Change im vorgesehenen Zeitfenster durchführen
↓
Ergebnis technisch und fachlich prüfen
↓
Abschluss kommunizieren
↓
Dokumentation, CMDB und Knowledge aktualisieren
↓
Failed Changes oder Abweichungen auswerten

Merksätze

Ein Change ist mehr als die technische Änderung.

Genehmigung bedeutet bewusste Risikoentscheidung.

Gute Planung reduziert Incidents nach Changes.

Rollback wird vor der Umsetzung geplant, nicht während der Störung.

Der Service Desk muss wichtige Changes kennen.

Ein Change ist erst abgeschlossen, wenn Ergebnis und Dokumentation geprüft sind.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

angepasst werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026

5.4 Release Management und Deployment Management

Kurz erklärt

Release Management und Deployment Management sorgen dafür, dass neue oder geänderte Services, Anwendungen, Funktionen oder Infrastrukturkomponenten kontrolliert bereitgestellt werden.

Release Management betrachtet vor allem, wann und in welcher Form eine Änderung für Benutzer oder Kunden verfügbar gemacht wird.

Deployment Management betrachtet vor allem, wie technische Komponenten in eine Zielumgebung gebracht werden.

Beide Bereiche hängen eng mit Change Enablement zusammen.

Warum Release und Deployment wichtig sind

Viele Änderungen werden nicht einzeln sichtbar.

Oft werden mehrere technische Änderungen gemeinsam bereitgestellt.

Beispiele:

Wenn solche Änderungen unkoordiniert ausgerollt werden, können entstehen:

Release und Deployment sorgen für geordnete Bereitstellung.

Release und Deployment unterscheiden

Begriff Bedeutung
Release Bündel neuer oder geänderter Funktionen, Services oder Komponenten, das bereitgestellt und für Nutzung freigegeben wird
Deployment technische Überführung von Komponenten in eine Zielumgebung
Change kontrollierte Änderung an einem Service oder unterstützenden Bestandteil
Rollout Verteilung oder Einführung eines Releases bei Benutzern, Standorten oder Systemen
Rollback Rücknahme einer Änderung auf einen vorherigen Zustand
Backout geplanter Ausstieg aus einer Änderung, wenn Abbruchkriterien erfüllt sind

Ein Deployment kann technisch erfolgreich sein, obwohl das Release aus Benutzersicht noch nicht erfolgreich ist.

Beispiel:

Die neue Version wurde auf dem Server installiert.

Benutzer können aber eine wichtige Funktion nicht nutzen.

Technisch wurde deployed.

Das Release ist fachlich noch nicht erfolgreich.

Release Management

Release Management plant, koordiniert und steuert die Bereitstellung neuer oder geänderter Services und Funktionen.

Typische Fragen:

Release Management verbindet technische Bereitstellung mit Benutzer- und Serviceperspektive.

Deployment Management

Deployment Management sorgt dafür, dass technische Komponenten kontrolliert in eine Zielumgebung gebracht werden.

Typische Fragen:

Deployment Management besitzt damit einen stärker technischen Fokus.

Release, Deployment und Change Enablement im Zusammenspiel

Ein möglicher Zusammenhang:

Änderungsbedarf entsteht
        ↓
Change Request wird erstellt
        ↓
Risiko und Auswirkung werden bewertet
        ↓
Release wird geplant
        ↓
Deployment wird vorbereitet
        ↓
Change wird genehmigt
        ↓
Deployment wird durchgeführt
        ↓
Release wird für Benutzer verfügbar
        ↓
Erfolg wird geprüft
        ↓
Dokumentation und Knowledge werden aktualisiert

Nicht jede Organisation trennt diese Schritte gleich stark.

Wichtig ist, dass technische Umsetzung, Freigabe und Kommunikation zusammenpassen.

Beispiel: Anwendungsversion

Eine Fachanwendung erhält eine neue Version.

Change Enablement

Release Management

Deployment Management

Alle drei Bereiche müssen zusammenarbeiten.

Release-Paket

Ein Release-Paket kann alle Bestandteile enthalten, die für eine Bereitstellung notwendig sind.

Mögliche Inhalte:

Nicht jedes Release-Paket ist gleich umfangreich.

Der Umfang muss zum Risiko und zur Bedeutung des Releases passen.

Release-Plan

Ein Release-Plan beschreibt, wann und wie ein Release bereitgestellt wird.

Typische Inhalte:

Ein Release-Plan muss nicht kompliziert sein.

Er muss aber ausreichend klar sein, damit alle Beteiligten wissen, was passiert.

Release Notes

Release Notes beschreiben, was sich mit einem Release ändert.

Sie können enthalten:

Release Notes sollten zielgruppengerecht sein.

Technische Teams benötigen andere Informationen als Endbenutzer.

Benutzerorientierte Release Notes

Ungeeignet:

Backend-Komponente API-GW-PRD wurde auf Build 2026.08.14-rc3 aktualisiert.

Besser:

Die Suche im Mitarbeiterportal wurde verbessert. Ergebnisse werden nun schneller angezeigt. Während des Updates kann das Portal am 14.08.2026 zwischen 20:00 und 20:30 Uhr kurzzeitig nicht verfügbar sein.

Benutzer müssen verstehen:

Deployment-Plan

Ein Deployment-Plan beschreibt die technische Umsetzung.

Mögliche Inhalte:

Bei einfachen Deployments kann der Plan kurz sein.

Bei kritischen Deployments muss er detaillierter sein.

Umgebungen

Viele Organisationen nutzen mehrere Umgebungen.

Beispiele:

Ziel ist, Änderungen vor der Produktion zu prüfen.

Typische Fragen:

Ein Test in einer völlig abweichenden Umgebung gibt nur begrenzte Sicherheit.

Test und Abnahme

Vor einem Release sollten geeignete Tests durchgeführt werden.

Mögliche Tests:

Der Testumfang hängt vom Risiko ab.

Ein kritisches Release benötigt mehr Prüfung als eine kleine, risikoarme Änderung.

Regressionstest

Ein Regressionstest prüft, ob bestehende Funktionen nach einer Änderung weiterhin funktionieren.

Beispiel:

Eine neue Exportfunktion wird eingebaut.

Der Regressionstest prüft zusätzlich:

Dadurch wird verhindert, dass eine neue Funktion alte Funktionen unbeabsichtigt beschädigt.

Smoke Test nach Deployment

Ein Smoke Test ist eine kurze Grundprüfung direkt nach dem Deployment.

Beispiele:

Ein Smoke Test ersetzt keine vollständige Abnahme.

Er hilft aber, grobe Fehler sofort zu erkennen.

Deployment-Methoden

Organisationen können verschiedene Deployment-Methoden nutzen.

Beispiele:

Methode Kurzbeschreibung
Big Bang Bereitstellung für alle Benutzer gleichzeitig
phasenweise Bereitstellung Einführung in mehreren Gruppen oder Standorten
Pilot begrenzte Einführung bei kleiner Benutzergruppe
Rolling Deployment schrittweise Aktualisierung einzelner Systeme
Blue-Green Deployment Wechsel zwischen zwei vorbereiteten Umgebungen
Canary Deployment neue Version zunächst für kleinen Teil der Benutzer
Feature Toggle Funktion wird technisch bereitgestellt, aber gezielt aktiviert oder deaktiviert

Diese Methoden sind Praxisbeispiele.

ITIL schreibt keine bestimmte technische Deployment-Methode für alle Organisationen vor.

Big-Bang-Deployment

Beim Big-Bang-Deployment wird eine Änderung für alle betroffenen Benutzer oder Systeme gleichzeitig bereitgestellt.

Vorteile:

Risiken:

Geeignet eher dann, wenn:

Phasenweise Bereitstellung

Bei einer phasenweisen Bereitstellung erfolgt der Rollout schrittweise.

Beispiele:

Vorteile:

Risiken:

Pilot

Ein Pilot testet ein Release mit einer begrenzten Benutzergruppe.

Geeignet für:

Ein Pilot sollte klare Kriterien besitzen:

Ein Pilot ohne Auswertung bringt wenig Nutzen.

Blue-Green Deployment

Beim Blue-Green Deployment existieren zwei Umgebungen.

Beispiel:

Nach Tests wird der Verkehr auf die neue Umgebung umgeschaltet.

Vorteile:

Risiken:

Canary Deployment

Beim Canary Deployment erhält zuerst nur ein kleiner Teil der Benutzer die neue Version.

Wenn keine Probleme auftreten, wird der Anteil erhöht.

Vorteile:

Risiken:

Feature Toggles

Feature Toggles ermöglichen, Funktionen unabhängig vom technischen Deployment zu aktivieren oder zu deaktivieren.

Beispiel:

Die neue Funktion ist bereits deployed, aber nur für eine Pilotgruppe aktiviert.

Vorteile:

Risiken:

Feature Toggles benötigen klare Verwaltung und Dokumentation.

Deployment-Automatisierung

Deployments werden häufig automatisiert.

Beispiele:

Vorteile:

Risiken:

Manuelles Deployment

Manuelle Deployments können notwendig sein, wenn:

Risiken manueller Deployments:

Runbooks und Checklisten reduzieren diese Risiken.

Release-Kalender

Ein Release-Kalender zeigt geplante Releases und wichtige Change-Zeitpunkte.

Er hilft bei:

Ein Release-Kalender sollte für relevante Teams sichtbar sein.

Change Freeze und Release Freeze

Ein Freeze ist ein Zeitraum, in dem Releases oder Changes eingeschränkt werden.

Beispiele:

Ein Freeze bedeutet nicht zwingend, dass gar nichts geändert werden darf.

Sicherheitsupdates oder Emergency Changes können trotzdem notwendig sein.

Dann muss besonders bewusst entschieden und dokumentiert werden.

Kommunikation vor einem Release

Vor einem Release sollten betroffene Gruppen informiert werden.

Mögliche Inhalte:

Der Service Desk muss besonders gut vorbereitet sein.

Service Desk vorbereiten

Der Service Desk benötigt vor einem Release:

Ohne Vorbereitung steigen nach einem Release unnötige Tickets und Rückfragen.

Monitoring während und nach Deployment

Während und nach einem Deployment sollte Monitoring aktiv beobachtet werden.

Zu prüfen sind:

Nach kritischen Releases kann eine verstärkte Beobachtungsphase sinnvoll sein.

Rollback und Roll Forward

Bei Problemen nach einem Deployment gibt es zwei grundsätzliche Richtungen.

Ansatz Bedeutung
Rollback Rückkehr zum vorherigen Zustand
Roll Forward Vorwärtskorrektur durch neue Änderung oder Hotfix

Rollback ist nicht immer möglich.

Roll Forward kann sinnvoll sein, wenn:

Beide Wege benötigen Entscheidung, Dokumentation und Risikobewertung.

Release-Erfolg prüfen

Nach einem Release sollte geprüft werden:

Ein Release ist nicht erfolgreich, nur weil Dateien deployed wurden.

Es muss aus Service- und Benutzersicht funktionieren.

Post-Deployment Review

Ein Post-Deployment Review kann nach wichtigen Deployments sinnvoll sein.

Fragen:

Nicht jedes kleine Deployment benötigt ein ausführliches Review.

Bei kritischen oder fehlgeschlagenen Deployments ist es wichtig.

Release Management und Knowledge Management

Nach einem Release müssen Wissensbestände aktualisiert werden.

Mögliche Inhalte:

Veraltete Knowledge-Artikel erzeugen nach Releases häufig neue Tickets.

Release Management und Configuration Management

Nach Releases und Deployments müssen Configuration Items aktuell bleiben.

Mögliche Änderungen:

Wenn die CMDB veraltet bleibt, werden spätere Incidents, Problems und Changes schwieriger.

Release Management und Incident Management

Nach Releases können Incidents entstehen.

Deshalb sollte Incident Management vorbereitet sein.

Wichtig:

Ein Anstieg von Incidents nach einem Release kann auf Probleme in Test, Kommunikation oder Deployment hinweisen.

Release Management und Problem Management

Wenn nach einem Release wiederkehrende oder schwere Incidents entstehen, kann ein Problem Record notwendig sein.

Problem Management prüft dann:

Release Management und Change Enablement

Change Enablement sorgt dafür, dass Releases und Deployments kontrolliert umgesetzt werden.

Zu klären ist:

Release und Deployment sollten nicht an Change Enablement vorbei erfolgen.

Praxisbeispiel: VPN-Client-Rollout

Ausgangslage

Eine alte VPN-Client-Version verursacht wiederkehrende Incidents.

Release

Neue VPN-Client-Version wird bereitgestellt.

Deployment

Erfolgskontrolle

VPN-Incidents gehen zurück.

Known Error wird aktualisiert.

Knowledge-Artikel wird angepasst.

Praxisbeispiel: Mitarbeiterportal

Ausgangslage

Das Mitarbeiterportal erhält neue Funktionen.

Release Management

Deployment Management

Nachbereitung

Incidents nach Release beobachten und Knowledge-Artikel aktualisieren.

Praxisbeispiel: Fehlgeschlagenes Deployment

Situation

Eine neue Anwendungsversion wird erfolgreich installiert.

Problem

Nach dem Deployment funktioniert der PDF-Export nicht mehr.

Maßnahmen

Lerneffekt

Der Testplan muss künftig auch Exportfunktionen abdecken.

Typische Fehler

Fehler 1

Release und Deployment werden gleichgesetzt.

Fehler 2

Technisches Deployment gelingt, aber Benutzer sind nicht vorbereitet.

Fehler 3

Service Desk erhält keine Release-Informationen.

Fehler 4

Release Notes fehlen oder sind zu technisch.

Fehler 5

Tests decken wichtige Geschäftsprozesse nicht ab.

Fehler 6

Rollback wird nicht realistisch geplant.

Fehler 7

Mehrere Releases kollidieren zeitlich.

Fehler 8

Monitoring wird nach Deployment nicht beobachtet.

Fehler 9

Known Errors und Workarounds werden nicht dokumentiert.

Fehler 10

CMDB und Knowledge Base bleiben nach Release veraltet.

Fehler 11

Fehlgeschlagene Deployments werden nicht ausgewertet.

Fehler 12

Automatisierung wird genutzt, aber nicht überwacht.

Checkliste Release Management

Checkliste Deployment Management

Checkliste Kommunikation

Checkliste Nachbereitung

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker sind häufig direkt an Deployments beteiligt.

Im Alltag bedeutet das:

Gute technische Bereitstellung bedeutet nicht nur:

Installation erfolgreich.

Sondern:

Service funktioniert, Benutzer sind arbeitsfähig, Support ist vorbereitet und Dokumentation stimmt.

Zusammenfassung

Release-Inhalt festlegen
↓
Changes, Risiken und Abhängigkeiten prüfen
↓
Deployment vorbereiten
↓
Service Desk und Benutzer informieren
↓
technische Bereitstellung durchführen
↓
Smoke Test und Monitoring prüfen
↓
Release aus Benutzersicht bewerten
↓
Incidents und Feedback beobachten
↓
Knowledge, CMDB und Runbooks aktualisieren
↓
Lessons Learned übernehmen

Merksätze

Release Management betrachtet die Bereitstellung aus Service- und Benutzersicht.

Deployment Management betrachtet die technische Überführung in eine Zielumgebung.

Ein erfolgreiches Deployment ist nicht automatisch ein erfolgreiches Release.

Service Desk und Benutzer müssen auf wichtige Releases vorbereitet sein.

Rollback und Kommunikation gehören vor dem Deployment geplant.

Nach einem Release müssen Knowledge, CMDB und Monitoring geprüft werden.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

angepasst werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026

5.5 Change-Erfolg messen und Continual Improvement

Kurz erklärt

Ein Change ist nicht automatisch erfolgreich, nur weil er technisch durchgeführt wurde.

Erfolgreich ist ein Change erst dann, wenn der gewünschte Nutzen erreicht wurde, der Service stabil bleibt, Benutzer arbeitsfähig sind und keine unvertretbaren Nebenwirkungen entstehen.

Deshalb müssen Changes nach der Umsetzung bewertet, dokumentiert und für zukünftige Verbesserungen genutzt werden.

Warum Change-Erfolg gemessen werden muss

Ohne Erfolgsmessung bleibt unklar, ob ein Change wirklich sinnvoll war.

Mögliche Fragen:

Change-Erfolg bedeutet mehr als:

Umsetzung abgeschlossen.

Entscheidend ist das Ergebnis aus Service-, Benutzer- und Betriebssicht.

Technische Umsetzung und Service-Erfolg unterscheiden

Technische Umsetzung Service-Erfolg
Paket wurde installiert Benutzer können wieder arbeiten
Konfiguration wurde geändert Service funktioniert stabil
Server wurde aktualisiert abhängige Systeme funktionieren weiterhin
Firewall-Regel wurde gesetzt Schnittstelle funktioniert sicher und erwartungsgemäß
Zertifikat wurde erneuert Anmeldung funktioniert ohne neue Störungen
Deployment ist abgeschlossen Release erzeugt den gewünschten Nutzen

Ein Change kann technisch erfolgreich sein und trotzdem aus Service-Sicht Probleme verursachen.

Beispiel:

Eine neue Anwendungsversion wurde korrekt installiert.

Nach dem Update funktioniert jedoch der Export für die Buchhaltung nicht mehr.

Technisch war das Deployment erfolgreich.

Aus Sicht des Services ist der Change nur teilweise erfolgreich oder fehlgeschlagen.

Erfolgskriterien vorab festlegen

Erfolg sollte vor der Umsetzung definiert werden.

Gute Erfolgskriterien sind:

Beispiele:

Change mögliches Erfolgskriterium
VPN-Client aktualisieren VPN-Incidents sinken innerhalb von vier Wochen deutlich
Zertifikat erneuern Anmeldung funktioniert und Monitoring erkennt zukünftige Abläufe
Firewall-Regel setzen gewünschte Verbindung funktioniert, keine unerwarteten Freigaben
Anwendung aktualisieren Kernfunktionen funktionieren nach Smoke Test und Fachbereichstest
Monitoring erweitern relevante Warnung wird korrekt ausgelöst und an richtiges Team gesendet
Druckertreiber aktualisieren Etikettendruck funktioniert und Incidents treten nicht erneut auf

Ohne Erfolgskriterien wird die Nachprüfung ungenau.

Mögliche Kennzahlen für Change-Erfolg

Bereich mögliche Kennzahl
Umsetzung Anteil erfolgreich abgeschlossener Changes
Qualität Anzahl fehlgeschlagener Changes
Stabilität Incidents nach Changes
Risiko Anzahl Emergency Changes
Planung Anteil Changes mit Rollback-Plan
Kommunikation Beschwerden oder Rückfragen nach Change
Geschwindigkeit Durchlaufzeit von Change Request bis Umsetzung
Wirkung Rückgang wiederkehrender Incidents
Wissen aktualisierte Knowledge-Artikel nach Change
Verbesserung Lessons Learned umgesetzt

Nicht jede Organisation benötigt alle Kennzahlen.

Wichtig ist, dass die Kennzahlen Entscheidungen und Verbesserungen unterstützen.

Change Success Rate

Die Change Success Rate beschreibt den Anteil der Changes, die erfolgreich umgesetzt wurden.

Vorsicht:

Eine hohe Erfolgsquote ist nur sinnvoll, wenn klar definiert ist, was „erfolgreich“ bedeutet.

Ungeeignet:

Change wurde durchgeführt, also erfolgreich.

Besser:

Change wurde wie geplant durchgeführt, Erfolgskriterien wurden erreicht, keine relevanten Incidents entstanden, Dokumentation wurde aktualisiert.

Eine zu einfache Erfolgsdefinition verfälscht die Kennzahl.

Failed Changes

Ein Failed Change ist eine Änderung, die nicht wie geplant erfolgreich war oder unerwünschte Auswirkungen verursacht hat.

Mögliche Beispiele:

Failed Changes sind wichtige Lernquellen.

Sie sollten nicht versteckt oder beschönigt werden.

Incidents nach Changes

Eine wichtige Kennzahl ist die Anzahl der Incidents, die nach Changes entstehen.

Zu prüfen ist:

Nicht jeder Incident nach einem Change wurde durch den Change verursacht.

Der zeitliche Zusammenhang ist ein Hinweis, aber kein Beweis.

Emergency-Change-Quote

Eine hohe Anzahl von Emergency Changes kann auf Probleme hinweisen.

Mögliche Ursachen:

Emergency Changes sind manchmal notwendig.

Wenn sie aber zur Regel werden, sollte das Change-Modell überprüft werden.

Rollback-Quote

Die Rollback-Quote zeigt, wie oft Changes zurückgenommen werden mussten.

Eine hohe Quote kann hinweisen auf:

Eine niedrige Rollback-Quote ist nicht automatisch gut.

Sie kann auch bedeuten, dass bei Problemen kein funktionierender Rollback vorhanden war.

Durchlaufzeit von Changes

Die Durchlaufzeit beschreibt, wie lange ein Change von der Anforderung bis zur Umsetzung benötigt.

Zu betrachten sind:

Lange Durchlaufzeiten können auf Engpässe hinweisen.

Beispiele:

Qualität der Change Requests

Die Qualität eines Change Requests beeinflusst die gesamte Bearbeitung.

Zu prüfen ist:

Unvollständige Change Requests führen zu Rückfragen, Verzögerungen und höheren Risiken.

Change-Kalender auswerten

Ein Change-Kalender zeigt nicht nur geplante Änderungen.

Er kann auch zur Verbesserung genutzt werden.

Zu prüfen ist:

Ein gut gepflegter Change-Kalender reduziert Konflikte und Überraschungen.

Post Implementation Review

Ein Post Implementation Review prüft nach der Umsetzung, ob der Change erfolgreich war.

Mögliche Fragen:

Nicht jeder kleine Standard Change benötigt ein ausführliches Review.

Bei risikoreichen, fehlgeschlagenen oder besonders wichtigen Changes ist es sehr sinnvoll.

Review nach Emergency Changes

Emergency Changes sollten besonders sorgfältig nachbereitet werden.

Zu prüfen ist:

Ziel ist nicht, die schnelle Entscheidung nachträglich zu bestrafen.

Ziel ist, zukünftige Notfälle zu vermeiden.

Review nach Failed Changes

Ein Failed Change sollte analysiert werden.

Mögliche Fragen:

Failed Changes sind wichtige Daten für Continual Improvement.

Lessons Learned

Lessons Learned sind Erkenntnisse aus erfolgreichen und fehlgeschlagenen Changes.

Mögliche Ergebnisse:

Lessons Learned sind nur wertvoll, wenn daraus konkrete Maßnahmen entstehen.

Continual Improvement im Change Enablement

Change Enablement sollte selbst kontinuierlich verbessert werden.

Möglicher Ablauf:

Change-Daten sammeln
        ↓
Trends und Schwachstellen erkennen
        ↓
Verbesserungsidee erfassen
        ↓
Nutzen und Aufwand bewerten
        ↓
Maßnahme umsetzen
        ↓
Wirkung messen
        ↓
Change-Modell anpassen

Verbesserung kann sich auf Prozesse, Werkzeuge, Kommunikation, Vorlagen, Automatisierung oder Rollen beziehen.

Improvement Register

Verbesserungsideen aus Change Reviews sollten nicht verloren gehen.

Ein Improvement Register kann enthalten:

Beispiele:

Standard Changes regelmäßig überprüfen

Standard Changes sind vorab genehmigt.

Trotzdem müssen sie regelmäßig geprüft werden.

Fragen:

Ein Standard Change darf nicht dauerhaft ungeprüft bleiben.

Change-Modell anpassen

Ein Change-Modell beschreibt, wie bestimmte Change-Arten bearbeitet werden.

Es sollte angepasst werden, wenn:

Ein gutes Change-Modell ist stabil, aber nicht starr.

Automatisierung im Change Enablement

Automatisierung kann Change Enablement verbessern.

Beispiele:

Automatisierung muss aber kontrolliert werden.

Ein falsch automatisierter Change-Prozess kann Fehler schneller verbreiten.

Change-Datenqualität verbessern

Gute Auswertung benötigt gute Daten.

Probleme entstehen durch:

Eine wichtige Verbesserung kann darin bestehen, die Pflichtinformationen im Change-Prozess zu verbessern.

Zusammenhang mit Problem Management

Problem Management ist besonders wichtig für Change-Erfolg.

Ein Change kann:

Nach einem Change zur Problemlösung sollte geprüft werden:

Zusammenhang mit Knowledge Management

Nach Changes muss Wissen aktuell bleiben.

Zu prüfen ist:

Ein Change kann technisch erfolgreich sein und trotzdem Supportprobleme verursachen, wenn Knowledge veraltet bleibt.

Zusammenhang mit Service Configuration Management

Nach Changes müssen Configuration Items und Beziehungen aktuell bleiben.

Zu prüfen ist:

Eine veraltete CMDB erschwert zukünftige Incidents, Problems und Changes.

Zusammenhang mit Measurement and Reporting

Measurement and Reporting unterstützt Change Enablement durch:

Wichtig ist, nicht nur Zahlen zu zeigen.

Berichte sollten erklären:

Beispiel: Failed Change

Situation

Ein Anwendungspatch wurde eingespielt.

Problem

Nach dem Patch funktioniert der PDF-Export nicht mehr.

Analyse

Verbesserungen

Beispiel: Zu viele Emergency Changes

Beobachtung

Emergency Changes nehmen über mehrere Monate zu.

Analyse

Viele Emergency Changes betreffen ablaufende Zertifikate und Speicherplatzprobleme.

Ursachen

Verbesserungen

Beispiel: Standard Change verbessern

Situation

Standardsoftware wird über ein Portal bereitgestellt.

Problem

Viele Requests schlagen fehl, weil Geräte nicht erreichbar sind.

Analyse

Verbesserungen

Typische Fehler

Fehler 1

Change gilt als erfolgreich, nur weil er technisch durchgeführt wurde.

Fehler 2

Erfolgskriterien werden nicht vorab definiert.

Fehler 3

Incidents nach Changes werden nicht ausgewertet.

Fehler 4

Failed Changes werden beschönigt oder nicht dokumentiert.

Fehler 5

Emergency Changes werden nicht nachbereitet.

Fehler 6

Lessons Learned werden gesammelt, aber nicht umgesetzt.

Fehler 7

Standard Changes werden nie überprüft.

Fehler 8

Kennzahlen erzeugen falsche Anreize.

Fehler 9

Change-Datenqualität ist schlecht.

Fehler 10

Knowledge Base und CMDB werden nach Changes nicht aktualisiert.

Fehler 11

Review-Fragen konzentrieren sich nur auf Technik, nicht auf Servicewirkung.

Fehler 12

Verbesserungen bleiben ohne Verantwortlichen und Termin.

Problematische Kennzahlen

Kennzahl möglicher Fehlanreiz
möglichst viele Changes unnötige oder schlecht geplante Änderungen
sehr kurze Durchlaufzeit unzureichende Prüfung
hohe Erfolgsquote Fehler werden nicht ehrlich dokumentiert
wenige Emergency Changes dringende Fälle werden falsch klassifiziert
wenige Failed Changes Teams melden Fehlschläge nicht transparent
niedrige Rollback-Quote Rollback fehlt oder wird vermieden

Kennzahlen müssen deshalb immer mit Kontext betrachtet werden.

Gute Kennzahlenkombinationen

Sinnvoll ist eine kombinierte Betrachtung.

Beispiele:

Einzelne Kennzahlen können täuschen.

Kombinationen zeigen bessere Zusammenhänge.

Checkliste Change-Erfolg prüfen

Checkliste Post Implementation Review

Checkliste Failed Change

Checkliste Continual Improvement im Change Enablement

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker tragen wesentlich dazu bei, ob Change-Erfolg messbar und nachvollziehbar ist.

Im Arbeitsalltag bedeutet das:

Gute technische Arbeit endet nicht beim erfolgreichen Befehl.

Sie endet erst, wenn der Service stabil funktioniert und die Änderung nachvollziehbar abgeschlossen ist.

Zusammenfassung

Change-Ziel und Erfolgskriterien festlegen
↓
Change durchführen
↓
technisches Ergebnis prüfen
↓
Benutzer-Outcome und Servicewirkung prüfen
↓
Incidents, Monitoring und Feedback auswerten
↓
Failed Changes und Emergency Changes reviewen
↓
Knowledge, CMDB und Dokumentation aktualisieren
↓
Lessons Learned erfassen
↓
Verbesserungen verfolgen
↓
Change-Modell kontinuierlich verbessern

Merksätze

Ein Change ist nicht erfolgreich, nur weil er durchgeführt wurde.

Erfolg muss aus Service- und Benutzersicht geprüft werden.

Failed Changes sind Lernquellen.

Emergency Changes benötigen Nachbereitung.

Kennzahlen ohne Kontext erzeugen falsche Schlüsse.

Lessons Learned sind nur wertvoll, wenn sie umgesetzt werden.

Change Enablement selbst muss kontinuierlich verbessert werden.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

angepasst werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026