Ein allgemein akzeptiertes Handbuch oder Regelwerk für erfolgreiche CIOs existiert nicht. Es wäre auch zu unflexibel, müsste entweder jedes Jahr neu geschrieben werden, oder die konkreten Handlungsanweisungen würden schneller veralten, als man die Wörter "Internet" oder "Jahr-2000-Problem" schreiben könnte.
Erfolgsrezepte für den CIO (Teil 1)
Gibt es ein Patentrezept, mit dem CIOs zwangsläufig Erfolg haben - sofern sie nur ihre Karriere danach ausrichten? Oder wenigsten eine Liste, deren Punkte sie nur ordentlich abarbeiten müssen, um den Erwartungen der Unternehmensführung und der Fachabteilungen gerecht zu werden? Diese Frage stellen der Wirtschaftsinformatiker Walter Brenner und computerwoche-Chefredakteur Christph Witte in ihrem Buch: "Erfolgsrezepte für CIOs", das demnächst im Hanser-Verlag erscheint (ISBN 3-446-40633-6). Der Text auf dieser Seite fasst den Beginn des Kapitels 6 zusammen. Weitere Auszüge folgen.
Doch es gibt einige Signale, die ein CIO so schnell wie möglich aussenden sollte, wenn er seine Position behalten möchte:
• strikte Business- und Prozess-Orientierung sowie die deutliche Forderung, an Business-Entscheidungen teilzuhaben,
• eine klare Orientierung, wohin sich die Informationstechnik im Haus bewegen soll,
• Flexibilität bezüglich der Business-Anforderungen - bei gleichzeitiger Entschiedenheit in Bezug auf Architekturfragen,
• kontinuierliche Verringerung der Run-Kosten,
• genügend Raum und Budget für Change und Innovation.
Daneben können einige Fehler eine Karriere definitiv schädigen. Hier sind in erster Linie Delivery-Probleme zu nennen. CIOs, die ihre Systeme nicht im Griff haben, bleiben nicht lange in dieser Rolle.
Einmal und nie wieder
Frank Annuscheit, CIO der Commerzbank, bringt es auf den Punkt: "Weil die Abhängigkeit von der IT so hoch ist, ist auch die Primärerwartung an den CIO, den Laden am Laufen zu halten." In den Selbstbeschreibungen tauche dieser Punkt zwar erst weiter hinten auf ("Vorher kommen Dinge, die auch Spaß machen"), aber die Systeme verfügbar zu halten, sei eindeutig der wichtigste Anspruch an den CIO. Krisen ließen sich zwar nicht verhindern, aber nach ihrer Bewältigung sei es absolut angezeigt, "Maßnahmen zu ergreifen, die verhindern, dass so etwas wieder vorkommt".
Rainer Janßen, CIO der Münchner Rück, formuliert ganz ähnlich: "Die Basiserwartung ist erst einmal, dass der Laden läuft. Dazu gehört, den Qualitätsansprüchen der Anwender in puncto Service und Verfügbarkeit zu genügen, die Informationen der Company zu sichern, und das alles zu vernünftigen Preisen darzustellen."
Als Janßen seinen Job vor acht Jahren antrat, fand er eine IT-Landschaft vor, die aus vielen kleinen Inseln bestand. "IT-Polynesien" nennt er das. Seit damals arbeitet er an der Globalisierung der IT und der Infrastruktur.
Inzwischen hat er einiges erreicht. Es gibt einen einheitlichen Corporate Client, das weltweite Corporate Network arbeitet inzwischen auch, und die IT-Infrastruktur ist ebenfalls weltweit vereinheitlicht. "SAP ist weltweit als Standard im Backoffice gesetzt, für die Konzernkonsolidierung haben wir bereits seit Anfang 2004 ein weltweit einheitliches System für alle 300 Gruppengesellschaften, das standardisierte Hauptbuch ist im globalen Rollout, und weitere Felder sind in Vorbereitung", erzählt der CIO. Zudem sei man auf dem besten Wege, Risikoeinschätzung und -bewertung - im Rückversicherer-Jargon "Underwriting" genannt - weltweit zu standardisieren. Wenn die Münchener Rück es auch noch schafft, das Versicherungsrisiko zusammen mit dem Kapitalanlagerisiko zu managen, ist Janßen auf dem Weg zur Globalisierung eine weiteren Schritt nähergekommen.
Globalisierung setzt Standardisierung voraus. Bei Letzterer kann Janßen allerdings nicht allzu rigoros vorgehen, denn die Heterogenität des Geschäfts muss respektiert werden. "Die Massenprozesse gibt es bei uns nicht. Da wir praktisch alle Risiken versichern, müssen wir auch jedes Versicherungsgeschäft weltweit abbilden können - gleichgültig, ob es um einen Raketenstart in Kourou geht oder um ein Konzert der Rolling Stones", berichtet der CIO. Deshalb beschränkt er sich darauf, im Kern und in der Wahl der Werkzeuge zu standardisieren, soweit es geht: "Der Kunde kann von uns alles bekommen, solange es das bei SAP oder Microsoft gibt."
Doch nicht immer ist der CIO für das reibungslose Funktionieren des Gesamtsystems IT verantwortlich. Die Schweizer Großbank UBS beispielsweise hat einen Chief Technology Officer mit dem Betrieb der gesamten Infrastruktur vom Arbeitsplatz über die Netze bis zu den Mainframes beauftragt. Die CIOs dagegen sind den drei strategischen Geschäftsbereichen Global Asset Management, Investment Banking sowie Global Wealth Management & Business Banking zugeordnet und für die Applikationen verantwortlich.
Auch Martin Frick von der Schweizer Winterthur beschäftigt einen CTO, der allerdings anders als bei der UBS an ihn berichtet. Die Aufgabenteilung ist indes ähnlich.
Verantwortung teilweise delegiert
Peter Sany, CIO der Deutschen Telekom, sieht sich zwar in der Gesamtverantwortung für das Funktionieren der Infrastruktur, delegiert diese Aufgabe aber ebenfalls: "Ab 1000 Mitarbeitern aufwärts hat man in der Regel einen RZ-Leiter oder einen CTO, der sich um das Funktionieren der Systeme kümmert."
Alex Röder, CIO des Mobilfunkanbieters O2, hat die Delivery sehr hoch gehängt: "Der CIO und der CTO sind Leistungserbringer." Die Rolle des CTO unterscheidet sich bei allen Telekommunikations-Carriern von der des CIO. Diese Funktion ist nicht für die IT-Infrastruktur verantwortlich, sondern für die gesamten Telekommunikationsnetze und Netzinfrastruktur.
Prozess-SLAs mit den Kunden
Im Rahmen von Process-Service-Level-Agreements vereinbart Röder mit seinen internen Kunden Prozessverfügbarkeiten. Er erklärt das am Beispiel des Aktivierungsprozesses, der zwischen Vertragsunterzeichnung und dem ersten Telefonat des neuen Kunden abläuft. Er besteht aus 39 Einzelapplikationen. Wenn diese jeweils eine Verfügbarkeit von 98 Prozent aufweisen, dann sei der reibungslose Ablauf des Gesamtprozesses nur zu 52 Prozent garantiert, erklärt Röder: "Das ist für die Geschäftsleitung natürlich nicht akzeptabel." Bei O2 sei der Gesamtprozess 98 Prozent verfügbar, was wirklich ein sehr hoher Wert sei.
Das Jahr 2006 hat Röder unter das Motto "Zero Downtime" gestellt. Ungeplante Ausfallzeiten sollen auf ein Minimum reduziert werden. Sollten sie doch auftreten, muss die Zeit des Stillstands möglichst kurz sein. "Zurzeit bemühen wir uns, die Recovery-Zeiten durch Start-Stop-Scripts weiter zu reduzieren", erklärt der CIO. Auch die geplanten Downtimes will er "gegen null" bringen. "Durch das Online-Business können wir uns keine Downtime mehr erlauben. Selbst wenn wir im Backend down sind, muss der Online-Shop erreichbar sein. Alles andere kostet bares Geld."
End-to-end-Tests vermeiden
Röders übergeordnetes Ziel lautet "kontinuierliche Delivery". Das hat mit Verfügbarkeit, aber auch mit Time-to-Market zu tun. Zurzeit bewältigt O2 vier Releases des Kernsystems im Jahr. Dabei werden neue Anforderungen gebündelt abgearbeitet. Das Ganze wird vor dem Roll-out einem End-to-End-Test unterzogen.
Danach sammelt die IT wieder neue Anforderungen ein, aber stellt erst im nächsten Release die optimierten Applikationen zur Verfügung. "In ungünstigen Fällen kann das drei Monate dauern. Deshalb wollen wir weg von den Releases," sagt Röder. Sein Team arbeitet daher an einem Produktkatalog, der getestete Einzelprodukte enthält. So hofft der CIO, künftig auf die aufwendigen End-to-End-Tests verzichten zu können. (qua)