IT-Strategie

Die Lehren der Zentralisierung

Von Horst Ellermann

2. Teil: Drei Gründe für SSC

Schmidbaur und Brunn führen zusammen drei Argumente auf, die für SSC sprechen, wobei sie diese unterschiedlich gewichten:

1. SSC können Geld sparen

Beispiel EADS : Um 15 Prozent will Schmidbaur sein IT-Budget bis Ende 2006 reduziert haben. Rund 10 Prozent hat er bereits in den ersten 18 Monaten der Projektlaufzeit realisiert. Damit ist ihm eines der wenigen IT-Projekte in der Welt gelungen, das sich selbst finanziert. Schmidbaur hat mit nur drei Beratern einen 310 Mann starken Bereich reorganisiert, die IT für 24.000 Mitarbeiter liefert. "Die größten Einsparungen entstehen dabei natürlich durch Skaleneffekte im Standard-IT-Servicebereich", sagt Schmidbaur.

Außerdem sind beim Restrukturieren auch zwei alte ERP-Systeme auf der Strecke geblieben, die das Wort Standard nur noch zur Zierde trugen. Weitere ERP-Systeme hat der CIO in echte Standards überführen lassen und eine konsequente SAP-Integrationsstrategie mit dem Management vereinbart. Außerdem hat er parallele Projekte in allen Infrastruktur-und Anwendungssystemen gestoppt.

Wolfgang Brunn von MAN bestätigt das Einsparpotenzial von SSC, relativiert aber die Erwartungen an das Volumen. Wenn der Einkauf bereits zentralisiert sei, ließen sich Skaleneffekte natürlich nicht mehr der neu strukturierten IT zuschreiben. Und außerdem: "Wenn Sie die SAP-Systeme schon standardisiert haben, dann können Sie mit dem Rest der IT kaum mehr herausstrampeln", sagt Brunn.

2. SSC rütteln die Organisation wach

Beispiel MAN: Das Traditionsunternehmen hatte sich in der IT eine lange Phase der Dezentralität gegönnt. Strukturen verkrusten dabei automatisch. Anwendungsentwickler rücken enger an die Fachbereiche, liefern spezialisierte Lösungen und machen sich schließlich unabkömmlich. Softwarestandards und selbst Infrastruktur lassen sich durch "Customizing" so kundenfreundlich gestalten, dass am Ende nur noch ein Anwender und ein Anbieter damit glücklich sind.

Ein SSC kann hier Vergleichbarkeit schaffen, wenn die Reorganisation mit dem Erstellen eines Standardservicekatalogs verknüpft wird – was eigentlich immer das Ziel sein sollte. "Ich habe lange Jahre gewartet, bis ein neuer Vorstand kam, der die Organisation so strukturieren wollte", erzählt Brunn. Jahre zu lang, wie er findet: "Man sollte generell alle sieben Jahre reorganisieren, das verhindert Erstarrung und bringt immer mehr, als es kostet", meint der CIO. Die nächste Reorganisation wird er dann aber nicht mehr mitmachen. Der MAN-CIO will bis dahin schon mindestens sechs Jahre in Rente sein.