IT Service Management / ITIL

Wie so viele Andere warten wir gespannt auf die neue Version der ITIL Ausgabe. Anstatt der bisherigen Bücher wird es jetzt folgende Aufteilung geben:
- Service Strategy
- Service Design
- Service Transition
- Service Operation
- Continual Service Improvement

Vom 8. bis 22. Januar 2007 fanden die letzten öffentlichen Reviews, durch 471 ausgewählte “Prüfer”, der neuen Ausgabe statt. Seitdem werden sämtliche Anmerkungen überprüft und ggf. eingearbeitet.

Das Releasedatum der englischen Ausgabe ist der 30. Mai 2007.

Wie schon in dem ein oder anderen Beitrag angemerkt, geht es bei IT Service Management um das große Ganze und nicht nur um ITIL oder andere Auszüge. Auch gibt es nicht DAS Projekt und nach Projektende ist man fertig - kontinuierliches Tun ist angesagt.

Interessant zu beobachten ist, dass gerade diese essentiell wichtige Einsicht selten im Top-Management verinnerlicht oder gelebt wird. 

Als Beispiel ein Bericht über ein abgeschlossenes ITIL Projekt, der allen Zuhörern unlängst auf einer “Executive ITIL-Veranstaltung” vom Redner mitgeteilt wurde: Durch die Einführung von Prozessen, Prozess-Managern und einer Matrix-Organisation würde man geschickt das Prinzip “Teile und Herrsche” einführen und seine Vorteile nutzen. Auf meine Nachfrage, worauf das abzielt, erhielt ich die Antwort, dass das Prinzip dafür steht, dass man unter Gegnern Zwietracht und Uneinigkeit sät, um so in der Machtausübung ungestört zu bleiben. Als “Gegner” wurden dann die Prozess-Manager und disziplinarischen Vorgesetzten genannt……

Nicht nur, dass damit die Basis für IT Service Management komplett zerstört wird, das Prinzip ist vollkommen falsch ausgelegt / verstanden worden, da es im Sinne einer Unternehmensarchitektur komplett anders verstanden wird und auch dann auch sinnvoll ist. “Teile und Herrsche” steht auch für eine Strategie mit komplexen Themen umzugehen, um diese besser lösen zu können: Zunächst wird ein Problem in einzelne, beherrschbare Teile zerlegt. Die einzelnen Teile werden für sich gelöst, und die einzelnen Lösungen zu einer Gesamtlösung zusammengefügt.

Ich halte es in diesem Zusammenhang eher wie Goethe. Der schrieb: “Entzwei und gebiete! Tüchtig Wort. – Verein und leite! Besserer Hort.”.

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.