ISO 20000 — IT-Services im System

ISO/IEC 20000-1 beschreibt die Anforderungen an ein Service-Management-System für IT-Dienstleistungen. Sie ist der Prüfmaßstab, gegen den eine Zertifizierungsstelle bewertet, ob eine Organisation ihre Services planbar erbringt, steuert und verbessert.

Gedacht ist die Norm für alle, die IT-Leistungen als Service liefern und dafür geradestehen müssen: externe Dienstleister und Systemhäuser, Rechenzentrums- und Cloud-Betreiber, IT-Einheiten in Konzernen, Anbieter in öffentlichen Vergabeverfahren. Sie ist branchenneutral, aber inhaltlich eindeutig auf den Betrieb von Diensten zugeschnitten — nicht auf Softwareentwicklung, nicht auf Projektgeschäft.

Die häufigste Verwechslung betrifft ITIL. ITIL ist nicht zertifizierbar, jedenfalls nicht für Organisationen. Es ist eine Sammlung bewährter Praxis mit Empfehlungen, keine Anforderungsnorm. Personen können ITIL-Prüfungen ablegen, Unternehmen nicht. Wer ein Unternehmenszertifikat für IT-Service-Management braucht, landet bei ISO 20000. Umgekehrt gilt: Die Norm schreibt ITIL nicht vor. Sie beschreibt Ergebnisse, nicht Verfahren.

Was die Norm verlangt

Der Aufbau folgt der Struktur, die alle neueren Managementsystemnormen teilen. Kapitel 4 bis 7 und 9 bis 10 regeln den Rahmen, Kapitel 8 den eigentlichen Servicebetrieb — und dort liegt der überwiegende Teil der Arbeit.

Kapitel 8 gliedert sich in sechs Gruppen. Diese Aufteilung ist zugleich eine brauchbare Prüfliste für den eigenen Reifegrad:

Zwei Anforderungen daraus prägen den Zuschnitt eines Projekts stärker als alle anderen.

Die Steuerung anderer Beteiligter. Services dürfen ganz oder teilweise von Dritten erbracht werden — von Lieferanten, von Konzerneinheiten, auch vom Kunden selbst. Die Norm verlangt dann aber den Nachweis, dass Sie diesen Teil steuern: definierte Leistungen, vereinbarte Zielwerte, laufende Überwachung, Konsequenzen bei Abweichung. Wer eine Leistung vollständig durchreicht und nur die Rechnung weitergibt, kann sie nicht in den Geltungsbereich nehmen.

Kosten je Service. Kapitel 8 verlangt Budgetierung und Kostenverrechnung bezogen auf Services, nicht auf Kostenstellen. Für interne IT-Abteilungen ist das regelmäßig der unangenehmste Punkt, weil er eine Umstellung in der Buchhaltungssystematik nach sich zieht und nicht in der IT allein entschieden werden kann.

Die Fassung von 2018 hat außerdem eine Erwartung aufgegeben, die viele noch im Kopf haben: Sie schreibt keine bestimmten dokumentierten Verfahren mehr vor. Verlangt wird die dokumentierte Information, die für die Wirksamkeit des Systems nötig ist — welche das ist, entscheidet die Organisation und muss es begründen können. Für Unternehmen mit schlanker Dokumentation ist das eine Erleichterung, für Auditoren eine Verlagerung: Sie prüfen nicht mehr die Existenz eines Handbuchs, sondern ob die Steuerung tatsächlich trägt.

Für wen sich die Zertifizierung lohnt und wann nicht

Der stärkste Grund ist ein externer: Ausschreibungen. Bei Vergaben der öffentlichen Hand und bei Rahmenverträgen großer Auftraggeber ist ISO 20000 eine wiederkehrende Eignungsanforderung für Betriebsleistungen. Ohne Zertifikat scheiden Anbieter aus, bevor das Angebot inhaltlich gelesen wird.

Der zweite Grund ist der Wechsel vom Projekt- ins Betriebsgeschäft. Unternehmen, die bisher Software gebaut und dann übergeben haben, übernehmen zunehmend auch den Betrieb. Damit ändert sich die Leistungsverpflichtung grundlegend: Es geht nicht mehr um Abnahme, sondern um Verfügbarkeit über Jahre. Die Norm liefert dafür eine belastbare Struktur.

Der dritte Grund ist die Konzernvorgabe. Wenn eine Muttergesellschaft ihre IT-Einheiten vergleichbar machen will, ist ISO 20000 der übliche Maßstab, weil er messbare Zusagen erzwingt: Ohne definierte Services und vereinbarte Zielwerte lässt sich die Leistung zweier Standorte nicht gegenüberstellen. Dieser Nebeneffekt ist oft der eigentliche Auslöser, auch wenn im Projektauftrag etwas anderes steht.

Gegen ein Projekt sprechen andere Konstellationen. Eine interne IT ohne Nachweispflicht hat vom Zertifikat wenig, von einzelnen Praktiken aber viel — Servicekatalog, Problemmanagement und Kapazitätsplanung wirken auch ohne Auditor. Auch Organisationen, deren Wertschöpfung in der Entwicklung liegt, greifen mit ISO 20000 daneben: Die Norm sagt nichts über Codequalität, Architektur oder Releasequalität in der Entwicklung. Und wer weniger als eine Handvoll klar abgrenzbarer Services betreibt, sollte prüfen, ob ISO 9001 mit sauber beschriebenen Prozessen nicht der angemessenere Rahmen ist.

Der Weg zum Zertifikat

Der Ablauf einer Zertifizierung unterscheidet sich nicht grundsätzlich. Drei Punkte verdienen dennoch Aufmerksamkeit.

Der Geltungsbereich ist die eigentliche Entscheidung. Er wird über Services definiert, nicht über Abteilungen, und er steht später auf dem Zertifikat. Ein zu enger Geltungsbereich macht das Zertifikat im Vertrieb wertlos, ein zu weiter erzeugt Nachweispflichten für Leistungen, die Sie gar nicht steuern. Die Frage „Welche Services will unser Kunde im Zertifikat lesen?“ gehört an den Anfang, nicht ans Ende.

Der Auditor folgt dem Service, nicht dem Organigramm. Er nimmt eine Störung aus dem Ticketsystem und verfolgt sie: Aufnahme, Priorisierung nach vereinbarten Kriterien, Eskalation, Lösung, Information des Kunden, Verbindung zu einem Problemdatensatz. Diese Auditspur durchquert mehrere Prozesse und deckt Brüche zwischen ihnen auf.

Nachweise entstehen im Betrieb, nicht im Projekt. Servicebewertungen mit Kunden, Kapazitätsberichte, Änderungsentscheidungen mit Bewertung des Ergebnisses, Auswertungen von Zielwertverfehlungen: Diese Belege brauchen mehrere Monate Laufzeit. Ein System, das drei Wochen vor dem Audit erstmals Berichte erzeugt, hat keine Historie vorzuweisen.

Woran Projekte scheitern

Der Servicekatalog listet Systeme. „Exchange“, „SAP-Basisbetrieb“, „Netzwerk“ — das sind technische Bausteine, keine Services aus Sicht des Kunden. Ein Servicekatalog, den der Fachbereich nicht versteht, taugt nicht als Grundlage für Vereinbarungen.

Service-Level werden zugesagt, aber nicht gemessen. Oder sie werden gemessen, aber auf Daten, die der Kunde nicht nachvollziehen kann. Am häufigsten fehlt die Definition, wann die Uhr steht: Wartungsfenster, Rückfragen beim Anwender, Wartezeit auf Dritte.

Problemmanagement ist Incidentmanagement mit anderem Namen. Es gibt keine Datensätze über bekannte Fehler, keine Analyse wiederkehrender Störungen, keine proaktive Suche nach Ursachen. Der Auditor erkennt das daran, dass jeder Problemdatensatz genau einen Incident als Auslöser hat.

Fast jede Änderung ist eine Notfalländerung. Damit wird die Bewertung vor der Umsetzung umgangen. Ein Änderungsverfahren, in dem der Ausnahmeweg der Regelweg ist, führt zuverlässig zu einer Feststellung — meist einer Hauptabweichung, weil die Steuerung des Kernprozesses nicht wirksam ist.

Lieferantenverträge stützen die eigenen Zusagen nicht. Dem Kunden ist eine Wiederherstellzeit von vier Stunden zugesagt, der Subunternehmer schuldet Reaktion am nächsten Werktag. Diese Lücke fällt spätestens bei der Lieferantenbewertung auf und ist vertraglich nur langsam zu schließen.

Die Konfigurationsdatenbank wird nicht geprüft. Sie existiert, sie wird gepflegt, aber niemand vergleicht sie stichprobenartig mit der Wirklichkeit. Ohne diese Prüfung ist sie kein Nachweis, sondern eine Behauptung.

Kapazitätsmanagement ist Beschaffung. Erweitert wird, wenn es eng wird. Die Norm verlangt eine Vorausschau, die Geschäftsentwicklung und technische Auslastung verbindet — und die Verbindung zum Nachfragemanagement, damit absehbare Lastspitzen vorher bekannt sind.

Der Kontinuitätsplan wurde nie geübt. Dieselbe Feststellung wie bei jeder Norm mit Kontinuitätsanforderungen. Sie ist so verbreitet, dass Auditoren im Eröffnungsgespräch direkt nach dem Datum der letzten Übung fragen.

Verbesserungen werden gesammelt, nicht abgeschlossen. Eine Liste mit vierzig offenen Punkten, davon die Hälfte älter als zwei Jahre, ist kein Beleg für fortlaufende Verbesserung — sondern für das Gegenteil.

Abgrenzung zu Rahmenwerken und verwandten Normen

In der Praxis kommt ISO 20000 selten allein. Die häufigste Kombination ist die mit ISO 27001: Der Kunde will wissen, ob der Betrieb funktioniert und ob seine Daten sicher sind. Beide Systeme teilen Kontext, Führung, Kompetenzregelung, Dokumentenlenkung, internes Audit und Managementbewertung. Getrennt aufgebaut kosten sie fast das Doppelte — mit dem zusätzlichen Nachteil, dass zwei Systeme auseinanderlaufen, sobald sich die Organisation ändert. Wie viele Prozesse ein solches System tatsächlich braucht, ist dabei keine Frage der Norm, sondern des Zuschnitts: dazu der Beitrag zur Prozessanzahl im Managementsystem.