Konfigurationsdaten, die tragen

Wofür du eine CMDB wirklich brauchst

Zwei Fragen rechtfertigen den ganzen Aufwand: Was fällt aus, wenn dieses System steht? Und was hängt daran, wenn wir es ändern? Alles andere ist Pflege ohne Abnehmer.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Kleine Gruppen Präsenz und Live-Online Zertifizierte Trainer
Worum es geht

Die meisten CMDBs scheitern nicht am Werkzeug, sondern am Zuschnitt

Der übliche Verlauf beginnt mit einem Projekt, das alles erfassen will. Nach einem halben Jahr steht ein beeindruckend vollständiger Bestand, und zwölf Monate später weicht er an genug Stellen von der Wirklichkeit ab, dass niemand mehr blind darauf vertraut. Ab da wird bei jeder wichtigen Frage doch wieder telefoniert.

Der Schaden ist doppelt. Der Pflegeaufwand läuft weiter, weil das Werkzeug bezahlt und der Ablauf beschlossen ist, aber der Nutzen ist weg. Und im Ernstfall, wenn schnell klar sein müsste, wer betroffen ist, verlässt sich das Team auf Erfahrungswissen, das an einzelnen Personen hängt und mit ihnen das Haus verlässt.

Wer das umdreht und mit den Fragen statt mit den Objekten anfängt, kommt mit einem Bruchteil der Datenmenge aus. Eine kleine CMDB, der alle trauen, ist mehr wert als eine vollständige, die niemand mehr abfragt.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Aufbau im Detail

Der Aufbau im Detail

Der Aufbau

Configuration Item = Identifikation + Attribute + Beziehungen + führende Datenquelle + Verantwortung + Lebenszyklusstatus
  1. 01 Stabiler Schlüssel Identifikation

    Eine Kennung, die eine Umbenennung übersteht. Wer den Hostnamen als Schlüssel nimmt, verliert die Historie beim ersten Umzug.

  2. 02 Beschreibende Felder Attribute

    Nur die Felder, die eine benannte Auswertung speisen. Jedes zusätzliche Feld erzeugt Pflegeaufwand, der dauerhaft anfällt und nie wieder verschwindet.

  3. 03 Der eigentliche Wert Beziehungen

    Die Verbindungen nach oben zum Service und nach unten zur tragenden Technik. Genau diese Kanten beantworten die Frage nach der Betroffenheit, für die die ganze Datenbank existiert.

  4. 04 Schreibhoheit führende Datenquelle

    Je Attribut genau eine Quelle, die schreiben darf. Alle anderen liefern einen Abgleich und melden Abweichungen, statt den Wert stillschweigend zu überschreiben.

  5. 05 Benannte Person Verantwortung

    Ein Eintrag ohne verantwortliche Person veraltet garantiert, weil niemand die Rückfrage bekommt, sobald der Wert nicht mehr stimmt.

  6. 06 Aufbau bis Rückbau Lebenszyklusstatus

    Der Status trennt geplant, im Betrieb und stillgelegt. Ohne Endstatus bleibt jedes abgeschaltete System für immer in der Auswirkungsanalyse stehen.

Wenn es nicht funktioniert

Das siehst du

Die Auswirkungsanalyse vor einem Change listet Systeme auf, die es längst nicht mehr gibt.

Warum

Abgeschaltete Systeme werden nie auf einen Endstatus gesetzt, weil das Abschalten keinen Vorgang erzeugt.

Was hilft

Den Rückbau als eigenen Change-Typ führen, dessen Abschluss den Status des Configuration Items setzt.

Das siehst du

Zwei Einträge beschreiben denselben Server unter verschiedenen Namen.

Warum

Automatische Erkennung und manuelle Pflege schreiben in dieselben Felder, ohne dass eine Quelle führend ist.

Was hilft

Je Attribut eine führende Quelle festlegen und die zweite nur noch abgleichen und Abweichungen melden lassen.

Das siehst du

Niemand kann sagen, welcher Service ausfällt, wenn eine bestimmte Datenbank stehenbleibt.

Warum

Die CMDB kennt nur Geräte und Software, aber keine Beziehungen zu den Services darüber.

Was hilft

Zuerst die Beziehungen zwischen den wichtigsten Services und der tragenden Technik modellieren, bevor die Tiefe wächst.

Das siehst du

Die Pflege kostet spürbar Zeit, und trotzdem fragt niemand die Daten ab.

Warum

Erfasst wurde, was erfassbar war, und nicht das, was für Entscheidungen gebraucht wird.

Was hilft

Jedes Attribut an eine konkrete Auswertung binden und ersatzlos streichen, was keine hat.

Das siehst du

Der Lizenznachweis stimmt nicht, obwohl die CMDB gepflegt aussieht.

Warum

Vertrags- und Lizenzdaten gehören ins IT Asset Management und nicht in die Konfigurationssicht.

Was hilft

Beide Bestände getrennt führen und über eine gemeinsame Kennung verknüpfen, statt sie in ein Datenmodell zu zwingen.

Sechs Schichten eines belastbaren Configuration Items

  1. 01 Eine Kennung, die den nächsten Umzug und die nächste Umbenennung übersteht.
  2. 02 Attribute, die jeweils eine benannte Auswertung speisen.
  3. 03 Beziehungen nach oben zum Service und nach unten zur Technik.
  4. 04 Genau eine Quelle, die schreiben darf, alle anderen gleichen ab.
  5. 05 Eine verantwortliche Person, die bei Abweichungen gefragt wird.
  6. 06 Ein Status, der auch das Abschalten eines Systems abbildet.
Was du mitnimmst

Was du mitnimmst

Du bekommst die Kriterien, nach denen du entscheidest, was aufgenommen wird und was nicht, und die Regeln, mit denen der Bestand aktuell bleibt, ohne dass die Pflege ein eigenes Team braucht.

Vom Nutzen her aufbauen

Du leitest jedes Attribut aus einer konkreten Auswertung ab und streichst alles, hinter dem keine steht.

Beziehungen vor Attributen

Du modellierst zuerst die Verbindungen zwischen Service und tragender Technik, weil genau daran die Auswirkungsanalyse hängt.

Schreibhoheit festlegen

Du bestimmst je Attribut eine führende Quelle und lässt die zweite nur abgleichen, damit Widersprüche sichtbar statt zufällig werden.

Den Rückbau erfassen

Du machst das Abschalten zu einem Vorgang, der einen Status setzt, und stoppst damit das einseitige Wachstum des Bestands.

Assets getrennt führen

Du trennst Vertrags- und Lizenzdaten von der Konfigurationssicht und verbindest beide über eine gemeinsame Kennung.

Qualität messbar machen

Du prüfst per Stichprobe nach größeren Änderungen statt einmal im Jahr und erkennst Abweichungen, bevor sie in einer Störung auffallen.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Der Nutzen entsteht in zwei konkreten Momenten

Der erste Moment ist die Störungsanalyse. Ein Speichersystem meldet einen Fehler, und die Frage lautet, welche Fachverfahren jetzt betroffen sind und wen man informieren muss. Ohne modellierte Beziehungen beginnt an dieser Stelle eine Telefonrunde, die zwanzig Minuten kostet, während der Ausfall weiterläuft.

Der zweite Moment ist die Bewertung einer Änderung. Die Change Authority soll das Risiko einschätzen und braucht dafür dieselbe Beziehung in der Gegenrichtung: Was hängt an dem System, das verändert werden soll? Genau dafür sind Configuration Items da, und genau deshalb ist die Beziehung wichtiger als das einzelne Attribut.

Alles, was diese beiden Fragen nicht beantwortet, ist Datenpflege ohne Abnehmer. Das ist der nützlichste Filter beim Aufbau: Zu jedem Attribut gehört benannt, welche Auswertung es speist.

Was ein Configuration Item ausmacht

Ein Configuration Item ist alles, was verwaltet werden muss, damit ein Service erbracht werden kann, also Hardware, Software und Netzstrecken, aber auch Dokumente und Vereinbarungen. Entscheidend ist nicht die Technik, sondern die Frage, ob eine Änderung daran Auswirkung hat.

Die Tiefe ist eine bewusste Entscheidung. Wer jede Schraube modelliert, erzeugt Pflegeaufwand, der nach drei Monaten aufgegeben wird. Ein tragfähiger Anfang sind die Services mit der höchsten Kritikalität und die eine Ebene darunter, die sie trägt. Diese Beziehungen lassen sich mit vertretbarem Aufwand aktuell halten und beantworten die meisten Fragen im Ernstfall.

Warum Konfigurationsdaten veralten

Der Hauptgrund ist ein struktureller. Der Aufbau erzeugt einen Eintrag, der Rückbau erzeugt keinen. Systeme werden angelegt, dokumentiert und irgendwann abgeschaltet, ohne dass die Abschaltung einen Vorgang auslöst. Deshalb wächst jede ungepflegte CMDB nur in eine Richtung und wird mit der Zeit immer unschärfer.

Der zweite Grund ist die geteilte Schreibhoheit. Automatische Erkennung liefert technische Attribute zuverlässig, aber sie kennt weder den fachlichen Zweck noch die Verantwortung. Beschreiben beide Quellen dasselbe Feld, gewinnt abwechselnd die eine oder die andere, und niemand traut dem Ergebnis. Service Configuration Management löst das nicht durch mehr Werkzeuge, sondern durch die Festlegung, welche Quelle für welches Attribut führend ist.

CMDB und IT Asset Management sind nicht dasselbe

Die Konfigurationssicht fragt, wie etwas zusammenhängt. Die Asset-Sicht fragt, was es kostet, wem es gehört und wie lange es noch unter Vertrag steht. Beide Bestände beschreiben oft dieselben Geräte, verfolgen aber verschiedene Zwecke, und sie in ein einziges Datenmodell zu quetschen macht beide unbrauchbar.

In ITIL 4 sind das zwei getrennte Practices, Service Configuration Management und IT Asset Management, die über eine gemeinsame Kennung verbunden werden. Für den Lizenznachweis ist die Asset-Seite zuständig, für die Auswirkungsanalyse die Konfigurationsseite.

Dazu passende Kurse

Service Configuration Management und IT Asset Management liegen gemeinsam im Modul Plan, Implement & Control, und wer beide sauber trennen will, kann sich dazu die Trainings zum Configuration Management ansehen .

Wer den Aufbau direkt am aktuellen Schema ausrichtet, findet die neuere Generation der ITIL-Zertifizierungen mit demselben Zuschnitt der Module.

Wissen prüfen

Wie sicher bist du beim Thema wirklich?

Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.

Katharina war eine super Dozentin mit sehr viel Wissen. Sie ist auf alle Fragen eingegangen und konnte alle klären.
PRINCE2® 7 Kompaktkurs (Foundation & Practitioner)
Ein sehr anspruchsvolles Training welches von einer sehr kompetente Trainerin geleitet wurde.
PRINCE2® 7 Kompaktkurs (Foundation & Practitioner)
Alles in allem bin ich sehr zufrieden, da der Trainer sich viel Mühe gegeben hat und alles sehr gut erklären konnte.
ITIL® 4 Foundation (English)

Häufige Fragen

Reicht nicht eine gut gepflegte Tabelle?
Für eine Liste von Geräten ja, für Beziehungen nein. Sobald du wissen willst, welche Services an einem System hängen, brauchst du Verknüpfungen in beide Richtungen und eine Historie, welcher Stand wann galt. Beides bildet eine Tabelle nur mit sehr viel Disziplin ab, und die hält selten länger als ein Jahr.
Womit fängst du an, wenn noch nichts existiert?
Mit den Services, deren Ausfall wehtut, und nicht mit dem Serverraum. Nimm die fünf bis zehn wichtigsten Fachverfahren, modelliere die Systeme, die sie tragen, und die Beziehung dazwischen. Damit läuft die erste Auswirkungsanalyse, und dieser sichtbare Nutzen trägt die Diskussion über den weiteren Ausbau.
Wie oft musst du Konfigurationsdaten prüfen?
Regelmäßige Stichproben schlagen den jährlichen Großabgleich. Sinnvoll ist eine feste Prüfung nach jedem größeren Change und eine Baseline vor Umbauten, damit du hinterher vergleichen kannst. Ein vollständiger Abgleich einmal im Jahr findet die Abweichungen erst, wenn sie schon geschadet haben.
Gehören bezogene Cloud-Dienste in die CMDB?
Ja, aber nicht in derselben Tiefe. Was du selbst nicht änderst, musst du nicht bis ins Detail modellieren. Der bezogene Dienst gehört als Configuration Item hinein, mit den Beziehungen zu den Services, die auf ihm laufen, und mit dem Verweis auf den Vertrag, der auf der Asset-Seite geführt wird.

Passt thematisch dazu

Sobald im Bestand auch Systeme mit KI-Funktionen stehen, kommt die Frage dazu, welche Pflichten für sie gelten, und dabei hilft die Einordnung in die Risikoklassen des AI Act .

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem ITIL & PRINCE2-Programm den passenden Kurs für deinen Stand zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.

Konfigurationsdaten sind so gut wie die Fragen, die sie beantworten

Der Zuschnitt der Datenmodelle, die Arbeit mit Baselines und die Trennung von Asset- und Konfigurationssicht gehören ins Modul Plan, Implement and Control.