„Wir haben Discovery eingeschaltet – jetzt ist die CMDB aktuell." Diesen Satz hören wir regelmäßig. Und er ist nur zur Hälfte richtig. Discovery erkennt zuverlässig, was im Netzwerk vorhanden ist. Aber eine CMDB ist mehr als eine Inventarliste. Sie ist das Fundament für Incident Management, Change-Risikoabschätzung und Service-Abhängigkeiten. Dafür reicht Discovery allein nicht aus.
Was Discovery kann – und was nicht
ServiceNow Discovery scannt das Netzwerk und erkennt automatisch Configuration Items (CIs): Server, Switches, Router, virtuelle Maschinen, Cloud-Ressourcen. Es aktualisiert Attribute wie IP-Adresse, Betriebssystem, installierte Software und Hardwarekonfiguration. Das ist wertvoll – und spart enorme manuelle Arbeit.
Was Discovery nicht kann:
- Business-Kontext liefern – wer ist verantwortlich, welchem Service gehört das CI?
- Beziehungen zwischen CIs vollständig modellieren, insbesondere auf Anwendungsebene
- CIs erkennen, die nicht netzwerkfähig sind (z.B. Verträge, Lizenzen, physische Assets ohne IP)
- Cloud-native Ressourcen ohne zusätzliche Service Graph Connectors vollständig abbilden
- Die CMDB-Governance sicherstellen – also entscheiden, welche CIs überhaupt relevant sind
Das eigentliche Problem: Zu viele CIs, zu wenig Kontext
Discovery neigt dazu, sehr viele CIs zu erstellen – auch solche, die für das IT-Management irrelevant sind. Das Ergebnis: Eine CMDB mit Zehntausenden von Einträgen, die niemand pflegt und niemand versteht. Statt Klarheit entsteht Rauschen.
„Eine CMDB mit 50.000 CIs und unklaren Verantwortlichkeiten ist gefährlicher als eine CMDB mit 5.000 sorgfältig gepflegten CIs."
Die Lösung: Scope-Definition vor der Discovery-Aktivierung. Legen Sie fest, welche CI-Klassen für Ihr Unternehmen relevant sind – und konfigurieren Sie Discovery so, dass irrelevante CIs gar nicht erst erstellt werden.
Reconciliation: Das unterschätzte Herzstück
In vielen Unternehmen gibt es mehrere Datenquellen für CIs: Discovery, ein ITAM-Tool, manuelle Erfassung, vielleicht ein externes CMMS. ServiceNow bietet mit dem CMDB Reconciliation Framework die Möglichkeit, diese Quellen gegeneinander abzugleichen und zu priorisieren.
Ohne Reconciliation entstehen Duplikate, widersprüchliche Attribute und CI-Datensätze, denen niemand vertraut. Mit einem sauber konfigurierten Reconciliation-Setup wird Discovery zu einem von mehreren vertrauenswürdigen Eingabekanälen – nicht zum einzigen.
- Alle Datenquellen inventarisieren und Vertrauensstufen vergeben
- Reconciliation-Regeln pro CI-Klasse und Attribut definieren
- Duplikat-Erkennung aktivieren und Merge-Regeln festlegen
- Regelmäßige CMDB-Health-Checks mit dem CMDB Health Dashboard
Service Graph Connectors für die Lücken
Was Discovery nicht erreicht, decken Service Graph Connectors ab: vorkonfigurierte Integrationen für AWS, Azure, GCP, VMware, Kubernetes, Okta und viele weitere Plattformen. Sie liefern nicht nur CI-Daten, sondern auch Beziehungen – und sind damit der entscheidende Baustein für eine vollständige Service Map.
Governance: Der Faktor Mensch
Am Ende ist eine saubere CMDB kein technisches Problem – es ist ein Governance-Problem. Wer ist verantwortlich für welche CI-Klassen? Wie werden neue CIs genehmigt? Was passiert mit CIs, die Discovery nicht mehr findet? Diese Fragen müssen organisatorisch beantwortet werden, bevor jede Konfiguration sinnvoll ist.
- CI-Owner für jede relevante CI-Klasse benennen
- Regelmäßige Review-Zyklen für verwaiste und veraltete CIs
- Change-Prozess mit CMDB verknüpfen – jeder Change aktualisiert die CMDB
- CMDB-Qualität als KPI im IT-Betrieb verankern
Ihre CMDB braucht eine Grundlage?
Wir helfen Ihnen, Discovery sinnvoll einzusetzen, Reconciliation aufzusetzen und eine CMDB-Governance zu etablieren, die im Alltag funktioniert.
Kostenloses Erstgespräch vereinbaren