Ziele und Zweck des Change Management

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.

Termingerechte, risikominimierte und wirtschaftliche Umsetzung von Changes

• Steuern aller Changes über ihren gesamten Lebenszyklus, damit nutzbringende Changes mit minimalen Auswirkungen auf das Business und die IT Services überführt werden können

• Antworten auf Änderungsanforderungen von Business und IT

• Maximierung der Wertschöpfung

• Minimierung von Incidents

• Sicherstellung der korrekten Erfassung, Bewertung, Entscheidung aller Änderungsanfragen

• Planung, Test, Implementierung, Dokumentation und Review aller Changes sicherstellen

• Sicherstellen, dass das CMS aktuell ist

• Optimieren des Risikos für das Business

Prozess Change Management

Open

Teilprozesse des Change Management

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.

Prozessvorschlag Change Management

Open

Change Management Prozess

Basiskonzepte Change Management

Service Change

• Hinzufügen, Verändern oder Entfernen Services oder Servicekomponenten und der dazugehörigen Dokumentationen

• Fokus auf Service Assets und Configuration Items

Change-Kategorien

• Die Kategorisierung von Changes soll helfen, das richtige Mass an Bürokratie auf das Risiko Management von Changes anzuwenden

• Die Priorität eines Changes wird anhand der Kombination von Auswirkung (Impact) und Dringlichkeit (Urgency) bestimmt und liefert ein Indiz dafür, mit welcher Geschwindigkeit und Gewichtung ein Change durchzuführen ist

Risikoanalyse

Risikostufen/Risikoklassen ermöglichen eine Bewertung und Beurteilung von Changes bezüglich deren Auswirkung auf den IT Service

7 R's des Change Management

• RAISE - Wer hat den Change eingereicht?

• REASON - Was ist der Grund für den Change?

• RETURN - Welchen Ertrag soll der Change bringen?

• RIKS - Welche Risiken birgt der Change?

• RESOURCES - Welche Ressourcen sind für die Durchführung des Changes erforderlich?

• RESPONSIBLE - Wer ist für Build, Testen und Implementierung des Changes verantwortlich?

• RELASTIONSHIP - Welche Beziehung besteht zwischen diesem Change und anderen Changes?

Change Kategorien

Standard-Change (vorab autorisiert)

• Standardisierbare Änderungen, die häufig auftreten, ein geringes Risiko aufweisen und deren Auswirkungen definiert sind

• Durchführung erfolgt nach einem vereinfachten Prozessablauf

• Sind praktisch vorab genehmigt, sofern sie in der vorgegebenen Prozedur durchgeführt werden

Normaler Change

• Änderungen mit einer entsprechenden Komplexität

• Übergreifende Koordination und Freigabeprozedur mit eventueller Einbindung des CAB notwendig

Notfall-Change

• Änderungen, die kurzfristig und mit höchster Dringlichkeit notwendig sind

• Die Durchführung erfolgt auf Basis klarer und kurzer Prozessstufen

Change Authority

Zusammenspiel Change Management, Service Asset und Configuration Management

Umfang des Change Management

KPI des IT-Change Management

Wichtige Rollen

Change Manager

• Verantwortlich für den täglichen Betrieb und die Einhaltung des Change Management-Prozesses

• Sicherstellung, dass der Prozess und die Prozessaktivitäten überwacht werden und dass Verbesserungen/Aktualisierungen vorgenommen werden

• Regelmässige Reviews des Change Management-Prozesses

• Regelmässiges und präzises Reporting an das IT-Management und den Vorsitz

• Zusammensetzung und Koordination der CAB- und ECAB-Meetings

• Im Rahmen der Change Authority kann er die Kompetenz erhalten, Changes zu autorisieren

Change Advisory Board (CAB)

• Gremium, das den Change Manager bei der Genehmigung der Changes einer hohen Kategorie unterstützt

• Der Change Manager hat den Vorsitz des CAB

• Die Zusammensetzung des Boards kann sich aufgrund der anliegenden Changes ändern

Emergency Change Advisory Board (ECAB)

• Änderungsbeirat, der sicherstellt, dass kurzfristig notwendige Entscheidungen bezogen auf vorgeschlagene Änderungen getroffen und umgesetzt werden können

• Ziel ist, die Kontrolle über Änderungen auch im Notfall aufrechtzuerhalten und auch hier die negativen Auswirkungen auf den produktiven Betrieb so gering wie möglich zu halten

Definitionen

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.