CSDM verstehen:
Das gemeinsame Datenmodell als Fundament Ihrer Plattform

ServiceNow-Kunden, die verschiedene Module betreiben – ITSM, HRSD, ITOM, CSM – stoßen früher oder später auf ein gemeinsames Problem: Die Daten in den verschiedenen Modulen sprechen unterschiedliche Sprachen. Ein „Service" in ITSM ist nicht dasselbe wie ein „Service" in ITOM. Eine „Application" im Incident-Formular hat nichts mit einer „Application Service" in der CMDB gemein.

Genau hier setzt das Common Service Data Model (CSDM) an: Es ist ein von ServiceNow empfohlenes Framework, das eine einheitliche Terminologie und Datenstruktur für alle Module der Now Platform definiert.

Was ist das CSDM?

Das CSDM ist kein neues Modul und auch kein Tool. Es ist ein Datenmodell – genauer gesagt eine Empfehlung, wie bestimmte Tabellen und Beziehungen in ServiceNow zu befüllen und zu nutzen sind. Es definiert vier Hauptdomänen:

• Sell/Consume: Business Capabilities, Service Offerings, Service Commitments
• Design: Business Applications, Application Services
• Build/Test: Software Products, Software Instances
• Manage/Operate: Technical Services, Infrastructure

Im Kern geht es darum, dass ein „Service" von der Business-Perspektive (Was bieten wir an?) bis zur technischen Ebene (Welche Server stehen dahinter?) durchgängig beschrieben und verknüpft ist.

Warum ist das CSDM so wichtig?

Ohne CSDM können Sie ServiceNow zwar nutzen – aber nur eingeschränkt. Mit CSDM wird ServiceNow zur strategischen Plattform. Einige konkrete Beispiele:

1. Impact Analysis: Bei einem Incident auf einem Server sofort sehen, welche Business Services betroffen sind
2. Service Health: Den Gesundheitsstatus eines Business Service von der technischen Infrastruktur bis zum SLA sehen
3. Change Risk: Beim Change-Request automatisch berechnen, welche Services betroffen und wie kritisch sie sind
4. Cost Transparency: IT-Kosten auf Business Services umlegen und transparent machen

Die vier CSDM-Reifegrade

ServiceNow empfiehlt eine schrittweise Einführung in vier Reifegraden – von der einfachen Basiskonfiguration bis zur vollständigen Service-Modellierung:

„CSDM ist kein Big-Bang-Projekt. Wer versucht, alles auf einmal umzusetzen, scheitert an der Komplexität. Starten Sie klein – aber starten Sie richtig."

• Stufe 1 – Crawl: Technische CIs und einfache Service-Verknüpfungen
• Stufe 2 – Walk: Application Services, Business Application Mapping
• Stufe 3 – Run: Vollständige Service-Hierarchie, SLA-Mapping
• Stufe 4 – Fly: Automatisierte Service-Gesundheit, AI-gestützte Insights

Wie starten wir ein CSDM-Projekt?

Ein CSDM-Projekt beginnt nicht mit Technik – es beginnt mit Workshops. Die entscheidenden Fragen zu Beginn:

• Welche Business Services bietet die IT tatsächlich an?
• Wer ist der Business Owner eines Service?
• Wie ist der Service technisch realisiert (Anwendungen, Server)?
• Welche Informationen sind bereits in der CMDB vorhanden?

Erst wenn diese Fragen beantwortet sind, beginnt die technische Umsetzung: Mapping-Workshops, CI-Klassen-Design, Discovery-Regeln und Integrations-Konfiguration. In der Regel dauert ein CSDM-Projekt auf Stufe 2 vier bis acht Wochen.

Häufige Stolpersteine

Aus unserer Projekterfahrung sind dies die typischen CSDM-Probleme:

1. Fehlende Business-Sponsorship: CSDM braucht die Unterstützung des CIO, nicht nur der IT
2. Unklare Service-Definitionen: „Was ist ein Service?" ist keine triviale Frage
3. Schlechte CMDB-Basis: CSDM funktioniert nicht auf wackligem Fundament
4. Kein Governance-Prozess: Ohne klare Regeln für Updates veraltet das Modell schnell