Change-Management nach ITIL vertieft: CAB, Risiko und Rollback

Warum dieser Artikel ueber die Grundlagen hinausgeht

Im Artikel ITIL-Grundlagen hast du gelernt, dass ein Change eine geplante Aenderung ist und dass es Standard-, Normal- und Emergency-Changes gibt. Das reicht, um zu verstehen, worum es geht – aber es reicht nicht, um einen Change-Prozess so aufzubauen, dass er im Ernstfall traegt.

Die eigentliche Arbeit steckt in drei Dingen, die in der Praxis am haeufigsten schiefgehen: Erstens wird das Risiko eines Changes nicht sauber bewertet, sondern nach Bauchgefuehl entschieden. Zweitens gibt es einen Rollback-Plan nur auf dem Papier, der im Ernstfall nicht funktioniert, weil er nie getestet wurde. Drittens fehlt ein Change-Kalender, sodass zwei Teams am selben Wochenende unabhaengig voneinander den Fileserver und die Firewall anfassen – und beim anschliessenden Ausfall niemand weiss, welcher der beiden Changes schuld ist.

Dieser Artikel geht auf genau diese drei Punkte vertieft ein: wie ein Change Advisory Board (CAB) tatsaechlich funktioniert, wie du Risiko systematisch statt intuitiv bewertest, wie ein Rollback-Plan aussehen muss, der im Notfall wirklich hilft, und wie Change-Kalender und Freeze-Perioden Kollisionen verhindern.

Die drei Change-Typen im Detail

Die Klassifizierung eines Changes entscheidet ueber den gesamten weiteren Prozess: Wie viel Papierkram, wer genehmigt, wie viel Vorlaufzeit. Wer hier falsch klassifiziert, produziert entweder unnoetige Buerokratie oder umgeht wichtige Kontrollen.

Standard Change

Ein Standard Change ist eine vorab genehmigte, dokumentierte, wiederholbare Prozedur mit bekanntem, niedrigem Risiko. Der entscheidende Punkt: Die Genehmigung passiert einmalig, wenn die Prozedur in den Katalog aufgenommen wird – nicht bei jeder Ausfuehrung erneut.

Typische Standard Changes im KMU-Alltag:

• Neuanlage eines Benutzerkontos nach dokumentiertem Onboarding-Prozess
• Passwort-Reset, Freischaltung eines Netzlaufwerks
• Austausch eines defekten Clients nach Standard-Image (MDT/Intune)
• Monatliches Patchen von Nicht-produktiven Testsystemen im definierten Wartungsfenster

Ein Standard-Change-Katalog muss periodisch reviewt werden (empfohlen: jaehrlich oder bei jeder groesseren Systemaenderung). Sonst schleicht sich ein Standard Change ein, dessen Rahmenbedingungen sich veraendert haben – z.B. weil das Zielsystem inzwischen geschaeftskritisch geworden ist.

Normal Change

Ein Normal Change durchlaeuft den vollen Prozess: Antrag (Request for Change, RFC), Risikobewertung, Genehmigung durch die zustaendige Instanz, Planung, Implementierung, Review. ITIL 4 unterscheidet hier oft zusaetzlich zwischen:

• Minor Change: geringe bis mittlere Auswirkung, kann durch eine delegierte Change-Autoritaet (z.B. Teamleiter) genehmigt werden, ohne das volle CAB zu bemuehen.
• Major Change: hohe Auswirkung oder hohes Risiko, gehoert vor das CAB.

Diese Aufteilung ist der Kern dessen, was ITIL 4 mit “Risiko-basierter Freigabe” statt “alles durchs CAB” meint: Nicht jede Aenderung braucht das volle Gremium, aber jede Aenderung braucht eine bewusste, dokumentierte Entscheidung, wer sie freigibt.

Emergency Change

Ein Emergency Change wird ausgeloest, um einen Major Incident zu beheben oder eine akute Sicherheitsluecke zu schliessen – z.B. ein Zero-Day-Patch fuer eine aktiv ausgenutzte Schwachstelle. Der Prozess ist bewusst verkuerzt:

1. Kurzabstimmung mit dem Emergency CAB (ECAB) – oft ein Telefonat oder ein Teams-Call mit 2-3 Personen statt einer vollen Sitzung.
2. Implementierung, ggf. ohne vollstaendigen Test.
3. Nachtraegliche, lueckenlose Dokumentation des RFC und aller getroffenen Entscheidungen – das ist keine Kann-Bestimmung, sondern Pflicht, weil sonst nie geprueft werden kann, ob die Abkuerzung gerechtfertigt war.
4. Verpflichtendes Post-Implementation-Review.

Entscheidungsbaum: Welcher Change-Typ liegt vor?

Ist die Aenderung Teil eines dokumentierten, bereits genehmigten Standard-Katalogs?
  JA  → Standard Change (keine erneute Einzelgenehmigung noetig)
  NEIN
    ↓
Muss die Aenderung SOFORT erfolgen, um einen Major Incident
oder eine aktive Sicherheitsluecke zu beheben?
  JA  → Emergency Change → ECAB kontaktieren
  NEIN
    ↓
Risiko-Score berechnen (siehe naechster Abschnitt)
  Niedrig/Mittel → Minor Normal Change → delegierte Freigabe (z.B. Teamleiter)
  Hoch/Kritisch  → Major Normal Change → volles CAB

Risiko- und Impact-Bewertung

Die haeufigste Schwachstelle im Change-Prozess: Risiko wird gefuehlt, nicht gemessen. “Das sollte kein Problem sein” ist keine Risikobewertung. Eine brauchbare Bewertung braucht zwei unabhaengige Dimensionen.

Impact (Auswirkung im Schadensfall)

Wahrscheinlichkeit (dass etwas schiefgeht)

Risiko-Score und Konsequenz

Risiko-Score = Impact × Wahrscheinlichkeit (jeweils 1, 3 oder 5), daraus ergibt sich ein Wert zwischen 1 und 25.

Beispielrechnung: Migration des Exchange-Postfachs von On-Premises nach Exchange Online fuer die gesamte Firma.

• Impact: Betroffene User = 5 (alle), Kritikalitaet = 5 (Mail ist Kerngeschaeft), Reversibilitaet = 3 (Rueckmigration moeglich, aber aufwendig) → gerundeter Impact-Wert 5
• Wahrscheinlichkeit: Erfahrung = 3 (schon einmal gemacht, aber nicht routinemaessig), Testabdeckung = 3 (Pilotgruppe getestet) → Wahrscheinlichkeit 3
• Score = 5 × 3 = 15 → Hoch, gehoert vor das volle CAB, mit definiertem Wartungsfenster ausserhalb der Buerozeiten und getestetem Rollback (z.B. Hybrid-Koexistenz-Phase beibehalten, bis Migration verifiziert ist).

Change Advisory Board (CAB): Aufbau und Kadenz

Rollen im CAB

Kadenz

Ein funktionierendes CAB braucht einen festen Rhythmus, sonst verschiebt sich alles und Changes stauen sich. Bewaehrtes Muster:

• Woechentliches CAB, fixer Slot (z.B. jeden Dienstag 10:00–10:45 Uhr).
• Einreichefrist: RFCs muessen bis Freitag 12:00 Uhr der Vorwoche eingereicht sein, damit alle Teilnehmenden Zeit zur Pruefung haben.
• Traktandenliste wird am Montag verschickt, inklusive Risiko-Score jedes Antrags.
• ECAB ist kein fixer Termin, sondern eine definierte Eskalationskette (z.B. Change Manager → IT-Leiter → Geschaeftsleitung), erreichbar innert 30–60 Minuten per Telefon/Teams.

CAB im Schweizer KMU – realistisch verkleinert

Im KMU mit 3-8 IT-Mitarbeitenden ist ein CAB mit sieben Rollen aus einer anderen Welt. Realistisch:

• Das CAB ist ein fixer Traktandenpunkt im woechentlichen IT-Jour-Fixe, nicht ein separates Meeting.
• Change Manager und Service Owner sind oft dieselbe Person.
• Business-Vertretung reicht als kurze Rueckmeldung per E-Mail oder Teams-Kanal (“Passt das Wartungsfenster fuer die Buchhaltung?”), statt physisch anwesend zu sein.
• Wichtig ist nicht die Anzahl Koepfe, sondern dass jemand ausserhalb des Umsetzenden den Change gegenliest. Ein Vier-Augen-Prinzip verhindert die meisten vermeidbaren Fehler.

RFC-Vorlage

rfc_id: CH-2026-118
titel: "SQL Server 2019 auf 2022 In-Place-Upgrade – ERP-Datenbankserver"
antragsteller: "M. Keller"
datum_antrag: 2026-07-10
change_typ: normal
kategorie: major
betroffene_systeme:
  - SRV-SQL-01 (ERP-Produktivdatenbank)
impact:
  betroffene_user: 5      # 1 / 3 / 5
  kritikalitaet: 5        # 1 / 3 / 5
  reversibilitaet: 5      # 1 / 3 / 5 (In-Place-Upgrade schwer rueckgaengig)
wahrscheinlichkeit:
  team_erfahrung: 3       # 1 / 3 / 5
  testabdeckung: 1        # 1 / 3 / 5 (vollstaendig auf SRV-SQL-TEST getestet)
risiko_score: 15          # Impact-Mittelwert x Wahrscheinlichkeits-Mittelwert
geplantes_fenster: "2026-07-19, Samstag 06:00-10:00 Uhr"
rollback_plan_verlinkung: "RB-2026-118"
freigabe_erforderlich: CAB
status: eingereicht

Rollback- und Backout-Plaene

Der haeufigste Grund, warum ein Change zur Katastrophe wird, ist nicht der Change selbst – es ist ein Rollback-Plan, der auf dem Papier gut aussieht, aber nie getestet wurde. “Wir spielen das Backup zurueck” ist kein Rollback-Plan, solange niemand geprueft hat, wie lange das dauert und ob das Backup ueberhaupt vollstaendig ist.

Was ein brauchbarer Rollback-Plan enthalten muss

1. Go/No-Go-Kriterien: Klar messbare Bedingungen, ab wann zurueckgerollt wird. Nicht “wenn es Probleme gibt”, sondern konkret: “Wenn nach dem Upgrade mehr als 5 Fehlermeldungen im Anwendungslog innert 15 Minuten auftreten” oder “wenn der ERP-Login-Test nach 20 Minuten nicht erfolgreich ist”.
2. Zeitbudget: Ab welchem Zeitpunkt wird der Rollback zwingend eingeleitet, unabhaengig vom Fortschritt der Fehlersuche? (Sogenannter “Point of No Return” bzw. Entscheidungszeitpunkt.)
3. Konkrete Schritte, nummeriert, nicht als Fliesstext.
4. Verantwortliche Person fuer die Rollback-Entscheidung – im Idealfall nicht dieselbe Person, die technisch unter Zeitdruck steht.
5. Kommunikationsplan: Wer wird informiert, wenn zurueckgerollt wird (Anwender, Geschaeftsleitung, betroffene Abteilung)?
6. Verifikationsschritte nach dem Rollback: Woran erkennst du, dass der Rollback erfolgreich war und der Ausgangszustand wirklich wiederhergestellt ist?

Beispiel: Backout-Plan fuer ein SQL-Server-Upgrade

Backout-Plan RB-2026-118
Bezug: CH-2026-118 (SQL Server 2019 → 2022 In-Place-Upgrade, SRV-SQL-01)

Go/No-Go-Kriterien (Pruefung 30 Min. nach Upgrade):
 - ERP-Testtransaktion (Auftrag anlegen) erfolgreich? [ja/nein]
 - SQL Server Error Log ohne kritische Fehler (Severity >= 17)? [ja/nein]
 - Antwortzeit ERP-Login < 5 Sekunden? [ja/nein]
Wenn EIN Kriterium "nein" → Rollback einleiten.

Point of No Return: 08:30 Uhr (danach beginnt regulaerer Betrieb, kein Rollback mehr moeglich)

Rollback-Schritte:
1. ERP-Applikationsdienst auf SRV-APP-01 stoppen
2. Vollstaendiges Restore der Datenbank aus Backup vor Upgrade
   (Backup-Zeitstempel: 2026-07-19 05:45 Uhr, getestet auf SRV-SQL-TEST am 2026-07-15)
3. SQL Server Dienst auf Version 2019 zurueck (VM-Snapshot von 05:50 Uhr einspielen,
   da In-Place-Upgrade kein einfaches Deinstallieren erlaubt)
4. ERP-Applikationsdienst starten
5. Testtransaktion wiederholen
6. Betroffene Abteilungen per Teams-Broadcast informieren

Verantwortlich fuer Rollback-Entscheidung: M. Keller (nicht der ausfuehrende Techniker)
Kommunikation: IT-Leiter, Leiter Finanzen (ERP-Hauptnutzer)
Geschaetzte Rollback-Dauer: 45 Minuten

Ein praktischer Trick fuer Datenbankaenderungen: SQL Server unterstuetzt transaktionale DDL. Schema-Aenderungen lassen sich testweise in einer expliziten Transaktion ausfuehren und bei Bedarf zurueckrollen, bevor sie fest committed werden:

BEGIN TRANSACTION;

ALTER TABLE dbo.Auftraege ADD Lieferdatum DATE NULL;

-- Validierung: Stichprobe pruefen, Anwendung testweise gegen die
-- geaenderte Struktur laufen lassen (in einer Staging-Session)
SELECT TOP 10 * FROM dbo.Auftraege;

-- Bei Problemen:
-- ROLLBACK TRANSACTION;

-- Erst nach erfolgreicher Verifikation:
COMMIT TRANSACTION;

Das ersetzt keinen vollstaendigen Rollback-Plan, reduziert aber das Risiko bei reinen Schemaaenderungen erheblich, weil du die Aenderung vor dem endgueltigen Commit noch verwerfen kannst.

PowerShell: Backup-Integritaet vor dem Change verifizieren

# Prueft, ob ein aktuelles, vollstaendiges Backup vor dem Change-Fenster existiert
$BackupPfad = "\\SRV-BACKUP-01\SQL\SRV-SQL-01\Full"
$MaxAlterStunden = 6

$LetztesBackup = Get-ChildItem -Path $BackupPfad -Filter "*.bak" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -First 1

if (-not $LetztesBackup) {
    Write-Error "Kein Backup gefunden - Change darf NICHT gestartet werden."
    exit 1
}

$AlterStunden = (New-TimeSpan -Start $LetztesBackup.LastWriteTime -End (Get-Date)).TotalHours

if ($AlterStunden -gt $MaxAlterStunden) {
    Write-Error "Letztes Backup ist $([math]::Round($AlterStunden,1)) Stunden alt - zu alt fuer den Change."
    exit 1
}

Write-Host "Backup-Check OK: $($LetztesBackup.Name), Alter: $([math]::Round($AlterStunden,1)) h" -ForegroundColor Green

Ein solches Skript gehoert als automatisiertes Pre-Change-Gate in die Pipeline oder wird manuell vor jedem Major Change ausgefuehrt und dessen Ergebnis dem RFC angehaengt.

Change-Kalender und Freeze-Perioden

Forward Schedule of Change (FSC)

Der FSC ist die zentrale Uebersicht aller geplanten Changes – ITIL-Standardbegriff. Ohne FSC passiert regelmaessig genau das: Zwei Teams planen unabhaengig voneinander Changes im selben Zeitfenster an verwandten Systemen, und beim anschliessenden Vorfall kann niemand die Ursache eindeutig zuordnen.

Praktische Umsetzung im KMU:

• Ein gemeinsamer Kalender (Outlook/Exchange-Kalender, SharePoint-Liste oder das Change-Modul im Ticketsystem), sichtbar fuer alle IT-Mitarbeitenden.
• Jeder genehmigte Change wird mit Zeitfenster, betroffenen Systemen und Verantwortlichem eingetragen.
• Vor jeder Genehmigung wird der Kalender auf Ueberschneidungen mit anderen Changes und mit Freeze-Perioden geprueft.

Freeze-Perioden (Change Freeze)

Eine Freeze-Periode ist ein definiertes Zeitfenster, in dem keine Normal Changes an bestimmten Systemen durchgefuehrt werden – Emergency Changes bleiben moeglich, aber mit erhoehter Huerde.

Typische Freeze-Perioden im Schweizer KMU-Kontext:

• Monatsabschluss in der Buchhaltung (meist die ersten 2-3 Arbeitstage des Folgemonats)
• Jahresabschluss und Lohnlauf Dezember/Januar
• Saisonale Spitzen im Handel (z.B. Black Friday, Weihnachtsgeschaeft)
• Inventur-Zeitraum bei Produktionsbetrieben
• Grosse Firmenevents (Kundenmessen, Praesentationen), bei denen Netzwerk und Praesentationstechnik stabil bleiben muessen

Technische Durchsetzung einer Freeze-Periode ist mehr als eine Kalendereintragung – sie sollte, wo moeglich, auch technisch abgesichert werden:

• WSUS/Intune: Genehmigung neuer Update-Ringe fuer den Freeze-Zeitraum manuell pausieren.
• Azure DevOps / CI-CD-Pipelines: Deployment-Gate, das gegen einen Freeze-Kalender prueft, bevor ein Release durchlaeuft.
• Git-Branch-Schutz: Merge in den Produktions-Branch waehrend der Freeze-Periode blockieren (Branch Protection Rule mit zeitlich befristetem Required Reviewer oder Status Check).

# Beispiel: einfache Freeze-Kalender-Definition, die eine Pipeline vor
# dem Deployment abfragen kann (z.B. als JSON/YAML-Datei im Repo)
freeze_perioden:
  - name: "Monatsabschluss Buchhaltung"
    von: "2026-08-01"
    bis: "2026-08-03"
    systeme: ["ERP", "SRV-SQL-01"]
  - name: "Weihnachtsgeschaeft"
    von: "2026-11-20"
    bis: "2027-01-05"
    systeme: ["Webshop", "Zahlungsdienstleister-Schnittstelle"]

Ein Pipeline-Schritt kann diese Datei einlesen und das Deployment mit Fehlercode abbrechen, wenn das aktuelle Datum und die betroffenen Systeme in eine Freeze-Periode fallen – so wird aus einer reinen Prozessregel eine technische Kontrolle, die nicht vom Erinnerungsvermoegen des Teams abhaengt.

Post-Implementation-Review (PIR)

Das PIR ist der am haeufigsten uebersprungene Schritt – der Change ist gelaufen, alle sind erleichtert, und niemand nimmt sich die Zeit fuer die Nachbetrachtung. Dabei liefert genau das PIR die Daten, mit denen sich der Prozess verbessert.

Wann?

Ueblich sind 3-10 Arbeitstage nach Abschluss des Changes – frueh genug, dass sich noch alle erinnern, spaet genug, dass Spaetfolgen (z.B. Performance-Probleme, die erst unter Volllast auftreten) sichtbar geworden sind.

Was gehoert ins PIR?

1. Wurden die Ziele des Changes erreicht? (Nicht nur “ist es gelaufen”, sondern “hat es das geloest, was es sollte”.)
2. Gab es unerwartete Nebenwirkungen oder Incidents im Nachgang?
3. War die Risikobewertung im Nachhinein zutreffend, oder wurde das Risiko unter-/ueberschaetzt?
4. Musste der Rollback ausgeloest werden? Falls ja: Hat er wie geplant funktioniert?
5. Was wuerdest du naechstes Mal anders machen? (Testabdeckung, Kommunikation, Zeitfenster.)
6. Ist die CMDB/Dokumentation aktualisiert? (Siehe IT-Dokumentation & Inventar.)

Wenn ein PIR wiederholt aehnliche Probleme aufdeckt (z.B. “Testumgebung bildet Produktivumgebung nicht ab”), ist das ein klassischer Fall fuer Problem Management statt fuer eine erneute Ad-hoc-Loesung im naechsten Change.

Tooling-Vergleich fuer Change Management

Haeufige Fallstricke in der Praxis

• Rollback nie getestet: Der Plan sieht gut aus, aber niemand hat je versucht, ihn tatsaechlich durchzufuehren. Teste Rollbacks fuer kritische Systeme regelmaessig, nicht nur im Ernstfall.
• Change-Kalender existiert, wird aber nicht konsultiert: Er muss Teil des Genehmigungsschritts sein, nicht eine optionale Fleissaufgabe.
• Standard-Change-Katalog veraltet: Ein Standard Change, der vor drei Jahren risikoarm war, kann heute (z.B. wegen neuer Abhaengigkeiten) ein anderes Risikoprofil haben.
• CAB wird zur Blockade-Instanz: Wenn jede Kleinigkeit durchs volle CAB muss, umgehen Teams den Prozess irgendwann komplett (“shadow changes”). Risikobasierte Delegation ist hier der Schluessel.
• PIR wird uebersprungen: Ohne PIR verbessert sich der Prozess nie, und wiederkehrende Fehler bleiben unentdeckt.
• Freeze-Perioden gelten nicht fuer Cloud-Anbieter: Siehe oben – eigene Disziplin nuetzt wenig, wenn SaaS-Updates parallel durchlaufen.

Praxis: Ein Normal Change end-to-end

Zum Abschluss ein durchgaengiges Beispiel, das alle Bausteine dieses Artikels verbindet:

1. Antrag: IT-Mitarbeiter reicht RFC fuer “Firewall-Regel-Update: neue VPN-Site-to-Site-Verbindung zum neuen Aussenstandort” ein, inklusive Risiko-Score-Berechnung (Impact 3, Wahrscheinlichkeit 3 → Score 9, “Mittel”).
2. Kalenderpruefung: Kein Konflikt mit anderen geplanten Changes, keine Freeze-Periode im Zeitraum.
3. Genehmigung: Da Score “Mittel”, genuegt delegierte Freigabe durch den Teamleiter Netzwerk statt volles CAB – wird aber im woechentlichen CAB zur Kenntnisnahme aufgefuehrt.
4. Rollback-Plan: Firewall-Konfiguration wird vor der Aenderung exportiert (Export-Configuration bzw. herstellerspezifisches Backup), Wiedereinspielen im Fehlerfall dauert laut Test ca. 5 Minuten.
5. Implementierung: Aenderung im definierten Wartungsfenster (ausserhalb der Kernarbeitszeit des neuen Standorts).
6. Verifikation: Verbindungstest, Routing-Pruefung, Monitoring-Alarm fuer die neue Verbindung eingerichtet.
7. Post-Implementation-Review nach 5 Arbeitstagen: Verbindung stabil, keine Incidents, ein kleiner Verbesserungspunkt dokumentiert (MTU-Wert haette vorab getestet werden sollen) – fliesst in die naechste Standard-Vorlage fuer Site-to-Site-VPN-Changes ein.

Genau dieser letzte Schritt – aus einem einzelnen Change eine wiederverwendbare, verbesserte Vorlage zu machen – ist der eigentliche Mehrwert eines reifen Change-Prozesses: Jeder Change macht den naechsten sicherer und schneller.

Weiterlernen

• ITIL 4 Change Enablement – Axelos – Offizielle ITIL-4-Grundlagen und Zertifizierungsinfos
• mITSM – Change Management (deutsch) – Praxisorientierte Erklaerung von Rollen und Ablauf
• IT Process Wiki – Change Management (deutsch) – Detaillierte Prozessbeschreibung mit Aktivitaetsdiagrammen
• Atlassian – IT Change Management Guide – Change-Typen, CAB und moderne DevOps-Perspektive
• Microsoft Learn – SQL Server transaktionale DDL-Anweisungen – Referenz zu BEGIN TRANSACTION/COMMIT/ROLLBACK
• ITSM.tools – Change Enablement in ITIL 4 – Vertiefung zu risikobasierter Freigabe und Change-Autoritaet