06_P2.2.3 – OpenIT-ITDLM, Service Transition

(1)

Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung

unter dem Förderkennzeichen 16OH21005 gefördert.

Die Verantwortung für den Inhalt dieser Veröffentlichung liegt

beim Autor/bei der Autorin.

(2)

2.2.3-1 Dr. P. Steffen  IT-DLM

SS 2018

IT-Dienstleistungsmanagement

Teil 2: Das ITIL

^®

-Modell als Rahmenwerk für das IT-Servicemanagement

Hier 2.2.3: ITIL

^®

-Baustein Service Transition

Open IT

Zertifikatsstudiengang Wirtschaftsinformatik

Modul 8361: IT-Dienstleistungsmanagement / IT-Projektmanagement

ITIL^®ist eine eingetragene Marke von AXELOS Limited

(3)

Inhaltsübersicht

1 Einführung in die Thematik

1.1 Dienstleistung 1.2 IT-Service

1.3 IT-Servicemanagement

2 Das ITIL-Modell als Rahmenwerk für das IT-Servicemanagement

2.1 ITIL im Überblick

2.2 Bausteine des ITIL-Modells

2.2.1 Service Strategy 2.2.2 Service Design 2.2.3 Service Transition 2.2.4 Service Operation

2.2.5 Continual Service Improvement

(4)

SS 2018

Integrierter Ablauf der Lifecycle Elemente

Hier sind wir heute!

Buchsein, S. 18

• * Early Life Support : Überprüfung von Key Performance

Indicators, Service Level etc., um

sicherzustellen, dass die Serviceziele erreicht werden

können. Bereitstellung von zusätzlichen

Ressourcen für

Incident- und Problem - Management.

(5)

Lebenszyklusphase Service Transition

Ziele:

 Umsetzung des Designs

– in betriebsfähige Services und – Infrastrukturen

– sowie in eine geordnete

Überführung in den Betrieb

(6)

SS 2018

Prozesse

 Transition Planning & Support*

 Change Mgmt

 Service Asset & Configuration Mgmt

 Release and Deployment Mgmt

 Service Validation and Testing

 Change Evaluation

 Knowledge Mgmt

Kernthemen

 Integration der Services in den Geschäftsprozess des Kunden

 Übereinstimmung der Services mit den in den SLR spezifizierten

Anforderungen

 Erkennen und Steuern der

Kundenerwartungen bzgl. neuer und geänderter Services

 Sicherstellung einer effektiven

Umsetzung des Design in den Betrieb

Lifecycle-Phase Transition:

Prozesse und Kernthemen

* Wird im Kurs nicht weiter behandelt.

Output: Early Life Support



Veränderung in Service und Business der Kunden sind aufeinander abgestimmt



Serviceveränderungen werden überwacht u. gesteuert (Kosten, Zeit, Qualität)



Die effektive Umsetzung in den Betrieb ist sichergestellt.

(7)

Service Transition im Überblick

Release &

Deployment Mgmt Build

Change Eval. & Testing Test

Release &

Deployment Mgmt

Transfer, Deployment („Implementieren“) Service Design

Package

Implementierter Service:



getestet,



funktionierend



abgenommen Change Mgmt Erfassen, bewerten,

genehmigen

Change Mgmt Finale Freigabe

Change Mgmt Post Implementation Review (PIR)

Change Schedule Request for Change

Prozess Tätigkeiten

Early Life Support

(8)

SS 2018

Service Transition im Detail

Continual Service Improvement

Change Management

Service Asset und Configuration Management

RfC RfC RfC RfC RfC RfC

BL BL BL BL BL

Service Transition und Planning

Übergreifendes Management der Organisation und Stakeholder

Evaluation eines Changes oder Service

Release und Deployment Management Service

Design Service

Strategy

Service Operation Release-

Planung u.

Vorbereitung Build u. Test

Service- Tests u.

Piloten

Deployment- Planung u. - Vorbereitung

Transfer, Deployment, Ausmusterung

Review u.

Abschluss der Transition Early Life Support

Service-Validierung und Testing

Knowledge Management

E E E

BL

Legende: Baseline-

Punkte

RfC Request for Change

E Evaluations Punkte

Configuration Baseline

Mit einer Configuration Baseline kann eine bekannte Konfiguration einer IT-Infrastruktur wiederhergestellt werden,

wenn ein Change oder ein Release fehlschlägt.

Hier nicht behandelt!

Spezifische Transitionsprozesse Lifecycle Prozesse

In Anlehnung an Ebel, ITIL- Basiszertifizierung, Abb. 8.1

(9)

 Ein Configuration Item (CI) ist

– eine Servicekomponente oder ein Asset oder ein sonstiges Objekt,

– das unter der Kontrolle des Configuration Mgmt steht,

– um einen IT-Service bereitstellen zu können.

 Beispiele:

– IT-Services – Hardware – Software – Gebäude

– Prozessdokumentation – Verträge mit Service Level

 Alle CI unterliegen der Kontrolle des

Configuration Mgmt



CI dürfen nur anhand eines formalen Change geändert werden



Mögliche Attribute eines CI

 Bezeichnung (eindeutig!)

 CI-Typ

 Name

 Beschreibung

 Version

 Hersteller

 Status (in Betrieb, defekt, stillgelegt,…)

 Relationen zu anderen CIs

 Besitzer

 Definitive Media Library (DML)

Standorte, an dem die endgültigen und genehmigten Versionen aller Software CIs sicher gespeichert sind.

 Die DML enthält kann darüber hinaus zugehörige CIs wie Lizenzen u. Dokumentationen beinhalten.

 Die DML ist als einzelner logischer

Speicherbereich definiert, auch wenn sie auf verschiedene Speicherorte aufgeteilt ist.

 Die gesamte Software in der DML untersteht der Steuerung des Change und Release

Management und wird im Configuration Management System erfasst.

 Für ein Release ist ausschließlich der Einsatz von Software aus der DML gestattet.

Definitionen, Beispiele und Attribute

von CI

(10)

SS 2018

Change Management:

Ziel, Definitionen, Rolle (1/2)

 Definition Change:

Hinzufügen, Modifizieren oder Entfernen eines Elements (Configuration Item „CI“), das Auswirkungen auf

die IT-Services haben könnte.

 Ein Change sollte enthalten sämtliche betroffenen

 IT-Services

 Configuration Items

 Prozesse

 Dokumentationen.

Ziel:

 Reaktion auf Requests for Changes (RfC) vom

Business und der IT

(11)

Change Management:

Ziel, Definitionen, Rolle (2/2)

 Request for Change:

Realisiert als in Form eines standardisierten Dokuments

 Change Schedule

Dokument, das alle genehmigten Changes und deren geplante Implementierungsdaten enhält, ebenso Informationen zu Changes, die bereits implementiert wurden.

 Post Implementation Review Review, der nach der

Implementierung eines Changes oder eines Projekts erfolgt.



Im PIR wird festgestellt, ob Change oder Prozess erfolgreich waren



Liefert ggf. Optimierungspotenzial.

Rolle Change Manager

verantwortlich für die Zielerreichung des Change-Mgmt-Prozesses:

 Annahme, Filterung, Dokumentation und Priorisierung der RfC

 Einberufen des CAB (= Change

Advisory Board, s.u.) und Vorlage der relevanten Changes

 Autorisieren der Changes. ggf. nach Abstimmung mit dem CAB

 Bereitstellen der Change-Planung

 Koordinierung von Change-Erstellung, Test u. Implementierung

 Review aller implementierten Changes

 Schließen der RfC nach Abschluss

 Bereitstellen des Management

Reporting

Beispiel: RfC

(12)

SS 2018

Beispiel eines

Change Advisory Boards

Change Manager (Vorsitz)

CAB

Service Level Manager

Application Manager Service Desk

Benutzervertreter

Configuration Manager

Lieferanten Weitere Personen

nach Bedarf Kunde

Administratoren Consultants

Change Advisory Board:

Eine Gruppe von Personen…



setzt sich i.d.R. zusammen aus



Vertretern aller Bereiche des IT-Service Providers



dem Business



Drittparteien, wie z. B. Supplier



berät den Change Manager bei der Bewertung, Festlegung von Prioritäten und Zeitplanung von Changes



wird abhängig von der

Priorisierung des/der Changes einberufen.



Für zeitkritische Fälle: Emergency CAB („ECAB“)

Quelle: Ebel, ITIL-Basiszertifizierung, Abb. 11.24

(13)

Change-Arten (Kategorien)

 Normaler Change

– Änderungen an CIs bzw. Services, die der Genehmigung bedürfen

 Anwendung des kompletten CM-Prozesses

 Standard Change

– Ein gleichartiger Change wurde bereits mind. einmal durchlaufen

 Änderungen mit standardisiertem Arbeitsablauf;

 keine neue Genehmigung erforderlich (i.d.R. jedoch mit Change Schedule)

 (Einzelne) Schritte im CM-Prozess können ausgelassen bzw. in abgespeckter Form ausgeführt werden

 Emergency Change

– „Notfall“

– Meist Schnell-Genehmigung durch Emergency CAB

 Dokumentation und manche Tests erst NACH Änderung der CIs möglich

(14)

SS 2018

Change Authority: Beispiel für die Ausgestaltung der Kompetenzen

Geschäftsführung/Vorstand (Business Executive Board)

IT-Direktor

(IT Management Board)

CAB oder Emergency CAB

Lokale Instanz (Local authorization)

Hohe Kosten/Risiken, benötigt Entscheidung aus dem

Management

Change hat Auswirkungen auf mehrere Services oder Organisationsbereiche

Changes mit lokalen Auswirkungen oder einer

Service-Gruppe

Standard-Changes

Change Authority Beispiele

Kommunikation, Eskalationsweg für RfCs, Risiken, offene Punkte Kommunikation, Entscheidungen, Aktionen

Ende BI 01 2. Online Session am 12.03.18

(15)

Change Evaluation - Prozess

Ziele:

 Bewertung, ob in der Transition Phase die Spezifikationen und die Performance erfüllt werden

 und Kosten akzeptabel sind

 Generischer Prozess zum Nachweis der

Erbringung der geforderten Performanz

 kommt zur Anwendung an verschiedenen

Stellen des Release &

Deployment-Prozesses

•Selbst- studium

Beispiel CM-Prozess

(16)

SS 2018

Service Asset and Configuration Management (SACM)

 …ist der Prozess, der für die Pflege von Informationen zu den Configuration Items (CI) einschließlich der

zugehörigen Beziehungen verantwortlich ist, die für die Erbringung eines IT-Service erforderlich sind.

 Diese Informationen werden über den gesamten

Lebenszyklus eines CI hinweg in der CMDB verwaltet.

 Das Configuration Management ist Teil eines umfassenden Service Asset and Configuration Management - Prozesses.

Ziel:



Integrität der Service Assets und der Configuration Items schützen



Unterstützung der operativen Service Mgmt –

Prozesse

(17)

SA SA

SA

Begriffsabgrenzung: Service Asset and Configuration Mgmt

Kund e IT -Orga ni satio n (Servi ce Provi de r)

GP1 GP2 GP3 GP4

CI CI

CI

IT-Service

GP = Geschäftsprozess CI = Configuration Item (ITIL-Abkürzung für IT- Komponente)

SA = Service Asset CMS: Configuration Management System CMDB: CM-Datenbank IM = Incident M.

ChM = Change M.

Org. = Organisation

Service Assets

• Organisation, Management

• Prozesse/Funktionen

• Prozessmanagement

• Informationen

• Finanzkapital

• Mitarbeiter (Know How)

• Wissensmanagement

• Infrastruktur

• Anwendungen

IM Org

ChM CMDB

SA

SA SA SA

SA

(18)

SS 2018

Lebenszyklus eines Configuration Items

CI geplant bestellt geliefert getestet implementiert

im Betrieb ausgefallen

gewartet stillgelegt

Zeit -->

CI -Status

(19)

Ziel und Begriffsdefinitionen zum R&D Mgmt

 Release = Umsetzung eines/mehrerer Changes

– Satz von neuen, geänderten und/oder

unveränderten CIs, die gemeinsam getestet und in die produktive Umgebung ausgerollt werden.

 Release Unit (RU)

– Ein Release kann bei Bedarf in logisch sinnvolle „Units“ strukturiert werden.

– Komponenten eines IT-Service, die üblicherweise im selben Release veröffentlicht werden.

• z.B. alle Komponenten für eine Funktion

• z. B. ein Desktop-PC mit Hardware, Software, Lizenzen, Dokumentation usw. sein.

 Release Package (RP)

– RPs können aus einer oder mehreren Release Units bestehen.

– RPs sollten so gestaltet werden, dass die Möglichkeit besteht, einzelne RUs bei Bedarf (z..B. aufgrund entsprechender

Testergebnisse) aus dem RP zu entfernen.

Ziele:

 Erfolgreiche Integration von Changes in die Zielumgebung

 Bereitstellung von Dokumentation für Benutzer und Service Operation

 Bewertung, ob in der Transition Phase die Spezifikationen erfüllt werden und Kosten akzeptabel sind.

WI 52 am 05.11.17:

Ende KE-9 (Überflug)

(20)

SS 2018

Release und Deployment - Modelle

 Big Bang: Alle Komponenten eines Releases werden gleichzeitig in die Betriebsumgebung eingeführt:



kurze Dauer, weniger Beeinträchtigungen



höheres Risiko für erhebliche Beeinträchtigungen des Betriebs.

 Phased: Rollout phasenweise, z. B.

nach Standort oder Funktionalität:



geht über längeren Zeitraum (=aufwendigere Planung, teurer)



geringeres Risiko für weitreichende Beeinträchtigungen



Erfahrungen aus den ersten Phasen können für die folgenden verwendet werden.

Release und Deployment - Methoden

 Push: Der Service Provider verteilt das Release aktiv und implementiert es entweder manuell oder automatisiert (z. B. per Softwareverteilung) .

 Pull: Der Service Provider stellt das Release bereit und der

Kunde bzw. die Anwender rufen dieses Release ab, wenn sie die Implementierung vornehmen wollen.

Begriffsdefinitionen zum R&D Mgmt

WI 50, KE 6:

hier PAUSE (14.11.17) (danach FS) Ebenso WI 52

(21)

Der Release und Deployment-Prozess

(22)

SS 2018

Release & Deployment im Zusammenspiel mit Change Management u. SACM

Change Management

Release und Deployment Management Service Asset u.

Configuration Management

Impact Analysis

Changes Changes

Ausrollen der Releases Service- u. CI-

Überwachung und -Aktualisierung, Modell

Cha nge-A

nnahm e und -A

uftrag

Release & Deployment – Ziel:

 Erfolgreiche Integration von Changes in die Zielumgebung

 Bereitstellung von Dokumentation für Benutzer und Service

Operation

 Bewertung, ob in der Transition Phase die Spezifikationen erfüllt werden und Kosten akzeptabel sind.

Service Asset & Configuration (SACM) – Ziel:

 Integrität der Service Assets und der CI schützen

 Unterstützung der operativen Service Mgmt – Prozesse Change Management – Ziel:

 Reaktion auf Requests for Changes (RfC) vom Business und der IT

* In Anlehnung an Ebel, ITIL-Basiszertifizierung, Abb. 11.34

(23)

Aspekte eines Testmodells, Validierungs- u. Test-Prozess

Testmodell (s. auch V-Modell):

Service-Vertrag:

Prüfen, ob der Kunde über den Service einen entsprechenden Nutzen erhält (Utility)

Service-Anforderungen:

Prüfen, ob der Service Provider den Service in gewünschter und vereinbarter Form liefert

Service Level:

Sicherstellen, dass der Service Provider den Service

entsprechend den Service Level-Anforderungen (SLR) in der Produktionsumgebung mit der entsprechenden Warranty zur Verfügung stellt (Testen der Antwortzeiten, Maintainability, Support-Leistungen, etc.)

Betrieb:

Prüfen, ob das Betriebsteam den Service betreiben kann.

Service Validation & Test – Ziel:

 Kundenerwartungen erfüllen

 Erfüllung der Spezifikationen:

 einsatzbereite Services

(24)

SS 2018

Release & Deployment:

Test und Pilotierung

Deployment-Readiness-Test: Nachweis, dass alle Deployment-Prozesse und -Systeme die Release Packages in die Produktivumgebung transferieren können.

Service Operation Test: Nachweis, dass der Service Provider die neuen oder geänderten Services betreiben kann.

User Test: Nachweis, dass die End-User die neuen und geänderten Services wie vereinbart nutzen können.

Service Provider Interface (SPI) Test:

Nachweis, dass die Schnittstellen des Service zum Business funktionieren.

Service Management Test: Nachweis, dass die Performance des Service gemessen, überwacht und dokumentiert werden kann.

Deployment (Service Level )Test: Nachweis, dass die neuen oder geänderten Services die Service Level Requirements erfüllen.

Deployment Verification Test: Nachweis, dass die neuen oder geänderten Services für alle geplanten Business-Umgebungen

verfügbar sind.

Quelle: Beims, S. 135

(25)

Beispielhafte Inhalte einer Test- Strategie

Service-Vertrag:

Prüfen, ob der Kunde über den Service einen entsprechenden Nutzen erhält (Utility).

Service-Anforderungen:

Prüfen, ob der Service Provider den Service in gewünschter und vereinbarter Form liefert.

Service Level:

Sicherstellen, dass der Service Provider den Service

entsprechend den Service Level-Anforderungen (SLR) in der Produktionsumgebung mit der entsprechenden Warranty zur Verfügung stellt (Testen der Antwortzeiten, Maintainability, Support-Leistungen, etc.).

Betrieb:

Prüfen, ob das Betriebsteam den Service betreiben kann.

(26)

SS 2018

Das V-Modell:

Testmodell in Service Transition

Definition der Kunden-/

Business-Anforderungen

Ebene 1

Validierung der Service Packages, Angebote u.

Verträge Service Review-Kriterien/Planung

1a 1b

Definition der Service- Anforderungen

2a

Design der Service- Lösung

3a

Design des Service- Release

4a

Entwicklung der Service-Lösung

Service-Akzeptanztest

2b Operativer Service- Fertigstellungstest

3b Service Release

Package-Test

4b Komponenten- u.

Assemblierungstest

5b 5a

Service Komponenten-

Build u. -Test Interne u.

externe Lieferanten

Service Akzeptanzkriterien/Planung

Service Betriebskriterien/

Planung

Service Release- Testkriterien/

Planung - Vertrag, Service Package, SLP, SPI

- SLR, Entwurf der SLA

- SDP (Service-Modell, Kapazitäts- u.

Ressourcenpläne

- Release Design, Release Plan

Ergebnisse von externen u.

internen Lieferanten

Ebene 2

Ebene 3

Ebene 4

Ebene 5

Service Design Service Transition

Definition und Entwicklung eines neuen Services Testaktivitäten zur Validierung der Spezifikationen

Baseline- Punkte

Zeit

Szenarien

Testfälle

Testfälle Testfälle

Definition der Service- Anforderungen

(27)

Service Knowledge Mgmt

Entscheidungs- unterstützung:



die richtige Information muss zur richtigen Zeit an der

richtigen Stelle zur Verfügung stehen:

– Strategisches Mgmt – Operatives Mgmt

Knowledge Processing Layer Berichtsgenerierung- und

Präsentationssysteme

Known Error DB Avail. Info.

Mgmt System

Service- Katalog Capacity Info.

Mgmt System

Definitiv Media Library

Config.

Mgmt System

Service Knowledge Management – Ziel:

 Unterstützung des Service

Providers zur Verbesserung von Effizienz und Qualität

 Bereitstellung der erforderlichen Informationen für die Mitarbeiter des Service Providers

Service Knowledge Mgmt System (SKMS)

(28)

SS 2018

Ende des Kapitels

Vielen Dank für Ihre Beiträge!

Quellenangaben (für alle Kapitel):

Beims, M.: IT Service Management in der Praxis mit ITIL, München, Hanser, 2015.

Buchsein, R., Victor, F., Günther, H., Machmeier, V.: IT-Management mit ITIL V3 – Strategien, Kennzahlen, Umsetzung, 2., aktual. und erw. Aufl., Wiesbaden, GWV Fachverlage, 2007.

Ebel, N.: ITIL V3 Basis-Zertifizierung, Addison-Wesley, 2008.

Kresse, M., Bause, M.: Learn ITILv3, Advanced Service Management - Pocket Book, 2. Aufl., Serview, 2008.

Zarnekow, R., Hochstein, A., Brenner, W.: Serviceorientiertes IT-Management, Springer, 2005.