IT-Dienstleistungsprodukte systematisch entwickeln

Das systematische Entwickeln von Dienstleistungsprodukten - auch Service-Engineering genannt - gewinnt für unternehmensinterne IT-Dienstleister an Relevanz. Wie es gelingt, die zentralen Bestandteile der Dienstleistungsentwicklung stärker zu professionalisieren, zeigt der Beitrag.

Dienstleistungsentwicklung professionalisieren

Service-Engineering gewinnt für unternehmensinterne IT-Dienstleister an Relevanz. Dennoch stellte das Fraunhofer IAO in einer Studie fest dass die Realität heute noch anders ist: Die meisten Entwicklungsprojekte gehen auf Initiativen einzelner Personen zurück und sind nur selten das Ergebnis eines systematischen Innovationsmanagements für Dienstleistungen. Es wird gefordert die zentralen Bestandteile der Dienstleistungsentwicklung stärker zu professionalisieren.

Das Problem liegt in der überwiegend mangelnden Greifbarkeit von Dienstleistungen. »Den Betrachtungsgegenstand begriffen bzw. wahrgenommen zu haben ist jedoch eine Grundvoraussetzung für die effiziente Gestaltung von Dienstleistungen.« [1] Im Fall von IT-Services wird aus diesem Grund oftmals das Greifbare nämlich die physikalische Infrastruktur mit der Dienstleistung gleichgesetzt. Dies ist falsch weil die Infrastruktur nur eine Ressource für die Erbringung von Dienstleistungen ist. Das Entwickeln von Dienstleistungsprodukten erfordert auch Kundenorientierung Kostenbewusstsein und Prozesskenntnis. In diesem Beitrag beleuchten wir welche Vorteile von der Produktorientierung erwartet werden können wie vorzugehen ist und welche Herausforderungen gemeistert werden müssen.

Die Begriffe Leistung Dienstleistung und Service werden in diesem Zusammenhang synonym verwendet. Weiterhin betrachten wir den Service als das Produkt des Dienstleisters.

Zielsetzungen für die strategische Entwicklung von IT-Dienstleistungsprodukten

Transparenz der Organisation

Das Erfassen der von einer IT-Organisation erbrachten Dienstleistung hat ursprünglich häufig ein einfaches Ziel: Transparenz schaffen. In den IT-Bereichen großer Konzerne ist die Transparenz darüber welche Leistungen durch wen zu welchen Konditionen erbracht werden und wer die Nutzer sind über die Jahre verloren gegangen. Um das aufzuarbeiten werden in vielen Unternehmen heute von der Geschäftsführung Gruppen eingerichtet häufig als eine Art Stabsstelle organisiert die die IT-Organisation neu strukturieren oder zumindest die erbrachten Leistungen katalogisieren.

Effizienzsteigerung durch Konsolidierung

Dabei tritt zutage dass viele Leistungen mehrfach erbracht werden. Beispielsweise werden in unterschiedlichen Rechenzentren organisatorisch getrennt Oracle-Datenbankserver betrieben. Weil die Oracle-Datenbanken für unterschiedliche Anwendungen verwendet werden ist die Teilleistung »Betrieb eines Oracle RDBMS« mehrfach vorhanden. So müssen die Kompetenzen zum Betrieb dieser komplexen Anwendung mehrfach vorgehalten werden. Möglicherweise werden Softwarelizenzen unabhängig voneinander zu ungünstigen Konditionen erworben und nicht zuletzt muss die Datenbank auch auf einer Hardware betrieben werden: Das Problem setzt sich hier fort. In Zeiten knapper IT-Budgets drängt sich der Wunsch nach Konsolidierung dieser Dienstleistungen auf.

Das Ziel durch Konsolidierung IT-Kosten zu senken steht bei gro-ßen Unternehmen auf der Agenda. Beispielsweise hat sich die Siemens AG vorgenommen die Anzahl der Rechenzentren bis 2004 von weltweit 46 auf sieben zu reduzieren [2]. Viele Stolperschwellen tun sich während eines solchen Projekts auf aber die erste ist sicherlich eine falsche Planung aufgrund fehlender Transparenz über die erbrachten Leistungen. Dies kann der Ansporn sein warum für bereits lange existierende Dienstleistungsprodukte im Nachhinein eine Produktdefinition vorgenommen wird.

Dokumentation eines Leistungskatalogs

Erst bei genauerem Hinsehen wird erkannt dass die Produktdefinition nicht nur im Innenverhältnis eine wichtige Rolle spielt. Im Außenverhältnis wird sie sich zukünftig als enormer Werttreiber erweisen. Denn wenn IT-Leistungen nicht mehr von dem Anwender »beantragt« werden sondern durch die IT-Organisation aktiv verkauft werden sollen dann ist ein akkurater Produktkatalog unabkömmlich.

Messbarkeit von Performance-Indikatoren

Messbarkeit ist ein weiteres großes Ziel der Entwicklung von IT-Dienstleistungsprodukten. Zwar wird im IT-Umfeld schon deshalb viel gemessen weil das Messen verschiedener Parameter durch die Technik leicht möglich ist jedoch haben die Messwerte aus zweierlei Gründen oft wenig Aussagekraft:

Das Entwickeln von IT-Dienstleistungsprodukten ermöglicht es einer IT-Organisation produktorientierte Performance-Indikatoren zu erheben die weiter zu geschäftsorientierten Kennzahlen verdichtet werden können. IT-Service-Engineering ist somit auch eine Voraussetzung dafür strategische Führungssysteme wie beispielsweise die Balanced Scorecard bei einem IT-Service-Provider einzusetzen.

Vorgehensweise zur Entwicklung von IT-Service-Leistungen

Wenn ein IT-Dienstleister dazu übergeht seine Leistungen zu entwickeln dann bedeutet dies oftmals einen organisatorischen Eingriff. Es soll eine Aufgabe wahrgenommen werden die bisher beiläufig wenn überhaupt erledigt wurde. Dazu muss eine neue Funktion eingerichtet werden die des Produktmanagers und es müssen die Prozesse neu strukturiert werden. Erschwerend kommt hinzu dass der neue Produktmanager nicht auf der grünen Wiese anfängt aber die bestehenden Dienstleistungen nicht definiert und wahrscheinlich nur schlecht dokumentiert sind. Diese Konstellation erfordert Fingerspitzengefühl und eine mehrstufige auf die Organisation abgestimmte Einführungsmethode.

Plattformstrategie

Der Begriff »Plattformstrategie« ist aus der Automobilindustrie bekannt. Gemeint ist damit eine Standardisierung von Komponenten. Die Idee dass ein Seat auch mit einem Golf-Motor und ein Skoda mit einem Audi-Fahrwerk gebaut werden kann hat dem VW-Konzern geholfen die Produktion und die Logistik zu optimieren.

Dieser Ansatz kann auch erfolgreich in den IT-Betrieb übernommen werden. Die Produkte respektive Autos sind IT-Dienstleistungen die dem Kunden verkauft werden. Die Komponenten respektive Motor Fahrwerk sind Teilleistungen. Das Ziel ist nun durch Standardisierung eine Teilleistung möglichst nur einmal zu erbringen und diese in möglichst viele Produkte einfließen zu lassen.

Je höher die Granularität der Teilleistungen ist desto erfolgreicher wird dieses Ziel erreicht. Deshalb drängt es sich auf die Teilleistungen wiederum in Komponenten zu zerlegen. Durch ein solches n-stufiges Modell wird eine komplexe Dienstleistung in Teilleistungen zerlegt und schließlich einzelnen Ressourcen sei es Personal oder Infrastruktur zugeordnet.

Abb. 1:

Durch Dekomposition wird ein kundenspezifischer Service in seine Komponenten zerlegt. In diesem Beispiel ist der »Workplace Service« in UML-Notation dargestellt. [4]

Es entsteht ein Abhängigkeitsgraph. Dieser Abhängigkeitsgraph erlaubt uns von oben nach unten aus den Anforderungen des Kunden an die Gesamtdienstleistung die Zielvorgaben einzelner Teilleistungen und Ressourcen abzuleiten. In umgekehrter Richtung können die gemessenen Performance-Indikatoren der Ressourcen entlang des Graphs verdichtet werden und führen so zu einer Qualitätsaussage über die erbrachte Dienstleistung.

Klassen von Teilleistungen

Zur Identifikation der Teilleistungen in einer bestehenden IT-Organisation ist es hilfreich zunächst Leistungsklassen festzulegen. Dem Paradigma der Objektorientierung bei Analyse und Design folgend können Leistungsklassen voneinander abgeleitet sein und Eigenschaften vererben. Zunächst wird also eine allgemeine Klasse »IT-Service« erstellt und ein Schema definiert wie dieser IT-Service beschrieben wird.

Von dieser Oberklasse werden weitere Klassen abgeleitet also beispielsweise »Netzwerk-Service« »Anwendungs-Service« und »System-Service«. Dies kann nun weiter verfeinert werden bis man bei sehr konkreten Teilleistungen angekommen ist wie etwa »Betrieb eines Oracle RDBMS«. Beim Festlegen dieser Klassenhierarchie kann man sich vom logischen Denkvermögen leiten lassen sollte aber auch folgende zwei Aspekte berücksichtigen: