Service-Level-Agreements (SLAs) haben sich in den meisten IT-Organisationen als Basis für eine Leistungsvereinbarung etabliert. Während zunächst externe Dienstleister SLAs mit ihren Kunden abgeschlossen haben, gehen nun auch interne IT-Organisationen mit ihren Fachbereichen dazu über. Aber das System ist bei weitem nicht perfekt. Die vereinbarten SLA-Parameter wie zum Beispiel Reaktionszeiten, Wiederherstellungszeiten und Durchsatzraten werden auf Einzelsystembasis abgeschlossen. Eine Gesamtsicht auf den jeweiligen Business-Prozess fehlt. Dem Nutzer jedoch hilft der Blick auf die Verfügbarkeit eines Einzelsystems oder einer Netzwerkstrecke nicht, wenn sein Arbeitsplatz nicht funktioniert. Oft fehlt auch schon die konkrete Beschreibung der Anforderungen auf der Arbeits-platzebene. Arbeitsplatzfunktionen jedoch setzen sich immer aus einer ganzen Reihe von einzelnen Technologiekomponenten zusammen, die erst in ihrer Summe die Anwendung zum Nutzer bringen.
Die Leistung am IT-Arbeitsplatz bleibt intransparent
In vielen IT-Kundenbeziehungen zeigt sich darüber hinaus, dass die vereinbarten SLAs für Einzelkomponenten weitgehend eingehalten werden, die Leistung des einzelnen Arbeitsplatzes aufgrund der Komplexität jedoch intransparent bleibt. Und die User Perception, das heißt die subjektiv empfundene Zufriedenheit des Endkunden, wird meist gar nicht gemessen, weil der Provider oft die damit geschaffene Transparenz scheut. Ganz offensichtlich existiert aus den genannten Gründen eine Diskrepanz zwischen vertraglichen Vereinbarungen und den tatsächlichen qua-litativen Anforderungen der Fachbereiche an die IT.
Die Lösung des Problems ist eine Leistungsvereinbarung auf Prozessebene, wie sie auch schon von vielen Providern angestrebt wird. Ausgehend von den Business-Prozessen müssen die Anforderungen an die IT nicht auf der Basis von Einzelsysteme, sondern vielmehr übergreifend in eine End-to-End-Sicht übertragen und auf dieser Ebene vereinbart werden. Heutige Organisation verfügen jedoch noch nicht über das notwendige Wissen und die Mittel, derartige SLAs zu entwickeln und zu vereinbaren.
End-to-End-SLAs: Viele sind gescheitert
Ein konkretes Beispiel hierfür ist ein großes Dienstleistungsunternehmen. Die Verantwortlichen haben versucht, SLAs auf Basis der Kernprozesse und daraus abgeleiteter Transaktionen zu definieren. Ziel war es, System- und Einzel-SLAs zu vermeiden. Stattdessen sollten Vorgaben entwickelt werden, wie lange zum Beispiel eine Suchanfrage oder Stornierung dauern sollte. Das Problem bestand darin, dass bei den Prozessen nicht ein, sondern viele hoch integrierten Systeme auch von Fremdanbietern involviert waren. Letztlich scheiterte das Unternehmen daran, die Prozessvorgaben auf die Einzelsysteme zu übertragen, um zu ermitteln, wie viel Zeit eine einzelne Komponente pro Suchvorgang oder Stornierungsprozess benötigt. Sobald mehrere Systeme, möglicherweise auch von mehreren Dienstleistern, involviert sind, muss in letzter Konsequenz die Prozessvorgabe wieder auf Systemebene heruntergebrochen werden, da niemand den Betrieb des gesamten Prozesses verantwortet.
Ein weiteres Projekt bereitete einem großen Logistikunternehmen Kummer. Hier hatten IT und Fachbereiche schon seit Jahren SLAs pro Einzelsystem etabliert, bevor die Verantwortlichen den Versuch begannen, End-to-End-SLAs zu entwickeln. Hierbei sollten sämtliche in die Leistungskette integrierten Systeme eines Service zusammen betrachtet werden. Neben der jeweiligen Applikation und der dazugehörigen Hardware mussten dazu auch alle Netzwerkkomponenten bis hin zum Frontend einbezogen werden. Das führte dazu, dass selbst bei ziemlich hohen Anforderungen an die Einzelsystemebene in der Addition der Komponenten eine derart schlechte Leistung zu erwarten war, dass sie dem Fachbereich nicht mehr plausibel vermittelt werden konnte. In beiden Fällen scheiterten die Verantwortlichen also daran, einem nachvollziehbaren Ansinnen der Nutzer zu entsprechen.
Einen Podcast (MP3-Download) zur Gestaltung von SLAs finden hier.
Der Regelkreis kombiniert technische SLAs mit der Anwendererfahrung
Was lässt sich tun, wenn die System-SLAs die Business-Anforderungen nicht abbilden und eine End-to-End-Prozessbetrachtung an der Umsetzung scheitert? Es gibt eine pragmatische Lösung, die im Rahmen mehrerer Kundenprojekte entwickelt wurde und das Service-Level-Management voranbringt. Die System-SLAs werden dabei mit einem kontinuierlichen Perception-Reporting und dahinterliegendem Service-Level-Management kombiniert. Hierüber ist es möglich, die vorhandenen SLAs mit der aus Anwendersicht wahrgenommenen Leistung der IT abzugleichen. Dadurch lassen sich Service-Level-Vereinbarungen mit Optimierungspotenzial identifizieren und können im Rahmen der kontinuierlichen Verbesserungen an den Bedarf angepasst werden. Wenn zum Beispiel die SLAs weitestgehend eingehalten werden, das Perception-Reporting hingegen ein schlechtes Ergebnis liefert, könnte das ein Indiz für zu schwach formulierte SLAs sein. Hier bekommt der Kunde nicht, was er benötigt. Wenn hingegen das Perception-Reporting gut ausfällt, das SLA-Reporting aber die eine oder andere rote Ampel zeigt, sollte überprüft werden, ob die SLAs nicht zu anspruchsvoll vereinbart sind. In dies der Fall ließe sich am Budget sparen.
Das Reporting muss Daten logisch verknüpfen
Wie sieht ein Perception-Reporting nun in der Praxis aus? Zunächst muss festgelegt werden, welche Leistungen im Rahmen eines Perception-Reportings von den Kunden oder der Fachseite überhaupt bewertet werden sollen. Da die subjektive Einschätzung mit den SLAs abgeglichen wird, müssen sie logisch zueinanderpassen. Es muss also klar sein, welche konkreten SLAs sich hinter einer Perception verbergen. So könnte eine Bewertung des User Helpdesk durchaus sinnvoll sein, während eine zu allgemein gehaltene Perception-Bewertung des Applikationsbetriebs wenig Rückschluss auf die einzelnen Systeme gibt.
Ferner ist darauf zu achten, dass sich die Leistung von den Kunden oder dem Fachbereich überhaupt differenziert bewerten lässt. Hier ist der Dialog mit den "Bewertern" und eine Aufklärung über das Verfahren zwingend erforderlich.
Dafür sollte ein Personenkreis klar definiert werden. Das ist wichtig, um Vergleichbarkeit und eine zeitliche Entwicklung der Wahrnehmung zu gewährleisten. Nur so lässt sich Aussagekraft erzielen. Deswegen ist es auch wichtig, Personen zu benennen, die regelmäßig mit den Systemen arbeiten und die Leistungen auch wirklich beurteilen können. Führungskräfte sollten hier eher die Empfänger von Reports als Bewertungspartner sein.
Die intensive Kommunikation mit den Fachbereichen bleibt
Zudem müssen die Verantwortlichen die Frage klären, in welcher Form und in welchem Zeitabstand die Regelabfrage betrieben werden sollen. Dafür gibt es verschiedene Tools und Verfahren. Während einige Unternehmen dafür umfangreiche Web-Anwendungen programmiert haben, begnügen sich andere Unternehmen mit einfachen Excel-Lösungen. Der Rhythmus beziehungsweise der Zeitpunkt für die Abfrage hängt stark von etablierten Gremienstrukturen und der Art des Service ab, der betrachtet werden soll.
In der Praxis haben sich einfache Bewertungen bewährt, etwa in Form von Ampel- oder Schulnotensystemen. Wichtig ist, dass der Beurteiler bei schlechten Bewertungen eine kurze Begründung angibt. Das erleichtert die Ursachenanalyse.
Aber: Auch ein noch so gut konzipiertes Perception- Reporting verbessert die Servicequalität nur, wenn auch der Dialog mit den Kunden oder Fachbereichen gesucht wird. Erst eine gemeinsame Bewertung der Ergebnisse und Vereinbarung von Maßnahmen zwischen IT und Fachbereich sorgt für eine kontinuierlich steigende Zufriedenheit der Anwender auch ohne die Ausgestaltung von End-To-End-Business-SLAs. (jha)
Einen Podcast (MP3-Download) zur Gestaltung von SLAs finden hier.