1. 1 / 55
Service Operation mit ITIL
Christian Habermüller
http://news.fuer-IT-Profis.de

2. 2 / 55
Was ist ITIL ?
• IT Infrastructure Library
– Internationaler de facto Standard im IT-Service
Management
• Unabhängige Betrachtung von IT-
Serviceleistungen
– Herstellerunabhängig
– nicht verbindlich
– aber genormt durch ISO/IEC 20000

3. 3 / 55
Definition Service
Ein Service erbringt für einen Kunden einen
Mehrwert, indem er die Kundenziele
unterstützt, verbessert oder überhaupt erst
ermöglicht.
Dabei muss der Kunden selbst keine
Verantwortung für bestimmte Kosten und
Risiken tragen !

4. 4 / 55
Ziele und Anliegen in
Service Operation
• Lieferung von Service an den Kunden bzw.
seine Anwender
• Verwalten der Bereitstellungsprozesse
• Verwalten der zugrunde liegenden
Technologien
• Messen & Überwachen

5. 5 / 55
Aufgaben in Service Operation
• Notwendige Aktivitäten planen, Betrieb und
Finanzierung sicherstellen
– Mit geeigneten Werkzeugen und Training
• Unvorhergesehenes mit ein rechnen
– Unvorhergesehene Störungen
– Unvorhergesehener Bedarf

6. 6 / 55
Service aus zwei Perspektiven
betrachtet
• IT-Perspektive
• Versprechen, was
geht
– Stabilität
– Qualität
– Reaktives Handeln
• Geschäfts-Perspekt'
• Liefern, was
gebraucht wird
– Reaktionsfreudigkeit
– Kosten
– Proaktives Handeln

7. 7 / 55
Prozesse & Funktionen in
Service Operation
• Prozesse
– Event Mngmt
– Incident Mngmt
– Problem Mngmt
– Request Fulfillment
– Access Mngmt
• Funktionen
– Service Desk
– Technical Mngmt
– IT Operations Mngmt
– Applications Mngmt

8. 8 / 55
Prozesse

9. 9 / 55
Definition Process
Ein Process ist ein strukturierter Satz von
Aktivitäten, der einen klar definierten Input
zu einem oder mehreren klar definierten
Outputs umwandelt.
Er beinhaltet beliebig viele Rollen,
Verantwortlichkeiten und Hilfsmittel und kann
Richtlinien, Standards, Leitlinien, Aktivitäten
und Arbeitsanweisungen definieren.

10. 10 / 55
Eine Rolle wird in einem Process definiert
und ist ein Satz von Verantwortlichkeiten,
Aktivitäten und Kompetenzen, die einem
Team oder einer Person zugewiesen sind.
Einer Person oder einem Team können mehrere
Rollen zugewiesen werden.
Definition Rolle

11. 11 / 55
Prozess Event Management

12. 12 / 55
Definition Event
Ein Event ist eine Benachrichtigung aufgrund
einer Statusänderung durch einen Service,
einen Configuration Item oder einen
Monitoring Tool.

13. 13 / 55
Ziele Event Management
• Informationen über
– Status der Infrastruktur
– Abweichungen von erwarteten Betrieb auf Basis
von Service Level Agreements
• Event Management ist die Basis für
Betriebsüberwachung & -steuerung !

14. 14 / 55
Arten von Events
• Information
• z.B. eine Aufgabe ist erledigt
– hat rein informative Zwecke
• Warning
– Der Service ist noch betriebsbereit aber
erfordert ein Eingreifen
• Alert
– Der Service ist nicht mehr vollständig
betriebsbereit

15. 15 / 55
Design für Event Management
• Wie können IT-Infrastruktur und IT-
Services überwacht und beeinflusst
werden ?
• Wie wird überwacht ?
• Wie werden Events erzeugt ?
• Welche Schwellwerte sind notwendig ?
• Welche Filter werden benötigt ?

16. 16 / 55
Rollen in Event Management
(1/2)
• Service Desk
– Üblicherweise nicht eingebunden
• lediglich Informationsstelle für Anwender
• IT Operations Management
– Wenn als separate Funktion vorhanden: Event
Management ausführen

17. 17 / 55
Rollen in Event Management
(2/2)
• Technical Management und Applications
Management
– Während Design: Instrumentierung & Event-
Klassifizierung
– Während Transition: Test der Event-Erzeugung
– Während Operation: Event Management
ausführen

18. 18 / 55
Prozess Incident Management

19. 19 / 55
Ein Incident ist eine Qualitätsminderung oder
eine ungeplante Unterbrechung eines Service.
Auch ein Ausfall eines Configuration Item
ohne bisherige Auswirkungen auf einen
Service ist ein Incident.
Beispiel: Der Ausfall einer einzelnen Festplatte
in einem RAID5-Verbund.
Definition Incident

20. 20 / 55
Definition Workaround
Ein Workaround reduziert oder beseitigt die
Auswirkungen von Incidents oder Problems,
bevor noch eine vollständige Lösung
vorhanden ist.
Workarounds für Problems werden in Known
Error Records dokumentiert, während
Workarounds ohne Problem Records in
Incident Records dokumentiert werden.

21. 21 / 55
Definition Problem
Ein Problem ist die Ursache für einen oder
mehrere Incidents.
Zum Zeitpunkt der Erstellung eines
Problem Record ist die Ursache in der Regel
noch unbekannt.
Für die weitere Untersuchung ist der Problem
Management Prozess verantwortlich !

22. 22 / 55
Auswirkung / Schaden
Hoch Mittel Niedrig
Dringlichkeit
Hoch 1 < 1h 2 < 8h 3 < 24h
Mittel 2 < 8h 3 < 24h 4 < 48h
Niedrig 3 < 24h 4 < 48h 5 Planung
Prio
Lösungs-
zeit
Auswirkung
Dringlichkeit
Priorität
angestrebte
Lösungszeit

23. 23 / 55
Definition Major Incident
Ein Major Incident ist die höchste Kategorie
eines Incident und führt zu einer erheblichen
Unterbrechung des Business.
Incidents dürfen nicht mit Problems
verwechselt werden !

24. 24 / 55
Major Incident erfordert ...
• … eine Vereinbarung, was ein solcher ist !
• Separate Prozeduren
– Kürzere Zeiten
– Höhere Dringlichkeit
– evtl. Major Incident Team erforderlich

25. 25 / 55
Incident Management
Messgrößen
• Gesamtzahl der Incidents
• Rückstand des Incidents
• Mittlere Zeit bis zur Lösung bzw. zum
Workaround
• Prozentzahl der Incidents, die innerhalb der
definierten Antwortzeit behandelt wurden
– Direktlösungsquote

26. 26 / 55
Prozess Problem Management

27. 27 / 55
Definition Known Error
Ein Known Error ist ein Problem, für das die
Ursache und ein Workaround dokumentiert
wurde.
Für die Erstellung und Verwaltung von Known
Errors ist das Problem Management
verantwortlich !

28. 28 / 55
Zwei Problem Management
Prozesse
• Reaktiv
– Reaktion beim
Auftreten
– Aufgabe des Problem
Management
– Teil der Service
Operation
• Proaktiv
– Vorausschauend vor
dem Auftreten
– Teil des Continual
Service Improvment
– Initiiert in Service
Operation

29. 29 / 55
Rollen in Problem Management
• Problem Manager
– Prozessverantwortlicher und Verwalter der
KEDB
– Schließt Problem Record
• Operative Problemlösungsgruppe
– Technischer Mitarbeiter
– Analyse, Diagnose
– kann bei speziellem Problem extra
zusammengestellt werden

30. 30 / 55
Prozess Request Fulfillment

31. 31 / 55
Ein Service Request ist eine Anfrage eines
Anwenders nach Informationen, Beratung,
einem Standard Change oder nach Zugriff auf
einen Service.
Service Requests werden in der Regel von einem
Service Desk bearbeitet und erfordern
üblicherweise nicht die Einreichung eines
Request for Change.
Definition Service Request

32. 32 / 55
Ziele Request Fulfilment
• Information für Anwender
– Welche Services gibt es ?
– Wie kann man diese nutzen ?
– Anfragen nach Standard Services
• Beschaffung des Services & der dazugehörigen
Komponenten

33. 33 / 55
Ein Service Request befasst sich nicht mit
Incidents oder Changes !
Vielmehr wird dabei ein vordefiniertes
Vorgehen (Standard Change) durch den
Anwender abgerufen, der mitunter vom
Change Management vorab autorisiert wurde !

34. 34 / 55
Prozess Access Management

35. 35 / 55
Ziele Access Management
• Steuern der Rechte- & Zugriffe der
Anwender
• Ausführen von Richtlinien & Aktionen
– Aus dem Security Management
– Aus dem Availability Management

36. 36 / 55
Begriffe im Access Management
• Access
– Umfang & Stufe des Service, zu deren Nutzung
der Anwender berechtigt ist
• Identity
– Eindeutige Kennung zur Identifikation des
Anwenders = Person oder Rolle
• Authority
– Berechtigungen, die einer Identity gegeben
werden, um Access zu ermöglichen

37. 37 / 55
Funktionen

38. 38 / 55
Eine Function ist ein Team oder eine Gruppe
von Personen und deren Hilfsmittel, die
eingesetzt werden, um einen oder mehrere
Processes oder Aktivitäten durchzuführen.
Eine Function ist also eine Einheit einer
Organisation !
Definition Function

39. 39 / 55
Funktion Service Desk

40. 40 / 55
Ziele Service Desk
• Single Point of Contact
– Erste Informationsstelle für Anwender für
Diagnosen & Nachforschungen
• Direkte Lösung, wenn möglich
• Wenn keine direkte Lösung in gegebener Zeit ...
– … dann Eskalation an entsprechendes Management
• Aufnahme & Abschließen von
• mit den dazugehörigen Records
– Incident und Problem
– Service Requests
– Access Requests

41. 41 / 55
Arten von Service Desks
• Lokaler Service Desk
– Ein Service Desk pro Firmenstandort
• Zentraler Service Desk
– Ein Service Desk für die gesamte Organisation
• Virtueller Service Desk
– Die Anfragen werden über ein System auf
mehrere Service Desks verteilt
– Vor allem bei 24/7-Verfügbarkeit

42. 42 / 55
Messgrößen für Service Desk
• Erstlösungsrate
• Mittlere Lösungszeit (direkt)
• Mittlere Eskalationszeit
• Mittlere Service Desk Kosten pro Incident,
pro Anruf, pro Minute etc.
• Kunden- und
Anwenderzufriedenheitsumfragen

43. 43 / 55
Rollen in Service Desk
• Service Desk Analyst
– First Level Support
• Ansprechpartner für Anwender
• Service Desk Supervisor
– Schichtplanung
– Eskalationspunkt
• Service Desk Manager
– Generelle Verantwortung (nur bei großen
Organisationen)

44. 44 / 55
Funktion Technical Management

45. 45 / 55
Ziele Technical Management
• Stabile technische Infrastruktur
– Planung, Implementierung & Aufrechterhaltung
• Gut gestaltete technische Infarstruktur
– Kosteneffizient
– Hoch belastbar
– unverwüstlich
• Optimaler Betriebszustand
– Rasche Fehlerdiagnose & -lösung

46. 46 / 55
Funktion Applications Management

47. 47 / 55
Ziele in Applications
Management
• Funktionierende, stabile & verwaltbare
Applikationen
– Anforderungen erkennen
– Design & Entwicklung unterstützen
– Fortlaufenden Support & Verbesserung liefern
– Rasche Fehlerdiagnose & -lösung
• Gut gestaltete Applikationen
– Kosteneffizient
– Features unterstützen Business Process

48. 48 / 55
Funktion IT Operations Management

49. 49 / 55
Ziele IT Operations Management
• Stabiler Betrieb des aktuellen Zustandes
– Betriebssteuerung & Anlagenwartung
• Überwachung der Ausführung von
Betriebsaktivitäten & Events
• Verwaltung der physischen IT-Umgebung
• Regelmäßige Untersuchungen
– Stabilität aufrecht erhalten
– Kosten senken
– Service verbessern
• Schnelle Diagnose & Lösung bei Störungen

50. 50 / 55
Überlappende Zuständigkeiten

51. 51 / 55
Applications
Management
Technical
Management
IT
Operations
Management

52. 52 / 55
Das ist IBM Lotus Notes Domino!
(1/2)
• Teamfähige Kommunikations-Software
– Informationen werden nicht in Echtzeit
ausgetauscht
– Intra-/Internet-Fähig
• Hochsicherheitssystem
– Für sensible Daten
• Dezentral in der Datenhaltung
– Daten können verteilt werden, auch Off-Line

53. 53 / 55
Das ist IBM Lotus Notes Domino!
(2/2)
• Programmierbar
– IBM Lotus Notes Domino verfügt über 4
integrierte Programmierunterstützungen
• Formelsprache
• Lotus Script
• JavaScript
• Java
• Dokumentenorientiert
– Jeder Datensatz kann eine individuelle
Datenstruktur haben

54. 54 / 55
Diese Präsentation ist urheberrechtlich geschützt.
© 2010 Christian Habermüller – http://chabermu.wordpress.com
Alle Rechte vorbehalten.
Kein Teil dieser Präsentation darf ohne schriftliche Genehmigung
des Autors in irgendeiner Form durch
Fotokopie, Mikrofilm, Scannen, Download oder andere Verfahren
reproduziert, gespeichert, wiedergegeben oder verbreitet werden.
Insbesondere die Rechte der Wiedergabe durch Vortrag, Funk,
Fernsehen und Internet sind dem Autor vorbehalten.
Jede Zuwiderhandlung wird zivil- & strafrechtlich verfolgt.

55. 55 / 55
Diese Präsentation ist ausschließlich für den informativen Einsatzzweck gedacht und wird
als diese ohne jegliche Garantie oder Gewährleistung bereitgestellt.
Der Autor ist ausdrücklich nicht haftbar für mögliche Folgen oder mögliche Schäden, die
durch die Verwendung des bereitgestellten Materials entstehen können oder könnten.
Hinweise, Verweise oder Verknüpfungen bzw. Links in diesem Material unterliegen
ebenfalls diesem Haftungsausschluß und sind Eigentum des jeweiligen Rechteinhabers.
Die Rechte von geschützten Markennamen, Handelsmarken sowie alle weiteren Rechte
unterliegen dem jeweiligen Rechteinhaber und bzw. oder des Eigentümers derselben.