Bildquelle: extern
Alte Servicekataloge verstecken Kosten, die erst bei Störungen auffallen
Ein Servicekatalog soll Orientierung geben. Er zeigt, welche IT-Leistungen es gibt, wer sie bestellen kann, welche Zusagen gelten und wohin eine Anfrage gehört. Im Alltag wird daraus jedoch schnell eine hübsche Liste, die niemand mehr ernsthaft pflegt. Dann stehen dort Services, die längst anders betrieben werden, Kontakte, die nicht mehr zuständig sind, und Leistungsversprechen, die im Störungsfall niemand einlösen kann.
Für ITSM-Generalisten ist genau das gefährlich. Der Servicekatalog wirkt zunächst wie ein Ordnungssystem für Nutzer und Fachbereiche. Tatsächlich ist er auch ein Steuerungsinstrument für Kosten, Risiken, Supportwege und Betriebsverantwortung. Wenn alte Einträge stehen bleiben, merken Teams den Schaden oft erst dann, wenn ein Ausfall, eine Prüfung oder eine Budgetfrage Druck erzeugt.
Kurze Einordnung: Ein IT-Servicekatalog beschreibt die bestellbaren oder nutzbaren IT-Services einer Organisation. Er verbindet Nutzerbedarf mit Betriebsverantwortung, Supportwegen, Servicezeiten und oft auch mit Genehmigungen oder Kostenstellen. IT Service Management, kurz ITSM, nutzt solche Kataloge, damit Leistungen nicht nur technisch existieren, sondern für Nutzer und Betrieb nachvollziehbar gesteuert werden.
Ein Katalog ist kein Schaufenster, sondern ein Betriebsversprechen
Der häufigste Fehler liegt in der Perspektive. Ein Servicekatalog wird als Portalprojekt gestartet, als Self-Service-Oberfläche gestaltet und nach dem Go-live als erledigt betrachtet. Danach wächst die Organisation weiter. Neue Tools kommen hinzu, alte Anwendungen bleiben im Hintergrund aktiv, Verträge ändern sich, Rollen wechseln, Servicezeiten werden angepasst. Der Katalog sieht stabil aus, aber die Wirklichkeit dahinter verschiebt sich.
Damit entsteht ein stiller Unterschied zwischen Angebot und Betrieb. Ein Fachbereich bestellt einen Service nach alter Beschreibung. Der Service Desk verweist auf ein Team, das die Aufgabe nicht mehr trägt. Die Sicherheitsabteilung erwartet eine Prüfung, die im Bestellweg nicht vorgesehen ist. Der Einkauf sieht Kosten erst später, weil der Katalog keine klare Zuordnung erzwingt. Jeder einzelne Fall wirkt klein. Zusammen entsteht ein teurer Reibungsverlust.
Veraltete Einträge erzeugen falsche Erwartungen
Ein alter Servicekatalog ist besonders problematisch, weil er offiziell wirkt. Nutzerinnen und Nutzer vertrauen der sichtbaren Beschreibung. Wenn dort steht, dass ein Dienst in zwei Tagen bereitsteht, erwarten sie diese Frist. Wenn ein Supportkanal genannt ist, nutzen sie genau diesen Weg. Wenn eine Leistung als Standardangebot erscheint, planen Projekte damit.
Der Betrieb muss die Lücke dann auffangen. Aus Sicht des Service Desk werden Anfragen unklarer, Rückfragen häufiger und Eskalationen unangenehmer. Aus Sicht des IT-Managements verschwinden echte Kosten in Korrekturen, Sonderwegen und manueller Abstimmung. Aus Sicht der Fachbereiche entsteht der Eindruck, IT-Prozesse seien langsam, obwohl die Ursache im ungepflegten Leistungsversprechen liegt.
Kosten entstehen nicht nur durch Tools
Bei Servicekatalogen wird oft über Portalsoftware, Workflows und Automatisierung gesprochen. Das ist verständlich, aber nicht der Kern. Die größten Kosten entstehen häufig dort, wo Zuständigkeit, Leistungsgrenze und Folgeschritt unklar bleiben. Ein Bestellformular ohne verantwortlichen Service Owner spart keine Arbeit. Ein Genehmigungsweg ohne klare Entscheidungskriterien verlagert nur die Rückfrage. Eine automatische Weiterleitung an das falsche Team beschleunigt den Fehler.
Deshalb braucht jeder Katalogeintrag eine einfache Betriebsprüfung. Existiert der Service noch in dieser Form? Wer besitzt ihn fachlich und technisch? Welche Nutzergruppe darf ihn verwenden? Welche Kosten oder Lizenzfolgen entstehen? Welche Sicherheits- oder Datenschutzprüfung ist nötig? Welche Supportstufe übernimmt den ersten Kontakt? Und welche Zusage ist realistisch, nicht nur wünschenswert?
Service Owner müssen Löschrechte haben
Ein Katalog bleibt nur zuverlässig, wenn jemand Einträge nicht nur erstellen, sondern auch ändern, sperren oder löschen darf. Genau dieser Punkt wird organisatorisch unterschätzt. Niemand möchte einen vertrauten Serviceeintrag entfernen, weil irgendwo noch ein Nutzer ihn brauchen könnte. Also bleibt er sichtbar, bekommt vielleicht einen Hinweistext und erzeugt weiter Anfragen.
Besser ist ein klarer Lebenszyklus. Neue Services kommen mit Mindestdaten in den Katalog. Bestehende Services erhalten regelmäßige Reviews. Auslaufende Services bekommen ein sichtbares Enddatum, Ersatzweg und Migrationshinweis. Nicht mehr gültige Einträge verschwinden aus der Bestelloberfläche, bleiben aber intern dokumentiert. So wird der Katalog nicht zur Ablage, sondern zur aktuellen Arbeitsfläche.
Der Service Desk erkennt die Schwachstellen zuerst
Service-Desk-Mitarbeitende sehen oft früher als das Management, welche Katalogeinträge nicht mehr stimmen. Sie hören dieselben Rückfragen, leiten Tickets um und erklären Ausnahmen. Dieses Wissen sollte nicht informell bleiben. Ein einfacher Feedbackweg aus dem Service Desk in die Katalogpflege ist ein praktischer Qualitätshebel.
Hilfreich sind Kennzahlen, die auf Pflegebedarf hindeuten. Dazu zählen häufige Rückfragen zu einem Eintrag, viele manuelle Weiterleitungen, überdurchschnittlich lange Bearbeitungszeiten, wiederkehrende Genehmigungskonflikte oder Tickets mit falscher Kategorie. Solche Signale zeigen nicht nur Prozessprobleme. Sie zeigen, wo der Katalog seine Orientierungsfunktion verliert.
Eine kleine Review-Routine reicht oft aus
Die Lösung muss nicht groß beginnen. Für einen wirksamen Start genügt eine Liste der meistgenutzten Katalogeinträge. Jeder Eintrag wird gegen vier Fragen geprüft: Ist die Beschreibung für Nutzer verständlich? Stimmt die interne Zuständigkeit? Passt der Bestellweg zur tatsächlichen Bearbeitung? Sind Kosten, Risiken und Abhängigkeiten sichtbar genug?
Danach folgt eine harte Entscheidung. Aktualisieren, vorübergehend sperren, zusammenlegen oder entfernen. Gerade das Entfernen ist wichtig, weil ein Katalog sonst mit jedem Jahr schwerer wird. Ein schlanker, aktueller Katalog ist für Nutzer wertvoller als ein großes Verzeichnis mit zweifelhaften Versprechen.
Was IT-Management jetzt prüfen sollte
- Gibt es für jeden wichtigen Katalogeintrag einen benannten Service Owner?
- Wird sichtbar, welche Kosten, Lizenzen oder Genehmigungen mit einem Service verbunden sind?
- Kann der Service Desk fehlerhafte Einträge direkt zur Korrektur melden?
- Haben auslaufende Services ein Enddatum, einen Ersatzweg und einen Kommunikationsplan?
- Wer entscheidet, dass ein Eintrag aus der Nutzeransicht entfernt wird?
Der Servicekatalog ist damit kein Nebenprojekt der Portalpflege. Er ist eine laufende Betriebsverantwortung. Wer ihn aktuell hält, reduziert Rückfragen, Fehlbestellungen und Schattenkosten. Wer ihn liegen lässt, merkt die Lücke spätestens dort, wo Nutzer, Kostenstelle und Betrieb gleichzeitig eine verlässliche Antwort brauchen.
Quellen und Einordnung
- Atlassian, Überblick zu IT-Servicekatalogen und Service Request Management: https://www.atlassian.com/itsm/service-request-management/service-catalog
- IBM, Einordnung von IT Service Management: https://www.ibm.com/think/topics/it-service-management
