Change Management
Ziel: ITIL Change Management steuert den Lebenszyklus aller Changes. Dieser Prozess hat das vorrangige Ziel, nutzbringende Changes zu ermöglichen und dabei negative Auswirkungen auf die IT-Services zu vermeiden.
Deutsche Bezeichnung: Change Management
Teil von: Service Transition (Serviceüberführung)
Prozess-Verantwortlicher: Change Manager
ITIL 4 Change Management - Change Enablement
Der hier beschriebene Change-Management-Prozess folgt den Spezifikationen von ITIL V3, wo Change Management (Abb. 1) als Prozess in der Service-Überführung (Service Transition, der vierten Phase im ITIL-Service-Lifecycle) definiert ist.
ITIL V4 gibt keine bestimmten Prozesse mehr vor sondern führt 34 Praktiken ("Practices") ein. Damit sind Organisationen freier bei der Definition maßgeschneiderter Prozesse.
Unter der neuen Bezeichnung "Change Enablement" wird Change Management in ITIL 4 somit als Service-Management-Praktik aufgeführt. ITIL 4 beschreibt die grundlegenden Aktivitäten im Change Enablement sowie die wichtigsten Inputs, Outputs und Rollen. Organisationen sollen auf Basis dieser Leitlinien einen detaillierten Prozess für das Managen von Changes festlegen, der ihren individuellen Anforderungen entspricht.
Hinweis: Die Practice Change Enablement wurde in früheren ITIL 4-Publikationen zunächst als "Change Control" bezeichnet und später in "Change Enablement" umbenannt.
Nachdem die in ITIL V3 definierten Prozesse mit der Einführung von ITIL V4 nicht ihre Gültigkeit verloren haben, können Organisationen den Change-Management-Prozess aus ITIL V3 nach wie vor als Vorlage verwenden.
In unserem YaSM Service-Management-Wiki beschreiben wir ein schlankeres Modell mit 19 Service-Management-Prozessen, das gut zu ITIL 4 passt, wo einfache und praktikable Lösungen bevorzugt werden.
Im YaSM-Prozessmodell ist ein Change-Management-Prozess enthalten, der eine gute Ausgangsbasis für Organisationen darstellt, die ITIL 4 einführen möchten.
Prozess-Beschreibung
Im Change Management geht es darum, die mit Änderungen einhergehenden Risiken zu minimieren. ITIL definiert einen Change in diesem Zusammenhang als "das Hinzufügen, Entfernen oder Modifizieren von allem, was sich auf die IT-Services auswirken könnte". Hierzu gehören z. B. Änderungen an der IT-Infrastruktur oder auch an Prozessen, Dokumenten, Schnittstellen mit Lieferanten und Dienstleistern etc.
ITIL unterscheidet zwischen drei unterschiedlichen Arten von Changes:
- Standard-Changes: Vorautorisierte Änderungen mit geringem Risiko, die einer erprobten Prozedur folgen.
- Notfall-Changes (Emergency Changes): Änderungen, die sofort implementiert werden müssen, zum Beispiel um einen Major Incident zu beheben.
- Normale Changes: Alle Änderungen, die keine Standard-Changes oder Notfall-Changes darstellen.
Normale Changes werden in Abhängigkeit vom Risiko-Grad oft weiter kategorisiert als Major Changes, Significant Changes oder Minor Changes. Organisationen sollten diese Change-Typen und die erforderlichen Autorisierungsebenen in ihrer Change-Richtlinie definieren. Zum Beispiel könnten Major Changes ein vollständiges Review durch das CAB (Change Advisory Board) erfordern, während Significant Changes durch den Change Manager freigegeben werden können.
Wenn ein Nicht-Standard-Change notwendig ist, wird der für den Change Verantwortliche in der Regel einen Request for Change (RFC) beim Change Management einreichen. Das Change Management ist dann dafür zuständig, den Change zu registrieren, zu analysieren und freizugeben (bzw. zurückzuweisen).
Notfall-Changes werden vom ECAB (Emergency Change Advisory Board) begutachtet und autorisiert. Das ECAB besteht aus Kernmitgliedern des CAB und ist jederzeit auf Abruf verfügbar, um auf Notfälle reagieren zu können.
Für bestimmte Arten von Änderungen wird eine formale Evaluierung durch den Prozess Change-Evaluierung durchgeführt und ein einem Change-Evaluierungsbericht dokumentiert.
Organisationen sollten das Change Management schlank halten und unnötige Bürokratie vermeiden, indem der vollständige Change-Management-Prozess nur für relativ wenige, signifikante Changes angewendet wird. Die Effektivität und Wirksamkeit des Change Managements kann zum Beispiel durch die folgenden Maßnahmen gesteigert werden:
- Erstellen von Change-Modellen für wiederkehrende Änderungen,
- Dezentralisierung der Change-Freigabe für Standard-Changes,
- Aufteilung größerer Änderungen in mehrere kleinere Changes mit geringerem Risiko,
- Automatisierung bestimmter Checks, Tests und Deployments.
Change Management verfügt über eine Reihe von Schnittstellen mit anderen ITIL-Prozessen:
- Der Service-Strategie-Prozess unterbreitet Change-Vorschläge (Change Proposals), damit das Change Management sich abzeichnende strategische Änderungen hinsichtlich der Auswirkungen auf andere Services, Ressourcen etc. bewerten kann.
- Verschiedene andere ITIL-Prozesse reichen RFCs beim Change Management ein, wenn Änderungen erforderlich werden. Zum Beispiel müssen im Problem und Incident Management häufig Changes implementiert werden, um Problems bzw. Incidents zu lösen. Vom Service Design werden typischer Weise RFCs eingereicht, wenn es darum geht, neue Services einzurichten oder bestehende Services zu erweitern. Im Zuge von Service Improvement können Changes notwendig werden, um Services zu verbessern.
- Configuration Management stellt wichtige Informationen zur Verfügung, um vorgeschlagene Changes und deren Auswirkungen auf andere Configuration Items zu bewerten. Das Configuration Management erhält vom Change Management aktualisierte Konfigurationsdaten.
- Change-Evaluierung wird vom Change Management angestoßen, falls ein Change eine formale Evaluierung erfordert.
Das Übersichts-Diagramm zu ITIL Change Management (Abb. 1) illustriert die wichtigsten Schnittstellen des Prozesses.
In ITIL 4 wird "Change Enablement" als Service-Management-Praktik aufgeführt (s. o.).
Teil-Prozesse
ITIL Change Management umfasst die folgenden Teil-Prozesse:
Change Management Support
- Prozessziel: Bereitstellen von Vorlagen und Leitlinien zur Autorisierung von Changes sowie Bereitstellen von Informationen zu geplanten und laufenden Changes für die anderen IT-Service-Management-Prozesse.
Bewertung von Change-Vorschlägen
- Prozessziel: Bewertung von Change-Vorschlägen, die typischerweise vom Service-Strategie-Prozess für bedeutende Changes eingereicht werden. Das Ziel ist, Change-Vorschläge auf potentielle Probleme zu untersuchen, bevor die Design-Aktivitäten beginnen.
RFC-Erfassung und Review
- Prozessziel: Herausfiltern von Requests for Change (RFC), die nicht alle erforderlichen Informationen für eine Bewertung enthalten oder für nicht machbar erachtet werden.
Bewertung und Implementierung von Notfall-Changes
- Prozessziel: Schnellstmögliches Bewerten, Freigeben und Implementieren eines Notfall-bedingten Changes. Dieser Prozess wird initiiert, wenn normale Change-Management-Abläufe nicht angewandt werden können, da ein Notfall unmittelbare Maßnahmen erfordert.
Change-Bewertung durch den Change Manager
- Prozessziel: Bestimmen der zutreffenden Autorisierungs-Ebene für die Bewertung einen vorgeschlagenen Changes. Bedeutende Changes werden an das CAB weitergeleitet, während weniger bedeutende Changes unmittelbar vom Change Manager bewertet und freigegeben werden.
Change-Bewertung durch das CAB
- Prozessziel: Bewerten eines vorgeschlagenen Changes und Autorisieren der Change-Planungs-Phase. Falls erforderlich, werden höhere Genehmigungs-Ebenen in den Freigabe-Prozess mit einbezogen (z.B. das IT-Management).
Change-Planung und Freigabe der Build-Phase
- Prozessziel: Autorisierung der detaillierten Change- bzw. Release-Planung und Bewertung des daraus resultierenden Projektplans vor der Freigabe der Change-Build-Phase.
Freigabe der Change-Deployment-Phase
- Prozessziel: Prüfen, ob alle erforderlichen Komponenten für den Change erstellt und ausreichend getestet wurden. Im Falle eines positiven Ergebnisses erfolgt die Freigabe der Change-Deployment-Phase.
Implementierung von Minor Changes
- Prozessziel: Implementierung von Changes mit geringem Risiko und gut vorhersehbaren Auswirkungen, die nicht die Einbeziehung des Release Managements erfordern.
Post Implementation Review und Change-Abschluss
- Prozessziel: Bewerten des Verlaufs der Change-Implementierung und der erreichten Ergebnisse, um sicherzustellen, dass eine komplette Historie aller Aktivitäten aufgezeichnet wurde; Vergewissern, ob alle Fehler analysiert und die für die Zukunft wichtigen Erfahrungen dokumentiert worden sind.
Definitionen
Die folgenden ITIL-Begriffe und Acronyme (Informations-Objekte) werden in ITIL Change Management zur Darstellung der Prozess-Outputs und -Inputs verwendet:
Bericht zur Change-Evaluierung
- Bestimmte Arten von umfangreichen Changes, wie z.B. die Einführung eines neuen Service oder bedeutende Änderungen an einem bestehenden Service, erfordern formale Change-Evaluierungen, bevor Sie freigegeben werden können. Die Ergebnisse einer Change-Evaluierung werden in einem entsprechenden Bericht dokumentiert. Change-Evaluierungen können an unterschiedlichen Punkten im Lebenszyklus eines Changes durchgeführt werden, z.B. vor der Freigabe der Change/Release-Build-Phase oder während des Post Implementation Reviews.
Change
- Hinzufügen, Modifizieren oder Entfernen eines Elements, das Auswirkungen auf die IT Services haben könnte. Der Umfang sollte Changes an allen Architekturen, Prozessen, Tools, Messgrößen und Dokumentationen genauso einschließen, wie Changes an IT Services und anderen Configuration Items.
Change-Management-Richtlinie
- Die Entscheidung, ob ein vorgeschlagener Change autorisiert oder abgewiesen wird, basiert auf einer abgeschlossenen Change-Bewertung. Die Change-Bewertung hat insbesondere das Ziel, die mit der Implementierung des Changes verbundenen Risiken zu verstehen. In diesem Zusammenhang definiert die Change-Management-Richtlinie die Autorisierungs-Ebenen, die zur Freigabe bestimmter Arten von Changes zuständig sind, sowie weitere Regeln für die Bewertung von Changes.
Change-Modell
- Change-Modelle beschreiben Verfahren zum Umgang mit wiederkehrenden Standard-Changes. Change-Modelle können für Changes jeder Tragweite erstellt werden; oft werden Sie zur Definition von Standard-Changes eingesetzt (vorab freigegebene Changes mit geringem Risiko, wie zum Beispiel die Aufrüstung eines Client-PCs).
Change Record
- Im Change Record sind alle Einzelheiten eines Changes enthalten; er dokumentiert somit den Lebenszyklus eines einzelnen Changes. Ein Change Record wird zumeist aus einem vorausgehenden Request for Change (RFC) erstellt.
Change Schedule
- In der Change Schedule sind alle genehmigten Change-Vorschläge und Changes mit den geplanten Implementierungsterminen aufgeführt. Die Change Schedule wird manchmal auch als Forward Schedule of Change (FSC, Zeitplan künftiger Changes) bezeichnet, auch wenn sie Informationen zu bereits implementierten Changes enthält.
Change-Vorschlag
- Ein Change-Vorschlag beschreibt einen vorgeschlagenen größeren Change, wie z.B. die Einführung eines neuen Service oder umfangreiche Änderungen an einem bestehenden Service. Der Zweck von Change-Vorschlägen ist die Kommunikation eines vorgeschlagenen größeren Changes, so dass dessen Risiko, Auswirkung und Machbarkeit beurteilt werden kann, bevor die Design-Aktivitäten beginnen. Change-Vorschläge werden typischerweise vom Service Portfolio Management erstellt.
Notfall-Change (Emergency Change)
- Ein Change, der so bald wie möglich eingeführt werden muss, beispielsweise um einen Major Incident zu lösen oder ein Sicherheits-Patch zu installieren.
Projected Service Outage (PSO)
- Im Dokument zu voraussichtlichen Serviceunterbrechungen (Projected Service Outage, PSO) sind erwartete bzw. geplante Abweichungen von der in den SLAs vereinbarten Serviceverfügbarkeit aufgeführt.
Request for Change (RFC)
- Der RFC ist ein formeller Antrag zur Durchführung eines Changes. Für jeden Nicht-Standard-Change muss ein Request for Change beim Change Management eingereicht werden (siehe auch: ITIL-Checkliste Request for Change - RFC)
RFC-Template
- Ein Template für die formale Beantragung eines Changes. Ein RFC enthält die Details zum vorgeschlagenen Change; er kann in Papierform oder elektronisch erstellt werden.
Vorlage CAB-Agenda
- In der CAB-Agenda sind die Themen aufgelistet, die in einem Meeting des CABs zur Diskussion anstehen.
KPIs | Checklisten
Rollen | Verantwortlichkeiten
Change Manager - Prozess-Verantwortlicher
- Der Change Manager autorisiert und dokumentiert sämtliche Änderungen an der IT-Infrastruktur und ihrer Komponenten (Configuration Items), um störende Auswirkungen auf den laufenden Betrieb so gering wie möglich zu halten. Bei weitreichenden Veränderungen bindet er das Change Advisory Board (CAB) bzw. das IT Management mit ein.
Change Advisory Board (CAB)
- Eine Gruppe von Personen, die den Change Manager hinsichtlich der Bewertung, Priorisierung und Terminplanung von Changes beraten. Dieses Gremium wird normaler Weise aus Vertretern aller Bereiche des Service Providers, der Unternehmensseite und den Drittparteien, z.B. den Suppliern gebildet.
Emergency Change Advisory Board (ECAB)
- Eine Teilgruppe des Change Advisory Boards, die Entscheidungen zu Notfall-Changes mit erheblichen Auswirkungen trifft. Die Zusammensetzung des ECAB kann zum Zeitpunkt der Einberufung des Meetings festgelegt werden; sie hängt von der Art des zu behandelnden Notfall-Changes ab.
| ITIL-Rolle / Teil-Prozess | Change Manager | Change Advisory Board (CAB) | Emergency Change Advisory Board (ECAB) | IT Operator[3] | Andere beteiligte Rollen |
|---|---|---|---|---|---|
| Change Management Support | A[1]R[2] | R[4] | - | - | - |
| Bewertung von Change-Vorschlägen | AR | R | - | - | - |
| RFC-Erfassung und Review | AR | - | - | - | - |
| Bewertung und Implementierung von Notfall-Changes | AR | - | R | R | R[5] |
| Change-Bewertung durch den Change Manager | AR | - | - | - | R[6] |
| Change-Bewertung durch das CAB | AR | R | - | - | R[6] |
| Change-Planung und Freigabe der Build-Phase | AR | R | - | - | - |
| Freigabe der Change-Deployment-Phase | AR | R | - | - | - |
| Implementierung von Minor Changes | AR | - | - | R | - |
| Post Implementation Review und Change-Abschluss | AR | - | - | - | - |
Erläuterungen
[1] A: Accountablei.S.d. RACI-Modells: Verantwortlich dafür, dass ITIL Change Management als Gesamt-Prozess korrekt und vollständig ausgeführt wird.
[2] R: Responsible i.S.d. RACI-Modells: Verantwortlich für die Ausführung bestimmter Aufgaben in Change Management.
[3] siehe → Rollen-Beschreibungen
[4] Die in diesem Prozess erstellten oder gepflegten Dokumente sind vom CAB freizugeben.
[5] Anwendungssystem-Analytiker, Technischer Analytiker (und andere, je nach Erfordernis)
[6] Configuration Manager, Anwendungssystem-Analytiker, Technischer Analytiker (und andere, je nach Erfordernis).
Screenshots zum Change Management
Die Screenshots zur ITIL-Prozesslandkarte zeigen Inhalte des ITIL-Prozessmodells von IT Process Maps; sie enthalten u.a. Informationen zu den ITIL-Prozessen Service Transition und Change Management, wie z.B.
- Übersicht über ITIL Service Transition (Detailebene 1)
- Übersicht über den Prozess ITIL Change Management (Detailebene 2)
- Detaillierte Aktivitäten im Teil-Prozess "Bewertung von Change-Vorschlägen" (Detailebene 3)
Anmerkungen
Von: Stefan Kempter 
, IT Process Maps.
ITIL 4 Change Management - Change Enablement › Prozess-Beschreibung › Teil-Prozesse › Definitionen
