Eine gute Lösung, Standardbauteile so zu kombinieren, dass sie ein individuelles Produkt ergeben, haben die Automobilhersteller gefunden. Auf deren Web-Seiten können potenzielle Kunden mit Hilfe eines Konfigurators Autos ganz nach eigenem Geschmack zusammenstellen. Für die Gestaltung von SLAs gibt es bislang weder einheitliches Layout noch einen "Konfigurator". Hintergrund ist, dass SLAs letztlich von Kunden bestimmt werden und jeder Klient andere Anforderungen an die auszulagernden IT-Services oder Prozesse hat. Ziel eines SLA ist es, einen gemeinsamen Nenner für einen individuellen Dienstleistungsvertrag zu finden. Ohne diese Übereinkunft ist es schwer, Konflikte und regelmäßig aufkommende Diskussionen während und nach der Vertragslaufzeit effizient zu schlichten. Je weniger Details im Vorfeld bestimmt werden, desto mehr Spielraum bietet sich nach Vertragsabschluss - für Streit. Ein Beispiel: Welche Vertragsseite muss sich um eventuell benötigte Sonderschriften für Textverarbeitungsprogramme bei einem Vertrag zum Desktop-Outsourcing kümmern, wenn dies im Vorfeld nicht schriftlich fixiert wurde?

SLAs - die Startphase

Der Kunde muss auf die IT-Auslagerung vorbereitet sein. Das klingt banal, ist aber gerade in kleineren Unternehmen nicht die Regel. Der DV-Leiter sollte die geschäftlichen Anforderungen kennen, seine IT analysiert und viel Vorarbeit geleistet haben. Nur so kann er ein SLA-Abkommen erhalten, das sowohl den eigenen Ansprüchen gerecht wird, als auch den Dienstleister nicht übermäßig unter Druck setzt.

Beide Vertragsseiten haben den SLA-Rahmen mit Inhalten zu füllen. Bereits im Request for Proposals (RFP - die Ausschreibung) muss der Kunde definieren, was er an Servicequalität (Service-Level) erwartet. Nur dann kann der Dienstleister ein vernünftiges Preisangebot kalkulieren. Wenn im RFP salopp der "Server-Betrieb" ausgeschrieben wird, bindet dies im Nachhinein durch zusätzlichen Abstimmungsaufwand viele Ressourcen auf beiden Seiten. Wer etwas auslagern will, muss in der Lage sein, seine technischen und geschäftlichen Bedürfnisse möglichst exakt zu beschreiben. Das geleistete Niveau der Anforderungen ist nach dem RFP noch verhandelbar, damit auf beiden Seiten Preis und Leistung ins Gleichgewicht finden.

Der Kunde macht seine Vorgaben für den Dienstleistungsvertrag, denn nur er weiß, wie kritisch gewisse durch die IT unterstützte Prozesse sind. Typisches Beispiel ist die Personalabrechnung: Wenn diese Anwendung zwei Tage ausfällt, kann ein Unternehmen das in der Regel leicht verschmerzen. Sollte jedoch ein System für die Auftrags- und Bestellabwicklung beziehungsweise ein papierloser Geschäftsprozess für einen vergleichbaren Zeitraum nicht zur Verfügung stehen, hat das unter Umständen gravierende Konsequenzen. Der Kunde weiß, was wie kritisch ist, und sollte seine Prozesse oder Anwendungen in verschiedene Kategorien einstufen - von unkritisch bis geschäftskritisch.

Anschließend verhandelt der Kunde mit dem Dienstleister über die Ausprägung dieser umschreibenden Begriffe. Für jeden Prozess muss die Verfügbarkeit sämtlicher IT-Komponenten, etwa Server, Speicher, Betriebssystem, Netze und Desktops, definiert werden. Bei einer gewünschten Verfügbarkeit von 99,9 Prozent sollte beispielsweise festgelegt werden, in welchem Zeitraum (Monat, Jahr) gemessen wird, ob während der Betriebszeit gemessen wird oder ob feststehende Wartungsintervalle aus der Berechnung ausgeklammert werden sollen. Die Definitionen im Rahmen der SLAs sind außerordentlich wichtig, doch häufig werden sie vergessen oder nicht präzise ausformuliert. Typisches Beispiel hierfür ist die maximale Ausfallzeit MTTR (Mean time to repair) eines Prozesses am Stück. Ein Promille eines ganzen Jahres ist im schlimmsten Fall eine komplette Schicht oder ein Arbeitstag im Büro einschließlich Mittagspause.

SLAs - die Verhandlungsphase

An erster Stelle steht das Gespräch der internen IT mit dem "betroffenen" Fachbereich, denn die eigenen IT-Experten kennen die Prozesse des Unternehmens in der Regel besser als ein externer Dienstleister. Wurden bereits SLAs zwischen der IT und den internen Kunden vereinbart, ist das ein großer Vorteil, denn darauf lässt sich aufbauen. Leider gibt es sehr selten brauchbare SLAs innerhalb eines Unternehmens, obwohl sie auch der internen Zusammenarbeit zugutekommen. Wurde nichts vereinbart, gehen interne Anwender wie selbstverständlich davon aus, dass etwa der Helpdesk an allen Tagen rund um die Uhr verfügbar ist und innerhalb von zehn Minuten die optimale Lösung präsentiert.

Eine sinnvolle Gestaltung, die das IT-Budget des Unternehmens nicht sprengt, wäre beispielsweise ein Helpdesk, der an fünf Wochentagen mit acht Stunden eine Reaktionszeit von 30 Minuten und eine Lösungszeit von zwei Stunden verspricht. Jeder Kunde möchte hohe Qualität für wenig Geld. Die Dienstleister streben einen hohen Verdienst mit möglichst geringem Aufwand an. Die Balance zwischen Preis und Leistung wird mit Hilfe eines SLA gefunden. Durch verschiedene Service-Level-Stufen lassen sich die Kosten und Leistungen bedarfsgerecht angleichen.

SLA- die Struktur

Für die gute Zusammenarbeit der Partner sind verständliche Leistungsbeschreibungen wichtig. Dort gehört hinein, was der Dienstleister überhaupt für den Kunden leisten soll. Wird der Server nur in ein Rechenzentrum gestellt und an Strom- und Datennetze angeschlossen? Soll das Betriebssystem aufgespielt werden? Wird es sogar gepatcht, und ist der Dienstleister für Upgrades zuständig? Wird der Kunde überdies beraten? Dies alles muss ebenfalls in einem SLA beschrieben werden. Nicht nur die Qualität der Services (die Service-Levels), sondern auch die Leistungsbeschreibung ist eine entscheidende Komponente. Diese wird vom Dienstleister vorgegeben, abhängig davon, was der Kunde wünscht.

SLA - die Konflikte

Häufig muss der Outsourcing-Deal einschließlich der SLAs zu einem Stichtag unter Dach und Fach sein. Dies macht sich in der Qualität der Vereinbarungen bemerkbar - je größer der Zeitdruck, desto schlechter die Qualität. Gerade Anwender ohne SLA-Erfahrung sollten sich unbedingt Zeit nehmen. Das Problem ungenauer SLAs findet sich häufig in kleineren IT-Ausgründungen, die Services für den Mutterkonzern und zum Teil auch für externe Kunden betreiben. Größere Dienstleister haben oft entsprechende Prozesse etabliert, um SLAs zu gestalten.

Erfahrungsgemäß entzünden sich Diskussionen oft an der Zahl der Software-Updates und -Upgrades, denn die diesbezüglichen Vereinbarungen sind meist schwammig beschrieben. Beim SAP-Transportverfahren etwa, der Übernahme von Definitionen und Änderungen aus dem Test- und Entwicklungssystem ins Produktivsystem, fehlen regelmäßig Angaben dazu, wie viele Transporte der Dienstleister unterstützen muss.

Fachliche und vertragliche Lücken sind ein Risiko für beide Seiten. Am häufigsten versäumen es die Vertragsparteien, die zu erbringende Leistung genau zu beschreiben. Jede Seite wird versuchen, vorhandenen Spielraum für sich zu besetzen. Dies schafft Konfliktpotenzial, durch das die Partnerschaft in Mitleidenschaft gezogen wird. Selbst wenn es in Streitfällen zu einer Lösung kommt, ist das Verhältnis bereits gestört. Zudem hat der Konflikt unnötig Ressourcen gebunden.

SLA - der Umfang

SLAs beziehen sich auf die einzelnen zu erbringenden Services. So vereinbaren die Partner in der Regel separate Vereinbarungen etwa für den Desktop-Bereich, den E-Mail-Betrieb sowie für Server, Speicher und Netze. Jedes SLA kann (ungefähr) zwischen fünf und 15 Seiten, manchmal auch bis zu 25 Seiten umfassen. Der Umfang richtet sich nach den Details, der Struktur und den Anforderungen des Kunden - etwa wenn der Desktop-Betrieb an einem Standort, an verschiedenen Standorten in Deutschland und Europa oder auch in den Niederlassungen des Unternehmens in Übersee gewünscht wird.

In jedes SLA sollten außerdem spezifische Definitionen der verwendeten Begriffe integriert werden, beispielsweise zur Berechnung der geleisteten "Verfügbarkeit" oder zur Erläuterung der "Reaktionszeit", denn diese Termini sind nicht allgemeingültig definiert. SLAs mit einem Umfang von 100 Seiten, die sämtliche Aspekte des erbrachten Service betreffen, werden von keiner Seite gelesen und sind daher sinnlos. Der SLA-Entwurf ist ein Balanceakt zwischen Genauigkeit, Detailtreue und Lesbarkeit.

SLA - das Management

Wer mit dem Outsourcing das komplette Fachwissen aufgibt, um die Kosten weiter zu senken, begeht einen fatalen Fehler. Die "Retained Organization", also die "Übriggebliebenen", dient als Schnittstelle zu den Dienstleistern und soll neben der Kontrolle und Steuerung der Partnerschaft auch eine komplette Abhängigkeit des Unternehmens in Sachen IT von externen Ratgebern verhindern. In der Regel kommuniziert die Kontrollorganisation wöchentlich mit den Dienstleistern, um Probleme zu beheben und die Verantwortung für Fehler zu klären. Regelmäßige Treffen für die Nachbetrachtung sind überaus wichtig. Zudem müssen interne IT-Spezialisten die Rechnungen des Dienstleisters kontrollieren - Anwender sollten dies Aufgabe nicht auf die leichte Schulter nehmen. In Unternehmen mit großen Outsourcing-Kontrakten können bis zu 40 Mitarbeiter permanent damit beschäftigt sein, den IT-Dienstleister zu überprüfen.

SLA- die Pönalen

Konventionalstrafen für den Fall, dass die zugesagte Leistung nicht erbracht wird, finden sich fast nie bei kleineren Unternehmen, die ihre IT-Töchter ausgelagert haben und noch an ihnen beteiligt sind. Es gäbe keinen Sinn, Geld aus der rechten in die linke Tasche zu verschieben. Aber auch in anderen Fällen sind Pönalen nicht unbedingt empfehlenswert. Zwar sind Vertragsstrafen ein gutes Druckmittel des Kunden, um den Dienstleister relativ unkompliziert für Fehler zu "bestrafen". Jedoch kalkuliert der Dienstleister die potenziellen Pönalen und das Risiko in seinen Preis ein. Wenn der Dienstleister seine Arbeit vertragsgemäß leistet, hat er die "Rücklage" für die Pönalen zusätzlich verdient. Für Pönalen-Modelle gibt es keinen Standard. Sie sind nach Belieben verhandelbar.

SLA- die Benchmarks

Im Master-Service-Agreement, dem Rahmenvertrag, sind allgemeine Punkte rechtlicher und finanzieller Natur des Abkommens geregelt. Dort sollte eine Klausel aufgenommen werden, die besagt, dass nach einer gewissen Eingewöhnungszeit - beispielsweise zwei Jahre - die vereinbarten Preise mit dem Marktüblichen verglichen werden. Beide Parteien haben üblicherweise das Recht, den Benchmark-Dienstleister vorzuschlagen. Die Kosten der Analyse teilen sie in der Regel. Hintergrund ist der rasante Preisverfall im Markt, der von Anwendern gerne zu Nachverhandlungen genutzt wird.

SLA - das Vertragsende

Spezielle Service-Levels für das Ende der Vertragslaufzeit schützen den Kunden, wenn er den Kontrakt nicht verlängern will. Durch Ausstiegsklauseln für den Fall, dass der Dienstleister gewisse Bedingungen nicht erfüllt, erhält der Klient zudem ein Sonderkündigungsrecht. Letzteres findet sich relativ häufig. Dagegen gibt es kaum Service-Levels, die den Übergang zu einem anderen Provider regeln. Der Sonderfall, dass die IT wieder zurück ins alte Unternehmen geholt wird, kommt kaum vor. Dennoch ist es ratsam, bereits zu Vertragsbeginn eine Regelung zur Mitwirkungspflicht des Dienstleisters für den Fall der Vertragsauflösung zu treffen. Darin sollte zweifelsfrei geklärt werden, ob der Service-Provider aktiv am Übergang beteiligt ist und wer für die dadurch anfallenden Kosten aufkommen muss. (jha)

Einen Podcast (MP3-Datei) zur Gestaltung von SLAs finden sie hier.