Service Level Agreements: Ehevertrag für IT-Dienstleistungen
Artikel erschienen in Swiss IT Magazine 2001/34
Service Level Agreements, kurz SLA genannt, sind bei Outsourcing-Projekten aller Art unabdingbar, darin sind sich die Experten einig. Die Grundvoraussetzung für jede Geschäftsbeziehung ist das Vertrauen zwischen den Partnern - ohne exakte Vereinbarung der geschuldeten Dienstleistungen und deren minutiöse Kontrolle kommt es jedoch allzu rasch zum Krach, wenn der Service einmal nicht zur vollen Zufriedenheit funktioniert.
Laut Urban Lankes, CEO des IT-Dienstleisters Trivadis, erreicht man "wirklich zufriedene Kunden nur über messbare, vertraglich festgeschriebene Grössen". Marketingleiterin Silvana Baselgia vom Application-Hosting-Provider Aspectra formuliert es so: "Ein Service Level Agreement ist wie ein Ehevertrag: Am Anfang der Beziehung glaubt man, es brauche keinen. Sobald aber etwas nicht mehr läuft, zeigt sich sein Nutzen."
Die Grösse des Kunden spielt eine untergeordnete Rolle; es kommt auf Inhalt und Ziel der Vereinbarung an: "Je komplexer das Outsourcing-Projekt oder die Abhängigkeiten, desto wichtiger wird das SLA", fährt Baselgia fort, "das entscheidende Kriterium ist nicht die Unternehmensgrösse, sondern die Komplexität des Projekts."
Service Level Agreements sind grundsätzlich nicht auf technische Umgebungen beschränkt, kommen heute jedoch vor allem in der IT-Welt zum Zug, die zunehmend auf Outsourcing basiert - kaum ein Unternehmen bewältigt heutzutage noch sämtliche Datenverarbeitungsaufgaben ausschliesslich mit Ressourcen aus eigenem Hause.
Unter "Outsourcing" verstehen sich personalbezogene Dienstleistungen wie Consulting, Entwicklung, Support, Pikettdienst und Netzwerkadministration, Telekommunikationsdienstleistungen wie VPN, Voice-over-IP oder WLL wie auch serverbasierte Softwaredienste - vom "Office aus der Steckdose" des Application Service Providers über den ausgelagerten Betrieb der gesamten Unternehmensinformatik im Data Center bis zum kommunen Webhosting, sei es auf einem virtuellen Server des ISP oder auf eigener Gerätschaft im Housing-Modus.
Auch SLA zwischen verschiedenen Abteilungen einer Firma trifft man oft an: Zwischen der IT-Abteilung und den firmeneigenen Anwendern werden vor allem in Grossunternehmen meist sogenannte In-House-SLA abgeschlossen, die mit Verfügbarkeitsanforderungen von hundert Prozent teils sogar strenger ausfallen als das typische externe SLA. Weniger stringent sind die ebenfalls oft anzutreffenden internen SLA, in denen Leistungsziele und Metriken informell festgehalten werden.
In der Realität hängt eine reibungslos funktionierende IT selten von einem einzigen Dienstleistungserbringer ab - vom Consultant über den Supporter bis zu den Herstellern der eingesetzten Software- und Hardwareprodukte sind meist mehrere Anbieter involviert. Damit der Kunde sich nicht mit einer Vielzahl von Partnern und Vertragswerken herumschlagen muss, greift er mit Vorteil auf das sattsam bekannte Generalunternehmermodell zurück: Ein Serviceprovider übernimmt die Gesamtverantwortung für einen Dienst und kümmert sich um die Abhängigkeiten zu den übrigen Leistungserbringern, mit denen er seinerseits Verträge abschliesst, die das SLA mit dem Kunden unterstützen.
Eine Variante des konventionellen GU-Modells ist das sogenannte Multi-Tiered-SLA: Hier sind im Vertrag mit den Endkunden auch alle Beziehungen zu den weiteren Providern von Anfang an im Detail festgelegt - samt Messgrössen, Massnahmen bei Nichterfüllung und Eskalationspfaden. Der hauptsächliche Provider kann sich damit ideal absichern.
Neben der rein juristischen Sicherheit bringt eine gut formulierte Detailvereinbarung zwischen Anbieter und Bezüger von Outsourcing-Dienstleistungen auf verschiedenen Ebenen grossen Nutzen. Ein komplettes und gut formuliertes SLA
verschafft Klarheit über die beiderseitigen Rechte und Pflichten,
dient als Kommunikationsmittel zwischen Service-Anbieter und Abnehmer,
hilft, übermässige Erwartungen zu vermeiden,
setzt den Standard für die zu erbringenden Dienstleistungen,
gibt beiden Vertragspartnern Sicherheit während der Vertragsdauer und bei Beendigung des Verhältnisses,
definiert Methoden und Messgrössen zur Überprüfung der Dienstleistungen und ihrer Qualität,
zementiert das gegenseitige Vertrauen,
garantiert gleichbleibende Dienstleistungsqualität,
gibt dem Abnehmer seinerseits ein Verkaufsargument für die eigenen Produkte und Dienste.
Je nach Art des Projekts kommen entweder Standard-SLA zum Zug, ergänzt durch projektspezifische Zusätze, oder die Verträge werden individuell verhandelt. Unisys-Pressesprecher Thomas Hügli unterscheidet zwei Kategorien: "Bei KMU kommen in der Regel standardisierte Verträge zum Einsatz, die dann mit projektspezifischen Leistungsstufen ergänzt werden. Bei Grossunternehmen setzen wir massgeschneiderte SLA auf." Auch Trivadis arbeitet mit individuell erweiterbaren Standard-SLA: "Nur für Standard-SLA können wir ohne vorherige Absicherung ein direktes Umsetzungsangebot machen, da wir dafür standardisierte Prozesse implementiert haben." Aspectra pflegt einen modularen SLA-Stil: "Unser SLA besteht aus einzelnen Bausteinen, mit denen es sich leicht auf die Kundenbedürfnisse anpassen lässt. Wir erbringen vor allem komplexe Lösungen, die sich mit einem fixen Standard-SLA fast unmöglich abdecken lassen."
Beim Aushandeln eines SLA sollte bei allen Vertragspartnern das höhere Management involviert sein - jedenfalls dann, wenn es nicht um einen simplen Service mit Standard-SLA geht, das die IT-Abteilung von sich aus erledigen kann. Man beachte allerdings, dass auch scheinbar unwichtige Details wie die Überwachung eines Abteilungs-Mailservers für das Unternehmen manchmal lebenswichtig sind.
Die beteiligten Teams sollten sich aus technisch, betriebswirtschaftlich und juristisch versierten Personen zusammensetzen und auf beiden Seiten etwa gleich gross sein. Für Outsourcing-Projekte in mittleren und grösseren Unternehmen empfehlen Sturm, Morris und Jander in ihrem Standardwerk über Service Level Agreement Teams mit vier bis zehn Mitarbeitern. Die Verhandlungen sind üblicherweise in einigen Wochen zu erledigen; sie sollten auf keinen Fall zum Lebenswerk der Beteiligten werden. Dazu sollten die Verhandlungspartner bereits im Vorfeld über Rahmenbedingungen wie gewünschte Dienste, Kostendecke sowie die bereits bestehenden Dienste und Messmethoden informiert sein.
Das SLA sollte vom Kunden und vom Provider in einer gemeinsamen Anstrengung erarbeitet und nicht von einer Seite diktiert werden - nur so widerspiegelt es das Vertrauen, ohne das auch eine SLA-abgesicherte Geschäftsbeziehung wenig Sinn macht.
Auf die Definition der Vertragspartner folgen im typischen SLA eine Reihe von unerlässlichen Komponenten, die idealerweise in separaten Vertragsabschnitten aufgeführt, mindestens aber irgendwo im Text enthalten sein sollten. Wie bei allen juristisch relevanten Dokumenten sollten alle Punkte klar und bis ins Detail ausformuliert sein - immer wieder führen unzureichende SLA-Spezifikationen zu späteren Missliebigkeiten zwischen den Vertragspartnern. Dies ist für Nicole Josi von BMC Software ein häufiger Fallstrick: "Oft sind die SLA nicht präzise formuliert. Messkriterien für die Dienstleistung fehlen, oder die Bedürfnisse des Kunden sind schlecht berücksichtigt." Die SLA, so Josi weiter, seien vielfach "zu technisch" - der Kunde könne nur schwer abschätzen, welche Dienstleistung er einkauft und was er beim Ausfall in der Praxis erwarten könne.
Die folgenden Komponenten bilden die Basis der meisten SLA:
Dauer: Die Zeitdauer, während der das SLA Gültigkeit hat. Da sich die technologischen Voraussetzungen in der IT-Welt rasch ändern, beträgt diese üblicherweise allerhöchstens zwei Jahre.
Umfang: Die Dienste, die das SLA abdeckt. Zu einer kompletten Spezifikation gehören neben den rein technischen Parametern auch die betroffenen Geschäftsprozesse, die Anwender dieser Prozesse sowie die Tages- und Wochenzeiten, während der die festgelegten Service Levels erreicht werden müssen. Wichtig: Ein SLA sollte sämtliche beteiligten Komponenten berücksichtigen, nicht nur eine Teillösung. Bei Aspectra setzt man auf eine Gesamtsicht, wie Silvana Baselgia anmerkt: "Gerade Hoster mit Vergangenheit im Netzwerkbereich argumentieren gerne mit hohen Verfügbarkeitszahlen - doch decken diese SLA häufig nur den Netzwerkteil ab. Garantierte Verfügbarkeiten für Server und Anwendungen fehlen oder sind nur schwer zu erhalten." Trivadis-CEO Lankes betont einen anderen Aspekt - trotz vollständiger Abdeckung darf die Übersicht nicht verlorengehen: "Transparenz ist ein wichtiges Element des SLA: lieber weniger, dafür die für den operativen Betrieb wirklich notwendigen Komponenten im SLA klar definieren. Es nützt weder dem Kunden noch dem Lieferanten etwas, lange, unübersichtliche Papiere zu verabschieden."
Rahmenbedingungen: Hier werden die Bedingungen beschrieben, unter denen die gewünschten Service Levels zu erbringen sind, zum Beispiel das Transaktionsvolumen, das der Anbieter zu bewältigen hat, oder die Personalkosten, die dabei entstehen können. Dabei ist nach Urban Lankes eine Trennung von Betriebskosten und Aufwendungen für die Weiterentwicklung unumgänglich, sinnvoll sei auch die Differenzierung von Basis- und Applikationsbetrieb. Der Anbieter kann sich so gegen übermässige Forderungen des Kunden absichern; der Abnehmer der Leistungen erhält die Garantie, dass seine Ansprüche im vorgegebenen Rahmen tatsächlich erfüllbar sind. Wichtig: Soll das SLA unter realistischen Bedingungen Bestand haben, müssen zukünftige Entwicklungen wie Geschäftswachstum, Neueröffnung oder Schliessung von Firmenstandorten sowie auch die Integration bestehender Informatiksysteme bei Akquisitionen in die Überlegungen einbezogen werden. Auch die wirklich exakte Bestimmung des aktuellen SLA-Umfelds ist essentiell. Ein Beispiel: Besser als die "geschätzte Anzahl" betroffener Arbeitsplätze hält man im SLA deren exakte Zahl fest - falls sie aus den bestehenden Unterlagen nicht zu ermitteln ist, was gar nicht so selten vorkommt, ist vor dem Abschluss des SLA dringlichst der Einsatz einer Inventarsoftware zu empfehlen.
Service Levels: Genaue Angaben über die vereinbarten Service Levels, üblicherweise unterteilt in Verfügbarkeit (Availability), Leistung (Performance) und Genauigkeit (Accuracy). Neben dem im Normalfall geforderten Level können hier in jeder der drei Kategorien auch ein Minimal-Level für Notfälle sowie ein höheres Level definiert werden, bei dessen Überschreitung der Provider mit Zusatzentschädigungen belohnt wird. Die Verfügbarkeit spielt insbesondere bei kontinuierlich benötigten Serverdiensten eine wichtige Rolle, aber auch bei personalbasierten Dienstleistungen - das Pikett muss nun einmal zu bestimmten Zeiten ohne Fehl zur Verfügung stehen. Sie misst sich in Zeiteinheiten, zum Beispiel Stunden pro Tag oder Tage pro Woche, oder in Zeitprozenten. Mögliche Messgrössen für die Leistung sind das Arbeitsvolumen, zum Beispiel die Anzahl der verarbeiteten Transaktionen oder die Geschwindigkeit. Der Level an Genauigkeit gibt an, ob der Dienst tatsächlich das leistet, was er leisten soll - als Accuracy-Level kann zum Beispiel die maximale Zahl von Fehlern während einer Zeitperiode bestimmt werden. Eines gilt für alle Kategorien: Nicht immer wird durchgängig der höchste Level benötigt. Geschäftskritische Anwendungen verlangen oft Verfügbarkeiten bis 99 Prozent und mehr - aber was ist wirklich geschäftskritisch? In weniger entscheidenden Bereichen - zum Beispiel bei der Netzwerkverbindung eigenständiger Filialen, die nur gelegentlich Ergebnisse an die Zentrale übermitteln müssen - genügen auch beträchtlich geringere Verfügbarkeiten. Wer sich genau überlegt, wo welche Dienste in welchem Mass benötigt werden, kann beim SLA-Abschluss viel Geld sparen.
Indikatoren: Hierbei handelt es sich um die Mess- und Überwachungsmethoden, mit denen die Service Levels ermittelt werden. Bei personalbezogenen Diensten ist die Messung relativ einfach: Die Präsenzzeit von Mitarbeitern ist ohne Schwierigkeiten feststellbar, ebenso die erbrachte Leistung. Availability, Performance und Accuracy von Hardware- und Software-basierten Diensten werden am besten mit Hilfe von Monitoring-Utilities ermittelt. Für Enduser-Anwendungen ergeben sich die besten Resultate aus Benutzersicht: Wie durchgängig und mit welchem Antwortverhalten waren die Services für die Anwender verfügbar? Solche Fragen lassen sich, ebenso wie die Levels von Serverdiensten, die im Hintergrund ablaufen, mit anwendungsspezifischen Monitoring-Paketen, allgemeinen Server- und Netzwerkmanagement-Tools oder aber mit Spezialsoftware wie dem BMC-Produkt Patrol for Service Level Management beantworten. Weitere gängige Monitoring-Produkte stammen beispielsweise von Mercury Interactive, Segue Software, Keynote, Compuware oder SMA. Verschiedene Dienstleistungsunternehmen entwickeln sogar eigene Monitoring-Software, die sie bei ihren Kunden einsetzen, so zum Beispiel Aspectra und Trivadis. Lankes: "Arbeitet man mit marktgängigen Tools grosser Hersteller, wird dies sehr schnell sehr teuer. Es gibt gut funktionierende schlanke Alternativlösungen mit deutlich geringerem Investitionsaufwand."
Kosten: Die für die geleisteten Dienste zu entrichtenden Beträge werden meist pro Zeitperiode definiert. Für klar definierte Leistungen sollten Fixpreise angeboten werden, so Lankes: "Leistungen, die bei bestimmten betrieblichen Ereignissen notwendig sind, müssen transparent zu Fixpreisen verrechnet werden können. Eine SLA-Pricing-Struktur, die nicht so aufgebaut ist, wird meist grosse Reserven zugunsten des Lieferanten enthalten - der Nachteil ist allerdings, dass im voraus kein Kostendach bestimmt werden kann; die Kosten können ereignisabhängig stark variieren."
Massnahmen bei Nichterfüllung: Hier werden die "Strafen" definiert, mit denen der Anbieter zu rechnen hat, wenn die Service Levels nicht erbracht werden. Ohne einschneidende Penalties hat ein SLA keinen Biss. Denkbar und üblich sind Rabatte auf die Dienstleistungspreise, Konventionalstrafen oder die Einberufung eines Meetings zwecks weiterer Verhandlungen. Wichtig für externe SLA: Der Kunde sollte im Fall schwerwiegender Nichterfüllung die Möglichkeit haben, den Vertrag sofort und ohne Kostenfolge zu beenden.
Ausschlüsse: Fallweise kann es ratsam sein, in einem gesonderten Abschnitt Dienste oder Umstände zu definieren, die das SLA nicht abdeckt - zum Beispiel Störungen durch höhere Gewalt oder besonders hohe Geschäftsvolumina zu bestimmten Zeiten.
Übergangsbestimmungen: Zur Absicherung des Kunden am Ende der Vertragsdauer sollte das SLA auch eine Option zur Verlängerung enthalten, die eine Weiterführung der Dienste für eine bestimmte Zeit zu den gleichen Konditionen garantiert. So kann ein allfälliger Providerwechsel ohne Zeitdruck über die Bühne gehen. Diese Fortführungsklausel kann eine Vertragsverlängerung oder einen neuen Vertrag implizieren.
Ebenfalls wichtig: eine Bestimmung, die dem Provider bei Beendigung der Geschäftsbeziehung ein ordnungsgemässes Verhalten vorschreibt. Er darf beispielweise keine Daten zurückhalten, die dem Kunden gehören, und muss bereits bezahlte Softwarelizenzen dem Kunden oder seinem neuen Provider weitergeben.
Zum Schluss dürfen administrative Angaben (organisatorische Verantwortlichkeiten bei den Partnern, Berichtswesen oder regelmässige Überprüfung des SLA) sowie die rechtsrelevanten Unterschriften nicht fehlen.