Bildquelle: Pexels / Foto-ID 669610 / https://www.pexels.com/photo/669610/ / CC0-Lizenz
ITIL und ISO 20000 werden im IT-Betrieb häufig gemeinsam genannt. Im Audit stellen sie aber unterschiedliche Fragen. ITIL hilft dabei, Servicearbeit zu gestalten. ISO 20000 verlangt, dass Steuerung, Rollen, Ziele und Nachweise als Managementsystem belegbar sind.
Für ITSM-Generalisten ist dieser Unterschied mehr als ein Begriffsthema. In vielen Organisationen entstehen Serviceprozesse zuerst aus ITIL-Begriffen: Incident Management, Change Enablement, Problem Management, Service Level Management oder Continual Improvement. Das ist nützlich, weil Teams eine gemeinsame Sprache bekommen. Spätestens im Audit reicht die Sprache allein aber nicht mehr. Dann zählt, ob Entscheidungen, Verantwortlichkeiten, Messpunkte, Reviews und Verbesserungen im laufenden Betrieb nachvollziehbar dokumentiert sind.
ISO 20000 ist deshalb nicht einfach „ITIL mit Zertifikat“. Die Norm fragt nicht nur, ob ein Prozessname existiert. Sie fragt, ob ein Service-Management-System gesteuert wird, ob Anforderungen bekannt sind, ob Rollen zugeordnet sind, ob Risiken betrachtet werden, ob Leistung überwacht wird und ob Verbesserungen aus Belegen entstehen. ITIL kann dabei helfen. Es ersetzt aber nicht den Nachweis, dass die Organisation diese Arbeitsweise tatsächlich lebt.
ITIL liefert Sprache für die tägliche Servicearbeit
ITIL ist für viele Teams der praktische Einstieg in strukturiertes IT-Service-Management. Es hilft, wiederkehrende Aufgaben zu sortieren: Störungen aufnehmen, Änderungen bewerten, Wissen nutzbar machen, Services beschreiben, Lieferanten steuern und Verbesserungen planen. Der Nutzen liegt weniger in einzelnen Begriffen als in einer gemeinsamen Arbeitslogik. Wenn Service Desk, Betrieb, Fachbereich und Management unter einem Incident dasselbe verstehen, sinkt Reibung im Alltag.
Diese Stärke zeigt sich besonders bei Prozessdesign und Rollenklärung. Ein Team kann mit ITIL prüfen, wo ein Ticket hängen bleibt, welche Übergabe fehlt oder welche Rolle in einer Freigabe unklar ist. Der Beitrag ITIL Practices nach Betriebsaufgabe auswählen folgt genau diesem Prinzip: Nicht jede Practice muss sofort aufgebaut werden. Entscheidend ist, welche Arbeit im Betrieb gerade eine belastbare Struktur braucht.
Für ein Audit ist diese Struktur ein Anfang, aber kein Ende. Ein Prozessdiagramm beweist noch nicht, dass der Prozess beherrscht wird. Eine Rollenbeschreibung beweist noch nicht, dass Entscheidungen wirklich dokumentiert werden. Eine KPI-Liste beweist noch nicht, dass Abweichungen bewertet und Verbesserungen ausgelöst werden. Hier beginnt der Unterschied zu ISO 20000.
ISO 20000 fragt nach dem steuerbaren Managementsystem
ISO 20000 richtet den Blick stärker auf das System hinter der Servicearbeit. Die Norm erwartet, dass Service Management geplant, betrieben, überwacht und verbessert wird. Dafür braucht es Ziele, Verantwortlichkeiten, dokumentierte Informationen, Leistungsbewertung, Umgang mit Risiken und Chancen sowie nachvollziehbare Verbesserungen. Das klingt formeller als ITIL, ist im Betrieb aber sehr konkret.
Ein Beispiel: Ein Unternehmen kann einen Change-Prozess nach ITIL-Begriffen beschreiben. Für ISO 20000 stellt sich zusätzlich die Frage, wie Anforderungen an Changes gesteuert werden, welche Kriterien für Bewertung und Freigabe gelten, wie Ausnahmen dokumentiert werden und wie aus Fehlern Verbesserungen entstehen. Der Beitrag Change Management Prozess in der IT zeigt, wie Risikoklassen Entscheidungen strukturieren. Für die Norm braucht der Betrieb dann auch Nachweise, dass diese Struktur regelmäßig verwendet und überprüft wird.
Damit verschiebt sich die Diskussion. Es geht nicht darum, möglichst viele Dokumente zu erzeugen. Es geht darum, die Belege zu kennen, die zeigen, ob der Servicebetrieb steuerbar ist. Ein Audit sucht nicht nach schönen Prozessnamen, sondern nach einer nachvollziehbaren Kette aus Anforderung, Entscheidung, Umsetzung, Messung und Verbesserung.
Der häufigste Fehler ist die falsche Erwartung
Viele Teams erwarten von ITIL eine Zertifizierungssicherheit, die ITIL allein nicht liefern kann. Andere erwarten von ISO 20000 eine fertige Prozessbibliothek, die die Norm nicht sein will. Beides führt in die Irre. ITIL gibt Orientierung für gute Praxis. ISO 20000 beschreibt Anforderungen an ein Managementsystem, das geprüft werden kann. Wer diese Rollen verwechselt, baut entweder zu weiche Prozesse oder zu schwere Dokumentation.
Zu weiche Prozesse entstehen, wenn ein Team nur Begriffe übernimmt. Dann gibt es vielleicht eine Incident-Kategorie, aber keine saubere Eskalationsregel. Es gibt ein Service Review, aber keine Entscheidungsliste. Es gibt Service Level, aber keine belastbaren Messpunkte. Der Artikel SLA Vorlage mit Messpunkten zeigt, warum Zusagen erst dann prüfbar werden, wenn Startpunkt, Messpunkt, Wartezeit und Verantwortlichkeit eindeutig sind.
Zu schwere Dokumentation entsteht, wenn ISO 20000 als Papierübung verstanden wird. Dann sammelt der Betrieb Formulare, Policies und Präsentationen, ohne die tägliche Servicearbeit zu verbessern. Im Audit mag kurzfristig etwas vorzeigbar sein. Im Alltag bleiben die gleichen Brüche bestehen: Tickets ohne Entscheidung, Changes ohne Rückweg, Lieferanten ohne klare Eskalation und Reviews ohne wirksame Maßnahmen.
Welche Belege der Betrieb wirklich braucht
Eine pragmatische Trennung hilft. ITIL-Fragen lauten: Wie soll die Arbeit fließen? Welche Rolle übernimmt welchen Schritt? Wo entsteht Kundennutzen? Welche Practice hilft bei dieser konkreten Betriebsaufgabe? ISO-20000-Fragen lauten: Wo ist die Regel festgelegt? Wer verantwortet sie? Wo wurde sie angewendet? Wie wird gemessen? Was passiert bei Abweichung? Welche Verbesserung wurde daraus abgeleitet?
Aus dieser Trennung entsteht eine einfache Beleglandkarte. Für Incident Management braucht der Betrieb nicht nur ein Prozessbild, sondern Beispiele für Priorisierung, Eskalation, Kommunikation und Abschlussbewertung. Für Change braucht er Kriterien, Freigaben, Risikobewertung, Rückfallplanung und Nachbereitung. Für Service Level braucht er vereinbarte Ziele, Messdaten, Ausnahmen und Review-Protokolle. Für Supplier Management braucht er Verantwortliche, Leistungsdaten, Eskalationswege und Entscheidungen aus Lieferantengesprächen.
Der Beitrag Service Review vorbereiten mit Entscheidungen statt KPI-Folien passt dazu. Ein Review ist erst dann wertvoll, wenn aus Daten Entscheidungen werden. Genau diese Entscheidungsspur ist im Audit wichtiger als eine Präsentation mit grünen Kurven.
Kopierbares Artefakt für die Vorbereitung
Für die nächste interne Prüfung reicht oft eine kurze Arbeitsliste. Sie sollte nicht als Bürokratie verstanden werden, sondern als Übersetzung zwischen Prozesspraxis und Nachweisführung.
- Prozessfrage: Welche ITIL-Logik nutzen wir für diese Betriebsaufgabe?
- Normfrage: Welche ISO-20000-Anforderung berührt diese Arbeit?
- Verantwortung: Welche Rolle entscheidet, welche Rolle führt aus und welche Rolle prüft?
- Arbeitsbeleg: Welches Ticket, Protokoll, Review oder Register zeigt die tatsächliche Anwendung?
- Messpunkt: Welche Kennzahl oder Beobachtung zeigt, ob der Prozess wirkt?
- Abweichung: Wo wird festgehalten, wenn die Regel nicht passt oder nicht eingehalten wurde?
- Verbesserung: Welche Maßnahme wurde aus Review, Audit, Incident oder Beschwerde abgeleitet?
- Aktualität: Wann wurde die Regel zuletzt geprüft und wer hat sie bestätigt?
Diese Liste ersetzt kein vollständiges Auditprogramm. Sie verhindert aber, dass Teams mit Prozessnamen in ein Nachweisgespräch gehen. Sie zwingt dazu, schon vor dem Termin zu prüfen, ob der Betrieb tatsächlich zeigen kann, was er behauptet.
FAQ zu ITIL und ISO 20000 im Betrieb
Braucht ein Team ISO 20000, um ITIL sinnvoll zu nutzen?
Nein. ITIL kann auch ohne Zertifizierungsziel helfen, Servicearbeit klarer zu strukturieren. ISO 20000 wird relevant, wenn ein prüfbares Service-Management-System aufgebaut oder zertifiziert werden soll.
Ersetzt eine ISO-20000-Zertifizierung gute ITIL-Praxis?
Nein. Eine Zertifizierung zeigt, dass Anforderungen an das Managementsystem erfüllt werden. Sie garantiert nicht automatisch, dass jede operative Entscheidung klug, schnell oder kundennah getroffen wird.
Was sollte zuerst geprüft werden?
Praktisch ist der Start bei häufigen Betriebsbrüchen: unklare Eskalationen, schwache Service Reviews, schlecht messbare SLAs oder Changes ohne Rückweg. Danach lässt sich klären, welche ITIL-Logik hilft und welcher ISO-20000-Nachweis nötig ist.
Der Betrieb braucht beides, aber nicht als Mischmasch
ITIL und ISO 20000 sind dann stark, wenn sie nicht verwechselt werden. ITIL gibt dem Betrieb eine verständliche Arbeitslogik. ISO 20000 zwingt dazu, Steuerung und Nachweise belastbar zu machen. Wer beides sauber trennt, kann Prozesse gestalten, ohne im Audit mit leeren Begriffen dazustehen. Gleichzeitig bleibt die Dokumentation nah genug an der täglichen Arbeit, damit sie nicht nur für den Prüfungsordner existiert.
Für ITSM-Verantwortliche ist die wichtigste Frage daher nicht, welches Kürzel wichtiger ist. Wichtiger ist, welche Servicearbeit gerade verbessert werden muss und welcher Beleg später zeigt, dass diese Verbesserung wirklich stattgefunden hat. Genau an dieser Schnittstelle entstehen weniger Papierprozesse und mehr verlässliche Steuerung im Betrieb.
Quellen und Stand: Quellenprüfung am 03.09.2026 anhand des PeopleCert-Überblicks zu ITIL, der AXELOS-Seite zu ITIL Service Management, des BSI-Überblicks zu ISO/IEC 20000-1 und der Advisera-Einordnung zu ISO 20000. Es werden keine konkreten Preise, Tarife oder Beträge genannt. Bildquelle: Pexels / Foto-ID 669610 / CC0-Lizenz