Configuration Management Database (CMDB)

Automatische Erkennung (Discovery)

Das ist die Funktion, die über Erfolg oder Scheitern entscheidet. Discovery scannt dein Netzwerk und erkennt Geräte, Anwendungen und deren Konfiguration automatisch. Achte darauf, ob die Erkennung agentenbasiert läuft (kleine Software auf jedem Gerät) oder agentenlos über Protokolle wie SNMP, WMI oder SSH. Agentenlos ist einfacher auszurollen, kommt aber nicht überall hin. Agentenbasiert liefert mehr Detail, verursacht aber Verwaltungsaufwand. Viele Betriebe brauchen eine Mischung.

Beziehungsmodellierung

Schau dir an, wie das Tool Abhängigkeiten darstellt. Kannst du auf einen Blick sehen, was von einem CI abhängt und wovon es selbst abhängt? Gibt es eine grafische Darstellung, die auch bei mehreren hundert Verbindungen noch lesbar bleibt? Eine Beziehungskarte, die bei fünfzig Objekten schon zum unlesbaren Knäuel wird, hilft im Ernstfall nicht.

Auswirkungsanalyse

Wenn du eine Änderung planst, willst du wissen, was betroffen ist. Ein gutes Werkzeug zeigt dir vor der Änderung: Diese Anwendung, diese Abteilung, diese Schnittstelle hängen dran. Diese Funktion rechtfertigt in vielen Betrieben allein schon die Einführung, weil sie ungeplante Ausfälle nach Wartungsarbeiten verhindert.

Schnittstellen zu anderen Systemen

Eine CMDB steht selten allein. Sie tauscht Daten mit dem Ticketsystem, dem Monitoring, der Endgeräteverwaltung und oft mit der Personalverwaltung aus. Prüf konkret, welche Schnittstellen fertig vorhanden sind und welche du bauen lassen musst. Eine offene API klingt gut, kostet aber Entwicklungsaufwand, wenn keine fertige Anbindung existiert.

Rollen und Berechtigungen

Nicht jeder soll alles sehen und ändern. Achte darauf, ob du Berechtigungen fein steuern kannst: Wer darf CIs anlegen, wer nur lesen, wer Beziehungen ändern? In größeren Betrieben mit mehreren Standorten oder Tochtergesellschaften ist die Mandantenfähigkeit ein Thema.

Historie und Nachvollziehbarkeit

Jede Änderung an einem CI sollte protokolliert sein: Wer hat wann was geändert. Das brauchst du für die Fehlersuche und für Prüfungen. Ohne Historie stehst du bei einem Problem ratlos da, weil niemand mehr weiß, wann sich die Konfiguration geändert hat.

Lass die richtige Person testen

Lass die Software in der Demo von der Person bedienen, die später täglich damit arbeitet, nicht vom Chef und nicht vom Vertriebler. Gib ihr eine konkrete Aufgabe: Leg ein neues CI an, verknüpf es mit einem bestehenden, und finde alle Abhängigkeiten eines dritten CI. Wenn das zäh ist oder unklar, wird es im Alltag schlimmer, nicht besser.

Prüf die Discovery an deiner echten Umgebung

Eine Discovery-Demo im Vorführnetz des Anbieters sagt wenig aus. Verlang einen Testlauf in deinem eigenen Netz, auch wenn nur ein Teilbereich. Schau, wie viele Geräte erkannt werden, wie viele falsch zugeordnet sind und wie viel Nacharbeit von Hand nötig ist. Genau hier zeigt sich, ob das Werkzeug zu deiner Landschaft passt.

Bewerte den Datenmodell-Aufwand

Manche Systeme kommen mit einem fertigen Datenmodell, das du übernehmen kannst. Andere erwarten, dass du dein Modell selbst aufbaust. Beides hat Vor- und Nachteile. Ein fertiges Modell ist schneller startklar, passt aber vielleicht nicht zu deiner Realität. Ein freies Modell ist flexibel, kostet aber viel Vorarbeit und Fachwissen.

Denk an die Betriebsgröße, aber nicht an die Wunschgröße

Wähle nach dem, was du bist, nicht nach dem, was du in fünf Jahren sein willst. Ein Werkzeug, das auf große Konzerne zugeschnitten ist, überfordert einen Mittelständler mit Komplexität, die niemand nutzt. Skalierbarkeit ist wichtig, aber sie darf nicht dazu führen, dass du heute eine überdimensionierte Lösung betreibst.

Cloud oder eigener Betrieb

Klär früh, ob du eine Cloud-Lösung willst oder das System selbst betreiben musst. Das hängt oft an internen Vorgaben zum Datenschutz und an der Frage, ob deine IT den Betrieb selbst stemmen kann. Beides beeinflusst Kosten und Aufwand erheblich.

Die Lizenzkosten sind selten das größte Problem. Der eigentliche Aufwand steckt woanders. Ich gehe die üblichen Kostenblöcke durch, damit du weißt, worauf du achten musst.

Verbreitete Abrechnungsmodelle

Du triffst im Markt auf mehrere Modelle. Verbreitet ist die Abrechnung nach Anzahl der verwalteten CIs oder nach Anzahl der Nutzer. Manche Anbieter rechnen nach erkannten Geräten, andere nach Modulen. Rechne bei einer Abrechnung nach CIs vorher hoch, wie viele Objekte dein Bestand tatsächlich umfasst, denn diese Zahl wächst schnell, sobald die Discovery greift. Ich nenne bewusst keine Zahlen, weil sie je nach Anbieter stark schwanken. Lass dir die Kosten für deinen konkreten Bestand ausrechnen, nicht für ein Musterszenario.

Die versteckten Kosten

• Einführung und Beratung: Der Aufbau des Datenmodells und die Einrichtung der Discovery kosten oft mehr als die Lizenz im ersten Jahr.
• Schnittstellen: Jede Anbindung an ein bestehendes System, die nicht fertig vorhanden ist, verursacht Entwicklungsaufwand.
• Datenpflege: Auch mit Discovery bleibt manuelle Arbeit, besonders bei Beziehungen und bei Objekten, die kein Scanner erkennt (Verträge, Prozesse).
• Schulung: Die Leute müssen das System bedienen können. Ohne Schulung nutzt es niemand richtig.
• Betrieb bei eigener Installation: Server, Updates, Backups, Wartung.

Die laufende Pflege ist der größte Posten

Der teuerste Teil einer CMDB ist die Zeit, die jemand jeden Monat in die Pflege steckt. Diese Kosten tauchen in keinem Angebot auf, sind aber real. Plan von Anfang an eine verantwortliche Person und deren Zeit ein. Eine CMDB ohne festen Verantwortlichen verrottet.

Alles auf einmal erfassen wollen

Der häufigste Fehler ist der Versuch, von Tag eins an jedes noch so kleine Detail zu erfassen. Das führt zu einem riesigen Datenberg, den niemand pflegen kann, und zu Frust, weil nach drei Monaten die Hälfte veraltet ist. Fang mit den Objekten an, die für deine wichtigsten Prozesse zählen, und erweitere schrittweise.

Zu viele Attribute pro CI

Ich habe Betriebe gesehen, die pro Server dreißig Felder pflegen wollten, von denen zwanzig nie jemand abgefragt hat. Jedes Feld, das du pflegst, kostet Zeit und veraltet. Frag bei jedem Attribut: Wer nutzt das und wofür? Wenn die Antwort unklar ist, lass es weg.

Discovery als Selbstläufer betrachten

Manche denken, die automatische Erkennung erledige alles. In der Praxis findet die Discovery viel, ordnet aber nicht alles richtig zu und erkennt Beziehungen nur teilweise. Ohne Nacharbeit entsteht ein Bestand voller Dubletten und falscher Verknüpfungen.

Keine klare Zuständigkeit

Wenn niemand offiziell für die CMDB verantwortlich ist, kümmert sich am Ende niemand. Nach dem Projektabschluss verliert die Datenqualität langsam an Boden, weil neue Systeme nicht mehr eingetragen werden. Benenne eine Person mit klarem Auftrag und eingeplanter Zeit.

Die CMDB von den Prozessen entkoppeln

Wenn die CMDB nicht in die täglichen Abläufe eingebunden ist, wird sie nicht aktualisiert. Ein Beispiel: Wird ein neuer Server aufgesetzt, muss der Eintrag in der CMDB Teil dieses Prozesses sein, nicht eine separate Aufgabe, die man später erledigen will und dann vergisst.

Eine CMDB enthält oft mehr personenbezogene Daten, als man zunächst denkt. Sobald du Geräte einem Mitarbeiter zuordnest oder erfasst, wer ein System nutzt, gilt die Datenschutz-Grundverordnung. Kläre, welche personenbezogenen Daten wirklich nötig sind, und erhebe nicht mehr als das (Grundsatz der Datenminimierung).

Zugriff und Protokollierung

Du musst nachweisen können, wer auf welche Daten zugreift und wer sie ändert. Ein Berechtigungskonzept und eine lückenlose Änderungshistorie sind hier keine Kür, sondern Grundlage. Bei einer Prüfung willst du zeigen können, dass nur befugte Personen Zugriff haben.

Standort der Daten

Bei Cloud-Lösungen ist der Speicherort der Daten relevant. Kläre, wo die Daten liegen und ob eine Verarbeitung ausserhalb des europäischen Raums stattfindet. Für viele Betriebe in Deutschland, Österreich und der Schweiz ist ein Serverstandort im europäischen Raum eine Vorgabe. Bei einer Verarbeitung durch einen Dienstleister brauchst du einen Vertrag zur Auftragsverarbeitung nach Artikel 28 DSGVO.

Aufbewahrung und Löschung

Überleg dir, wie lange du Konfigurationsdaten und Historie aufbewahren musst und wann du sie löschst. Ausgemusterte Geräte samt ihrer Zuordnung zu Personen dürfen nicht ewig im System bleiben. Ein Löschkonzept gehört dazu.

Branchenspezifische Vorgaben

Je nach Branche kommen zusätzliche Anforderungen hinzu, etwa im Finanzwesen oder bei Betreibern kritischer Infrastrukturen. In diesen Fällen kann eine belastbare CMDB sogar ausdrücklich verlangt sein, weil du die Nachvollziehbarkeit deiner IT-Landschaft belegen musst. Prüf, welche Regelwerke für deinen Betrieb gelten, und binde die betroffenen Fachbereiche früh ein.

Schritt eins: Zweck festlegen

Schreib auf, welche Fragen die CMDB beantworten soll. Zum Beispiel: Bei einer Störung schnell die Ursache eingrenzen, vor Änderungen die Auswirkung sehen, den Lizenzbestand überblicken. Diese Zwecke bestimmen, welche Daten du brauchst. Alles, was keinem dieser Zwecke dient, lässt du erst mal weg.

Schritt zwei: Bestand grob schätzen

Schätz, wie viele CIs du ungefähr verwalten wirst und welche Arten (Server, Netzwerkgeräte, Anwendungen, Endgeräte). Diese Zahl brauchst du für die Kostenschätzung und für die Auswahl der passenden Größenklasse.

Schritt drei: Anforderungsliste erstellen

Trenn zwischen Muss und Kann. Ein Muss könnte sein: agentenlose Discovery für dein Netz, Anbindung an dein bestehendes Ticketsystem, Serverstandort im europäischen Raum. Ein Kann sind Dinge, die schön wären, aber keine Bedingung sind. Diese Liste schützt dich davor, dich von Zusatzfunktionen blenden zu lassen.

Schritt vier: Zwei bis drei Anbieter testen

Hol dir eine überschaubare Auswahl und teste mit echten Aufgaben in deiner eigenen Umgebung. Lass die spätere Fachkraft testen, nicht die Führungsebene. Miss konkret: Wie gut greift die Discovery, wie schnell legt man ein CI an, wie lesbar ist die Beziehungsdarstellung.

Schritt fünf: Gesamtkosten über drei Jahre rechnen

Rechne nicht nur die Lizenz, sondern Einführung, Schnittstellen, Schulung, laufende Pflege und Betrieb. Betrachte einen Zeitraum von drei Jahren, damit die einmaligen Einführungskosten im Verhältnis sichtbar werden.

Schritt sechs: Mit einem Teilbereich starten

Führe die CMDB zuerst für einen abgegrenzten Bereich ein, etwa die wichtigsten Geschäftsanwendungen und ihre Server. Sammle Erfahrung, korrigiere das Datenmodell, und erweitere dann. Dieser schrittweise Ausbau verhindert, dass du dich im Großprojekt verrennst.

Schritt sieben: Verantwortung festlegen

Bevor das System live geht, benenne eine Person, die für die Pflege zuständig ist, und plane ihre Zeit fest ein. Verankere die CMDB in den bestehenden Prozessen, damit neue Systeme automatisch eingetragen werden. Ohne diesen Schritt scheitert die beste technische Lösung.

Wenn du diese sieben Schritte durchgehst, triffst du eine Entscheidung, die auf deiner Realität beruht und nicht auf einer Hochglanzpräsentation. Das ist der Unterschied zwischen einer CMDB, die nach zwei Jahren noch stimmt, und einer, die zur Datenruine wird.