CSDM ist kein Datenmodell — es ist die Business-Diskussion, die niemand führen will
Das wichtigste Framework, das niemand zu Ende bringt
Öffnen Sie eine beliebige ServiceNow-Instanz, die seit mehr als zwei Jahren produktiv ist.
Gehen Sie zur Business-Service-Tabelle. Zählen Sie, wie viele Einträge tatsächlich mit Application Services verknüpft sind. Prüfen Sie dann, wie viele dieser Application Services auf CIs gemappt sind.
Ich warte.
In den meisten Unternehmen ist es ein Friedhof. Halb befüllte Tabellen. Verwaiste Datensätze. Services, die nur dem Namen nach existieren — kein Mapping, kein Owner, keine Beziehung zu dem, was das Business tatsächlich nutzt.
Das ist kein Dateneingabeproblem.
Das ist das Common Service Data Model — CSDM — und es ist das wichtigste Framework im gesamten ServiceNow-Ökosystem.
Es ist gleichzeitig das am schlechtesten umgesetzte.
Nicht weil es technisch komplex wäre. Das Schema ist gut dokumentiert. ServiceNow hat klare Anleitungen veröffentlicht. Es gibt Accelerator, Referenzarchitekturen und ein eigenes CSDM Health Dashboard.
Die Werkzeuge sind nicht das Problem.
Die Diskussion ist das Problem.
Denn eine saubere CSDM-Implementierung erfordert, dass IT-Leadership, Business-Leadership und Finance sich in einen Raum setzen und sich auf etwas trügerisch Einfaches einigen:
Was ist ein Service?
Diese Diskussion ist politisch unbequem. Organisatorisch chaotisch. Karrieretechnisch riskant.
Also überspringen die meisten Teams sie.
Und wundern sich dann, warum die Change-Risikobewertung sich wie Raten anfühlt. Warum Kostentransparenz nie Realität wird. Warum Now Assist unbrauchbare Zusammenfassungen liefert, die auf unbrauchbaren Daten basieren.
Warum CSDM stagniert — und es liegt nicht an der Komplexität
Das Service-Definitions-Problem
Fragen Sie fünf Personen in Ihrer Organisation, was „E-Mail-Service" bedeutet.
Das Business sagt: Outlook auf dem Laptop.
Das Infrastrukturteam sagt: der Exchange-Cluster.
Das Applikationsteam sagt: Microsoft 365.
Der Service Desk sagt: „E-Mail geht nicht."
Finance sagt: eine Position im Microsoft Enterprise Agreement.
Alle haben recht. Alle sind unvollständig. Und keiner hat sich je mit den anderen zusammengesetzt, um das abzugleichen.
CSDM verlangt von Ihnen, die Beziehung zu formalisieren zwischen dem, was das Business konsumiert (Business Services), den Applikationen, die diesen Konsum ermöglichen (Application Services), und der Infrastruktur, die diese Applikationen trägt (CIs).
Diese Formalisierung erfordert ein gemeinsames Vokabular.
Die meisten Organisationen haben keines.
Das Ownership-Problem
Jeder Service in CSDM braucht einen Owner.
Kein Team. Eine Person.
Eine namentlich benannte Person, die verantwortlich ist für die Service-Definition, die Mapping-Qualität und den laufenden Lifecycle.
An dieser Stelle wird es still im Raum.
Ownership bedeutet Verantwortlichkeit. Verantwortlichkeit bedeutet: Wenn die Service Map falsch ist — und das eine Change-Bewertung oder einen Major Incident beeinflusst — steht jemandes Name darauf.
Niemand meldet sich freiwillig dafür.
Also bleibt das Feld „Owner" leer. Oder es wird mit einem Gruppennamen befüllt. Oder einer Verteilerliste. Was dasselbe ist wie leer.
Das politische Problem
Hier kommt der Teil, den niemand laut ausspricht.
CSDM erzwingt bereichsübergreifende Abstimmung. Um Business Services auf Application Services auf Infrastruktur abzubilden, müssen Personen aus verschiedenen Bereichen des Organigramms sich auf gemeinsame Definitionen und gemeinsame Ownership-Modelle einigen.
Diese Einigung legt Dysfunktionen offen.
Sie bringt ans Licht, dass drei Teams überlappende Applikationsportfolios verwalten und niemand weiß, wem was gehört. Sie zeigt, dass der „Servicekatalog" keinerlei Ähnlichkeit hat mit dem, was das Business tatsächlich nutzt. Sie macht die Schatten-IT sichtbar, von der alle wissen, die aber niemand dokumentieren will.
CSDM schafft diese Probleme nicht.
Es macht sie unmöglich zu ignorieren.
Deshalb wird es aufgegeben. Nicht weil das Datenmodell schwierig ist. Sondern weil die organisatorische Ehrlichkeit schwierig ist.
Was halb eingeführtes CSDM Sie tatsächlich kostet
Überspringen Sie CSDM, und alles Nachgelagerte bricht. Langsam, leise, teuer.
Die Change-Risikobewertung wird zum Theater. Ohne Service Maps, die Changes mit Business Services verknüpfen, raten Change Advisory Boards beim Impact. Das ist kein Risiko-Management. Das ist ein Meeting.
Kostentransparenz bleibt eine Fantasie. Sie können IT-Kosten nicht auf Geschäftsergebnisse umlegen, wenn Sie IT-Services nicht auf Business Services abbilden können. Finance fragt immer wieder danach. Die IT sagt immer wieder „nächstes Quartal." Das geht jetzt seit vier Jahren so.
KI-Funktionen landen auf einem kaputten Fundament. Predictive Intelligence braucht strukturierte, konsistente Daten, um automatisch zu kategorisieren und zuzuweisen. Now Assist braucht saubere Beziehungen, um brauchbare Zusammenfassungen zu generieren. CSDM soll genau diese Struktur liefern. Ohne CSDM füttern Sie eine teure KI-Engine mit Datenmüll.
SPM kann Investitionen nicht mit Ergebnissen verknüpfen. Strategic Portfolio Management hängt davon ab, Demand, Projekte und Applikationen mit Business Services zu verbinden. Ohne CSDM ist Ihre Portfolio-Sicht eine zusammenhanglose Tabelle mit hübscherer Oberfläche.
Sie haben nicht ein Datenmodell übersprungen.
Sie haben das strukturelle Fundament übersprungen, auf dem jede fortgeschrittene ServiceNow-Fähigkeit aufbaut.
Der Phasenansatz, der tatsächlich funktioniert
Der größte CSDM-Fehler ist, es als Big-Bang-Datenmigrationsprojekt zu behandeln.
Das ist es nicht.
Es ist eine iterative Business-Alignment-Übung mit einer technischen Ausprägung in ServiceNow.
So gehen Sie es an, ohne den Verstand oder Ihre Glaubwürdigkeit zu verlieren.
Phase 1 — Ehrliches Scoping
Versuchen Sie nicht, 500 Services zu definieren.
Nehmen Sie 5–10.
Wählen Sie die Business Services, die am meisten zählen. Umsatzrelevant. Kundenorientiert. Regulatorisch kritisch. Die Services, bei denen ein Major Incident dazu führt, dass das Telefon des CEO klingelt.
Holen Sie die richtigen Personen in einen Raum. Business-Verantwortliche. Application Owner. Infrastructure Lead. Finance-Partner. Platform Owner.
Definieren Sie jeden Service. Einigen Sie sich auf den Namen. Einigen Sie sich darauf, was dazugehört. Einigen Sie sich darauf, was nicht dazugehört. Schreiben Sie es auf.
Das wird länger dauern, als Sie denken.
Das ist in Ordnung. Das ist der Punkt.
Phase 2 — Das Modell verankern
Für diese 5–10 Services bauen Sie den vertikalen Stack.
Business Service → Application Service → CIs.
Bilden Sie es in ServiceNow ab. Nutzen Sie den CSDM-Lifecycle und die Standardtabellen — erfinden Sie kein eigenes Schema.
Nutzen Sie Discovery und Service Mapping zur Validierung Ihrer Arbeit. Nicht als Ausgangspunkt. Discovery zeigt Ihnen, was existiert. Es sagt Ihnen nicht, was relevant ist. Das ist eine menschliche Entscheidung.
Wenn Ihre Discovery-Daten dem widersprechen, worauf sich der Raum geeinigt hat, untersuchen Sie es. Überschreiben Sie nicht einfach die menschliche Entscheidung mit automatisierten Daten. Der Business-Kontext wiegt schwerer als der Netzwerk-Scan.
Phase 3 — Operationalisieren vor dem Erweitern
Mappen Sie noch keine weiteren Services.
Beweisen Sie zuerst, dass diese 5–10 nützlich sind.
Binden Sie sie in die Change-Risikobewertung ein. Wenn ein Change auf ein CI abzielt, das mit einem kritischen Business Service verknüpft ist, sollte der Risiko-Score das automatisch widerspiegeln.
Routen Sie Incidents über die Service Map. Wenn ein Application Service beeinträchtigt ist, sollte das richtige Team auf Basis der CSDM-Beziehungen benachrichtigt werden, nicht auf Basis einer statischen Assignment Group.
Speisen Sie Kostendaten durch die Service-Hierarchie. Zeigen Sie Finance, was es kostet, diese 5–10 Services end-to-end zu betreiben.
Hier verdient sich CSDM seine Glaubwürdigkeit. Wenn ein VP sieht, dass sein Service abgebildet, bepreist und durch risikobewusstes Change Management geschützt ist, wird er zum Fürsprecher.
Sie brauchen Fürsprecher, um zu skalieren.
Phase 4 — Skalieren mit Governance, nicht mit Hoffnung
Jetzt erweitern. Aber nicht ohne Struktur.
Etablieren Sie einen Service-Taxonomie-Verantwortlichen. Eine Person (oder ein sehr kleines Team), verantwortlich für CSDM-Standards, Namenskonventionen und Datenqualität.
Implementieren Sie quartalsweise Service Reviews. Sind die Maps korrekt? Sind die Owner noch aktuell? Wurden neue Applikationen ohne Mapping hinzugefügt?
Veröffentlichen Sie die Service Maps. Machen Sie sie sichtbar. Wenn ein Service nicht in CSDM existiert, erhält er keinen Change-Risikoschutz, keine Kostenallokation und kein priorisiertes Incident-Routing.
Das schafft einen natürlichen Anreiz zur Teilnahme.
Governance ist keine Bürokratie. Sie ist das Immunsystem, das CSDM am Leben hält, nachdem das ursprüngliche Projektteam weitergezogen ist.
Der Leadership-Schritt, der den Unterschied macht
Alles oben Genannte ist nutzlos ohne eine Sache.
Eine Führungskraft auf Senior-Ebene, die die Diskussion erzwingt.
Nicht sponsert. Nicht delegiert. Nicht das Budget freigibt und in sechs Monaten wieder nachfragt.
Im Raum sitzt. Die schwierigen Fragen stellt. Leute für Antworten in die Pflicht nimmt.
„Wem gehört dieser Service?"
„Warum mappen diese zwei Teams dieselbe Applikation unterschiedlich?"
„Warum stimmt unser Servicekatalog nicht mit dem überein, was wir gerade definiert haben?"
CSDM Governance sollte ein fester Agendapunkt für die Direct Reports des CIO oder CTO sein. Kein Quartalsbericht. Ein monatlicher operativer Rhythmus.
Die Organisationen, die CSDM hinbekommen, sind nicht die mit den besten technischen Teams.
Es sind die, in denen jemand mit genügend Seniorität gesagt hat: „Wir werden uns darauf einigen, und ich verlasse diesen Raum nicht, bis wir es getan haben."
CSDM ist nicht optional.
Es ist das Rückgrat, das Ihre CMDB mit Ihrem Change-Prozess, Ihrem Kostenmodell und Ihrer KI-Strategie verbindet.
Aber es funktioniert nur, wenn Ihre Organisation aufhört, es als Datenprojekt zu behandeln, und anfängt, es als das zu behandeln, was es tatsächlich ist: eine Business-Alignment-Übung.
Das beginnt mit einem unbequemen Meeting.
Dann einem weiteren. Und noch einem.
Bis Sie etwas Echtes aufgebaut haben.
