Ver-ITIL-t


Prozess: Change Management

Zielstellung des Change Management

Als einer der wichtigsten Prozesse der ITIL stellt das Change Management die Plattform für alle Veränderungen an der IT Infrastruktur zur Verfügung. Vor dem Hintergrund, dass durchgeführte Änderungen (Changes) häufig zu Fehlfunktionen führen und sich im Incident Management ohne konsistente Dokumentation der durchgeführten Changes oft eine aufwändige Fehlersuche anschließt, birgt der Prozess drastische Potenziale. Der Trigger für das Change Management ist grundsätzlich ein Request for Change (RfC). RfC’s entstehen in anderen Prozessen – beispielsweise im Problem Management oder als Folge von Service Design Aktivitäten. Sie enthalten:

  • das Objekt, welches verändert werden soll oder die gewünschte Auswirkung der Änderung
  • den Antragsteller
  • einen Terminvorschlag
  • eine Priorität
  • einen Implementierungs- und Fallbackplan.


Der Request Fulfillment Prozess (Teil des Bandes Service Operation) behandelt den Umgang mit standardisierten Kundenanforderungen mit immer wiederkehrenden und automatisierbaren Genehmigungs- und Freigaberegeln. Für diese Trivialfälle gilt ein deutlich vereinfachter Workflow, der im Change Management nicht beschrieben ist.

Grundsatz: CAB und ECAB

RfCs müssen genehmigt werden. Dafür stehen mit dem Change Advisory Board (CAB) und dem Emergency Change Advisory Board (ECAB) zwei Institutionen zur Verfügung. Dieses Vorgehen verhindert die Durchführung von Veränderungen, die weder dokumentiert noch bekannt sind und somit zu unnötigen Aufwänden im Service Desk führen. Das Change Advisory Board bündelt alle beteiligten Rollen. Ihm sollten folgende Rollen angehören:

  • Change Manager
  • Service Desk
  • Service Level Manager
  • Administratoren
  • Configuration Manager
  • Benutzer
  • Lieferanten
  • Kunde
  • Application Manager
  • Consultants

Der Change Manager ist Vorsitzender des CAB. Ihm obliegt die Verantwortung für alle Changes – er priorisiert, selektiert und plant die Veränderungen. Für die Freigabe von Changes benennt die ITIL die Change Authority, die von Fall zu Fall verschieden sein kann. Ihr können grundsätzlich alle Rollen angehören, wobei eine Gefahr in der Überbürokratisierung des Prozess besteht. Für die Change Authority gilt der Grundsatz “soviele Rollen wie nötig“. Im ECAB werden Changes mit hoher Dringlichkeit auf Kundenwunsch und damit unter Einbezug des Kunden in die Verantwortung unter Abkürzung des Prozess behandelt. In Frage können RfCs kommen, die aus dem Incident- und Problemmanagement resultieren und deren Verzögerung sich kritisch – mindestens jedoch negativ - auf den Geschäftsprozess des Kunden auswirken.

Topics des CAB

Folgende Themen sollten im Rahmen des CAB behandelt werden:

  • anstehende Changes
  • gestellte RfCs
  • fehlgeschlagene Changes
  • durchgeführte Emergency Changes
  • nicht genehmigte Changes

Arten von Changes

  • Normal Changes
    ziehen Änderungen an einem / mehreren CIs nach sich und durchlaufen den Standard-Change-Prozess.
  • Standard Changes
    besitzen einen standardisierten Arbeitsablauf und können gekürzt bearbeitet werden (beispielsweise da sie schon mehrfach durchlaufen wurden).
  • Emergency Changes
    besitzen eine besondere Dringlichkeit, durchlaufen einen abgekürzten Workflow (ECAB) und müssen nach Abschluss gereviewed werden.

Priorisierung im Change Management

Ein wesentliches Erfolgskriterium für den IT-Betrieb ist die Priorisierung – für das Change Management als “Tor zum Produktiveinsatz” gilt dies insbesondere. Folgende Abstufungen können Verwendung finden:

  1. Highest
    RfCs, deren Durchführung die Beseitigung von Beeinträchtigungen von Kundenprozessen zur Folge hat. Der Workflow wird unter Nutzung des ECAB durchgeführt.
  2. High
    RfCs, deren Durchführung die Beseitigung einer schwerwiegenden Störung verfolgt.
  3. Normal
    Die Durchführung ist nicht kritisch für den Kundenprozess, so dass der Zeitpunkt eine untergeordnete Rolle spielt.
  4. Low
    Der RfC verfolgt einen Anwenderwunsch.

Dokumentationsrichtlinie: 7R’s

Die 7R’s können als Dokumentationsrichtlinie für RfCs verstanden werden. Sie beinhalten:

  • Raised
    Wer stellt den RfC?
  • Reason
    Warum?
  • Return
    Was ist das gewünschte Ergebnis?
  • Risks
    Welche Risiken sind bekannt?
  • Ressources
    Welche Ressourcen werden beansprucht?
  • Responsibility
    Wer ist verantwortlich?
  • Relationship
    Existieren Beziehungen zu weiteren Changes?

Weitere interessante Inhalte

Category: Change Management – Stefan –
!-- Piwik -->