Service Level Agreements – aber richtig
Geht es um Service Level Agreements klaffen Realität und Kundenwunsch meist weit auseinander. Um teure Streitfälle zu vermeiden, müssen beide Seiten sorgfältig an die Entwicklung entsprechender Vereinbarungen herangehen. Auch die die richtige Betrachtung von Begriffen und Formulierungen ist ein Muss, sagt Christian Wischki, Service Manager bei der Trivadis AG, im Gespräch mit silicon
silicon.de: Herr Wischki, bei der Beauftragung eines externen Dienstleisters, kommt man heute kaum mehr um ein Service Level Agreement herum, warum kommt es gerade hier immer wieder zu Problemen?
Christian Wischki: Bei einem Service Level Agreement handelt es sich um eine schriftliche Vereinbarung zwischen zwei Vertragsparteien, in der die exakten Liefergegenstände eines Service Providers und die dafür zu entrichteten Gebühren niedergelegt werden. Dennoch kommt es nach Vertragsabschluss fast immer zu Missverständnissen.
Die Gründe dafür sind so einfach wie komplex: Viele SLAs sind nur ungenügend auf die individuellen Bedürfnisse des jeweiligen Kunden abgestimmt und werden in der Regel von der IT-Abteilung des Dienstleisters entwickelt. So entstehen Vertragswerke, die sehr techniklastig und nicht in “Businesssprache” formuliert sind. Die aufgeführten IT-Leistungen sind damit verbal weder auf die realen Bedürfnisse des Servicenehmers ausgerichtet, noch können sie von selbigem in einen direkten Zusammenhang mit seinen Geschäftszielen gebracht werden.
silicon.de: Wie kann man denn diese babylonische Verirrung minimieren?
Christian Wischki: In vielen SLAs werden Verfügbarkeiten, Reaktionszeiten, Antwortzeiten und teilweise auch Lösungszeiten geregelt. Doch was besagen diese Begriffe wirklich? Die Reaktionszeit besagt im Falle von Störungsmeldungen im Grunde nur, dass sich der Serviceprovider innerhalb dieser Reaktionszeit melden muss. Wenn die Reaktionszeit also nicht genauer definiert wurde, dann ist der Serviceprovider im Grunde seinen Pflichten schon nachgekommen, wenn er bei einer Störungsmeldung den Telefonhörer abhebt und diese entgegen nimmt.
Um dieses zu vermeiden, greift man gerne auf den Begriff “Lösungszeit” zurück. Diese lässt sich jedoch nicht für alle Bereichen der IT exakt definieren. Grund: bei komplexen Systemen können nicht alle potenziellen Störungen vorhergesagt, geschweige denn ein perfekter Lösungsansatz bereitgestellt werden. Dies gilt besonders für Enterprise Software. Realistische Lösungszeiten stellen also im Grunde die Zeiten dar, welche der Serviceprovider maximal benötigt, um auch defekte Hardware auszutauschen und anschließend ein Backup auf das neue System einzuspielen.
silicon.de: Was sollte man unter Verfügbarkeit verstehen?
Christian Wischki: Der Begriff der “Verfügbarkeit” wird ebenfalls oft falsch definiert. Hier sollte vor allem darauf geachtet werden, dass wegen Wartungsarbeiten nicht erreichbare Serversysteme (geplante Downtimes) nicht in die Verfügbarkeitsbetrachtung und -berechnung einbezogen werden. Ein Beispiel: Was bedeutet eine zugesicherte Verfügbarkeit von 98 Prozent? Auf den ersten Blick betrachtet klingt diese für Kunden nahezu perfekt. Doch betrachtet man diese Angabe genauer, darf der betreffende Service mehr als 175 Stunden pro Jahr ausfallen – es sei denn, es ist im SLA konkreter definiert. Dies entspricht einem erlaubten Ausfall von 17 aufeinanderfolgenden Werktagen, ohne dass der Serviceprovider die im SLA vereinbarten Verpflichtungen verletzt.
silicon.de: Es scheint da ja gerade für Anwender einige Fallen zu geben…
Christian Wischki: Die Liste der tückischen Details bei der Verwendung von festen Begrifflichkeiten lässt sich im Grunde beliebig fortsetzen. Aus diesem Grund sollten diese in SLAs nie ohne kundenspezifische Konkretisierung verwendet werden, sondern möglichst genau präzisiert werden.
- Ein SLA sollte grundsätzlich ausgehend vom Servicenehmer entwickelt werden.
- Zu liefernde IT-Services sind klar auf Kundenbedürfnisse auszurichten und eindeutig zu formulieren.
- Feststehende Begriffe sind stets genau zu spezifizieren.
- Key Performance Indikatoren sollten stets die Added Values für den Servicenehmer beinhalten, permanent gemessen und periodisch rapportiert werden.
- Sämtliche Indikatoren sind in mess- und überprüf- und dokumentierbare Service Level Objectives (SLO) umsetzen. Die zugehörigen Mess-Methoden müssen exakt definiert sein.
SLAs müssen zwingend konkrete Review-Termine enthalten, damit diese auf veränderte Bedürfnisse des Servicenehmers angepasst werden können. - Jedes SLA sollte eine fest definierte Laufzeit haben und in angemessener Zeit kündbar sein. Kunden sollten darauf bestehen, dass sich der Serviceprovider im SLA verpflichtet, nach Vertragsende alle Informationen und Erkenntnisse vollständig weiterzugeben.
silicon.de: Zu welcher Strategie raten Sie?
Christian Wischki: Ein Service Level Agreement sollte immer aus Sicht des Kunden entwickelt werden (“Top Down”) und die direkte Verbindung zwischen IT-Services und Businessprozessen herstellen. Außerdem ist es ratsam, den Nutzen der angebotenen Dienstleistung aufzeigen. Diese “Added Values” sollten unbedingt die Key-Performance- Indikatoren eines Service Level Agreements darstellen und nicht von technischen Begriffen wie CPUs, RAM, Bandbreiten oder ähnlichem dominiert werden. Um Missverständnisse zu vermeiden, ist es zudem empfehlenswert, alle Begrifflichkeiten zu konkretisieren und das Vertragswerk erst dann an den Kunden zu übergeben.
silicon.de: Wir haben jetzt über die Bedürfnisse der Servicenehmer gesprochen. Aber auch für die Dienstleister muss das Vertragswerk ja einen akzeptablen Rahmen bieten.
Christian Wischki: Die Entwicklung beidseitig akzeptabler Service Level Agreements ist für Kunden wie Serviceprovider fast immer ein längerer Prozess, der praktisch nie ohne Nachjustierung funktioniert. Vor allem für komplexe Vertragswerke empfiehlt sich deshalb der Einsatz eines “Moderationsteams”, welches die exakten Kundenbedürfnisse kennt, die SLA entwickelt, mit allen Beteiligten abstimmt und finalisiert. Handelt es sich um einen Vertrag zwischen den Business und IT, ist ein “Moderationsteam” aus dem Bereich Business Service Management (BSM) sinnvoll, da diese die Bedürfnisse beider Seiten sehr genau kennen.
silicon.de: Vielen Dank für das Gespräch, Herr Wischki!
