Ver-ITIL-t


Update: Service Design + Service Transition

Die Prozessliste des Service Designs wurde mit dem Supplier und dem Application Management vervollständigt. Darüber hinaus können Sie sich in der Service Transition über die Prozesse Transition Planning & Support, Service Asset & Configuration Management sowie das Change Management informieren.

Die Erarbeitung weiterer Prüfungsfragen steht jetzt ganz oben auf der Liste.

Sie haben Fragen, Anregungen oder Kritik? Sie können einen Kommentar hinterlassen oder uns via info@ver-itil-t.de per Mail erreichen.

Weitere interessante Inhalte

Category: News – Stefan –

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 –

BSM als Teil einer ITSM-Suite?

Aus Sicht gängiger Best Practises dürfte das durchaus aufgehen. Für übergreifendes Management erzeugt dieser Ansatz ausgehend vom Service Portfolio über den Service Katalog und damit verbunden dem Business Service hin zu den Prozessen der Transition und Operation, die zwangsläufig mit diesen Daten operieren, deutlichen Mehrwert. Die Ursachen sind vielfältig – in erster Linie ist zumeist die logische Verknüpfung von Business und IT problematisch. Während sich mit analytischen Methoden innerhalb der IT viele Probleme lösen lassen, wird es im Business schnell abstrakt. Auch die Schnittstellenproblematik steht in diesem Zusammenhang im Raum, da Entscheidungsträger nicht unbedingt innerhalb des IT-Departments sitzen.

Kurzum – der Ansatz ist der Verfolgung wert und mit BMC und Novel (die Ihre Lösung gerade vorstellten) sollen beispielhaft zwei Anbieter genannt sein, die diesen verfolgen.

Weitere interessante Inhalte

Category: News – Stefan –

Prozess: Service Asset & Configuration Management

Zielstellung des Asset & Configuration Management

Ziel des Configuration & Asset Managements ist die allumfängliche Information anderer Prozesse und des Managements mit Informationen zur Infrastruktur. Die Bestrebung nach Real-Time-Daten und die Komplexität der Infrastrukturen machen den Einsatz von Tools unumgänglich. Das zentrale Repository ist das CMS, in dem CIs abgelegt werden.


Begrifflichkeiten im Asset & Configuration Management

Das CMS (Configuration Management System) ist die zentrale Ablage aller CIs.

Unter CIs (Configuration Items) versteht man alle Komponenten, die während der Bereitstellung von Services Benutzung finden. Neben dem Bereich Hardware gehören beispielsweise auch Software, Gebäude, Netzwerkkomponenten und virtuelle Umgebungen dazu. Die Auflösung eines Service in seine Bestandteile (CIs) ist eine der Aufgaben, die in Echtzeit möglich sein sollte.

Unter dem Begriff CMDB (Configuration Management Database) versteht ITILv3 eine physikalische Ablage. Das CMS kann unter bestimmten Anforderungen auch mehrere CMDBs enthalten.

Neben den CMDBs sind im CMS noch weitere Repositories enthalten, die beispielsweise funktions- oder unternehmensbezogen befüllt werden. Auch die DML (Definitive Media Library) gehört zum CMS und damit in die Zuständigkeit des Asset & Configuration Managements.

Grundsätze des Asset & Configuration Management

Ein wesentlicher Grundsatz ist die Automatisierung. Kaum eine Infrastrukturlandschaft kann heute noch händisch dokumentiert werden. Die Ursachen dafür sind vielschichtig – an der Stelle sei nur der Trend zur Virtualisierung genannt, der zu einer vorher nicht gekannten Dynamik geführt hat.

Eine wesentliche Herausforderung für die Modellierung und Befüllung des CMS ist die Abstraktionstiefe. Je mehr Details abgebildet werden müssen, desto höher wird der Aufwand für die Pflege – je geringer der Datenbestand, desto eingeschränkter ist die Nutzung des CMS möglich. Es gilt, einen praktikablen Kompromiss zu finden, was sich in der Praxis vor allem beim Start eines solchen Vorhabens als schwierig herausstellen kann.

Die Bildung eines hierarchichen Bildes der Infrastruktur wird ausdrücklich empfohlen. Für das Reporting anderer Prozesse (zum Beispiel Uptimes von Services, …) ist das Etablieren von Parent-Child-Beziehungen obligatorisch. Die “Trivialform” sieht folgende Hierarchie vor:

Business Service -> Technical Service -> Komponenten CIs

Für die Pflege des Status könnte folgende Systematik zum Einsatz kommen:

planned -> ordered ->tested -> implemented -> working ->archieved

Auch für die Stati kann nur eine Hilfestellung gegeben werden – in Abhängigkeit der Anforderungen zur Information können mitunter noch mehr oder auch deutlich weniger Stati notwendig sein.

Weitere interessante Inhalte

Prozess: Transition Planning & Support

Zielstellung: Transition Planning & Support

Der Prozess Transition Planning & Support plant und unterstützt die Überführung des im Service Design entstandenen Service Design Package in die Produktion. Neben einem effektiven Projektmanagement – v.A. der Planung von Ressourcen für die Überführung – gehören auch Reportingtätigkeiten in diese Zuständigkeit. Es wird sichergestellt, dass alle Beteiligten die Standards in Prozessfragen einhalten.


Grundsätze: Transition Planning & Support

Die Klärung der Ressourcen über den gesamten Transition-Prozess sollte unter Einhaltung der Normen zum Projektmanagement durchgeführt werden. Speziell für Zuständigkeiten empfiehlt die ITIL das RACI-Modell. In einer Matrix werden Prozesse und Personen aufgetragen, denen die Attribute responsible, accountible, consulting und informed zugeordnet werden. Die Auflösung dieser Matrix erfolgt nach den im Artikel “RACI-Modell” beschriebenen Regeln, so dass u.A. nur eine Person pro Prozess responsible (verantwortlich) ist. Diese Methodik vermeidet Kompetenzstreitigkeiten und sorgt für einen klar definierten Workflow. Der Prozess Transition Planning & Support kann als Querschnittsprozess verstanden werden.

Weitere interessante Inhalte

Category: Transition Planning and Support – Stefan –
!-- Piwik -->