Überblick über ITILv3, Teil 2
Von der Strategie zum IT-Betrieb
ITIL (IT Infrastructure Library) ist das etablierte Regelwerk für die professionelle Umsetzung der ITSM-Prozesse (IT-Service-Management) zur Erbringung von IT-Services. Nachdem Teil 1 dieses Beitrags die ersten beiden Service-Lifecycle-Phasen Service-Strategy und Service-Design vorgestellt hat, thematisiert der zweite Teil nun die Prozesse und Funktionen der verbleibenden drei Phasen: Service-Transition, Service-Operation und Continual Service- Improvement.
Die aktuelle Version 3 von ITIL kommt in Kürze in deutscher Sprache auf den Markt. Das
strukturgebende Element von ITILv3 ist der Service-Lifecycle mit den fünf Kernphasen
Service-Strategy, Service-Design, Service-Transition, Service-Operation und Continual
Service-Improvement. Jeder dieser Phasen ist ein ITIL-Buch gewidmet. Die Bücher zu Service-Strategy
und Service-Design sind im Beitrag "Business trifft IT" (www.lanline.de/kn31450041) im Überblick
dargestellt.
Buch 3: Service-Transition
Service-Transition beschreibt, wie ein Service-Provider die im Service-Design umgesetzte
Strategie (Service-Strategy) effektiv in den Betrieb (Service-Operation) überführen kann. Ziel von
Service-Transition ist es, die Planung und Durchführung von Service-Änderungen (Changes) zu managen
und Service-Releases erfolgreich in der Produktivumgebung zu implementieren. Service-Transition
plant und steuert die Paketierung, Erstellung, Bewertung, das Testen und die Implementierung der
Releases. Effiziente und wiederholbare Methoden überprüfen, ob die Releases mit den Anforderungen
übereinstimmen. Zudem verantwortet Service-Transition Aufbau und Aufrechterhaltung der Integrität
aller Service-Assets und Configuration Items (CIs) in einem Configuration-Managementsystem (CMS).
Bei dieser Phase geht es somit um die Fragen: Wie werden Changes und Releases geplant, erstellt,
getestet und implementiert, ohne dass sich dies negativ auf die Produktivumgebung auswirkt? Wie
sind Informationen und Wissen zu speichern und bereitzustellen? Wie lässt sich die Integrität aller
Service-Assets und CIs aufrechterhalten?
Service-Transition umfasst sieben Prozesse: Transition Planning and Support, Change-Management,
Service-Asset- and Configuration-Management, Release- and Deployment-Management, Service-Validation
and Testing, Evaluation und Knowledge-Management.
Transition Planning and Support führt die übergeordnete Planung der Phase Service-Transition
durch. Dieser Unterstützungsprozess koordiniert die Kapazitäten und Ressourcen, die die anderen
Prozesse innerhalb von Service-Transition benötigen, um ihre Aufgaben zu erledigen.
Als Change wird jedes Hinzufügen, Modifizieren oder Entfernen von Elementen bezeichnet, das sich
auf IT-Services auswirkt. Das Change-Management prüft und genehmigt Änderungsanträge (Requests for
Change, RFCs) und steuert, koordiniert und kontrolliert die Implementierung von Changes. Das eng
mit dem Change-Management verknüpfte Service-Asset- und Configuration-Management hat die Aufgabe,
die Changes im CMS zu speichern.
Dieser Kernprozess beantwortet folgende Fragen: Wie lassen sich Changes effektiv bearbeiten und
negative Auswirkungen fehlgeschlagener Changes minimieren? Wie ist sicherzustellen, dass Changes an
Service-Assets und CIs systematisch aufgezeichnet, ausgewertet, genehmigt, priorisiert, geplant,
getestet, implementiert, dokumentiert und überprüft werden? Wie erfüllt das Unternehmen rechtliche,
vertragliche und behördliche Anforderungen an transparente Change-Prozesse?
Der Prozess Service-Asset- and Configuration-Management (SACM) pflegt die Informationen über
Service-Assets und CIs einschließlich ihrer Beziehungen untereinander. SACM speichert sie im CMS ab
– das die aus ITILv2 bekannte CMDB (Configuration Management Database) beinhaltet. Das CMS umfasst
auch die Definitive Media Library (DML), die alle freigegebenen Softwareversionen sowie
Dokumentationen und Lizenzen enthält. Sie löst die Definitive Software Library (DSL) aus ITILv2
ab.
Dieser Prozess identifiziert, kontrolliert, protokolliert, prüft und verifiziert Service-Assets
und CIs und schützt ihre Integrität während des gesamten Lebenszyklus. SACM beantwortet die
zentralen Fragen: Wie verwaltet man Service-Assets und CIs möglichst effektiv und effizient, sodass
dies die andere Prozesse durch zuverlässige und exakte Informationen unterstützt? Wie sind diese
Informationen zentral im CMS bereitzustellen? ITILv2 bezeichnete diesen Prozess als
Configuration-Management.
Ein Release besteht laut ITIL aus Hardware, Software, Dokumentation, Prozessen und weiteren
Komponenten, die erforderlich sind, um genehmigte Changes an einem IT-Service durchzuführen. Das
Release- and Deployment-Management plant, installiert, testet, verifiziert und deinstalliert
Releases. Es gibt Komponenten gemäß der Release-Richtlinien frei und stellt so die Integrität der
Produktivumgebung sicher. Deployment – auch als Rollout bezeichnet – bedeutet, Releases in die
Produktivumgebung zu überführen. ELS-Aktivitäten (Early Life Support, Unterstützung in der
Anfangsphase einer Serviceeinführung) sind ebenfalls hier angesiedelt.
Der Prozess adressiert folgende Fragen: Wie lassen sich genehmigte Changes zu minimalen Kosten
und mit minimalem Risiko schnellstmöglich umsetzen? Wie gewährleistet man Kontinuität bei der
Implementierung von Releases, zum Beispiel in Form eines einheitlichen Implementierungsansatzes,
wie eine überprüf- und nachweisbare Rückverfolgung von Changes innerhalb der
Service-Transition-Phase? ITILv2 bezeichnete diesen Prozess als Release-Management.
Die Hauptaufgabe von Service-Validation and Testing ist die Qualitätssicherung eines Releases,
seiner Bestandteile, des zugehörigen IT-Services und der Servicefunktionalität, die ein Release
erbringt. Service-Validation and Testing stellt sicher, dass neue oder geänderte IT-Services den
Anforderungen gerecht werden und ihren Entwicklungsvorgaben sowie Designspezifikationen
entsprechen. Dieser Prozess identifiziert, bewertet und bearbeitet Fehler und Risiken innerhalb
eines Releases und orientiert sich dabei am V-Modell. Wie lassen sich also Fehler so frühzeitig wie
möglich eliminieren, um die Kosten eines IT-Services im Lifecycle insgesamt zu minimieren? Wie
entsteht Vertrauen dafür, dass IT-Services erfolgreich in die Produktumgebung überführt werden und
dort den geforderten Mehrwert liefern?
Evaluation bewertet die Funktionalität oder Leistung eines neuen oder geänderten IT-Services und
unterstützt das Change-Management dabei, zu entscheiden, wie mit einem Change zu verfahren ist.
Evaluation basiert auf den Designspezifikationen der Phase Service-Design und den von
Service-Validation and Testing erstellten Berichten. Der Prozess hinterfragt, wie die
Funktionalität beziehungsweise Leistung eines neuen oder geänderten IT-Services bestimmt wird, wie
sich dessen tatsächliche Leistung im Vergleich zu der erwarteten Leistung darstellt, ob ein
IT-Service den erwarteten Mehrwert liefert und welche Risiken ein Service-Change mit sich
bringt.
Das Knowledge-Management sammelt, analysiert, speichert und verteilt Informationen und Wissen
innerhalb einer Organisation. Es verbessert die Qualität von Entscheidungen, indem es verlässliche
Informationen für alle Phasen des Service-Lifecycles bereitstellt. Das Knowledge-Management
arbeitet idealerweise mit einem zentralen Service-Knowledge-Managementsystem (SKMS). Das SKMS
basiert auf dem CMS und den zugrunde liegenden Datenbanken. Knowledge-Management beantwortet die
Fragen, welche Daten und Informationen sowie welches Wissen aufzuzeichnen und zu verteilen ist, wie
sich verwertbare Erkenntnisse aus den Daten generieren lassen und wie man Wissen zum Beispiel mit
Anwendern, Support-Mitarbeitern und Lieferanten teilen kann.
Buch 4: Service-Operation
Service-Operation behandelt den laufenden IT-Betrieb. Es geht darum, wie man IT-Services und
Prozesse im Betrieb steuert und kontrolliert und welche technikbasierten Aktivitäten (etwa
Monitoring, Netzwerk- und Server-Management) notwendig sind, um IT-Services fortlaufend und
qualitativ hochwertig zu erbringen. Erst Service-Operation setzt die strategischen Ziele um und
liefert aus Kundensicht den tatsächlichen Mehrwert. Das Managen des täglichen Betriebs ist somit
besonders wichtig für einen Service-Provider. Dennoch sollte er die vorangegangen Phasen nicht
vernachlässigen. Der IT-Betrieb gelingt nur, wenn er auch Strategieentwicklung, Design und
Transition gewissenhaft ausgeführt hat, wie im ganzheitlichen Service-Lifecycle-Ansatz von ITILv3
beschrieben.
Service-Operation umfasst fünf Prozesse: Event-Management, Incident-Management, Request
Fulfilment, Problem-Management und Access-Management. Hinzu kommen die Funktionen Service-Desk,
Technical-Management, IT-Operations-Management und Application-Management.
Ein Event ist laut ITIL ein nachweisbares Ereignis, das für das Management der IT-Infrastruktur
oder die Erbringung von IT-Services bedeutend ist. Das Event-Management stellt sicher, dass die
IT-Abteilung Events entdeckt, versteht und angemessen behandelt. Es ist ein Ausgangspunkt für viele
Prozesse und Aktivitäten und automatisiert Routinetätigkeiten. Auch bei der Früherkennung von
Incidents (Vorfällen, Störungen) spielt das Event-Management eine Schlüsselrolle. Das
Event-Management beantwortet folgende Fragen: Wie werden relevante Meldungen generiert? Wie kann
man Incidents proaktiv entdecken? Wie können Events die Betriebsabläufe automatisieren?
Das Incident-Management bearbeitet alle Incidents; ein Incident ist dabei definiert als eine
ungeplante Unterbrechung oder eine Minderung der Qualität eines IT-Services. Anwender melden
Incidents über den Service-Desk an den Service-Provider. Zudem zeichnet dessen technisches Personal
Incidents selbstständig auf oder stellt sie im Rahmen des Monitorings fest. Dieser Prozess zielt
darauf ab, den Betrieb gemäß den vereinbarten Service-Level-Zielen so schnell wie möglich
wiederherzustellen und negative Auswirkungen zu minimieren. Das Ergebnis des
Incident-Managementprozesses ist für den Anwender gut sichtbar und beeinflusst maßgeblich, wie
zufrieden Kunden und Anwender mit der Servicequalität sind. Das Incident-Management thematisiert,
wie Incidents zu klassifizieren, zu priorisieren und entsprechend zu eskalieren sind, außerdem wie
man Incidents untersucht und IT-Services schnellstmöglich wiederherstellt.
Service-Requests sind Anfragen der Anwender an den Service-Provider. Typische Service-Requests
entstehen, wenn ein Passwort zurückzusetzen oder Software zu installieren ist oder ein
IT-Arbeitsplatz umzieht. Service-Requests sind Standard-Changes mit geringem Risiko, die dieser
Prozess effektiv und effizient bearbeitet. Request Fulfilment beantwortet die Frage, wie Anwender
einfach, unbürokratisch und kostengünstig auf Standardleistungen zugreifen können. Dieser in ITILv3
eigenständige Prozess entlastet vor allem das Incident- und Change-Management.
ITIL definiert ein "Problem" als Ursache eines oder mehrerer Incidents. Das Problem-Management
bearbeitet diese Probleme. Es verhindert proaktiv deren Auftreten, identifiziert und beseitigt
Probleme als Ursache für wiederkehrende Incidents und minimiert die Auswirkungen unvermeidbarer
Incidents. Insofern besteht eine enge Beziehung zwischen Incident- und Problem-Management. Beide
Prozesse nutzen üblicherweise dieselben Tools und auch ähnliche Klassifizierungen und
Priorisierungen. Umgehungslösungen (Workarounds) werden in Known Error Records und diese wiederum
in einer Known Error Database (KEDB) gespeichert, die Teil des CMS ist. Im Vergleich zu v2
verzichtet ITILv3 im Prozessablauf auf die explizite Trennung in Problembehandlung (Problem
Control) und Fehlerbehandlung (Error Control). Das Problem-Management beantwortet folgende Fragen:
Wie kann man Fehler proaktiv vermeiden? Wie lässt sich die Ursache wiederkehrender Incidents
endgültig beheben?
Das Access-Management schützt die Vertraulichkeit, Integrität und Verfügbarkeit von Daten und
steht daher in enger Verbindung mit dem Information-Security- and Availability-Management. Es
stellt sicher, dass nur autorisierte Anwender auf Service-Assets zugreifen oder diese modifizieren
können. Es vergibt Berechtigungen, einen IT-Service zu nutzen, während es nicht-autorisierten
Anwendern den Zugriff verwehrt. Nicht zuletzt erfordern auch die gestiegenen
Compliance-Anforderungen zum Beispiel aus dem Sarbanes-Oxley Act (SOX) die Einführung eines
Access-Managements. Technisch wird das Access-Management unter anderem mithilfe von Directory
Services realisiert. Es thematisiert insbesondere, wie man Berechtigungskonzepte entsprechend der
Sicherheitsvorgaben erstellt und implementiert, außerdem wie man sichergestellt, dass nicht mehr
benötigte Zugriffsberechtigungen auch tatsächlich gelöscht werden.
Service-Operation thematisiert als einzige der fünf Kernpublikationen zusätzlich zu den
Prozessen auch Funktionen. Funktionen sind auf bestimmte Arbeitsbereiche spezialisierte
Organisationseinheiten, die Prozesse und Aktivitäten ausführen. So ist der Service-Desk eine weit
verbreitete Funktion, die schon aus ITILv2 bekannt ist. Die drei neuen Funktionen in ITILv3 lauten
Technical-, IT-Operations- sowie Application-Management.
Der Service-Desk fungiert als zentrale Anlaufstelle (Single Point of Contact, SPOC). Anwender
wenden sich an den SPOC und melden Störungen und Service-Requests. Insofern nimmt der Service-Desk
eine Schlüsselposition in Bezug auf die Kundenzufriedenheit ein. Die Funktion Service-Desk führt
insbesondere wesentliche Teile des Incident-Managements und des Request-Fulfilment-Prozesses
aus.
Das Technical-Management spielt eine zentrale Rolle beim Entwurf, dem Testen, der Freigabe und
der Verbesserung von IT-Services, was wiederum der Inhalt der Lifecycle-Phasen Service-Design,
Service-Transition, Continual Service-Improvement und der darin beschriebenen Prozesse ist. Das
Technical-Management stellt zudem detaillierte, technische Fachkenntnisse und Ressourcen bereit,
die den Betrieb der IT-Infrastruktur im Rahmen der Phase Service-Operation unterstützen.
Das IT-Operations-Management verantwortet den täglichen Betrieb der IT-Infrastruktur und
orientiert sich dabei an den im Service-Design definierten Leistungsstandards. Es besteht aus den
in der Regel organisatorisch getrennten Bereichen IT Operations Control und Facilities-Management.
IT Operations Control arbeitet zumeist im Schichtdienst und erledigt Routineaufgaben. Es überwacht
und kontrolliert die IT-Services und die IT-Infrastruktur. Facilities-Management verwaltet die
physische IT-Umgebung wie Rechenzentren und Computerräume.
Das Application-Management verwaltet den kompletten Lebenszyklus aller Anwendungen. Die
Unterstützung des laufenden Betriebs von Applikationen gehört genauso zu den Aufgaben wie der
Entwurf, das Testen und die Verbesserung von Applikationen, was wiederum der Inhalt der
Lifecycle-Phasen Service-Design, Service-Transition und Continual Service-Improvement ist.
Buch 5: Continual Service-Improvement
Continual Service-Improvement (CSI) verantwortet das Management von Verbesserungen der
IT-Services, der Prozesse, der IT-Infrastruktur und des gesamten Service-Lifecycles. CSI passt
IT-Services und Prozesse kontinuierlich an geänderte Geschäftsanforderungen an und treibt
Verbesserungen am Design, der Einführung und dem Betrieb von IT-Services voran. Eine
kontinuierliche Verbesserung durchzuführen setzt voraus, dass man Leistungen im laufenden Betrieb
regelmäßig misst. Nur so lässt sich der Ist-Zustand als Ausgangspunkt einer Verbesserungsmaßnahme
erfassen und das erreichte Ziel beurteilen. CSI hinterfragt, wie sich die Servicequalität
kontinuierlich verbessern lässt, wie sich Prozesseffektivität und -effizienz optimieren lassen und
wie der Mehrwert, den IT-Services generieren, erhöht wird.
CSI basiert auf dem so genannten Seven-Step Improvement Process (Verbesserungsprozess in sieben
Schritten), der im Wesentlichen von zwei weiteren CSI-Prozessen unterstützt wird, dem
Service-Measurement und dem Service-Reporting. Er gibt der kontinuierlichen Verbesserung, die auch
in ISO 20000 verankert ist, die notwendige Struktur.
Schritt eins dieses Verbesserungsprozesses definiert, was zu messen ist. Dies erfordert
Gespräche mit Kunden und dem IT-Management. Vision, Mission, der Servicekatalog,
Service-Level-Anforderungen und -Ziele werden ausgewertet. Schritt zwei definiert, was messbar ist.
Jedes Unternehmen stößt hinsichtlich der messbaren Größen an seine Grenzen. Die vorhandenen Reports
und Tools, die ein Unternehmen nutzt, sind hier der Ausgangspunkt. Auf dieser Basis lässt sich
identifizieren, was bereits jetzt oder mit vertretbarem Aufwand gemessen werden kann, zum Beispiel
durch (Re-)Konfiguration der Tools. Schritt drei sammelt die Daten. Dies setzt ein Monitoring
voraus. Es sollten sowohl technische Messwerte als auch Messwerte für Prozesse und IT-Services
erfasst werden. Hier ist zu klären, wer die Datensammlung verantwortet und in welchen Abständen
diese stattfindet.
Schritt vier bereitet die Daten aus vielen unterschiedlichen Quellen auf und überführt sie in
ein verwertbares Format. Daten werden aggregiert und ihre Genauigkeit wird beurteilt, um sie
anschließend zu analysieren. Die Datenaufbereitung wandelt die Daten in Informationen um. Schritt
fünf ist die Datenanalyse und Auswertung und wandelt die aus Daten gewonnenen Informationen in
Wissen um. Hier identifiziert man Schwachstellen der IT-Services und Prozesse, Trends, Auswirkungen
auf das Geschäft und Korrekturmaßnahmen. Schlussfolgerungen für die weitere Vorgehensweise sind das
Ergebnis dieses fünften Schrittes.
Im sechsten Schritt werden die Erkenntnisse und Verbesserungsmaßnahmen präsentiert. Schritt
sieben implementiert schließlich die beschlossenen Korrekturmaßnahmen. Wichtig bei der
Implementierung ist es, die Maßnahmen innerhalb der Organisation zu kommunizieren und zu erläutern.
Dieser Schritt gilt als erfolgskritisch für den gesamten Seven-Step Improvement Process.
Lesen Sie mehr zum Thema
