IT Service Management / ITIL

Wir allen kennen die berühmten Leitsätze a la „vereinbare nur, was Du auch messen kannst!“.Na klar, wie denn sonst – sollte man meinen.

In der Praxis  sieht es dann schon ganz anders aus: Nicht alles, was ich messen kann, ist sinnvoll (Sind 28.736.658.244 Bytes, die über einen Port geflossen sind, gut oder schlecht und was bedeutet das für den Kunden?).

Dagegen sind häufig gerade die Werte, die aus Sicht des Services relevant wären, gar nicht messbar (Wer hat nicht das eine oder andere Excel VBA Tool, um Daten aus verschiedenen Quellen, die nicht miteinander sprechen, zu aggregieren?

Und wenn ich dann alles zusammengesetzt habe, um eine vollständige Sichtweise auf einen Service zu generieren, dann entwickelt der Kunde im Rahmen der Service Level Reports plötzlich eine ganz andere Sichtweise und ist nicht mehr meiner Meinung (Meinem Ziel, die Erwartungshaltung zu steuern, bin ich nicht näher gekommen!).

Somit ergibt sich zwingend eine Reihenfolge, der ich folgen muss, wenn ich sinnvoll messen will:

1) Kenngrößen zu Charakterisierung eines Services (und nur diese!) müssen vorab mit dem Kunden abgestimmt werden. Das heißt, dass mit dem Kunden im Rahmen der Designphase festgelegt werden muss, wann die Dienstleistung „gut“ ist und wann „schlecht“. Als Ergebnis erhalten beide Beteiligte eine Beschreibung der Messgrößen UND deren Zielwerte (Niederlegen, z.B. im SLA Anhang).

2) Intern definieren und kommunizieren, wer auf welche Weise in welchem Intervall diese Werte bereitstellt. Sinnvoll ist hier nicht, sich auf die vereinbarte (Kunden-) Intervalle zu beschränken: Schön, wenn ich die notwendigen Kennwerte dann habe, wenn ich sie dem Kunden vorstellen muss – Intern sollte ich zu jeder Zeit wissen, wie der Service läuft.

3) Implementierung der zugrunde liegenden Automatismen und Tools / Monitore.

Auffällig ist in dieser Aufzählung, dass ich zu keiner Zeit frage, was ich messen kann. Diese Frage ist aus meiner Sicht irreführend: Ich muss das messen, was ich zur Steuerung des Services (und des Kunden ?!?) benötige. Ich lege meine Anforderungen aber inhaltlich nicht danach aus, was ich (im Moment) messen kann.

Der ein oder andere wird meinen Beitrag zum Thema Mnemotechnik gelesen haben. Einer der Hinweise lautet “Erzählt Geschichten“.

Nun habe ich eine interessante Entdeckung zum Thema “Erzählen” gefunden, die ich nicht vorenthalten möchte.

Es geht um Storytelling - die Macht der Geschichten.

Storytelling bezeichnet eine Methode, mit der explizites aber vor allem implizites Wissen weitergegeben werden kann. Storytelling wird u. a. in der Bildung und im Wissensmanagement eingesetzt.
Konkret geht es um das Erzählen von Geschichten und um aktives Zuhören. Wichtig ist, dass der Zuhörer in die erzählte Geschichte eingebunden wird. Dadurch wird der Inhalt der Geschichte nicht nur „gehört“, sondern auch „erlebt“. Das hat den Vorteil, dass das zu transportierende Wissen eher verstanden wird und sich zudem verfestigt.
Soweit zur theoretischen Beschreibung, auch nachzulesen in Wikipedia.

IT Service Management stellt den Kunden in den Mittelpunkt - haben wir hier schon seeeeehr oft strapaziert. Es geht also um Geschichten, die nebenbei oder zu bestimmten Erlebnissen erzählt werden und meistens Aussagen haben, als die ITIL Theorie. Geschichten machen das Leben bunt und das gilt insbesondere in Unternehmen. Diesen Umstand nutzt Storytelling auf vielfältige Weise und kann somit das P für People auf hervorragende Weise unterstützen.
Gut erzählte Geschichten helfen den Menschen Zusammenhänge zu erkennen und nutzen so den Teil der Mnemonik. Geschichten berühren, amüsieren, helfen Erfahrungen weiterzugeben, und die eigentliche Botschaft zu überliefern.
Erzählen ist eine interaktive Form der Kommunikation - nicht zu verwechseln mit dem Schreiben einer Mail, aber dazu ein anderes mal. Der Zuhörer lässt sich von der Geschichte inspirieren, schenkt ihr seine Aufmerksamkeit und ist damit ganz bei der Sache. In dieser Form übermitteltes Wissen kommt in den Köpfen der Zuhörer von ganz allein an.

Wie geht man das nun konkret an? Der grundsätzliche Aufbau folgt diesem Muster:
- Was war am Anfang (Problembeschreibung)?
- Wer (der Held) hat was (die gute Tat) mit wessen Hilfe (die gute Fee) getan?
- Welche Gefahren (das Abenteuer) gab es?
- Wie ging das Ganze aus?

Was mir jetzt noch fehlt, ist die praktische Erfahrung. Diese werde ich alsbald nachreichen und hoffe gleichzeitig auf Rückmeldung (Erfahrungen, Methodenergänzungen und Geschichten) aus dem WWW.

Die Firma Serview, eine der führenden und renommiertesten deutschen Firmen im Bereich IT Service Management, über nimmt den itil-blog.

Wir wünschen Michael Kresse und seinem Team auf diesem Weg gutes Gelingen und hoffen auf einen ergiebigen Blog-Austausch.

Wie schön des öfteren beschrieben besteht der Sinn von ITIL in der Fokussierung auf den Kunden bzw. IT Services - soweit nichts Neues.

Die Erfahrung zeigt, dass nach kurzer Zeit das Thema CMDB (Configuration Management Data Base) in den Mittelpunkt rückt.
An dieser Stelle sei vermerkt und auch darauf hingewiesen, dass der entscheidenene Unterschied zwischen einem Asset-Management und der CMDB die Verknüpfungen der Inhalte (Configuration Items) sind.
Die initiale Erfassung und nachhaltige Pflege der CIs und ihrer Verknüpfungen ist eine nicht zu unterschätzende Aufgabe. Oft entscheidet sich gerade hierbei, in wie weit die Umsetzung gemäß ITIL erfolgreich sein wird.

Viel zu oft wird dieses Thema aus Sicht der Technik gesehen. Dabei geht es hier um IT Service Management - also hin zum IT Service und zum Kunden. Auch gibt es einige Tools, die einem automatisch die Arbeit der Befüllung abnehmen, in dem sie die technische Infrastruktur scannen und so suggerieren, dass die Arbeit damit getan ist.

Auch hier gilt es, dass die richtige Strategie entscheidend ist. Aus meiner Sicht gibt es zwei Erfolgsfaktoren
1. die 3 Ps (People, Processes, Products) beachten
2. Top-Down Ansatz bei der Befüllung.

People, Processes, Products
Natürlich ist das Tool (Product) wichtig und muss überhaupt erstmal die notwendigen Strukturen mitbringen. Allerdings ist mir derzeit kein Tool auf dem Markt bekannt, welches dies nicht tut…und das Tool ist nur 1/3 vom Ganzen.
Ohne, dass die Prozesse (Processes) (insbesondere Change Management) etabliert und auf die CMDB abgestimmt sind, wird jede initiale Befüllung mit dem ersten Tag der Nutzung hinfällig sein, da niemand für die Aktualisierungen sorgt bzw. bemerkt, dass die CMDB nicht mehr dem ‘wahren Leben’ entspricht.
Auch hier ist der Faktor Mensch (People) wichtig. Als Erstes wird die zusätzliche Pflege von ‘theoretischen Gebilden’ als unnütze Mehrbelastung empfunden. Es ist also wichtig, dass vom ersten Tag der operativen Nutzung, jeder Mitarbeiter einen praktischen Nutzen bei seiner Arbeit spürt. Das ist dann auch der elegante Übergang zu meinem 2. Punkt.

Top-Down Befüllung
Viel zu viele Projekte gehen den Weg, dass erstmal die ganze IT Landschaft in die CMDB gebracht werden muss - wir erinnern uns an die schönen Tools, die uns die Arbeit hier komplett abnehmen wollen. Nachdem dann alle Assets geladen wurden, werden dann alle Verknüpfungen erfasst und schon sind knapp 2 Jahre rum, ohne dass irgendwelche Ergebnisse erzielt wurden.
Der Top-Down Ansatz bedeutet, dass die Befüllung Kunde pro Kunden bzw. pro Kunde und Service erfolgt. Dies hat die Vorteile, dass die Menge der zu erfassenden CIs deutlich geringer ist und, dass es über alle Prozesse hinweg einen sofortigen Mehrwert mit dem Go-Live Zeitpunkt gibt.
Darüber hinaus lassen sich somit auch kleinere Unstimmigkeiten bei den CMDB Inhalten und Attributen bzw. bei den Prozessen leichter korrigieren.

Also ran an die 3 Ps und unternehmen Sie die konkrete kleine Schritte, um Ihre CMDB sorgfältig zu planen. Und verpassen Sie keine Gelegenheit, die Potentiale einer CMDB wirksam aufzuzeigen; die Prozesse zu etablieren sowie die Paradigmen hin zur Service-Orientierung zu ändern.
Dann werden Sie auch den Beitrag von der CMDB an dem ROI zu ITIL spüren…