SLAs sind entwickelt worden, weil die internen oder externen Abnehmer von IT-Diensten mehr Transparenz und Kontrolle der Leistungen verlangten. Kriterien waren bisher primär Kosten und Qualität. Gemessen und bewertet wurden die Leistungen so, wie sie sich aus Sicht der IT darstellen: Auf der Systemebene werden Kosten und Verfügbarkeit einzelner Komponenten festgelegt (zum Beispiel: Server 99,5 Prozent oder Netz 99,2 Prozent) und nach verschiedenen Qualitätsstufen gegliedert. Ergänzende Vereinbarungen regelten, wie die Partner bei Abweichungen verfahren würden.

Diese Kriterien reichen jedoch nicht mehr aus, um die IT zu bewerten. Denn zunehmend wollen Unternehmen wissen, welchen Nutzen die IT für das Kerngeschäft hat.

Techniklastige SLAs

Die Schwäche herkömmlicher Servicevereinbarungen besteht darin, dass sie weder die Prozesse noch den Anteil der IT an der Wertschöpfung angemessen abbilden. Die Anwender erkennen weder, wie sich technische Entscheidungen auf das Geschäft auswirken (ob etwa Kosten infolge neuer Technologien sprunghaft steigen), noch wie sich strategische Entscheidungen im Kerngeschäft beziehungsweise neue regulatorische Vorgaben (wie die Pflicht zur E-Mail-Archivierung, Compliance etc.) auf die technische Ausstattung niederschlagen.

Die entscheidende Frage lautet: Wer übernimmt die Verantwortung und Initiative, um die bestehende Lücke zu füllen? In den herkömmlichen SLA-Vereinbarungen obliegt diese Aufgabe dem Kunden des IT-Dienstleisters. Um beurteilen zu können, ob die notwendigen Leistungen angemessen sind, benötigt er technisches Detailwissen. Wichtige Komponenten für den Gesamtprozess bleiben eventuell außen vor.

Notwendig sind deshalb weitere Bezugsgrößen zur Leistungsbeurteilung. Diese Aufgabe erfüllen komplexere IT-Produktvereinbarungen. Sie können je nach Reifegrad in fünf Stufen eingeteilt werden:

• Systemorientiert. Dies sind die beschriebenen traditionellen SLAs. Sie beziehen sich auf das technische System. Beispiel: Verfügbarkeit des Servers XY von 99 Prozent.

• Serviceorientiert. Solche Vereinbarungen beschreiben einen kompletten Dienst, der sich aus verschiedenen technischen Komponenten zusammensetzen kann. Beispiel: Verfügbarkeit des E-Mail-Service von 98 Prozent wird garantiert.

• Kundenorientiert. Vereinbarungen beziehen sich ebenfalls auf Dienstebene, sind aber weniger technisch, sondern stärker in den Denkkategorien des Anwenders abgefasst. Beispiel: Der E-Mail-Service darf pro Monat maximal eine halbe Stunde ausfallen.

• Business-orientiert. Hier werden Vereinbarungen für eine ganze Applikation getroffen, in denen alle für die Leistungserbringung notwendigen Services enthalten sind. Beispiel: ein Sachbearbeiter-Arbeitsplatz für das SAP-Modul HR mit allen Diensten wird garantiert, wobei die maximale Ausfalldauer vier Stunden pro Jahr betragen darf, gestaffelt nach verschiedenen Qualitätsanforderungen (Kernzeiten, Restzeiten etc.).

• Value-Chain-orientiert. Dies ist die anspruchvollste Vereinbarungsform. Beispielsweise lässt sich für die Logistikbranche eine garantierte Zeit zur Bearbeitung eines Frachtbriefs definieren.

Auf Standards aufbauen

IT-Produkte werden nach dem Baukastenprinzip zusammengesetzt. Um die notwendige Transparenz und Vergleichbarkeit zu schaffen, sollte man dabei bis zu 80 Prozent Standardleistungen zugrunde legen. Derzeit gibt es Standards für die Systemebene (zum Beispiel Managed MIPS) und die Dienstebene (etwa Desktop- und E-Mail-Service). Solche für die Applikationsebene bilden sich heraus (wie End-to-End-Betrieb eines SAP-Moduls). Hinter derartigen komplexen Produktvereinbarungen stehen wiederum unterschiedlich detaillierte SLAs bezüglich Umfang und Qualität.

Weitere Verfeinerungen der Produktstandards werden sich etablieren. Die Definition unterscheidet sich auch nach Branchen; so hat eine Investmentbank andere Ansprüche an einen Desktop-Service als etwa das produzierende Gewerbe.

Übertriebene Granularität

IT-Produkte werden von unten nach oben aufgebaut. Zunächst müssen die darin enthaltenen IT-Größen bewertet werden. Dabei gilt es, aggregierbare Messgrößen zu identifizieren, die sich auf höherer Ebene zu sinnvollen Aussagen verdichten lassen. Hier ist eine pragmatische Auswahl sinnvoll, damit das Modell beherrschbar ist. Denn der Wunsch nach Transparenz verleitet oft zu übertriebener Granularität.

Bei der Vereinbarung von IT-Produkten steigt mit jedem Reifegrad die Verantwortung der IT für das Business. Der CIO ist nicht nur für einzelne Komponenten verantwortlich, sondern auch für deren Zusammenspiel. Wird zum Beispiel auf Systemebene für Server und Netz jeweils eine Verfügbarkeit von 90 Prozent garantiert, beträgt auf der Dienstebene die Gesamtverfügbarkeit nur 81 Prozent, auf der Applikationsebene - wenn zwei entsprechende Dienste zugrunde liegen - sind es dann nur noch 65 Prozent. Möchte der Kunde dennoch eine Gesamtverfügbarkeit von 90 Prozent, muss die IT - da sie für das Ergebnis geradesteht - zusätzliche Redundanzen schaffen.

CIO muss werten können

Einigen sich Anwender und Dienstleister auf Qualitätsmerkmale, die sich an der Wertschöpfungskette orientieren, muss sich der Abnehmer der IT-Leistungen überhaupt nicht mehr mit Verfügbarkeitsaspekten befassen. Deshalb müssen hier die Produkte am weitesten entwickelt sein. Der CIO muss beurteilen können, welchen Einfluss IT-Leistungen auf die Geschäftsentwicklung haben. Wurden Garantien vereinbart, muss er die damit verbundenen Risiken erkennen und bewerten. Dazu braucht er IT- und Fach-Know-how.

Reifegrad entscheidet

Die IT kann eine solche Verantwortung nur tragen, wenn sie selbst und die Gesamtorganisation darauf vorbereitet sind. Der Reifegrad erstreckt sich auf Mitarbeiter, Prozesse, Unternehmenskultur, Management und Technik.

Mit der Einführung von IT-Produktvereinbarungen wird die Schnittstelle immer weiter zum Anwender verlagert, die Dienstleister dringen also immer tiefer in die Organisation ihrer Kunden vor. Aber eine Systemsicht ist natürlich weiterhin notwendig, denn die IT muss ihre Kostentreiber kennen und eine Verbindung zu Geschäftsentscheidungen herstellen können. Beste Voraussetzung dazu ist die Erfassung und Abbildung der IT-Größen in einem normierten, funktionalen Modell und ihre Verknüpfung mit betriebswirtschaftlichen Einflussgrößen. So lässt sich sicherstellen, dass verschiedene Perspektiven auf identischen Basisgrößen aufbauen. (jha)