ITIL-Change-Workflows etablieren

Das Change Advisory Board ist das Herzstück des Change-Managements. Es bewertet geplante Changes, identifiziert Risiken und gibt Freigaben – oder verweigert sie mit Begründung. Wir bauen ein CAB von Anfang bis Ende auf: definieren die Zusammensetzung (IT-Betrieb, Fachbereiche, Sicherheit), etablieren ein Meetingrhythmus, legen Entscheidungskriterien fest und bilden den gesamten Prozess im ITSM-Tool ab. Besonders wichtig ist dabei die Einbindung der Fachbereiche – Change-Management ist keine reine IT-Angelegenheit.

Jeder Normal Change muss einen Rollback-Plan haben. Das klingt selbstverständlich – ist es in der Praxis aber oft nicht. Die Etablierung umfasst die Rollback-Planung als festen Bestandteil des Change-Antragsformulars: Was passiert, wenn der Change fehlschlägt? Wie wird der ursprüngliche Zustand wiederhergestellt? Wer ist verantwortlich? Diese Fragen müssen beantwortet sein, bevor ein Change genehmigt wird – nicht danach.

Change-Workflows müssen im ITSM-Tool vollständig abgebildet sein: von der Antragsstellung über die Risikobewertung und CAB-Genehmigung bis zur Implementierung und dem Post-Implementation-Review. Die Konfiguration umfasst Change-Workflows so, dass sie den definierten Prozess erzwingen – ohne unnötige Hürden für die Anwender. Automatisierte Benachrichtigungen, klare Statusübergänge und eine vollständige Audit-Trail-Dokumentation sind dabei Standard.

Ein häufiges Missverständnis: Change-Management und agile Entwicklung schließen sich aus. Das stimmt nicht. Es liegen Change-Prozesse gestaltet, die mit agilen Entwicklungszyklen kompatibel sind – durch klare Klassifizierung von Deployment-Changes, automatisierte Standard-Change-Genehmigungen und eine enge Verzahnung mit dem Release Management.

Standard Changes sind wiederkehrend, niedrig-riskant, vollständig dokumentiert, getestet und mit klaren Preconditions versehen. Die Liste wird regelmäßig überprüft und angepasst.

Durch klaren Scope, definierte Rollen, Entscheidungskriterien, festen Takt, Vorab-Readouts und Tool-gestützte Entscheidungsdokumentation. Nur CAB-pflichtige Changes werden diskutiert.

Durch konsequente Standardisierung wiederkehrender Changes, klare Klassifizierung, Automatisierung in Tool-Workflows und schlanke Entscheidungslogik für Normal Changes.

Rollback reduziert Ausfallrisiken und verkürzt Wiederherstellungszeiten. Er stellt sicher, dass Fehlerfälle vor Implementierung eingeplant und operativ beherrschbar sind.

Über KPIs wie Change Success Rate, Change-related Incidents, Throughput, Lead Time, Rework-Quote und PIR-Ergebnisse. Ziel ist Stabilität bei angemessener Geschwindigkeit.

Über Workflow-Status, Pflichtfelder wie Risiko, Impact, Test und Rollback, Genehmigungsstufen, CAB-Entscheidungen, automatisierte Benachrichtigungen und vollständigen Audit Trail.

Durch definierten eCAB-Prozess, Mindestdokumentation, nachgelagerte PIR-Pflicht und klare Kriterien, wann ein Emergency Change zulässig ist.

Durch Verknüpfung mit CIs/Services aus der CMDB, Kalender-/Scheduling-Regeln und die Darstellung konkurrierender Changes im Tool (Change Calendar).

Über transparente Impact-Kommunikation, nachvollziehbare Freigabeentscheidungen und Beteiligung relevanter Fachvertreter im CAB bei fachlich kritischen Changes.

Unklare Klassifizierung, fehlende Tests, unzureichende Rollback-Planung, fehlendes Scheduling, sowie Umsetzungen außerhalb definierter Wartungsfenster.