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.
Eine CMDB ist das Datenfundament für das IT-Management. Die Datenbank umfasst alle Betriebsmittel der IT (Configuration Item - CI) und deren Beziehungen. Die Verwaltung der Configuration Management Database erfolgt im Configuration Management.
Meine persönliche Definition ist greifbarer. Damit Du eine konkrete Verstellung bekommst, darfst Du Dir CMDBs wie Legokisten vorstellen: Dort drin findest Du alle Bausteine, die Du brauchst, um Deine Services zusammenzubauen. Die Bausteine bezeichnen wir als CIs (Configuration-Items). Der Bauplan für Deine Services wird Dir gleich mitgeliefert:
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 Komponenten 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.
Die CMDB Definition aus ITIL4 lautet: "Eine Datenbank, in der Konfigurationsdatensätze während ihres Lebenszyklus gespeichert werden. Sie verwaltet auch die Beziehungen zwischen den Konfigurationsdatensätzen."
FitSM definiert die Datenbank wie folgt: "Speicherort für Daten über Configuration Items (CIs)" - mit dem Hinweis: "Eine CMDB ist nicht notwendigerweise eine einzelne Datenbank, die alle CIs abdeckt. Sie kann vielmehr aus mehreren physischen Datenspeichern zusammengesetzt sein." (aus FitSM-0)
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 bei so vielen Vorhaben im IT-Service-Management ist auch im Configuration-Management der erfahrbare Nutzen der CMDB das wichtigste Erfolgskriterium für das Einführungsprojekt und natürlich für die Aktualität der Datenquelle. Nur wenn Du und Deine Kollegen kontinuierliche einen Nutzen aus der Configuration-Management-Database ziehen, wird sie auch gepflegt werden.
Zu wenig Nutzen >> keine Pflege!
Das ist der Grundgedanke für die Planung des Vorhabens. Dokumentation der IT darf keine reine Pflichtaufgabe sein. Der Zugriff auf eine aktuelle Datenquelle für die Infrastruktur, Anwendungen und Services ist der spürbare Vorteil von CMDBs. Egal ob für die Planung oder eine schnelle Auskunft.
Die entscheidende Frage am Anfang Deines Vorhabens: „Welche Fragen sollen beantworten werden?“. 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 zu beantwortenden Fragen leiten sich Struktur und Inhalt ab. Der Aufbau erfolgt zielgerichtet. Der Nutzen des Werkzeugs wird so schnell für jeden Mitarbeiter spürbar.
Was hat Deine IT-Organisation von dem ganzen Aufwand? Die Informationen kannst Du in ganzen vielen Szenarien sinnvoll nutzen, um schneller zum Ziel zu kommen.
Die zweite Frage lautet: „Welche Ziele sollen mit der Einführung einer CMDB erreicht werden?“ Das Erreichen dieser Ziele darf für die einzelnen Interessengruppen (Stakeholder) erfahrbar oder spürbar sein. Jeder muss merken, dass mit dem Werkzeug etwas anders ist, schneller geht, weniger Probleme bereitet oder überhaupt erst möglich wird. Das motiviert die Menschen am meisten, sich zu beteiligen. Wenn Du die Zielerreichung messen kannst, dann umso besser.
Wenn es solche spürbare Ergebnisse nicht gibt, dann überlege bitte, ob Du Deine Zeit in die richtige Sache investiert.
An den Antworten auf diese Frage richtet sich das Projekt aus: Die Definition der messbaren bzw. erlebbaren Ziele ist der erste Schritt. Danach legst Du fest, 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 und die größten Nutzenpotentiale zu identifizieren. Du kannst Dir den Fragebogen hier kostenfrei herunterladen:
Der wirkliche Nutzen einer CMDB liegt darin, dass sie Fragen beantwortet. Stell sie Dir wie ein Orakel oder eine Glaskugel vor. Du kannst Ihr jede Frage zur Konfiguration Deiner Services stellen. Ob Sie eine Antwort darauf weiß, hängt davon ab, welche Objekte (CIs), Informationen (Eigenschaften der CIs) und Beziehungen (CI-Relations) Du gespeichert hast.
Ob die Antwort brauchbar und verlässlich ist, hängt von der Aktualität ab.
Das bedeutet, dass es am Anfang 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. das Incident-Management habt Ihr vielleicht folgende Fragen zu den Konfigurationselementen der Infrastruktur, Servern oder Anwendungen:
Im Änderungs- bzw. Change-Management fragst Du nach ähnlichen, aber auch ganz andere Informationen:
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
Die meisten CMDB-Tools verfügen in Ihrem logischen 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 Software mit. Ich persönlich halte diese verschiedenen Beziehungstypen gerade am Anfang für überflüssig. Da reicht es in der Regel aus, dass Du kennzeichnen kannst, welches Objekt von welchem abhängig ist.
Die CMDB liefert die relevanten Informationen zu einem Objekt. Diese ergeben sich aus den Attributen und den Beziehungen zu anderen CI-Klassen.
Genau diese Struktur - das CMDB-Datenmodell, -Schema oder -Metamodell - ist Kern eines Konzepts für den Aufbau des Configuration-Management-System (CMS). Um genauer zu sein, es ist der erste Schritt im Konzept.
Ganz wichtig: Es geht darum, dass Du schnell und erfolgreich eine Configuation-Management-Database 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 Merkmale hinzufügen, der schmerzhaft fehlen. Auch muss beim Schema der kontinuierliche Verbesserungsprozess ansetzen. Das Schema muss regelmäßig geprüft und angepasst werden. Deine IT entwickelt sich weiter. Als dürfen sich auch die Werkzeuge weiterentwickeln. Das darfst Du mit regelmäßigen Reviews und vor allem auf Basis vom Feedback Deiner Kollegen unterstützen.
Das Modell einer CMDB 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:
Genau solche einzelnen Szenarien können ein wundervoller, kleiner Einstieg in ein funktionierendes Konfigurationsmanagement sein.
Natürlich findest Du in Deinem Konzept auch Angaben zur Aktualisierung der CMDB-Daten, der Integration in die ITSM-Prozesse und 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.
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 soweit sinnvoll automatisiert werden.
Der nächste, gerade angesprochene, Stolperstein ist die Datenpflege und damit die Aktualität der Daten. Selbst wenn es ein schlankes Modell gibt, müssen die Attribute gepflegt werden. Sonst hast Du keine Vorteile. 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 essenzielle Frage dabei: Werden die Daten, die ich brauche, schon irgendwo anders gepflegt oder automatisiert erhoben?
In der Frageliste (19 Fragen) findest Du auch dazu passende Vorschläge, wie Du genau herausbekommst, die führende Datenquelle liegt. Du kannst Dir die Liste kostenfrei herunterladen:
Ohne aktuelle Daten wird die CMDB keinen Nutzen stiften. Dieses Schicksal hat in der Vergangenheit ganz viele Konfigurationsdatenbanken ereilt. Viel zu ambitioniert gestartet, viel zu viele Daten und keiner, der diese verwalten möchte.
Wenn die Daten niemand pflegt, sind sie 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 Configuration-Management-Database 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.
Zusätzlich erlaubt Dir eine CMDB auf ältere Versionen einer Konfiguration des bspw. Servers zuzugreifen. Du kannst nachvollziehen, welches Betriebssystem letztes Jahr auf dem Server installiert war. Dieses Versionsmanagement ist ein gutes Werkzeug, um beispielsweise ungenehmigte Changes zu ermitteln. Damit kannst Du den Einsatz des Konfigurationsmanagements ausweiten. Das bedeutet für Dich noch mehr abgedeckte Anforderungen und somit noch mehr motivierte Menschen für die Verbesserung der Datenbasis.
Folgende Schwerpunkte sehe ich:
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.
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 seine eigenen Anforderungen umsetzen kann. Es darf Dein Ziel sein, dass jeder Mitarbeiter einen persönlichen Vorteil aus dem Zugriff auf die CMDB erreichen kann. Denn diese Zielstellung leitet Dich bei der Konzeption, dem Aufbau und verhindert Schlimmeres. Jeder darf Verantwortung für die Qualität übernehmen.
Was verstehe ich jetzt unter persönlichem Nutzen einer CMDB? Dazu ein paar Beispiele aus meiner Vergangenheit:
Das Thema Bereitschaft ist häufig ein großer Treiber. 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. Genügend Vorteile?
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.
Auch hier gilt: Eine aktuelle Datenbasis macht Dein Leben und das Deiner Kollegen viel leichter.
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 verwalten 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 Informationen und Beziehungen aktuell gepflegt sind?
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.
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 Verwaltung 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 erfasst werden, 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 Dich bei der Pflege unterstützen 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 Verwaltung der CMDB nutzen darfst. Automatisierung bedeutet weniger Aufwand und vor allem aktuelle Informationen. 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.
Die Integration der vielen vorhandenen Datenquellen in der IT und im Unternehmen ist ein Schlüssel zur Aktualität.
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. Änderungen in der Quelle werden bemerkt und führen zu einer automatischen Änderung. Wie von Zauberhand ist Dein Konfigurationsmanagement-System sofort wieder aktuell.
Du partizipierst hier nicht nur an den vorhandenen Informationen über die Assets, 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 Verwaltung sparen, für bessere Datenqualität und eine höhere Akzeptanz der Configuration-Management-Database sorgen.
Überlege mal, welche potenziellen Quellen ist bei Dir im Unternehmen gibt. Oder andersrum, überlege welche Attribute Du gern automatisiert gepflegt haben möchtest, und such Dir dann die führende Quelle.
Noch ein kleiner Tipp: Ich binde in fast jedem Projekt das Directory-System an. Dort holen wir beispielsweise die eMail-Adresse, Telefonnummer und Abteilungszugehörigkeit raus. Allein das spart schon und sorgt für Akzeptanz.
Damit vermeidest Du unnötigen Pflegeaufwand und die Aktualität ist gewährleistet. Nur so kann sichergestellt werden, dass die Fragen tatsächlich beantwortet werden können. Mit einer manuellen Datenpflege 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 Konfigurationsmanagement-Datenbank beziehen? Es kann nur eine Mutter der Daten geben!
Wenn wir etwas im IT-Service-Management haben, dann sind es Prozesse. Unter ihnen einige, die uns in Sachen Aktualisierung der CIs sehr nützlich werden können.
Die Verknüpfung von Vorgängen mit CIs ist eine grundlegende Anforderung an die Integration zwischen Konfigurationsdatenbank und Ticketsystem. Es hört nicht bei den Objekten und Attributen auf, sondern geht mit den Prozessen im Unternehmen weiter. Je mehr Abläufe von den Informationen der CMDB profitieren, desto mehr Menschen haben Interesse an der Aktualität. Was wiederum einen direkten Einfluss auf die tatsächliche Aktualität und die Betriebskosten hat.
In den Abläufen und Vorgängen des Service-Managements 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 ein Attribut, welches gepflegt werden darf. Wenn Deine CMDB und Dein ITSM-Tool 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 das Aktualisieren der CMDBs geht.
Viele Prozesse verarbeiten Daten aus der CMDB. Im Umkehrschluss können diese Informationen durch diese auch gepflegt werden. Idealerweise automatisch.
Mithilfe von Service-Requests werden Services bestellt, gekündigt und Parameter des Service verändert. Nimm nur mal die IMAC - 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 pflegen.
Hinter den meisten Service-Request verbergen sich Workflows, die sich immer auf ein ganz konkretes Objekt beziehen. Teil dieser Workflows darf die automatische Pflege der veränderten Informationen sein. In der Regel kannst Du das mit wenig Aufwand in die bestehenden Workflows integrieren.
CMDBs müssen nicht Teil der ITSM-Software sein. Es gibt genügend Gründe, diese Funktionalität in einem eigenen funktionalen Baustein zu etablieren. Es ist nur in vielen Fällen einfach nicht sinnvoll oder finanziell leistbar.
Der direkte Zugriff Deines Service-Management-Tools auf die CMDB ist wichtig und darf grundsätzlich realisert sein. 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 damit beantworten werden können:
Die Konfigurationsdatenbank ist das Kernelement der Serviceerbringung im ITSM. Das Konzept wird in allen ITSM-Frameworks wie ITIL, FitSM oder YasM genutzt.
Jeder Vorgang in ITSM-Tool sollte einem CI zugeordnet werden. Damit entsteht ein Lebenslauf für jede Komponente. Für jedes Objekt, welches für die Serviceerbringung relevant ist. Das ermöglicht weitergehende Analysen und ist vor allem Basis für ein Problemmanagement.
Ob die CMDB-Implementierung der einzelnen Service-Management-Tools für Deine Ziele geeignet ist, darfst Du kritisch hinterfragen. Meiner Meinung nach gibt es da bei vielen Anbietern noch genügend Raum für Verbesserungen. Insbesondere wenn Du Dir die Integration des Service im Spannungsfeld von Prozess, Self-Service-Portal und Configuration-Management anschaust.
Integration geht noch weiter. Auch andere Werkzeuge im Betrieb, der Planung oder des Kundenmanagements können von den ganzen Informationen profitieren.
Denk mal bitte 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 verantwortlichen Administratoren mit dem Servierobjekt verlinkt sind.
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 immer wieder darüber nachdenken, welche Werkzeuge miteinander verknüpft werden können. Automatisierung ist ein essentieller Faktor für die Arbeitserleichterung und die Qualitätssicherung.
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:
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 ausgehend von den Prozessen 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.
Die Möglichkeit diese Beziehungsebenen sinnvoll zu visualisieren sollte als Anforderung bei der Auswahl der geeigneten Softwareanwendung unbedingt beachtet werden.
Was kannst Du 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 Veränderung bis hin zum Geschäftsprozess verfolgen, so ist 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.
Noch mehr: Risikomanagement, Sicherheitsmanagement und andere nicht-IT-Prozesse brauchen die gleichen Informationen in ähnlicher Form. Es profitieren viele Stakeholder im Unternehmen von der CMDB, wenn diese als Werkzeug verstanden und genutzt wird. Damit kann die Configuration-Management-Database ein wichtiger Erfolgsfaktor bei Änderungen / Anpassung des Geschäftsmodells oder der Abläufe sein. Entsprechend der Abbildung der Services ist einfach zu identifizieren, welche Veränderungen wo notwendig sind.
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.
Mit Projektabschluss ist nicht Schluss: Ebenso wichtig wie das erfolgreiche Projekt ist die anschließende Aufgabe der Pflege. Nur wenn die Werte 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 soweit sinnvoll automatisiert werden.
IT-Hotline – Fluch oder Segen?
Wer gibt schon gern ein Ticket auf, wenn er den nette Kollegen aus der IT doch gleich direkt anrufen kann. Das ist ein großes Plus bei der Zufriedenheit der Nutzer. Gleichzeitig ein dickes Minus für die IT-Abteilung selbst. Warum ist das so und was kannst Du tun, damit die Nutzer das Self-Service-Portal bevorzugen?
Weiterlesen
Risiko, Sicherheit, Datenschutz & Services – macht es doch gemeinsam!
Risikomanagement, Datenschutz und Informationssicherheit sind wichtige Aufgaben in Deinem Unternehmen. Wie Du diese zusammen mit Service-Management gemeinsam betrachtest, darüber sprechen wir heute.
Weiterlesen
Beherzige diesen einen Tipp bei der ITSM-Tool-Auswahl
Die Auswahl eines Tools ist aufwendig und kostet viel Zeit und Geld. Und trotzdem bekommen viele Unternehmen ein (ITSM)-Tool, welches nicht das abbilden kann, wozu es gekauft wurde. Wie Du das verhindern kannst, erkläre ich Dir an einem ganz aktuellen Beispiel.
Weiterlesen
Das Serviceerlebnis entscheidet über die Qualität
Das Serviceerlebnis beginnt sobald der potentielle Kunde sich über das Angebot informiert. Ob das Serviceerlebnis endet, ist eine interessante Frage. Selbst wenn der Kunde keine Berührungspunkte mit dem Service hat, möchte ich ihn vielleicht wiedergewinnen und bleibe in Kontakt.
Egal wie – ein Serviceerlebnis zu gestalten ist eine große Herausforderung. Lass uns pragmatisch an die Sache rangehen und fünf wichtige Punkte anschauen. Zusätzlich geben ich Dir noch Tipps, wie Du die Veränderung starten kannst.
Ich habe ganz viel über die Identifikation von CIs und deren Pflege 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: Konfigurationsmanagement (deutsche Übersetzung) dokumentiert und administriert alle Configuration-Items und deren Beziehungen untereinander. Es besteht aus drei Teilprozessen:
Damit werden neue Elemente entdeckt und Veränderungen an bestehenden CIs aufgedeckt.
Die Konfigurationsdatenbank ist ein wichtiger Bestandteil der Dokumentation einer IT-Umgebung.
Daher ist die Pflege des Datenfundaments für mich Aufgabe eines jeden Mitarbeiters der IT. Die Verantwortung, ob alle Konfigurationselemente dokumentiert und aktuell 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?
Die CMDB bekam in ITIL v3 einen neuen Namen: CMS - Configuration-Management-System. Neben dem neuen Namen wurde das Konzept 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.
ITIL v3 setzt auf das CMS ist als Konzept einer Datendrehscheibe: 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 einzelne Datenbank, sondern ein logisches Konstrukt aus vielen Quellen, die in der 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.
Möchtest Du eine zentrale Informationsbasis aufbauen, dann brauchst Du ein Tool dafür! Konfigurationsmanagement ist eine Disziplin, bei der Du ohne Tool nicht weit kommst.
Die gute Nachricht ist, dass die meisten ITSM-Tools die entsprechende Funktionalität eingebaut haben. Der Funktionsumfang der einzelnen Tools unterscheidet sich sehr. Du solltest bei der Auswahl einer CMDB Software auf folgende Anforderungen achten:
Neben den Lösungen, die in ITSM-Tools integriert sind, gibt es 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.
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 Eigenschaften 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 Software zusammenführen.
ITIL4 trägt dieser Sichtweise Rechnung und kennt zwei Praktiken: Asset-Management und Service-Configuration-Management.
ITIL4 kennt die Praktik Service-Configuration-Management. Die CMDB oder das CMS sind in ITIL4 nach wie vor das Daten-Fundament jeder Serviceerbringung.
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.
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 bzw. CMS mit hoher Datenqualität, die alle Informationen aktuell enthält und minimalen Pflegeaufwand bedeutet. Folgende Punkte werden wir gemeinsam klären:
Das Ergebnis ist ein umfassender und sorgfältig ausgearbeiteter Plan für den Aufbau Deiner Configuration-Management-Database. Damit steht dann einer nachhaltigen 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 Dein Vorhaben zu einem 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.
Wenn Du eine gut strukturierte und vor allem nützliche CMDB aufbauen möchtest, dann vereinbare jetzt ein kostenfreies Erstgespräch: