„Ordnung ist die Verbindung des Vielen nach einer Regel“ (Teil 2)

Im zweiten Teil meines Blog-Beitrags gehe ich zunächst noch einmal auf den Nutzen einer CMDB ein, bevor ich mich dem Aufbau einer gut strukturierten CMDB widme.

Der größte Nutzen einer CMDB oder eines CMS (Configuration Management System) leitet sich aus den Relationen zwischen den einzelnen Objekten ab. Diese Beziehungen helfen, Abhängigkeiten, Auswirkungen und andere Zusammenhänge übersichtlich und schnell zu begreifen. Die CMDB ist ein Instrument der IT zur Unterstützung des Business. Ohne Business-Services (IT-Dienste, die Geschäftsprozesse unterstützen) hat sie nur einen geringen Wert für die IT-Organisation selbst. Gemeinsam mit dem Service Catalogue Management ist sie das wichtigste Werkzeug an der Schnittstelle zwischen Geschäft und IT (Business-IT-Alignment).

Der Schlüssel für eine erfolgreiche CMDB-Einführung und deren Betrieb ist, sich immer wieder bewusst zu machen, dass eine CMDB die alltäglichen Fragen im IT-Betrieb und den Planungsprozessen beantworten soll. Dazu muss sie über die aktuellen, passenden Daten und Verbindungen verfügen. Aus den Fragen leiten sich sukzessive Struktur und Inhalt der CMDB ab. Auf diese Weise erfolgt der Aufbau zielgerichtet und der Nutzen des Werkzeugs wird schnell spürbar.

Wie in Teil 1 bereits geschrieben, beantwortet eine CMDB Fragen, die beim Erbringen von technischen Services oder Business-Services sowie in den einzelnen IT-Prozessen entstehen. Für das Incident Management typische Fragen, die eine CMDB beantworten kann, sind z. B.:

– Wer ist die zuständige Person/Administrator?
– Wie erreiche ich den Support des Dienstleisters/Herstellers?
– Welche Services (technische und nicht-technische) sind von der Störung betroffen?
– Wo finde ich eine Wiederherstellungsanleitung nach größeren Ausfällen?

Im Change Management könnten diese Fragen so lauten:

– Was passiert, wenn wir den Drucker/Server/etc. außer Betrieb nehmen?
– Kann der Change in der geplanten Zeit durchgeführt werden?
– Wer muss über den Change informiert werden (Nutzer-/Interessengruppen)?
– Welche Störungen werden durch den Change nachhaltig beseitigt?

Die in der CMDB hinterlegten Antworten auf diese Fragen sollen vor allem Sicherheit geben: Sie sollen dafür sorgen, dass in Stress- und Planungssituationen zügig die richtigen Entscheidungen getroffen werden können. Möglich wird dies durch eine auf die eigene Situation zugeschnittene CMDB-Struktur. Dazu gehört ein individuelles Metamodell, welches auf den Fragen aufbaut, die zukünftig beantwortet werden sollen. Dazu ist es unerlässlich, die zukünftigen Nutzer mit ins Boot zu holen und sie zu fragen, in welchen Situationen sie welche Informationen benötigen. Bezogen auf die obigen Beispielen könnte dies so aussehen:

– Welche Informationen haben beim letzten Ausfall des Systems gefehlt, um den Fehler schneller einzukreisen oder sogar zu vermeiden?
– Welches Wissen ist notwendig, um Störungen nach Changes zu vermeiden?
– Welchen Einfluss hat ein ungeplanter Ausfall einer Infrastrukturkomponente (z. B. ein Drucker, ein Switch oder die Klimaanlage) auf welche Prozesse?
– usw.

Daraus ergeben sich automatisch die Objekte (Configuration Items (CIs)), die verwaltet werden müssen, sowie deren Eigenschaften und Relationen untereinander. Auf Basis dieser und anderer Fragen können nun grundsätzlich die Business-Services (Dienste) modelliert werden, also die Abbildung der Abhängigkeiten der Objekte zu konkreten Dienstleistungen der IT-Abteilung.

Es fehlen nun noch weitere Informationen bzw. Definitionen, um die Auswirkung von Störfällen, Änderungen usw. auf Business-Services und Business-Prozesse bewerten zu können. Diese Informationen könnten z. B. Servicelevels, verantwortliche Personen usw. sein. Diese zusätzlichen Informationen befähigen dann, beispielsweise folgende Fragen zu beantworten:

– Welche Auswirkung (technisch/Business) und Ursache hat eine Störung?
– Wie lange kann eine Störung toleriert werden, bevor Geschäftsprozesse gefährdet sind?
– Wer muss informiert werden?
– Wer muss dem Change zustimmen?

Im gesamten Prozess sollte man immer darauf achten, das System nur auf die nötigsten Daten zu reduzieren.

Damit sind die Grundsteine gelegt, um im Servicebetrieb richtige Entscheidungen schneller und effizienter zu treffen. Nachdem der innere Mechanismus steht, geht es im Folgenden um das Äußere, also die „Touchpoints“ mit den Anwendern, die wesentlich entscheidend für Akzeptanz und Erfolg des Systems sind. Dazu gehört, den Services sprechende Namen zu geben bzw. sie in der Sprache der Anwender zu formulieren (siehe folgende Abbildung). Das stellt zum einen sicher, dass der Nutzen für die Zielgruppe klar ersichtlich wird, zum anderen wird der Wert der IT sichtbar, weil Abhängigkeiten zwischen Prozessen und IT fassbar werden.

IT-Services benötigen sprechende Namen in der Sprache der Anwender. Dadurch können diese die Relevanz der Services für sich erkennen und sie Geschäftsprozessen zuordnen. Somit werden Services verstärkt zu einem wichtigen Ordnungskriterium in einer heterogenen IT-Umgebung.

Werden Business-Services nach diesen Vorgaben, angefangen bei der technischen Infrastruktur, über verschiedene Ebenen hinweg bis hin zu den Business-Prozessen vollständig beschrieben und in einem kundenfreundlichen Servicekatalog angeboten, wird man in der praktischen Umsetzung in vielfacher Hinsicht belohnt:

Root-Cause-Analyse: Im Störungsfall greift eine präzise Root-Cause-Analyse und zeigt die eigentliche Fehlerursache auf. So können Fehler und Ursache zeitnahe beseitigt bzw. der Störfall verhindert werden.

Effiziente Kommunikation: Dazu ein Beispiel: „Morgen können wegen einer Softwareumstellung zwischen 14:00 und 15:00 Uhr keine Lieferscheine gedruckt werden“ anstatt „Heute zwischen 14:00 und 15:00 Uhr Druckserver wdf01_213 im SAP Mandanten Fi nicht verfügbar“. Die Nutzer haben sofort eine Relation zu ihrer Arbeit und können die Information einordnen. Das Ergebnis ist eine höhere Nutzerzufriedenheit sowie weniger Tickets und Eskalationen.

Sicheres Change Management: Lässt sich die Auswirkung einer Änderung bis hin zum Geschäftsprozess verfolgen, so wird ersichtlich, welche Stakeholder am Change-Prozess beteiligt werden müssen. Ferner ist es einfacher zu entscheiden, ob und wann ein Change durchgeführt werden kann oder nicht.

Service Level Agreement: Es werden realistischere Einschätzungen der maximalen Verfügbarkeits- bzw. Ausfallquoten möglich. Darüber hinaus erhält man bessere Vorwarnmechanismen, falls Service Level Agreements gefährdet werden.

Zudem profitieren viele weitere Prozesse von einer gut strukturierten CMDB, wenn diese als Werkzeug verstanden und genutzt wird. Risikomanagement, Sicherheitsmanagement und andere Nicht-IT-Prozesse benötigen die gleichen Daten in ähnlicher Form. Daher kann eine CMDB ein wichtiger Erfolgsfaktor bei Änderungen der Prozesse oder bei Anpassung des Geschäftsmodells im Sinne eines zukünftigen Enterprise Service Management sein.

Im abschließenden dritten Teil werde ich darauf eingehen, was nach der Inbetriebnahme einer CMDB wichtig ist.

 

Autor: Kürsad Gögen, Portfolio Manager

Kontakt: Kuersad.Goegen@dot4.de

 

Nahtloses Business IT Alignment: Digitale Transformation leichtgemacht mit dot4

Schreibe einen Kommentar

Your email address will not be published. Required fields are marked *