CSDM ist kein Datenmodellprojekt. Es ist die Startbedingung für KI
Kaum ein Thema wurde in ServiceNow Projekten so zuverlässig vertagt wie das Common Service Data Model. Der Grund war nachvollziehbar. CSDM sah aus wie ein Modellierungsvorhaben ohne sichtbares Ergebnis: viele Workshops, viele Tabellen, am Ende funktioniert der Servicedesk genauso wie vorher. Der Nutzen lag in der Zukunft, der Aufwand in der Gegenwart.
Diese Rechnung stimmt nicht mehr. Nicht, weil das Modell besser geworden wäre, sondern weil sich geändert hat, wer die Daten liest.
Menschen gleichen Lücken aus, Agenten nicht
Ein erfahrener Servicedesk Mitarbeiter braucht keine saubere CMDB. Er weiß, dass die Anwendung im Ticket unter drei verschiedenen Namen geführt wird, dass der Eintrag seit dem letzten Rechenzentrumsumzug falsch ist und wen man bei diesem System tatsächlich anruft. Dieses Wissen steht nirgends. Es gleicht seit Jahren still aus, was im Modell fehlt.
Ein KI Agent verfügt nicht über dieses Wissen. Er liest, was da ist. Ist der Service nicht mit der Anwendung verbunden, findet er den Zusammenhang nicht. Ist der Eigentümer nicht hinterlegt, eskaliert er ins Leere. Ist der Lebenszyklus eines Konfigurationselements nicht gepflegt, behandelt er ein abgeschaltetes System wie ein produktives.
Damit wird aus einer Datenqualitätsfrage eine Funktionsfrage. Die Lücke im Modell ist nicht mehr unangenehm, sondern begrenzend.
Was ein Agent aus dem Modell tatsächlich braucht
Der Reflex, daraufhin ein vollständiges CSDM aufzubauen, führt zurück in dieselbe Vertagungsschleife. Sinnvoller ist die umgekehrte Reihenfolge: von den geplanten Anwendungsfällen auf das benötigte Modell schließen.
Ein Agent, der Störungen automatisch der richtigen Gruppe zuordnen soll, braucht die Verbindung von Konfigurationselement zu Anwendungsservice und von dort zur verantwortlichen Gruppe. Er braucht nicht das vollständige Portfolio aller Geschäftsfähigkeiten.
Ein Agent, der Änderungsrisiken bewerten soll, braucht belastbare Abhängigkeiten zwischen Services und die Kritikalität der betroffenen Systeme. Er braucht keine durchmodellierten Vertragsbeziehungen.
Ein Agent, der Wissen bereitstellt, braucht gepflegte Artikel mit klarem Servicebezug und einem Gültigkeitsstatus. Er braucht keine Discovery über die gesamte Infrastruktur.
Aus dieser Perspektive wird CSDM planbar. Nicht als Programm über achtzehn Monate, sondern als Abfolge kleiner, überprüfbarer Ausbaustufen, die jeweils einen konkreten Anwendungsfall freischalten.
Der Preis des Wartens hat sich verändert
Früher kostete ein dünnes Modell vor allem Berichtsqualität. Kennzahlen waren ungenau, Servicekosten schwer zuzuordnen, das Portfolio unscharf. Das war ärgerlich und selten dringend.
Heute kostet ein dünnes Modell Automatisierungsgrad. Jeder Anwendungsfall, der an fehlenden Beziehungen scheitert, bleibt manuell. Und da KI Fähigkeiten inzwischen fest in den Lizenzstufen liegen, zahlt das Unternehmen dafür unabhängig davon, ob es sie nutzen kann.
Dazu kommt die regulatorische Seite. Nachvollziehbarkeit setzt voraus, dass sich eine automatisierte Entscheidung auf einen definierten Service, ein definiertes System und eine verantwortliche Stelle zurückführen lässt. Genau diese Zuordnung leistet das Modell. Ohne sie ist der Nachweis eine Rekonstruktion aus Logdateien.
Ein pragmatischer Einstieg
Drei Schritte reichen, um aus der Vertagung herauszukommen.
Bestand aufnehmen, nicht bewerten. Welche Ebenen des Modells sind heute wirklich gefüllt, welche existieren nur als leere Tabelle? Diese Aufnahme dauert Tage, nicht Wochen, und beendet die meisten Grundsatzdiskussionen.
Zwei Anwendungsfälle auswählen. Einen mit hohem Volumen und einen mit hohem Risiko. Daraus ergibt sich, welcher Ausschnitt des Modells zuerst gebraucht wird.
Pflege dauerhaft verankern. Ein Modell, das im Projekt aufgebaut und danach nicht gepflegt wird, ist nach zwei Releases wieder ungenau. Zuständigkeit, Discovery und Lebenszyklusregeln gehören zum Betrieb, nicht zur Einführung.
CSDM war lange ein Thema für Architekten. Es ist inzwischen ein Thema für alle, die von ihrer ServiceNow Plattform Automatisierung erwarten. Der Unterschied zwischen einem funktionierenden Agenten und einem enttäuschenden liegt selten im Modell der KI. Er liegt in dem, was sie vorfindet.
