Wer IT-Betrieb einkauft oder auslagert, landet schnell bei einem Vokabular, das selten jemand erklärt: Service Desk, Incident, Change, Service Level. Die Begriffe stammen aus ITIL und haben sich so weit durchgesetzt, dass sie in fast jeder Ausschreibung und jedem Betriebsvertrag stehen. Das macht sie tückisch. Ein Kunde meldet ein „Problem“ und meint eine Störung, der Dienstleister hört einen Auftrag zur Ursachenanalyse. Ein „Change“ klingt nach einer Kleinigkeit und ist im Vertrag eine eigene, oft kostenpflichtige Leistung.

Solche Verwechslungen erleben wir seit 2003 im Betrieb für unsere Kunden. Unsere Betriebsprozesse folgen ITIL und sind Teil eines internen Kontrollsystems, das jedes Jahr geprüft wird. Für uns ist ITIL deshalb vor allem eine gemeinsame Sprache mit Kunden, Prüfern und Partnern. Um sie zu sprechen, muss man das Rahmenwerk nicht auswendig kennen. Es reicht, eine Handvoll Begriffe genau zu verstehen.

Was ist ITIL?

ITIL ist die Abkürzung für Information Technology Infrastructure Library, eine Sammlung bewährter Vorgehensweisen für das IT-Servicemanagement. Sie beschreibt, wie eine Organisation IT-Services plant, aufbaut, betreibt und verbessert. Dafür gibt sie feste Begriffe für Prozesse, Rollen und Ergebnisse vor. Entstanden ist ITIL Ende der 1980er-Jahre im Auftrag der britischen Regierung, die einheitliche Regeln für den Betrieb ihrer Rechenzentren suchte. Heute gehört das Rahmenwerk dem Zertifizierungsanbieter PeopleCert.

Einfach erklärt: ITIL ist keine Norm und kein Gesetz, sondern ein Baukasten. Niemand muss alle Teile einsetzen. Ein Unternehmen kann sich auch nicht „nach ITIL“ zertifizieren lassen. Zertifiziert werden Personen, etwa mit der Prüfung ITIL Foundation. Der Nutzen entsteht dort, wo Kunde und Dienstleister, Einkauf und Technik dieselben Wörter für dieselben Dinge verwenden.

Was ist der Unterschied zwischen ITIL und ITSM?

IT-Servicemanagement, kurz ITSM, ist die Aufgabe, ITIL ist eine Anleitung dafür. ITSM umfasst alles, was nötig ist, damit IT als verlässlicher Service bei den Anwendern ankommt: Anfragen annehmen, Störungen beheben, Änderungen steuern, Leistung messen. Wie ein Unternehmen das organisiert, entscheidet es selbst. ITIL ist das verbreitetste Rahmenwerk dafür. Daneben steht COBIT, das die Steuerung und Kontrolle der IT beschreibt. Nach der Norm ISO/IEC 20000 lässt sich ein Servicemanagement als Organisation zertifizieren.

Die Ansätze schließen sich nicht aus. Viele Organisationen kombinieren sie: ITIL für den Betrieb, COBIT für die Steuerung, eine Norm für den Nachweis nach außen.

Welche ITIL-Version gilt heute?

Aktuell ist ITIL (Version 5), die PeopleCert Anfang 2026 veröffentlicht hat. Sie baut auf ITIL 4 von 2019 auf und ergänzt vor allem praktische Anleitungen für den Lebenszyklus digitaler Produkte und Services sowie für den Umgang mit KI. PeopleCert selbst beschreibt die neue Fassung als Weiterentwicklung von ITIL 4 für KI und Cloud, nicht als Bruch. Zertifikate nach ITIL 4 bleiben gültig.

Viele Begriffe aus dem Alltag stammen noch aus ITIL v3 von 2007. Dessen Service-Lebenszyklus mit den fünf Phasen Service Strategy, Service Design, Service Transition, Service Operation und Continual Service Improvement prägt bis heute viele Organisationen, auch unsere. ITIL 4 hat ihn durch eine Wertschöpfungskette und 34 sogenannte Practices ersetzt, die Bausteine wie Incident Management oder Change Enablement beschreiben. Wer heute von ITIL-Prozessen spricht, meint meist diese Bausteine.

Welche ITIL-Prozesse sollte man kennen?

Für die Zusammenarbeit mit einem Dienstleister genügen eine Handvoll Begriffe. Sie stehen in Verträgen, Service-Level-Vereinbarungen und Betriebsberichten. An ihnen entstehen die meisten Missverständnisse.

Begriff Was er bedeutet
Service Desk Der Service Desk ist die zentrale Anlaufstelle für alle Meldungen und Anfragen.
Incident Ein Incident ist eine Störung, die einen Service unterbricht oder seine Qualität mindert.
Incident Management Das Incident Management stellt den vereinbarten Betrieb so schnell wie möglich wieder her.
Problem Ein Problem ist die noch nicht beseitigte Ursache eines oder mehrerer Incidents.
Problem Management Das Problem Management findet die Ursache und verhindert, dass sich ein Incident wiederholt.
Change Ein Change ist jede Änderung an einem Service oder System, vom Update bis zum Umbau.
Service Request Ein Service Request ist keine Störung, sondern eine planbare Anfrage wie ein neuer Zugang.
Service Level Agreement (SLA) Das SLA legt fest, welche Leistung, Verfügbarkeit und Reaktionszeit vereinbart sind.
Configuration Management Database (CMDB) Die CMDB verzeichnet alle Komponenten eines Service und wie sie zusammenhängen.
Continual Improvement Continual Improvement heißt, Services anhand von Kennzahlen und Rückmeldungen laufend zu verbessern.

Am häufigsten werden Incident und Problem verwechselt. Wer einen Ausfall meldet, will, dass der Service wieder läuft. Warum er ausgefallen ist, klärt das Problem Management danach, oft mit anderen Beteiligten und in einem anderen Tempo. Wie die vereinbarte Verfügbarkeit gemessen wird, zeigt unser Beitrag zur Berechnung von Verfügbarkeit und Ausfallzeiten.

Wie arbeitet Adacor mit ITIL?

Wir nutzen ITIL als Gerüst für den Betrieb und als Grundlage für geprüfte Kontrollen. In unserem internen Kontrollsystem laufen drei Rahmenwerke zusammen: COSO für die internen Kontrollen, COBIT für die Steuerung der IT und der Service-Lebenszyklus von ITIL für die Betriebsprozesse. Eine Kontrolle bedient so mehrere Prüfungen, etwa die jährliche Prüfung nach IDW PS 951 und ISAE 3402.

Den 24/7-Betrieb unserer Infrastruktur organisieren wir entlang der ITIL-Begriffe. Für alle Anfragen gibt es eine zentrale Anlaufstelle, nachts und am Wochenende sind mindestens zwei Administratoren in Rufbereitschaft. Incidents stufen wir nach Schweregrad von P1 bis P4 ein, schwere Vorfälle werten wir in einem Post-Incident-Review aus, damit sich der Fehler nicht wiederholt. Jede Änderung läuft über ein Ticket und das Vier-Augen-Prinzip, ein Rollback-Plan ist Pflicht, Wartungsfenster kündigen wir an.

An einer Stelle weichen wir bewusst vom Lehrbuch ab. Viele Organisationen übersetzen ITIL in große Gremien und Ticketportale, hinter denen niemand mehr erreichbar ist. Bei uns entscheidet über eine Änderung kein Gremium mit zwölf Personen, sondern wer das System versteht. Kunden sprechen mit einem persönlichen Ansprechpartner, nicht mit einer Ticketnummer. Das folgt aus unserem Modell, in dem Planung, Aufbau und Betrieb bei einem Team liegen. ITIL 4 nennt den Gedanken dahinter selbst: „Keep it simple and practical“ ist einer seiner sieben Leitgedanken.

Die Daten, die diese Prozesse erzeugen, werten wir inzwischen auch mit KI aus. Unser selbst entwickeltes AIOps-Werkzeug verknüpft Monitoring, Hosts, Tickets und Deployments in einem Graphen. Bei einem Incident sieht das Team so Zusammenhänge, die sonst in getrennten Dashboards liegen.

Wie führt man ITIL im eigenen Unternehmen ein?

Am besten klein und mit den Begriffen, die täglich gebraucht werden. Das Rahmenwerk ist zu umfangreich, um es auf einmal einzuführen. Das verlangt ITIL auch nicht: „Start where you are“ ist ein weiterer Leitgedanke von ITIL 4. Bewährt hat sich diese Reihenfolge:

  1. Bestehende Services beschreiben: Was liefert die IT heute, für wen und in welcher Qualität? Ohne diese Bestandsaufnahme lässt sich nichts gezielt verbessern.
  2. Störungen und Anfragen trennen: Incidents und Service Requests getrennt erfassen, damit eine Störung nicht hinter einer Routineanfrage wartet.
  3. Changes steuern: Änderungen dokumentieren, von einer zweiten Person prüfen lassen und einen Weg zurück planen.
  4. Service Levels vereinbaren: messbare Ziele für Verfügbarkeit und Reaktionszeit festlegen, intern wie mit Dienstleistern.
  5. Messen und verbessern: Kennzahlen regelmäßig auswerten und daraus die nächsten Schritte ableiten.

Wichtig ist, die Teams früh einzubinden, die die Services erbringen, ohne zu viele Beteiligte an einen Tisch zu holen. Eine Vertretung je Team, die das Thema kennt, bringt mehr als eine große Runde.

Übernehmen wir den Betrieb einer bestehenden Umgebung, beginnen wir genauso. Beim Service Takeover nehmen wir Architektur, Abhängigkeiten, Zugänge und SLAs auf, richten das Monitoring ein und schreiben Runbooks für den Betrieb, auch wenn es vorher keine Dokumentation gab.

Brauchen Unternehmen ITIL-Kenntnisse?

Grundkenntnisse ja, ein vollständiges ITIL-Programm nein. Wer IT-Services einkauft oder auslagert, verhandelt über Service Levels, Reaktionszeiten und Änderungen. Wer die Begriffe kennt, erkennt, ob ein Angebot vollständig ist: ob es zwischen Incident und Problem unterscheidet, ob Wartungsfenster im SLA geregelt sind und was ein Change kostet. Dafür genügt meist der Stand einer Foundation-Schulung bei den Menschen, die Verträge verhandeln und Dienstleister steuern.

Fazit: ITIL ist vor allem eine gemeinsame Sprache

ITIL beschreibt, wie IT als Service funktioniert. Es gibt allen Beteiligten dieselben Begriffe. Mit Version 5 ist das Rahmenwerk um digitale Produkte und KI gewachsen, der Kern ist geblieben: Störungen schnell beheben, Ursachen finden, Änderungen kontrolliert umsetzen, Leistung messen. Wir nutzen ITIL als Gerüst für unseren Betrieb und als Grundlage für geprüfte Kontrollen, ohne Gremien und Formulare zum Selbstzweck zu machen. Wie ein Betrieb nach diesen Regeln für Ihre Plattform aussehen kann, besprechen wir gern in einem Fachgespräch mit unserem Team.