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:

Passwort eines Testkontos zurücksetzen,

Standardsoftware installieren,

Firewall-Regel in Produktion ändern,

Datenbankmigration durchführen,

Sicherheitsupdate wegen aktiver Schwachstelle einspielen,

zentrale Authentifizierung umstellen.

Diese Änderungen unterscheiden sich stark in:

Risiko,

Auswirkung,

Dringlichkeit,

Wiederholbarkeit,

Genehmigungsbedarf,

Testaufwand,

Kommunikationsbedarf,

Rollback-Möglichkeit.

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

Grundidee der Change-Klassifizierung

Eine Organisation sollte festlegen:

welche Change-Typen verwendet werden,

welche Kriterien dafür gelten,

wer entscheiden darf,

welche Genehmigung notwendig ist,

welche Dokumentation erwartet wird,

welche Tests erforderlich sind,

wann Kommunikation notwendig ist,

und wie der Erfolg geprüft wird.

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:

wiederholt sich häufig,

besitzt geringes Risiko,

Ablauf ist dokumentiert,

Auswirkungen sind bekannt,

Umsetzung ist standardisiert,

Genehmigung ist bereits grundsätzlich erteilt,

Rollen und Schritte sind klar,

Erfolg ist leicht prüfbar.

Beispiele:

Standardsoftware aus genehmigtem Katalog installieren,

Benutzer in eine genehmigte Standardgruppe aufnehmen,

Standardarbeitsplatz bereitstellen,

neues Standard-Monitoring für einen Server aktivieren,

Zertifikat nach geprüftem Runbook erneuern,

Standarddrucker einrichten.

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:

nicht vollständig standardisiert,

Risiko muss bewertet werden,

Auswirkungen müssen geprüft werden,

Genehmigung ist erforderlich,

Umsetzung muss geplant werden,

Tests und Rollback müssen betrachtet werden.

Beispiele:

Update einer produktiven Anwendung,

Änderung einer Firewall-Regel,

Datenbankänderung,

Umstellung eines Servers,

Anpassung einer Schnittstelle,

Änderung an einem produktiven Netzwerksegment,

Einführung eines neuen Tools.

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:

kritischer Service ist ausgefallen,

Sicherheitslücke wird aktiv ausgenutzt,

Datenverlust droht,

Major Incident benötigt sofortige technische Maßnahme,

kein sicherer Workaround ist verfügbar,

dringende Wiederherstellung ist notwendig.

Beispiele:

kritischen Patch kurzfristig einspielen,

fehlerhafte Konfiguration sofort zurückrollen,

abgelaufenes Zertifikat bei Produktionsausfall erneuern,

kompromittierten Zugang sperren,

DNS oder Routing kurzfristig korrigieren.

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:

neues Rechenzentrum anbinden,

zentrales Identity-System migrieren,

ERP-System aktualisieren,

Netzwerkarchitektur grundlegend ändern,

neue Cloud-Plattform einführen,

mehrere Standorte gleichzeitig umstellen,

kritische Datenbank migrieren.

Typische Merkmale:

viele Stakeholder betroffen,

hoher Planungsaufwand,

mehrere Teams beteiligt,

umfangreiche Tests notwendig,

Kommunikationsplan erforderlich,

Rollback komplex oder nur eingeschränkt möglich,

Management-Entscheidung notwendig.

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:

kleine Konfigurationsanpassung an einem nicht kritischen System,

Ergänzung einer Monitoringbeschreibung,

Anpassung eines Formularfelds,

Änderung eines nicht produktiven Testsystems,

kleinere Dokumentationsänderung.

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:

Was kann schiefgehen?

Welche Services wären betroffen?

Welche Benutzer oder Kunden wären betroffen?

Wie wahrscheinlich ist ein Fehler?

Wie schwer wären die Auswirkungen?

Wie gut ist der Change getestet?

Gibt es einen Rollback?

Gibt es ein Wartungsfenster?

Gibt es Abhängigkeiten?

Gibt es Sicherheits- oder Datenschutzrisiken?

Wer muss informiert werden?

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:

Ist ein geschäftskritischer Service betroffen?

Sind interne Benutzer betroffen?

Sind externe Kunden betroffen?

Sind mehrere Standorte betroffen?

Gibt es Auswirkungen auf Produktion, Verkauf, Abrechnung oder Support?

Können Daten verloren gehen?

Können Sicherheitsanforderungen verletzt werden?

Sind gesetzliche oder vertragliche Anforderungen betroffen?

Gibt es Abhängigkeiten zu anderen Services?

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:

Komplexität der Änderung,

Erfahrung des Teams,

Qualität der Tests,

Reife des Runbooks,

Anzahl beteiligter Systeme,

Anzahl manueller Schritte,

bekannte Fehler,

Stabilität der Umgebung,

Lieferantenabhängigkeit,

Neuartigkeit der Änderung.

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:

Warum ist die Änderung dringend?

Gibt es einen akuten Schaden?

Droht ein Sicherheitsvorfall?

Läuft eine Frist ab?

Gibt es einen Workaround?

Kann die Änderung bis zum nächsten Wartungsfenster warten?

Wird die Dringlichkeit durch schlechte Planung verursacht?

Welche Risiken entstehen durch sofortige Umsetzung?

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:

Incident dauerhaft beheben,

Sicherheitsrisiko reduzieren,

Performance verbessern,

Kosten senken,

Benutzererfahrung verbessern,

gesetzliche Anforderungen erfüllen,

technische Schulden reduzieren,

Stabilität erhöhen,

Automatisierung ermöglichen,

Betrieb vereinfachen.

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:

Genehmigung,

Testtiefe,

Kommunikationsbedarf,

Wartungsfenster,

Dokumentationsumfang,

Beteiligung von Spezialisten,

Nachprüfung.

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:

mehrere Services betroffen sind,

mehrere Teams beteiligt sind,

hohes Risiko besteht,

der Rollback schwierig ist,

Benutzer oder Kunden informiert werden müssen,

Sicherheitsfragen bestehen,

Lieferanten beteiligt sind,

mehrere Changes zeitlich kollidieren,

oder Managemententscheidungen notwendig sind.

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:

Incident Manager,

Change Manager,

Service Owner,

Informationssicherheit,

verantwortliches Fachteam,

Management bei hohem Geschäftsrisiko.

Wichtig ist:

Entscheidung dokumentieren,

Risiko akzeptieren oder begründen,

Umsetzung kontrollieren,

Ergebnis prüfen,

nachträgliches Review durchführen.

Standard Change richtig definieren

Ein Standard Change sollte nicht leichtfertig als Standard eingestuft werden.

Vorab zu klären:

Ist der Ablauf wiederholbar?

Ist das Risiko niedrig?

Sind Auswirkungen bekannt?

Gibt es ein geprüftes Runbook?

Sind Berechtigungen klar?

Gibt es definierte Erfolgskriterien?

Gibt es Abbruchkriterien?

Wird die Ausführung protokolliert?

Wird der Standard regelmäßig überprüft?

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:

ein Request zu spät gestellt wurde,

Planung vergessen wurde,

Genehmigung umgangen werden soll,

ein Team schneller arbeiten möchte,

normale Change-Zeiten als störend empfunden werden.

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:

Sicherheitslücke bleibt offen,

Zertifikat läuft bald ab,

Speicher läuft voll,

instabile Version bleibt produktiv,

gesetzliche Frist wird verpasst,

Workaround belastet Betrieb dauerhaft,

bekannte Fehler erzeugen weitere Incidents.

Eine gute Bewertung betrachtet deshalb:

Risiko des Changes,

Risiko des Nicht-Handelns,

Risiko einer Verzögerung,

Risiko des Workarounds.

Rollback und Backout in der Risikobewertung

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

Zu prüfen ist:

Kann die Änderung vollständig zurückgenommen werden?

Wie lange dauert der Rollback?

Sind Backups vorhanden?

Wurden Konfigurationen gesichert?

Werden Daten verändert?

Gibt es Abhängigkeiten?

Wer entscheidet über Abbruch?

Wann ist der späteste sichere Abbruchzeitpunkt?

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:

betroffene Benutzer,

Service Desk,

Fachbereiche,

Management,

Lieferanten,

Informationssicherheit,

Kunden,

Bereitschaftsdienst.

Inhalt der Kommunikation:

Was wird geändert?

Wann wird geändert?

Welche Auswirkungen sind möglich?

Gibt es eine Unterbrechung?

Was müssen Benutzer tun?

Wo gibt es Statusinformationen?

Wann gilt der Change als abgeschlossen?

Wartungsfenster bewerten

Ein Wartungsfenster sollte passend gewählt werden.

Zu berücksichtigen sind:

Servicezeiten,

Geschäftsprozesse,

internationale Zeitzonen,

Monats- oder Jahresabschluss,

Produktionszeiten,

Kundenverkehr,

Backupfenster,

Lieferantenverfügbarkeit,

Bereitschaft,

Rollbackdauer.

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

Abhängigkeiten und Change-Kollisionen

Mehrere Changes können sich gegenseitig beeinflussen.

Beispiele:

Netzwerkteam ändert Routing, während Anwendungsteam ein Deployment durchführt.

Datenbankwartung fällt mit Reporting-Lauf zusammen.

Cloud-Team ändert Identitätsdienst, während VPN-Client aktualisiert wird.

Backupfenster überschneidet sich mit Datenbankmigration.

Change Enablement sollte prüfen:

Welche Changes laufen gleichzeitig?

Betreffen sie gleiche Services oder CIs?

Können sie sich gegenseitig beeinflussen?

Gibt es ein Change Freeze?

Muss eine Reihenfolge festgelegt werden?

Change Freeze

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

Beispiele:

Jahresabschluss,

kritische Verkaufsphase,

Produktionshochlauf,

Prüfung oder Audit,

große Migration,

Feiertagsgeschäft.

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:

Firewall-Regeln,

Identitätsdiensten,

Administratorrechten,

MFA,

Logging,

Verschlüsselung,

Zertifikaten,

externen Schnittstellen,

Cloud-Berechtigungen,

Datenfreigaben,

Sicherheitssoftware.

Fragen:

Werden neue Zugriffe eröffnet?

Werden Rechte erweitert?

Werden Schutzmaßnahmen deaktiviert?

Werden Logs reduziert?

Werden sensible Daten berührt?

Gibt es ein Prüf- oder Rezertifizierungsverfahren?

Datenschutz und Compliance

Manche Changes betreffen Datenschutz oder Compliance.

Beispiele:

neue Datenverarbeitung,

neue Schnittstelle,

neue Cloud-Ablage,

geänderte Aufbewahrung,

geänderte Protokollierung,

Zugriff auf personenbezogene Daten,

Standortwechsel von Daten,

Einführung eines neuen Tools.

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

Beispielsweise durch Datenschutz, Informationssicherheit, Compliance oder Rechtsabteilung.

Lieferantenrisiken

Bei Changes mit Lieferantenbezug zu prüfen:

Ist der Lieferant verfügbar?

Gibt es Support während des Wartungsfensters?

Gibt es Herstellerhinweise?

Ist die Version unterstützt?

Gibt es bekannte Fehler?

Wer führt welche Aufgabe aus?

Welche Eskalationswege gelten?

Welche SLA oder Verträge sind betroffen?

Wie wird das Ergebnis abgenommen?

Auch externe Changes müssen intern nachvollziehbar gesteuert werden.

Change-Erfolgskriterien

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

Beispiele:

Anwendung startet ohne Fehler,

Benutzer können sich anmelden,

Schnittstelle überträgt Daten korrekt,

Monitoring ist grün,

keine neuen Fehler in Logs,

Performance bleibt im Zielbereich,

Sicherheitsprüfung erfolgreich,

Service Desk erhält keine Störungswelle,

Fachbereich bestätigt Funktion.

Ohne Erfolgskriterien ist die Nachprüfung unklar.

Failed Change und Lessons Learned

Ein Change kann fehlschlagen.

Wichtig ist dann:

Auswirkungen begrenzen,

Rollback durchführen, falls erforderlich,

Benutzer informieren,

Incident oder Problem verknüpfen,

Ursache des Fehlschlags untersuchen,

Change-Modell verbessern,

Tests anpassen,

Dokumentation korrigieren.

Ziel ist Lernen, nicht Schuldzuweisung.

Praxisbeispiel: Standard Change

Änderung

Standardsoftware aus genehmigtem Katalog wird installiert.

Bewertung

Ablauf ist bekannt,

Software ist geprüft,

Zielgruppe ist definiert,

Risiko ist niedrig,

Installation ist automatisiert,

Rollback ist möglich.

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

mehrere Fachbereiche betroffen,

Testsystem vorhanden,

Wartungsfenster notwendig,

Rollback möglich, aber zeitaufwendig,

Benutzerkommunikation erforderlich.

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

Risiko des Nicht-Handelns sehr hoch,

Testzeit begrenzt,

Produktionssystem betroffen,

Management und Informationssicherheit müssen eingebunden werden.

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:

nicht jede Änderung sofort produktiv durchführen,

technische und geschäftliche Auswirkungen bedenken,

betroffene Services und Abhängigkeiten prüfen,

Rollback vor der Umsetzung planen,

Tests passend zum Risiko durchführen,

Service Desk und Benutzer informieren,

Changes sauber dokumentieren,

und aus fehlgeschlagenen Changes lernen.

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

5.1 Change Enablement – Ziele, Begriffe und Abgrenzung

5.3 Genehmigung, Planung und Umsetzung von Changes

5.4 Release Management und Deployment Management

5.5 Change-Erfolg messen und Continual Improvement

Incident Management

Problem Management

Service Configuration Management

Information Security Management

Quellen und Versionsstand

Offizielle Grundlagen

PeopleCert – ITIL Practice Guide: Change Enablement

PeopleCert – ITIL Practice Guide: Incident Management

PeopleCert – ITIL Practice Guide: Problem Management

PeopleCert – ITIL Practice Guide: Information Security Management

PeopleCert – ITIL Practice Guide: Service Configuration Management

ITIL Foundation – Version 5

Einordnung

Die dargestellten:

Change-Typen,

Risikokriterien,

Matrizen,

Checklisten,

Praxisbeispiele,

und Bewertungsfragen

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

Change-Typen-Matrix,

Risikoskala,

Genehmigungsmatrix,

CAB-Pflicht,

Testvorgabe,

oder Emergency-Change-Struktur

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

Services,

Risiken,

Organisation,

Service Levels,

Sicherheitsanforderungen,

Change-Modell,

Lieferanten,

Datenqualität,

und verfügbare Fähigkeiten

angepasst werden.

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