Internes Service Level Management

ITIL® hilft ungemein eine einheitliche Sprechweise zu etablieren. Ein schönes Beispiel ist das Wort Problem, die Ursache von Incidents. Bei einigen Organisationen basiert die Bereinigung von Fehlerursachen auf engagierten Mitarbeitern, die auch noch ein gutes Zeitmanagement haben müssen, um in Zeiten knapper Ressourcen das Hobby Ursachenanalyse nicht zu vernachlässigen. In einer Ist-Aufnahme kreuzen derart strukturierte Organisationen trotzdem gerne an, dass Problem Management wohl etabliert sei. Das Wort Problem ist so schön dehnbar und Probleme werden gelöst. Stimmt ja auch.

Deshalb bin ich ein Freund davon ITIL-Begriffe zu etablieren, das senkt die Signal-to-Noise-Ratio. Dauert und kostet Energie, aber ist bisher immer erfolgreich gewesen. Ein Resultat könnte zum Beispiel weniger Spielraum im reporteten Reifegrad eines Dienstleisters sein.

Bei der Einführung von Service Level Management habe ich es jedoch noch nie gesehen, dass zwischen den Begriffen OLA, SLA und UC unterschieden wird. Es wird alles der Einfachheit halber SLA genannt. Inhaltlich wird schon unterschieden, aber nicht in den Begriffen. In dem Fall finde ich es nicht schlimm, an den Worten OLA oder UC sind dann die ITIL-Leute einer Organisation leichter zu erkennen 🙂

Die Einführung eines Service Level Managment ist von der Vorgehensweise einfach, jedoch sehr langwierig in den Verhandlungen:

• Die bestehenden Service sind eventuell gar nicht als solche zu erkennen, weil an jeden Kunden ein anderes Tortenstück vom Kuchen verkauft wurde. In Kardinalfällen muss sogar auf technischer Ebene ein Service herausgearbeitet werden.
• Nachdem ein erster Satz an Services greifbar ist, müssen passende Service Level Klassen festgelegt werden. Dies muss meiner Meinung nach Maßgeschneidert auf die Organisation geschehen. Eine vorgegebene Struktur führt leicht dazu, dass KPIs zurecht-gelogen  werden. Das nützt Keinem.
• Nun geht es an den Rahmenvertrag, ITIL nennt das Multi-Level-SLA (Service Design, S. 66ff). Neben der genauen Abgrenzung der Service Level Klassen sollten hier die Voraussetzungen, mögliche Änderungen und generelle Regelungen für alle Services festgelegt werden.
• Nachdem die Rahmenvereinbarung von allen Kunden akzeptiert wird, geht es nun an alle Service-Erbringer. Es müssen die SLAs (OLAs) unterschieben werden und mancher weiß gar nicht, dass er Service-Erbringer ist. Underpinning Contracts können meist bis zur nächsten Vertragsverlängerung warten, aber auch das bedeutet Aufwand und Verhandlungen.

Der Lohn für diese lange Verhandlungsstrecke ist in knappen Worten folgendes:

• Es existiert ein System aus Rahmenvertrag und einer Tabelle (Service/Service Level Klasse), das sich leicht auf vier PowerPoint-Folien darstellen lässt. Der Transparenzeffekt gerade aus Sicht eines Managers ist enorm.
• Bestehende Services müssen sich zuerst an die Service Level Klassen gewöhnen. Mache passen sofort andere müssen sich ein halbes Jahr einrütteln. Danach kann recht einfach, vielleicht einmal pro Jahr, die Wichtigkeit eines Service für das Geschäft festgelegt werden. Services steigen typischerweise zuerst an Wert. Mehrausgaben sind einfacher verhandelbar, wenn der Gegenwert klar formuliert werden kann.
• Die Parameter, die ein Service erfüllen muss (Service Level Targets , KPIs) sind festgelegt. Deren Messung kann und sollte kontrolliert werden. Bei unreifen Services mit ganz wenig Messwerten anzufangen ist schlau. Messung kostet Geld, vor allem dauerhafte Messung von Aussagelosen Werten.
• Durch Service Level Management werden nach und nach Services als solche erfasst bzw. bei manchen Diensten festgeschrieben, dass diese eben keine Services sind. So können sich Betreiber von Piratenservern in das System eingliedern oder bewusst draußen bleiben. Das sorgt für weniger Streit, wenn es in der Operations mal heiß her geht.

In dem konkreten Projekt habe ich ein Rahmenvertrag entworfen, der eine spezielle Service Level Klasse für Piratenserver hatte. Auch ist das System so ausgelegt, das die Organisation vom Ist-Zustand in eine strukturierte Service Erbringung wachsen kann. Solche Kompromisse müssen eine Wachstumsrichtung vorgeben, das ist entscheident. Denn es ist wie immer im Leben, es ist nicht nur eine Seite, die für Probleme sorgt. Gerade hier müssen Kunden und Service Provider zusammen einen Weg finden, um aus IT Services einen integralen Bestandteil des Geschäfts zu machen. Dort liegt zwar Risiko, aber auch eine Menge Effizienz, die gehoben werden will.