CSDM pragmatisch einführen: in vier Schritten statt vier Jahren

Kaum ein ServiceNow-Thema löst so viel Ehrfurcht aus wie das Common Service Data Model. Das große Diagramm mit seinen Domänen und Tabellen hängt inzwischen in jedem Architektur-Workshop, und regelmäßig sitzt mir danach jemand gegenüber und fragt leise: Müssen wir das wirklich alles machen?

Nein. Und das sagt auch ServiceNow selbst, es hören nur viele nicht hin.

Was CSDM ist und was nicht

CSDM ist die Antwort auf eine reale Schmerzerfahrung: In gewachsenen Instanzen modelliert jede Abteilung Services und Anwendungen anders, Reports widersprechen sich, und Module wie Service Mapping oder APM finden nicht die Datenstrukturen vor, die sie erwarten. Das Modell definiert, welche Tabellen wofür gedacht sind und wie sie zusammenhängen, damit alle Produkte der Plattform auf denselben Grundlagen arbeiten.

Entscheidend ist aber, als was CSDM gedacht ist: als Reifegradmodell mit aufeinander aufbauenden Stufen, Crawl, Walk, Run, Fly. Niemand erwartet, dass eine Organisation von null auf die volle Ausbaustufe springt. Trotzdem sehe ich Projekte, die im ersten Anlauf Business Capabilities, Service Offerings und Application Services gleichzeitig modellieren wollen. Das endet zuverlässig in monatelangen Modellierungsdebatten, in denen sehr kluge Menschen sehr lange über die Frage streiten, ob etwas ein Business Service oder ein Technical Service ist, während draußen niemand einen Nutzen sieht.

Schritt 1: Die Grundlagen geradeziehen

Der Einstieg ist unspektakulär. Anwendungen sauber in der Business-Application-Tabelle erfassen, mit Besitzer und Lebenszyklus-Status. Technische CIs aus der Discovery darunter, korrekt klassifiziert. Klare Verantwortlichkeiten, wer welche Daten pflegt. Das ist im Kern die Crawl-Stufe, und sie ist für viele Anwendungsfälle bereits die halbe Miete: ein verlässliches Anwendungsinventar mit technischem Unterbau.

Wichtig in dieser Phase ist Disziplin bei dem, was man nicht tut. Keine vorauseilende Modellierung von Strukturen, für die es noch keinen Abnehmer gibt. Jede Tabelle, die befüllt wird, will gepflegt werden, und ungenutzte Daten veralten zuverlässig.

Schritt 2: Genau einen Use Case wählen

Die nächste Ausbaustufe wird nicht vom Modell diktiert, sondern von einem konkreten Bedarf. Meistens ist es die Impact-Analyse: Der Change Manager will vor der Freigabe sehen, welche Anwendungen und Services an einem Server hängen. Der Incident Manager will beim Major Incident wissen, was betroffen ist.

Für diesen Use Case braucht es Application Services mit echten Abhängigkeiten, also Service Mapping für die kritischen Services oder, durchaus legitim für den Anfang, manuell gepflegte Service-Strukturen für die zwanzig wichtigsten Anwendungen. Nicht für alle. Für die zwanzig, bei denen ein Ausfall wirklich weh tut.

Schritt 3: Liefern und vorzeigen

Jetzt entsteht der Moment, der über das ganze Vorhaben entscheidet: Der Change Manager sieht vor der Freigabe zum ersten Mal eine belastbare Liste betroffener Services. Aus Raten wird Wissen. Diese Erfahrung, konkret und im Alltag erlebt, ist das beste Argument für jede weitere Ausbaustufe und überzeugender als jede Architektur-Präsentation.

Diesen Erfolg sollte man bewusst sichtbar machen. Kurz dokumentieren, in den relevanten Runden zeigen, die beteiligten Teams nennen. So entsteht Nachfrage statt Überzeugungsarbeit.

Schritt 4: Am Bedarf entlang weiterklettern

Erst jetzt, mit funktionierendem Fundament und sichtbarem Nutzen, stellt sich die Frage nach Walk und Run: Service Offerings für differenzierte SLAs, Business Capabilities für das Portfolio-Management, Verknüpfung mit APM. Und die Antwort hängt jeweils daran, ob jemand die nächste Stufe wirklich braucht, also ob es einen Abnehmer mit einer konkreten Frage gibt. Gibt es ihn nicht, ist Stehenbleiben kein Versagen, sondern Kostenbewusstsein.

Das Modell ist gut, die Lesart entscheidet

Nichts davon spricht gegen CSDM. Das Modell ist durchdacht, es beschreibt, wohin die Reise gehen kann, in welcher Reihenfolge und mit welchen Tabellen, und wer es ignoriert, baut sich mittelfristig genau das Datenchaos, das es verhindern soll. Nur die Lesart muss stimmen: CSDM ist eine Landkarte, kein Marschbefehl. Man muss nicht jeden Ort auf der Karte besuchen. Man muss nur wissen, wo man ist, wohin man als Nächstes will und warum.

Die Projekte, die so vorgehen, haben nach einem Jahr eine gepflegte Grundlage und zwei, drei echte Use Cases in Produktion. Die anderen haben nach einem Jahr ein beeindruckendes Modellierungsdokument. Ich weiß, was ich lieber im Audit vorfinde.