So führst Du eine CMDB erfolgreich ein und stellst deren Aktualität langfristig sicher

Die CMDB ist Grundlage für eine effiziente und verlässliche Serviceerbringung. Sie fehlt in vielen Unternehmen. Die Folge: hoher Personalaufwand durch manuelle Tätigkeiten, vermeidbare Kosten, Sicherheitsrisiken und  unzufriedene Nutzer.

Was ist eine CMDB? 


Das Konzept der Configuration Management Database wurde in ITIL v2 eingeführt. Sinngemäß ist die Definition: "Die CMDB ist das genehmigte Abbild der IT-Infrastruktur".  


Meine persönliche Definition ist greifbarer, damit Du eine konkrete Verstellung bekommst: Du darfst Dir die CMDB wie eine Legokiste vorstellen: Dort drin findest Du alle Bausteine, die Du brauchst, um Deine Services zusammenzubauen. Die Bausteine bezeichnen wir als CIs (Configuration-Items).


Die CMDB Definition aus ITIL4: "Eine Datenbank, in der Konfigurationsdatensätze während ihres Lebenszyklus gespeichert werden. Sie verwaltet auch die Beziehungen zwischen den Konfigurationsdatensätzen."


Jedes CI verfügt über genau die Informationen (CI-Attribute), die Deine IT-Organisation für die Serviceerbringung benötigt.


Das Schöne an einer guten CMDB ist, dass der Bauplan für Deine Services gleich mit geliefert wird: Die Beziehungen und Abhängigkeiten der einzelnen CIs untereinander werden abgebildet. In Ihrer Gesamtheit bilden sie die Bauanleitung für Deine Services. 


Damit ist die CMDB das Fundament für eine schnelle, sichere, kostengünstige und automatisierte Serviceerbringung.

Robert Sieber unterstützt Unternehmen aus vielen verschiedenen Branchen bei der Definition ihres passgenauen CMDB-Datenmodells, Aufbau und der automatischen Pflege der Konfigurations-Datenbank.

Wie gelingt die Einführung einer CMDB?


Meiner Erfahrung nach lassen sich Configuration-Management-Projekte zum Erfolg führen!

Ich möchte Dir hier einen Weg beschreiben, den ich für sinnvoll erachte. Damit knüpfe ich meinen allerersten Blogpost an. Da schrieb ich, dass viele Projekte mit dem Satz "Wir wollen eine CMDB einführen." starten – das sich dann entspinnende Gespräch, lässt sich im Post nachlesen.

Das "Geheimnis" liegt darin, nicht ein Projekt zur Einführung einer Configuration-Management-Database durchzuführen, sondern den dahinter liegenden Nutzen in den Mittelpunkt zu stellen. Die Konfigurationsdatenbank ist ein Werkzeug. Kein Maurer würde sich eine Kelle kaufen, nur weil er denkt er braucht eine Kelle.

Wie starte ich ein CMDB-Projekt?


Wie bei so vielen Vorhaben im IT-Service-Management, ist auch beim Configuration-Management der erfahrbare Nutzen der CMDB das wichtigste Erfolgskriterium für das CMDB-Projekt und natürlich die Aktualität der CMDB.


Die entscheidende Frage am Anfang: „Welche Fragen soll die CMDB beantworten?“. Eine CMDB soll die alltäglichen Fragen im IT-Betrieb und den Planungsprozessen beantworten. Dazu muss sie über die richtigen Daten und Verbindungen mit entsprechender Aktualität verfügen. Aus den Fragen leiten sich Struktur und Inhalt ab. Der Aufbau erfolgt zielgerichtet. Der Nutzen des Werkzeugs wird so schnell für jeden Mitarbeiter spürbar.

Grafik, die den Nutzen einer CMDB zeigt: Integration von Dateninseln, Unterstützung IT-Betrieb & Prozesse, Planungssicherheit, sicheres Change-Management, erfolgreiches Audits, Risiko-Management, Datenschutz und Informationssicherheit, IT-Kosten, Service-Architektur

Warum brauche ich eine CMDB? Die Daten der CMDB kannst Du in ganzen vielen Szenarien sinnvoll nutzen, um schneller zum Ziel zu kommen.

Die zweite Frage lautet: „Welches Ziel soll mit der Einführung einer CMDB erreicht werden?“ Das Erreichen des Ziels soll für die einzelnen Interessengruppen (Stakeholder) erfahrbar / spürbar ist. Das gelingt nicht immer. Die Ziele sollten dann wenigstens messbar sein. An den Antworten richtet sich das Projekt aus. Die Definition der messbaren bzw. erlebbaren Ziele ist der erste Schritt. Danach wird festgelegt in welchen Stufen dies erreicht werden soll und welche Methoden angewendet werden. Erst dann kann die Konzeptionsphase starten.


Damit Du herausfinden kannst, wo der Nutzen für die Anwender der CMDB in Deinem Unternehmen liegt, kannst Du meinen Fragebogen nutzen. Darin findest Du 19 Fragen, die Dir helfen schnell und unkompliziert die Hauptargumente für eine CMDB und die größten Nutzenpotentiale zu identifizieren. Du kannst Dir den Fragebogen hier kostenfrei herunterladen:

Button, um einen Fragebogen mit 19 Fragen für ein erfolgreiches CMDB-Projekt kostenfrei herunterzuladen

Was ist der Nutzen einer CMDB?


Der wirkliche Nutzen einer CMDB liegt darin, dass sie Fragen beantwortet. Stell Dir die CMDB wie ein Orakel oder eine Glaskugel vor. Du kannst Ihr jede Frage stellen. Ob Sie eine Antwort darauf weiß, hängt davon ab, welche Objekte (CIs), Informationen (Attribute der CIs) und Beziehungen (CI-Relations) Du in Deiner CMDB gespeichert hast.


Das bedeutet, dass es am Anfang des CMDB-Projektes wichtig ist, dass Du und Deine Kollegen Klarheit haben, welche Fragen, die das Configuration Management System im ersten Schritt beantworten soll.


Für die Störungsbearbeitung bzw. Incident-Management habt Ihr vielleicht folgende Fragen:

  • Wer ist der zuständige Administrator?
  • Wie erreiche ich den Support des Herstellers?
  • Welche IT-Dienste sind von der Störung betroffen?
  • Wo finde ich die Disaster-Recovery Anleitung?


Im Änderungs- bzw. Change-Management fragst Du nach ähnlichen, aber auch ganz andere Informationen:


  • Was passiert, wenn wir das Gerät außer Betrieb nehmen?
  • Kann der Change in der geplanten Zeit durchgeführt werden?
  • Wer muss über den Change informiert werden?
  • Welche Störungen oder Probleme werden durch den Change gelöst?


Die Antworten sollen Dir und Deiner IT-Organisation Sicherheit geben. Sie sollen dafür sorgen, dass in Stress- und Planungssituation schnell die richtigen Entscheidungen getroffen werden. Möglich wird dies durch eine, auf die eigene Situation, zugeschnittene CMDB-Struktur. Dazu gehört das individuelle CMDB-Datenmodell oder CMDB-Schema. Dieses enthält:

Infografik zur Verbreitung von CMDB in den Unternehmen

Infografik zur Verbreitung von CMDBs

  • CI-Klassen: die Kategorien in denen die IT- und nicht-IT-Objekte (also Deine CIs) verwaltete werden
  • CI-Attribute: die zugehörigen Attribute für die einzelnen CI-Klassen
  • CI-Relations: Beziehungen zwischen den Kategorien, mit denen Du Abhängigkeiten darstellst


Die meisten CMDB-Tools verfügen in Ihrem logischen CMDB-Modell über die sogenannten CI-Relationship-Types. Damit kannst Du unterschiedliche Beziehungstypen aufbauen. Zum Beispiel: "installiert auf", "nutzt" oder "abhängig von". Häufig kommen auch ganz viele Beziehungstypen vordefiniert in der CMDB-Software mit. Ich persönlich halte gerade am Start einer CMDB dies für überflüssig. Da reicht es in der Regel aus, dass Du kennzeichnen kannst, welches Objekt von welchem abhängig ist. 

Abbildung von beispielhaften Beziehungen eines CI (Server) zu anderen CI-Klassen in der CMDB

Die CMDB liefert die relevanten Informationen zu einem Objekt. Diese ergeben sich aus den Attributen und den Beziehungen zu anderen CI-Klassen.

Was steht im CMDB-Konzept?


Genau diese Struktur - das CMDB-Datenmodell, CMDB-Schema oder CMDB-Metamodell - ist Kern eines Konzepts für den Aufbau einer CMDB oder eines CMS. Um genauer zu sein, es ist der erste Schritt im Konzept.

Ganz wichtig: Es geht darum, dass Du schnell und erfolgreich eine CMDB aufbauen kannst. Deswegen reden wir hier von einer Struktur für den Start sein. Anpassungen im Projektverlauf und im Betrieb sind ganz normal. Sie sind ein Zeichen, dass das Werkzeug auch richtig genutzt wird.


Konzentriere Dich auf die, für Deine Service-Erbringung, relevanten Informationen und Beziehungen. Lieber am Ende Attribute hinzufügen, der schmerzhaft fehlen. Auch muss beim Schema der CMDB der kontinuierliche Verbesserungsprozess ansetzen. Das Schema muss regelmäßig geprüft und angepasst werden.


Das CMDB Datenmodell beruht vor allem auf den Fragen, die zukünftig beantwortet werden sollen. Daraus ergeben sich die Objekte, die verwaltet werden müssen, deren Eigenschaften sowie die Beziehungen zwischen ihnen. Weiterhin hat es sich als nützlich erwiesen die zukünftigen Nutzer zu fragen, in welchen Situationen sie welche Informationen benötigen.

Du kannst Deine Kollegen beispielsweise folgendes fragen:


  • Welche Informationen werden in der Bereitschaft benötigt?
  • Welche Informationen haben gefehlt, um den Ausfall letzte Woche schneller zu beheben / zu vermeiden?
  • Was müssen wir wissen, um Störungen nach Änderungen (Changes) zu vermeiden?


Genau solche einzelnen Szenarien können ein wundervoller kleine Einstieg in ein funktionierendes Configuration Management sein.


Natürlich findest Du in Deinem CMDB-Konzept auch Angaben zur Aktualisierung der CMDB-Daten, der Integration in die ITSM-Prozesse und ganz wichtig: Automatisierung. Diese Punkte sind so wichtig, dass Du dafür weiter unten eigene Kapitel findest.


Die Einführung einer CMDB ist ein klassisches Projekt. Von entscheidender Bedeutung sind die definierten Ziele, die erlebbar oder messbar sein müssen. Es hat sich bewährt diese in einzelne Stufen zu teilen, um nicht lange auf die ersten positiven Effekt zu warten. Die Reihenfolge der dargestellten Schritte kann variieren. Es ist wichtig, mit einem Konzept zu beginnen und dieses im Projekt fortzuschreiben.

Button, um einen Fragebogen mit 19 Fragen für ein erfolgreiches CMDB-Projekt kostenfrei herunterzuladen

Mit Projektabschluss ist nicht Schluss: Ebenso wichtig wie das erfolgreiche Projekt ist die anschließende Aufgabe der Pflege. Nur wenn die Daten aktuell sind und auch das Metamodell an sich verändernde Rahmenbedingungen angepasst wird, kann sich die CMDB als Vertrauenspunkt etablieren und Ihr Potenzial entfalten. Dieser Teil ist nicht zu unterschätzen und sollte so weit sinnvoll automatisiert werden.

Wie gelingt die Pflege der CMDB?


Der nächste, gerade angesprochene, Stolperstein beim Thema CMDB ist die Datenpflege und damit die Aktualität der CMDB-Daten. Selbst wenn es ein schlankes Datenmodell gibt, müssen die Attribute gepflegt werden. Sonst nutzt es nichts. Der Nutzer soll darauf vertrauen können, dass die Daten aktuell und richtig sind. Ansonsten kann ich mich auf die Antwort auf meine Frage nicht verlassen.


Eine essentielle Frage dabei: Werden die Daten, die ich brauche, schon irgendwo anders gepflegt oder automatisiert erhoben?


Um diese Frage zu beantworten, stelle ich zum Start eines jeden CMDB-Projektes 19 Fragen an die Menschen, die die CMDB später nutzen sollen. Diese Fragen und jeweils eine Erklärung warum ich sie stelle, habe ich für Dich zum Download zusammengefasst:

Button, um einen Fragebogen mit 19 Fragen für ein erfolgreiches CMDB-Projekt kostenfrei herunterzuladen

Ohne aktuelle Daten in der CMDB, wird die CMDB keinen Nutzen stiften. Dieses Schicksal hat in der Vergangenheit ganz viele CMDB-Projekte und CMDBs ereilt. Viel zu ambitioniert gestartet, viel zu viele Daten und keiner, der diese pflegen möchte.

Wenn die Daten niemand pflegt, sind die veraltet. Wer feststellt, dass die Daten der CMDB veraltet sind, der hat gar keine Lust, die Daten selbst zu pflegen - ein Teufelskreis.


Das ist gefühlt in jedem Projekt der Knackpunkt: Es wird mit viel Aufwand, Kosten und externen Beratern eine CMDB geboren und nach Abschluss des Projektes, ist es im Prinzip wie vorher. Es hat sich nichts geändert, die Daten veralten mit jedem Tag und kaum einer pflegt sie. Die Ursachen sind vielfältig.  Die Grundlage für das Problem wird schon ganz am Anfang des Projektes gelegt. Folgende Schwerpunkte sehe ich:


  • Sinn erkennen und persönlichen Nutzen erleben
  • Was steht drin und wie kommt es rein?
  • Integration in die ITSM-Prozesse und –Werkzeuge
  • Konsequenz auf der Leitungsebene oder wie wichtig ist es wirklich


Es gibt verschiedene Strategien, um die Aktualität der CMDB sicherzustellen. Diese stelle ich Dir im Folgenden vor. Du kannst Dir meine Vorschläge anhören oder direkt weiter lesen.

Wer ist für die CMDB-Pflege verantwortlich?


Die Frage, warum ich die CMDB pflegen soll, die stellst Du Dir und die stellt sich jeder Deiner Kollegen.

Bewusst oder unbewusst.


Und wie sieht es mit der Deiner Motivation und der Motivation Deiner Kollegen aus?


Du triffst jeden Tag viele Entscheidungen für und noch viel mehr gegen bestimmte Tätigkeiten. Du priorisierst Deine Aufgaben. Auch das passiert bewusst, aber auch unbewusst. Ganz intuitiv erledigst Du erst die Aufgaben, mit denen Du Schmerzen vermeidest – zum Beispiel, um eine Frist einzuhalten – oder die, die für Dich in Zukunft eine Arbeitserleichterung darstellen oder gleich einen Erfolg versprechen.


Und genau das ist der Punkt: Welche Arbeitserleichterung hat der einzelne Mitarbeiter? Was ist der Nutzen für ihn ganz persönlich?


Das ist sicherlich ein ganz schwieriger Punkt. Es ist in wenigen Fällen möglich, das wirklich jeder Mitarbeiter einen persönlichen Nutzen erkennt. Es sollte aber Dein Ziel sein. Denn diese Zielstellung leitet Dich bei der Konzeption, dem Aufbau und verhindert Schlimmeres. 

Was verstehe ich jetzt unter persönlichem Nutzen einer CMDB? Dazu ein paar Beispiele aus meiner Vergangenheit:


1. Beispiel: Bereitschaft


Das Thema Bereitschaft ist häufig ein großer Treiber für die CMDB. Stelle Dir vor Du bist verantwortlich für die Server und wenn Du Bereitschaft hast, musst Du Dich auch um Probleme im Bereich Storage, Netzwerk und Virtualisierung kümmern. Bereiche, in denen Du technisch zwar halbwegs fit bist, aber die konkreten Ausprägungen in der Firma nicht kennst. Wozu auch.


Im Bereitschaftsfall ist es für Dich aber essenziell an die notwendigen Informationen heranzukommen. Beispielsweise den Wartungsvertrag, die Nummer des Servicevertrages oder die IP des Clusterpartners zu kennen.


Wenn das Notwendige in der CMDB steht, dann findest Du es einfach. Und wenn Du Dich darauf verlassen kannst, dass es aktuell ist, dann macht es Dir das Leben leichter. Und: Der Fachadministrator muss nicht erst zusätzlich geweckt werden. Motivation genug?


2. Beispiel: Change-Management


Change-Management – In vielen IT-Organisationen ist es inzwischen so, dass größere Ausfälle im normalen Betrieb selten passieren. Allerdings kommt es nach Änderungen häufig zu Problemen. Du kennst die Herausforderung, alle Abhängigkeiten zu erkunden, die potenziell zu einem Problem werden. Da hier häufig aktuelle Informationen fehlen, kommt es dazu, dass nicht mit allen Beteiligten der Change abgestimmt werden kann und letztlich Probleme entstehen. Das macht zusätzliche Arbeit, Ärger und im schlimmsten Fall muss der Change zurückgebaut werden.


Gleiche Thematik hast Du übrigens auch beim Incident-Management. Wenn Du die Ursache und Auswirkung einer Störung zügig analysieren kannst, kann die Behebung viel schneller starten. Das funktioniert aber nur, wenn die Abhängigkeiten aktuell gepflegt sind.


3. Beispiel: Arbeit vermeiden


Als letztes Beispiel noch die Vermeidung von doppelter oder dreifacher Arbeit. Wenn Du Dir mal Risiko- und Sicherheitsmanagement, Servicekatalog oder Business Continuity anschaust, dann kommst Du immer wieder bei den gleichen Strukturen an. Und vor allem bei den gleichen Elementen, die die Struktur bilden.

Also warum nicht an einer Stelle die notwendigen Informationen pflegen und dafür andere Werkzeuge abschaffen und die entsprechenden Prozesse auf die CMDB aufsetzen.


Das waren drei Beispiele für Deinen persönlichen Nutzen.


Es ist aber auch wichtig, dass jeder Mitarbeiter in der IT den übergeordneten Sinn versteht. Denn, wie schon erwähnt, wirst Du schwerlich für jeden Einzelnen den Sinn herausarbeiten können.

Es muss klar und deutlich sein, warum braucht Deine Organisation die CMDB. Was soll durch den Einsatz besser werden. Welche anderen Tätigkeiten werden dadurch leichter oder fallen weg. Wie merkt der einzelne Mitarbeiter, dass das Ziel erreicht wurde? Also was ist anderes, wenn die CMDB immer aktuell gepflegt ist?


Soll heißen: Es bedarf einer Vision, einer Strategie und eines Planes. Alle drei darfst Du immer und immer wieder verkünden. Wenn Du die Befürchtung hast, dass Du es viel zu häufig erzählst, dann verdopple Deine Anstrengungen. Gerade die Vision ist wichtig.


Denn die CMDB steht nicht für sich allein, sie ist Teil eines größeren Zieles. Oder?

Automatisierte Pflege der CMDB


Egal wie viele oder wie wenig Attribute ein Objekt hat, es wird immer dringendere Aufgabe geben, als diese zu pflegen. Natürlich hilft es da, den Sinn und Nutzen verstanden zu haben, aber ist das genug Motivation?


Da bin ich mir unsicher. 


Deswegen bin ich ein Freund der automatischen Pflege möglichst vieler Attribute.


Eine Discovery-Engine kann da ziemlich nützlich sein. Diese erfasst zumindest die „elektrisch“ auslesbaren Daten. Häufig ist das aber zu wenig. Wer pflegt die Servicevertragsnummer und das Ablaufdatum? Ich habe aktuell ein Projekt, da soll in der CMDB stehen, wer der Warenempfänger war und wie die BANF-Nummer (Bedarfsanforderung) ist. Das erkennt kein Scanner.


Die gute Nachricht ist, dass die Informationen aber schon in Deinem Unternehmen vorhanden und gespeichert sind. Es gibt so viele potenzielle Datentöpfe, die die CMDB pflegen können. Ich danke da an beispielsweise das SAP oder andere Materialwirtschaftssysteme oder an die Verwaltungswerkzeuge der Hard- und Softwarehersteller.


Das kann dann wie folgt aussehen: 


Der HP Insight Manager kann Dir genau sagen, welcher Server welche Seriennummer und welchen Servicevertrag hat. Informationen zum installierten Betriebssystem und Software liefert die Inventarisierungssoftware oder Discoverylösung. Telefonnummer und eMail Adresse der Mitarbeiter findest Du im LDAP, Active Directory oder Telefonbuch Deines Unternehmens.

Alles Datenquellen, die Du für die Pflege der CMDB nutzen darfst. Automatisierung bedeutet weniger Aufwand und vor allem aktuelle Daten. Die Partizipation an bestehenden Pflegeprozessen ist essenziell!


Deswegen ist der zweite Schritt im Konzept die Identifikation der notwendigen Informationen (CI-Attribute) und ihrer Quellen. Diese Erfassung ist die Grundlage für eine Datenintegration und einen regelmäßigen Abgleich der Informationsquellen. 

Abbildung zeigt schematisch wie die verschiedenen Datenquellen integriert werden, um die Aktualität der CMDB sicherzustellen

Die Integration der vielen vorhandenen Datenquellen in der IT und im Unternehmen ist ein Schlüssel zur Aktualität der CMDB-Daten.

Du bedienst Dich über Konnektoren Deiner CMDB-Software oder eine EAI-Lösung (Enterprise Applikation Integration) an den vorhandenen Datentöpfen. Du importierst die Informationen aus System A – zum Beispiels SAP – in die CMDB. Änderungen in der Quelle werden bemerkt und führen zu einer automatischen Änderung in der CMDB. Wie von Zauberhand ist die CMDB sofort wieder aktuell.


Du partizipierst hier nicht nur an den vorhandenen Daten, sondern auch an einem etablierten Pflegeprozess. Doppelte Pflege entfällt und die Fehleranfälligkeit sinkt. Damit steigt die Akzeptanz. Auf diese Art und Weise kannst Du viel manuellen Aufwand in der Pflege sparen, für bessere Datenqualität und eine höhere Akzeptanz sorgen.


Überlege mal, welche potenziellen Datenquellen ist bei Dir im Unternehmen gibt. Oder andersrum, überlege welche Daten Du gern automatisiert gepflegt haben möchtest, und such Dir dann die Datenquelle.

Noch ein kleiner Tipp: Ich binde in fast jedem Projekt das Directory-System an. Dort holen wir die Personendaten wie eMail, Telefonnummer und Abteilungszugehörigkeit raus. Allein das spart schon und sorgt für Akzeptanz.


Damit wird unnötiger Pflegeaufwand vermieden und die Aktualität der Daten gewährleistet. Nur so kann sichergestellt werden, dass die Fragen tatsächlich beantwortet werden können. Mit einer manuellen Pflege wäre der Einsatz einer CMDB in den meisten Fällen wirtschaftlich sinnlos.


Ich bin an diesem Punkt ein ganz klarer Freund von so viel Automatisierung wie möglich. Natürlich unter Beachtung, ob es wirtschaftlich sinnvoll ist. Gerade, wenn es unwirtschaftlich ist, bekommt eine weitere Frage Relevanz: Kann das bisherige System abgelöst und der existente Pflegeprozess auf die CMDB verlagert werden? Oder kann das bisherige System die Daten aus der CMDB beziehen? Es kann nur eine Mutter der Daten geben!

Automatische CMDB-Pflege über ITSM-Prozesse


Wenn wir etwas im IT-Service-Management haben, dann sind es Prozesse. Ganz viele Prozesse, die uns in Sachen CMDB allerdings sehr nützlich werden können.


Das Thema Integration spielt eine sehr große Rolle. Es hört nicht bei den Daten auf, sondern geht mit den Prozessen im Unternehmen weiter. Je mehr Prozesse von den Daten der CMDB profitieren, desto mehr haben Interesse an der Aktualität. Was wiederum einen direkten Einfluss auf die tatsächliche Aktualität und die Betriebskosten hat.


In den ITSM-Prozessen selbst entstehen viele Daten, die Du (möglichst automatisch) zur Pflege verwenden kannst. Zieht beispielsweise ein Server von einem Rack ins nächste, dann ist das eine Information, die gepflegt werden darf. Wenn Deine CMDB und Dein Prozesswerkzeug so miteinander verwoben sind, dass nach Abschluss des Post Implementation Review (PIR) im Change-Management das neue Rack automatisch übernommen wird, dann ist das echt hilfreich. Selbst wenn es jemand manuell macht, steigert es die Datenqualität. Change-Management und Service-Request-Fulfillment sind zwei wundervolle Prozesse, wenn es um die Pflege der CMDB geht.

Darstellung, welche Prozesse alle genutzt werden können, um die Pflege der CMDB zu automatisieren.

Viele Prozesse verarbeiten Daten aus der CMDB. Im Umkehrschluss können diese Informationen durch die Prozesse gepflegt werden. Idealerweise automatisch.

Mithilfe von Service-Requests werden Services bestellt, gekündigt und Parameter des Service verändert. Nimm nur mal die IMAC-Prozesse - alles Service-Request. Dabei geht es um alle Abläufe rund um den Client. IMAC steht für "Install, Move, Add, Change". Dahinter verbergen sich dann die konkreten Abläufe des Client-Managements. Wenn der Nutzer beispielsweise eine neue Software bestellt (Add), dann wird diese installiert. Genau diese Information brauchst Du wahrscheinlich in Deiner CMDB. Dann lass sie doch einfach im Request-Fulfillment-Workflow automatisch in der CMDB pflegen.


Hinter den meisten Service-Request verbergen sich Workflows, die sich immer auf ein ganz konkretes Objekt beziehen. Teil dieser Workflows sollte die automatische Pflege der veränderten Informationen in der CMDB sein. In der Regel kannst Du das mit wenig Aufwand in die bestehenden Workflows integrieren.

CMDB als Datenlieferant


Es gibt eine Vielzahl von Abläufen im Unternehmen, die auf verlässliche Daten angewiesen sind. Sicherheits-, Risiko- und Lizenzmanagement nutzen ähnliche oder gleiche Strukturen wie die IT-Prozesse. Warum sollen die Daten mehrfach in unterschiedlichen Tools gepflegt und gehalten werden?  

CMDB und die ITSM-Tools


Wann immer möglich, sollte ein direkter Zugriff aus dem entsprechenden Managementwerkzeug auf die CMDB realisiert werden. So können die Informationen genutzt werden, ohne kopiert werden zu müssen. Sie sind dadurch immer aktuell in der Arbeitsumgebung der jeweiligen Experten vorhanden. Auch hier gilt es die Wirtschaftlichkeit im Auge zu behalten, aber das Potenzial ist groß.


Der zweite Aspekt ist die Integration von Vorgängen am CI. Ich glaube, folgende Fragen sollte eine CMDB beantworten können:


  • Wie haben wir das letzte Mal gelöst?
  • Welche Störung liegen zu diesem CI vor?
  • Wie oft ist der Fehler schon aufgetreten?
  • Was wurde an dem Server geändert?
Schematische Abbildung, dass viele ITIL-Prozesse im ITSM von den Daten der CMDB profitieren.

Die CMDB ist das Kernelement der Serviceerbringung im ITSM. Das Konzept wird in allen ITSM-Frameworks wie ITIL, FitSM oder YasM genutzt.

Die Verknüpfung der einzelnen Vorgänge mit den Objekten der CMDB ermöglicht dies. Jeder Vorgang sollte einem CI zugeordnet werden. Damit entsteht ein Lebenslauf für jedes Objekt in der CMDB. Das ermöglicht weitergehende Analysen und ist vor allem Basis für ein Problemmanagement.


Das führt zwangsläufig zur Integration von CMDB und IT-Prozesswerkzeug (Tickettool, Service Desk oder wie auch immer das heißt). Ob die CMDB-Implementierung der einzelnen Service-Management-Tools geeignet sind, für das individuelle Vorhaben, sollte kritisch hinterfragt werden. Meiner Meinung nach gibt es da bei vielen Anbietern noch genügend Raum für Verbesserungen.


Bitte sehen Sie die CMDB-Einführung als ein Projekt mit mehreren Stufen. Suchen Sie sich für den Anfang schnelle Erfolge und etablieren Sie frühzeitig die kontinuierliche Verbesserung. Planen Sie am Anfang grob, um zu wissen, wo die Reise hingehen soll. Planen Sie im Detail jede Stufe einzeln. Arbeiten Sie in kleinen Iterationen und vor allem holen Sie sich früh und immer wieder das Feedback der verschiedenen Interessengruppen.

CMDB und andere Tools


Integration der CMDB geht noch weiter. Auch andere Werkzeuge im Betrieb, der Planung oder des Kundenmanagements können von den Daten profitieren.


1. Beispiel: Monitoring


Denk mal an das Monitoring. Wenn wir jetzt davon ausgehen, dass ein neuer Server zuerst in der CMDB auftaucht und dort drin steht, dass es ein HP DL380 ist, auf dem Windows Server 2012 und Microsoft Exchange installiert ist, was spricht dagegen aus diesen Informationen das Monitoring automatisch zu konfigurieren?


Alle notwendigen Informationen sind bekannt. Über ein Skript kann die, hoffentlich vorhandene, API Deines Monitoringsystems genau mit diesen Informationen versorgt werden. Vorteil: Niemand vergisst mehr das Monitoring zu konfigurieren.

Die Alarmierung wird natürlich auch gleich eingerichtet, da die CMDB ja die verantwortlichen Administratoren kennt.


2. Beispiel: Abrechnung


Abrechnung von Leistungen: In der CMDB ist bekannt welcher Kunde welche Services nutzt. Das CRM System weiß, in welchen Einheiten zu welchen Preisen die Services verkauft wurden. Das Monitoringsystem kennt die SLA-Verletzungen. In einer integrierten Landschaft entsteht am Monatsende daraus die Rechnung und die SLA-Reports für den Kunden – völlig automatisch.


Du darfst im Laufe eines CMDB-Projektes darüber nachdenken, welche Werkzeuge miteinander verknüpft werden können. Automatisierung ist ein essentieller Faktor für die Arbeitserleichterung und die Qualitätssicherung. 

Servicesicht in der CMDB


Am Ende des Konzeptes steht die Modellierung der Services: Die Abbildung der Abhängigkeiten der Objekte zu konkreten Dienstleistungen der IT-Abteilung. Dazu gehört die Anreicherung mit notwendigen Daten: Nutzer, Servicelevel oder verantwortliche Mitarbeiter. Auch hier geht es darum, so schnell wie möglich Fragen zu beantworten:


  • Welche Auswirkung und Ursache hat eine Störung?
  • Wer muss informiert werden?
  • Wer muss dem Change zustimmen?

Mit der Konzentration auf das wirklich notwendige sind alle Informationen für den Betrieb vorhanden. Damit werden schneller die richtigen Entscheidungen getroffen.

Modellierung eines Service in der CMDB, ausgehend von den Prozesse des Unternehmens

Modellierung eines Service in der CMDB, ausgehend von den Prozesse des Unternehmens

Wie Du der Grafik entnehmen kannst, werden die Dienste in der Sprache der Anwender / Nutzer definiert – sogenannte Business Services. Die IT muss aus der Kostenstellenecke (siehe Kernaufgabe der IT) raus. Es muss für jeden klar ersichtlich sein, welche Prozesse und Funktionen wie von der IT abhängig sind. Somit ist die Analyse von Auswirkung und Ursache bis und vom Prozess aus möglich. Was lässt sich damit erreichen?


Bessere Kommunikation: Heute können aufgrund eines Softwareupdates keine Rechnungen gedruckt werden. Klingt besser als: Heute Druckserver z5698 im SAP Mandanten Fibu nicht verfügbar. Die Nutzer haben sofort eine Relation zu Ihrer Arbeit und können es für sich einordnen. Ergebnis ist eine höhere Nutzerzufriedenheit und weniger Tickets sowie Eskalationen.


Sicheres Changemanagement: Lässt sich die Auswirkung einer Änderung bis hin zum Geschäftsprozess verfolgen, so ist einmal klar, welche Stakeholder beteiligt werden müssen. Auf der anderen Seite ist es einfacher zu entscheiden, ob ein Change durchgeführt werden kann oder nicht. Beispielsweise ist es keine gute Idee, eine Applikation am Monatsanfang zu aktualisieren, wenn sie für den Dienst “Kostenrechnung” benötigt wird.


SLA-Vereinbarung:  Fragst Du einen Geschäftsführer nach der geforderten Verfügbarkeit eines Druckservers, so wird er nach kurzer Überlegung sagen: “Immer” – mit einer Maximalforderung kann er auf den ersten Blick nichts falsch machen. Fragst Du ihn aber, wie lange die Firma auf das “Drucken von Rechnungen” verzichten kann, so wird er eine realistische Antwort abgeben – vielleicht: “Eine Woche”. Zwischen diesen beiden Angaben liegen im Projekt und im Betrieb mehrere 0en Kosten. Mit der zweiten Frage sprichst Du ihn auf seiner Ebene an. Die Frage kann er realistisch einschätzen und beantworten.


Weitere Prozesse: Risikomanagement, Sicherheitsmanagement und andere nicht-IT-Prozesse brauchen die gleichen Daten in ähnlicher Form. Es profitieren viele Prozesse / Aufgaben im Unternehmen von der CMDB, wenn diese als Werkzeug verstanden und genutzt wird. Damit kann die CMDB ein wichtiger Erfolgsfaktor bei Änderungen / Anpassung des Geschäftsmodells oder der Prozesse sein. Entsprechend der Abbildung der Services ist einfach zu identifizieren, welche Änderungen wo notwendig sind.

Fazit


Die Einführung einer CMDB ist ein klassisches Projekt. Von entscheidender Bedeutung sind die definierten Ziele, die erlebbar oder messbar sein müssen. Es hat sich bewährt diese in einzelne Stufen zu teilen, um nicht lange auf die ersten positiven Effekt zu warten. Die Reihenfolge der dargestellten Schritte kann variieren. Es ist wichtig, mit einem Konzept zu beginnen und dieses im Projekt fortzuschreiben.

Button, um einen Fragebogen mit 19 Fragen für ein erfolgreiches CMDB-Projekt kostenfrei herunterzuladen

Mit Projektabschluss ist nicht Schluss: Ebenso wichtig wie das erfolgreiche Projekt ist die anschließende Aufgabe der Pflege. Nur wenn die Daten aktuell sind und auch das Metamodell an sich verändernde Rahmenbedingungen angepasst wird, kann sich die CMDB als Vertrauenspunkt etablieren und Ihr Potenzial entfalten. Dieser Teil ist nicht zu unterschätzen und sollte so weit sinnvoll automatisiert werden.

Wichtige Begriffe rund um die CMDB


Service-Configuration-Management

Ich habe ganz viel über die Identifikation von CIs und die Pflege der CMDB gesprochen, ohne das Wort Configuration-Management (ITIL v2), Service-Asset- and Configuration-Management (ITIL v3) oder Service-Configuration-Management (ITIL4) in den Mund zu nehmen. Das hätte ich wohl tun soll, oder?


Alles das, was ich bisher geschrieben habe, ist Configuration-Management: Configuration Management dokumentiert und administriert alle Configuration-Items und deren Beziehungen untereinander. Es besteht aus drei Teilprozessen:

  • Configuration-Identifizierung 
  • Configuration-Steuerung 
  • Configuration-Verifizierung und -Audit

Die Pflege der CMDB und damit das Configuration Management ist für mich Aufgabe eines jeden Mitarbeiters der IT. Die Verantwortung, ob alle CIs ordentlich in der CMDB vorhanden und gepflegt sind, gehört für mich in die Hände des Service-Owners. Wer, wenn nicht er und sein Service-Team haben das Wissen und die Motivation, die servicerelevanten CIs zu pflegen?

CMS - Configuration Management System

Die CMDB bekam in ITIL v3 einen neuen Namen: CMS - Configuration-Management-System. Neben dem neuen Namen wurde das Konzept CMDB in ITIL v3 überarbeitet und an die Realität angepasst:


Mit ITIL v2 ist wohl der Eindruck entstanden, dass alle Daten unbedingt in dieser einen einzigen physischen Datenbank gehalten werden müssen.


Die ITIL v3 CMDB ist als Datendrehscheibe konzipiert: Unterschiedlichste Quellen liefern Ihre Objekte, Informationen und Relationen zu. Dadurch entsteht eine konsolidierte Sicht auf alle Configuration-Items (CIs). 


Das sogenannte CMS ist nun keine Datenbank, sondern ein logisches Konstrukt aus vielen Datenquellen, die in der CMDB-Software zu einem Gesamtbild zusammengesetzt werden.


Diese Bild kommt der Realität wesentlich näher, als das was in vielen Unternehmen aus dem Konzept CMDB umgesetzt wurde.

CMDB-Software & CMDB-Tools

Möchtest Du eine CMDB aufbauen, dann brauchst Du ein Tool dafür! Configuration-Management ist eine Disziplin, bei der Du ohne Tool nicht weit kommst.

Die gute Nachricht ist, dass die meisten ITSM-Tools eine CMDB-Funktionalität eingebaut haben. Der Funktionsumfang der einzelnen Tools unterscheidet sehr. Du solltest bei der Auswahl einer CMDB Software auf folgendes achten:

  • Lässt sich das CMDB-Schema oder CMDB-Datenmodell anpassen? Dabei geht es um die CI-Klassen, CI-Attribute und CI-Relationen?

  • Welche Möglichkeiten der Datenintegration bietet die Software? Wie einfach ist es, externe Datenquellen anzubinden?

  • Verfügt die Software über eine eigene Lösung für das Discovery oder gibt es vorgefertigte Integrationen zu Lösungen von Drittanbietern?

  • Ist die Software in der Lage, die Strukturen der CMDB gut zu visualisieren, sodass ein Servicebaum auch über fünf oder sechs Ebenen noch brauchbar dargestellt wird?

  • Bietet das Tool die Möglichkeit die Abhängigkeiten (grafisch) zu analysieren? Ich denke an Root-Cause- und Business-Impact-Analyse?

Neben den Lösungen, die in ITSM-Tools integriert sind, gibt es CMDB-Software, die sich genau auf diesen Teil spezialisiert hat. Diese musst Du dann in Dein ITSM-Tool integrieren.

Des Weiteren gibt es viele unterschiedliche Lösungen für die Inventarisierung und das Discovery auf dem Markt, mit deren Hilfe Du die Aktualität und Qualität Deiner Daten erhöhen kannst.

Unterschied Asset und CI

Beschäftigst Du Dich mit dem Configuration-Management, dann kommt das Thema Asset-Management meist gleich mit auf den Tisch. 


Die Begriffe “Asset” und “CI” darfst Du getrennt verstehen. Ein CI ist in der Hoheit des IT-Betriebs und wird mit betriebsrelevanten Informationen und Attributergänzungen “erläutert”. 


Ein Asset wird i.d.R. kaufmännisch gesehen und mit finanziellen-monetären Attributen beschrieben und liegt in der Verantwortung der Anlagebuchhaltung oder des Controllings. 


Gerade, wenn es um die Themen IT-Kosten, interne Verrechnung und Financial-Management der IT geht, liegt es nahe, die beiden Disziplinen zu vermischen. Allerdings zeigt sich in der Praxis, dass die Ziele, die jeweils im Configuration- und Asset-Management erreicht werden sollen, dazu führen, dass die gleichen Objekte völlig unterschiedlich verwaltet werden.


Deswegen darfst Du die IT- und die kaufmännische Sicht trennen. Es muss festgelegt sein, für welche Attribute wer die Pflegehoheit hat und wo dieses führend gespeichert wird.

Danach kannst Du im Sinn des CMS diese verschiedenen Datenquellen wieder zu einer konsolidierten Sicht in Deiner CMDB-Software zusammenführen.


ITIL4 trägt dieser Sichtweise Rechnung und kennt zwei Praktiken: Asset-Management und Service-Configuration-Management.

CMDB in ITIL4

ITIL4 kennt die Praktik Service-Configuration-Management. Die CMDB ist nach wie vor das Daten-Fundament jeder Serviceerbringung. ITIL4 kennt beide Begriffe: CMDB und CMS


Definition CMS: "Ein Set von Werkzeugen, Daten und Informationen, die zur Unterstützung der Praktik des Servicekonfigurationsmanagements verwendet werden."


Definition CMDB: "Eine Datenbank, in der Konfigurationsdatensätze während ihres Lebenszyklus gespeichert werden. Sie verwaltet auch die Beziehungen zwischen den Konfigurationsdatensätzen." 


Besonders schön finde ich, dass die Praktik Service-Configuration-Management heißt. Da wird sofort klar, worum es geht.

CMDB Jump-Start Workshop


Dein sicherer Weg zu einer funktionierenden und qualitativ hochwertigen CMDB

Im Rahmen dieses Workshops legen wir gemeinsam die Grundlage für eine zuverlässige CMDB mit hoher Datenqualität, die alle Informationen aktuell enthält und minimalen Pflegeaufwand bedeutet. Folgende Punkte werden wir gemeinsam klären:

  • Wir klären, welche Fragen Deine CMDB beantworten soll.
  • Wir leiten davon die notwendigen CI-Klassen, CI-Attribute und CI-Beziehungen ab.
  • Wir definieren das CMDB-Schema für Deine CMDB.
  • Wir identifizieren die Datenquellen, die notwendige Daten zuliefern können.
  • Wir identifizieren die Systeme, die Du durch die CMDB ersetzen kannst.
  • Wir definieren die notwendigen Prozesse und Regeln für ein zuverlässiges Konfiguration-Management.
  • Wir definieren einen Stufenplan, sodass Deine CMDB schnell einen Nutzen liefert.

Das Ergebnis ist ein umfassender und sorgfältig ausgearbeitet Plan für den Aufbau Deiner CMDB. Damit steht dann einer nachhaltigen CMDB-Einführung nichts mehr im Wege. Das gleiche Vorgehen können wir für die Renovierung einer bestehenden CMDB anwenden.


Das Vorgehen vermeidet, dass Du die typischen Fehler in CMDB-Projekten machst. Du verhinderst, dass aus Deinem CMDB-Projekt ein Asset-Management-Projekt wird, welches Du nach drei Jahren ohne nennenswerten Erfolg einstampfst.

Der CMDB Jump-Start sichert Dir ein praxiserprobtes Vorgehen und eine zuverlässige Basis für das Datenfundament Deines Service-Managements.

Jetzt kostenfreies Erstgespräch vereinbaren

Wenn Du eine gut strukturierte und vor allem nützliche CMDB aufbauen möchtest, dann vereinbare jetzt ein kostenfreies Erstgespräch:

zum Seitenanfang