Change Management: RFC, CAB

Wenn etwas an einem produktiven IT-System geändert wird – ein Server gepatcht, eine Firewall-Regel angepasst, eine neue Software installiert – kann eine Menge schiefgehen. Change Management ist die ITIL-Practice, die solche Änderungen kontrolliert: jeder Change wird als RFC (Request for Change) beantragt, bewertet, freigegeben, umgesetzt und nachverfolgt. Ziel: nützliche Änderungen schnell durchsetzen, gefährliche frühzeitig erkennen, Spuren hinterlassen für Troubleshooting („wer hat hier was wann geändert?"). Das zentrale Gremium für nicht-triviale Changes ist das CAB (Change Advisory Board) – eine Runde aus Stakeholdern, die jeden RFC bewertet und freigibt. In ITIL 4 heißt die Practice offiziell Change Enablement – „Management" klang zu bremsend, „Enablement" betont das Ziel Änderung möglich machen, nicht verhindern. Diese Lektion zeigt RFC-Inhalt und -Lifecycle, CAB-Rollen, Risikobewertung und die Verzahnung mit Problem Management und CMDB.

1) Der RFC – was drinsteht

Ein RFC (Request for Change) ist das formalisierte Antragsdokument. Standard-Felder:

Der wichtigste Punkt, der oft vergessen wird: der Backout-Plan. „Was machen wir, wenn die neue Firmware den Switch zerstört?" – ohne diese Frage, beantwortet vor dem Change, kein Genehmigungsstempel. Ein gutes CAB lehnt einen RFC ohne plausiblen Backout-Plan grundsätzlich ab.

2) Der RFC-Lebenszyklus

Klick die Stati an, um zu sehen, was in jeder Phase passiert:

3) Das CAB – Change Advisory Board

Das CAB ist kein Vetorecht-Gremium, sondern ein Beratungs- und Genehmigungsausschuss. Es trifft sich regelmäßig (oft wöchentlich), bewertet anstehende Changes und gibt sie frei – oder hält sie zurück, wenn Risiken oder Kollisionen zu groß sind.

4) Risikobewertung – die 3×3-Matrix

Jeder RFC wird auf zwei Dimensionen bewertet: Eintrittswahrscheinlichkeit (wie wahrscheinlich geht etwas schief?) und Auswirkung (was passiert, wenn es schiefgeht?). Klick eine Zelle an:

5) Verzahnung mit anderen Practices

6) Wichtige KPIs

• Change Success Rate – Anteil erfolgreich abgeschlossener Changes ohne Backout. Ziel: > 95 %.
• Change-induzierte Incidents – Tickets, die direkt nach einem Change aufgetreten sind. Sollte gering sein und sinken.
• Durchlaufzeit RFC – Wie lange von Antragstellung bis Implementierung? Lange Zeiten frustrieren, sehr kurze sind verdächtig.
• Anteil Emergency Changes – Hoher Anteil = schlechte Planung / mangelhaftes Problem Mgmt.
• Standard-Change-Quote – Anteil vor-genehmigter Changes. Höher = effizienter (weniger CAB-Overhead).
• Backout-Rate – Wie oft musste rückgerollt werden? Hohe Quote = unzureichende Tests vorab.

7) Antipatterns

• Cowboy-Changes. Admin meldet sich auf der Konsole ein und „macht mal eben". Keine Dokumentation, kein Backout-Plan. Beim nächsten Incident sucht alle stundenlang die Ursache. Lösung: kein Zugriff ohne RFC für produktive Systeme.
• CAB-Bürokratiemonster. Jeder Triviafall braucht CAB-Sitzung, einfache Patches dauern 6 Wochen Bürokratie. Lösung: Standard-Changes definieren, Emergency-Pfade.
• Backout-Plan „Wir restoren halt das Backup". Klingt nett, hat aber niemand jemals geübt. Lösung: Backout-Pläne vor dem Change testen.
• RFC mit Wissens-Lücken. Antragsteller weiß selbst nicht, was er ändern will. Lösung: RFC-Template mit Pflichtfeldern; unvollständige RFCs nicht annehmen.
• Genehmigung als Stempel. CAB-Mitglieder nicken alles durch, weil sie überlastet sind. Lösung: weniger Sitzungen, fokussiertere Agenda, klare Pre-Approval-Pfade für triviale Sachen.
• Kein Post-Implementation Review (PIR). Change durchgeführt, niemand prüft, ob es geklappt hat. Lösung: PIR ist Pflicht-Schritt; ohne PIR kein „Closed".

Zusammenfassung

Change Management (in ITIL 4: Change Enablement) kontrolliert alle Änderungen an produktiven IT-Systemen. Antrag: RFC (Request for Change) mit Pflichtfeldern Beschreibung, Impact-Analyse, Risikobewertung, Umsetzungsplan, Test-/Validierungsplan und besonders wichtigem Backout-Plan. Lifecycle: Logged → Assess → Authorize → Plan → Implement → Review (PIR) → Closed; Abzweige nach Rejected/Cancelled/Failed. Genehmigung über das CAB (Change Advisory Board) mit Change Manager, Service-Owner, Tech Leads, Security, Business, ggf. Lieferanten. Für Notfälle: ECAB (Emergency CAB). Risikobewertung: Wahrscheinlichkeit × Auswirkung in einer 3×3-Matrix. Wichtige KPIs: Change Success Rate (> 95 %), Change-induzierte Incidents, Backout-Rate, Anteil Emergency Changes. Tiefe Verzahnung mit CMDB, Incident, Problem, Patch Management, CI/CD. Antipatterns: Cowboy-Changes, Bürokratie-Monster, ungetestete Backout-Pläne, fehlende PIRs.

Verwandte Lektionen: Change-Typen · Problem Management · CMDB · und mehrWeitere relevante LektionenIncident ManagementKEDBPatch-ManagementCI/CDAnsibleSLAFailover