Change Management

ES - EN - Change Management

 

Ziel: ITIL Change Management steuert den Lebenszyklus aller Changes. Change Management 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

 

Prozess-Beschreibung

In ITIL 2011 wurde die Struktur des Change Management Prozesses modifiziert, um zu betonen, dass signifikante Changes an verschiedenen Punkten ihres Lebenszyklus' autorisiert werden müssen.

ITIL Change Management

Das Übersichts-Diagramm zu ITIL Change Management (.JPG) illustriert die wichtigsten Schnittstellen des Prozesses (siehe Abbildung 1).

Neue Teil-Prozesse sind hinzugekommen, die für die Bewertung von Change-Vorschlägen und die Implementierung von Changes mit geringem Risiko (Minor Changes) zuständig sind.

Change Management übermittelt umfassende Changes (Major Changes) nun für eine formale Bewertung an den Prozess Change-Evaluierung.

Ebenfalls überarbeitet wurde die Change-Planung: Für die Detail-Planung eines Changes und des entsprechenden Releases ist jetzt das Release Management zuständig.

ITIL V3 hatte den Begriff der Change-Modelle eingeführt und damit die Notwendigkeit herausgestellt, wie unterschiedliche Change-Typen zu definieren und zu handhaben sind. In ITIL 2011 spielen die Change-Modelle innerhalb von Change Management eine noch größere Rolle. Sie werden nicht nur für Standard-Changes (d.h. Changes mit geringem Risiko auf Betriebsebene), sondern auch für wiederkehrende, signifikante Changes eingesetzt.

 

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

• Kennzahlen (KPIS) zum ITIL Change Management
• Checklisten Change Management:
  • Checkliste Request for Change - RFC, sowie
  • Checkliste Change Record
  • Checkliste Change-Einordnung
  • Checkliste CAB-Agenda
  • Checkliste Forward Schedule of Changes - FSC
  • Checkliste Post Implementation Review - PIR

 

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.

 

Verantwortlichkeits-Matrix: ITIL Change Management
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.

 

Überblick › Prozess-Beschreibung › Teil-Prozesse › Definitionen