it infrastrukturit-infrastrukturen.de/docs/01_it infrastructures_part-3-mba-ss2013.pdf ·...

IT Infrastruktur

Sommersemester 2013

ITIL V3 Part III Markus Bauer

Sommersemester 2013

ITIL V3 Service Transition 2

Agenda ITIL v3 Framework

Overview & Allgemeines

ITIL Service Lifecycle

Service Strategies

Service Design

Service Transition Service Operation

Continual Service Improvement

Sommersemester 2013


ITIL V3 Service Transition Service Transition behandelt die praktische Umsetzung und Übertragung der geschäftlichen Anforderungen in konkrete IT-Dienstleistungen Der Schwerpunkt liegt in der erweiterten Aufgabe des bekannten Change-Managements sowie in einer standardisierten Übermittlung von Service-Leistungen Es enthält Risiko-Analyse, Nutzenrechnung, sichere Auslieferung und Gewährleistung für eine stabile Erfüllung der Leistungsverpflichtung

Die Publikation "Service Transition" beinhaltet folgende Kapitel:

• Service Transition Principles • Service Transition Processes

• Transition planning and support • Change Management • Service Asset & Configuration Management • Release and deployment management • Service validation and testing • Evaluation • Knowledge Management

• Common Operation Activities • Technology Considerations • Implementation Considerations

Sommersemester 2013


ITIL V3 - Overview

Sommersemester 2013


Service Transition - Ziele

• Änderungen an und für Services planen und managen

• Service Release erfolgreich in Produktion überführen

• Hilfe bei Entwicklung und Verbesserung der Verfahren zur Einführung neuer und geänderter Services

• Optimale Betriebsübernahme inklusive

• Release Planung

• Building

• Testing

• Deployment

• Evaluierung

Sommersemester 2013


Service Transition – Werte aus Sicht des Business

• Sehr hohe Flexibilität

• Schnelle Anpassung an sich ändernde Anforderungen

• Optimale Planungssicherheit

• Störungsfreies Umsetzen von Veränderungen

Sommersemester 2013


Service Transition – Prozesse

• Transition Planning and Support (Dokumentation aller Vorgaben)

• Change Management (*)

• Service Asset and Configuration Management (*)

• Release and Deployment Management (*)

• Service Validation and Testing

• Evaluation

• Knowledge Management

(*) Nur diese 3 Prozesse sind für die Zertifizierung relevant

Sommersemester 2013


Change Management - Ziele • Ziel ist die angemessene Reaktion auf die sich ändernden Anforderungen des Business mit dem Ziel

• Werte zu maximieren

• Incidents und Unterbrechungen zu minimieren

• zusätzliche Aufwände zu minimieren

• Service Changes Hinzufügen, modifizieren oder löschen autorisierter, geplanter oder unterstützter Services oder Servicekomponenten und der dazugehörigen Dokumentationen • Das Change Management ist verantwortlich für die Überführung der betroffenen CI‘s (Configuration Items) aus einem definierten statischen Ursprungszustand in einen neu definierten Zielzustand

Sommersemester 2013


Change Management – Ziele II

Das Change Management soll sicher stellen, dass Changes beherrschbar und erfolgreich durchgeführt werden durch:

• Protokollierung aller notwendigen Details

• Beurteilung aller Einflüsse und Auswirkungen

• Zulassung und Autorisierung

• Priorisierung der Change Aktivitäten

• Planung aller Einzelaktivitäten

• Testing

• Implementierung

• Dokumentation

• Abschließende Prüfung

Sommersemester 2013


Change Management - Umfang

• Der Change Management Prozess besitzt Schnittstellen zum Business und zu den Lieferanten auf verschiedenen Ebenen:

• strategischer (Strategic Change)

• taktischer (Tactical Change)

• operativer (Operational Change)

• Die Schnittstellen betreffen interne und externe Service Provider

• Changes für Services und Servicekomponenten beinhalten

• Erweiterungen (add)

• Aktualisierungen (update)

• Löschungen & Außerbetriebnamen (delete)

Sommersemester 2013


Change Management - Output

• Ausschließlich autorisierte Changes

• Stabile Services ohne Ausfall

• Hohe Erfolgsquote der durchgeführten Changes

• Minimale Anzahl von Emergency Changes

• Hohe Projektsicherheit durch Einhaltung der Planungszyklen

Sommersemester 2013


Change Management – Change Arten

Das Change Management kennt folgende Arten von Changes:

• Normale Changes

• So nachhaltig wie möglich

• Standard Changes

• So unbürokratisch wie möglich

• Emergency Changes

• So schnell wie möglich

Achtung: Sehr Wichtig, auch für die Zertifizierung!!

Sommersemester 2013


Change Management – Change Request

Es gibt verschiedene Arten von Change Requests:

• Request for Change to Service Portfolio

• Request for Change to Service

• Project Change Proposal

• User Access Request

• Operational Activity

Sommersemester 2013


Change Management – Prozessmodell Prozessmodell:

• Definition aller erforderlichen Schritte und Aktivitäten zur erfolgreichen Durchführung eines Prozesses im vereinbarten Rahmen

Change Modell:

• Vordefinierte Schritte zur Umsetzung eines bestimmten Changes

Inhalt des Modells:

• Schritte zur Umsetzung des Changes

• Bearbeitungshinweise mit Berücksichtigung unerwarteter Ereignisse

• Chronologische Reihenfolge, mit Abhängigkeiten zu Subprozessen

• Verantwortlichkeiten

• Zeitpläne und Meilensteine zur Erfüllung

• Eskalationsprozeduren

Sommersemester 2013


Change Management – RFC •Der Request for Change (RFC) ist ein Änderungsantrag für ein oder mehrere Configuration Items (CI‘s)

• Der Träger (Sponsor) des Changes übernimmt die Kosten des Changes

• Der Auslöser ist die vom Change betroffene Intressensgruppe

• Träger (Sponsor) und Auslöser müssen nicht identisch sein

• Klassifizierung der Changes mit Kategorisierung und Priorisierung (nach Auswirkungen und Dringlichkeit)

• Der RFC enthält eine Aufstellung aller betroffenen CI‘s. Die Identifikation der CI‘s ist Aufgabe des Configuration Managers nicht des Change Managers

• Das Change Advisory Board (CAB) ist für den Genehmigungsprozess des Changes verantwortlich

• Ein RFC kann nur IT intern initiiert werden

Sommersemester 2013


Change Management – RFC Request for Change:

• Träger (wer zahlt) und Auslöser (wer wills) des Changes

• Betroffen CI‘s

• Vorschläge des CAB

• Begründung und Auswirkung bei nicht Durchführung des Changes

• Klassifizierung mittels Kategorisierung und Priorisierung

• Ermittlung der Ressourcen und Kosten

• Aktivitäten- und Zeitplanung

• Lösungskonzept und Backout-Plan

• Beschreibung und Dokumentation

• Status des RFC

• Jeder RFC muss auf Dringlichkeit, Auswirkungen, Risiken, Kosten und Abhängigkeiten untersucht werden

Sommersemester 2013


Change Management – Aufgaben Aufgaben des Change Management:

• Prüfen von RFCs

• Klassifizieren (Kategorisieren und Priorisieren) der Changes

• Autorisieren der Changes

• Planen von Changes

• Überwachung von Umsetzung und Test

• Freigabe von Changes

• Review aller implementierten Changes

Die Devise ist: Kein Change ohne

• Autorisierung

• Freigabe

• Review

• Backout-Plan

Sommersemester 2013


Change Management – Rollen

• Change Manager Begleitet den Change als Prozessverantwortlicher von Beginn bis Ende und hat den Vorsitz im Change Advisory Board (CAB)

• Change Authority

Hierarchisch organisierte Genehmigungsinstanz, genehmigt und beurteilt Risiken

• Change Advisory Board (CAB) Beratung und Unterstützung bei der Genehmigung

• Emergency Change Advisory Board (ECAB) Im Rahmen von Urgent Changes kann oft nicht bis zur

Autorisierung durch das CAB gewartet werden. Eine Genehmigung durch eine repräsentative Gruppe muss schnellstens erfolgen.

Sommersemester 2013


Change Management – CAB

Mögliche Mitglieder im CAB:

• Vom Change betroffene Kunden

• Repräsentative End User

• Vertreter aller Bereiche der ITIL-Prozesse

• Vertreter aus dem Bereich der Anwendungsentwicklung

• Technische Experten

• Repräsentanten des Service Desk

• Repräsentanten der Lieferanten

Aufgaben des CAB:

• Prüfen der RFCs

• Durchführen der Risikobewertung

• Durchführung einer Kosten/Nutzen-Analyse

• Autorisierung und Vorplanung von Changes

• Definition des ECAB für dringende Fälle

Sommersemester 2013


Change Management – ECAB

• Im Rahmen von Urgent Changes kann oft nicht bis zur Autorisierung durch das CAB gewartet werden

• Eine Genehmigung durch eine repräsentative Gruppe soll dennoch schnellstens erfolgen

• Für solche Fälle wird das ECAB (Emergency Change Advisory Board) einberufen

• Es besteht aus den zum entsprechenden Zeitpunkt verfügbaren Mitgliedern des CAB oder einer definierten Notfallgruppe

Sommersemester 2013


Change Management – Autorisierung

Kommunikation bottom up

• Eskalation für RFCs

• Risiken

• Probleme & Fragen

Kommunikation top down

• Entscheidungen

• Aktionen

Change Authority Examples of configuration level impacted

Business

executive board

IT management board

CAB or ECAB

Local authorization

Level 1

Level 2

Level 3

Level 4

High cost/risk changes executive decision

Change impacts multiple services or organizational groups

Change which impacts only local or service groups

Standard Change

Sommersemester 2013


Change Management – Change Schedule

• Der Change Schedule, „Change Kalender“, dient der zeitlichen Planung und Implementierung von Changes

• Der Change Schedule als Arbeitsmittel beinhaltet:

• Details aller genehmigten Changes

• Geplante Implementierungszeiten

• Wartungsfenster

• „Freeze Times“

• Alle SLA relevanten Daten, die die Planung von Changes betreffen, werden im PSO (Projected Service Outage) Dokument veröffentlicht

• Der Change Schedule (CS) und das PSO-Dokument werden vom Change Manager gepflegt und veröffentlicht

• Wichtigste Zielgruppe für den CS ist der Service Desk, der die Anwender informiert, bzw. Service Ausfälle in Beziehung zu Changes bringen kann

Sommersemester 2013


Change Management – Seven R’s

Die sieben R zur Bewertung von Changes:

• Who submitted or RAISED the change?

• What is the REASON?

• What is its result or RETURN?

• What are the changes RISKS?

• What RESOURCES does it require?

• Who is RESPONSIBLE for build, test and implementation?

• Which RELATIONSHIP exist between this and other changes?

Sommersemester 2013


Change Management – KPIs

Key Performance Indicators für Change Management:

• Anzahl gemäß Kundenanforderungen erfolgreich durchgeführter Changes

• Leistung und Nutzen der Changes im Verhältnis zu Kosten

• Reduktion der Service Unterbrechungen

• Reduzierung nicht autorisierter Changes

• Reduzierung der Backouts

• Reduzierung der ungeplanten Changes

• Erfolgsrate genehmigter Changes gemäß Evaluation

Sommersemester 2013


Change Management – Zusammenfassung

• RFC –Request for Change

• CS – Change Schedule

• CAB – Change Advisory Board

• ECAB – Emergency Change Advisory Board

• 7 R‘s

• Normal, Standard, Emergency Change

• PSO- Projected Service Outage

Sommersemester 2013


Service Asset & Configuration Management - Ziel

• Ziel dieses Prozesses ist es, die Service Assets des Unternehmens zu verwalten und die anderen Service Management Prozesse zu unterstützen

• Service Asset & Configuration Management (SACM) ist kein Prozess mit Eigenwert

Sommersemester 2013


Service Asset & Configuration Management – Configuration Model

Das Configuration Model liefert das logische Modell mit Services, Assets und der Infrastruktur durch Pflege der CIs und ihrer Relationen, mit dem Ziel:

• Unterstützung bei der Ursachenanalyse von Incidents und Problems

• Auswirkungen geplanter Changes untersuchen

• Unterstützung bei Planung und Entwurf neuer Services

• Unterstützung für Technologie Refresh und Software Upgrades

• Planung und Migration von Release und Deployment Packages

• Hilfe bei Optimierung der Assetverwendung und Kosten

Sommersemester 2013


Service Asset & Configuration Management – Configuration Items

• Komponente der IT-Infrastruktur unter Kontrolle des Configuration Management

• CIs können bezüglich Komplexität und Größe und Typ stark variieren Dies kann ein ganzes System oder ein Service sein oder eine HW Komponente

• CIs sind logische und physikalische Elemente zur Erbringung eines Service

• Es gibt mehrere Arten von CIs:

• Service Lifecycle CIs

• Service CIs

• Internal CIs

• External CIs

• Interface CIs

Sommersemester 2013


Ein Configuration Item CI ist ein Element der Infrastruktur und Bestandteil von Services

CI´s sind eindeutig identifiziert und können miteinander verknüpft werden

Regeln der Erfassungstiefe:

• Alles erfassen, was benötigt wird

• Nichts erfassen, was nicht benötigt wird

• Nur erfassen, was gemessen/erfasst werden kann

• Nur erfassen, was einen Owner und einen Pflegeprozess hat

• Jedes CI muss unabhängig sein, also unabhängig installiert, ersetzt, geändert oder ausgetauscht werden können

• Aufwand für Erfassung und Pflege bewerten

Service Asset & Configuration Management – Configuration Items

Sommersemester 2013


Name bzw. ID (eindeutige Beschreibung)

Seriennummer

Model

Versionsnummer

Standort

Owner

Lieferant

Status aktuell

Status alt

Status geplant

Parent/Child-Beziehungen

Containment-Beziehungen

Relationen zu anderen Cis

Vertragsdaten

Verbindung zu allen

• Incidents

• Known Errors

• Problemen

• RFCs

Bemerkungen

Service Asset & Configuration Management – CI Attribute

Sommersemester 2013


CI´s werden in Relationen zu einander gestellt. Dabei wird jede servicerelevante Beziehung berücksichtig:

Vater-Kind Beziehung

nutzt

Beinhaltet

Ist Teil von

Verbindet

Variante von

Über Beziehungen kann ermittelt werden

Welche Komponenten, welchen Service erbringen

Welche Changes, Incidents oder Problems zu welchen CI´s gehören

Service Asset & Configuration Management – CI Beziehungen

Sommersemester 2013


Service Asset & Configuration Management – Configuration Management System (CMS)

Datenbankgestütztes System, das alle Informationen bezüglich der CIs und Ihrer Beziehungen zueinander bereitstellt. Dazu gehören:

• Systeminformationen (Data & Information, Sources & Tools) dies ist der IST-Zustand

• Integrationsinformationen (Integrated CMDB) dies dis der SOLL-Zustand

• Dadurch erworbenes Know-how und dessen spezifische Präsentation

Sommersemester 2013



SMT (Systeminformation) – Data, Information, Sources and Tools Systemeinformation mit echten & aktuellen Informationen über den „IST-Zustand“ der CIs, z.B. in den physikalischen CMDBs

Information Integration Layer – Integrated CMDB mit Business/Customer/Supplier/User – Service – Application – Intrastrucutre Mapping

Knowledge Processing Layer mit Queries and Analysis, Reporting, Performance Management,

Modeling und Monitoring

Presentation Layer mit Portalen und Views für Change und Release, Asset Management, Configuration Life Cycle, Technical Configuration, Quality Management und Service Desk

Data

Information

Knowledge

Sommersemester 2013



Sommersemester 2013



Die Elemente des Configuration Management System (CMS) sind:

• CMDB

• Secure Library and Secure Store

• Definitive Media Library

• Definitive Spares

• Configuration Baselines

• Snapshots

Sommersemester 2013



Secure Libraries „Was gehört uns und was können wir nutzen“:

• Sammlung elektronischer CIs (SW, Dokumentation)

• Beschränkter und kontrollierter Zugriff

• Kontrolle und Freigabe von Komponenten im Service Lifecycle, z.B. für Design, SW-Builds, Test, Rollout und Betrieb

Secure Stores (Ersatzteillager)

• Lokation wo die IT-Vermögenswerte (HW) verwaltet werden

• Spielt eine wichtige Rolle für Security und Continuity Management

• Zugriff auf Equipment in definierter und bekannter Qualität

Sommersemester 2013



Definitive Media Library:

• Secure Library, in der die genehmigten Versionen aller Software CIs gespeichert sind

• Physikalische Lagerstätte, in der alle Masterkopien gelagert und geschützt werden (Tapes, DVD, CDs oder Disketten)

• Enthält sowohl Eigenentwicklungen als auch gekaufte Standardsoftware

• ESCROW (treuhänderische Hinterlegung) und ESCROW Agent

Was steht dazu im CMS bzw. in der CMDB

• Die logische Präsentation und Abbildung der SW CIs

Sommersemester 2013



Definitive Spare:

• Physikalisches Ersatzteillager (Secure Store) mit autorisierter und getesteter Hardware

• Enthält Einzelkomponenten und Systeme, die gepflegt werden wie vergleichbare Komponenten und Systeme in der Test- und Produktivumgebung

Was steht dazu im CMS bzw. in der CMDB

• Die logische Präsentation und Abbildung der HW CIs

Sommersemester 2013


Service Asset & Configuration Management –

Entscheidungen

Service Knowledge Management System

Configuration Management System

Configuration Management Database

Data

Information

Knowledge

Sommersemester 2013


Service Asset & Configuration Management – Zusammenfassung

• Configuration Management System (CMS)

• Configuration Items (CIs)

• Attribute: ID, Kategorie, Status, Relation

• Detailtiefe & Umfang

• Configuration Baseline

• Secure Store

• Defintive Media Library

• SACM Plan

Sommersemester 2013


Release and Deployment Management – Ziele

• Ziel des Release and Deployment Management ist die effektive und effiziente Überführung von Releases in die Produktionsumgebung

• Das Release Management fasst definierte Changes zusammen

• Eine Release ist die Zusammenstellung von Komponenten, die zusammen gehören und als Einheit ausgerollt werden

• Eine Release Unit ist der Teil eines IT Service der normalerweise zusammen eingeführt wird

• Wichtige Fragestellungen des Release and Deployment Management:

• Was soll zusammengestellt werden?

• Wie soll es ausgerollt bzw. deployed werden?

Sommersemester 2013


Release and Deployment Management – Release Design Optionen

• Big Bang & Phased RollOut

• Push & Pull RollOut

• Automatic & Manual RollOut

• Releases & Release Packages

Release Policy Release 1

Release 2

Release 3 1

2

3 1

1 2

2 3

3 4

5

WS X

5

4

*)

*) Additional Workstations

4 *

5 *

6 *

7 *

8 *

6

7

Initial Launch

„Big Bang“ RollOut

Phased RollOut

Sommersemester 2013


Release and Deployment Management – Release Package

Sommersemester 2013


Release and Deployment Management – Aktivitäten

• Planung

• Vorbereitung von Build, Test & Deployment

• Build & Test

• Service Test & Pilot

• Planung & Vorbereitung des Deployments

• Durchführung von Transfer, Deployment & Retirement

• Verifizierung

• Early Life Support

• Review & Abschluss von Deployment Transition

Sommersemester 2013


Release and Deployment Management – Service V-Modell

• Das Service V-Modell verbindet die Ebenen

• der Konfiguration mit denen des

• Tests

• Das Service V-Modell repräsentiert, wie die verschiedenen Konfigurationsebenen erstellt und getestet werden müssen um die geforderte „Service Capability“ zu liefern

• Die Linke Site zeigt die Spezifikationen der Serviceanforderungen bis zum Service Design

• Die Rechte Seite fokussiert sich auf die korrespondierenden Validation und Testaktivitäten

• What signifies the service V-model? Answer: The levels of configuration and testing

Sommersemester 2013


Release and Deployment Management – Service V-Modell

Sommersemester 2013


Release and Deployment Management – Servicesimulation

Der Fokus der Servicesimulation liegt normalerweise auf einer erfolgreichen Serviceumstellung an einem bestimmten Tag. Inklusive Vorbereitung, Analyse und Test sind jedoch meist mehrere Durchläufe erforderlich. Typische Stufen, basierend auf dem Deming Cycle beinhalten folgende Aktivitäten:

• Plan – Vorbereitung der Simulation

• Do – Durchführung der Simulation

• Check – Dokumentation der Simulation

• Act – Reaktion auf der Ergebnisse der Simulation

Nach Auswertung der Ergebnisse der Simulation bestehen folgende Möglichkeiten:

• Der Service hat die Simulation ohne größere Beanstandungen bestanden und liefert die erwarteten Ergebnisse

• Der Service Rollout wird zum aktuellen Zeitpunkt nicht empfohlen. Der Service wird mit Verbesserungsvorschlägen zurück an CSI (Continual Service Improvement) , Service Design und Service Transition Management gegeben

Sommersemester 2013


Release and Deployment Management – Zusammenfassung

• Release Policy

• Release Unit

• Service V Model

• Release Design Option

Sommersemester 2013


Service Transition – Zusammenfassung

• Änderungen an Services oder Service-Komponenten planen und managen

• Service Releases erfolgreich in die Produktionsumgebung überführen

• Planungssicherheit

• Störungsfreies Implementieren und Umsetzen der Veränderungen

• Transition Planning und Support

• Change Management

• Service Asset and Configuration Management

• Release and Deployment Management

Sommersemester 2013


Das war der 3. Teil

Weiter geht es mit Service Operation

it infrastrukturit-infrastrukturen.de/docs/01_it infrastructures_part-3-mba-ss2013.pdf ·...

Documents