Ein Servicekatalog ist keine Liste von Anwendungen

Viele Servicekataloge beginnen mit einer Liste: ERP, Microsoft 365, VPN, Telefonie, Drucker, Netzwerk. Die Liste ist technisch nicht falsch. Sie hilft einem Mitarbeiter jedoch kaum bei der Frage, welche Leistung er anfordern kann, welche Angaben nötig sind, wer entscheiden darf und was er anschließend erwarten kann.

Eine Anwendung ist zunächst ein Mittel. Ein Service beschreibt dagegen ein für den Nutzer verständliches Ergebnis. Das GOV.UK Service Manual fasst einen Service als etwas, das Menschen dabei hilft, ein Ziel zu erreichen. Dazu gehören nicht nur Technik, sondern auch die beteiligten Prozesse, Daten, Menschen und Unterstützungswege.

Für einen mittelständischen Servicekatalog folgt daraus eine einfache Leitlinie: Nicht das eingesetzte Produkt ist der Ausgangspunkt, sondern die Leistung, die jemand benötigt.

Drei Listen, die nicht verwechselt werden sollten

In der Praxis werden unterschiedliche Verzeichnisse häufig unter demselben Begriff geführt:

Verzeichnis	Beantwortet vor allem	Typischer Inhalt
Technisches Inventar	Was betreiben oder besitzen wir?	Anwendungen, Geräte, Versionen, Verträge
Servicekatalog	Welche verlässlichen Leistungen bietet die IT für wen an?	Ergebnis, Zielgruppe, Owner, Leistungsgrenze und Erwartung
Bestell- oder Request-Katalog	Was kann ein Nutzer konkret anfordern?	Formular, Eingaben, Freigabeweg, Bearbeitungsziel

Diese Sichten dürfen technisch miteinander verbunden sein. Sie sind aber nicht austauschbar. Das Inventar kann zeigen, dass Microsoft 365 vorhanden ist. Der Servicekatalog beschreibt beispielsweise „digitale Zusammenarbeit bereitstellen“. Der Request-Katalog enthält konkrete Anforderungen wie „Projektteam mit externen Beteiligten anlegen“ oder „Zugriff auf einen Arbeitsbereich beantragen“.

Auch ein Produktname kann ausnahmsweise eine verständliche Leistung bezeichnen. Wenn alle Beteiligten unter „ERP-Zugang“ dasselbe Ergebnis verstehen, muss der Katalog keine künstliche Geschäftssprache erfinden. Entscheidend ist, dass der Eintrag die folgenden Fragen zuverlässig beantwortet.

Was ein Nutzer vor der Anfrage wissen muss

Ein schlanker Katalogeintrag braucht keine lange Leistungsbeschreibung. Er sollte aber so vollständig sein, dass Nachfrage nicht erst durch Rückfragen geklärt wird:

• Ergebnis: Was ist nach erfolgreicher Erbringung möglich?
• Zielgruppe: Wer darf oder soll die Leistung nutzen?
• Voraussetzungen: Welche Rolle, Ausstattung, Freigabe oder Vorleistung ist nötig?
• Bestellweg: Wo wird angefragt, und welche Informationen müssen mitgeliefert werden?
• Entscheidungsweg: Wer genehmigt, falls eine Freigabe erforderlich ist?
• Verantwortung: Wer verantwortet das Leistungsversprechen und wer erbringt die Leistung?
• Erwartung: Wann erfolgt eine Reaktion oder Bereitstellung, und zu welchen Servicezeiten?
• Leistungsgrenze: Was ist ausdrücklich nicht enthalten?
• Kostenwirkung: Entstehen zuordenbare Lizenz-, Beschaffungs- oder Dienstleisterkosten?
• Lebenszyklus: Wie werden Änderung, regelmäßige Prüfung und Beendigung ausgelöst?

Nicht jede Leistung benötigt in jedem Feld einen langen Text. „Keine zusätzliche Freigabe“ und „keine Einzelverrechnung“ sind ebenfalls hilfreiche Aussagen. Ein leeres Feld zwingt Nutzer und Service-Team dagegen dazu, die Regel bei jeder Anfrage neu auszuhandeln.

Der Service-Steckbrief

Für den Einstieg reicht ein einheitlicher Steckbrief. Die folgende Struktur ist eine KinOps-Empfehlung, keine verbindliche Vorgabe aus ISO/IEC 20000:

Feld	Leitfrage
Servicename	Welche Formulierung versteht die Zielgruppe ohne Produktwissen?
Nutzenversprechen	Welches Ergebnis liefert der Service?
Zielgruppe und Berechtigung	Für wen ist er vorgesehen, und wer darf ihn auslösen?
Leistung und Grenze	Was ist enthalten, was nicht?
Eingang und Pflichtangaben	Wo und mit welchen Angaben beginnt die Bearbeitung?
Freigabe	Welche Rolle entscheidet unter welchen Bedingungen?
Service Owner	Wer verantwortet Zuschnitt, Qualität und Weiterentwicklung?
Erbringung	Welches Team oder welcher Dienstleister liefert die Leistung?
Erwartungswerte	Welche Reaktions-, Bereitstellungs- oder Wiederherstellungsziele gelten?
Abhängigkeiten und Kosten	Welche Vorleistungen, Lizenzen oder Verträge sind wesentlich?
Beendigung und Review	Wie wird die Leistung entzogen, beendet oder überprüft?

Die Felder machen zugleich Lücken sichtbar. Wenn niemand den Service verantwortet, ist das kein redaktionelles Problem des Katalogs. Es ist eine ungeklärte Organisationsentscheidung. Wenn der Freigabeweg fehlt, sollte das Team ihn nicht durch ein besonders ausführliches Formular ersetzen.

Ein konstruiertes Beispiel: vom Produkt zur Leistung

Das folgende Beispiel ist konstruiert.

Ein bestehender Katalog nennt „ERP“, „Microsoft 365“, „VPN“ und „Drucker“. Für das Onboarding einer neuen Kollegin entsteht daraus eine Kette von Einzelanfragen. Die Führungskraft weiß nicht, welche Zugänge zur Rolle gehören, HR kennt den technischen Bestellweg nicht und die IT muss nach Arbeitsbeginn fehlende Angaben einsammeln.

Der neue Katalog beginnt nicht mit den vier Produkten, sondern mit der Leistung „Mitarbeitende arbeitsfähig bereitstellen“. Der Eintrag benennt:

• den gewünschten Starttermin und die benötigte Vorlaufzeit,
• die freigebende Führungskraft,
• die von HR bestätigte Rolle und Organisationseinheit,
• ein definiertes Ausstattungspaket,
• daraus abgeleitete Standardzugänge,
• Abweichungen, die separat entschieden werden müssen,
• den verantwortlichen Service Owner,
• und den Auslöser für den Entzug beim Austritt.

ERP, Microsoft 365 und gegebenenfalls VPN bleiben als Anwendungen und Abhängigkeiten dokumentiert. Für den Nutzer stehen sie aber nicht mehr unverbunden nebeneinander. Der Katalog verbindet sie zu einem Ergebnis und macht deutlich, welche Sonderwünsche außerhalb des Standards liegen.

Das Beispiel behauptet keinen realen Kundenfall oder gemessenen Effekt. Es zeigt, welche organisatorische Information eine bloße Produktliste nicht liefert.

Nicht mit dem Formular beginnen

Ein häufiger Fehler ist, den Servicekatalog unmittelbar im Ticketsystem aufzubauen. Dann bestimmt die Formularfunktion des Werkzeugs, wie die Leistung geschnitten wird. Das Ergebnis sind viele Kategorien und Pflichtfelder, aber weiterhin unklare Zusagen.

Der Beitrag über Ticketsysteme zeigt dieselbe Grenze: Ein zentraler Eingang macht Arbeit sichtbar, löst aber keine ungeklärten Prioritäten, Rollen oder Entscheidungsrechte. Für den Katalog sollte deshalb zuerst der Service-Steckbrief fachlich geklärt werden. Danach wird entschieden, welche Angaben in ein Formular gehören und welche Informationen nur für das Service-Team sichtbar sein müssen.

Das schützt auch vor überladenen Anfragen. Der Nutzer muss nicht jede technische Abhängigkeit kennen. Er liefert die Informationen, die für Bedarf, Berechtigung und Termin notwendig sind. Die IT leitet daraus technische Arbeitsschritte und Configuration Items ab.

Mit echter Nachfrage beginnen

Ein vollständiger Unternehmenskatalog als Startprojekt ist selten nötig. Sinnvoller ist eine begrenzte erste Fassung aus Leistungen, bei denen heute besonders viele Rückfragen, Wartezeiten oder Missverständnisse entstehen.

Ein praktikables Vorgehen besteht aus sechs Schritten:

1. Nachfrage sichten: Tickets, E-Mails und Zurufe aus einem begrenzten Zeitraum nach wiederkehrenden gewünschten Ergebnissen gruppieren.
2. Leistungen formulieren: Produktnamen in eine für die Zielgruppe verständliche Leistung übersetzen, ohne unklare Marketingbegriffe zu verwenden.
3. Owner und Grenze klären: Für jede Leistung Verantwortung, Standardumfang und bewusste Ausschlüsse festlegen.
4. Bestell- und Entscheidungsweg ergänzen: Pflichtangaben, Berechtigung und Freigabe definieren.
5. Mit Nutzern prüfen: Kann eine Person aus der Zielgruppe den richtigen Eintrag finden und eine vollständige Anfrage stellen?
6. Im Betrieb lernen: Rückfragen, Fehlleitungen, Wartezeiten und nicht genutzte Einträge prüfen und den Zuschnitt anpassen.

Die ersten Einträge sollten nicht danach ausgewählt werden, welche Services technisch am interessantesten sind. Vorrang haben Leistungen mit häufiger Nachfrage, hoher Geschäftswirkung oder wiederkehrender Unklarheit. Der pragmatische ITSM-Einstieg folgt demselben Grundsatz: erst Transparenz und eine belastbare Grundmechanik schaffen, dann den Umfang erweitern.

Service Owner ist nicht gleich Bearbeiter

Der Service Owner verantwortet nicht zwingend jede einzelne Erbringung. Er sorgt dafür, dass Zielgruppe, Leistung, Qualitätsversprechen, Kostenwirkung und Weiterentwicklung zusammenpassen. Die operative Arbeit kann bei internen Teams, Fachverantwortlichen oder Dienstleistern liegen.

Diese Trennung ist besonders wichtig, wenn mehrere Beteiligte einen Service liefern. Für „sicher extern arbeiten“ können Client-Management, Identitätsverwaltung, Netzwerk, Informationssicherheit und ein externer Provider zusammenwirken. Der Nutzer braucht trotzdem einen verständlichen Service und einen belastbaren Verantwortungsweg.

Die Anforderungen der ISO/IEC 20000-1:2018 ordnen Services in ein Managementsystem aus Planung, Gestaltung, Übergang, Erbringung, Überwachung und Verbesserung ein. Der Servicekatalog ist deshalb kein isoliertes Inhaltsprojekt. Auch der Service-Management-Standard des britischen Department for Education behandelt Catalogue Management gemeinsam mit Verantwortungen, Support, Messung und Verbesserung. Diese Quellen schreiben dem Mittelstand keinen konkreten Steckbrief vor; sie stützen aber die Einordnung, dass ein Katalog in die Steuerung der Leistung eingebettet sein muss.

Katalog und CMDB brauchen unterschiedliche Blickrichtungen

Ein Katalog blickt aus Sicht der Nachfrage auf die Leistung. Eine CMDB blickt auf die für Betrieb und Entscheidungen relevanten Configuration Items und Beziehungen. Der Service ist die sinnvolle Verbindung beider Sichten.

Beim Service „Warenwirtschaft verfügbar“ beschreibt der Katalog Zielgruppe, Leistungsversprechen, Supportweg und Erwartungen. Die CMDB kann zeigen, von welchen Anwendungen, Datenbanken, Plattformen, Identitäts- und Netzwerkdiensten dieses Versprechen abhängt. Der Beitrag „Eine CMDB beginnt nicht mit Daten, sondern mit Entscheidungen“ vertieft diese technische und organisatorische Beziehungssicht.

Beide Modelle sollten einander nicht ungeprüft duplizieren. Der Katalog muss keine Hostnamen enthalten. Die CMDB muss nicht den vollständigen Bestelltext speichern. Gemeinsame Identifikatoren und klare Verantwortungen genügen, um beide Sichten verlässlich zu verbinden.

Wirkung messen, nicht Seitenaufrufe sammeln

Die bloße Zahl veröffentlichter Services sagt wenig über die Qualität des Katalogs. Auch viele Seitenaufrufe können bedeuten, dass Nutzer lange suchen und trotzdem nicht weiterkommen.

Nützlichere Prüffragen sind:

• Werden Anfragen häufiger beim richtigen Service und Team eingeordnet?
• Geht der Anteil unvollständiger Anfragen und notwendiger Rückfragen zurück?
• Sind Freigabe- und Berechtigungswege für Nutzer und Bearbeiter eindeutig?
• Können Erwartungen und Abweichungen nachvollziehbar erklärt werden?
• Werden ungenutzte oder nicht mehr verantwortete Leistungen erkannt und bereinigt?
• Lassen sich Lizenz- und Dienstleisterkosten den verantworteten Leistungen zuordnen?

Der letzte Punkt verbindet den Katalog mit der wirtschaftlichen Steuerung. IT-Kosten werden erst steuerbar, wenn Kostenarten mit Leistungen, Mengen und Verantwortung verbunden werden. Eine Produktrechnung ohne Servicebezug zeigt Ausgaben. Ein Servicekatalog kann zusätzlich erklären, wofür sie anfallen.

Der kleinste sinnvolle nächste Schritt

Wählen Sie eine häufig angefragte Leistung, die heute Rückfragen oder Zuständigkeitsprobleme erzeugt. Schreiben Sie den Service-Steckbrief zunächst außerhalb des Werkzeugs. Lassen Sie eine Person aus der Zielgruppe erklären, was sie bestellen kann, welche Voraussetzungen gelten und was sie erwarten darf.

Wenn diese Fragen nicht eindeutig beantwortet werden können, fehlt keine weitere Katalogsoftware. Es fehlt eine Leistungsentscheidung. Erst nachdem sie getroffen ist, lohnt sich die Abbildung im Portal oder Ticketsystem.

Ein guter Servicekatalog ist deshalb keine schönere Inventarliste. Er ist die sichtbare Vereinbarung darüber, welche Ergebnisse die IT für wen, unter welchen Bedingungen und mit welcher Verantwortung liefert.