Überprüft

ITIL V3 Service Transition

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Dieser Artikel beschäftigt sich mit der Service Transition. Sie ist ein Bestandteil des Service-Lifecycles des ITIL-Frameworks in Version 3.

Die Service Transition beschreibt den Prozess der Überführung von IT-Servicekomponenten, z. B. Softwarebestandteile, in den operativen Betrieb. Sie besteht aus mehreren Bausteinen, die während der Service-Transition-Phase ineinandergreifen und zum Ziel haben, neue oder geänderte Services oder Servicekomponenten einer Softwareanwendung zur Verfügung zu stellen. Ebenso wird die Service Transition angewendet, um veraltete oder obsolete Bestandteile einer Softwareanwendung zu deaktivieren oder zu entfernen. Ziel der Service Transition ist immer die operative Bereitstellung neuer oder geänderter IT-Services, die über das Change Management erstellt wurden.

Transition Planning and Support

[Bearbeiten | Quelltext bearbeiten]

Vorbereitung aller Aktivitäten der Transition-Phase. Planung und Koordination der Ressourcen, um die in Service Design erstellten Pakete zu realisieren.

Change Management

[Bearbeiten | Quelltext bearbeiten]

Das Change Management steuert sämtliche Veränderungen der IT. Dazu werden alle Änderungen an der IT-Infrastruktur, den beteiligten Prozessen und ihrer Komponenten, den Configuration Items (CIs) beantragt, klassifiziert, autorisiert und dokumentiert. Größere Veränderungen mit erhöhtem Risiko bedingen neben einer komplexeren Genehmigung auch eine entsprechende Planung. Damit soll ein Risiko für die laufende Prozesslandschaft so gering wie möglich gehalten werden. Diese Planungen beinhalten neben einer Risiko-Analyse und Genehmigungs-Verfahren auch entsprechende Planungs-, Aufbau-, Test- und Implementierungs-Meilensteine. Die Reihenfolge der einzelnen Schritte wird geplant und kommuniziert. Eventuelle Überschneidungen mit weiteren Änderungen evaluiert und bei Bedarf konsolidiert. Dem Change Manager und dessen Mitarbeitern obliegt die Koordination der Durchführung sowie die Abnahme der erfolgten Änderungen. Für dringliche Änderungen im Notfall gibt es ein spezifisches Verfahren, den sogenannten Emergency Change.

Bei weitreichenden Veränderungen mit erhöhtem Risiko, den sogenannten „Major Changes“ spielt neben dem Change Manager das Change Advisory Board (CAB) als die genehmigende Instanz eine wichtige Rolle. Bei sehr großen Veränderungen den sogenannten „Significant Changes“ ist für die Genehmigung und Risiko-Evaluierung das Management Board (MB) beteiligt, welches auf Ebene der Geschäftsführung an der Umsetzung von Veränderungen mit hohem Impakt auf die IT gesteuerten Prozesse so ebenfalls entscheidend beteiligt ist. Diese Art von schwierigen Change Prozessen erfordert nach Abschluss eine individuelle Effizienzanalyse, den sogenannten „Post Implementation Review“ (PIR). Dabei wird sowohl die umgesetzte Veränderung als auch der angewandte Prozess auf Zielerreichung überprüft.

Service Asset and Configuration-Management

[Bearbeiten | Quelltext bearbeiten]

Die für das IT-Service-Management notwendigen Informationen werden vom Configuration-Management bereitgestellt. Die Aktualität der Informationen wird überwacht. Dem Configuration-Management fällt damit eine zentrale Rolle im kommunikativen und informativen Zusammenspiel der einzelnen Prozesse zu. Somit sind ständig aktuelle und historische Informationen über die Configuration Items (CI) in der Configuration Management Database (CMDB) verfügbar.

Release and Deployment Management

[Bearbeiten | Quelltext bearbeiten]

Das Release Management verantwortet die Freigabe neuer Hard- und Software anhand der gültigen Release-Richtlinien. Auch die Planung und Bereitstellung des Rolloutverfahrens für freigegebene Soft- und Hardware fällt in seine Zuständigkeit. Ferner fallen unter die Verantwortung des Release-Managements die „definitive Software Library“ (DSL) und der „definitive Hardware Store“ (DHS) bisher unter ITIL V2. Nach dem neuen ITIL V3 Standard sind beide Bibliotheken als Definitive Media Library (DML) zusammengefasst. Verträge mit externen Lieferanten etc., werden als „Underpinning Contracts“ (UC) ausgelagert.

Das Deployment (Verteilung) ist ein temporär aktiver Prozess und beinhaltet Projektverwaltungsverfahren zur Einführung neuer Hard- und Software. In dieser Funktion bildet Deployment das Bindeglied über Development, Change Management, Operations und Technical Support. Es steuert über diese Management-Bereiche hinweg die Entwicklung und Überführung neuer oder erweiterter Hard- und Software Releases in die Produktion. Dieser Prozess kommt damit typischerweise im Rahmen von Änderungs- oder Einführungsprojekten zur Ausführung.

Service Validation and Testing

[Bearbeiten | Quelltext bearbeiten]

Bevor ein neuer oder geänderter Service in den Betrieb überführt werden kann, muss in ausführlichen Tests überprüft werden, ob er die Anforderungen erfüllt. Außerdem müssen mögliche Risiken minimiert sowie Fehler erkannt und behoben werden.

Im Verlauf der Transition-Phase wird immer wieder bewertet, ob die Leistung des Service akzeptabel ist, die Qualität angemessen ist, Risiken beachtet wurden etc. Ziel ist eine Empfehlung an das Change Management, den Change zuzulassen oder abzulehnen.

Knowledge Management

[Bearbeiten | Quelltext bearbeiten]

Das Knowledge Management sorgt dafür, dass die richtigen Informationen zum richtigen Zeitpunkt am richtigen Ort für die richtigen Personen bereitgestellt werden, um sachkundige Entscheidungen zu treffen.