Was ist ITIL? Grundlagen, Nutzen und Einstieg für IT-Entscheider

Rund 80 Prozent des IT-Budgets fliessen in den reinen Betrieb bestehender Systeme. Was für Verbesserungen übrig bleibt, hängt weniger von besserer Hardware ab als von besseren Prozessen. Genau hier kommt das Framework ins Spiel.

ITIL (Information Technology Infrastructure Library) ist ein Best-Practice-Framework für IT-Service-Management, das beschreibt, wie IT-Services aus Kundenperspektive strukturiert, betrieben und kontinuierlich verbessert werden. Die aktuelle Version ITIL 4 fasst dieses Wissen in 34 flexiblen Practices innerhalb eines Service Value Systems zusammen und ist explizit kompatibel mit agilen Methoden und DevOps.

Drei Missverständnisse tauchen in der Praxis immer wieder auf: ITIL ist kein Softwareprodukt, das man kauft und installiert. Es gibt keine Zertifizierungspflicht für Unternehmen. Und ITIL ist kein starres Regelwerk, das vollständig umgesetzt werden muss. Organisationen wählen daraus, was zu ihrer Situation passt.

Der Unterschied zwischen ITIL v3 und ITIL 4 liegt weniger in der Substanz als in der Struktur. ITIL v3 arbeitete mit 26 Prozessen, aufgeteilt in fünf Lebenszyklusphasen. ITIL 4 ersetzt diese durch 34 Practices und bettet sie in ein übergeordnetes Service Value System ein. Das macht ITIL 4 anschlussfähiger für IT-Organisationen, die gleichzeitig mit agilen Teams, DevOps-Pipelines und Cloud-Providern arbeiten.

Was das konkret für Budget und Betrieb bedeutet, zeigt das nächste Kapitel.

Rund 80 Prozent des IT-Budgets fliessen in den reinen Betrieb bestehender Systeme. Was übrig bleibt, reicht kaum für strategische Initiativen. Das ist kein Budget-Problem, es ist ein Prozess-Problem.

Der grösste Kostentreiber im Betrieb ist ungeplante Arbeit: Incidents, die eskalieren, weil niemand einen Standardprozess befolgt. Changes, die Ausfälle verursachen, weil Abhängigkeiten nicht dokumentiert sind. Jeder ungeplante Eingriff kostet mehr als ein geplanter, und er verdrängt planbare Arbeit. In der Praxis zeigt sich, dass ein Grossteil der reaktiven Aufwände im Service Desk auf fehlende Prozessklarheit zurückgeht, nicht auf technisches Versagen.

ITIL setzt genau hier an. Standardisierte Incident- und Change-Management-Prozesse reduzieren Wiederholungsfehler und schaffen Transparenz über Ursachen. Organisationen, die das Framework konsequent einführen, senken ihren laufenden operativen IT-Aufwand um 20–40 Prozent. Das sind keine Effizienzgewinne auf dem Papier. Das ist Budget, das für Verbesserungen zur Verfügung steht statt für Schadensbegrenzung.

Für jeden Entscheider mit Budgetverantwortung stellt sich damit die logische Folgefrage: Was bringt ITIL messbar, und wie lässt sich der Nutzen konkret belegen?

Eine IDC-Studie, zitiert im Beitrag der British Computer Society, belegt einen ROI von 422 Prozent über drei Jahre bei einer Amortisationszeit von 11,8 Monaten: Investitionskosten von rund 1,1 Mio. GBP stehen jährlichen Einsparungen von 7,7 Mio. GBP gegenüber. Das sind Zahlen, die in jede Vorstandspräsentation passen.

Die Herkunft dieser Einsparungen ist nachvollziehbar aufgeschlüsselt. Laut IDC-Forschung erzielen Organisationen im Incident Management und Service Desk einen Effizienzgewinn von 40,5 Prozent, im Server Management 30,9 Prozent, im Change Management 28,4 Prozent. Der Gesamtdurchschnitt über alle Bereiche liegt bei 30 Prozent. Jede dieser Kategorien lässt sich direkt auf eine Kostenposition in Ihrer IT abbilden.

Fallbeispiele belegen den Effekt konkret: Capital One reduzierte geschäftskritische Vorfälle nach einer ITIL-Einführung um 92 Prozent. Hershey Foods erreichte eine Erfolgsquote von 97 Prozent bei Changes. Beide Werte entstanden nicht durch neue Hardware, sondern durch bessere Prozesse.

Neben den harten Zahlen liefert ITIL drei Argumente, die im Vorstandsgespräch oft unterschätzt werden: belastbare Budgetplanung durch standardisierte Prozesskosten, lückenlose Audit-Trails für Compliance-Nachweise und eine messbar höhere Servicequalität, die die Wahrnehmung der internen IT verändert. Doch Schweizer Entscheider haben über den Business Case hinaus einen weiteren Grund, ITIL ernst zu nehmen.

Das FINMA-Rundschreiben 2023/1 erwartet von beaufsichtigten Instituten explizit die Berücksichtigung international anerkannter Standards im IKT-Risikomanagement. ITIL-Practices sind genau das: ein etablierter, international anerkannter Standard für IT-Service-Management. ITIL ist damit kein Pflichtrahmen, aber ein direkt kompatibler Compliance-Enabler für regulierte Unternehmen in der Schweiz.

Die Verbindung ist konkret. Das ITIL Change Management liefert die Nachvollziehbarkeit und Dokumentation, die das FINMA-Rundschreiben für IKT-Änderungen verlangt. Incident Management stellt sicher, dass Störungen klassifiziert, priorisiert und nachvollziehbar bearbeitet werden, was Meldepflichten gegenüber dem BACS und der FINMA strukturell unterstützt. Supplier Management schafft die Transparenz über externe Provider, die der Regulierer im Bereich Outsourcing erwartet.

Das revidierte Datenschutzgesetz (revDSG) stellt eigene Anforderungen: klare Rollendefinitionen, dokumentierte Prozesse für die Bearbeitung von Personendaten und nachweisbare Verantwortlichkeiten. ITIL-Practices erfüllen diese Anforderungen strukturell, weil Rollen und Zuständigkeiten in jedem Prozess explizit definiert sind. Der EDÖB prüft genau das, wofür ITIL den organisatorischen Rahmen liefert.

Für Entscheider in regulierten Branchen verschiebt sich die Frage dadurch von «Wollen wir ITIL?» zu «Wie führen wir ITIL so ein, dass der Aufwand zum Nutzen passt?»

Den grössten ITIL-ROI erzielen grosse Unternehmen, die mit Incident Management und Service Desk beginnen. Hier sind Quick Wins in Wochen messbar: kürzere Incident-Lösungszeiten, höhere Serviceverfügbarkeit, klarere Eskalationspfade. Alle anderen Practices lassen sich später aufbauen.

Der entscheidende Risikofaktor ist nicht die Technologie. 81 Prozent der Organisationen nennen internen Widerstand als grössten Scheiternsfaktor bei der ITIL-Implementierung. Wer das unterschätzt, verliert die Einführung nicht im Projektzimmer, sondern im Tagesgeschäft der Fachabteilungen.

Der pragmatische Einstieg folgt drei Schritten:

1. IST-Analyse: Bestehende Incident-Prozesse, Rollen und KPIs dokumentieren, Lücken benennen.
2. Pilotprojekt: Einen klar abgegrenzten Service-Bereich auswählen, Rollen verbindlich definieren, zwei bis drei messbare KPIs festlegen (z. B. Mean Time to Restore, First-Contact-Resolution-Rate).
3. Schrittweiser Ausbau: Erst wenn der Pilot stabil läuft, weitere Practices wie Change Management oder Problem Management integrieren.

Der häufigste Fehler in der Praxis: Unternehmen starten mit zu vielen Processes gleichzeitig und verlieren den Überblick über Verantwortlichkeiten. Weniger Scope zu Beginn ist kein Zeichen von Schwäche, es ist Risikominimierung. Wer mit einem sauber definierten Incident-Prozess startet, schafft die organisatorische Basis, auf der jede weitere ITSM-Transformation sicher aufbaut.