ITIL ist die Abkürzung für "Information Technology Infrastructure Library" und stellt eine Bibliothek mit einer Sammlung von Best-Practices zum Servicemanagement in der IT dar. Die erste Ausgabe der ITIL Bibliothek stammt aus dem Jahre 1989. Nach unterschiedlichen, jedoch nicht offiziell bestätigten Quellen, wird die Entwicklung dieser Bibliothek der britischen Premierministerin Margaret Thatcher zugeordnet. Sie soll, ausgelöst durch den Falklandkrieg, im britischen Unterhaus die Effizienz und die Effektivität der gelieferten IT-Leistungen in englischen Behörden angezweifelt haben. Als Ergebnis dieser Anfrage wurde von der Central Computer and Telecommunications Agency (CCTA) die erste Version des Leitfadens entwickelt.
Bis Mitte der 90er Jahre hat sich ITIL zu einem de facto Standard für IT-Service Management in England entwickelt. Da er in der ersten Fassung aus über 34 Dokumenten mit jeweils 26 separaten Modulen bestand, war das als ITIL (v1) benannte Rahmenwerk außerhalb von England kaum bekannt. Zwischen den Jahren 1999 und 2004 wurde diese umfangreiche Sammlung überarbeitet und in elf Büchern zusammengefasst als ITIL Version 2 veröffentlicht. Kern dieses Best-Practice Rahmens waren die Prozesse Service-Support und Service-Delivery, also die Einteilung in geschäftsnahe und techniknahe/IT-betriebsnahe Prozesse.
Die elementaren Prozesse von ITIL v2 sind in sieben Kernbüchern beschrieben. Das erste Buch "Business Perspective" beschreibt die Umsetzung der strategischen Prozesse des IT-Service Management. Der zweite Band "Service Delivery" befasst sich mit der grundlegenden Planung, Kontrolle und Steuerung von IT-Leistungen. Im Dritten Buch "Service Support" wird die Umsetzung der Service Prozesse und die Sicherstellung der Leistungslieferung im Rahmen des Nutzer-Supports beschrieben. In den weiteren Büchern werden die Aspekte Applikationsbetrieb, Systemkonfiguration und IT Sicherheit beschrieben.
Mitte 2007 wurde vom Office of Government Commerce (OGC), als Nachfolgeorganisation der CCTA, die dritte Fassung der ITIL Bibliothek, welche als ITIL v3 bezeichnet wird, veröffentlicht. Mit der Version 3 von ITIL ging ein Paradigmenwechsel einher. Statt eines Referenzrahmens und den beiden Disziplinen Service-Support und Service-Delivery stellt sich ITIL nun als Lebenszyklusmodell dar, das im Kern aus insgesamt fünf elementaren Büchern besteht.
Die Entwicklung von ITIL auf eine heutige Servicefrage beziehen. Fragen Sie, welcher Nutzen mit einem bestimmten Prozess erreicht werden sollte. Diese historische Perspektive hilft, heutige Praktiken bewusst auszuwählen und Begriffe nicht mit einem unveränderlichen Organisationsmodell gleichzusetzen.
{tmamazon asin="B0HKS5SZXW" layout="mini" align="right" label="ITIL5 – Alles was man wissen muss" text="Eine vertiefte Betrachtung von ITIL 5 als Orientierungsrahmen für Service Management und Wertschöpfung. Das Buch ordnet Rollen, Prozesse und Service-Leistungen in eine nachvollziehbare Managementperspektive ein." shorttext="Eine vertiefte Betrachtung von ITIL 5 als Orientierungsrahmen für Service Management und Wertschöpfung." image="images/mg-publikationen/cover/buch-itil5-alles-was-man-wissen-muss-services-prozesse-wertbeitrag.jpg" book="1" note="Von Dr. Markus Groß" price="0" rating="0" count="0" features="0" disclosure="1"}
Zum essentiellen Verständnis von ITIL sind als Grundlage die Begriffe "Service-(management)" und "Prozess" sowie die Sichtweise von "Kunde" und "Dienstleister" zu klären. Unter Servicemanagement versteht man die Generierung eines Mehrwerts für Kunden in Form von Services. Diese Services sind standardisierte Methoden und Prozesse, die kosten- und nutzeneffizient zur Verfügung stehen. "Ein Service in ITIL bedeutet, einem Kunden einen Nutzen zu liefern, indem die erwarteten Ergebnisse produziert werden, ohne dass der Kunde die spezifischen Risiken zu tragen hat." Die sachlogisch zusammenhängende Reihe von Aktivitäten zur Erreichung eines definierten Ergebnisses wird hierbei als ein Prozess verstanden. Dieser verursacht Kosten und verbraucht materielle und personelle Ressourcen. Merkmale eines Prozesses sind Ziel, Input, Aktivitäten, Output und Qualität. Aus der Perspektive von ITIL wird unter Kunde jeder interne und externe Personenkreis verstanden, der die bereitgestellten IT-Services nutzt. Unter Dienstleister werden all die internen Ressourcen verstanden, die IT-Services erbringen.
Um die Zielerreichung der Prozesse messbar zu machen werden Key Performance Indikatoren (KPI) definiert. Diese Indikatoren werden für jeden Teilschritt der Prozesse festgelegt. "... KPI ... sind Variablen, anhand derer man den Fortschritt hinsichtlich wichtiger Zielsetzungen oder kritischer Erfolgsfaktoren innerhalb einer Organisation ermitteln kann." Die Auswahl sollte die Sicherstellung der Effizienz, Effektivität und Wirtschaftlichkeit berücksichtigen.
Der Hauptunterschied zwischen den Versionen v2 und v3 besteht in der konsequenten Ausrichtung an dem Lebenszyklus der IT-Produkte und Dienstleistungen, was zu einer größeren Kundenorientierung bei der Erbringung der IT-Services führt. Auch wenn sich die Prozessabläufe der einzelnen Funktionen nicht grundlegend gegenüber der Version 2 geändert haben, wurden doch die Schnittstellen der einzelnen Prozesse untereinander so angepasst, um den Anforderungen eines Unternehmens bei der Implementierung der Services optimal Rechnung zu tragen. Die fünf-Phasen des Lifecycle-Ansatzes bilden die Gegebenheiten der meisten Organisationen nach.
Vertiefung: Die Entstehung der ITIL Bibliothek
Aus „Die Entstehung der ITIL Bibliothek“ lässt sich mehr gewinnen als eine Momentaufnahme. Die nachfolgende Vertiefung ordnet für Arbeitsergebnis ein, welche Annahmen geprüft und welche Konsequenzen organisatorisch sauber umgesetzt werden sollten.
Nachweis als Konsequenz aus „Die Entstehung der ITIL Bibliothek“
Aus dem historischen Befund entsteht für „Die Entstehung der ITIL Bibliothek“ eine praktische Steuerungsfrage: Es ist zu klären, welches Arbeitsergebnis Ausführung und Ergebnis glaubhaft belegt. Beim Schwerpunkt „Die Entstehung der ITIL Bibliothek“ geht es um ein Management- oder Governance-Framework und seine praktische Nutzung sowie um den Bezug zu „Prozessnutzen“; zu entscheiden ist, welcher Baustein ein konkretes Organisationsproblem löst (hier bezogen auf „Anpassungstiefe“), ohne das Framework zum Selbstzweck zu machen. Dabei bleibt folgende Grenze maßgeblich: Ein Framework liefert Orientierung (hier bezogen auf „Managementbedarf“); Verantwortung für Auswahl, Anpassung und Wirkung bleibt bei der Organisation. Der nächste Arbeitsschritt lautet: Nachweise möglichst im normalen Prozess entstehen lassen; für den Aspekt „Arbeitsergebnis“ wird daraus ein eigener Prüfschritt. Überprüfbar wird der Schritt durch folgendes Ergebnis: eine datierte Spur aus Soll, Ausführung, Ergebnis und Abweichung; für „Anpassungstiefe“ ist das Ergebnis gesondert festzuhalten. Relevant bleibt dabei: Entscheidungsdauer, Ergebnisqualität, Nacharbeit, Rollenklarheit und nachweisbare Verbesserung. Der Diskussionsaspekt „klare Zuständigkeiten und Entscheidungsrechte“ ergänzt die Betrachtung sinnvoll, weil er „Prozessnutzen“ mit der tatsächlichen Anwendung verknüpft.
Was „Prozessnutzen“ für Messgröße bedeutet
Der Beitrag gewinnt beim Aspekt „Prozessnutzen“ an Aktualität, sobald sein Kerngedanke in eine heutige Entscheidung übersetzt wird: Es ist zu klären, welcher Wert eine konkrete Reaktion auslösen kann. Beteiligt sind hier vor allem Management, Prozess- und Serviceverantwortliche, Projektteams, Governance-Funktionen und Revision; ihre Perspektiven treffen beim Aspekt „Arbeitsergebnis“ unmittelbar aufeinander. Die gewählte Lösung muss auch dann tragen, wenn Terminologie und Prozessbilder wachsen (hier bezogen auf „Reifeentwicklung“), während Entscheidungen, Leistungen oder Kontrollen unverändert schwach bleiben. Im Regelbetrieb wird folgender Punkt verankert: Definition, Quelle, Schwelle, Eigentümer und Konsequenz gemeinsam festlegen; „Methodenumfang“ liefert dafür den praktischen Anwendungsfall. Überprüfbar wird der Schritt durch folgendes Ergebnis: eine Kennzahl mit erklärbarer Datenherkunft und Entscheidung; der Prüfkontext ist hier „Reifeentwicklung“. Relevant bleibt dabei: der Zusammenhang zwischen „Prozessnutzen“ und „Arbeitsergebnis“. Eine brauchbare Gegenprobe ist die Frage, ob dieselbe Entscheidung bei einer Störung rund um „Prozessnutzen“ noch nachvollziehbar wäre.
Integration – Reifegrad praktisch fassen
Die fachliche Vertiefung von „Integration“ beginnt nicht mit einer weiteren Methode, sondern mit einer Grenze: Es ist zu klären, welche nächste Fähigkeit wichtiger ist als eine möglichst hohe Stufe. Als belastbare Grundlage dienen Zielproblem, ausgewählte Praktiken, Rollenentscheidung, Arbeitsergebnisse, Abweichungen und Verbesserungsnachweise; für den Aspekt „Integration“ muss ihre Herkunft nachvollziehbar bleiben. Die Entscheidung über „Methodenumfang“ sollte deshalb ausdrücklich festhalten, welcher Baustein ein konkretes Organisationsproblem löst (hier bezogen auf „Methodenumfang“), ohne das Framework zum Selbstzweck zu machen. Statt einer neuen Parallelstruktur genügt zunächst: Reife an beobachtbarer Praxis statt an Selbsteinschätzung festmachen. Die Dokumentation hält zwei Dinge fest – ein priorisierter Entwicklungsschritt mit messbarem Abschluss; zusätzlich sichtbar wird: die beobachtbare Veränderung beim Aspekt „Messbarkeit und nachgewiesene Wirkung“. Für den Dialog unter dem Beitrag ist „Messbarkeit und nachgewiesene Wirkung“ der passende Belastungstest: Gerade beim Aspekt „Methodenumfang“ muss die Regel im Alltag tragen.
Prüfbarkeit: Verbesserungsschritt
Eine nüchterne Fortführung trennt bei „Verbesserungsschritt“ den damaligen Anlass von der bleibenden Organisationsfrage: Es ist zu klären, ob eine dritte Person Entscheidung und Durchführung ohne mündliche Rekonstruktion versteht. Die alltagstaugliche Übersetzung für „Verbesserungsschritt“ lautet: Nur die für das Ziel erforderlichen Elemente werden übernommen und anhand beobachtbarer Ergebnisse weiterentwickelt – betrachtet im Kontext „Die Entstehung der ITIL Bibliothek“. Damit wird zugleich die Grenze beim Aspekt „Auswahl der Praktiken“ sichtbar: Ein Framework liefert Orientierung (hier bezogen auf „Entscheidungsweg“); Verantwortung für Auswahl, Anpassung und Wirkung bleibt bei der Organisation. Der nächste Arbeitsschritt lautet: Begründung, Zeitpunkt, Verantwortliche, Eingangsdaten und Ergebnis zusammenhalten; der Belastungstest erfolgt mit Blick auf „Die Entstehung der ITIL Bibliothek“. Die Dokumentation hält zwei Dinge fest – einen reproduzierbaren Prüfpfad bis zur Quelle; zusätzlich sichtbar wird: Entscheidungsdauer, Ergebnisqualität, Nacharbeit, Rollenklarheit und nachweisbare Verbesserung. Eine brauchbare Gegenprobe ist die Frage, ob dieselbe Entscheidung bei einer Störung rund um „Verbesserungsschritt“ noch nachvollziehbar wäre.
Entscheidungsoptionen ohne blinden Fleck bei „Die Entstehung der ITIL Bibliothek“
Für die heutige Einordnung von „Arbeitsergebnis“ ist zunächst eine Unterscheidung entscheidend: Es ist zu klären, welche Alternativen zwischen vollständigem Verbot und uneingeschränkter Freigabe liegen. Ein realistischer Belastungstest betrachtet den Fall, dass Terminologie und Prozessbilder wachsen (hier bezogen auf „Rollenklarheit“), während Entscheidungen, Leistungen oder Kontrollen unverändert schwach bleiben. Für die beteiligten Rollen – Management, Prozess- und Serviceverantwortliche, Projektteams, Governance-Funktionen und Revision – braucht der Aspekt „Arbeitsergebnis“ daher einen vorab geklärten Entscheidungsweg. Statt einer neuen Parallelstruktur genügt zunächst: Optionen nach Nutzen, Risiko, Aufwand und Rückbaubarkeit vergleichen; im Fokus steht dabei „Verbesserungsschritt“. Überprüfbar wird der Schritt durch folgendes Ergebnis: eine dokumentierte Optionsentscheidung mit verworfenen Alternativen; für „Arbeitsergebnis“ ist das Ergebnis gesondert festzuhalten. Relevant bleibt dabei: der Zusammenhang zwischen „Arbeitsergebnis“ und „Die Entstehung der ITIL Bibliothek“. Für den Dialog unter dem Beitrag ist „Mindestanforderungen und befristete Ausnahmen“ der passende Belastungstest: Gerade beim Aspekt „Die Entstehung der ITIL Bibliothek“ muss die Regel im Alltag tragen.
Der Praxistest für Integration bleibt bewusst einfach: Die Regel zu Verbesserungsschritt muss im Normalbetrieb verständlich, beim Aspekt Arbeitsergebnis im Ausnahmefall entscheidbar und nach einer Änderung erneut prüfbar sein. Fehlt eine dieser Eigenschaften, besteht bei Anpassungstiefe weiterer Handlungsbedarf.