IT-Dienstleister komplett umgekrempelt

Rushhour im rumänischen Zementwerk: Das Beladen eines Lkw darf sechs bis sieben Minuten dauern. Dann wird gewogen, und der Fahrer holt sich den Lieferschein. Der gesamte Vorgang dauert keine zehn Minuten – normalerweise. Doch dann streikt der Drucker. Ohne Lieferschein darf der Betonlaster aber nicht vom Hof. Der Dispatcher in der Verladestation schaltet den Drucker an und aus, fährt den PC runter und wieder rauf. Der Lkw-Fahrer schimpft. Die Jungs auf dem Bau warten. Der Zementmann meldet die Störung per Mail an die Holcim Services EMEA (HSEE) in Madrid. Die Mail muss allerdings erst noch ein externer Dienstleister ins Englische übersetzen. Derweil bildet sich eine Schlange hinter dem Lkw. Ein SAP-Spezialist versucht nachzuvollziehen, was passiert ist, seit das Signal von der rumänischen Waage an den SAP-Server in den USA gesendet wurde. Nach einigem E-Mail-Pingpong zwischen Rumänien, Übersetzungsbüro und Madrid wird klar, dass der Druckertreiber sich nicht mit einem Spiel verträgt, das ein Wachmann nächtens auf den PC geladen hat.

Dieser kleine Fall beschreibt, womit sich die Holcim-IT in Europa lange herumgeärgert hat. Der Customer-Service für die 22 europäischen Niederlassungen und ihre Werke war im Jahr 2006 schlecht und teuer, die Kundenzufriedenheit im Keller. Die Ursache dafür lag ironischerweise in den Erfolgen der Holcim-IT. Wo früher die Länder ihre Infrastruktur und Applikationen selbst verantworteten, sorgen jetzt weltweit sechs Shared Service Center dafür, dass SAP R/3 in der Version 4.6 C läuft. 30 Prozent der Kosten hat Holcim mit diesem zentralen Ansatz gespart. Außerdem hat die IT jedes Wachstum verkraftet: "Wir waren eine reinrassige Projektorganisation. Da hat uns keiner etwas vorgemacht", erklärt Jan Babst, seit drei Jahren Holcim-CIO für EMEA und Chef des Shared Service Center. "Leider wurde zu wenig Wert auf den Betrieb gelegt."

An ISO 20.000 orientiert

Mit der Konsolidierung auf ein Template verlagerte sich die Verantwortung für den Betrieb und den Support ebenfalls nach Madrid und auf die dort angesiedelte 140-köpfige Mannschaft. Allerdings passte man die Organisation nicht an die neuen Bedingungen an. Die kleinen IT-Mannschaften vor Ort berichteten an den CFO der Landesorganisation und nicht an das Shared Service Center. Eine einheitliche Steuerung (Governance) existierte genauso wenig wie ein einheitliches Incident- und Change-Management. Einen Service-katalog und nachvollziehbare Service Level Agreements suchte man ebenfalls vergebens.

In der Folge eskalierte die Situation. Praktisch alle Niederlassungen meldeten nur noch Incidents mit höchster Priorität. Change-Requests stauten sich. Holcim musste auf viele externe Berater zurückgreifen, die das Serviceproblem in den Griff bekommen sollten. Das erhöhte die Kosten erheblich. Die mit der Konsolidierung erreichten Einspareffekte drohten zu versickern. "Irgendwann war klar, dass wir das Problem an der Wurzel anpacken müssen", erklärt Babst. Man beschloss, sich an der ISO-Norm 20.000 für IT-Service-Management zu orientieren.

Doch zunächst brauchte Babst eine Standortbestimmung. Er ließ die kleine Beratertruppe dprp aus München Ende 2006 einen "IT Health Check" durchführen. Im Prinzip lässt sich damit prüfen, inwieweit einzelne IT-Prozesse standardisierten Vorgaben wie ISO, ITIL, Cobit oder CMMI entsprechen. Der im Falle Holcim angewandte Health Check misst den Reifegrad einer IT-Organisation in vier Stufen, die zwar auf der ISO-Norm 20.000 basieren, aber von dprp angepasst wurden.

Fernziel "Business Engineer"

Die unterste Stufe "IT-Department" steht dabei für eine Organisation, die nur die IT beherrscht. Die Stufe "Service-Provider" ist laut Babst auf der gleichen Ebene anzusiedeln wie IBM oder Accenture: "Sie können zwar Prozesse abbilden, aber keine spezifischen." Der "Business Partner" stellt firmenspezifische Services zur Verfügung. Und auf der Stufe "Business Engineer" kann die IT schließlich auch Geschäftsprozesse managen, das heißt zentral für die Landesorganisationen abwickeln.

Im Fall Holcim führten die dprp-Berater mit den wichtigsten IT-Verantwortlichen in den Standorten und mit dem Management-Team im HSEE Interviews zum Stand der Dinge. Wie steht es um die Fähigkeiten der Mitarbeiter? Existieren Servicekataloge? Werden Service-Level-Agreements eingehalten? Im Anschluss an diese Einzelinterviews wurde in einem halbtägigen Workshop mit den acht Mitgliedern des HSEE Management-Teams der Health Check mit einer Standortbestimmung abgeschlossen. Den Reifegrad bezeichneten die Berater als "IT-Department mit Tendenz zum Service-Provider".

Gründe für die Service-Lücken

Auf dem Weg zum nächsten Klassenziel machten HSEE und die Berater folgende Gründe für die Servicelücken aus:

• Zwar sind die Lieferprozesse definiert, doch sie werden nicht angewendet.

• Die Adressaten der Services sind nicht an der Gestaltung der Prozesse beteiligt.

• Es gibt keine definierten Eskalationswege.

• Frühwarnindikatoren sind nicht definiert.

Der Health Check hat mit vorbereitenden Interviews sechs Wochen beansprucht, die Konzeptionsphase drei Monate, und die gesamte Transformation der HSEE wurde in 15 Monaten bewältigt. Die Verbesserungsvorschläge wurden noch weiter detailliert und in einzelne Projekt mit To do‘s, Aufwand, Risiken und den damit erzielbaren Vorteilen heruntergebrochen.

Ein solches Projekt war zum Beispiel die Erstellung eines Servicekatalogs. "Wir hatten keine Transparenz, was an SAP-Services für die Länder und in den Ländern erbracht wurde", erzählt Babst. Außerdem waren die Services nicht genau beschrieben, nachvollziehbare SLAs waren nicht verbindlich für alle Länder festgelegt, und Preise für die Dienstleistungen fehlten auch. "Heute genügt die Serviceerbringung industriellem Standard. Jeder weiß jetzt, welcher Service in welcher Qualität verfügbar ist", sagt dprp-Partner Jörg Plegge.

10.000 Nutzer in EMEA

Auf dem Weg zum Business Partner war auch die Governance deutlich zu stärken. Eine länderübergreifende Steuerung existierte zwar für das Projektgeschäft, doch im Servicebereich fehlte sie. Auch eine klare Ablauforganisation, die Berichtswege zwischen HSEE, europäischen Regionen und Ländern verdeutlichte, war Anfang 2007 noch nicht vorhanden. Im Prinzip wurden die 180 Mitarbeiter in den Regionen und Standorten in verschiedenen virtuellen Kompetenzteams organisiert. Gemeinsam unterstützten sie rund 10.000 Nutzer in der Region EMEA.

Heute berichten alle IT-Leiter in den Regionen und Standorten fachlich an Babst, auch wenn sie disziplinarisch noch dem Chief Financial Officer des jeweiligen Standorts unterstellt sind. "Vorher haben die IT-ler vor Ort das getan, was ihnen ihr CFO gesagt hat. Wir konnten nur Vorschläge machen, und die bedeuteten ihnen herzlich wenig", blickt der EMEA-CIO zurück.

Babst hat sein Ziel noch nicht erreicht, die HSEE als Business Engineer gegenüber der Business-Seite zu etablieren. Und er wird es auch nicht mehr erreichen, da er im Juni einen neuen Job annehmen wird. Aber er sieht die Organisation auf dem richtigen Weg: "Wir müssen noch einige Prozesse durchkonjugieren; bisher haben wir uns auf die kundenorientierten Prozesse wie Incident, Change, Problem-Management und Release konzentriert."

Dann formuliert er es ehrgeiziger: "Wir waren früher gute SAP-Berater, wir brauchen aber zunehmend gute IT-Manager." So einer löse nicht nur ein singuläres Druckerproblem, sondern der frage auch, wieso das Problem auftaucht und wie es sich in Zukunft vermeiden lässt, und der müsse auch die Frage stellen: Muss ich überhaupt drucken?