| Nicht ohne die Anwender | |
| Der Regelkreis kombiniert technische SLAs mit der Anwendererfahrung |
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.
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.
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.
