

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.
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.
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.

Kommentare 25
Eine Frage zur Umsetzung: wie sich die Wirkung im laufenden Betrieb zuverlässig erkennen lässt. Welche Beobachtung wäre wichtiger als eine reine Vollständigkeitsquote?
Aus meiner Sicht sollte man mit einem kritischen, aber überschaubaren Fall beginnen. Daran werden fehlende Zuständigkeiten meist schneller sichtbar als in einer allgemeinen Bewertung.
Ich würde außerdem festhalten, welche Annahmen hinter der Bewertung stehen. Ändern sie sich, sollte nicht einfach derselbe Status fortgeschrieben werden.
Genau diese Verbindung ist entscheidend: klein beginnen, aber Wirkung und Entscheidungsfolge vorher festlegen. So bleibt der Aufwand vertretbar und das Ergebnis trotzdem belastbar.
Damit wird es für mich deutlich greifbarer. Vor allem die vorher festgelegte Entscheidungsfolge verhindert, dass der Pilot nur als zusätzlicher Bericht endet.
Eine Frage zur Umsetzung: Welche Abläufe eignen sich aus deiner Sicht am besten für einen ersten Verbesserungsversuch?
Ein häufiger und klar abgrenzbarer Vorgang wäre sinnvoll. Dort kann man Übergaben, Rückfragen und Ergebnisse gut beobachten.
Woran würde man im Servicebetrieb nach einigen Wochen erkennen, dass die Regelung im Alltag trägt? Das wäre ein sinnvoller Prüfpunkt vor einer breiteren Einführung. Ein kurzer Vermerk im bestehenden Ablauf dürfte dafür ausreichen.
Welche kleine Stichprobe würde bei Rückkopplung aus Störungen und Änderungen zuerst zeigen, ob die Umsetzung im Alltag funktioniert?
Eine kleine, begründete Auswahl konkreter Fälle wäre für mich ein guter Einstieg. Neben einem normalen Ablauf würde ich einen schwierigen Fall prüfen und die Abweichungen kurz dokumentieren. Für Rückkopplung aus Störungen und Änderungen würde ich den ersten Prüfschritt bewusst klein halten.
Wie viel Prozess braucht ein kleiner Betrieb, bevor die Umsetzung selbst zum Problem wird?
Ich würde es so einordnen: Ich würde den Umfang von den tatsächlichen Services und Problemen abhängig machen. Klare Verantwortlichkeiten können am Anfang wertvoller sein als ein großer Dokumentensatz.
Was wäre ein guter Einstieg, wenn noch keine gemeinsamen Begriffe und Abläufe existieren?
Daran würde ich anknüpfen. Ich würde einen regelmäßig auftretenden Ablauf auswählen, Zuständigkeiten klären und die Verbesserung daran überprüfen. Danach ließe sich gezielter erweitern.
Ich lese das etwas anders. Für mich steht zuerst die Frage im Raum, ob der zugrunde liegende Bedarf überhaupt ausreichend geklärt ist. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Bei fehlenden Informationen würde ich die Unsicherheit sichtbar machen und eine vorläufige Entscheidung mit klarer Wiedervorlage treffen. Einfach so zu tun, als wäre alles bekannt, wäre die schlechtere Grundlage. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Wo endet hilfreiche Standardisierung und wo beginnt unnötige Bürokratie?
Wie würdet ihr Rückkopplung aus Störungen und Änderungen konkret prüfen, wenn die Maßnahme bereits auf dem Papier abgeschlossen ist?
Für diesen Fall wäre mein Ansatz: die Umsetzung an einem konkreten Fall nachvollziehen und dabei das tatsächliche Ergebnis prüfen. Damit bleibt sichtbar, was entschieden wurde und was noch offen ist. Bei Rückkopplung aus Störungen und Änderungen sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Dazu eine Rückfrage: Wie vermeidet man, dass Servicequalität ausschließlich aus Sicht der IT bewertet wird?
Mein Vorschlag wäre: Die Erwartungen der Nutzenden müssten mit hinein. Eine intern erfüllte Kennzahl kann trotzdem einen unbrauchbaren Service beschreiben.
Beim Prinzip bin ich dabei. Bei der Umsetzung könnte aber gerade die Übergabe zwischen zwei Zuständigen schwierig werden.
Ich würde das Ergebnis vorher festlegen: Was soll danach klarer, schneller oder belastbarer sein? Ohne diesen Bezug ist der Erfolg einer Änderung schwer zu beurteilen. Auf die Ausgangsfrage bezogen: Die Erwartungen der Nutzenden müssten mit hinein. Eine intern erfüllte Kennzahl kann trotzdem einen unbrauchbaren Service beschreiben.
Ich bleibe beim Aufwand etwas skeptisch. Eine kleine, überprüfbare Lösung könnte hier zunächst mehr bringen als ein umfassendes Konzept. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Für mich fehlt dabei noch der Umgang mit Ausnahmen. Wer darf abweichen und wie wird diese Entscheidung später nachvollzogen? Das bezieht sich für mich auf den hier beschriebenen Ansatz.