Bildquelle: Bildquelle: Pexels / RDNE Stock project / https://www.pexels.com/photo/a-person-using-a-magnifying-glass-on-a-document-7821674/
ISO/IEC 20000 prüft im Alltag keine Tool-Demos, sondern belastbare Übergaben
Viele Service-Organisationen unterschätzen, woran ISO/IEC 20000 im Alltag wirklich sichtbar wird. Nicht an besonders schönen Prozessfolien, nicht an einem frisch aufgeräumten Ticket-Tool und auch nicht an einem Audit-Ordner voller Einzelbelege. Entscheidend ist, ob zwischen Servicekatalog, Änderungen, Lieferantensteuerung, Eskalationen und Verbesserungen belastbare Übergaben funktionieren.
Gerade deshalb führt die Norm in vielen Häusern zu einer typischen Fehleinschätzung. Es wird viel Energie in einzelne Prozesse, Vorlagen oder Tool-Screens investiert, aber zu wenig in die Stellen, an denen Informationen und Verantwortung tatsächlich von einem Schritt zum nächsten wechseln. Genau dort zeigen Audits dann die eigentlichen Brüche: Der Servicekatalog verspricht etwas, das im Betrieb nirgends sauber gemessen wird. Änderungen werden dokumentiert, aber ihre Service-Auswirkungen bleiben diffus. Lieferanten liefern Leistungen, doch Eskalationen, Nachweise und Verbesserungen laufen an der eigenen Service-Steuerung vorbei.
Wer ISO/IEC 20000 nur als Zertifizierungsprojekt behandelt, erkennt diese Lücken oft zu spät. Wer den Standard dagegen als Betriebsmodell versteht, gewinnt einen viel praktischeren Blick: Welche Zusage ist wo dokumentiert? Wer übernimmt an welcher Stelle Verantwortung? Und welche Evidenz zeigt, dass die Zusage im laufenden Betrieb wirklich getragen wird?
Warum Audits heute eher Serviceflüsse als Prozessfolien lesen
ISO und BSI beschreiben ISO/IEC 20000 ausdrücklich als Rahmen für ein Service Management System, also für das geordnete Planen, Erbringen, Überwachen und Verbessern von Services. Genau deshalb endet eine Prüfung selten an der Frage, ob ein einzelner Prozess formal vorhanden ist. Viel interessanter ist, ob mehrere Teile des Systems zusammenwirken.
In der Praxis heißt das: Ein Audit springt gedanklich über Abteilungsgrenzen. Es verbindet den beschriebenen Service mit seinen Zielgruppen, Rollen, Abhängigkeiten, Lieferanten, Change-Abläufen, Kennzahlen und Verbesserungen. Diese Querprüfung ist für viele Teams unbequemer als das reine Vorzeigen eines Tools, aber sie ist näher an der Realität des Betriebs. Denn Servicequalität entsteht nie nur an einer Stelle. Sie entsteht in der Kette aus Vereinbarung, Umsetzung, Übergabe, Überwachung und Korrektur.
Darum sind glänzende Tool-Demos allein wenig wert. Ein modernes ITSM-Werkzeug kann Tickets, Changes, Knowledge, Assets oder SLAs hervorragend darstellen. Aber ein Audit interessiert sich nicht primär für die Oberfläche, sondern für die Nachvollziehbarkeit. Wenn die Servicebeschreibung unklar ist, Owner wechseln, Lieferanten außerhalb des Steuerungsmodells handeln oder Kennzahlen nicht an Entscheidungen anschließen, dann bleibt das Werkzeug ein gutes Frontend für eine schlechte Übergabequalität.
Der Servicekatalog ist kein Schaufenster, sondern die Referenz für Scope und Zusagen
Viele Organisationen pflegen ihren Servicekatalog noch immer eher als Kommunikationsartefakt denn als Steuerungsobjekt. Dort stehen Leistungsversprechen, Supportzeiten, Zielgruppen oder Kontaktwege – aber oft ohne saubere Verbindung zu Verantwortlichkeiten, Eskalationswegen, Abhängigkeiten und messbaren Servicezielen. Genau das wird unter ISO/IEC 20000 problematisch.
Der Servicekatalog ist operativ nur dann belastbar, wenn aus ihm eindeutig hervorgeht, was ein Service umfasst, was bewusst nicht dazugehört, wer verantwortlich ist, welche Lieferantenbeiträge eingehen und an welchen Stellen Risiken oder Ausnahmen geregelt sind. Fehlt diese Präzision, entstehen zwei typische Probleme. Erstens bewertet das Audit zwar einen dokumentierten Service, trifft im Betrieb aber auf mehrere widersprüchliche Varianten. Zweitens lassen sich Reklamationen, Changes oder Verbesserungen nicht klar auf dieselbe Service-Definition zurückführen.
Gerade in hybriden Landschaften mit Cloud, Managed Services und internen Plattformteams wird das schnell kritisch. Dann hängt ein Service an mehreren Betriebsanteilen, aber niemand hat die End-to-End-Sicht sauber aufgeschrieben. Der Katalog sieht vollständig aus, trägt aber die eigentlichen Übergaben nicht. Für ISO/IEC 20000 ist genau das kein Schönheitsfehler, sondern ein Steuerungsdefizit.
Changes müssen Wirkung, Risiko und Belegführung zusammenhalten
Änderungsmanagement ist unter ISO/IEC 20000 nicht deshalb wichtig, weil irgendwo ein CAB-Protokoll abgelegt werden kann. Relevant ist, ob Änderungen nachvollziehbar bewertet, entschieden, umgesetzt und nachverfolgt werden – und zwar in Bezug auf den betroffenen Service. Genau hier trennen sich Dokumentation und Wirksamkeit.
Viele Teams dokumentieren sauber, dass eine Änderung beantragt und freigegeben wurde. Weniger sauber ist oft die Verbindung zur Servicewirkung. Welche Zusage im Servicekatalog berührt die Änderung? Welche Lieferanten oder Betriebspartner müssen mitziehen? Welche Rollback- oder Eskalationswege existieren? Und welche Evidenz zeigt nach der Umsetzung, dass die Änderung das Risiko reduziert oder zumindest kontrolliert eingeführt wurde?
Wenn diese Fragen unbeantwortet bleiben, entsteht ein bekanntes Audit-Muster: Die Change-Dokumentation wirkt formal vorhanden, aber die betriebliche Steuerung bleibt lückenhaft. Dann sieht das Gremium zwar Aktivität, aber keine belastbare Kette aus Bewertung, Entscheidung und Wirkung. Genau deshalb sollten Service- und Change-Verantwortliche nicht nur Freigaben sammeln, sondern die Nachweise rund um Auswirkungen, Kommunikation, Lieferantenabhängigkeiten und Nachkontrolle enger zusammenführen.
Lieferantensteuerung ist kein Appendix zum Vertrag
Besonders häufig brechen ISO/IEC-20000-Setups an der Lieferantensteuerung. Der Grund ist simpel: In vielen Organisationen werden Lieferanten zwar vertraglich geführt, operativ aber nicht sauber in das eigene Service Management System eingebunden. Eskalationen laufen separat, Leistungsnachweise liegen in Einkauf oder Vendor Management, Verbesserungen werden bilateral vereinbart und Serviceverantwortliche sehen nur Ausschnitte.
Das genügt für einen belastbaren Servicebetrieb selten. Sobald externe Beiträge Teil des eigenen Leistungsversprechens sind, muss die Lieferantensteuerung an dieselbe Service-Logik anschließen wie interne Teams. Sonst weiß im Ernstfall niemand, welche Abhängigkeit gerade verletzt wird, welche Reaktionszeit wirklich zugesagt war oder auf welcher Basis eine Abweichung eskaliert werden muss.
Für Audits ist das deshalb relevant, weil Lieferantenbeiträge nicht außerhalb des Scope verschwinden dürfen, sobald sie für die Serviceerbringung wesentlich sind. Praktisch heißt das: Leistungsbeziehungen, Review-Rhythmen, Abweichungen, Eskalationen und Verbesserungsmaßnahmen müssen aus Sicht des Service nachvollziehbar werden. Ein sauber archivierter Vertrag ersetzt diese operative Sicht nicht.
Kennzahlen und Verbesserungen brauchen mehr als Monatsreports
PECB und BSI betonen beide den Gedanken der kontinuierlichen Verbesserung. Auch dieser Punkt wird in der Praxis oft unterschätzt, weil Teams Verbesserungen mit Reporting verwechseln. Ein Dashboard oder Monatsreport ist aber noch kein Verbesserungsprozess. Wert entsteht erst, wenn Kennzahlen Entscheidungen auslösen und wenn deren Wirkung wieder nachvollziehbar wird.
Unter ISO/IEC 20000 sollten Kennzahlen deshalb nicht nur gesammelt, sondern an Servicezusagen, Risiken und Ursachen angeschlossen werden. Wer Abweichungen erkennt, muss zeigen können, wie daraus eine Bewertung, Priorisierung und Korrektur entsteht. Noch wichtiger ist die Schleife zurück: Wurde etwas wirklich verbessert oder nur dokumentiert, dass man darüber gesprochen hat?
Genau an dieser Stelle zeigt sich die Reife eines Service Management Systems besonders deutlich. Reife Teams können erklären, welche Daten sie warum verfolgen, welche Abweichungen relevant sind, wer Entscheidungen trifft und wie Verbesserungen in Katalog, Betrieb, Lieferantensteuerung oder Change-Routinen zurückgespielt werden. Unreife Teams produzieren dagegen viele Reports, aber wenig anschlussfähige Wirkung.
Was Teams vor dem nächsten Audit konkret ordnen sollten
- Servicekatalog schärfen: Scope, Zusagen, Ausschlüsse, Owner, Lieferantenbeiträge und Eskalationspfade pro Service eindeutig beschreiben.
- Change-Nachweise verdichten: Nicht nur Freigaben ablegen, sondern Serviceauswirkung, Kommunikation, Risiko und Nachkontrolle sauber verbinden.
- Lieferanten an die Service-Logik anbinden: Reviews, KPIs, Abweichungen und Verbesserungen aus Sicht des verantworteten Services dokumentieren.
- Kennzahlen auf Entscheidungen zurückführen: Für jede relevante Metrik sollte erkennbar sein, welche Entscheidung oder Korrektur sie auslösen kann.
- Verbesserungen rückverfolgbar machen: Was wurde geändert, warum, mit welchem erwarteten Effekt und mit welchem überprüfbaren Ergebnis?
Diese Vorarbeit ist mühsamer als ein kurzes Audit-Polishing. Sie zahlt sich aber doppelt aus: für die Prüfung und für den Betrieb. Denn dieselben Lücken, die Audits sichtbar machen, verursachen meist auch Reibung im Alltag – etwa in Störungen, Abstimmungen, Eskalationen oder Lieferantenkonflikten.
Fazit
ISO/IEC 20000 bewertet im Kern nicht, wie elegant ein Tool aussieht, sondern wie belastbar ein Service Management System Übergaben organisiert. Genau deshalb sind Servicekatalog, Change-Steuerung, Lieferantenbelege und Verbesserungsnachweise keine isolierten Pflichtfelder, sondern Teile derselben Betriebskette.
Wer diese Kette sauber aufbaut, erlebt Audits deutlich entspannter und gewinnt nebenbei einen stabileren Servicebetrieb. Wer dagegen nur einzelne Prozessinseln optimiert, produziert oft gute Screenshots – aber keine durchgängige Steuerbarkeit. Im Alltag ist genau das der Unterschied zwischen zertifizierbar und tragfähig.
