Streiche alte Services erst nach Owner-Freigabe. So schützt Du den Servicekatalog vor falschen Lücken

Ein alter Service im Katalog stört auf den ersten Blick vor allem die Übersicht. Er wirkt wie Ballast, macht Suchergebnisse länger und lässt das Angebot ungepflegt aussehen. Trotzdem ist schnelles Löschen riskant. In vielen Organisationen hängt an einem Katalogeintrag mehr als nur ein Name: Bestellwege, Supportgruppen, Kostenstellen, Providerkontakte, Wissensartikel und alte Tickets können darauf verweisen.

Für ITSM-Generalisten ist deshalb die zentrale Frage nicht: Kann dieser Eintrag weg? Die bessere Frage lautet: Wer bestätigt, dass der Service fachlich, betrieblich und kommunikativ wirklich beendet ist? Erst diese Freigabe schützt den Servicekatalog vor falschen Lücken.

Warum Löschen nicht dasselbe ist wie Ausmustern

Ein Servicekatalog beschreibt, welche IT-Leistungen für Nutzer, Fachbereiche oder interne Teams verfügbar sind. Er hilft dabei, Anfragen sauber zu stellen, Leistungen zu erklären und Zuständigkeiten sichtbar zu machen. Atlassian beschreibt Servicekataloge als zentrale Oberfläche für verfügbare Services und Anfragen. IBM ordnet IT Service Management allgemein als Steuerung von IT-Services über ihren Lebenszyklus ein. Genau deshalb darf ein Katalogeintrag nicht isoliert betrachtet werden.

Löschen ist eine technische Aktion. Ausmustern ist ein Prozess. Beim Löschen verschwindet ein Datensatz. Beim Ausmustern wird geklärt, ob der Service ersetzt, umbenannt, zusammengelegt, abgeschaltet oder nur aus dem Nutzerportal entfernt wird. Dieser Unterschied entscheidet, ob der Service Desk später noch erklären kann, warum eine Leistung nicht mehr sichtbar ist.

Der Service Owner muss die fachliche Wahrheit bestätigen

Der Service Owner ist die Person oder Rolle, die fachlich für einen Service verantwortlich bleibt. Sie muss wissen, ob der Service noch genutzt wird, ob ein Nachfolgeangebot existiert und welche Kommunikation nötig ist. Ohne diese Freigabe wird der Katalog schnell zur Schönheitsreparatur: Ein Eintrag verschwindet, aber die echte Nutzung bleibt im Hintergrund bestehen.

Praktisch reicht oft ein schlanker Freigabecheck. Der Owner bestätigt den gewünschten Zielzustand, etwa beendet, ersetzt durch neuen Service, nur intern sichtbar oder vorübergehend gesperrt. Zusätzlich nennt er das Datum, ab dem Nutzer nicht mehr bestellen oder anfragen sollen. Diese Bestätigung gehört nicht in einen Chat, sondern in ein Ticket oder einen nachvollziehbaren Änderungsdatensatz.

Ein Nutzungscheck verhindert falsche Lücken

Bevor ein Service aus dem sichtbaren Katalog verschwindet, sollte der Betrieb drei einfache Spuren prüfen. Erstens: Gibt es offene Tickets, Bestellungen oder wiederkehrende Anfragen zu diesem Service? Zweitens: Verweisen Wissensartikel, Formulare oder Automationen noch auf den Eintrag? Drittens: Gibt es aktive Kosten, Providerleistungen oder technische Komponenten, die im Namen dieses Services laufen?

Diese Prüfung muss nicht schwerfällig sein. Eine kurze Liste im Änderungsticket reicht oft aus. Wichtig ist, dass die Entscheidung nicht nur auf Bauchgefühl basiert. Ein Service, der seit Monaten nicht bestellt wurde, kann trotzdem in einem Incident, einer Vertragsanlage oder einer internen Supportbeschreibung gebraucht werden.

Umbenennen braucht andere Regeln als Abschalten

Viele Katalogbereinigungen scheitern daran, dass verschiedene Fälle gleich behandelt werden. Ein Service kann fachlich beendet sein. Er kann aber auch nur einen neuen Namen bekommen, in ein Paket wandern oder von einem Provider zu einem anderen wechseln. Für Nutzer sieht das Ergebnis ähnlich aus, für den Betrieb ist es etwas völlig anderes.

Bei einer Umbenennung sollte der alte Begriff eine Übergangszeit sichtbar bleiben oder sauber weiterleiten. Bei einer Zusammenlegung braucht der Service Desk eine Erklärung, welcher alte Wunsch künftig wo landet. Bei einer echten Abschaltung braucht es eine Kommunikation an betroffene Nutzergruppen. Wird alles einfach gelöscht, entstehen Nachfragen genau dort, wo der Katalog eigentlich Klarheit schaffen sollte.

So sieht eine sichere Ausmusterungsregel aus

Eine praxistaugliche Regel besteht aus fünf Pflichtfeldern: betroffener Service, gewünschter Zielzustand, bestätigender Owner, geprüfte Abhängigkeiten und Kommunikationshinweis. Dazu kommt ein Datum, ab dem die Änderung gelten soll. Erst wenn diese Punkte vollständig sind, wird der Eintrag entfernt, umbenannt oder auf eine Nachfolgeleistung verwiesen.

Für kleine IT-Organisationen reicht dafür ein normales Change- oder Katalogticket. Größere Organisationen können daraus einen Standardablauf im ITSM-Tool machen. Entscheidend ist nicht die Größe des Formulars, sondern die Nachweislinie: Wer hat bestätigt, was geprüft wurde und wie Nutzer künftig zur richtigen Leistung kommen?

Der schnelle Test für Deinen Katalog

Nimm einen alten Serviceeintrag, der aus dem Portal verschwinden soll, und stelle vier Fragen: Wer ist Owner? Gibt es noch Tickets oder Anfragen? Gibt es eine Nachfolge oder Umbenennung? Weiß der Service Desk, was er Nutzern sagen soll? Wenn eine Antwort fehlt, ist der Eintrag noch nicht bereit zum Streichen.

Ein schlanker Servicekatalog ist wertvoll. Aber er wird nur dann besser, wenn Bereinigung nicht zur unsichtbaren Abschaltung wird. Alte Services dürfen verschwinden, sobald Owner-Freigabe, Abhängigkeitscheck und Nutzerhinweis zusammenpassen. Dann entsteht weniger Ballast, ohne dass der Betrieb versehentlich Orientierung entfernt.

Quellen und Stand: Quellenprüfung am 26.07.2026. Einordnung zu Servicekatalogen nach Atlassian Service Catalog, zu IT Service Management nach IBM IT Service Management und zur Service-Catalogue-Perspektive nach AXELOS Service Catalogue Management.

Bildquelle: Pexels / Foto-ID 4792285 / https://www.pexels.com/photo/4792285/ / C00 Lizenz