Zehn Erfolgsfaktoren für CMDB-Projekte
Obwohl in vielen Unternehmen der Einführung einer Configuration Management Database eine große Bedeutung beigemessen wird, sind viele solcher Projekte zum Scheitern verurteilt: Sei es, weil vorab keine klaren Zielsetzungen und Verantwortlichkeiten definiert wurden oder weil das Configuration Management sich in zu granularen Datenstrukturen verliert. Unser Fachartikel erklärt, wie Sie solche Stolpersteine aus dem Weg räumen und nennt zehn Erfolgsfaktoren, die für CMDB-Projekte entscheidend sind.
Ein Großteil der in Unternehmen auftretenden Downtimes ist auf Probleme zurückzuführen, die durch Konfigurationsänderungen in der Infrastrukturlandschaft verursacht werden. Ein entscheidender Erfolgsfaktor zur Sicherstellung einer hohen Servicequalität ist vor diesem Hintergrund die Configuration Management Database (CMDB). Die Datenbank bildet einen genauen und vollständigen Bestand der Configuration Items (CIs) im Unternehmen sowie ihre Attribute und Beziehungen untereinander ab – und zwar mit allen historischen Ständen während ihres gesamten Lebenszyklus.
Durch ihren Einsatz werden die Auswirkungen von Konfigurationsänderungen an der IT-Infrastruktur schon im Vorfeld transparent. Auch der Tatsache, dass die CMDB als einheitliche Datenbasis die Grundlage für effiziente, ITIL-basierte Prozesse und eine Senkung der IT-Kosten liefert, sind sich heute die meisten Unternehmen bewusst. Dennoch haben viele von ihnen nach wie vor keine CMDB im Einsatz. Oder die Einführung war von Schwierigkeiten begleitet. Nicht wenige Organisationen unternehmen aktuell bereits den zweiten Versuch, eine CMDB erfolgreich einzuführen. Hier die zehn wichtigsten Erfolgsfaktoren, damit solche Projekte nicht (wieder) aus dem Ruder laufen:
1. Räumen Sie falsche Annahmen von vornherein aus
Häufig herrschen schon vor der Umsetzung von CMDB-Projekten völlig falsche Erwartungen und Annahmen: Kommen Ihnen Sätze wie "Das Configuration Management ist für die Pflege der Daten verantwortlich" oder "Wir brauchen keine manuelle Pflege in der CMDB – dafür haben wir automatisierte Tools!" bekannt vor? Dann sorgen Sie am besten gleich bei allen Beteiligten für Klarheit und stellen Sie die Verantwortlichkeiten und Zusammenhänge dar – sonst werden Sie später dafür verantwortlich gemacht, wenn Ihr CMDB-Projekt diese Erwartungen nicht erfüllt.
2. Halten Sie sich an die etablierten Schritte des Configuration Management Prozesses
Der Configuration Management Prozess regelt die Bereitstellung aktueller und gesicherter Informationen über die IT-Infrastruktur und deren Beziehungen zueinander in Form der CMDB. Die hierfür erforderlichen Daten werden über bestimmte Schnittstellen zugeliefert. Im Einzelnen gliedert sich der Configuration Management Prozess in 5 Schritte, die Sie auf jeden Fall in dieser Reihenfolge durchlaufen sollten:
In der Planungsphase definieren Sie die Ziele, der Umfang sowie die Prioritäten des Prozesses. Oberstes Ziel dabei: Ihre ITSM-Prozesspartner sollen die gewünschten Daten möglichst schnell und mit möglichst geringem Aufwand finden. Im Rahmen der Identifizierung des Informationsbedarfes erweitern, bewerten und prüfen Sie die Anforderungen der angrenzenden Prozesse. In dieser Phase legen Sie die Strukturen fest, die später in der CMDB angelegt werden: In welche eindeutig identifizierbaren Elemente (CIs) wird die Konfiguration der IT-Infrastruktur aufgeteilt? Welche CI-Klassen gibt es und wo werden diese in der CMDB-Struktur abgelegt? Welche Attribute haben die CIs?
Die darauffolgende Phase Steuerung beschäftigt sich mit der Frage, wie die relevanten Daten in die CMDB hineingelangen, richtig in den vorgegebenen Strukturen abgelegt werden und wie die Prozesse, die CIs anliefern oder verändern, sauber auf die Datenstrukturen zugreifen können. Über periodisch durchgeführte Statusberichte erhalten die beteiligten Prozessverantwortlichen ohne viel Aufwand Zugang zu den für sie relevanten Daten.
Der letzte Prozessschritt Konfigurationsverifizierung und Audits dient dazu, sicherzustellen, dass allen Prozessen hundertprozentig zuverlässige und korrekte Daten zur Verfügung gestellt werden. Konkret prüfen Sie an dieser Stelle, ob die vorgegebenen Datenstrukturen auch wirklich so gefüllt sind, wie sie gefüllt sein sollen, und ob die tatsächlich verwendeten CIs mit den Daten in der CMDB übereinstimmen.
3. Definieren Sie eindeutige Rollen und Verantwortlichkeiten
Folgende Rollen haben sich in zahlreichen CMDB-Projekten für eine optimale Prozesssteuerung bewährt:
- Der Configuration Librarian legt die Datenstruktur in der CMDB fest und fordert diese beim Configuration Manager an. Je nach Unternehmensgröße können eine oder mehrere Personen diese Rolle ausüben.
- Der Configuration Manager vertritt die verschiedenen Parteien – sprich: Fachbereiche und ITSM-Prozesspartner –, die Anforderungen an die CMDB stellen. Für diese Anforderungen, zum Beispiel Anforderungen des Unix-Serverbetriebs an das CMDB-Datenmodell zur Verwaltung von Servern sowie zur Verknüpfung von Incidents und Changes, vereinbart er mit dem Configuration Librarian die entsprechenden Strukturen. Ein Configuration Manager vertritt in der Regel ein bis zwei Fachbereiche oder Technologien und bringt für diese das fachliche Verständnis mit, das dem Configuration Librarian oft fehlt.
- Die Configuration Owner tragen die Verantwortung dafür, dass die Daten für bestimmte CIs in der CMDB richtig und aktuell gepflegt sind. Sie sind etwa beim Auftreten einer Störung, die eines ihrer CIs betrifft, zu informieren.
- Der Configuration Auditor bereitet regelmäßig Reports vor, anhand derer im Rahmen von Audits überprüft werden kann, ob die tatsächlich verwendeten CIs mit den Daten in der CMDB übereinstimmen.
4. Verwenden Sie ein hierarchisches Modell für Ihre Datenstruktur
In der Praxis hat sich der Ansatz bewährt, die Datenstruktur in der CMDB hierarchisch aufzubauen. Sie beginnen ganz oben mit dem CI. Anschließend folgen die Superklassen, zum Beispiel Server, Clients, Business-Applikationen, Middleware-Software, Netzwerk et cetera als oberste Einstiegspunkte. Konkret wird es dann in den Unter- und Instanzklassen, in denen unter anderem Unix-Server, Windows-Server, Oracle-Datenbanksysteme dokumentiert werden. Die Modellierung sollte dabei möglichst herstellerunabhängig erfolgen.
Es empfiehlt sich, sich schon vor dem Aufbau der Datenstruktur Gedanken darüber zu machen, wie die Prozesse später die Datenstruktur nutzen werden, um an die gewünschten Informationen zu gelangen. Wenn beispielsweise das Change Management eine Unterscheidung der Server in Unix und Windows vorsieht und zusätzlich noch eine Unterteilung in eine 32 und 64 Bit-CPU-Architektur benötigt, sollte die Datenstruktur auch entsprechend angeboten werden. Die Granularität des Datenmodells sollten Sie dabei so ausrichten, dass das Configuration Management und die beteiligten Prozesse optimal bei ihrer täglichen Arbeit unterstützt werden. Wird etwa auf bestimmte, manuell gepflegte Attribute nur sehr selten zugegriffen, ist deren Relevanz für die CMDB zu hinterfragen.
Seite 1 von 2 Nächste Seite>>
Sabrina Hahn, Online-Marketing bei der matrix technology AG/ln