Der Schwerpunkt der CIO-Aufgaben verlagert sich in Richtung Abläufe und Prozesse. Die IT-Verantwortlichen werden künftig betriebswirtschaftliche Vorgänge unternehmensweit identifizieren und leiten. Voraussetzung dafür ist eine neue Einstellung gegenüber dem Dogma des zentralisierten Information-Engineering.

Vielleicht ändert der Chief Information Officer sogar seinen Titel in Chief Process Officer, abgekürzt vielleicht: CPO, um dem vergrößerten Verantwortungsbereich Rechnung zu tragen. Die Position des CIO ist keineswegs veraltet – im Gegenteil: Als geborene Change Agents werden gute CIOs hervorragende CPOs sein.

Was hat es mit der Verlagerung in Richtung der Prozesse auf sich? Zum einen erkennen die CIOs in zunehmendem Maße, dass ihr „I“ – für Information – zu unflexibel ist, um mit sich ändernden Märkten, neuen Wettbewerbsanforderungen, rasanten technologischen Entwicklungen und organisatorischen Umstrukturierungen umzugehen.

Zum anderen beobachten wir die Geburt einer neuen Generation von „kollaborativen“ Unternehmungen, die Kunden sowie Partner bedienen und eine direkte Verbindung zu internen Systemen benötigen. Last, but not least zwingt die Kapitalkrise die Unternehmen dazu, betriebswirtschaftliche Effizienz anzustreben.

Die technischen Möglichkeiten von heute – zum Beispiel Enterprise Application Integration (EAI) und Business Process Management (BPM) – lassen neue Organisationsformen zu. In dieser gerade anbrechenden Ära wird der CPO betriebswirtschaftliche Abläufe organisieren und die Zusammenarbeit zwischen den Fachabteilungen und der IT leiten, indem er unterschiedliche Schichten von Software und Abläufen miteinander verbindet.

In diesem Sinne ist der CPO eine neue „C-Level“-Führungskraft, die einen kollaborativen, dynamischen und anpassungsfähigen IT-Ansatz vorantreibt. Seine Hauptaufgabe wird darin bestehen, mit der IT-Organisation eine technische Infrastruktur bereitzustellen, welche die Weiterentwicklung von Geschäftsabläufen unterstützt. Der Job verlangt die Anwendung neuer Regeln; sie dienen nicht mehr der restriktiven zentralen Kontrolle, sondern motivieren dazu, neue Ideen und Lösungen zu testen.

Im Einzelnen muss der CPO:

statistische und wissenschaftliche Methoden anwenden, um die Bandbreite der betriebswirtschaftlichen Abläufe zu managen,

einen umfassenden Katalog von Geschäftsabläufen pflegen, der deren jeweilige Ziele und mögliche Auswirkungen beschreibt,

gewährleisten, dass diese Beschreibungen vergleichbar sind, damit eine effiziente Bewertung möglich ist,

die Erstellung zahlreicher, miteinander im Wettbewerb stehender Geschäftsprozess-Implementierungen veranlassen und sie nach einer strengen Methode testen,

die Kosten für jede Prozessanwendung aufzeigen und sie nach Inbetriebnahme mit den jeweiligen Ergebnissen den Alternativen gegenüberstellen,

ineffiziente Anwendungen fallen lassen und die „Champions“ ausbauen,

kontinuierlich neue Implementierungen ausprobieren.

Eine technische Infrastruktur, die auf diesen Regeln beruht, wird das Unternehmen von einem unflexiblen, zentralisierten IT-Ansatz zu einem System führen, das Abteilungen, Kunden und Partner auf der Basis tatsächlicher Abläufe integriert.

Abschied von drei "CIO-Mythen"

Jede Veränderung in dieser Größenordnung macht es notwendig, sich von einem tief verwurzelten Denken zu trennen. In diesem Fall besteht der erste Schritt im Abschied von drei CIO-Mythen. Sie lauten:

Informationstechnik basiert auf Plänen.

Widersprüchliche Daten müssen eliminiert werden.

Anzustreben ist eine „Plug-and-play“-Wiederverwendbarkeit.

Mythos eins hat bewirkt, dass viele gängige Technologien für das Geschäftsprozess-Management „auf Plänen basierend“ entwickelt wurden. Ursache dafür ist die – durchaus anzweifelbare – Überzeugung, der effiziente IT-Gebrauch führe zwangsläufig zu effizienten Geschäftssystemen. Mit einer präzisen „Endstatus-Vision“ und einer unterstützenden Schwachstellenanalyse des derzeitigen Geschäftsablaufes lasse sich, so die Argumentationslinie, systematisch planen, wie der angepeilte Zielzustand erreicht werden könne. Anwendungen werden so zu einer Frage der Ausführung und der Details.

Wenn wir akzeptieren, dass ein auf Plänen basierender Ansatz der richtige Weg ist, um ein Unternehmen an sein Umfeld anzupassen, dann ist der logische Kandidat für das Management der Geschäftsprozesse der CIO. Aber angesichts der rapiden Veränderungen des heutigen Geschäftsumfeldes lässt sich nicht garantieren, dass eine Geschäftsprozess-Implementierung zum Zeitpunkt ihrer Einführung noch „passt“. Das Konzept einer Endstatus-Vision ist damit überholt.

Der zweite CIO-Mythos besagt, dass redundante oder widersprüchliche Daten eliminiert werden müssen. Gängige Datenverwaltungsprogramme verlangen, dass wir im Vorhinein entscheiden, welche „Field-Level“-Daten in unseren Systemen persistent sein sollen. Aber Verdopplungen, Widersprüche und Unvereinbarkeiten sind eine unvermeidbare Folge der lokalen Systemanpassungen, mit denen wir auf sich ändernde Geschäftsbedürfnisse und Ziele reagieren. Unter dem Zeit- und Kostenaspekt ist es am besten, dieses Thema auf dem Anwendungslevel zu behandeln. Das Information-Engineering (IE) war der offensichtlichste Versuch, die Datenkonsolidierung auf einer umfassenden Architekturebene zu leisten. Er ist gescheitert.

Mythos drei: In den neunziger Jahren wurde das Konzept der Wiederverwertbarkeit als Allheilmittel angepriesen. Trotz des Risikos, einen der geheiligsten Glaubenssätze des CIO zu stürzen, soll kurz untersucht werden, warum die Wiederverwertbarkeit viel weniger gebracht hat als versprochen. Das Kernkonzept besteht darin,

ein komplexes Problem durch eine Aufteilung nach Bezugsbereichen („Concerns“) in leichter zu handhabende Stücke zu teilen,

jeden Bestandteil als eine wiederverwertbare Komponente aufzubauen sowie

Standardprotokolle, Schnittstellen und eine spezielle Semantik für den Informationsaustausch zwischen den Komponenten zu verwenden.

Zunächst müssen also die Grenzen zwischen den divergierenden Bezugsbereichen gezogen werden. Die unsachgemäße Trennung eigentlich verknüpfter Bereiche führt aber zur Fragmentierung. Und Fragmentierung ist heute eines der größten Probleme bei IT-Altsystemen.

Stellen Sie sich vor, eine Bank soll einen Scheck für ein überzogenes Konto bearbeiten. Wer die Trennung nach Bezugsbereichen wörtlich nimmt, wird diesen Prozess als einfache Berechnung innerhalb eines "Kontoobjekts" einbauen. In Wirklichkeit aber ist das Handeln der Bank variabel; es hängt entscheidend ab vom Wert des Kunden, von den Zielen der Bank und von dem gesamten Bündel der Beziehungen, die Kunde und Bank unterhalten.

Problem als Ganzes betrachten

Handelt es sich um einen Kunden, der die Bank nur Geld kostet, so wird das Verfahren darin bestehen, den Scheck abzulehnen und eine Bearbeitungsgebühr zu erheben. Für einen profitablen Kunden mit einer ausgeprägten Neigung zum Wechsel des Instituts wird die Bank möglicherweise den Scheck bezahlen und auf die Gebühr verzichten.

Wenn der Kontoinhaber derzeit nur wenig Gewinn einbringt, aber ein hohes Zukunftspotenzial aufweist, wird die Bank vielleicht den Scheck bezahlen wollen, gleichzeitig eine geringe Gebühr erheben und versuchen, dem Kunden ein Instrument zum Schutz gegen Kontoüberziehung zu verkaufen (Cross-Selling).

Der oben erwähnte experimentelle Ansatz bestünde darin, jedes dieser Szenarien durch mehrere Anwendungsvarianten zu bedienen. Voneinander trennbare Bezugsbereiche gibt es hier nicht. Das Problem lässt sich viel leichter in den Griff bekommen, wenn es als Ganzes betrachtet wird - mit der kombinierten Perspektive von Bank und Kunde.

Die derzeitigen Formen der Geschäftssoftware sind schlecht auf die Bedürfnisse der modernen Geschäftsprozesse zugeschnitten. Ursache dafür ist das datenzentrierte Weltbild, das sich die IT-Gemeinde zu Eigen gemacht hat. Die Versuche, dieses Weltbild der prozesszentrierten Welt aufzuerlegen, haben im technischen wie auch im wirtschaftlichen Umfeld Kosten und Probleme verursacht.

Bestehende Systeme, Anwendungen und Komponenten werden immer auf lokalen Daten aufgebaut. Diese Datenmodelle stehen - semantisch und strukturell - im Konflikt miteinander. Jedes Softwaremodul macht seine eigenen Annahmen darüber, was ein Kunde oder ein Produkt ist, und es gibt nichts, was diese Widersprüche verhindern könnte.

Zudem ist die Geschäftslogik in den einzelnen Softwaremodulen eng verknüpft mit dem lokalen Datenmodell und daher ziemlich resistent gegenüber den Bedürfnissen realer Prozesse. Diese Widersprüche aufzulösen ist eine risikoreiche Arbeit. Deshalb betragen die Kosten für die Integration eines neuen Softwarepakets in ein Altsystem das Sieben- bis Zehnfache der Nutzungsgebühren.

Middleware für die Enterprise Application Integration (EAI) bietet einen Ausweg aus der Tyrannei des datenzentrierten Anwendungsbestandes. Gleichzeitig kann eine prozessgesteuerte Infrastruktur mit verknüpften Entwicklungs- und Management-Methoden sowie entsprechenden Werkzeugen eingerichtet werden.

Unter den geschilderten Voraussetzungen scheint die Wandlung vom CIO zum CPO gewaltig. Aber auch die CIO-Revolution der vergangenen Dekade war kein Zuckerschlecken. Ungeachtet der Abkürzung sollten die CIOs oder CPOs dasselbe übergeordnete Ziel verfolgen - dem Geschäft die Kraft zu verleihen, sich selbst zu definieren und auszuführen.

Um eine neue Abkürzung zu vermeiden, lässt sich möglicherweise einfach die Bedeutung des "I" verändern: von Information zu Infrastruktur. Der "Chief Infrastructure Officer" muss jemand sein, der die Rahmenplanung vornimmt und eine Infrastruktur schafft, bei der die User das, was sie wollen, selbst tun können. Er sollte so denken und handeln, als sei er der Haupt-Interessenvertreter der Anwender.

Die CPO-Agenda

Folgende Aufgaben müssen Sie als Chief Process Officer anpacken:

Erstellen Sie einen Geschäftsfall- und Geschäftsprozess-Katalog.

Identifizieren und selektieren Sie mögliche effektive Maßnahmen für jeden Geschäftsprozess.

Stellen Sie fest, bis zu welchem Grad ein gängiger Geschäftsprozess als "gerade richtig" für das Geschäft angesehen wird; priorisieren Sie die Geschäftsprozesse - soweit möglich - nach diesem Kriterium.

Legen Sie fest, welche die besten Kandidaten für eine "Darwinistische Auslese" sind.

Schaffen Sie einen Katalog von Systemen, Anwendungen und Schnittstellen.

Dokumentieren Sie das Knäuel aus Anwendungen und Geschäftsprozessen in Form einer Matrix; so erhalten Sie einen Indikator dafür, inwieweit der Anwendungsbestand an die Bandbreite der Geschäftsprozesse angepasst ist.

Starten Sie eine prozessorientiert EAI-Initiative, um das Unternehmen in ein Stadium der beherrschbaren Prozesse zu überführen; etablieren Sie in diesem Rahmen eine Schichtenarchitektur aus Anwendungskomponenten, die durch standardisierte Adapter an ein "Unternehmens-Rückgrat" angeschlossen werden.

Auf diesen EAI-fähigen "Informationsbus" platzieren Sie solche Komponenten, die eine elegante Einführung neuer Geschäftsprozessvarianten erlauben.