ITIL5 – Alles was man wissen muss
Eine vertiefte Betrachtung von ITIL 5 als Orientierungsrahmen für Service Management und Wertschöpfung.
Von Dr. Markus Groß
GEDANKEN & FACHLICHE EINORDNUNG
Blog
Impulse zu Governance, Informationssicherheit und KI.
7 Minuten Lesezeit
(1431 Worte)
FACHARTIKEL / IT
Die Entstehung der ITIL Bibliothek
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.
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.
| 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. |
PERSPEKTIVE & DIALOG
Beitrag bewerten
Deine Bewertung hilft bei der Einordnung der Inhalte.
Wissen weitergeben
Interessant für dein Netzwerk? Teile den Beitrag direkt.
Blog-Beitrag abonnieren
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.
Über den Autor
FACHMAGAZIN
Perspektiven. Governance. Einordnung.
Kommentare 28
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.
Spannend ist für mich, wie verlässliche Services und lernende Abläufe in bestehende Abläufe passt. Eine zusätzliche Parallelstruktur wäre schwer dauerhaft zu betreiben.
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.
Spannend ist für mich, wie verlässliche Services und lernende Abläufe in bestehende Abläufe passt. Eine zusätzliche Parallelstruktur wäre schwer dauerhaft zu betreiben.
Mich überzeugt besonders der Bezug zu verlässliche Services und lernende Abläufe. Ein konkreter Anwendungsfall könnte zeigen, wo der Ansatz noch zu abstrakt ist.