30.11.2017 Versäumnisse wiegen schwer

CMDB-Leitfaden: Zielsichere Einführung

Von: Stephan Witt, Martin Landis

Ein aktueller Praxisleitfaden zeigt auf, wie die Verantwortlichen eine erfolgreiche ­Einführung von Configuration Management Databases (CMDB) vornehmen können.

Besser ist immer ein kleineres Projekt mit klar definierten Zielen.

Viele starten nach dem Motto „Wir integrieren alles“. Besser ist aber ein kleineres Projekt mit klar definierten Zielen.

Das Wissen über vorhandene IT-Infrastrukturen und deren Beziehungen zum Geschäft wird immer wichtiger und ist mittlerweile eine Grundvoraussetzung für viele unternehmensrelevante Entscheidungen und Investitionen. Die Configuration Management Database (CMDB) übernimmt dabei die Aufgabe, dieses Wissen bereitzustellen. In der Praxis erreichen aber viele CMDB-Projekte ihr Ziel nicht, wie ein gemeinsamer Leitfaden von der Usu AG und dem Beratungshaus E:ndlich OHG aus Fürth aufzeigt. Daher sollten die Verantwortlichen die Herausforderungen und Stolpersteine im Blick behalten und einige praxisorientierte Tipps zur erfolgreichen Einführung beherzigen.

Zunächst bildet ein gut definierter Prozess die Basis: Die Definition des auf das Unternehmen angepassten Configuration-Management-Prozesses ist eine wichtige Voraussetzung für den Projekterfolg. Versäumnisse und Unklarheiten wiegen schwer. So können in der Planungsphase (Configuration Planning) häufig die folgenden Fehler beobachtet werden:

  • Keine gemeinsame Vision: Zuerst wird das CMDB-Tool beschafft, alles andere soll dann erst im Verlauf des Projekts definiert werden.
  • Zu großer Umfang: Viele starten nach dem Motto „Wir integrieren alles“. Besser ist aber ein kleineres Projekt mit klar definierten Zielen.
  • Wichtige IT-Service-Management-Prozesse (ITSM) werden nicht einbezogen: Eine CMDB alleine hat keinen Nutzen. Dieser entsteht erst durch die Integration von angrenzenden ITSM-Prozessen wie z.B. dem Change- und Release Management.
  • Unklare Rollenverteilung und Prozessschnittstellen: Oft sind diese Punkte vor der Implementierung nicht abschließend geklärt.
  • Fehlender Geschäftsbezug: Die Planung und Priorisierung der Inhalte einer CMDB vollziehen sich nicht nach der Top-down-Methode und häufig erfolgt keine Konzentration auf die geschäftskritischen Elemente.

Nicht in Details verlieren


Darüber hinaus können in der Identifikationsphase, der sogenannten Configuration Identification, bestimmte Probleme das Erreichen des Projektziels erschweren. So existiert oftmals ein unterschiedliches Verständnis von Begrifflichkeiten. Dabei sind Services, Applikationen und Software keine synonymen Begriffe, sondern verschiedene „Configuration Items“ (CI). Desweiteren können zu viele tiefergehende Details das Projekt ausbremsen, denn insbesondere bei den Attributen wird oft jede noch so unwichtige Nuance in die CMDB geführt. Auch ist die Configuration-Items-Pflege zu Attributen nicht vollständig geregelt. Von daher sollte man Fragen klären, wie: „Wird ein technisches Attribut, wie z.B. die CPU, automatisiert oder manuell gepflegt?“

In der anschließenden Kontrollphase (Configuration Identification) können folgende Stolpersteine den Erfolg gefährden:

  • Pflege der CMDB-Daten wird einem dedizierten „Pflegeteam“ übertragen: Dieses Team ist aber häufig gar nicht in den Change-Prozess involviert. Daher sollte man eher prozessorientiert denken.
  • Mangelhafte Datenqualität: Als Resultat geht das Vertrauen der Nutzer verloren.
  • Keine Dokumentationsrichtlinien: Richtlinien fehlen wie z.B. Voraussetzung zur CI-Dokumentation, welche Attribute gepflegt werden müssen, Nomenklatur etc.
  • Kontrollmechanismen zu spät eingeführt: Planen Sie Verifikations- und Kontrollmechanismen bereits vor der Erstbefüllung der CMDB.

In der Reporting-Phase (Configura­tion Status Accounting & Reporting) wird häufig der Aufwand unterschätzt. So sind sich viele Verantwortlichen der hohen Komplexität nicht bewusst. Denn regelmäßige Berichte und Dashboard-Ansichten müssen zielgruppenspezifisch erstellt werden. Diese Komplexität führt oft zu teuren CMDB-Customizing-Projekten oder dem Einsatz eines zusätzlichen Reporting-Tools. Darüber hinaus sollte der generelle Aufwand nicht unterschätzt werden. Denn im Lauf des Projekts werden aus den angrenzenden ITIL-Disziplinen viele Reporting-Anforderungen an das Configuration Management gestellt werden.

In der Verifizierungsphase (Configuration Verification & Audit) wird häufig der Aufwand für Audits gescheut und diese werden daher zu selten durchgeführt. Mit dem passenden Tool kann jedoch der Erfolg eintreten. Noch individueller als der Prozess hängt die Auswahl des passenden Tools allerdings vom erwarteten Nutzen und den gesetzten Zielen ab. Von daher sollte man auf die Flexibilität achten. Dies bedeutet, dass das Tool ein flexibles Datenmodell anbieten sollte. CI-Klassen, -Subklassen, CIs und deren Attribute sollten einfach modifizierbar sein. Daneben ist die Visualisierung der CIs und deren Abhängigkeiten wichtig. Sie macht Strukturen leichter verständlich und unterstützt bei Impact- und Root-Cause-Analysen.

Wichtige Datenintegration


Es ist nicht effizient, sämtliche Konfigurationsdaten aus diversen Werkzeugen in einer zentralen CMDB mit einem einheitlichen Datenmodell zu verwalten. Viel effizienter ist es, Daten dort zu belassen, wo sie entstehen. So sollte das Tool die „Föderierung“, also das Laden weiterer CI-Informationen aus externen Quellen, unterstützen. Zur initialen Befüllung und für einen Soll-Ist-Abgleich müssen Discovery-Tools angeschlossen werden können. Das Auftauchen derselben CIs in mehreren Datenquellen (z.B. beim Einsatz mehrerer Discovery-Tools) erfordert zum Datenabgleich eine „Reconciliation“-Funktion. Schließlich geht es um das Reporting. Dabei benötigen unterschiedliche Benutzergruppen verschiedene Reports und Dashboards, sodass das CMDB-Tool alle Zielgruppen unterstützen muss.

Dies ist ein Artikel aus unserer Print-Ausgabe 11/2017. Bestellen Sie ein kostenfreies Probe-Abo.

Vor diesem Hintergrund ist es ratsam, beim Aufbau einer CMDB klein anzufangen. Die Verantwortlichen sollten klare, abgegrenzte Ziele setzen, den Top-down-Ansatz wählen und auf Qualität achten. So werden schnell erste Erfolge sichtbar und man ist auf weitere Iterationen vorbereitet. Desweiteren sollte man das CMDB-Projekt niemals als Stand-alone-Projekt führen, denn das Configuration Management und die CMDB sind auf die Unterstützung der umliegenden Prozesse, insbesondere bei der CI-Pflege, angewiesen. Zwar existieren keine Out-of-the-Box-CMDB-Lösungen für alle Kunden, dennoch sollte man das Rad nicht komplett neu erfinden. Auf dem Markt gibt es zahlreiche Tools, mit denen Unternehmen schnell produktiv sein können.

Bildquelle: Thinkstock/iStock

©2017 Alle Rechte bei MEDIENHAUS Verlag GmbH