| Kleine Starthilfe für SLAs | |
| SLAs - die Verhandlungsphase | |
| SLA - das Management |
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?
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.
