IT-Service Management nach ITIL - Mit kontrollierten Prozessen zur optimalen IT-Struktur -

Dr. Rüdiger Armann, MediaStudio GmbH

MediaStudiofür Marketing und Multimedia Gmbh

• Geschäftsführer: Horst Neumann• Themenschwepunkte

– eBusiness + eMarketing: Bert Branahl, Thomas Werning

– Wissensmanagement: Dr. Jochen Köhler

– IT Service Management: Dr. Rüdiger Armann

• ITIL im Überblick– Die Entstehung von ITIL– Die Entwicklung der Versionen

• Das Konzept der "Best Practices" und KPIs– Beispiele aus ITIL-Diziplinen

• Service Level Agreements– SLA aus Sicht des Kunden– SLA aus Sicht des IT-Providers

• Ein Ausblick zur Entwicklung von ITIL

Agenda

Gartner zu ITIL

Ein interner IT-Dienstleister der heute seine Leistungserstellungsprozesse nicht an ITIL ausrichtet, wird in 2-3 Jahren outgesourct sein.

Gartner (2003)

Was bringt uns ITIL?

Der Status

• Die IT-Strategie unterliegt einer vorwiegend technologischen Betrachtung• Die Leistungsangebote der IT-Organisation sind dem internen/externen

Kunden nicht verständlich• Die Leistungserfüllung ist nicht messbar und kann damit nicht verbindlich

geregelt werden• Die Leistungsfähigkeit der eigenen IT-Organisation wird nicht an denen

vergleichbarer Anbieter gebenchmarkt• Unzufriedene Anwender und IT-Mitarbeiter, überlasteter UHD

• Der interne/externe Kunde hat stets den Eindruck, dass seine IT zu teuer ist• Der IT-Dienstleister hat stets den Eindruck, dass er mehr leistet als er dafür

bekommt

• Die "IT Infrastructure Library-Richtlinien wurden von der CCTA (jetzt OGC) in Norwich, England, für die britische Regierung entwickelt.

• ITIL ist die IT Infrastructure Library.• ITIL beschreibt das IT Service Management.• GartnerGroup: ITIL ist die einzige umfassende und öffentlich verfügbare

fachliche Anleitung zur Planung, Erbringung und Unterstützung von IT-Dienstleistungen.

• ITIL ist ein weltweiter de-facto Standard.• An der Entwicklung von ITIL waren IT-Dienstleister, Mitarbeiter aus

Rechenzentren, Lieferanten, Beratungsspezialisten und Ausbilder beteiligt.• ITIL enthält „best practices“.

Zur Entstehung von ITIL

Vorteile von ITIL

• Eindeutiges Bezugssystem für die gegenseitige Kommunikation• Merklich besser beherrschte Veränderungsprozesse innerhalb der IT• Eine prozessoptimierte Kostenoptimierung auf taktischer Ebene• Eine systematische und übersichtliche Organisation• Eine veränderte Unternehmenskultur, die sich positiv auf die IT-

Dienstleistungen auswirkt• Ein Maßstab für Professionalität

Was ist ITIL nicht?

• Ein Tool: ITIL wird nicht im herkömmlichen Sinne eingeführt und ist dann für alle Zeit vorhanden, sondern es stellt ein Bezugssystem für die Abläufe und Prozesse in der Organisation dar.

• Ein Allheilmittel: Vieles muss selber erarbeitet und mit den eigenen Erfahrungen und Anforderungen angereichert werden

• Ein starres Prozessmodell: Auf der Grundlage der am Markt vorhandenen Modelle entwickelt jede Organisation ihr eigenes Modell

Darstellungen von ITIL (1)

Darstellungen von ITIL (2)

Darstellungen von ITIL (3)

Zur Servicedefinition

Kunden-GeschäftsprozesseGeschäfts-Prozess-Ebene

Service-Ebene

System-/Leistungs-Ebene

Komponenten-Ebene

Man

agem

entp

roze

sseW

erts

chöp

fung

s-Pr

ozes

seBe

trie

bs-

und

Supp

ort

Proz

esse

Kund

ensi

cht

IT -

Sich

t

Service

System

Komponente Komponente Komponente Komponente Komponente

Leistung System Leistung

Service

Leistung

Externe Lieferanten

• Incident => Störung oder Service Request• Tatsächliche oder absehbare Beeinträchtigung der vereinbarten

Serviceleistung• Störungen können ihre Ursachen in verschiedenen Bereichen der

Infrastruktur haben

Beispiel: Incident Management

Häufige Ausgangssituation

• Vorgänge der Störungsbeseitigung und der Ursachenbeseitigung sind zusammengefasste Prozesse

• Im Bestreben gute Arbeit zu leisten, werden direkt kontaktierte Spezialisten versuchen, den gemeldeten Fehler zu korrigieren: „Wenn wir schon in unserer Arbeit gestört worden sind, dann beseitigen wir gleich die Ursache.“

• Der Anwender, der die Störung gemeldet hat, gerät in Vergessenheit (Bearbeitungsdauer, Distanz des Problemlösers)

• Der Anwender weiß nicht, ob und wann die Störung beseitigt ist.

• Das Incident Management besteht praktisch aus rein reaktiver Tätigkeit: Feuerwehreinsatz, wenn etwas geschehen ist.

15

Das Ziel des Incident Managements

• Das Incident Management zielt darauf,

–im Fall eines Zwischenfalles

–den vereinbarten Service

–so schnell wie möglich (mindestens in der vereinbarten Zeit)

–mit minimalen Auswirkungen für die Anwender

wiederherzustellen.

16

Incident Management Aktivitäten

• Zur Erfüllung der Aufgabe des Incident Managements gehören folgende sechs Aktivitäten:

– Erkennung und Dokumentation eines Incidents

– Klassifikation und Soforthilfe (Einordnung der Anfrage nach Symptom, System, Service Level)

– Diagnose des Incidents (Work-around finden, Zusammenhänge erkennen)

– Lösung/Behebung des Incidents und Wiederherstellung des Service

– Schließen des Incidents (einschließlich Nachprüfung, Zuordnung der Kategorie)

– Verfolgung der Incident-Bearbeitung (Ownership, Überwachung und Auswertung, Verfolgung, Information an den Anwender)

Prozessübersicht (Bsp. Incident Mgnt.)

• Eigner des Incident Mgnt.-Prozesses• Zweck des Prozesses• Scope des Prozesses• Ablauf des Prozesses

– Input ProzesschritteOutput

• Aufgaben des Incident Managers• Involvierte Rollen• Tools• KPIs

Empfohlene KPIs zum Incident Mgnt.• Kundennutzen

– Dauer der Störung, Wiederherstellungszeit– Sicherheitsbeeinträchtigungen– Einhaltung der SLA– Lösungsqualität

• Prozessqualität– Einhaltung der Supportvereinbarungen (OLA, UC)– Reaktionszeit 2nd Level– Erreichbarkeit 1st/2nd Level– Eigenlösungsrate 1st Level

• Kosten– Support/Prozesskosten– TCO, verdeckte IT-Kosten

• Sicherheit– Sicherheitsbeeinträchtigungen

• Verbindung zu anderen Prozessen– Unterstützung des Incid. Mgnt. durch Config. Mgnt.– Unterstützung des Incid. Mgnt. durch Problem Mgnt.– Info des Incid. Mgnt. durch Change- und Release Mgnt. über Änderungen + deren Auswirkungen

Best Practice im Incident Management

• Verwendung eines Tools zur Vereinfachung/Automatisierung• Trennung von Incident und Problem Management• Schnittstelle zwischen Incident Management Tool und

Configuration Management Data Base, um

– vollständige Information über die Anwender zu erhalten

– Incidents und Lösungen zu dokumentieren

– automatische Eskalation an hinterlegte Service Levels

anzubinden

Best Practises im Problem Mgnt.

• Zur Einführung des reaktiven Problem Managements konzentriert man sich auf die täglichen Top Ten der Incidents.

• Nicht jeder bekannte Fehler muss beseitigt werden. Kosten und Nutzen sind immer abzuwägen.

• Fehler können nicht-technischer Natur sein und z. B. in widersprüchlichen Verfahren gründen. Auch für Änderungen von Verfahren werden RFCs gestellt.

Best Practises im Service Desk

• Standardisierte Erfassung der Anruferdaten• Automatische Vergabe einer ID der Anfrage, Zusendung

einer Empfangsbestätigung und eines Feedback Formulars

• Punktuelle Pflege der Anwenderdaten • Einsatz von ACD für Ansagen, Anrufererkennung,

Routing an verfügbare Mitarbeiter• Ausnutzung des System Monitoring zur Früherkennung

von Beeinträchtigungen des Service• Personal aus dem Second Level Support wird zeitweise

im Service Desk eingesetzt.• Große Service Desks gliedern sich in Teams mit

speziellem Know-how, unterstützt durch Skill Routing.• Zusammenarbeit mit Super Usern

Beispiel-KPIs im Availability Mgnt.

Beispiel: Verfügbarkeitsvereinbarung vereinbart

Verfügbarkeit Verfügbarkeit in Prozent 98,00%

Uptime Gesamtzeit die das System verfügbar war

UT gemessen in Stunden 205,80

Downtime Summe der während der vereinbarten Betriebszeit auftretende Ausfallzeiten

DT gemessen in Stunden 4,20

Agreed Service Time Betriebszeit in Std. pro Monat abzüglich Wartung usw.

AST gemessen in Stunden 210,00

Downtime Max Dauer des längsten Ausfalls im Berichtszeitraum

DT Max gemessen in Stunden 1,00

Anzahl Ausfälle Gesamtzahl der Ausfälle pro Berichtszeitraum/Monat 2

Mean Time Between Failures Durchschnittliche Uptime des Systems

MTBF gemessen in Stunden 102,90

Mean Time to Recover Durchschnittliche Zeit zwischen dem Auftreten des Ausfalls bis Ende Recovery

MTTR gemessen in Stunden 2,10

Mean End User Dowtime Mit der durchschnittlichen Anzahl der Nutzer pro Stunde gewichtete Ausfallzeit

M-EUDT gemessen in Stunden 2184,00

Mean End User Downtime Costs Multiplikation der M-EUDT mit dem Standardkostensatz(h)

M-EUDC gemessen in Euro 65.520,00 €

M-EU /h Durchschnittliche Anzahl der Nutzer pro Stunde in der AST

gemessen in Anzahl 520

Standardkostensatz Standardkostensatz der Mitarbeiterstunde

gemessen in Euro 30,00 €

Das Service Level Management (SLM)

• IT-Organisationen, die ihre Service-Strategie an den Geschäftsprozessen ihrer Kunden ausrichten, werden die bessere Wettbewerbsposition haben (Business and IT-Alignment).

• Immer mehr Kunden fordern von ihren IT-Dienstleistern SLAs• Auch der Kunde braucht SLA-Beratung• Anforderungskataloge (SLRs) gemeinsam erstellen

(gefühlte Servicequalität)• SLM als Grundsatz und nicht als Behörde

BP

IT

supports

ITSM

controls

ITIL

describes

Das Service Level Management (SLM)

Config. Mgnt.

CI & Attribute; SLA;

OLA & UC; Kunden;

Servicekatalog

Availability Mgnt.

Impacts;

Verfügbarkeitsanforderungen;

Service Levels

Release Mgnt..

Impacts

Service

Level

ManagementCapacity Mgnt.

Leistungsanforderungen des

Business;

Security Policy

Continuity Mgnt.

Impacts;

Verfügbarkeitsanforderungen

Kunde/Anwender

SLA;

Service Level Reports;

Servicekatalog

Lieferanten

Feedback Leistungsqualität;

UC

Organisation/Management

OLA; Service Level Reports;

SIP

Service Katalog

Financial Mgnt.

Vereinbarte Services & Kosten;

vereinbarte Leistungen & Kosten

Incident Mgnt.

Supportlevelvereinb. (SLA,

OLA, UC); vereinbarte

Services; Impacts

Problem Mgnt.

Supportlevelvereinb. (SLA,

OLA, UC); Impacts

Change Mgnt.

Impacts; RfC

Service Level Agreements

Kunden-GeschäftsprozesseGeschäfts-Prozess-Ebene

Service-Ebene

System-/Leistungs-Ebene

Komponenten-Ebene

Man

agem

entp

roze

sseW

erts

chöp

fung

s-Pr

ozes

seBe

trie

bs-

und

Supp

ort

Proz

esse

Kund

ensi

cht

IT -

Sich

t

Service

System

Komponente Komponente Komponente Komponente Komponente

Leistung System Leistung

Service

Leistung

Externe Lieferanten

SLA

OLA

UC

Best Practices im Service Level Mgnt.

• Einführung des Service Level Managements– Planung des Prozesses– Implementierung des Prozesses

• Einführung von SLAs– Erstellen des Service Portfolios– SLA-Entwurf– Verhandlung– Abschluss von SLAs

• Laufender Prozess– Überwachen – Berichten – Review

Der SLM-Prozess

ITIL V3

Beziehungen zwischen ITIL V2 und V3

Was bringt ITIL V3 ?

ITIL V2 ist NICHT veraltet ITIL V3 ist in sich konsistenter ITIL V3 ist skalierbarer Zahlreiche Praxiserfahrungen wurden

eingearbeitet ITIL wird selbst zum Service

(z.B. Web Support Services) Zertifizierung nach ISO 20000

ITIL ist erwachsen geworden!Björn Hinrichs, itSMF Deutschland

Entwicklungsstand des ITSM

Zitate

• „Zuerst haben wir die eierlegende Wollmilchsau gesucht. Da diese bekanntlich schwer zu finden ist, beschlossen die Beteiligten, die 89 Prozessschritte für die Suche nach einer geeigneten Software auf 13 Hauptprozesse zu reduzieren.“

Alhard Horstmann, Projektleiter, Siemens Power Generation

• „Ich kann mir nicht vorstellen, dass Outsourcing und IT-Dienstleister ohne ITIL-Zertifikat künftig Services verkaufen können.“

Stefan Elbs, IT-Leiter bei BT Germany

• „Ich würde jedem internen IT-Dienstleister eine regelmäßige Selbstkontrolle empfehlen, wie sie auch der ITIL-Standard vorsieht.“

Simon Mingay, Gartner-Analyst

Herzlichen Dank!

Dr. Rüdiger Armann, MediaStudio GmbH