CMDB Management mit i-doit schafft eine verlässliche Grundlage für IT-Betrieb und Managemententscheidungen. Dieser Artikel zeigt, wie Sie Ihre CMDB strukturiert aufbauen, Datenquellen integrieren und die Datenqualität dauerhaft sichern. Sie erfahren außerdem, wie Reporting, Change Management, Audits und Vertragsmanagement auf derselben Datenbasis zusammenarbeiten.
1. CMDB Management: die Grundlage für eine verlässlich dokumentierte IT
2. Warum i-doit für das CMDB Management einsetzen?
3. CMDB-Datenintegration: Datenquellen verbinden und Konflikte vermeiden
4. CMDB-Datenanreicherung: Systeme mit Services, Verantwortlichen und Verträgen verknüpfen
5. CMDB-Datenqualität messen und verbessern
6. Reporting: aus CMDB-Daten konkrete Management-Aufgaben ableiten
7. Changes: Änderungen mit der Dokumentation verbinden
8. Audits und Vertragsmanagement unterstützen
9. CMDB Management: Mit i-doit das Thema IT-Dokumentation neu definieren und gezielt steuern
Eine Configuration Management Database, kurz CMDB, dokumentiert Configuration Items (CIs): beispielsweise Server, Anwendungen und IT-Services. Neben ihren Eigenschaften erfasst sie Abhängigkeiten und Beziehungen zwischen diesen Objekten. Damit lässt sich nachvollziehen, welche Anwendung auf welchem Server läuft und welche Services davon abhängen.
CMDB Management umfasst die Regeln und Abläufe, mit denen diese Informationen erfasst, geprüft, aktualisiert und genutzt werden. Dazu gehören Verantwortlichkeiten, Schnittstellen und der Umgang mit Änderungen über den gesamten Lebenszyklus eines CIs.
Die CMDB liefert die technische Grundlage. Ob sie brauchbare Antworten liefert, hängt davon ab, wie Ihre Prozesse aufgebaut sind.
Mit der i-doit CMDB für strukturiertes CMDB Management dokumentieren Sie Geräte, Anwendungen, Standorte und Services sowie deren Zusammenhänge. Der CMDB Explorer stellt erfasste Abhängigkeiten und Beziehungen grafisch dar. Damit können Betrieb und Management auf derselben Datenbasis arbeiten.
Ein praktischer Anwendungsfall: Vor der Wartung eines Servers prüft das IT-Team, welche Anwendungen und Services damit verbunden sind. Das Management erhält eine Grundlage, um betroffene Geschäftsabläufe und Wartungszeiten zu bewerten.
Dieser Ansatz passt zum Ziel des Service Configuration Management nach ITIL: verlässliche Konfigurationsinformationen dann bereitzustellen, wenn sie benötigt werden.
Wer eine CMDB implementieren möchte, sollte zuerst einmal festlegen, welche Entscheidungen sie unterstützen muss. Ein guter Einstieg ist ein klar abgegrenzter Anwendungsfall:
Welche Systeme sind von einer geplanten Wartung betroffen?
Wer verantwortet eine geschäftskritische Anwendung oder Prozess?
Welche Geräte verlieren in den nächsten Monaten ihren Herstellersupport?
Welche Wartungsverträge laufen demnächst aus?
Für die erste Frage benötigen Sie vor allem Abhängigkeiten. Für die letzte brauchen Sie Vertragsdaten und deren Zuordnung zu den betroffenen Objekten. Der Anwendungsfall bestimmt, welche Informationen zuerst dokumentiert werden.
So bleibt das CMDB Management auch mit begrenzten Ressourcen umsetzbar.
Ein einfaches Datenmodell kann folgendermaßen aussehen:
|
Objekttyp |
Wichtige Attribute |
Hostet Anwendungen; gehört zu einem Standort |
| Server | Eindeutige ID, Betriebssystem, Status, Prüftermin | Hostet Anwendungen; gehört zu einem Standort |
| Anwendung | Name, Version, verantwortliches Team, Kritikalität | Nutzt Datenbanken; unterstützt IT-Services |
| IT-Service | Serviceverantwortlicher, Betriebszeiten, Kritikalität | Benötigt Anwendungen und Infrastruktur |
| Vertrag | Anbieter, Laufzeit, Kündigungsfrist, Vertragsverantwortlicher | Deckt Geräte, Anwendungen oder Services ab |
Beschränken Sie Pflichtfelder auf Informationen, die für den jeweiligen Anwendungsfall erforderlich sind. Jedes zusätzliche Feld braucht eine Quelle, einen Pflegeprozess und einen Nutzen.
In i-doit strukturieren Sie die Dokumentation über Objekttypen, Kategorien und Attribute. Zur Dokumentation gehören außerdem verständliche Felddefinitionen. Legen Sie beispielsweise fest, ob „Verantwortlicher“ den technischen Betrieb, die fachliche Zuständigkeit oder die Vertragsbetreuung bezeichnet.
Erfolgreiches CMDB Management braucht jemanden, der das Datenmodell und die Qualitätsregeln koordiniert. Die fachliche Pflege der Assets kann auf mehrere Teams verteilt werden.
Definieren Sie je Objektklasse, wer Daten prüft, wer Fehler korrigiert und wann Aktualisierungen erfolgen. Ein Serverteam kann technische Serverdaten verantworten, während der Einkauf oder die Buchhaltung Vertragslaufzeiten pflegt.
Wenn Sie eine CMDB erstellen, planen Sie diese Zuständigkeiten von Anfang an mit ein.
Technische und organisatorische Informationen liegen meist in mehreren Systemen z.B. Discovery, Endgeräteverwaltung, Monitoring, MDM oder Verzeichnisdienste.
Für die CMDB-Datenintegration sollte festgelegt werden, welche Datenquelle welches Attribut liefern darf. Ein Discovery-System kann das erkannte Betriebssystem aktualisieren. Die Kostenstelle dagegen kommt meist aus einem Buchhaltungs- oder Faktorierungstool.
Schreiben zwei Datenquellen auf dasselbe Feld, braucht es eine Prioritätsregel. Andernfalls überschreibt ein Import möglicherweise eine korrekte Information durch einen veralteten Wert.
CMDB Management bedeutet hier, Datenflüsse bewusst zu steuern.
Ein Gerätename kann sich ändern. Eine IP-Adresse kann neu vergeben werden. Prüfen Sie deshalb je Objektklasse, welche Merkmale eine zuverlässige Zuordnung erlauben.
Für physische Geräte können Hersteller und Seriennummer geeignete Merkmale sein. Bei Cloud-Ressourcen kommen beispielsweise Ressourcen-ID und Kontokontext infrage. Eine interne CMDB-ID verknüpft anschließend die zugeordneten Informationen.
Zur CMDB-Datenintegration gehören außerdem Regeln für Dubletten, leere Felder und ausgebliebene Erkennungen. Wird ein Gerät einmal nicht gefunden, sollte daraus nicht unmittelbar eine Löschung folgen.
Protokollieren Sie Importfehler und ordnen Sie deren Bearbeitung einem Team zu. Ein unbemerkt ausgefallener Datenimport lässt die CMDB-Datenbank schleichend veralten.
Für technische Bestandsdaten bietet die Integration von i-doit und JDisc Discovery einen konkreten Einstieg. JDisc erkennt Geräte und technische Zusammenhänge; die Integration übernimmt diese Informationen in i-doit. Welche Daten importiert und aktualisiert werden, sollte zu Ihrem Datenmodell passen.
Automatische Inventarisierung liefert viele technische Informationen. Für betriebliche Entscheidungen fehlt jedoch häufig der Servicebezug, die fachliche Zuständigkeit oder die Kritikalität.
Durch CMDB-Datenanreicherung ergänzen Sie diese Zusammenhänge. Aus einem erkannten Server wird beispielsweise ein System, das eine Anwendung hostet, einen Geschäftsservice unterstützt und einem Wartungsvertrag zugeordnet ist.
In i-doit können Sie diese Angaben als Abhängigkeiten oder Beziehungen dokumentieren. Die Ergänzung kann manuell, über weitere Schnittstellen oder durch geprüfte Zuordnungsregeln erfolgen. Entscheidend ist, dass Herkunft und Verantwortung nachvollziehbar bleiben.
Ein Beispiel: Discovery erkennt eine virtuelle Maschine samt Betriebssystem und darauf laufender Anwendungen. Durch CMDB-Datenanreicherung ergänzen Sie den organisatorischen Kontext: Welchen Geschäftsprozess unterstützt die Anwendung? Wer ist für ihren Betrieb verantwortlich? Welche Auswirkungen hätte ein Ausfall? Und welcher Supportvertrag sichert das System ab?
Priorisieren Sie diese Ergänzungen für geschäftskritische Services und deren Abhängigkeiten. So hilft Ihre CMDB Documentation dabei, Wartungen zu planen, Störungen gezielt zu bearbeiten und betriebliche Risiken einzuschätzen.
CMDB Management braucht überprüfbare Qualitätsregeln. Die Anzahl dokumentierter Objekte allein sagt wenig darüber aus, ob Ihre Teams damit arbeiten können.
Hilfreiche Prüfkriterien sind Vollständigkeit, Aktualität, Eindeutigkeit und Plausibilität. Auch Beziehungen verdienen eigene Kontrollen: Ein vorhandener Servereintrag hilft bei der Impactanalyse wenig, wenn seine Anwendungen nicht zugeordnet sind.
Für i-doit sollten Sie daraus konkrete Prüfungen ableiten: beispielsweise Server ohne Zuständigkeit, produktive Anwendungen ohne Servicezuordnung oder Vertragsobjekte ohne Laufzeit. Definieren Sie die benötigten Auswertungen anhand Ihrer dokumentierten Felder.
Für ein eigenes Qualitätsreporting eignen sich beispielsweise diese Kennzahlen:
|
Kennzahl |
Was wird geprüft? |
Mögliche Folgeaktion |
| Pflichtfelder | Anteil der relevanten CIs mit vollständig befüllten Pflichtfeldern | Fehlende Angaben dem zuständigen Team zuweisen |
| Aktualität | Anteil der CIs innerhalb des definierten Prüfintervalls | Quelle oder Bestätigungsprozess prüfen |
| Servicezuordnung | Anteil der relevanten Systeme mit bestätigtem Servicebezug | Beziehungen fachlich ergänzen |
Definieren Sie den betrachteten Bestand und die Berechnung jeder Kennzahl eindeutig. Bei ausgeschiedenen Geräten gelten andere Anforderungen als bei produktiven Servern.
Befüllte Felder sind zudem kein Beweis für korrekte Inhalte. Ergänzen Sie automatisierte Kontrollen durch gezielte Stichproben.
Verbesserungen der CMDB-Datenqualität sollten in konkrete Aufgaben münden: mit Verantwortlichem, Termin und anschließender Kontrolle. Dadurch wird Qualitätspflege Bestandteil des Betriebs.
i-doit unterstützt das Reporting mit seinem integrierten Report Manager. Über Auditierung und Reporting mit i-doit lassen sich CMDB-Daten gezielt kombinieren, filtern und als wiederverwendbare Auswertungen zentral bereitstellen.
Welche Systeme müssen im nächsten Quartal ersetzt werden? Wo laufen Wartungsverträge aus? Und welche geschäftskritischen Anwendungen hängen noch von einem Server ohne Herstellersupport ab? Mit gezielten Reports in i-doit machen Sie aus dokumentierten Informationen eine Grundlage für Planung und Priorisierung.
Ein Beispiel: Ein Report zeigt alle Server, deren Support innerhalb der nächsten sechs Monate endet. Ergänzen Sie die darauf betriebenen Anwendungen, die betroffenen Services und deren Verantwortliche, lässt sich der Handlungsbedarf final bewerten. Ein Testsystem kann anders priorisiert werden als ein Server, auf dem die zentrale Warenwirtschaft läuft.
Die Führungsebene erhält damit einen Überblick über Investitionsbedarf und betriebliche Risiken. Die zuständigen IT-Teams können anhand der konkreten Assets Ersatzbeschaffungen vorbereiten, Migrationen planen und offene Zuständigkeiten klären.
Wiederkehrende Reports machen außerdem Fortschritte sichtbar: Welche Systeme wurden bereits ersetzt? Welche Maßnahmen sind noch offen? So unterstützt Reporting das CMDB Management mit i-doit von der ersten Bewertung bis zur Umsetzung.
Im Prozess wird die CMDB mit angebundenem Ticketsystem genutzt:
Den Change als Ticket erfassen und die betroffenen CIs aus i-doit zuordnen.
Anhand der dokumentierten Abhängigkeiten prüfen, welche Anwendungen und Services betroffen sind.
Die Änderung im Ticketsystem planen, freigeben und ihre Umsetzung dokumentieren.
Die geänderten Attribute und Beziehungen in i-doit aktualisieren und vor dem Ticketabschluss prüfen.
Ein Beispiel: Das IT-Team plant ein Betriebssystem-Upgrade auf einem Server. Im Change-Ticket werden das betroffene System, die Umsetzungsschritte und das Wartungsfenster festgehalten. i-doit liefert den Kontext: Welche Anwendungen laufen auf dem Server? Welche Services hängen davon ab? Welche Verantwortlichen müssen einbezogen werden?
Nach der Umsetzung dokumentiert das Team das Ergebnis im Ticket und aktualisiert den Betriebssystemstand in i-doit. So bleibt nachvollziehbar, was geändert wurde, während die CMDB den aktuellen Zustand abbildet.
CMDB Management wird damit Bestandteil der täglichen Arbeit im Ticketsystem. Definieren Sie dafür ein klares Abschlusskriterium: Ein Change ist erst abgeschlossen, wenn die betroffenen CMDB-Daten geprüft und erforderliche Aktualisierungen vorgenommen wurden.
Bei einer Prüfung müssen Informationen nachvollziehbar sein. Halten Sie deshalb fest, woher Daten stammen, wann sie geprüft wurden und wer für sie verantwortlich ist.
In i-doit lassen sich Zuständigkeiten und Objektinformationen auswerten; Änderungen an der Dokumentation werden im Logbuch nachvollziehbar erfasst. Eine strukturierte CMDB Documentation erleichtert damit die Zusammenstellung von Objektlisten, Zuständigkeiten und Änderungsverläufen. Vereinbarte Prüfkriterien können über Reports kontrolliert werden.
Welche Nachweise erforderlich sind, hängt vom konkreten Audit ab. Planen Sie deshalb anhand dieser Anforderungen, welche Informationen und Historien Sie aufbewahren müssen.
Beim Vertragsmanagement mit i-doit verknüpfen Sie Vertragsinformationen mit den zugehörigen Objekten und Verantwortlichen. Neben der Laufzeit zählt dabei auch der technische Geltungsbereich. Ordnen Sie Wartungs- und Supportverträge den Geräten, Anwendungen oder Services zu, die sie abdecken.
Dokumentieren Sie Vertragsverantwortliche, Kündigungsfristen und den Ablageort der Vertragsunterlagen. Richten Sie automatische Benachrichtigungen passend zu Ihren Anforderungen ein.
Eine weitere Form der CMDB-Datenanreicherung ist die Zuordnung von Supportbedingungen oder vereinbarten Reaktionszeiten. Dadurch lässt sich vor einer Verlängerung prüfen, welche Systeme noch genutzt werden und welche Zeiten tatsächlich benötigt werden.
Eine CMDB muss Fragen direkt beantworten können:
Welche Systeme halten Ihre Geschäftsprozesse am Laufen?
Wo besteht Handlungsbedarf?
Und welche Folgen hat eine geplante Änderung?
Mit i-doit führen Sie technische Informationen, Verantwortlichkeiten, Verträge und Serviceabhängigkeiten in einer zentralen CMDB zusammen. So erhält Ihr Team den Überblick, den es für fundierte Entscheidungen braucht.
Der CMDB Explorer macht Zusammenhänge sichtbar, Reports liefern Antworten auf konkrete Managementfragen und die Anbindung an Discovery- und Ticketsysteme bringt Ihre Dokumentation direkt in die täglichen Abläufe. Damit wird CMDB Management mit i-doit zu einem wirksamen Werkzeug: für planbare Changes, schnellere Fehleranalysen, nachvollziehbare Audits und einen besseren Überblick über Kosten und Vertragsfristen.
Erleben Sie, was i-doit für Ihre IT leisten kann: Entdecken Sie i-doit für Ihr CMDB Management und vereinbaren Sie eine Demo mit unserem Sales-Team.