Willkommen zur ITIL-Foundation! · PDF fileInnerhalb des Bereichs „Service Transition“ sind Prozesse zusammengefasst, die die Einführung neuer oder geänderter Komponenten abbilden

09/09/2010

© Comedia.MDS IT GmbH, 2010 1

Willkommen zur ITIL-Foundation!Service Transition (ST) - 4 von 8

Stand: 1.2 / 09.09.2010Syllabus: 4.3 / 01.05.2010

2

Übergang der Services zur und von der Liveumgebung; Steuern der Ressourcen und Risiken; Sicherstellung der Lieferung der Services

Aufbauen der angemessenen Kundenerwartung bezüglich neuer oder geänderter Services

Ermöglichen der Änderung der Geschäftsprozesse

Sicherstellen, dass die Services innerhalb der Anforderungen und Randbedingungen effektiv genutzt werden können

Ziele Service Transition – (1/2)

09/09/2010


3

Steuern der Ressourcen, damit neue oder geänderte Services erfolgreich in Produktion gehen, ohne die Ziele hinsichtlich Zeit, Kosten und Qualität zu verfehlen

Sicherstellen, dass möglichst wenig Unvorhergesehenes die produktiven Services und die Organisation negativ beeinflußen

Verbessern des bestimmungsgemäßen Gebrauchs der Services und zugehörigen Anwendungen

Bereitstellen einer verständlichen Planung, so dass der Kunde seine Änderungen mit der IT-Organisation abstimmen kann

Ziele Service Transition – (2/2)

4

Innerhalb des Bereichs „Service Transition“ sind Prozesse zusammengefasst, die die Einführung neuer oder geänderter Komponenten abbilden. Diese Ressourcen werden zusammengestellt, gebaut, getestet und in die Produktivumgebung überführt. Die zugehörigen Services erbringen die mit Kunden und Beteiligten vereinbarten Leistungen.

Service Transition – Abgrenzung

09/09/2010


5

ST ermöglicht eine große Anzahl von Changes und Releases für den Kunden

ST stellt das Verständnis für Risiken während und nach einem Change her

ST richtet die neuen und geänderten Services an den Anforderungen des Kunden bezüglich seines Geschäftes aus

ST stellt sicher, dass Kunde und Anwender alle Services effizient nutzen können

Service Transition – Wertbeiträge

6

Eindeutige Identifikation und Namenskonventionen für verschiedene Typen von Releases

Rollen und Verantwortlichkeiten für alle Stadien der Prozesse

Vereinbarte Häufigkeit von Release einhalten

Gruppieren von Releases

Service Transition – Prinzipien (1/2)

09/09/2010


7

Mechanismen, die automatisch Aufbau, Installation und Verteilung von Releases unterstützen

Details wie die Configuration Baseline ermittelt wird und gegen aktuelle Stände verglichen wird

Kriterien für die Weitergabe von Releases im Arbeitsablauf

Kriterien für die Abgabe der installierten Releases an Service Operation

Service Transition – Prinzipien (2/2)

8

Übersicht Service TransitionContinual Service Improvement

Change Management

RFC1 RFC2 RFC3 RFC4 RFC5 RFC6

Service Asset and Configuration Management

BL BL BL BL BL BL

Service Transition Planning and Support

Oversee management of organization and stakeholder change

Evaluation of a Change or Service

E1 E2 E3

ServiceStrategy

Early Life Support

Service Validation and Testing

Knowledge Management

ServiceDesign

Plan andpreparerelease

Buildand test

Service testing

and pilots

Plan andprepare

deployment

Transferdeployretire

Review and closeService

Transition

Service Operation

RFC=Request for Change / BL=Baseline / E = Evaluation

09/09/2010


9

Service Asset and Configuration Management (SACM)

Change Management

Release and Deployment Management

Knowledge Management

Service Transition – Prozesse

10

Ziele:

Bereitstellen von akkuraten und aktuellen Informationen über die IT-Infrastruktur

Bereitstellen eines logischen Modells der Services, Assets und anderen Komponenten, einschließlich der Beziehungen untereinander

Definieren und Steuern von Informationen über alle Komponenten von Services

Ermöglichen von Inventur, Change und Support Prozessen

SERVICE ASSET AND CONFIGURATION MANAGEMENT (Prozess)

09/09/2010


11

„Configuration Items“ sind alle Komponenten, die nötig sind und verwaltet werden müssen, um Services zu liefern.

Die Informationen über alle CIs werden im „Configuration Management System“ (CMS) verwaltet. Die Pflege der Informationen erstreckt sich über den kompletten Lebenszyklus von CIs. Alle CIs unterliegen der Steuerung durch den Prozess „Change Management“

CONFIGURATION ITEM (CI) (Def.)

12

Servicelebenszyklus-CIs – Kosten-Nutzen-Analysen, Service Design Packages, Change Pläne, Test Pläne

Service-CIs – Prozesse, Personen, Geld, Systeme

Organisations-CIs – Strategien und Richtlinien

Interne CIs – CIs die für die Erbringung von Service Management Leistungen selbst von Provider selbst benötigt werden

Externe CIs – Externe Services, fremde Anforderungen, fremde Releases

CONFIGURATION ITEM - Typen

09/09/2010


13

Die „Configuration Baseline“ ist eine detailliert beschriebene und formal abgenommene Konfiguration eines CIs zu einem bestimmten Zeitpunkt. Die Configuration Baseline wird als Referenzpunkt für den Change Prozess verwendet.

CONFIGURATION BASELINE (Def.)

14

Logisches Konfigurations Modell

AvailabilityUser

experience

Business logic

Messaging

Data services

Web services

Network topology

Authentication

Network service

service

E-bankingSupportservice

ApplicationApplication

Hostingservice

TechnicalInfrastructure

service

Serviceportfolio

BankingCore

service

CustomerServiceLevel

package

Contract

verwendetHostedUnterstützt

09/09/2010


15

Ein „Configuration Management System“ (CMS) besteht aus einer Reihe von integrierten Werkzeugen und Datenbanken. Das CMS verwaltet alle relevanten Konfigurationsinformationen eines Service Providers.

CONFIGURATION MANAGEMENT SYSTEM (Def.)

16

Eine „Configuration Management Database“ (CMDB) ist eine Datenbank, die alle Konfigurationsinformationen von CIs während derer Lebenszyklus speichert. Das CMS beinhaltet eine oder mehrere CMDBs. Jede CMDB führt die Attribute von CIs und die Beziehungen zu anderen CIs.

CONFIGURATION MANAGEMENT DATABASE (Def.)

09/09/2010


17

Beispiel CMSConfiguration Management System (CMS)

Presentation layer (views)(search, browse, store, retrieve update, publish, subscrible, collaborate)

Knowledge processing layer(query and analysis, reporting, performance management, modelling, monitoring)

Information integration layer

Integrated Asset and Configuration Management

Data and information sources

Change data

Documents

CMDB 1 DML A

CMDB 2 Release dataDML B

Discovery data

18

Beispiel CMS

Presentation layer (views)

09/09/2010


19

Management und Planung

Configuration-Identifizierung

Configuration-Steuerung

Statusnachweis und Berichterstattung

Verifizierung und Audit

Informationsmanagement

SERVICE ASSET AND CONFIGURATION MANAGEMENT (Aktivitäten)

20

Der Prozess Service Asset and Configuration Management

Change andconfigurationinformation

Configuration ManagementSystem (CMS)

Managment andPlanning

ConfigurationIdentification

ConfigurationControl

Status AccountingAnd Reporting

Verificationand Audit

Basic Concepts

Service Asset andConfiguration Management

09/09/2010


21

Change Management

Financial Management

IT Service Continuity Management

Incident and Problem Management

Availability Management

SERVICE ASSET AND CONFIGURATION MANAGEMENT (Schnittstellen)

22

Ziele:

Es ist sicherzustellen, dass Changes erfasst und anschließend auf kontrollierte Weise evaluiert, autorisiert, priorisiert, geplant, getestet, implementiert, dokumentiert und geprüft werden.

Auf die sich ändernden Business-Anforderungen der Kunden zu reagieren und dabei den Nutzen zu maximieren und den durch Incidents, Unterbrechungen und Nacharbeiten bedingten Aufwand zu minimieren

CHANGE MANAGEMENT (Prozess)

09/09/2010


23

Ein „Request for Change “ ist der formale Antrag zur Durchführung eines Changes. Der RfC enthält alle Details zum Change und kann auf Papier oder elektronisch erfasst werden.

REQUEST FOR CHANGE (RFC) (Def.)

24

Das „Change Advisory Board“ ist eine Personengruppe, die den Change Manager bei der Bewertung, Priorisierung und Terminierung eines Changes beraten.

Teilnehmer• Change Manager

• Kunde, Anwender, Business

• IT, Service Provider, Technik

CHANGE ADVISORY BOARD (CAB) (Def.)

09/09/2010


25

Das „Emergency Change Advisory Board“ ist eine Personengruppe, die im Falle eines entsprechenden Changes die nötige Kompetenz hat, Entscheidungen dieser Art zu treffen.

Teilnehmer• Change Manager

• Führungspersonal Kunde

• Führungspersonal Service Provider

EMERGENCY CHANGE ADVISORY BOARD (ECAB) (Def.)

26

Ein „Change“ bezeichnet das Hinzufügen, Modifizieren, oder Entfernen eines Services oder einer entsprechenden Servicekomponente und der dazugehörigen Dokumentation.

CHANGE (Def.)

09/09/2010


27

Normal Change

Ein „Normal Change“ wird durch die komplette Bewertung, inklusive Autorisierung, und Implementation geschickt.

Beispiele:• RfC bzgl. Service Portfolio

• RfC bzgl. Service

• Antrag auf Projektänderung

• Antrag für Anwenderberechtigung

CHANGE TYPEN

28

Standard Change

Ein „Standard Change“ ist bereits vorab genehmigt worden und ist ein üblicher und risikoarmer Change.

Folgende Merkmale treten auf:• Ein definierter Auslöser für den Standard Change

• Die Aufgaben sind bekannt, dokumentiert und nachweislich unschädlich

• Das finanzielle OK ist vorab vorhanden

• Die auftretenden Risiken sind klein und wohl bekannt

CHANGE TYPEN

09/09/2010


29

Emergency Change

Ein „Emergency Change“ ist für hochkritische Changes vorhanden. Das kann sich auf die Zeit, Sicherheit und das Budget beziehen. Diese Changes werden vom Emergency CAB (ECAB) genehmigt.

CHANGE TYPEN

30

Raise – Wer hat den Change eingebracht?

Reason – Was ist der Grund für den Change?

Return – Welche Nutzen hat der Change?

Risk – Welches Risiko birgt dieser Change?

Resources – Welche Ressourcen sind für die Durchführung nötig?

Responsible – Wer ist für diesen Change verantwortlich?

Relationship – Welche Beziehung besteht zwischen diesem und anderen Changes?

Die „sieben Rs“ zum Change Management

09/09/2010


31

RFC erstellen

RFC aufzeichnen

RFC-Review durchführen

Change bewerten und evaluieren

Change autorisieren

Aktualisierung planen

Change bauen, testen und Implementierung koordinieren

Change Record prüfen und schließen

CHANGE MANAGEMENT (Aktivitäten)

32

Beispielprozess Normal-Change

Change andconfigurationinformation

Configuration ManagementSystem (CMS)

Create Request for Change (RFC)

Record RFC

Review RFC

evaluate changeAssess and

evaluate change

changeAuthorizechange

Plan updates

Coordinate changeimplementation

Eview and closechange record

Evaluationreport

09/09/2010


33

Ziele:

Die Überführung von Releases in die Produktionsumgebung, um den Service effektiv zu nutzen, der seinerseits einen Wertbeitrag für den Kunden erbringt

Sicherstellen, dass es klare und verständliche Installationspläne gibt, die Kunden und IT ermöglichen, sich darauf einzustellen

Sicherstellen, dass das Release Package erfolgreich und zeitgerecht erstellt, installiert, getestet und ausgerollt werden kann

RELEASE AND DEPLOYMENT MANAGEMENT (Prozess)

34

Ein „Release“ ist eine Ansammlung von Hardware, Software, Dokumentation, Prozessen oder anderen Komponenten, die notwendig sind, um einen oder mehrere genehmigte Changes in Bezug auf einen Service zu implementieren. Die Inhalte eines jedes Releases werden als eine Einheit verwaltet, getestet und ausgerollt.

RELEASE (Def.)

09/09/2010


35

Eine „Release Unit“ bezeichnet alle Komponenten eines Service, die normalerweise gemeinsam – entsprechend der geltenden Release Richtlinie - ausgerollt werden.

RELEASE UNIT (Def.)

36

Eine „Definitive Media Library“ bezeichnet einen oder mehrere Aufbewahrungsorte, in denen die maßgeblichen und abgestimmten Versionen aller Software-CIs sicher verwahrt werden. Die DML kann darüber hinaus auch zugehörige CIs wie Lizenzen und Dokumentationen enthalten.

Die Software in der DML wird vom Change und Release Management gesteuert. Aufgezeichnet ist sie im CMS, das seinerseits von SACM gesteuert wird.

DEFINITIVE MEDIA LIBRARY (DML) (Def.)

09/09/2010


37

DML und CMDB

38

Big Bang – Neue oder geänderte Services werden in einem Bereich für alle Anwender in

einer Aktivität ausgerollt

Phasenweiser Ansatz – Bestimmte Gruppen werden nacheinander in einem Bereich mit

dem Release versorgt

Push-Ansatz – Zentral gesteuert wird das Release ohne Zutun der Anwender ausgerollt

Pull-Ansatz – Die Arbeitsplätze holen sich das Release beim Neustart oder nach Belieben

der Anwender

Automatisierung – Das Release wird mithilfe selbsttätig ablaufender Mechanismen

installiert

Manuell - Manuell

Optionen für das Ausrollen von Releases

09/09/2010


39

Der Release und Deployment Prozess

Plan deploymentof releasepackege

Acquire Service Package or

release

Prepare

DelployService

component

Prepare Prepare Prepare

DelployService

component

DelployService

component

DelployService

component

Assurecompletion

Assurecompletion

Assurecompletion

Assurecompletion

Prepare

DelployService

component

Assurecompletion

Assure deploymentOf service package

or release

Operations

40

Ziele:

Sicherstellen, dass die benötigten Informationen zur richtigen Zeit bei den Personen zur Verfügung stehen, die Entscheidungen treffen

Die Organisation bei der Qualitätsoptimierung unterstützen, indem während des gesamten Lebenszyklus die entsprechenden Informationen vorhanden sind

Sicherstellen, dass das Personal ein klares und einheitliches Verständnis vom Wertbeitrag der Services beim Kunden hat

KNOWLEDGE MANAGEMENT (Prozess)

09/09/2010


41

Daten – Diese liegen als einzelne Fakten in großer Zahl in Datenbanken vor

Information – Sobald ein Kontext vorhanden ist, werden die Daten zu Informationen

Wissen – Wissen setzt sich aus Erfahrungen, Ideen, Einsichten, Werten und Urteilen zusammen. Wissen entsteht bei der Zusammenarbeit im Team oder der Analyse von

Informationen

Weisheit – Sobald vom Wissen abstrahiert wird uns dem Allgemeinen in korrekter Weise über das Einzelne geurteilt wird, ist Weisheit vorhanden

Vom Datum zur Weisheit

42

Ein „SKMS“ ist eine Zusammensetzung aus Werkzeugen und Datenbanken, die dazu dienen, Informationen und Wissen in strukturierter Weise zu speichern. Das SKMS beinhaltet alle Informationen, die ein Service Provider benötigt, um den Lebenszyklus von Services zu steuern.

SERVICE KNOWLEDGE MANAGEMENT SYSTEM (SKMS) (Def.)

09/09/2010


43

Der Prozess Knowledge Management

Define KnowledgeManagement strategy

Transferknowledge

Manage data andinformation

Use the Service knowledge

Management System

Service knowledge

Management System (SKMS)

Musterfragen

09/09/2010


45

a) Unterstützen des Change Managers, um sicherzustellen, dass Urgent

Changes nicht in betriebskritischen Zeiten durchgeführt werden.

b) Unterstützen des Change Managers bei der Implementierung von

Emergency Changes.

c) Unterstützen des Change Managers bei der Entwicklung von Emergency

Changes und der Entscheidung, ob der Change genehmigt wird.

d) Unterstützung des Change Managers, um den Emergency Change Prozess

im Durchlauf zu beschleunigen, um nicht unnötig Zeit zu verlieren.

Was ist die Funktion des Emergency Change Advisory Board (ECAB)?

46

a) Um den Betrieb zu standardisieren.

b) Um zu wissen, wie viel die bereitgestellten Services kosten.

c) Damit die Rollen und Verantwortlichkeiten geklärt sind.

d) Für spätere Vergleichsmöglichkeiten.

Aus welchem Grund wird hauptsächlich eine Baseline festgelegt?

09/09/2010


47

a) Standard-Change

b) Normaler Change

c) Dringender Change

d) Notfall-Change

Bei welchem der nachfolgenden Begriffe handelt es sich NICHT um eine Art von Change?

48

a) Incident Management

b) Release und Deployment Management

c) Service Asset und Configuration Management

d) Service Catalogue Management

Die folgenden Optionen gehören zu welchem Prozess?

1. Big Bang vs Phased2. Push and Pull3. Automated vs Manual

09/09/2010


Vielen Dank für Ihre Aufmerksamkeit!