Inhaltsverzeichnis

1  Einleitung  7

1.1  Thematische Einleitung  7

1.2  Zielsetzung der Arbeit  8

1.3  Aufbau der Arbeit  8

2  Does IT Matter?  10

2.1  IT als Massenware  11

2.2  Schwindende Wettbewerbsvorteile durch IT  14

2.3  Das IT-Produktivitätsparadoxon  18

2.3.1  Das Solowsche Produktivitätsparadoxon  18

2.3.2  Das IT-Produktivitätsparadoxon auf Unternehmensebene  19

2.4  Die Ausbauphase der IT (IT buildout) ist erreicht  24

2.5  Konsequenzen für das IT-Management  26

2.6  Bewertung von Carrs Ideen  28

2.6.1  Entwicklung der IT  30

2.6.2  Wechsel von nachhaltigen zu temporären Wettbewerbsvorteilen  31

2.6.3  Schlussbemerkung  33

3  Der CIO  34

3.1  Das CIO-Konzept  34

3.2  Die Weiterentwicklung des CIOs  35

3.3  Die Stellung des CIOs im Unternehmen  36

3.3.1  Der CIO in den DAX-Unternehmen  39

3.3.2  Der Einfluss des CIOs auf andere Führungskräfte  42

3.3.3  Die Beziehung zwischen CIO und CEO  44

3.4  Dezentralisierung vs. Zentralisierung der IT  46

3.5  Erfolgsfaktoren für CIOs  49

4  CPO-Konzepte  51

4.1  Vom CIO zum CPO  51

4.1.1  Der CPO als Enabler des SOA-Unternehmens  53

4.1.2  Der ITIL-Standard  57

4.1.3  Der CPO in der Sicht deutscher IT-Verantwortlicher  59

4.2  CPO-Konzepte  61

2

5  Der CPO nach Schmidt und Seidel  63

5.1  Allgemeine Vorstellungen  63

5.1.1  Die drei Mythen des CIOs  64

5.1.2  Der Paradigmenwechsel vom CIO zum CPO bringt neue Wörter  

hervor   66

5.2  Aufgaben, Kompetenzen, Verantwortung und Anforderungen  67

5.2.1  Aufgaben  67

5.2.2  Kompetenzen  68

5.2.3  Verantwortung  68

5.2.4  Anforderungen  69

6  Der CPO nach Abolhassan und Jost  70

6.1  Allgemeine Vorstellungen  70

6.2  Aufgaben, Kompetenzen, Verantwortung und Anforderungen  71

6.2.1  Aufgaben  71

6.2.2  Kompetenzen  72

6.2.3  Verantwortung  74

6.2.4  Anforderungen  74

7  Der CPO nach Schmelzer und Sesselmann  76

7.1  Allgemeine Vorstellungen  76

7.2  Aufgaben, Kompetenzen, Verantwortung und Anforderungen  78

7.2.1  Aufgaben  78

7.2.2  Kompetenzen  79

7.2.3  Verantwortung  81

7.2.4  Anforderungen  81

8  Erste CPOs  83

8.1  CPOs nach Schmelzer und Sesselmann  83

8.2  CPO nach Schmidt, Seidel, Abolhassan und Jost  84

8.2.1  Veränderung der CIO-Organisationsstruktur  85

8.2.2  Das Geschäftsprozessmodell bei VW  87

9  Vergleich und Bewertung der einzelnen Konzepte  89

9.1  Vergleich der Konzepte  89

9.2  Einsatz der Konzepte  92

9.2.1  Die Institutionalisierung des Geschäftsprozessmanagements  92

9.2.2  Die Ernennung eines CPOs  93

10  Fazit  98

3

Abbildungsverzeichnis   

2.1  Grenznutzen von Textverarbeitungsprogrammen  12

2.2  Ressourcen-basiertes Modell für die Nachhaltigkeit von Wettbewerbsvor-  

teilen   17

2.3  Das solowsche Produktivitätsparadoxon  20

2.4  Annäherung an die Daten der Aufbau- und Entwicklungsperioden  27

3.1  Die Entwicklung des CIOs von 1996 bis 2006  37

3.2  CIO Aufgabenverteilung  38

3.3  Einfluss der IT-Organisation auf das mittlere Management  48

6.1  Drei-Stufen-Modell des Geschäftsprozessmanagements  72

7.1  Prozessgremien innerhalb eines Betriebes  77

7.2  Grundstruktur eines Unternehmensprozessmodells  80

7.3  CPO-Organisation in der reinen Prozessorganisation  81

8.1  CIO Organisation bei VW  85

8.2  Prozessorganisation bei AUDI  88

9.1  Einordnung der verschiedenen Modelle  91

4

Tabellenverzeichnis   

2.1  Kosten für verschwendete Arbeitszeit  32

3.1  Berichtswege des CIOs  39

3.2  CIOs in den DAX 30  41

3.3  Qualitäten eines CIOs  45

4.1  Aktivität von CIOs auf dem englischen Arbeitsmarkt  53

4.2  Akzeptanz von ITIL in Deutschland  58

4.3  ITIL-Prozesse  59

4.4  Verantwortungsbereich von CPOs  60

7.1  Verantwortung in der Prozessorganisation  80

8.1  IT-Ausgaben  86

9.1  Vergleich CPO-Konzepte  89

9.2  Bedingungen für Wechsel vom CIO zum CPO  96

5

Abkürzungsverzeichnis

ARIS Architektur integrierter Informationssysteme BPEL Business Process Execution Language CIO Chief Information Officer CFO Chief Financial Officer CEO Chief Executive Officer CPO Chief Process Officer DBA Database Administration DEA Data Exchange Administration DP-Manager Data Processing-Manager EDM Enterprise Data Model EEM Enterprise Event Model ERP Enterprise Resource Planning ESB Enterprise Service Bus GPM Geschäftsprozessmanagement HTTP Hyper Text Transfer Protocol IT Informationstechnologie ITIL Information Technology Infrastructure Library J2EE Java 2 Platform Enterprise Edition MIS Management Information System MOF Meta Object Facility UDDI Universal Description, Discovery and Integration SOA Serviceorientierte Architektur XML Extensible Markup Language

6

1 Einleitung

1.1 Thematische Einleitung

Bei einer Podiumsdiskussion auf der Executive Lounge 2004 eröffnete Peter Clotten ¹ das Gespräch mit dem Satz: „Der CIO wird an Bedeutung verlieren, wenn er den Wandel zum CPO (Chief Process Officer) nicht schafft“ [Onl06]. Eine Meinung, die man in den letzten Jahren oft lesen konnte, wenn es um die Zukunft des Chief Information Officers (CIO) geht. Diese Arbeit befasst sich mit den Hintergründen dieser Meinung. Schnell wird deutlich, dass sich mit dieser Meinung sehr viele weitere Fragen in Verbindung bringen lassen, z.B. was diesen Anpassungsdruck auf den CIO verursacht oder in welcher Form sich denn der heutige CIO vom CPO unterscheidet. Auch das Anzweifeln des CIOs und damit auch ein Stück weit der IT selbst, ist nicht ungewöhnlich. So finden z.B. keine Debatten über die Zukunft des Chief Financial Officers (CFO) oder des Chief Operation Officers (COO) in der Unternehmenshierarchie statt; Grundsatzdiskussionen darüber wie IT in einem Unternehmen gemanaget werden sollte ² , finden sich aber zuhauf.

Der Grund dafür dürfte in der sich ständig verändernden Bedeutung der IT für Unternehmen liegen, die durch den technischen Fortschritt bestimmt wird. Von dieser sich verändernden Bedeutung der IT ist daher auch die Stellung des IT-Managements abhängig. Ob z.B. IT überhaupt die Produktivität steigert, ist seit Jahrzehnten ein beliebtes Forschungsgebiet. Solow brachte die Problematik dieses Bereichs 1987 mit seinem berühmten Satz „we can see the computer age everywhere but in the productivity statistics“ auf den Punkt (Vgl. 2.3.1). Ende der 90er Jahre sollte er seinen Satz allerdings zurücknehmen [Gor00, S. 49], denn der sogenannte fünfte Kondratieff, das Zeitalter der Informationsgesellschaft, schien sich nun auch in den Statistiken für die Arbeitsproduktivität bemerkbar zu machen (Vgl. 2.3.1 und [Ins01]). Als mit dem Börsencrash die Überbewertung der New Economy-Unternehmen deutlich wurde und die Unternehmen in der folgenden Konjunkturflaute umstrukturierten und Überkapizitäten abbauten, wurden auch die IT-Budgets zusammengestrichen ³ . In dieser für die IT-Branche immer noch trüben Zeit, löste 2003 Nicholas G. Carr mit seinem Aufsatz „IT Doesn’t Matter“ erneut Diskussionen um die Zukunft des CIOs aus. Die

¹ Peter Clotten ist CIO bei Giesecke & Devrient

² Um einige Beispiele zu nennen: [SG81], [Dea87], [RD90], [Hop90], [BJZ92], [Car03], [Jos04], [KB04]. Eines der bekanntesten Zitate dürfte dabei vom ehemaligen AirAmerica CIO Max Hopper kommen: „In this world [Hopper spricht von der Zukunft, in der immer mehr IT vernetzt und dezentralisiert ist], a company trumpeting the appointment of a new chief information officer will seem as anachronistic as a company today naming a new vice president for water and gas“ [Hop90].

³ Erst 2004 stiegen die IT-Investitionen wieder langsam an, nach dem sie 2001 das erste mal einbrachen [DSSW04]. Siehe auch [PS03, S. 230].

7

Argumente für das Ende des CIOs lesen sich dabei meist wie folgt: Da IT zur Massenware geworden sei, wäre es nicht mehr möglich, durch sie Wettbewerbsvorteile zu erreichen. Stattdessen sei IT in Zukunft fast so einfach wie Strom aus der Steckdose beziehbar und große Teile der IT ließen sich auf diesem Weg problemlos auslagern. Ein kompliziertes IT-Management entfiele daher.

Den Verlust seiner Stellung könne der CIO daher nur verhindern, wenn er seinen Aufgaben-, Kompetenz- und Verantwortungsbereich ausdehnt. Wenn er sich stärker betriebswirtschaftlich engagiere, wenn er konsequent die IT an dem Unternehmen ausrichte, wenn er zum Gestalter wird und als Kommunikator die IT im Unternehmen profiliere. Er müsse daher die Bedeutung des Geschäftsprozessmanagements erkennen, es zu seiner Kompetenz machen und im Unternehmen vorantreiben.

1.2 Zielsetzung der Arbeit

Das Ziel der Arbeit ist ein besseres Verständnis von dem zu bekommen, was oft als Wandel „vom CIO zum CPO“ bezeichnet wird. Dafür muss klar sein, woher man kommt (vom CIO), also welche Bedeutung z.B. die IT hat, welche Rolle der CIO im Unternehmen spielt usw., und wohin man geht (zum CPO), also was z.B. die Aufgaben des CPOs sind oder welche Faktoren das Entstehen eines CPOs begünstigen. In diesem sehr weiten Feld beschäftigt sich diese Arbeit mit den folgenden Fragen:

• Was macht Unternehmen mit erfolgreichem IT-Management aus?

• Welche CPO-Konzepte gibt es?

• Wann ist die Ernennung eines CPOs sinnvoll?

• Gibt es schon CPOs in der Praxis?

1.3 Aufbau der Arbeit

In zweiten Kapitel wird die aktuelle Debatte über die Bedeutung der IT im Unternehmen und für die Wirtschaft aufgegriffen, da sie sehr wichtig für die Weiterentwicklung des CIOs ist. Dies soll anhand einer kritischen Betrachtung von Carrs „Does IT Matter?“ geschehen. Im dritten Kapitel wird das CIO-Konzept behandelt. So wird z.B. die Weiterentwicklung des CIOs aufgezeigt, seine Stellung im Unternehmen behandelt und für ihn kritische Erfolgsfaktoren aufgelistet. Das vierte Kapitel widmet sich den unterschiedlichen CPO-Konzepten, die man in der Literatur finden kann: Es führt in die CPO-Konzepte ein, zitiert aktuelle Statistiken zum CPO und zeigt Faktoren auf, die die Weiterentwicklung des CIOs zum CPO befördern könnten. In den drei anschließenden Kapiteln werden dann unterschiedliche CPO-Konzepte behandelt. Der Aufbau dieser Kapitel wird in Punkt 4.2 behandelt. Überschneidungen lassen sich dabei nicht vermeiden, da es zu unvermeidlichen Inkonsistenzen bei einer Synthese der vorgestellten CPO-Konzepte käme. Was nicht heißen soll, dass nicht vielleicht das eine Konzept durch das andere erweiterbar wäre. Im

8

achten Kapitel (Erste CPOs) werden Führungskräfte vorgestellt, die den vorher behandelten CPO-Konzepten entsprechen oder ähneln. Im neunten Kapitel folgt schließlich eine Gegenüberstellung der unterschiedlichen Konzepte. In dieser Gegenüberstellung ist der Wert dieser Arbeit zu sehen, da eine vergleichende Beschreibung der CPO-Konzepte meines Wissens bisher nicht vorgenommen wurde. Des Weiteren soll in diesem Kapitel auch der Frage nachgegangen werden, wann die Einsetzung eines CPOs sinnvoll ist. Kapitel zehn schließt schließlich die Arbeit mit dem Fazit ab. Damit Definitionen für unklare Begriffe schneller gefunden werden können, enthält das letzte Kapitel (Index) ein Verzeichnis aller Definitionen. Eine spezielle Methodik wird in dieser Arbeit nicht angewendet. Es gibt nur zwei Grundsätze, denen diese Arbeit folgt:

1. Probleme, die sich in erster Linie um die Bedeutung von Wörtern, bzw. ihrer Definition drehen, werden - soweit möglich - vermieden ⁴ . Wörter, die anders als im normalen Sprachgebrauch verwendet werden oder unüblich sind, habe ich immer genau so zu erklären versucht wie sie auch in der Arbeit verwendet werden.

2. Die Arbeit ist möglichst einfach geschrieben ⁵ .

⁴ „Was man ernst nehmen muß, sind Fragen und Behauptungen über Tatsachen: Theorien und Hypothesen; die Probleme, die sie lösen; und die Probleme, die sie aufwerfen“ [Pop04, S. 20]. Das soll nicht heißen, dass Definitionen nicht wichtig wären, sie werden nur oft überschätzt. Keiner wird z.B. den Vorteil einer Definition als Abkürzung oder Unterscheidung (Allein in der BWL gibt es unterschiedlichste Bedeutungen von „Prozess“) abstreiten [vS80, S. 26]. Vermieden werden sollen nur die Probleme, mit denen man zu tun hat, wenn man nach einer Letztbegründung für Definitionen sucht (Vgl. dazu Albert [Alb91, S. 15 ff.]). Gleiches gilt für unnötige Wortklaubereien, mit denen man sich nur vom eigentlichen Untersuchungsgegenstand entfernt.

⁵ Dieser Grundsatz bezieht sich nicht auf den bekannten Satz Einsteins, sondern auf Popper. Feyerabend kritisierte zwar die poppersche Aufforderung zur Einfachheit, trieb die Einfachheit selbst aber auf die Spitze durch einen möglichst lockeren und leicht lesbaren Schreibstil, der zumindest von dem Popper-Schüler Albert in einem Briefwechsel mit Feyerabend als Weiterentwicklung Poppers empfunden wurde [Bau97]. Das soll aber nicht heißen, dass Dinge einfacher darstellt werden sollen als sie sind. Für die Forderung nach Einfachheit gibt es eine logische Begründung, denn je einfacher z.B. eine Theorie aufgebaut ist, desto einfacher ist sie überprüfbar, allein schon deshalb, weil sie von mehr Menschen verstanden werden kann. Der Grad der Überprüfbarkeit ist dabei umso höher, je höher die Anzahl der Basissätze ist, die nach der Theorie unmöglich sind [Pop05, S. 69 ff.]. Kurz: je mehr eine Theorie verbietet, desto leichter lässt sie sich überprüfen und desto gehaltvoller ist sie. Daher ist eine besonders gehaltvolle Theorie logisch betrachtet unwahrscheinlicher als eine weniger gehaltvolle [Pop05, S. 97], da mit wachsenden Gehalt die Zahl der Basissätze steigt, die im Widerspruch mit der Realität stehen können. Diese Forderung nach Überprüfbarkeit, die beinahe identisch mit der nach Einfachheit ist, ist deshalb von Bedeutung, da aus logischer Sicht ein Beweis, eine Verifizierung, eine endgültige Begründung, usw. unmöglich ist [Pop05, S. 19 ff.]. Theorien können sich also nur bewähren, weshalb nach dieser Sicht ein Unterschied zwischen Theorie und Hypothese entfällt. Es soll dem Leser also nur das Auffinden von Fehlern so leicht wie möglich gemacht werden, da das Lernen aus Fehlern, aus Versuch und Irrtum eine der Hauptquellen für wissenschaftlichen Fortschritt ist. Aus Platzgründen wird auf eine ausführliche und verständlichere Darstellung dieser Problematik verzichtet. Gute Kritik an dieser Auffassung findet man bei Paul Feyerabend, Imre Lakatos oder Herbert Keuth.

9

2 Does IT Matter?

Auf die Frage, ob „Wirtschaftsinformatik heute noch das richtige Studium für künftige CIOs“ sei, da „Angeblich [...] Technik für [...] IT-Manager nur noch eine untergeordnete Rolle“ spiele, antwortet Scheer:

„Zweifelsohne bewegen sich die Aufgaben des CIOs in Richtung mehr fachlicher Kompetenz hin zum Chief Process Officer. Für strategische Entscheidungen benötigt der IT-Verantwortliche aber nicht nur betriebswirtschaftliches Wissen, sondern auch Kenntnisse über Basistechnologie. Wie soll er sonst Innovationspotenziale, neue Systeme oder IT-Partner beurteilen?“[Sch06a]

Dieses Zitat, das nur stellvertretend für viele steht, zeigt welchen Einfluss Carrs Aufsatz „IT Doesn’t Matter“ bis heute hat, wenn es um die Zukunft des CIO oder der IT geht. Oft werden dabei Formulierungen wie „IT spielt nur noch eine untergeordnete Rolle“ oder „IT wird unwichtig“ gebraucht, die in dieser Pauschalität natürlich abgelehnt oder nur eingeschränkt akzeptiert werden. Die wirklichen Überlegungen Carrs spielen meist eine untergeordnete Rolle und sollen daher in diesem Kapitel näher beleuchtet werden ¹ . Verwunderlich ist dabei die große Resonanz auf Carrs Artikel, denn seine Ideen sind nicht neu. Wesentliche Ideen Carrs findet man schon in John Deardens Artikel „The Withering Away of the IS Organization“ von 1987 [Dea87] ² oder in Max Hoppers Artikel „Rattling SABRE - New Ways to Compete on Information“ von 1990 [Hop90]. In der Literatur wird überwiegend Carrs „IT Doesn’t Matter“ zitiert, der Rückgriff auf diesen Artikel wird hier aber vermieden, da sich Carrs Argumente teilweise in seinem später erschienenen Buch „Does IT Matter?“ änderten. In erster Linie behandelt Carr die folgenden Themenkomplexe:

• IT als Massenware

• Schwindende Wettbewerbsvorteile durch IT

• Konsequenzen für das IT-Management

¹ Natürlich wurde Carrs Artikel auch positiv aufgenommen, z.B. von Mieze [Mie04]

² Dearden zieht allerdings andere Schlüsse aus seiner Analyse als Carr. Dearden setzt sich für eine Dezentralisierung des IT-Management ein (Was vermutlich daran liegt, dass sein Artikel mit dem Aufkommen der PCs zusammenfällt, die eine Dezentralisierung der IT ermöglichten), während bei Carr ein Unterschied zwischen Zentralisierung oder Dezentralisierung keine Rolle spielt. Genaugenommen setzt er fast stillschweigend ein zentrales IT-Management voraus. Vgl. dazu auch Punkt 3.4 in Kapitel 3.

10

2.1 IT als Massenware

Den Begriff der Massenware (Commodity) versteht Carr aus der Perspektive des Nutzers. Ein Produkt ist demzufolge genau dann Massenware für einen Betrieb, wenn es für alle Wettbewerber leicht verfügbar ist, sodass sich kein Unternehmen durch dieses Produkt langfristig von anderen Unternehmen unterscheiden kann [Car04, S. 152]. Carr behandelt in seiner Analyse der IT Hardware und Software getrennt. Dass heißt, dass die viel an Carr geäußerte Kritik, dass IT für ihn nur Hardware sei, wie z.B. bei Smith und Fingar [SF03, S. 56], nicht mehr greift. Den Datentransport über die Hardware vergleicht er mit dem Gütertransport über das Schienennetz oder der Energiever-sorgung durch das Stromnetz:

„IT can be thought of as a transport system, carrying digital data just as railroads carry goods and the electric grid carries energy“ [Car04].

Als einen der Vorreiter für die Massenware Hardware sieht Carr Michael Dell an, der u.a. mit seinem Direktvertriebssytem für mehr Wettbewerb und günstigere PCs sorgte. Als Vorbedingung für eine Massenware sieht Carr gemeinsame Standards an. So ist für ihn der Server-Markt in den 90ern mangels einheitlicher Standards kein Massenmarkt gewesen, da Sun, IBM und HP, teils bis heute, eigene Lösungen favorisierten. Durch die ständig fortschreitende Technik verschwinde mit der Zeit auch der Mehrwert, den Kunden von Neuentwicklungen im Vergleich zu günstigeren Vorgängermodellen haben. Auf diesen Gedanken wies z.B. Gordon bereits 2000 hin [Gor00, S. 63 ff.]. Er zeigte am Beispiel von Textverarbeitungsprogrammen, dass mit jeder neuen Version der Grenznutzen trotz steigender Rechenleistung abnimmt. Die größte Nutzensteigerung kam demnach mit dem Übergang von der Schreibmaschine zur Textverarbeitung unter DOS mit einem einfachen Texteditor. Die nächste Nutzensteigerung kam mit Programmen wie Word-Perfect 4.0 ³ als erstem WYSIWYG-Textverarbeitungsprogramm ⁴ . Alle später folgenden Microsoft-Textverarbeitungssysteme brachten daher immer weniger zusätzlichen Nutzen für den Anwender ⁵ . Siehe dazu Abbildung 2.1.

Dies läge daran, dass sich ausgereiftere und etabliertere Vorgängermodelle gut zur Massenfertigung eignen und damit auch leicht von der Konkurrenz imitierbar sind [Car04, S. 39]. Der Wettbewerb wechsle daher von den eher spezialisierten Lösungen zu dem Faktor Kosten ⁶ . Carr kommt dabei zu folgendem Schluss:

„Carried to its logical conclusion, the trend toward commodity hardware would end with disapperance, from a user’s standpoint, of the individual

³ 1987 war Word Perfect das am besten verkaufte Textverarbeitungsprogramm, die Erlöse übertrafen sogar die von Lotus 1-2-3 und dBase III. 1984 hatte Word Perfect erst einen Anteil von 1%, führend war zu diesem Zeitpunkt noch MicroPros WordStar mit einem Marktanteil von 23% [CK03, S. 254].

⁴ What you see is what you get

⁵ Gordon greift hier also auf das 1. Gossensche Gesetz (Gesetz vom abnehmenden Grenznutzen) zurück. Vgl. dazu z.B. [Cez05, S. 84 f.]

⁶ Da Carr an anderer Stelle Porters „Competitive Advantage“ zitiert, ist anzunehmen, dass er genau dessen Terminologie verwendet. Siehe dazu auch Punkt 2.2

11

Abbildung 2.1: Grenznutzen von Textverarbeitungsprogrammen. Quelle: [Gor00, S. 64].

components of the physical infrastructure. Companies would simply connect to the infrastructure through a cable or antenna, and all the functions their employees require would automatically be delivered to them. IT would become as simple to use as electricity“ [Car04, S. 40].

Software sieht Carr ebenfalls als Massenware an, da sie genauso wie andere Produkte, trotz ihrer abstrakten Form, gehandelt wird und somit den gleichen Gesetzen des Marktes wie jedes andere Produkt auch unterworfen ist. Hinzu kommt, dass wohl kaum ein anderes Produkt zu so geringen Kosten vervielfältigt werden kann. Carr stellt außerdem die These auf, dass Unternehmen ihre Eigenentwicklungen und damit auch ihre Unterscheidungsmerkmale gegenüber anderen Unternehmen zugunsten von Standardsoftware aufgeben, wenn sie dadurch ihre Kosten senken können. Als Beispiel nennt Carr den Beginn der kommerziellen Softwareentwicklung. Zu Beginn der 50er Jahren bezog man Software vor allem aus drei Quellen: man schrieb sie selbst, erhielt sie vom Computer-Hersteller oder teilte sie mit anderen. Oftmals blieb am Anfang nur die erste Option übrig, da die Computer-Hersteller kaum Software zur Verfügung stellten [CK03, S. 29] ⁷ .

In diesen Zeitraum fällt auch die Gründung der IBM-User-Group SHARE im Mai 1955. Das erste Treffen fand am 22. August 1955 statt [Arm80, S. 125]. SHARE steht nicht für ein Akronym. Schon durch den Namen sollte zum Ausdruck kommen, dass in SHARE Informationen miteinander geteilt werden sollen. Im Dezember 1955 folgte Ramington

⁷ Der Chairman von SHARE schrieb über IBMs erste Produktionscomputer 1956: „The vendor delivered [...] a number of copies of Principles of Operations (IBM Form 24-6024-1) of 103 pages (including 4 pages of octal-decimal conversion tables), a primitive assembler, and some utility programs (such as a one-card bootstrap loader, a one-card bootstrap clear memory, and the like). That was it“ [Arm80, S. 123].

12

Rands USE (Univac Scientific Exchange) und im Jahre 1956 IBMs User Group GUIDE, die zur weltweit größten User-Group wurde und sich auf die Märkte außerhalb der USA bezog, während SHARE für die USA bestimmt war [CK03, S. 33 f.]. Paul Armer beschrieb das Ziel von SHARE 1956 wie folgt: „Its aim is to eliminate, as much as possible, red-undant effort expended in using the 704. It seeks to accomplish this aim by promoting cooperation and communication among installations that use the 704“ [Arm80, S. 123]. Carr sieht daher in SHARE einen Vorläufer für die spätere Entwicklung im IT-Markt. Die an SHARE beteiligten Unternehmen seien bereit gewesen ein Stück ihrer Einzigartigkeit aufzugeben, in dem sie untereinander Programme austauschten ⁸ . Ihre Einzigartigkeit würden die Unternehmen aber nur opfern, wenn die Vorteile durch eingesparte Kosten überwiegen würden [Car04, S. 43]. Daraus schließt Carr:

„When a widely used resource is expensive and subject to strong scale economies, cost calculations will often trump strategic ones. What typically happens in such cases is that control over the provision of the resource shifts from the users to a group of outside suppliers“ [Car04, S. 44].

Des Weiteren wurde nach Carr die Entwicklung der Software durch die folgenden Entwicklungen und Faktoren erheblich vereinfacht und erleichtert [Car04, S. 52-55]:

• Modularisierung von Software

• Wiederverwendbarkeit von Softwaremodulen 9

• Das Aufkommen mächtigerer Programmiersprachen wie Basic, Fortran und Cobol, die die Programmierung im Gegensatz zur Assemblersprache erheblich vereinfachten.

• Neue Anwendungen wie Visual Basic, in denen schon viel Programmierarbeit durch grafische Benutzeroberflächen abegenommen wird.

• Die Anzahl der Programmierer wuchs stark an. Während sich in den 50er Jahren die Anzahl der Programmierer weltweit auf einige Tausend belief, liegt sie heute vermutlich schon im zweistelligen Millionenbereich.

• Programmierarbeit lässt sich teilweise genauso gut in Niedriglohnländern erledigen.

• Software lässt sich über das Internet sehr leicht verbreiten und verkaufen.

⁸ Bis zum Jahre 1956 wurden ungefähr 300 Programme von den teilnehmenden Unternehmen in SHARE eingebracht. Welchen Verlauf SHARE danach nahm ist unklar, da es sich bei der Quelle [Arm80], die Champbell-Kelly [CK03] zitiert, die wiederum Carr [Car04] zitiert, um den Abdruck einer Arbeit von 1956 handelt. GUIDE soll zumindest in späteren Jahren in erster Linie ein Forum zum Austausch über IBMs Produkte gewesen sein.

⁹ Vgl. hierzu auch Schmidt und Seidels Vorstellungen in Kapitel 5

13

Zukünftige Entwicklung der Software

Bei neueren Entwicklungen wie Web Services und SOA (siehe dazu auch Punkt 4.1.1) sieht Carr vor allem Softwarehersteller als treibende Kraft. Er schreibt (Vgl. hierzu besonders Punkt 2.2):

„Whatever the particular fate of Web services, architectural innovations will continue to appear in one form or another as vendors compete to make the IT infrastructure a more stable, flexible, and reliable conduit for business. The benefits of these advances will be great, but they will tend to be broadly and quickley shared“ [Car04, S. 59].

Um die Zukunft der IT-Architektur zu beschreiben, schließt sich Carr Scott McNealy an. McNealy vergleicht die IT-Architektur mit einem Auto. Früher habe jedes Unternehmen sein eigenes Auto aus unterschiedlichen Komponenten montiert. Mit der Folge, dass nur mit viel Aufwand Interoperabilität zwischen einzelnen IT-Landschaften möglich war. Heute habe ein Unternehmen vier Möglichkeiten. Erstens, es lagert seine IT aus, z.B. von IBM Global Service; Zweitens, es betreibt weiterhin eine selbst entwickelte IT-Landschaft; Drittens, es kauft eine komplett neue IT oder Viertens, es mietet sich eine fertige IT-Landschaft (wenn z.B. Anwendungen von einem externen Anbieter browserbasiert angeboten werden) [McN03, S. 27]. Die vierte Möglichkeit ist für McNealy so einfach wie das Bestellen eines Taxis. Diesen Vergleich spitzt Carr noch zu: „Hailing a taxi is something everyone can do equally well“ [Car04, S. 60]. Als Beispiel nennen Carr und McNealy [McN03, S. 28] Salesforce.com. Da diese CRM-Software browserbasiert ist, ist keine Integration in die Unternehmens-IT mehr nötig ¹⁰ .

2.2 Schwindende Wettbewerbsvorteile durch IT

In dem Kapitel „Vanishing Advantage“ vertritt Carr die Meinung, dass durch IT keine nachhaltigen Wettbewerbsvorteile mehr möglich sind. Wenn Carr von Wettbewerbs-vorteilen spricht, verwendet er die Terminologie Porters, zitiert ihn allerdings nicht in diesem Zusammenhang. Trotzdem ist annehmbar, dass Carr, wenn er von Wettbewerbs-vorteilen spricht, die drei Strategien Porters meint, die Unternehmen zu nachhaltigen Wettbewerbsvorteilen verhelfen sollen. Demnach müsste IT einem Unternehmen vor Allem bei dem Erreichen einer der folgenden Strategien helfen:

1. Kostenführerschaft

2. Differenzierung (Dem Kunden etwas Besonderes bieten, für das er bereit ist mehr zu zahlen)

3. Marktnischen besetzen (Und in dieser Nische Kostenführerschaft oder Differenzierung anstreben. Auch Konzentration genannt.)

¹⁰ Ein ähnliches Beispiel wäre z.B. das Reisebuchungssystem CWT Connect des Reiseunternehmens Carlson Wagonlit Travel (siehe www.cwtconnect.com)

14

Porter ist dabei wichtig, dass ein Unternehmen nur dann einen nachhaltigen Wettbe-werbsvorteil erreichen kann, wenn es sich auf eine dieser drei Strategien konzentriert. Nachhaltigkeit lässt sich also nur dadurch erreichen, dass man bestimmte Bereiche vernachlässigt, um in anderen hervorragend zu sein. Es gibt zwar Unternehmen, die Kostenführerschaft und Differenzierung gleichzeitig erreichen, diese befinden sich dann allerdings in einer leicht angreifbaren Position [Por04, S. 19] ¹¹ . Auch wenn Carr diese Einteilung nicht vornimmt, kann man durchaus sagen, dass Carrs Ideen zu diesem Thema auch dann Gültigkeit haben sollten, wenn ein Unternehmen seine IT-Infrastruktur streng an einer dieser drei Strategien ausrichtet. Carr argumentiert dabei wie folgt: Wenn Eigenentwicklungen von Software immer seltener werden und Software zunehmend von Software-Herstellern bereitgestellt wird, dann kann man sich auch weniger durch Software von den Konkurrenten abheben. Das Erreichen von nachhaltigen Wettbewerbsvorteilen sei damit durch IT nicht mehr möglich, da Konkurrenten genauso leicht Zugang zu dieser IT hätten. Hopper hingegen sah noch die Möglichkeit Wettbewersvorteile zu erreichen, in dem man IT richtig nutzt und folgt damit eher der Meinung, dass Management der IT wichtig sei (Vgl. Punkt 2.6).

¹¹ Porter nennt drei Fälle, in denen ein Unternehmen Kostenführerschaft und Differenzierung erreichen kann: Erstens, wenn die Wettbewerber mittelmäßig sind; Zweitens, wenn das Unternehmen über einen großen Marktanteil verfügt und Drittens, wenn das Unternehmen der Vorreiter in einer neuen Technologie ist [Por04, S. 19 f.]. Dennoch sei diese Strategie nicht ungefährlich, da ein Unternehmen nicht auf Dauer Anbieter von Premiumangeboten mit den niedrigsten Kosten in der Branche sein kann. Das soll nicht heißen, dass ein Premiumanbieter nicht möglichst Kosten sparen sollte, solange er nicht seine Differenzierung aufgibt. Oder dass ein Kostenführer nicht nach Differenzierungsmöglichkeiten suchen sollte, die nicht viel kosten [Por04, S. 20]. Neben diesen drei Strategien wird in der Literatur außerdem die Strategie der Mass Customization behandelt (zu ihr nimmt aber keine der zitierten Studien Bezug, weshalb sie nur in dieser Fußnote kurz aufgegriffen wird). Nach Piller besteht diese Strategie in der gleichzeitigen Verfolgung der Kostenführerschaft- und Differenzierungsstrategie [Pil97, S. 15]. Die Verfolgung von einer von Porters Strategien reiche aufgrund der neuen Marktbedingungen nicht mehr aus, weshalb man nun nach Kostenführerschaft und Differenzierung streben sollte. Dies bedeutet, dass Porters Strategien ihre Gültigkeit verlieren würden, da sie Mass Customization ausschließen. Ein Nebeneinander dieser Strategien wäre eine logische Unmöglichkeit. Andererseits spricht Piller nur von einer relativen Kostenführerschaft und sein Beispiel der maßgeschneiderten Levis Jeans ist auch nicht die ausgeprägteste Differenzierungsform wie etwa eine Designerjeans. Daher liegt Mass Customization eher in der Mitte von beiden Strategien und erreicht bei gleichzeitiger Verfolgung beider Strategien bei guten Wettbewerbern zumindest keine der beiden Strategien (Der Verkaufspreis der Levis Jeans ist z.B. 20% höher als der einer herkömmlichen). Da Mass Customization in bestimmten Bereichen dennoch sehr erfolgreich ist, ist also eher zu fragen wann sich der Einsatz von Mass Customization lohnt. In allen Branchen ist Mass Customization nicht durchführbar, zumindest zurzeit nicht. In der Automobilbranche kann es z.B. zu Problemen kommen, vgl. dazu [AKM01]. Auch in allen Bereichen, in denen Bestellungen stark schwanken, kann es schnell zu Engpässen kommen, da man nicht auf Lager fertigen kann. In anderen Bereichen, z.B. im E-Business, scheint sie aber durchaus erfolgreich zu sein [GS02]. Die portersche Einteilung löst Mass Customization aber nicht auf. So basiert z.B. nach Porter der Wettbewerbsvorteil von Levis nur auf Technologie. Levis müsste sich daher nach Porter bei einer größeren Verbreitung dieser Technologie mit der Zeit wieder an einer der drei im Text genannten Strategien (Kostenführerschaft usw.) orientieren. Alternativ könnte die Mass Customization auch „wegdefiniert“ werden, in dem man sie einfach als eine günstige Differenzierungsmöglichkeit eines Kostenführers ansieht, womit man sie wieder in Einklang mit Porter brächte. Individualisierung bietet ja schließlich einen zusätzlichen Nutzen, der die höheren Kosten mehr als ausgleicht.

15

Zu ähnlichen Ergebnissen wie Hopper kommen auch Mata, Fuerst und Barney. Sie untersuchten 1995 unter welchen Bedingungen IT einem Unternehmen zu nachhaltigen Wettbewerbsvorteilen verhelfen kann [MFB95]. Sie verfolgten dabei einen ressourcenbasierten Ansatz, der weit über Carrs Überlegungen zur Nachhaltigkeit von Wettbe-werbsvorteilen hinaus geht. Demnach ist ein Wettbewerbsvorteil nur dann nachhaltig, wenn er die folgenden drei Bedingungen erfüllt (Siehe dazu auch Abbildung 2.2):

• Die infrage kommende Ressource oder Fähigkeit muss einen Wert für den Kunden darstellen,

• sollte heterogen sein, d.h. sie sollte sich von denen anderer Unternehmen unterscheiden

• und diese Heterogenität muss andauernd sein (Immobilität der Ressource oder Fähigkeit).

Wie andauernd diese Heterogenität ist, ist davon abhängig wie schwer die Ressource/Fähigkeit imitierbar ist. Mata et al nennen drei Kategorien, in die man die meisten Quellen für schwer imitierbare Heterogenität einordnen kann. In die erste Kategorie fallen alle Quellen, die sich aus der Geschichte des Unternehmens ergeben und daher nur mit hohen Kosten imitierbar sind. In die zweite fallen alle, bei denen unklar ist, warum das Unternehmen Wettbewerbsvorteile besitzt. In diesem Fall steigen ebenfalls die Kosten für eine Imitierung. In die letzte Kategorie fallen alle Quellen, die sozial komplex sind. Dies kann z.B. eine besondere Unternehmenskultur sein. Ein nachhaltiger Wettbe-werbsvorteil durch IT kann also dann erzielt werden, wenn sich die Quelle dieses Wett-bewerbsvorteils einer der drei genannten Kategorien zuordnen lässt und Abbildung 2.2 genügt. Nach genau diesem Ansatz (die drei Kategorien + Abbildung 2.2) untersuchten Mata et al die folgenden Quellen für nachhaltige Wettbewerbsvorteile:

1. IT-Switching-Costs 12 erhöhen 13 . Diese Strategie verfolgte mit IT z.B. AHS (heute Baxter Healthcare) mit seinem Bestellsystem ASAP. ASAP (ein Bestellsystem für Krankenhäuser) wurde in den 70er Jahren von AHS entwickelt. Die Kunden mussten erst in IT investieren, bevor sie ASAP nutzen konnten. Da diese IT aber nur mit ASAP kompatibel war, erhöhten sich automatisch die Kosten für einen Wechsel zu einem Konkurrenzprodukt [Car04, S. 72ff.][MFB95, S. 490]. Da heute Hardware günstiger von Hardware-Herstellern bezogen werden kann, in der Regel einheitliche Standards existieren und Kunden hohe Kosten für einen Wechsel von einem auf ein anderes System scheuen, seien nachhaltige Wettbewerbsvorteile über diese Strategie kaum noch zu erreichen. Im Gegenteil, das Verfolgen einer solchen Strategie kann sogar dazu führen, dass man seine Kunden verliert, wenn man sie mit

¹² Switching-Costs sind die Kosten, die einem Kunden zusätzlich entstehen, wenn er zu einem anderen Anbieter wechselt. Z.B. der Kauf neuer Hardware, da der neue Anbieter eine andere Schnittstelle verwendet.

¹³ Auch „The create-capture-keep paradigm“ genannt.

16

2. Eigenentwicklungen, sie können dann zu einem nachhaltigen Wettbewerbsvorteil verhelfen, wenn man sie vor der Konkurrenz geheimhalten kann. Patente auf Eigenentwicklungen sind allerdings nur bedingt ein Schutz, da sie nicht vor Imitation schützen. Aus diesem Grunde ist es unwahrscheinlich mit Eigenentwicklungen nachhaltige Wettbewerbsvorteile zu erzielen, da sie kaum geheim zu halten sind.

3. Technische Fähigkeiten sind unabdingbar für den Einsatz von IT. Sie erzeugen nach Abbildung 2.2 zwar Wert, sind allerdings sehr mobil. Selbst dann, wenn sie sehr ungleichmäßig über verschiedene Unternehmen verteilt sind. Aus diesem Grund schätzen die Autoren technische Fähigkeiten bestenfalls als einen temporären Wettbewerbsvorteil ein.

4. IT-Management-Fähigkeiten. Unter IT-Management wird hier z.B. die Fähigkeit verstanden, die IT-Bedürfnisse der einzelnen Geschäftseinheiten zu verstehen, mit ihnen zusammenzuarbeiten, die IT richtig zur Unterstützung von Lieferanten und Geschäftseinheiten einzusetzen und zukünftige IT-Bedürfnisse von Kunden, Liefe-

¹⁴ Chenund Forman stellten fest, dass es Herstellern von Switches und Servern auch in einer Open-Source-Umgebung noch gelang, die Switching-Costs zu erhöhen. Gerade Hersteller wie Microsoft oder Cisco konnten durch diese Strategie die Verbreitung neuer Technologien anderer Hersteller verzögern und gewannen so Zeit, diese neue Technologien selbst in ihre Produkte zu implementieren[yCF06, S. 560 f.].

17

ranten und Geschäftseinheiten vorwegzunehmen. Das IT-Management sehen Mata et al als Quelle für Wettbewerbsvorteile durch IT an. Nur das IT-Management könne die technischen Fähigkeiten des IT-Personals heben und zum Vorteil des Unternehmens einsetzen (Dieser Punkt wird noch ausführlicher in 2.6.2 behandelt).

2.3 Das IT-Produktivitätsparadoxon

Um seine Theorie zusätzlich zu untermauern zitiert Carr Studien, die sich mit dem IT-Produktivitätsparadoxon beschäftigen ¹⁵ . Diese Studien werden in Punkt 2.3.2 behandelt. Zuvor wird das IT-Produktivitätsparadoxon einleitend in Punkt 2.3.1 auf makroökonomischer Ebene behandelt.

Mit diesem Paradoxon bezeichnet man das Phänomen, dass sich der Einsatz von IT in den Statistiken nicht durch höhere Produktivität niederschlägt.

2.3.1 Das Solowsche Produktivitätsparadoxon

Die neoklassische Wachstumstheorie nach Solow und ihre Weiterentwicklungen weisen auf die enge Beziehung zwischen Wirtschaftswachstum und technischen Fortschritt hin. Diese traditionellen „neoklassische[n] Modelle vom Solow-Swan-Typ behandeln den technischen Fortschritt noch als eine exogene Größe [die] wie „Manna vom Himmel“ fällt und somit einem reinen öffentlichen Gut gleicht“ [Sch00, S. 6 ff.]. Im Gegensatz dazu behandeln neuere Modelle den technischen Fortschritt als endogene Größe, d.h. der technische Fortschritt soll aus dem Modell heraus erklärbar sein. Das Solowsche Produktivitätsparadoxon besteht nun darin, dass sich der technische Fortschritt der Computerbranche nicht in der gesamtwirtschaftlichen Produktivität niederschlägt. Abbildung 2.3 zeigt die durchschnittliche Wachstumsrate der Arbeitsproduktivität ¹⁶ sowie der IT-Investitionen in den USA über den Zeitraum von 1947 bis 1995 hinweg. Die Grafik zeigt deutlich, dass ein Rückgang des Arbeitsproduktivitätswachstums verzeichnet wird, während die Investitionen in IT deutlich anstiegen. Um dieses Paradoxon zu erklären, wird z.B. häufig angeführt, dass der Großteil der IT-Investitionen auf den Dienstleistungssektor entfalle ¹⁷ . So kamen z.B. mehr als 70% der IT-Investitionen des privaten Sektors bis zu den 1990er Jahren aus dem Dienstleistungsbereich. „Allein im Jahre 1992 können knapp 38% aller von der US-Wirtschaft vorgenommenen Investitionsprojekte als IT-Investitionen des Finanz-, Versicherungs- und Immobiliengewerbes identifiziert werden“ [Sch00, S. 16]. Grichilis kommt daher zu folgendem Schluss:

„The major answer to this puzzle is very simple: over three-quarters of this investment has gone into our ’unmeasurable’ sectors, and thus productivity effects, which are likely to be quite real, are largely invisible in the data“ [Sch00, S. 17, Griliches nach Schreyer].

¹⁵ Die Studien sind [HB96] und [PH97], siehe dazu Punkt 2.3.2

¹⁶ Ohne Landwirtschaft.

¹⁷ Vgl. dazu Punkt 2.3.2, der sich noch einmal mit „Erklärungsversuchen des IT-Produktivitätsparadoxon“ auf Unternehmensebene auseinandersetzt

18

Nach anderen Untersuchungen machen die Messprobleme des Dienstleistungssektors nur ein Drittel oder 12% des Produktivitätsrückgangs aus [Sch00]. Daher sind Zweifel angebracht, ob das Produktivitätsparadoxon durch den Dienstleistungssektor erklärbar ist. Da der Produktivitätsrückgang auch recht plötzlich in den 70er Jahren in allen OECD-Staaten einsetzte, müsste es in diesen Jahren einen deutlichen Zuwachs des Dienstleistungssektors gegeben haben, wenn der Produktivitätsrückgang in erster Linie durch Messprobleme im Dienstleistungssektor erklärbar sein soll. Dies ist aber nicht der Fall.

Von anderen Theoretikern wird die Meinung vertreten, dass das Potential der IT noch nicht richtig genutzt würde und dass wir uns erst in einer Übergangphase befänden (Vgl. dazu Perez in Punkt 2.4). Der Computer ist demnach eine Basisinnovation, die erst mit einiger Verzögerung wirtschaftlich spürbar wird. In dem Zeitraum von 1995 bis 1999 kam es allerdings zu einem starken Wachstum. Die Arbeitsproduktivität wuchs in den USA in diesen Jahren um durchschnittlich 2,58%, während gleichzeitig die IT-Investitionen aufgrund des Preisverfalls ¹⁸ der IT stark anstiegen. Allerdings wies Gordon 1999 darauf hin, dass dieses Wachstum nicht struktureller Natur ist. Er führt das Wachstum in diesem Zeitraum auf drei Gründe zurück [Gor99, S. 22]:

1. Änderungen in der Messung des Bruttoinlandsprodukt (GDP) in den USA

2. Immer leistungsfähigere Computer, die für exponentielles Wachstum bei den Computer-Herstellern sorgten, die nur 1,2% der US-Wirtschaft ausmachen;

3. Den Konjunkturzyklus, der normalerweise immer wachse, wenn der Output größer als der Trend ist.

2.3.2 Das IT-Produktivitätsparadoxon auf Unternehmensebene

Um seine Argumentation zu stützen, führt Carr zwei Studien an ([HB96] und [PH97]), in denen die Produktivität und die Profitabilität von IT in Unternehmen untersucht wird ¹⁹ . In der ersten Studie wurden von Hitt und Brynjolfsson [HB96] 370 große US-Unternehmen untersucht [Car04, S. 64 ff.]. Dabei stellte man fest, dass IT-Investitionen die Produktivität steigern und meist eine hohe Verzinsung des eingesetzten Kapitals ermöglichen. Zu dem Ergebnis, dass IT-Investitionen die Produktivität erhöhen, kam Brynjolfsson auch in einer späteren und breiteren Analyse [Bry03]. Allerdings gab es in den

¹⁸ Allein von 1995-1998 sanken die Preise um knapp 28% pro Jahr, von 1990 bis 1995 waren es 15% pro Jahr [Sch00, S. 45]

¹⁹ „Die Erklärung eines bestimmten Ablaufs aus einer einzigen Ursache, eine mono-kausale Erklärung also, ist jedoch bei Vorgängen, die erfahrungsgemäß komplexer zu sein pflegen, nur selten stichhaltig“ [Gla65, S. 157]. Die teilweise verwendeten mono-kausalen Erklärungen unterstellt indirekt, dass Profitabilitätssteigerungen nur auf den Faktor IT-Investition zurückzuführen sind. Aus diesem Grund ist es nicht verwunderlich, dass es bis heute viele, zum Teil sehr aufwendige Studien zu diesem Thema gibt, die zu unterschiedlichen Ergebnissen kommen.

19

Ergebnissen eine sehr breite Streuung, d.h. die IT-Produktivität verteilte sich sehr gleichmäßig über die Unternehmen und schwankte von einem positiven über einen neutralen bis hin zu einem negativen Einfluss auf die IT-Produktivität. Die Ergebnisse besitzen also keineswegs die hohe Eindeutigkeit, die in manchen Untersuchungen unterstellt wird. Dennoch ist insgesamt ein positiver Einfluss der IT auf die Produktivität gemessen worden.

Allerdings hat der IT-Einsatz nach Hitt und Brynjolfsson [HB96] einen negativen Einfluss auf die Profitabilität. So wird durch den IT-Einsatz neben der erhöhten Produktivität zwar ein höherer Wert für den Kunden generiert, dieser höhere Wert würde aber zumindest in den untersuchten Unternehmen an den Kunden weitergegeben. Daher sei kein Anstieg der Profitabilität durch den bloßen IT-Einsatz messbar. Die Autoren warnen aber davor, daraus den voreiligen Schluss zu ziehen, dass IT nur den Wert für den Kunden erhöhen würde und Profite zunichte macht. Dem Management geben Hitt und Brynjolfsson zwei Empfehlungen, für die sie auf die besprochenen Strategien von Porter zurückgreifen:

„First, when cost is the central strategic issue in an industry, our productivity results suggest that IT investment may be one way to pursue a cost leadership strategy, provided that the cost reductions cannot be emulated by other firms. However, for industries where cost is not the central strategic issue or where there are few barriers to adoption of IT, firms are unlikely to create lasting competitive advantage simply by spending more on IT. This raises the second issue: managers seeking higher profits should look beyond productivity to focus on how IT can address other strategic levers such as product position, quality, or customer service. While IT can potentially lower

20

the cost of providing these services, attaining competitive advantage may involve using IT to radically change the way products or services are produced and delivered in a way that cannot be duplicated by competitors. This may be possible by leveraging existing advantages with IT or using technology to target other segments of the industry where competition is less intense“ [HB96].

Hitt und Brynjolfsson schließen also nicht aus, dass ein überlegter IT-Einsatz zu Wett-bewerbsvorteilen führen kann. Höhere IT-Ausgaben allein seien aber kein Garant für Erfolg. Unternehmen könnten aber versuchen, die Vorzüge der IT zu nutzen, um Chancen auf dem Markt wahrzunehmen. Durch selektives Zitieren erweckt Carr beim Leser den Eindruck, dass nach Hitt und Brynjolfsson keine Wettbewerbsvorteile durch IT möglich wären:

„Their examination of company financial data „showed little evidence of an impact of IT on supranormal profitability“ and indeed suggested „the possibility of an overall negative effect of IT in profitability.“ Consumers, however, appeared to receive substantial economic benefits from companies’ investments in IT. In conclusion, the researchers reported that „our profitability results suggest that, on average, firms are making the IT investments necessary to maintain competitive parity but are not able to gain competitive advantage.““ [Car04, S. 64]

Hitt und Brynjolfsson untersuchten in ihrer Arbeit die Profitabilität und die Produktivität von IT sowie den Wert für den Verbraucher, der durch IT generiert wird. An der von Carr zitierten Stelle beziehen sie sich nur auf ihre Untersuchungsergebnisse zur Profitabilität. Diese Ergebnisse sind aber keinesfalls ihre „conclusion“, wie die oben zitierte Stelle aus Hitts und Brynjolfssons Arbeit zeigt. Das folgende Zitat ist aus der zweiten Studie, die Carr anführt. Sie soll zeigen, dass durch IT kein strategischer Wettbewerbsvorteil mehr möglich ist:

„The easy availability of IT to all banks implies that IT investments do not provide any competitive advantage. In other words, since there is no „barrier to entry“ in terms of IT in the retail banking industry, a bank investing in IT does not stand to gain additional market share as a result of its investment. In fact, by not investing in IT and by foregoing the gains provided by it, a firm may, on the other hand, lose market share (Clemons 1991). Thus, in this competitive environment of retail banking, neither IT capital nor IT labor investments should make significant impacts on the firm’s profitability. The results bear this hypothesis out: IT investment has zero or insignificant effect on bank profitability [PH97, S. 18].“ 20

²⁰ Carr zitiert abermals aus diesem Zitat nur Teile und lässt den Satz „In fact, by not investing in IT and by foregoing the gains provided by it, a firm may, on the other hand, lose market share“ aus. Er erwähnt leider auch nicht das sehr interessante Fazit dieser Studie, das nicht einmal unbedingt mit Carr im

21

Prasad und Harker [PH97] stellen ebenfalls fest, dass IT-Investitionen nicht zwingend zu höherer Profitabilität führen. Es ist hier aber zu vermuten, dass die Zahlen ähnlich weit gestreut sind wie die der 1167 oben erwähnten Unternehmen, die Brynjolfsson untersuchte [Bry03]. Prasad und Harkers [PH97] Schlussfolgerung wird auch bestätigt von den Ergebnissen von Westwood und Holland ²¹ . Sie untersuchten die Erträge im britischen Bankensektor. Dabei stellten sie fest, dass „die Bandbreite der Ertragsspanne zwischen den erfolgreichsten und den wenig erfolgreichen Banken über viele Jahre recht stabil war, seit Mitte der 90er Jahre aber stark“ auseinander klaffte [BBG ⁺ 04]. Klein [BBG ⁺ 04] stellt daher die Hypothese auf, dass die Banken mit gutem Management in größerem Maße von IT profitierten, während jene mit schlechter Performance starke Einbrüche hinnehmen mussten. Diese Untersuchung legt also nahe, dass IT-Investitionen zumindest bestehende Unterschiede zwischen Unternehmen zusätzlich verstärken. An dieser Stelle bewähren sich auch die Schlussfolgerungen aus der Studie von [PH97]. Die Höhe der IT-Investitionen ist also weniger ausschlaggebend als der intelligente Umgang mit IT, der auch maßgeblich von qualifiziertem IT-Personal abhängig ist. Oftmals werden bestehende Potentiale einfach nicht richtig ausgenutzt ²² .

Erklärungen für das IT-Produktivitätsparadoxon

Gründler hat die verschiedenen Erklärungsversuche des IT-Produktivitätsparadoxon auf Unternehmensebene wie folgt zusammengefasst:

Umverteilung der Gewinne durch stärkeren Wettbewerb: Bei dieser Erklärung geht man davon aus, dass der Einsatz von IT dazu führt, dass Unternehmen mit hohen IT-Aufwendungen die Kunden der restlichen Unternehmen abwerben und es so nur zu einer Umverteilung der Gewinne kommt.

Messprobleme des Inputs und Outputs: Messprobleme der IT-Produktivität werden besonders im Dienstleistungssektor deutlich. Zum einen weil Dienstleistungen nicht greifbar sind, zum anderen weil mehr Flexibilität, höhere Qualität,

Widerspruch steht:

„This paper has shown the importance of IT labor in the overall productivity and profitability of the U.S. banking industry. Beyond the econometric analysis, the paper presents an explo-ratory investigation into what characteristics of a bank lead to effective use of IT labor. All of this analysis points to the need to continually invest in not only the technical skills of this work force, but their industry-specific knowledge as well. As the „process engineers“ of the organization, IT labor is crucial in the design, control, and execution of service delivery in banks. Thus, a key driver of efficiency and effectiveness in the industry in the management of the IT labor force and procurement process.“[PH97, S. 29]

²¹ Nach Klein [BBG ⁺ 04].

²² Ein gutes Beispiel dürfte hier z.B. die Groupware Lotus Notes sein. In vielen Betrieben ist die Funktion SameTime von Lotus Notes deaktiviert. Dabei würde diese Funktionalität viele Kommunikationsprozesse bei flächendeckenden Einsatz beschleunigen. Dank des implementierten Chats ist die Kommunikation auch ungezwunger als im Schriftverkehr. Schon Fayol wollte am liebsten jeden Schriftverkehr abschaffen [Fay29, S. 33 f.] und durch persönliche Kommunikation ersetzen.

22

schnellere Lieferzeiten oder mehr Varianten sich kaum in steigender Produktivität niederschlagen. Erschwerend kommt hinzu, dass die meisten IT-Investitionen im Dienstleistungssektor getätigt werden [Grü97, S. 76f.]. Auch eine höhere Arbeitsqualität fließt nicht in die Statistiken mit ein. Um die Inputs und Outputs, und damit letztlich die Produktivität, über lange Zeiträume vergleichen zu können, muss man sie um die Inflation bereinigen. Da sich die Produkte und die IT aber schnell wandeln, müsste man die Inputs und Outputs auch um die Qualität bereinigen, die „das größte Problem bei der Bemessung von Input und Output“ darstellt.

Mangelnde Reinvestition von mitarbeiterbezogenen Einsparungen: Auch wenn die Möglichkeiten von IT ausgenutzt werden, müssen sie nicht zwangsläufig zu Produktivitätssteigerungen führen. Wird ein Prozess z.B. mit IT gestützt, erfolgt nur eine Produktivitätsteigerung „wenn entweder Personal abgebaut, die Tätigkeit erweitert oder die eingesparte Zeit zur Qualitätsverbesserung der Aufgabe verwendet wird. [...] So haben die Gestaltungsmöglichkeiten moderner Bürosoftware zu ausufernden Ansprüchen an die Gestaltung von Schriftstücken geführt. Für die Überarbeitung und Präsentation bereits bestehender Inhalte wird immer mehr Zeit aufgewendet, oft zu Lasten ihrer inhaltlichen Verbesserung“ [Pil98].

Gewinne durch IT werden mit Verzögerung realisiert: Es dauert z.B. seine Zeit bis neue Produkte mit einer neuen IT-Umgebung entwickelt sind und sich in den Bilanzen niederschlagen. Genauso benötigen die Mitarbeiter eines Unternehmens Zeit, bis sie sich mit einer neuen Anwendung vertraut gemacht haben, um deren Potential auszuschöpfen. Wird der Nutzen einer IT-Investition allerdings nur kurz nach der Implementierung gemessen, „kann es [...] so scheinen als ob die Investition unrentabel ist“ [Grü97, S. 79].

Abläufe werden unzureichend reorganisiert: Oftmals wird versucht, die bestehenden Abläufe eins zu eins in die IT zu übertragen, ohne die Möglichkeiten, die die neue Technik bietet, überhaupt auszuschöpfen. Ein Anzeichen dafür kann es z.B. sein, wenn Anwendungssysteme streng nach Funktionen getrennt sind und Möglichkeiten für „vertikale und horizontale Aufgabenintegration“ [Grü97, S. 79 f.] ausgelassen werden. Interessant ist an diesen Erklärungsansatz auch die historische Parallele: „So wurde David zufolge der Elektromotor Ende des 19. Jahrhunderts zunächst nur auf dieselbe Art und Weise genutzt wie die Dampfmaschine“ [Sch00, S. 28].

Missmanagement der IT: Gründler betont, dass das Missmanagement nicht nur ungewollt ist, sondern auch politische Gründe haben kann oder aus „nicht richtig abgestimmte[n] Ziel- und Anreizsystemen“ [Grü97, S. 80] resultieren kann.

Widerstände gegen den IT-Einsatz: Da mit der Einführung von IT-Systemen oft Reorganisationen verbunden sind, kann es zu Ängsten vor Macht- und Statusverlust kommen. Auch die Angst vor mehr Transparenz bei der Einführung vernetzter Informationssysteme führt zur Abwehrreaktionen. „In dieses Bild passen

23

verschiedene Umfrageergebnisse aus den USA und Europa, die alle gemeinsam zu der Aussage kommen, daß die erhöhte Komplexität der Umwelt in unserer Gesellschaft verstärkt zu einer generellen Technologieangst führt“ [Grü97, S. 81f.] ²³ .

2.4 Die Ausbauphase der IT (IT buildout) ist

erreicht

Carr nennt fünf Anzeichen dafür, dass der „IT buildout is much closer to its end than its beginning“ [Car04, S. 85]: IT bietet immer mehr Funktionalitäten (1), die der Nutzer eigentlich nicht braucht (Carr vertritt also auch Gordons These vom abnehmenden Grenznutzen von IT, Vgl. Abbildung 2.1). Gleichzeitig sei sie dabei aber so günstig geworden, dass sie sich mehr oder weniger jeder leisten könne (2). Außerdem stehe mittlerweile z.B. durch Glasfiberkabel mehr Bandbreite zur Verfügung als benötigt werde (3) und große IT-Hersteller böten immer mehr Dienstleistungen „on demand“ an (4), rechnen also zunehmend nach Nutzung ab.

Besonders widersprochen wurde dem fünften Anzeichen, dass Carr schon in „IT doesn’t matter“ anführte (5): „Finally, and most definitively, the investment bubble has burst, which historically has been a clear indication that an infrastructural technology is reaching the end of its buildout“ [Car03, S. 47]. Smith und Fingar antworteten darauf in ihrer Kritik an Carrs Artikel mit Carlota Perezs Buch „Technological Revolutions and Financial Capital“:

„In their book, Technological Revolutions and Financial Capital, they take a long-term perspective on the good and bad times in the economy and link technology and finance to „patterns of speculative exuberance, followed by crash, followed by a strong buildout period“ [SF03] ²⁴ .

Carr wiederum zitiert ebenfalls Perez, um seinen Satz nun theoretisch zu unterfüttern:

„Finally, and perhaps most tellingly, an enormous investment bubble has expanded and burst, which historically has been an indication that an infrastructural technology is reaching the end of its buildout. In her seminal book Technological Revolutions and Financial Capital, Carlota Perez divides the period of adaption of a new and broadly used technology into two phases. [...] The collaps of the bubble signals that „a new infrastructure is in place“

²³ Dies scheint allerdings in dieser Ausprägung eher ein Problem der westlichen Welt zu sein. Den Japanern ist diese Technologieangst z.B. fremd.

²⁴ Mit ihrem „their“ beziehen sich Smith und Fingar auf Carlota Perez und Chris Freeman. Das Buch ist aber nur von Carlota Perez verfasst. Perez und Freeman veröffentlichten allerdings 1988 gemeinsam den Aufsatz „Structural Crisis of Adjustment: Business Cycels and Investment Behavior“. Des Weiteren argumentieren Smith und Fingar, dass z.B. das Eisenbahnnetz nach der Investitionsblase von 1847 noch erheblich ausgebaut wurde. Dieser Einwand ist aber irrelevant, da Perez nach der Phase der Investitionsblase quasi Phasen der Massenproduktion sieht. So gesehen ist der erhebliche Anstieg von Schienenkilometer nach 1847 durchaus mit Carr vereinbar [SF03, S. 53].

24

and that „the new way of doing things with the new technologies has become ’common sense’“ [Car04, S. 85].

Wie im Zitat von Smith und Fingar schon deutlich wurde, schreibt Perez keineswegs, dass das Platzen der Blase ein Anzeichen für den Ausbau einer Infrastruktur ist. Im Sinne Perez setzt nach dem Platzen einer Blase ein Lernprozess ein und das momentan vorherrschende Paradigma wird zur allgemein akzeptierten Methode. Um den Paradigma-Begriff Perezs zu verstehen, soll hier kurz ihre Theorie umrissen werden. Perezs Theorie ist eine Verbindung aus den kuhnschen Paradigmen ²⁵ und den schumpeterschen Überlegungen zu Konjunkturzyklen. Sie überträgt das kuhnsche Paradigma, das ursprünglich nur für die Wissenschaft gilt, auf die Wirtschaft. Diese Paradigmen nennt sie technoökonomische Paradigmen (techno-economic paradigm). Ein Paradigma bei Kuhn ist z.B. die „Korpuskular Optik“ oder die „allgemeine Relativitätstheorie“. Dabei schließt der Begriff Paradigma nicht nur die Theorie ein. Um zum Paradigma zu werden, muss die Theorie eine Anhängerschaft von Wissenschaftlern anziehen, „die ihre Wissenschaft bisher auf andere Art betrieben [haben], und gleichzeitig [muss] sie noch offen genug [sein], um der neuen Gruppe von Fachleuten alle möglichen ungelösten Probleme zu stellen“ [Kuh76, S. 25]. Ein techno-ökonomisches Paradigma ist nach Perez ein bestpractice-Modell, dass aus einem Set von alles durchdringenden generischen Technologie-und Orangisationsprinzipien besteht. Diese Prinzipien repräsentieren den effizientesten Weg, um eine partikulare technologische Revolution anzuwenden und um sie für die Modernisierung und Verjüngung einer Wirtschaft einzusetzen [Per03, S. 15]. ²⁶ Während es auch in einer Wissenschaft mehrere Paradigmen geben kann, die Konsens sind, gibt es nach Perez immer nur ein etabliertes techno-ökonomisches Paradigma. Dieses Paradigma durchläuft fünf Phasen, ehe es von einem neuen abgelöst wird. Abbildung 2.4 zeigt diese Phasen anhand dem letzten und dem gerade etablierten technoökonomischen Paradigma. Jedes erfolgreiche techno-ökonomische Paradigma leitet eine neue große Entwicklungswelle ein (ähnlich den Kondratieff-Zyklen). Es folgt eine Beschreibung der fünf Phasen:

1. Die erste Phase dieser Entwicklungswelle ist die des „Eindringens“ (irruption phase). In dieser Phase ist viel Risikokapital vorhanden, dass in die neuen Produkte und Entwicklungen, die das neue Paradigma ermöglicht, investiert werden. In dieser Phase setzt auch der Prozess der kreativen Zerstörung von Schumpeter ein. Alte Branchen, die nicht den Entwicklungen, die das neue Paradigma mit sich bringt, gewachsen sind, verschwinden. Die Arbeitslosigkeit steigt an.

2. Die zweite Phase der Installationsphase nennt Perez die des „Wahnsinns“ (frenzy phase). In ihr verschärfen sich die Unterschiede zwischen arm und reich, es gibt viel Wettbewerb, die Gesellschaft individualisiert sich zunehmend, die Unternehmen werden stark überbewertet und es werden Überkapazitäten aufgebaut.

²⁵ Von Kuhn stammt auch der mittlerweile durch inflationären falschen Gebrauch zur Bedeutungslosigkeit verkommene Begriff des Paradigmenwechsels.

²⁶ In diesem Punkt unterscheidet sich Perezs Paradigma vom Kuhnschen. Für Kuhn muss ein neues Paradigma nicht besser sein als das alte, er leugnet auch, dass es „definitiven Fortschritt gäbe, mehr noch: dass wir Fortschritt gar nicht genau bestimmen könnten“ [SR02, S. 158].

25

3. Die dritte Phase beendet mit dem Platzen der Investitionsblase die zweite Phase und es kann zu Protesten kommen. Eine Rezession setzt ein.

4. Je nach dem wie stark das neue Paradigma ist und welche Rahmenbedingungen gesetzt werden, folgt die vierte Phase, die Synergiephase (synergy phase). Diese Phase ist die erste Phase der Entwicklungsperiode (deployment period). Es ist eine Phase der Massenproduktion und der Expansion. Die Wirtschaft wächst gleichmäßig, die Arbeitnehmerrechte und der Mittelstand werden gestärkt und der Wohl-stand wächst. Technologie wird als eine positive Kraft angesehen und die Arbeitslosigkeit sinkt.

5. Die letzte Phase ist die der Sättigung (maturity phase). Sie ist gekennzeichnet durch das Ende des vorherrschenden techno-ökonomischen Paradigmas. Die Produkte haben immer kürzere Lebenszyklen, der Markt ist gesättigt, die Gewerkschaften fordern weiterhin Lohnerhöhungen, es kommt zu einer starken Konzentration in den Branchen. Das bestehende System wird zunehmend hinterfragt wie z.B. durch die „Hippie-Bewegung“ 1968 in den USA, gleichzeitig gibt es Kräfte, die am alten Paradigma festhalten. Perez schreibt: „The stage is set for the decline of the whole mode of growth and for the next technological revolution“. [Per03, S. 49-56]

Perez betont allerdings, dass sich die Entwicklungswellen überlappen können. Sie ist sich auch keineswegs sicher ob die dritte Phase (Turning Point) bereits durchlaufen wurde. Damit das jetzige Paradigma in die nächste Phase übergehen kann, müssten zuerst die strukturellen Probleme gelöst werden, die die letzte Rezession auslösten. Würde dies geschafft, so müsste nach Perez eine neue Periode des Wachstums und Wohlstands folgen. Ein Übergang in die vierte Phase, in die Entwicklungsperiode also, kann durchaus im Sinne Carrs interpretiert werden. Denn es käme wie Carr richtig diagnostiziert, zu einem Zeitalter der Massenware Computer und Software. Ebenso würde eine weitere Konzentrationswelle auf längere Sicht einsetzen.

Die Anwendung dieses Modells, auch für langfristige Prognosen, dürfte sehr schwierig sein, da Konjunkturzyklen allgemein „sowohl [in ihrer] Frequenz als auch [ihrer] Amplitude der einzelnen Zyklen so unterschiedlich [sind], daß von einem gewissermaßen gesetzmäßig wiederkehrenden typischen Konjunkturzyklus nicht gesprochen werden kann“ [Cez05, S. 466]. Perez unterstellt dem Kapitalismus aber ein ihm immanentes Gesetz.

2.5 Konsequenzen für das IT-Management

Am Ende seines Buches stellt Carr vier Handlungsempfehlungen für das IT-Management an: Ausgaben senken; nicht die neuste IT-Technik verwenden, lieber der Entwicklung folgen; Eigenentwicklungen nur bei geringen Risiko ²⁷ ; die eigenen Schwächen fokussieren,

²⁷ Dieser Punkt war in „IT Doesn’t Matter“ noch nicht vorhanden und zeigt genau wie der Titel „Does IT Matter?“, dass auch Carr trotz großer Kritikresistenz der IT größere Bedeutung zumisst.

26

cherkapazität eines typischen Windows-Netzwerkes mit Spam, mp3s oder Video-Clips verschwendet. Carr schlägt vor, dass den Anwendern z.B. nur ein bestimmter Raum an Speicher zugewiesen wird. Andere Möglichkeiten sieht Carr im Auslagern von IT oder im Umstieg auf Linux. So habe E-Trade 1998 für 14 Millionen Dollar sechzig Sun-Server gekauft, deren jährliche Wartungskosten 1,5 Millionen Dollar betrugen. 2002 wurden diese durch 80 Linux-Server ersetzt, die 320 000 Dollar kosteten und die Wartungskosten erheblich reduzierten. Carr empfiehlt sogar, stellenweise den Mitarbeitern den Zugriff auf das Internet zu verbieten [Car04, S. 115].

2. Nicht die neuste IT-Technik verwenden, lieber der Entwicklung folgen. Wer später einsteigt, habe Vorteile, da er aus den Fehlern und Erfolgen der Innovatoren lernen könne und auf homogenere und standardisiertere Lösungen zurückgreifen kann, die sich auch leichter bei Partnern einbinden lassen. Neue Produkte seien hingegen oft um ein vielfaches teurer und selten kompatibel, wenn es bei ihrer Entwicklung noch keine anerkannten Standards gab.

3. Innovationen nur bei geringem Risiko. Ein Unternhemen sollte nur zum Innova-tor werden, wenn die Risiken abschätzbar sind und ein Wettbewerbsvorteil möglich wird. So könne ein Unternehmen mit Marktmacht wie z.B. WalMart gefahrlos in RFID-Chips investieren. Zumal WalMart einen Teil der Kosten auf seine Lieferanten abwälzen konnte, da diese ebenfalls die Technologie einführen mussten,

27

um ihre Verträge mit WalMart zu behalten. Ansonsten sollten Unternehmen nur Innovationen betreiben, wenn diese sehr spezialisiert sind, nicht leicht nachgeahmt werden können und sich nur schwer verbreiten und standardisieren lassen [Car04, S. 127]. Strategische Vorteile für Start Ups in etablierten Märkten seien dann möglich, wenn die etablierten großen Unternehmen bereits IT-Architekturen aufgebaut haben, die an neue Entwicklungen nur mit großem Aufwand anpassbar sind. Hier ist der Vorteil von StartUps, dass sie auf einer grünen Wiese beginnen können und über weniger komplexe Organisationsstrukturen verfügen, die es ja bei großen Unternehmen abzubilden gilt [Car04, S.127-129].

4. Die eigenen Schwächen fokussieren, nicht Chancen. Dieser Punkt geht davon aus, dass IT zunehmend Massenware wird. Wenn eine Ressource wie die IT zur Massenware geworden ist, obliegt sie nicht mehr der Kontrolle des Unternehmens. Die Vermeidung von Risiken, die durch diese Ressource entstehen können, werden dann wichtiger für das Unternehmen als das Gewinnen von strategischen Vorteilen durch diese Ressource [Car04, S. 108]. Carr vergleicht daher die IT mit dem Stromnetz. So sei die Vermeidung von Stromausfällen wichtig, das Erreichen von strategischen Vorteilen durch Stromnutzung wird aber kaum angestrebt werden. Risiken sieht Carr z.B. in der IT-Sicherheit. Nach Schätzungen wird jedes Jahr in 9 von 10 Unternehmensnetzwerken eingedrungen. Die Schäden, die hierbei z.B. durch Wirtschaftsspionage oder Viren u.ä. entstehen können, sind nur schwer zu beziffern.

In diesem Zusammenhang würden auch die Fähigkeiten des IT-Stabs zunehmend wichtiger werden. Gleichzeitig würden die Stäbe für IT aber schrumpfen, da immer mehr Produkte und Entwicklungen von Händlern übernommen werden. Die Fähigkeiten müssten sich aber beim IT-Stab verbessern, da er besser mit den Software-Verkäufern verhandeln muss [Car04, S. 133].

2.6 Bewertung von Carrs Ideen

In den Jahren 2001 bis 2003 kürzten die Unternehmen ihre IT-Budgets wegen der schlechten Konjunktur ²⁸ . Da Unternehmen meist ihre Investitionen von der wirtschaftlichen Lage abhängig machen, lässt sich nur schwer sagen, ob Carr bisher mit seiner Prognose Recht behielt. Zumal Carrs Prognose als Langzeitprognose verstanden werden sollte und nur wenige Jahre seit dem Erscheinen seines Artikels vergangen sind ²⁹ . Seit 2004 mehren sich zumindest die Anzeichen, dass wieder in IT mehr investiert wird oder die IT-Investitionen zumindest nicht mehr rückläufig sind ³⁰ . Nichtsdestotrotz bewähren sich die grundsätzlichen Ratschläge Carrs auch an empirisch erhobenen Daten:

²⁸ Investitionen werden generell bei schlechter Konjunktur eher zurückgefahren [Cez05, S. 299 ff.], solche rein konjunkturell bedingten IT-Kürzungen müssen nicht unbedingt sinnvoll sein.

²⁹ Es wäre möglich Perezs Modell im Sinne Carrs zugrunde zu legen (Vgl. Punkt 2.2.

³⁰ Vgl. dazu z.B. [DSSW04], [Nas04], [Nas05] und [Nas06a].

28

„Thirty-six percent of weak performers will shift dollars to consultants while just 6 percent of top performers will do the same. Poor performers are also playing catch-up in application spending; 47 percent will shift dollars into apps, compared with 36 percent for the top quartile„ [Eri02].

So gaben die erfolgreichsten Unternehmen z.B. deutlich weniger für Software (36% vom IT-Budget) aus als die schlechtesten Unternehmen (47% vom IT-Budget) und gaben auch nur in 6% der Fälle Geld für Berater aus, während die schlechten Unternehmen 36% für Berater ausgaben. Ob die besseren Unternehmen tatsächlich weniger in Eigenentwicklungen investieren ist unklar, zumindest geben sie auch weniger für die IT als der Durchschnitt aus [Eri02]. Weniger erfolgreiche Unternehmen

„investieren in IT eher aus Sorge vor negativen Konsequenzen in der Zukunft und Angst vor Wettbewerbsnachteilen als aufgrund klaren Wissens über den tatsächlichen Nutzen. Dies könnte erklären, warum in der Praxis oft zu früh (und zu teuer) oder zu umfangreich in IT investiert wird, wenn Warten zunächst die bessere Alternative gewesen wäre (vgl. Loveman 1994)“ [Pil98, S. 5] ³¹ .

Auch hier bewährt sich die zweite Regel von Carr, dass man lieber der Entwicklung folgen sollte anstatt Innovator zu sein. Allgemeingültige Sätze darüber, ob ein Unternehmen sein Budget für die IT erhöhen oder senken sollte, lassen sich natürlich nicht formulieren. Diese Entscheidung sollte immer abhängig vom Unternehmen und nie abhängig von irgendwelchen Verallgemeinerungen getroffen werden. Existieren in den verschiedenen Divisionen z.B. unterschiedliche ERP-Systeme, so ist eine Senkung der IT-Kosten durch die Einführung eines einzigen ERP-Systems sinnvoll. Vorausgesetzt, dass die Systeme ohne zu großen Datenverlust oder Aufwand überhaupt zusammengeführt werden können. Ist dies nicht der Fall, kann ein solches IT-Projekt schnell zum Millionengrab werden. Einen besseren Richtwert für das IT-Budget als Carr liefern Breshnahan, Brynjolfsson und Hitt:

„As information technology grows cheaper and more powerful, it induces more and more complementary investment in the rest of the cluster [Qualifizierte Arbeitskräfte und neue Organisationsformen] of changes-most im-portantly, for our present purposes, in skilled labor.“ [BHB02, S. 371]

Das IT-Management sollte also bei sinkenden Hardware- und Softwarepreisen in der Lage sein, die Kosten zu senken, gleichzeitig sollten aber nicht alle freigewordenen Res-

³¹ Zuähnlichen Ergebnissen kam Witte schon bei seinen Untersuchungen zu den ersten Management-Informations-Systemen Ende der 60er Jahre. Er schreibt: „Bis zum Jahre 1967 spielte nicht mal der Begriff des MIS in den Dokumenten der untersuchten 345 Unternehmungen und Behörden eine nennenswerte Rolle. Der Computer war auch nie mit der deklarierten Absicht beschafft worden, damit eine „Informations-Maschine“ für den entscheidungsbezogenen Dialog zu besitzen. Vielmehr wurde die notwendige Klarheit über die Anwendungsgebiete der Anlage regelmäßig erst nach ihrer Bestellung erarbeitet. Und auch dann dachte man in erster Linie an die Bewältigung von Massenarbeiten im Verwaltungs-und Fertigungsablauf“ [Wit72, S. 2].

29

sourcen dem IT-Management entzogen werden, da es freigewordene Mittel in eine bessere Ausbildung des Personals investieren sollte. Die Schulung des Personals ist ein wichtiger Faktor für eine höhere IT-Produktivität (Vgl. Punkt 2.6.2 und 3.5).

2.6.1 Entwicklung der IT

Dass ein Trend zur Massenware in der IT besteht, wird auch von Kritikern Carrs bestätigt. Allerdings ist das Bild etwas differenzierter. Petri und Stannat machen bei ihrer Befragung von 20 CIOs dt. Unternehmen mit 3000 bis 30 000 Mitarbeitern drei Trends in den Unternehmungen aus [PS03, S. 232]:

1. IT Nachzügler: Sie verfügen über hohe IT-Budgets und viele Mitarbeiter, die teils bis zu 50% nur die IT-Infrastruktur betreuen. Dazu kommen Investitionen in Infrastruktur- und ERP-Projekte. Zwar lagern diese Unternehmen nur wenig IT aus, die Autoren führen dies aber auch darauf zurück, dass diese Unternehmen erst „hohe Investitionen in die Entwicklung einer „State-of-the-art-Infrastruktur und Anwendungslandschaft“ [tätigen müssen], bevor sie z.B. an eine stärkere Auslagerung ihrer IT-Aktivitäten denken können“ [PS03, S. 231].

2. IT als Massenware: Diese Unternehmen zeichnen sich durch schrumpfende IT-Abteilungen und Budgets aus. Besonders im Infrasturkturbereich beziehen sie viele Leistungen von extern und nutzen verstärkt Standard-Software und streben keine Technologieführerschaft an. Neue Technologien setzen sie vor allem dann ein, wenn sie mit den Unternehmens-Standards kompatibel ist.

3. IT als strategische Ressource: diese Unternehmen lagern IT nur in den Bereichen aus, die strategisch nicht relevant sind. Gleiches gilt für Standard-Software. Es wird viel in Neuentwicklungen investiert, die besonders kundenorientiert sind.

Da Carr die Grenzen in „Does IT Matter?“ noch einmal verwischte, ist genügend Interpretationsspielraum gegeben, um zu sagen, dass sich diese Trends mit Carrs Ideen decken oder das sie dies eben nicht tun. Seine Empfehlungen an das IT-Management könnte man in Petris und Stannats Untersuchung schon teils verwirklicht sehen oder sie nur auf die schleppende Konjunktur in diesen Jahren zurückführen ³² .

³² Nimmt man das Jahr 2000 als Ausgangspunkt, so stieg inflationsbereinigt das deutsche Bruttoinlandsprodukt von 2000 bis 2003 nur um 1,05%. Allein 2004 wuchs es allerdings um 1,2% und 2005 um 0,9% [Deu06]. Addiert man dann noch aufgeschobene Ersatzinvestitionen in den jeweiligen Unternehmen hinzu, kann man trotz des insgesamt recht geringen Wachstums genauso leicht sagen, dass die IT-Einsparungen in Deutschland im Jahr 2003 (in diesem Jahr fand die Umfrage Petris statt) auf die Konjunktur zurückzuführen sind. Demnach müsste es im Zeitraum von 2004-2006 zu einer Aufhellung gekommen sein. Allerdings sollte man auch hier darauf achten, keinen mono-kausalen Zusammenhang zu unterstellen.

30

2.6.2 Wechsel von nachhaltigen zu temporären Wettbewerbsvorteilen

Carrs Schlussfolgerung besagt nicht mehr als dass sich Unternehmen nicht mehr rein durch den Einsatz von IT von Konkurrenten abheben können. Dieser Faktor wird aber m.E. überschätzt. Denn Unternehmen wie Coca Cola, ob mit einzigartiger IT-Landschaft oder ohne, wie in der Vergangenheit, beziehen ihre Einzigartigkeit nicht durch die IT sondern durch einzigartige Produkte, gutes Management und hervorragendes Marketing ³³ . Dennoch muss man sagen, dass Carrs Überlegungen zu Wettbewerbsvorteilen sehr trennscharf formuliert sind, wenn man sie nur auf von außen bezogene IT bezieht. Demnach können nach Carr nur Eigenentwicklungen Wettbewerbsvorteile bringen. Dass heißt dann aber auch, dass die Entwicklungen solcher Unternehmungen eben nicht unbedingt anderen Unternehmen zur Verfügung gestellt werden, durch User-Groups wie SHARE oder dadurch, dass die Erstellung von Software zu den Händlern übergeht. Es ist schwer vorstellbar, dass Ebay eine Auktions-Software oder amazon eine Buchshop-Software vertreibt. Traditionelle Buchhändler oder Auktionshäuser haben hier keine Wahl, sie können höchstens die Plattform nutzen. Wie Mata et al allerdings gezeigt haben, lassen sich auch mit Eigenentwicklungen kaum nachhaltige Wettbewerbsvorteile erzielen. Die Wettbewerbsvorteile von amazon sind z.B. historisch und deshalb nachhaltig. Historisch, da niemand ohne sehr großen Aufwand die Rezensionen von amazon imitieren kann. Genauso ist es nicht ohne weiteres möglich, den Kunden bessere Empfehlungen als amazon zu machen, da das amazon-System einen zeitlichen Vorsprung bei der Analyse der Kunden hat (die Einkäufe, die geschriebenen Rezensionen oder die besuchten Artikel, die in die Empfehlungen für den Kunden miteinfließen, lassen sich nicht ohne weiteres imitieren).

Nachhaltige Wettbewerbsvorteile sind also nur äußerst unwahrscheinlich mit IT zu erreichen, temporäre Wettbewerbsvorteile sind aber durchaus möglich. Als einzige nachhaltige Quelle für Wettbewerbsvorteile durch IT sehen Mata et al das IT-Management selbst an. Zu ähnlichen Ergebnissen kommen auch Bodendorf et al [BRBB04, S. 15]:

³³ Buffet (Sein Unternehmen ist größter Aktionär von Coca Cola) schrieb 1996 in einem seiner Investorenbriefe:

„Ich studierte vor kurzem den 1896er-Geschäftsbericht von Coke (und sie denken, Sie seien mit Ihrer Lektüre im Rückstand!). Zu jener Zeit war Coke, obwohl es bereits das führende alkoholfreie Getränk war, erst seit einem Jahrzehnt auf dem Markt. Aber seine Pläne für die nächsten 100 Jahre waren schon entworfen. Asa Candler, der Vorsitzende des Unternehmens, berichtet über Umsätze von 148.000 Dollar und sagte: „Wir haben nicht nachgelassen in unseren Anstrengungen, der ganzen Welt zu erklären, daß Coca-Cola das Getränk par excellence für die Gesundheit und gute Laune aller Menschen ist.“ Obwohl „Gesundheit“ ein wenig weit hergeholt sein mag, liebe ich die Tatsache, daß sich Coke noch heute auf Candlers Grundaussage verläßt - ein Jahrhundert später. Candler sagt dann weiter, genauso wie Roberto es heute könnte: „Kein Artikel mit ähnlichen Eigenschaften hat sich jemals so fest in der öffentlichen Gunst verwurzelt.“ Die Sirupumsätze in jenem Jahr betrugen nebenbei bemerkt 116.492 Gallonen im Vergleich zu 3,2 Milliarden Gallonen 1996.“ [BC03, S. 120].

Natürlich ist auch Coca Cola nicht vor sehr geschäftsschädigenden Strategieentscheidungen und Missmanagement gefeit, wenn es z.B. darum geht die Strategie auf neue Märkte anzuwenden. Ein gutes Beispiel ist hier die sehr unglückliche Expansion von Coca Cola in Indien. Vgl. dazu [Oer02].

31

Tabelle 2.1: Kosten für verschwendete Arbeitszeit. Quelle: [pc06, S. 10]

„Isoliert eingesetzt stell[t IT] für Unternehmen kein langfristiges Erfolgspotenzial dar, sondern ermöglich[t] lediglich kurzfristige Kosten und Differenzierungsvorteile, die leicht imitierbar sind und langfristig zu einem Preisverfall angebotener Leistungen führen“. Bodendorf et al sind allerdings der Auffassung, dass IT trotz allem zum Aufbau von Wettbewerbsvorteilen geeignet ist, wenn die „IT als kontinuierlicher Prozess insitutionalisiert [wird], um eine Erosion von Innovationspotenzial und - fähigkeit zu verhindern“ [BRBB04, S. 16]. Auch wenn Bodendorf et al Innovationspotential und -fähigkeit von IT bejahen und in den Mittelpunkt ihrer Analyse stellen, so kommen sie dennoch zu dem gleichen Schluss wie Mata et al, nämlich dass das IT-Management die wichtigste Quelle für nachhaltige Wettbewerbsvorteile durch IT ist.

Mit diesen Erkenntnissen decken sich auch die Ergebnisse der oben genannten empirischen Studien, die sich mit der IT-Produktivität auseinandersetzten. Denn nur ein gutes IT-Management stellt gutes IT-Personal sicher, dass z.B. von Prasad und Harker als wichtig für produktive und profitable IT-Investitionen angesehen wird [PH97, S. 29]. Ebenso unterstützen viele der Erklärungsversuche des IT-Produktivitätsparadoxons (Vgl. Punkt 2.3.2) diese Meinung.

Angesichts dieser Tatsachen verwundert es, dass sich z.B. keine Studien über die Produkitivtät oder das Zeitmanagement von IT-Managern im Vergleich zu anderen Managern finden lassen. Allgemein lässt sich aber sagen, dass im internationalen Vergleich die Produktivitätsverschwendung in Deutschland besonders hoch ist. Tabelle 2.1 zeigt die Kosten, die der dt. Volkswirtschaft durch verschwendete Arbeitszeit entstehen. Auch Peter Drucker machte schon vor 40 Jahren darauf aufmerksam, dass viele Manager ihre Zeit falsch einteilen, dass sie die Zeit, die sie meinen auf wichtige Aufgaben zu verwenden, meist überschätzen und die Zeit, die letztlich nichts zum Erfolg ihres Bereiches/Unternehmens beiträgt, unterschätzen ³⁴ . Druckers Erfahrung im Umgang mit Managern bewährte sich auch in der „Produktivitätsstudie 2005/06“ von proudfoot con-

³⁴ PeterDrucker schreibt in „The Effective Executive“:

„I sometimes ask executives who pride themselves on their memory to put down their guess as to how they spend their own time. Then I lock these guesses away for a few weeks or months. In the meantime, the executives run an actual time record on themselves. There is never much resemblance between the way these men thought they used their time and their actual records“ [Dru85, S. 27].

32

sulting [pc06, S. 10]. Zeitmanagement ist auch gerade in Bezug auf effizientes Mitarbeitermanagement wichtig. Es ist z.B. besser weniger Gespräche/Meetings zu führen, diese dann aber richtig zu führen: „But if executives in an organization spend more than a fairly small part of their time in meeting, it is a sure sign of malorganization“ [Dru85, S. 44].

2.6.3 Schlussbemerkung

Dieses Kapitel darf aber nicht so missverstanden werden, dass IT etwa unwichtig wäre. IT ist durchaus ein wichtiger Bestandteil für das Unternehmen. In Kapitel 3 wird auch noch deutlich werden wie wichtig die Ausrichtung der IT auf die Unternehmensstrategie ist. Zumindest im Moment muss man Abstand nehmen von Carrs vierter Richtlinie für das Management, denn es gibt Fälle, in denen eine Erhöhung der Mitarbeiteranzahl der IT-Abteilung mit einer Senkung der IT-Kosten einhergeht ³⁵ . Diese Vorgehensweise scheint mir am sinnvollsten, da ohne guten Personaleinsatz keine hohe IT-Produktivität gewährleistet werden kann. Da außerdem IT als Massenware immer leistungsfähiger und günstiger wird, sehe ich nicht, warum nicht die Ausgaben für Software und Hardware am Budget möglichst reduziert werden sollten. Diese Umsetzung ist nur durch eine gut ausgebildete IT-Belegschaft möglich, die gleichzeitig sichert, dass die vorhandene IT effektiv eingesetzt wird, in dem sie z.B. mehr Personal für die Unterstützung und Schulung der Mitarbeiter aufbringt. Gerade in diesem Zusammenhang ist m.E. auch das Wissensmanagement von großer Bedeutung, da in ihm viele Methoden zum Einsatz kommen, die ebenfalls die Produktivität von IT steigern können (Vgl. auch Punkt 3.5). Es wäre daher zu überlegen, ob die empirischen Daten nicht nahe legen, dass der CIO auch Aufgaben des Wissensmanagements wahrnehmen sollte. Zumindest sollte er eng mit den Wissensmanagement-Verantwortlichen zusammenarbeiten, denn es gilt: „Wird im Unternehmen Zusammenarbeit nicht gefördert und gibt es keine Anreize zur Aktualisierung und vollständigen Abspeicherung von Informationen, so wird der Nutzungserfolg ausbleiben“ [Nor02, S. 299]. Hier kommen auch die neuen Organisationsformen zum Tragen, die North in seinem Buch beschreibt. Solche Organisationsformen sieht auch Brynjolfsson als wichtig für eine hohe IT-Produktivität an. Diese Thematik wird ebenfalls noch in Punkt 3.5 gestreift.

³⁵ Ein Beispiel ist z.B. der CIO Klaus Hardy Mühleck bei VW, vgl. Kapitel 8.2

33

3 Der CIO

3.1 Das CIO-Konzept

Das CIO-Konzept wurde erstmals 1981 von Synnott und Gruber ¹ in ihrem Buch „Information Resource Management“ vorgestellt [SG81, S. 66 ff.] ² . Synnott definiert den CIO wie folgt:

„a CIO is the highest ranking executive with primary responsibility for in-formation management. The CIO is responsible for the planning and architecture of the firm’s information resources, for promoting information technology throughout the firm, and for looking after the corporation’s investment in technology.“ [Syn87, S.19].

Der CIO kontrolliert aber nicht die Informationen eines Unternehmens wie oft aus dem Namen falsch geschlossen wird. Er sei stattdessen der Architekt für die Systeme, durch die die Informationen fließen. Synnott legt viel Wert darauf, dass der CIO nicht als reiner Techniker verstanden wird. Synnott unterscheidet daher zwischen dem „Data Processing Manager“, der in erster Linie der Techniker ist, und dem „emerging CIO“. CIOs seien „business men first, managers second, and technologists third-in that order“ [Syn87, S. 23], d.h. dass sie sich an erster Stelle mit Fragen befassen, die in den Bereich der strategischen Planung fallen. An zweiter Stelle seien CIOs Manager, die sich mit finanzieller Planung, Projektmanagement, dem Managen des Personals oder mit Entscheidungsanalysen auseinandersetzen. Erst an dritter Stelle seien CIOs Techniker, die sich mit Data Center Management, der Telekommunikationsplanung, dem Management der Daten oder dem Endanwendersupport beschäftigen [Syn87, S.25]. So habe der Data Processing Manager 80% seiner Zeit mit Technik verbracht und nur 20% seiner Zeit für das Management aufgewendet. Dieses Verhältnis soll sich beim CIO lt. Synnott umdrehen. Bereits 1992 interagierten CIOs zu 58% mit Mitarbeitern außerhalb der IT und zu 42% der Zeit mit Mitarbeitern aus der IT Abteilung. MIS-Manager hingegen verbrachten noch 1981 mit 61% deutlich mehr Zeit innerhalb der IT-Abteilung

¹ Krcmar nennt Hortons 1979 erschienenes „Information Resources Management: Concept and Cases“ als erste Quelle für den CIO. Dieses Buch war bis zum Abgabetermin dieser Arbeit nicht beschaffbar. Es lässt sich allerdings sagen, dass der CIO, der Anfang der 80er Jahre aufkam, als Manager des Information Resources Management betrachtet wurde. Das Information Resources Management selbst wurde in Aufsätzen schon Anfang der 70er Jahre behandelt.

² 1981 wurde der CIO von Gruber und Synnott wie folgt definiert: „Senior executive responsible for establishing corporate information policy, standards, and management control over all corporate information resources“ [SG81, S. 66]

34

[SLMF92, S. 460] als außerhalb ³ .

Legt man das CIO-Konzept von Synnott und Gruber zugrunde, so stellt man in der Literatur häufig fest, dass (1) der technische Teil des CIOs bis heute oft eine große Rolle spielt ⁴ und (2) Probleme mit der IT häufig aus einem nicht korrekt umgesetzten CIO entstehen oder durch ihn verstärkt werden.

Studien, die sich so interpretieren lassen, finden sich viele. So zeigt z.B. eine Studie von McKinsey, bei der 2002 die CIOs und CEOs 70 führender französicher Unternehmen befragt wurden, dass sich viele der CIOs und CEOs eine größere Beteiligung der Geschäftseinheiten bei IT-Projekten wünschen, diese Erwartung aber nur selten erfüllt wird [MM04]. Dabei wäre es nach Synnots CIO-Definition gerade die Aufgabe des CI-Os hier selbst aktiv zu werden und die Akzeptanz der IT bei anderen Managern voranzutreiben. So verwundert es nicht, dass immer wieder Management-Aspekte als erfolgskritische Aspekte des CIOs genannt werden. Interessanterweise unterscheiden sich diese Ratschläge aber von denen, die auf Basis einer Produktivitätsanalyse von IT in Unternehmen gewonnen wurden. In diesen wird meist ein intelligenter Einsatz der Mitarbeiter gefordert. Dies ist zwar auch eine Managementaufgabe, die aber in den Untersuchungen, die in diesem Kapitel besprochen werden, völlig in den Hintergrund tritt. Die Untersuchungen dieses Kapitels stellen ganz eindeutig den CIO und seine Position in den Vordergrund und vergessen in diesem Zusammenhang, dass der CIO Manager einer IT-Abteilung ist, die aus Menschen besteht. In eher praxisorientierten Büchern wie etwa „THE NEW CIO LEADER“ [KB04] oder „Management für IT-Leiter“[AH02] wird die Bedeutung des Mitarbeiters sehr viel stärker betont. Es muss aber auch deutlich gesagt werden, dass es zu kurz gegriffen ist, immer die Schuld auf den CIO abzuwälzen wie die Arbeiten teilweise zeigen, die in Punkt 3.3 besprochen werden. Unter einem unfähigen CEO oder Eigentümer kann jeder Manager Schwierigkeiten haben sich zu entfalten.

3.2 Die Weiterentwicklung des CIOs

Nach Mahoney [Mah04] sind die folgenden Faktoren die treibenden Kräfte für eine Weiterentwicklung des CIOs:

• Hoher Druck die Kosten zu reduzieren

• Externe Service Provider gewinnen weiter an Bedeutung

• Trend der IT hin zur Massenware

• Die Unternehmensumwelt wird immer komplexer

³ Für beide Zahlen wurden jeweils fünf CIOs, bzw. MIS-Manager über fünf Arbeitstage hinweg beobachtet. Die Zahlen wurden also sehr genau erfasst, setzen sich aber nur aus kleinen und nicht unbedingt repräsentativen Stichproben zusammen.

⁴ Davon zeugen allein schon Artikel mit Namen wie „Vom Technikfreak zum Dienstleister und Problemlöser“ [vLB04], die bis heute erscheinen. Oder Schlagworte wie Business Alignment (Ausrichten der IT an den Bedürfnissen der einzelnen Geschäftseinheiten)

35

• Geschäftsprozessoptimierung wird immer wichtiger

Als Folge dieser sich auch untereinander beeinflussenden Kräfte müsse sich der CIO an die neuen Bedingungen anpassen. Einige CIOs würden verstärkt die IT auslagern, manche sich auf diese Weise sogar selbst wegrationalisieren. Die Analysten rechneten von dem Jahre 2004 aus, dass mit einer Wahrscheinlichkeit von 0,7 bis 2009 ein Drittel aller jetzigen CIOs verschwinden würden oder dass sich ihr Aufgabenfeld radikal verändern würde ⁵ . Abbildung 3.1 zeigt die Entwicklung des CIOs von 1996 bis 2004 wie sie die Gartner-Analysten sehen. In dieser Entwicklung werden vier verschiedene Arten von CIOs unterschieden. Der Erste dieser vier CIOs ist dabei als Functional Head und Operations Manager ein tendenziell mehr auf die IT-Architektur fokussierter CIO. Der letzte CIO-Typ hingegen ist Stratege, der ganz nach Synnott verfährt: „Technology must be applied to gain competitive advantage, not just to run internal operations“ [Syn87, S. 37]. Jeder CIO-Typ, der dem ersten folgt, schließt die Aufgabengebiete der ihm vorangehenden CIO-Typen mit ein. Aus der einfachen Tatsache heraus, dass Zeit nicht dehnbar ist, muss also der CIO der letzten Stufe mehr Aufgaben delegieren. Abbildung 3.2 zeigt sehr schön wie sich die Arbeitszeit der verschiedenen CIO-Typen dabei verteilt. Diese Entwicklung der Zeitaufteilung beim heutigen CIO ist durchaus vorstellbar, schließlich zeigt die Arbeit von Stephens [SLMF92, Vgl. Punkt 3.1], dass der CIO schon zu Beginn der 90er mehr Zeit mit Aufgaben verbracht haben muss, die außerhalb der IT-Abteilung liegen.

Die Gartner-Analysten empfehlen den CIOs, dass sie ihre eingesetzte Zeit und ihre Rollen mit der Gartner-Einteilung aus den Abbildungen 3.2 und 3.1 vergleichen, um sicherzustellen, dass sie ihre Organisation richtig ausrichten, die unterschiedlichen Punkte aus Abbildung 3.2 sollen dabei als Anhaltspunkt dienen.

3.3 Die Stellung des CIOs im Unternehmen

Die Diebold Research Group befragte 1984 130 Großunternehmen zum Chief Information Officer. Dabei stellte sich heraus, dass nur 5% der Unternehmen bereits 1979 einen CIO hatten, der an die Geschäftsführung berichtete. 1984 hatte schon ein gutes Drittel der Unternehmen einen CIO, der an die Geschäftsführung berichtete [Syn87, S. 21]. Dieser Trend hat sich bis heute stetig verstärkt wie die Recherchen von [DHLK06] zeigen. Die Ergebnisse sind Tabelle 3.1 zu entnehmen. Die Untersuchungen zeigen recht eindeutig, dass immer mehr CIOs nicht an den CFO, sondern an den CEO direkt berichten. Dass in der Vergangenheit mehr CIOs an den CFO als an den CEO berichteten liegt daran, dass im Finanzwesen meist zuerst IT intensiv eingesetzt wurde. Nach Broadbent und Kitzis berichten 40% der CIOs direkt an den CEO [KB04, S.15]. Aus diesen Ergebnissen lässt sich leider nicht schließen, ob der CIO wirklich an Bedeutung hinzugewonnen hat. Der Trend von Synnott, dass immer mehr CIOs direkt an den CEO berichten würden [Syn87,

⁵ Wie diese Zahlen zustande kommen, ist leider unklar. Man kann nur festhalten, dass sich durch die oben genannten Kräfte bis 2009 das Aufgabenfeld eines Drittels aller CIOs radikal verändern soll.

36

Abbildung 3.1: Die Entwicklung des CIOs von 1996 bis 2006 nach Gartner 2004 nach

S. 26], scheint sich aber durch diese Untersuchungen zu bestärken, auch wenn die Verhältnisse nicht so eindeutig sind wie sie sich Synnott vielleicht 1987 wünschte. Die von Harvey Nash in England durchgeführten Befragungen werfen ein etwas anderes Licht auf diese Problematik. So kommen diese Untersuchungen bis zum Jahre 2002 ebenfalls zu dem Ergebnis, dass mehr CIOs an den CEO direkt berichten würden. Tabelle 3.1 zeigt aber, dass die Zahl dieser CIOs in den darauffolgenden Jahren wieder abnahm. Aus unerklärlichen Gründen gibt Harvey Nash für das Jahr 2006 nicht alle Zahlen wie in den vorangegangenen Jahren an. Die Autoren der Studie schreiben: „There has been no significant change in reporting lines from last year’s survey“ [Nas06a]. Gleichzeitig schreiben sie aber, dass nur 36% aller CIOs an den CEO direkt berichten würden, was einen Einbruch von 9% zu 2005 und sogar von 22% zu 2002 bedeutet. Nach einer Studie von Burson-Marsteller sitzen nur in 5% der Fortune Global 500-Unternehmen ⁶ CIOs oder CTOs. Für diese Studie wurden die Biographien der Vorstandsmitglieder von 313 der 500 Unternehmen untersucht. Dabei legte man nur darauf Wert, dass das Vorstandsmitglied CIO-Erfahrung besitzt, nicht dass er die Funktion des CIOs im Vorstand inne hat. Lediglich 1% (Also 5 von 351 ⁷ untersuchten Unternehmen) der ehemaligen CIOs schafften es CEO zu werden. Interessant ist allerdings, dass die 15

⁶ Die Liste der Fortune Global 500-Unternehmen setzt sich aus den weltweit 500 größten Unternehmen nach Umsatz zusammen und wird jährlich vom amerikanischen Wirtschaftsmagazin Fortune aktualisiert.

⁷ Die Zahl weicht hier von den 313 vermutlich deshalb ab, weil es leichter ist, die Biographien der CEOs zu sichten.

37

Unternehmen (5% der 313 untersuchten), die ein Vorstandsmitglied mit CIO-Erfahrung besitzen, einen um 6,4% höheren Ertrag als der Branchendurchschnitt haben ⁸ . „Zu den Unternehmen mit CIOs oder ehemalige[n] CIOs im Führungsteam zählen u.a. die britische Tesco, Royal Philips Electronics, Canon, Mitsubishi, Sharp, Bouygues in Frankreich sowie die amerikanischen Firmen GAP, DuPont und Wal-Mart“ [BM04b]. Zu einem anderen Ergebnis kommt eine Umfrage bei CIO-Online, bei der 224 Stimmen abgegeben wurden. Demnach seien rund 36% der teilnehmenden CIOs inzwischen im Top-Management. 46% befänden sich im gehobenen Management und 18% im mittleren Management. Der hohe Anteil von CIOs im Top-Management hängt vermutlich damit zusammen, dass das „Top-Management“ einen größeren Personenkreis umfasst als der Begriff „Vorstand“ [Onl04d].

Tabelle 3.1: Berichtswege des CIOs. Quelle: [DHLK06], für die Umfrage von Harvey Nash [Nas05], [Nas06a]

3.3.1 Der CIO in den DAX-Unternehmen

Auch in den DAX 30-Unternehmen findet man keine Position, die dem CIO entspricht (Vgl. dazu Tabelle 3.2). Die Deutsche Börse ist das einzige Unternehmen im Index, das über einen Vorstand verfügt, der sich CIO nennt. Michael Kuhn zeichnet sich als CIO bei der Deutschen Börse verantwortlich für Technology/Systems (Central Support, Delivery, Application Development Trading and Consulting, Application Development Clearing

⁸ Der Branchendurchschnitt müsste sich ebenfalls aus den infrage kommenden Fortune Global 500-Unternehmen errechnen, um aussagekräftig zu sein. Da Fortune einen Branchendurchschnitt errechnet, ist anzunehmen, dass dieser schon aus Gründen der Einfachheit zugrunde gelegt wurde

39

and Settlement, Custody). Kuhns Aufgabengebiet beschränkt sich allerdings nicht auf das Managen der IT im klassischen Sinne, sondern er ist viel mehr Teil des operativen Geschäftes, in dem er auch die Architektur von Handels-, Clearing- und Abwicklungssystemen verantwortet, die die Deutsche Börse als einer der größten Insourcing-Anbieter ihren Kunden zur Verfügung stellt [Gro06]. Ansonsten verfügt die Deutsche Bank mit Josef Lamberti über einen Vorstand, der ehemals CIO in der Deutschen Bank war und als ehemaliger IBMer IT-Know-How in die Deutsche Bank miteinbringen konnte. Er organisierte auch die Auslagerung der gesamten Unternehmens-IT der Deutschen Bank an die IBM. Eines der größten IT-Outsourcing-Projekte der IBM Deutschland GmbH in den letzten Jahren [Lam04]. Die guten finanziellen Ergebnisse der Deutschen Bank in den letzten Jahren allerdings nur darauf zurückzuführen, dass ein CIO im Vorstand sitzt, wäre zu einfach ⁹ .

Diese Situation ist zum Teil auf die unterschiedliche Rechtslage in Deutschland und den USA zurückzuführen ¹⁰ . So heißt es in § 77 des Aktiengesetzes: „Besteht der Vorstand aus mehreren Personen, so sind sämtliche Vorstandsmitglieder nur gemeinschaftlich zur Geschäftsführung befugt“, dieses sogenannte Kollegialprinzip führt dazu, dass einer „Inflation von „chief labels““ [Hei01] entgegen gewirkt wird. Der deutsche Vorstand vergrößert sich meist nur, wenn ein Unternehmen expandieren will (Umsatzsteigerung, Diversifikation oder Internationalisierung), es fusioniert oder andere Unternehmen übernimmt. Auch die deutsche Mitbestimmung trägt tendenziell zu größeren Vorständen bei. Ansonsten wird in der Regel versucht, den Vorstand zu verkleinern, um eine schlagkräftigere Führung zu erreichen [BLP89].

Überhaupt gestaltet sich ein Vergleich mit den USA äußerst schwierig, da Detailfragen im Gesellschaftsrecht immer abhängig vom Sitz der jeweiligen US-Unternehmung sind. „Der Grund hierfür liegt darin, dass das Gesellschaftsrecht grundsätzlich in die Hoheit der einzelnen Bundesstaaten fällt und sich in Detailfragen nicht unerheblich von-einander unterscheidet. Zwischen den Bundesstaaten lässt sich sogar ein ausgeprägter Wettbewerb um das unternehmensfreundlichste Recht feststellen“[vW05, S. 136]. Dennoch stellt Bleicher et al eine Annäherung zwischen deutsche und amerikanischer Praxis fest. So führen deutsche Vorstandsvorsitzende trotz Kollegialprinzip häufig wie nach dem Direktionalprinzip ¹¹ das Unternehmen. Die „gesetzliche Konzeption des primus inter pares“ sei daher nach Bleicher und Paul „wenig realitätsnah“[vW05, S. 147]. In den USA hingegen versucht man durch kollegiale Arbeitsformen wie das Executive Commitee oder das Office-Konzept das Direktorialprinzip abzumildern. Als weitere Erklärung führt Heinzl an, dass der CIO in deutsche Vorständen z.B. mehr Verantwortung in den Bereichen Finanzen oder Controlling hätte [Hei01] ¹² . Aber ob es sich hierbei wirklich um CIOs mit mehr Verantwortung handelt oder eher um Vorstände, die zusätzlich noch das IT-Management verantworten, steht auf einem anderen Blatt. Es ist annehmbar, dass z.B. dem Finanzvorstand die IT aus meist historischen Gründen

⁹ Allein schon der hohen Erträge aus dem Investmentbanking wegen.

¹⁰ Mit dieser Thematik beschäftigen sich auch: [Hei01], [DHLK06] und [Krc05, S. 303 ff.]

¹¹ Das Direktionalprinzip ist in den USA üblich. Direktional wird geführt, wenn die oberste Instanz aus nur einer Person besteht, kollegial, wenn die oberste Instanz aus mehreren Personen besteht [BLP89, S.30].

¹² Eine Meinung die z.B. auch von [DHLK06] übernommen wurde

40

Tabelle 3.2: CIOs in den Vorständen der DAX-Unternehmen. Eigene Recherche, Y

zugeordnet wurde. Das heißt aber nicht, dass dieser ein CIO ist. Der CIO ist in diesen Fällen dann meist diesem Vorstand untergeordnet. Zu sagen, dass der CIO mehr Verantwortung in Deutschland hätte, führt daher nur zu einer Verwässerung des ohnehin unscharfen CIO-Begriffs. Damit würde auch der von Heinzl festgestellte Unterschied zwischen deutsche CIOs und US-CIOs entfallen. Einen weiteren Grund dafür, dass der CIO so selten im Vorstand anzutreffen ist, sieht Heinzel darin, dass „[d]ie Machtbasis eines CIO [...] auf der Assimilation und Komposition komplexer IKT [gründet], die außerhalb des Unternehmens erstellt und vielfältiger werden“ [Hei01]. Diese Machtbasis sei nicht mit der eines CFOs oder eines Linienchefs zu vergleichen. Außerdem würde IT, die zunehmend als Massenware betrachtet wird, häufig ausgeliedert, so dass sich der CIO letztlich „in leitender Position eines IT-Tochterunternehmens in der Rechtsform einer GmbH wieder[finde]“ [Hei01]

Nach Heinzl kommen bei allen deutsche Unternehmen, die einen CIO im Vorstand haben, folgende Punkte zusammen:

• die Branche des Unternehmens ist sehr IT-intensiv,

• durch IT-Innovationen lässt sich die Wettbewerbssituation verbessern,

• CIO hat Verantwortung über unternehmensübergreifende Geschäftsprozesse,

• hat fundiertes Technologie- und Branchenwissen und

• verfügt über ausgezeichnete Führungsqualitäten die ihn für andere Vorstandspositionen empfehlen.

3.3.2 Der Einfluss des CIOs auf andere Führungskräfte

Enns und Huff [EH00] untersuchten den Einfluss von CIOs in Organisationen. Unter Einfluss verstehen Enns und Huff die Fähigkeit einer Person andere Personen in ihren Entscheidungen zu beeinflussen. Frühere Untersuchungen hätten dabei gezeigt, dass der Einfluss des CIOs in der Vergangenheit nicht sehr groß war. Die Autoren führen dies einerseits darauf zurück, dass es CIOs erst seit ungefähr 15 Jahren in Unternehmen gibt und sie somit als Neulinge („new kids on the block“) Akzeptanzprobleme haben. Zum anderen konnten nicht viele CIOs durch ihre IT-Projekte überzeugen, was ihre Position zusätzliche schwäche ¹³ . Außerdem würden CIOs kaum zwischenmenschliche Beziehungen im Unternehmen pflegen. Die Autoren betonen allerdings, dass es auch wenige sehr

¹³ Vgl. hierzu auch Kapitel 1. Gescheiterte IT-Projekte sind in dieser Beziehung nicht zu unterschätzen, da sie auch die Glaubwürdigkeit des CIOs untergraben. Dabei müssen IT-Projekte nicht einmal scheitern, um die Glaubwürdigkeit zu untergraben wie Broadbent und Kitzis zeigen: „Even if you deliver projects on time and under budget, if they don’t help your executive colleagues meet their business goals, your credibility suffers“ [KB04, S. 20]. Das fast Paradoxe an dieser Situation ist dabei folgendes: „It is often not recognized in fact that information technology was one of the pioneering industries in the development of project management and has remained at the forefront of the discipline throughout the years since its development“ [Mor96, S. 321]. Gründe für das häufige Scheitern von IT-Projekten sieht Morris unter anderem in ihrer höheren Komplexität [Mor96, S. 335].

42

einflussreiche CIOs gäbe. Diese zeichnen sich besonders dadurch aus, dass sie ein her-vorragendes Wissen über das Tagesgeschäft und ihre Branche haben, dass sie gute Beziehungen zu anderen Führungskräften pflegen und ein deutlich breiteres Instrumentarium von Beeinflussungsmöglichkeiten verwenden.

In ihrer qualitativen Untersuchung führten Enns und Huff 14 Tiefeninterviews in sieben US-Unternehmen. Dabei wurden in jedem Unternehmen jeweils ein CIO und der, nach Meinung des CIOs, wichtigste interne Geschäftspartner interviewt, der nicht in der IT-Abteilung tätig ist. Dabei kam man zu den folgenden Ergebnissen: Die meisten CI-Os führen Einzelgespräche mit anderen Führungskräften bevor sie IT-Projekte vorschlagen. Sie versuchen meist über Gespräche die Sichtweise der anderen Führungskräfte zu verstehen. Alle CIOs gaben an, dass sie immer IT-Projekte in nicht-technischer Sprache erklären und die anderen Führungskräfte regelmäßig über den Status ihrer Projekte informieren. Interessanter hingegen sind die Antworten, in denen sich die CIOs unterschieden. Die CIOs, die in den Augen ihrer internen Geschäftspartner effektiv sind, unterscheiden sich von den weniger effektiven CIOs in den folgenden Punkten:

• Sie halten Absprachen mit anderen Führungskräften und versuchen diese argumentativ zu überzeugen,

• machen Pläne um die unterschiedlichen Menschen in einem Unternehmen gezielt anzusprechen,

• demonstrieren die Realisierbarkeit von Projekten anhand von Prototypen,

• verlassen sich weniger auf Hilfe von oben,

• bauen Beziehungen zu anderen Führungskräften auf und nutzen diese Netzwerke um Schlüsselpersonen und Führungskräfte in Projekte miteinzubinden,

• wissen wann sie jemand nicht mehr von einer Idee überzeugen können.

Enns und Huff betonen, dass diese Ergebnisse denen anderer Untersuchungen widersprechen, die zu dem Ergebnis kamen, dass CIOs den Kontakt mit Verantwortlichen scheuen und nicht ihre Strategien zur Beeinflussung wechseln. In einer weiteren, breiter (69 statt 7 Paaren) angelegten Studie untersuchten Enns und Huff mit Higgins nochmals den Einfluss des CIOs ¹⁴ . Und zwar auf die Fähigkeit von CIOs eigene SIS-Projekte (Strategic Information Systems) durchzuführen. Unter einem SIS-Projekt wird hier ein IT-Projekt verstanden, dass an der Geschäftsstrategie eines Unternehmens ausgerichtet ist. Die Ergebnisse dieser zweiten Studie befinden sich zwar weitestgehend im Einklang mit der schon zitierten, fördern allerdings einige weitere Erkenntnisse zu Tage. Demnach wenden erfolgreiche CIOs besonders persönliche Bitten (personal appeals) im Top-Management an und versuchen durch sachliche Argumente

¹⁴ Für die Studie wurden 459 CIOs angeschrieben, 144 sagten zu. Jeder CIO sollte ein SIS-Projekt vorschlagen und einen gleichrangigen Manager. Daraufhin wurden 288 Fragebögen versandt, von denen 75 vollständig zurückkamen und wiederum 69 brauchbar waren [EHH03, S. 170].

43

zu überzeugen. Interessant ist hier, dass persönliche Bitten normalerweise nur zu moderaten Erfolgen führen, im engen Führungskreis des Top-Managements aber eher Erfolg haben ¹⁵ . Hier ist allerdings auch das Vertrauen in den CIO von großer Wichtigkeit. Eine Führungskraft meinte: „a lot of people do not understand much about technology; it costs a lot of money, and they want someone they can trust“ [EHH03, S. 168]. Negative Auswirkungen auf den Einfluss hat z.B. die Strategie einen Gefallen anzubieten, damit einem selbst später ein Gefallen getan wird („Eine Hand wäscht die andere“). Das Gleiche gilt für das Versprechen von gemeinsamen Vorteilen durch ein neues SIS-System. CIOs die Druck gegenüber gleichrangigen Managern aufbauen, können ebenfalls kaum auf die Unterstützung anderer Manager hoffen. Dies gilt in etwas eingeschränkterem Maße auch für das Bilden von Allianzen. Im Unterschied zur ersten Untersuchung der Autoren fielen persönliche Absprachen nicht sonderlich ins Gewicht [EHH03, S. 166]. CIOs haben dann eine gute Erfolgschance, dass ihr SIS-Projekt bewilligt wird, wenn sie es auch wirklich mit der Unternehmensstrategie verbinden. Umgekehrt lehnen gleichrangige Führungskräfte umso eher Projekte von CIOs ab, wenn sie das Gefühl haben, dass das Projekt nur im Eigeninteresse des CIOs liegt [EHH03, S. 170]. Die Fähigkeit eines CIOs sich in die anderen Manager hineinzuversetzen, ist daher ein wichtiger Faktor für den Einfluss eines CIOs, da er auch nur dann sein SIS-Projekt richtig ausrichten kann. Diese Faktoren erkannten Gruber und Synnott schon sehr früh [SG81, S. 127 ff.]. Damit CIOs ihren Einfluss erhöhen, empfahl Synnott ihnen deshalb neben technischen Zeitschriften auch Wirtschaftszeitschriften (Wall Street Journal, Harvard Business Review, Fortune, Business Week) zu lesen, um sich die Sprechweise und das Verhalten anderer Manager anzueignen [Syn87, S. 24]. Eine Umfrage ¹⁶ von Harvey Nash in den USA zeigte, dass CIOs in erster Linie branchenspezifische Publikationen lesen. Die meisten dieser Informationen beziehen sie aus dem Internet über Online-Reports und -Zeitungen sowie News-Services. Über die Hälfte aller Befragten las das „CIO Magazine“. Ebenfalls beliebt waren „Computerworld“ und „Infoworld“. Die Autoren der Studie schreiben aber weiter: „Traditional sources of business information like The Economist, The Wall Street Journal, Business Week and Forbes were cited by only a handful of respondents“ [Nas06b, S. 10]. In Großbritannien führte Harvey Nash eine ähnliche Untersuchung durch, hier wurden die folgenden Zeitungen als die wichtigsten für Entscheidungen empfunden: 1. Computerworld, 2. Financial Times, 3. MIS [Nas05].

3.3.3 Die Beziehung zwischen CIO und CEO

Wichtig für den Einfluss des CIO ist nicht nur sein Einfluss auf gleichrangige Führungskräfte, sondern auch seine Beziehung zum CEO. Watson untersuchte 1989 die Beziehung von IS-Managern ¹⁷ zu CEOs [Wat90]. Obwohl die befragten IS-Manager kaum dem Ideal-CIO Synnots und Grubers entsprechen dürften, zeigen sie die Wichtigkeit von einer guten CIO/CEO-Beziehung. IS-Manager, die im telefonischen Kontakt oder face to

¹⁵ Da allerdings nur eine Frage zum Messen persönlicher Bitten gewählt wurde, sollte lt. den Autoren dieses Ergebnis vorsichtig behandelt werden [EHH03, S. 166]

¹⁶ Es wird leider keine Angabe über die Anzahl der Befragten gemacht.

¹⁷ Es wurden 43 IS-Manager der 200 größten australischen Unternehmen befragt.

44

Tabelle 3.3: Qualitäten eines CIOs. Diese Liste wurde den einzelnen CEOs zur Bewertung ihrer CIOs vorgelegt. Eigene Darstellung nach [FES92, S. 443]

face mit ihrem CEO in Kontakt stehen (35% der Befragten), schätzen die Bedeutung der IS-Planung für das Unternehmen geringer ein als jene, die nur über Memos oder über ihre Vorgesetzten im Kontakt mit dem CEO stehen. Letztere tun sich oftmals sehr schwer mit der Planung von Informationssystemen. Über einen dieser IS-Manager schreibt Watson: „In fact, the last two occasions on which he raised IS matters directly with the CEO, outside of a formal meeting, had been in the street (when he serendipitously bumped into the CEO) and at his organization’s Christmas party“ [Wat90, S. 226]. Diese Manager sind in der Regel auch von strategischen Entscheidungen ausgeschlossen. Diese Ergebnisse dürften heute nicht mehr so drastisch auffallen, da der Anteil von CIOs die direkt an den CEO berichten, eher gewachsen ist (Vgl. Punkt 3.3). Feeny, Edwards und Simpson untersuchten diese Beziehung in 14 britischen Großunternehmen ¹⁸ durch ausführliche Tiefeninterviews [FES92]. Insgesamt waren fünf der 14 CEO/CIO Beziehungen sehr gut, während zwei CEO/CIO Beziehungen schlecht waren. Alle fünf CEOs, die gute Beziehungen zu ihrem CIO pflegten, kamen aus dem Management oder Marketing. Von den anderen neun CEOs kamen vier ebenfalls aus diesen Bereichen, während die restlichen aus der Produktion oder der Verfahrenstechnik (process engineering) kamen. Die Autoren nehmen aber Abstand von der These, dass nur CEOs mit Management- oder Marketing-Hintergrund gute Beziehungen zu CIOs aufbauen können. Eine Möglichkeit sei aber, dass CEOs, die aus der Verfahrenstechnik oder der Produktion kommen, mehr auf Effizienz und Automatisierung Wert legen, während CEOs mit Marketing- oder Management-Hintergrund eher an Chancen und Innovationen interessiert sind und ergebnisorientierter vorgehen [FES92, S. 439]. Des Weiteren stimmten die fünf CEOs den von Schein entwickelten vier IT-Visionen 19

¹⁸ ≥ 2 Milliarden US-Dollar Umsatz. 10 aus dem privaten, 4 aus dem öffentlichen Sektor [FES92, S. 436].

¹⁹ Es muss beachtet werden, dass diese IT-Visionen aus dem Jahre 1989 stammen:

1. IT ersetzt unzuverlässige und teure Arbeitskräfte oder steigert deren Produktivität. IT verspricht mehr Qualität, Effizienz und Kosteneinsparungen.

45

zu. Schein entwickelte diese Visionen 1989 in Interviews, die er mit CEOs führte. Von den restlichen neun CEOs stimmte nur ein CEO diesen IT-Visionen zu. Des Weiteren wurde den CEOs die Liste aus Tabelle 3.3 vorgelegt. Alle CIOs, die sehr gute Beziehungen mit ihren CEOs pflegten, wurden hier in den Punkten 4-9 sehr gut benotet. Während die restlichen neun CIOs hier in nicht allen Punkten gute Bewertungen bekamen, schnitten doch einige dieser CIOs in den Punkten 1-3 besser als zwei der fünf CIOs mit sehr guten Beziehungen ab. Zwei der fünf CIOs mit sehr guten Beziehungen wiesen Management-Schwächen auf, die aber toleriert wurden. Inwiefern diese 14 CIOs tatsächlich zur IT-Produktivität ihres Unternehmens beitrugen, kann nicht gesagt werden, da Feeny et al davon ausgingen, dass eine exzellente Beziehung zwischen CIO und CEO eine erfolgreiche Nutzung von IT ermöglicht. Ein weiteres Unterscheidungsmerkmal zwischen den beiden CIO-Gruppen ist die Zustimmung der einzelnen CIOs zu der Sicht der CEOs (teilen z.B. CIO und CEO die vier oben genannten IT-Visonen). Die CIOs mit sehr guten Beziehungen zu ihrem CEO stimmten in 76% der Fälle mit ihrem CEO überein und in weiteren 19% teilweise. Die restlichen CIOs stimmten hingegen nur in 28% der Fälle mit ihrem CEO überein und nur in weiteren 10% teilweise [FES92, S. 443]. Darüber hinaus zeichneten sich die erfolgreichen CIOs durch folgende drei Merkmale aus [FES92, S. 444]:

1. Beratender Führungsstil (Wert auf Kommunikation legen, Beziehungen aufbauen und gute Gruppenprozesse erreichen.

2. Unternehmergeist (Tatkraft, Zielorientierung und Engagement)

3. Kreativität (z.B. sich in andere Bereiche eindenken, externe Netzwerke aufbauen)

Durch einen beratenden Führungsstil zeichnete sich z.B. nur ein CIO der CIOs, die weniger gute Beziehungen zu ihrem CEO haben, aus.

3.4 Dezentralisierung vs. Zentralisierung der IT

Von dieser Fragestellung ist abhängig, ob es einen CIO mit zentraler Verantwortung für die IT gibt oder ob die einzelnen Unternehmensbereiche eigene CIOs, bzw. IS-Manager haben sollten. Da diese Frage in der Praxis oft mit Machtentscheidungen verbunden ist und hiervon abhängig sein kann, ob es überhaupt einen CIO oder CPO in einem Unternehmen gibt, ist eine nähere Betrachtung dieser Problematik sinnvoll. Die Frage, ob

2. Durch IT kann das Management einen besseren Überblick über das Unternehmen gewinnen und bessere Entscheidungen treffen.

3. Mitarbeiter können durch IT einen besseren Einblick in ihre eigenen Aktivitäten bekommen. Die üblichen Kontroll- und Hierarchiestrukturen werden durch IT ein Stück weit überflüssig und erlauben eine dezentralere Organisation

4. Das Unternehmen sowie seine Beziehungen zu Lieferanten und Kunden kann durch IT grundlegend verändert werden. IT bietet eine Chance für mehr Informationsaustausch und Problemlösungen auf lokaler Ebene.

46

IT dezentral organisiert sein sollte oder nicht, dürfte auch heute noch genauso aktuell sein wie vor 20 Jahren. Dearden argumentierte 1987 [Dea87], dass funktionale Manager häufig von der zentralen IT abhängig seien, dass sie aber besser selbst entscheiden könnten, welche IT-Leistungen sie benötigen. Berücksichtigt man die schon nicht seltenen Abstimmungsschwierigkeiten, die schon weiter oben genannt wurden und fügt man hierzu noch die angeblich einfacher werdende IT hinzu, mag dieses Argument plausibel klingen. Des Weiteren sei der Benutzer selbst am besten in der Lage computerisierte Informationssysteme mit nichtcomputerisierten Systemen abzustimmen, die Wichtigkeit von Anwendungen für sein Tagesgeschäft zu bestimmen und könnte am schnellsten auf Änderungen im Markt reagieren. Marchand und Horton zitieren eine Studie ²⁰ , in der 1983-1984 16 Fortune 500-Organisationen untersucht wurden. Auch hier stellte man fest, dass eine Dezentralisierung zu schnelleren Reaktionsgeschwindigkeiten der ehemals zentralen IT-Abteilung führte [MJ86, S. 151]. Die Forderung nach einer dezentralen IT erschien in den 80er Jahren also durchaus sinnvoll, auch wenn der folgende Satz damals sicher mehr als heute galt (bezogen auf die IT-Abteilung): „No area stimulates more intense emotional debate among both theorists and practitioners than does the centralization-decentralization question“ [MJ86, S. 147 f.]. Durch Dezentralisierun entstehende Probleme wie mangelnde Datenkonsistenz, inkompatible Hardware und Software, den Aufbau doppelter Systeme und die Vernetzung zwischen den einzelnen Mitarbeitern hielt Dearden für lösbar [Dea87, S. 89 ff.]. Viele der von Dearden genannten Argumente, sind ähnlich zu jenen, die auch sonst für die De- oder Zentralisierung ins Feld geführt werden [EEF96, S. 201]. Deswegen soll hier nur auf die IT-spezifischen eingegangen werden. Nach Dearden mache der stetige Fortschritt der IT-Entwicklung Dezentralisierung möglich. Heute hingegen geht der Trend klar zu einer zentralen IT, zumindest nach 1987 gab es aber auch einen Trend hin zur Dezentralisierung wie noch später gezeigt wird.

Von Bedeutung sind auch die Auswirkungen von einer Zentralisierung oder Dezentralisierung auf das mittlere Management. Kraemer und Pinsonneault stellten fest [PK93, S. 285 ff.], dass IT-Einsatz nicht generell zu einem Abbau des mittleren Managements führt, sondern genauso gut zu einem Anstieg mittlerer Führungskräfte führen kann. Übergibt man den einzelnen Bereichen die Kontrolle über die IT, so tendieren sie dazu, dass mittlere Management aufzustocken. Ist eine starke Zentralisierung gegeben, so ist mit einem IT-Einsatz auch oft ein Abbau des mittleren Managements gegeben. Das ist besonders deshalb interessant, da die IT teilweise dezentralisiert wird, um Kosten und Personal einzusparen [EEF96, S. 224]. Kraemer und Pinsonneault betonen aber, dass die IT selten gezielt zum Reduzieren des mittleren Managements eingesetzt wird und meist andere Gründe entscheiden [PK93]. Wie man Abbildung 3.3 entnehmen kann, ist ein starker Zuwachs oder eine starke Abnahme der mittleren Führungskräfte nur bei starker Dezentraliserung oder Zentralisierung gegeben. Ob sich in unserem Falle der Zuwachs von Führungskräften auch in einer größeren Belegschaft niederschlägt, geht leider nicht aus den zitierten Studien hervor.

²⁰ „Excellence in Information Management: A Survey of Selected Fortune 500 Activities“ von Gregory T. Haugan und Ginger Levin.

47

Abbildung 3.3: Einfluss der IT-Organisation auf das mittlere Management. Eigene Dar-

Earl, Edwards und Feeny beschreiben fünf Organisationsformen der IT: Corporate Service, Internal Bureau, Business Venture, Decentralised und Federal. Sie sollen nicht alle hier erklärt werden. Decentralised bezeichnet eine IT-Organisation in der ein zentrales IT-Management fehlt und jede Geschäftseinheit ihre eigene IT betreibt. Federal hingegen steht für ein zentrales IT-Management, das eine verpflichtende IT-Architektur und -Strategie festlegt, an die sich die einzelnen IT-Organisationen der Geschäftseinheiten zu halten haben [EEF96, S. 211]. Earl et al untersuchten 1987 14 Unternehmen, die den oben genannten Organisationsformen zugeordnet wurden. 1987 wurden acht der Unternehmen als Federal und eins als Decentralised eingestuft. Sechs Jahre später untersuchten sie wieder diese 14 Unternehmen. Nun ließen sich neun als Federal und vier als Decentralised einstufen. Obwohl die Untersuchung schon älter ist und nur auf einer kleinen Stichprobe beruht, zeigt sie recht deutlich, dass Probleme mit einer uneinheitlichen IT-Landschaft sicherlich mit den Folgen einer in dieser Zeit dezentral organisierten IT zusammenhängen könnten. Die Organisationsform Federal darf hier aber nicht mit einer zentralen IT verwechselt werden, die so bezeichneten Unternehmen übertrugen teils sehr viel Kompetenz an die einzelnen Geschäftseinheiten. Besonders für komplexe Organisationen empfehlen Earl et al die Federal-Organisationsform [EEF96, S. 228].

48

3.5 Erfolgsfaktoren für CIOs

Für eine Untersuchung des „United States General Accounting Office“ wurden die CIOs führender Unternehmen interviewt. Die Ergebnisse der Untersuchung beschreiben die Autoren wie folgt: „The practices are not new ideas in the general management of organizations, but rather are the application of well-founded principles in the maturing area of information technology and management“ [Off01, S. 9]. Dabei kristallisierten sich die folgenden sechs Erfolgsfaktoren für CIOs heraus:

1. Der Anteil der IT an der Wertschöpfung wird anerkannt. Zudem wurden Instrumente eingeführt, die den Einfluss der IT auf die Unternehmensstrategie deutlich machen und die IT-Organisation sowie die Prozesse der IT sind in die bereichsübergreifenden Geschäftsprozesse integriert.

2. Der CIO ist richtig aufgestellt. Das CIO-Konzept ist auf die Organisation des Unternehmens abgestimmt, d.h. dass Rolle, Kompetenzen und Verantwortung des CIOs klar definiert sein müssen. Zudem sollte der CIO über IT- und Management-Kenntnisse verfügen und Teil des operativen Managements sein.

3. Die Glaubwürdigkeit der CIO-Organisation muss sichergestellt sein. Der CIO ist im Top-Management akzeptiert und kann seinen Einfluss nutzen, um dem Top-Management in IT-Fragen zu helfen. Darüber hinaus hat der CIO bei IT-Projekten die Unterstützung des Managements der betroffenen Bereiche. Außerdem erreicht er schnell sichtbare Erfolge mit hohem Einfluss und verliert dabei nicht die langfristige Strategie aus dem Auge. Zudem tauscht er sich auch mit externen Informationsmanagement-Experten und CIOs aus und geht mit ihnen Partnerschaften ein.

4. Erfolge messen und Ergebnisse zeigen. Interne und externe Partner sowie Kunden werden vom Management bei der Definition von Kennzahlen miteinbezogen. Das Management aller Unternehmensebenen stellt sicher, dass die IT-Kennzahlen mit den Geschäftskennzahlen abgestimmt werden. Außerdem setzen sich die Manager dafür ein, dass die Kennzahlen ständig beobachtet und genutzt werden, damit ein aktives Feedback sichergestellt ist.

5. Informationsressourcen so organisieren, dass sie zum Geschäftserfolg beitragen. Dazu sollte die CIO-Organisation wissen, was sie zum Unternehmen beitragen kann und sollte effizient und zuverlässig arbeiten. Wie dezentral IT-Ressourcen verteilt sind, sollte davon abhängig sein, was für das Unternehmen nötig ist. Zudem sollte die CIO-Organisation flexibel genug sein, um auf Änderungen reagieren zu können. Die Unternehmens- und Personalstrategie des Unternehmens sollte bei Entscheidungen über die Auslagerung von IT beachtet werden.

6. Das IT-Humankapital entwickeln. Dafür sollte die CIO-Organisation die Fähigeiten identifizieren, die für ein effektives IT-Management notwendig sind. Es sollten auch innovative Wege entwickelt werden, um Talente anzuziehen und zu halten.

49

Außerdem sollten dem IT-Fachpersonal die Trainings, Werkzeuge und Methoden zur Verfügung gestellt werden, die es zum Wahrnehmen seiner Arbeit braucht.

Einige dieser Erfolgsfaktoren lassen sich durch gezieltes IT-Marketing ²¹ erreichen. Torsten Niemitz, CIO bei Nordzucker, organisiert daher z.B. alle vier Monate ein IT-Informations-Meeting mit der gesamten Belegschaft, besucht jedes Jahr ausländische Niederlassungen zweimal und inländische einmal und trifft sich dabei mit Schlüsselanwendern. Für die Mitarbeiter wurde ein IT-Helpdesk-Newsletter eingeführt. Außerdem veröffentlicht die IT nun Beiträge in der Mitarbeiterzeitung. Zudem hat er regelmäßige Besprechungen mit dem Vorstandschef, bezieht die Fachbereiche aktiv in die Budgetplanung mit ein und betreibt „aktives „Walking-around“, um den Business-Kollegen Gelegenheit zur Kontaktaufnahme zu geben“ [Qua06].

Auch die Verbindung des ersten, zweiten und sechsten Punktes ist sehr wichtig, da eine hohe IT-Produktivität oft einher geht mit modernen Organisationsformen, die eine effektivere IT-Nutzung erst ermöglichen [BHB02]. Der CIO sollte daher darauf achten, dass auch die organisatorischen Grundlagen geschaffen sind, die einen effizienteren IT-Einsatz ermöglichen [BM04a]. Nach Brynjolfsson bedienen sich Unternehmen mit effektiven IT-Einsatz neuer Organisationsformen, die die folgenden Merkmale besitzen: sie schaffen den Wandel zum papierlosen Büro, dezentralisieren stärker und etablieren eine Unternehmenspolitik, die für mehr Transparenz, Kommunikation und freien Zugriff auf Daten sorgt. Denn nur wenn die Mitarbeiter in die Lage versetzt werden, das Potential der IT auszuschöpfen, können sie dies auch tun. Außerdem stellte Brynjolfsson fest, dass Unternehmen mit hoher IT-Produktivität intensiver nach gutem Personal suchen und mehr Geld in die Ausbildung ihrer Mitarbeiter investieren [BM04a] ²² . Des Weiteren wird die in Punkt 3.4 behandelte Federal-Organisationsform in einer eher dezentralen Ausprägung empfohlen.

²¹ Nicht zu verwechseln mit dem IT-Marketing-Manager. Der IT-Marketing-Manager ist eher ein auf IT-Dienstleistungen und -Produkte spezialisierter Marketing-Manager. Siehe dazu „IT Marketing Manager“ unter: http://www.apo-it.de/download/referenzprojekte/Referenzprojekt_IT_Mark eting_Manager_Nov03.pdf

²² Vgl. hier auch Punkt 2.6.3, in dem auf die Bedeutung des Wissensmanagements für die IT-Produktivität hingewiesen wird.

50

4 CPO-Konzepte

4.1 Vom CIO zum CPO

Viele der Punkte, die schon in Kapitel 3 angesprochen wurden, spielen stellenweise wieder eine Rolle innerhalb der unterschiedlichen CPO-Konzepte. Wie ein roter Faden zieht sich eine stärkere Betonung der Betriebswirtschaft durch alle Konzepte, egal ob CIO oder CPO. Interessant sind in diesem Zusammenhang die Untersuchungen Heinzls. Er leitete 1995 ausführliche Gespräche mit 26 CIOs, IT-Beratern und IS-Managern von US-Unternhemen ¹ . Nach vier Gesprächsrunden kamen die Teilnehmer zu der Meinung, dass „Die Qualifikation und Erfahrung des CIO [...] überwiegend betriebswirtschaftlicher und nicht technischer Natur sein [soll]“ [Hei96, S. 173] ² . Das Neue an den CPO-Konzepten im Vergleich zum CIO-Konzept ist daher nicht die stärkere Betonung der Betriebswirtschaft, die ja schon bei Synnott und Gruber verankert war [SG81, S. 60]. Vielmehr ist es der systematische Einsatz von Geschäftsprozessmanagement. Eine schlüssige Erklärung für den Wandel vom CIO zum CPO findet man bei Earl. Er forderte zwar 1996 noch keinen CPO, machte aber deutlich, dass in einer Prozessorganisation ebenfalls der Bedarf für Informationssysteme steigt, die Bereichs- und Unternehmensgrenzen überschreiten und so die Kommunikation erleichtern. Für diese Aufgabe der Vernetzung sei besonders der CIO geeignet. Earl schreibt weiter:

„It also, evidently, needs to embody the view that information systems alone achieve very little. A more socio-technical perspective on change is required. And we see CIOs being asked to lead [business process reengineering] projects because they are perceived to understand and know their business’s processes and maybe can bring a proactive but relatively neutral drive to business change“ [Ear96, S. 478].

Interessant ist hier das Argument, dass der CIO unabhängig wäre. Ein zusätzlicher Treiber des Wandels vom CIO zum CPO dürfte die Angst der CIOs sein, ihre Position zu verlieren. Genauso wie die Angst, eine wichtige Entwicklung zu verpassen, manch mal zu unsinnigen IT-Investitionen führt (Vgl. Punkt 2.6 in Kapitel 2). Dass diese Angst nicht unberechtigt ist, zeigt z.B. die in Punkt 3.2 besprochene Gartner-Studie. Während Gartner 2004 damit rechnete, dass sich das Aufgabenfeld bei einem Drittel der CIOs bis

¹ Darunter auch Max Hopper, der SABRE mitentwickelte, Duwayne Peterson (ehemaliger CIO bei Meryll Lynch) oder Mark Stein (damals CIO der BankAmerica) [Hei96, S. 142]

² In der zweiten, dritten und vierten Gesprächsrunde waren je 67%, 73% und 71% der Meinung, dass der CIO ein „business executive“ sein sollte. Allerdings waren in Runde drei und vier auch 18% und letztlich 29% der Meinung, dass der CIO „a tech. savvy executive“ sein sollte [Hei96, S. 174].

51

2009 radikal verändert, gaben 2005 in einer Umfrage von Harvey Nash 60% der CIOs an, dass sich ihre Aufgabenrolle innerhalb der nächsten 24 Monate verändern würde (die CIOs wurden allerdings nicht nach radikalen Veränderungen gefragt). In einem Artikel von CIO Online findet man einen weiteren Indikator, für den Wechsel vom CIO zum CPO. In dem Artikel wird von der Personalberatung Convenio berichtet, die „jährlich über 200 Positionen in der ersten und zweiten Riege des IT-Managements neu besetzt“ [Onl05a]. Nach dem Convenio-Mitarbeiter Hecken stagnierte der Personalmarkt für IT-Führungskräfte von 2001 bis Anfang 2003. Seit Mitte 2003 komme aber „immer mehr Bewegung ins Spiel“ [Onl05a]. In der Branche mache das Schlagwort von der „Ersatzbeschaffung“ die Runde: „Bei der Ersatzbeschaffung geht es um besetzte Positionen“ erklärt Hecken. Dabei würden CIOs, die sich nicht dem Wandel stellen oder zuviel Macht an sich binden, ersetzt:

„Bei vielen IT-Chefs spürt Hecken eine „Unbeweglichkeit, was die Aufstellung der IT angeht“, ein Drittel sieht er gar als „absolute Blockierer“, die sich dem Wechsel hin zum Prozess-CIO vehement in den Weg stellten - und dies, obwohl der CIO des neuen Zuschnitts weit mehr an Kompetenz gewinnt.“

Studien darüber, ob dieses Phänomen der „Ersatzbeschaffung“ im Bereich des Personalmarktes für IT-Führungskräfte weit verbreitet ist, lagen leider bei der Erstellung der Arbeit nicht vor. Einen Ansatz stellen aber die Umfragen von Harvey Nash unter IT-Führungskräften in England dar. Vgl. dazu Tabelle 4.1. Wenn die Feststellung von Hecken zutrifft und der englische IT-Arbeitsmarkt ungefähr vergleichbar mit dem deutschen ist, müsste eine erhöhte Aktivität ab 2003/2004 feststellbar sein. Da in der Befragung von Harvey Nash IT-Führungskräfte danach befragt werden, ob sie sich für andere Stellen interessieren oder ob sie ihre Stelle behalten möchten, kann man zumindest aus diesen Ergebnissen schließen, ob eine höhere Bewegung auf dem Personalmarkt für IT-Führungskräfte zu verzeichnen ist. Über die Aussagekräftigkeit lässt sich streiten, es ist aber von Vorteil, dass über den Zeitraum, in dem die Erhebung stattfand, das Wirtschaftswachstum und die Arbeitslosigkeit recht konstant waren, sodass ausgeschlossen werden kann, dass die Konjunktur den Personalmarkt in größeren Maße beeinflusst hat. Von Bechtolsheim liefert eine andere Erklärung für die CPO-Debatte. Für ihn spiegelt die Rolle des CIOs in einem Unternehmen immer dessen IT-Situation wider. Er vermutet daher, dass die Diskussion um den CPO vor allem auf die stiefmütterliche Behandlung der IT in vielen Unternehmen zurückzuführen sei. Er spielt damit besonders auf die Unternehmen an, die IT nur als Kostenblock betrachten und deshalb wichtige Entwicklungen in der IT verpassten. Diese Unternehmen hätten nun den Bedarf nach einem CIO, der den Wandel aktiv vorantreibt. Der CIO, bzw. CPO sollte daher genau diese Lücke schließen und als Innovator und Aufklärer auftreten, um den Fachbereichen das Potential von IT aufzuzeigen [vB05, S. 101].

Einen anderen Erklärungsversuch für den Wechsel vom CIO zum CPO kann man bei Jost und Wagner finden [JW05]. Sie beschreiben die folgende Ausgangssituation: Unternehmen wollen einerseits mehr Qualität, Flexibilität und Schnelligkeit erreichen, verwenden aber andererseits 80-90% ihrer IT-Budgets nur für den Betrieb ihrer oftmals

52

Tabelle 4.1: Die Tabelle zeigt wie aktiv IT-Führungskräfte im Vereinigten Königreich

sehr heterogenen IT-Landschaften, in denen Geschäftsprozesse meist hart codiert sind. Demnach blieben den meisten CIOs nur 10-20% ihres Budgets, um Innovationen umzusetzen, während sie gleichzeitig sehr komplexe IT-Landschaften managen, die sich oft nur schwer anpassen lassen. Zur Auflösung dieses Dilemmas könnten daher zwei Trends im Geschäftsprozessmanagement beitragen:

1. Viele Unternehmen setzen auf eine stärkere Prozessorientierung und standardisieren ihre Prozesse

2. „Software- und ERP-Hersteller [sind] derzeit dabei ihre Architekturen und Platt-formen stärker prozessorientiert auszurichten“ [JW05, S. 18]

Diese beiden Trends würden daher dazu beitragen, dass Geschäftsprozessmanagement immer wichtiger wird und der Wandel zu einer prozess- und serviceorientierten Anwendungslandschaft möglich ist [JW05, S. 18 f.].

4.1.1 Der CPO als Enabler des SOA-Unternehmens

Von den meisten Autoren wird der CPO als eine Weiterentwicklung des CIOs angesehen, der die gesamte Unternehmens-IT mit Hilfe von Enterprise Application Integration oder serviceorientierten Architekturen (SOA) umgestaltet und ein Unternehmen somit erst reif für ein umfassenderes Geschäftsprozessmanagement macht. Nicht mehr das Unternehmen soll der IT angepasst werden, sondern die IT wird flexibel auf die Geschäftsprozesse ausgerichtet. In diese Richtung geht auch die Vision des Echtzeitunternehmens (Vgl. dazu auch Punkt 6.1). Inwiefern dieser Wandel dann in der Praxis erreicht werden soll, hängt vom Hintergrund der jeweiligen Autoren ab. So setzen Abolhassan und Jost (beide IDS Scheer) einen größeren Schwerpunkt auf Geschäftsprozessmodellierung mit Aris. Schmidt und Seidel als Berater und Betreuer von EAI-Projekten setzen Akzente im EAI-Bereich (Vgl. zu EAI Kapitel 5). Sesselmann und Schmelzer heben deutlich

53

das Geschäftsprozessmanagement hervor als Verantwortliche oder ehemals Verantwortliche für Prozessmanagement bei Siemens. Es ist also keineswegs zwingend, dass der CPO aus dem CIO hervorgehen muss, denn als solches ist das Geschäftsprozessmanagement ja nicht speziell ein IT-Thema. Interessanterweise sehen die IT-Verantwortlichen selbst 2006 das Geschäftsprozessmanagement „nur wenig als Vorbereitung auf die Einführung einer service-orientierten Architektur (SOA) und noch weniger als Vorbereitung auf SAP NetWeaver“ [Gil06]. Der Grund dafür liege vermutlich darin, dass der Zusammenhang zwischen serviceorientierten Architekturen und Geschäftsprozessmanagement noch nicht erkannt werde und dass sich die Befragten noch nicht intensiv mit dieser Thematik auseinandersetzten [Gil06].

Serviceorientierte Architekturen

Eine serviceorientierte Architektur ist keine vollkommen neue Architektur. Die service-orientierte Architektur ist eher eine Weiterentwicklung von bekannten Integrationskonzepten wie der Enterprise Application Integration (Vgl. für eine Definition Kapitel 5). Eine bekannte Definition für eine serviceorientierte Architektur liefern Ali Arsanjani, Bernhard Borges und Kerrie Holley:

„SOA is the architectural style that supports loosely coupled services to enable business flexibility in an interoperable, technology-agnostic manner. SOA consists of a composite set of business-aligned services that support a flexible and dynamically reconfigurable end-to-end business processes realization using interface-based service descriptions“ [ABH04].

Wichtig ist dabei, dass die serviceorientierte Architektur nicht von einer bestimmten Technologie abhängig ist wie etwa von Web Services ³ : „Conversely, using Web services technologies to implement a distributed system doesn’t magically turn a distributed object architecture into an SOA“ [W3C04, S. 62]. Genauso gilt andersherum, dass Web Services nicht notwendigerweise am Besten für die Implementierung einer serviceorientierten Architektur sein müssen. Eine serviceorientierte Architektur ist also erst einmal nichts anderes als eine Anleitung, nach der man eine Architektur für Dienste erstellen kann. Um die oben zitierte Definition deutlicher zu machen, werden im folgenden die Konzepte aufgelistet, die nach Juric eine serviceorientierte Architektur auszeichnen [JMS06, S. 13 f.] ⁴ :

³ Die offizielle Definition für einen Web Service lautet:

„A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards“ [W3C04, S. 7].

⁴ Vgl. dazu auch die Auflistung des W3Cs: http://www.w3.org/TR/ws-arch/#service_oriente d_architecture

54

• Dienste die Business-Funktionalitäten anbieten (z.B. eine Anwendung für die Reiseabrechnung). Das ist ein großer Unterschied zu Diensten, die technische Funktionalitäten bereitstellen wie z.B. das Speichern und Abrufen von Daten in einer Datenbank. In einer serviceorientierten Architektur liefert ein Dienst hingegen einen betriebswirtschaftlichen Wert, ist autonom und verbirgt seine Implementierungsdetails.

• Selbstbeschreibende Interfaces mit grober Granularität. Kunden ⁵ können über solche Interfaces auf Dienste von Anbietern zugreifen. Das Interface stellt dabei gleichzeitig einen Vertrag zwischen Kunde und Anbieter des Dienstes dar und ist von der eigentlichen Implementierung getrennt und plattformunabhängig [JMS06, S. 13 f.]. Über Metadaten werden die Operationen beschrieben, die ein Dienst ausführen kann. Durch diese Art von Interfaces wird eine Entkoppelung von Kunde und Anbieter von Diensten ermöglicht. Damit ist es auch nicht mehr nötig, dass man den Aufbau der einzelnen Dienste kennen oder sich mit den Details ihrer Implementierung auseinandersetzen muss [W3C04, S. 60 f.].

• Austausch von Nachrichten (eine im Interface definierte Operation ist ein Set von Nachrichten). Diese Nachrichten spezifizieren die Daten, die zwischen Diensten ausgetauscht werden können. Im Gegensatz zur objektorientierten Programmierung ist keine Vererbung möglich. Des Weiteren muss eine Operation idempotent sein, d.h. dass der mehrmalige Aufruf eines Dienstes den gleichen Effekt haben muss wie der einmalige Aufruf eines Dienstes.

• Unterstützung von synchroner und asynchroner Kommunikation (z.B. durch das Protokoll SOAP ⁶ oder durch einen ESB (Enterprise Service Bus))

• Lose Kopplung. Die lose Kopplung der einzelnen Dienste wird sichergestellt durch die selbstbeschreibenden Interfaces, die grobe Granularität, die synchrone und asynchrone Kommunikation und den Austausch von Nachrichten.

• Service Registries. In Service Registries (z.B. UDDI) listen Diensteanbieter alle Dienste auf, die sie anbieten.

• Qualität der Dienste. Mit der Qualität der Dienste sind z.B. Aspekte der Sicherheit oder der reibungslose Austausch von Daten gemeint. Die Qualität der Dienste kann bei Web Services durch eine Vielzahl von Standards wie z.B. WS-Security, WS-Coordinating oder WS-Adressing erreicht werden. Ein ESB kann ebenso die Qualität von Diensten sicherstellen.

• Die Komposition von Diensten zu Geschäftsprozessen. Über spezielle Sprachen wie BPEL können mehrere Dienste zu Geschäftsprozessen zusammengeführt werden.

⁵ Kunden (service consumers) sind Entitäten, die Dienste aufrufen und deren Funktionalität nutzen.

⁶ Wurde früher mit Simple Object Access Protocol abgekürzt.

55

Empfehlenswert sei die Umsetzung einer serviceorientierten Architektur mit Web Services bei Anwendungen, die über das Internet ablaufen und bei denen eine schnelle Übermittlung und eine hohe Zuverlässigkeit nicht garantiert werden kann (1). Gut einsetzbar ist diese Kombination auch überall dort wo keine Möglichkeit besteht, neue Updates einzuspielen (2). Außerdem ist eine serviceorientierte Architektur mit Web Services immer dann geeignet, wenn die Komponenten eines verteilten Systems auf Platt-formen unterschiedlicher Hersteller laufen (3) und wenn existierende Anwendungen als Web Services gekapselt werden sollen, um ihre Funktionalität über ein Netzwerk bereitzustellen (4) [W3C04, S. 62]. Das größere Potential im Einsatz von serviceorientierten Architekturen mit Web Services gegenüber vergleichbaren älteren Technologien liegt vor allem in den verwendeten Standards. „Während CORBA versucht hat selbst einen neuen Standard durchzusetzen, benutzen Web Services Standards, die durch die Verbreitung des Internets durchgesetzt sind: HTML(s) und XML“ [Soi06]. Auch das Verständnis von BPEL ist wichtig für das Verstehen des Potentials von SOA. Die Business Process Execution Language für Web Services (BPEL), auch WS-BPEL oder BPEL4WS genannt, ist eine XML-basierte Sprache, die speziell für die Komposition, Orchestration und Koordination von Web Services zu Geschäftsprozessen entwickelt wurde [JMS06, S. 5]. An der Entwicklung dieser Sprache sind unter anderem BEA, IBM, Microsoft, Oracle und SAP beteiligt [Oas06]. Einen Überblick über die teils verwirrenden Kürzel und Entwicklungen im Geschäftsprozessmanagement, von denen BPEL nur eine unter vielen ist, liefert Bartonitz [Bar05].

Mit BPEL können Geschäftsprozesse nun auf zweierlei Weise beschrieben werden. Dies sind zum einen Geschäftsprozesse, die in einer „BPEL engine“ ausführbar sind (1). Bei diesen Prozessen kommt die Orchestration zum Tragen. Bei ihr werden mehrere Web Services durch einen zentralen Prozess (in der Regel ein Web Service) zu einem Geschäftsprozess zusammengefügt. Dieser zentrale Prozess steuert dabei den Aufruf der unterschiedlichen Operationen der einbezogenen Web Services. Die Orchestration ist also immer zentralisiert und die beteiligten Web Services kennen nicht den Geschäftsprozess, in den sie mit einbezogen werden. Zum anderen gibt es abstrakte Geschäftsprozesse (2), die nur den Austausch öffentlicher Nachrichten aller Beteiligten definieren. Abstrakte Geschäftsprozesse sind nicht ausführbar, werden choreographiert und finden nur wenig Verwendung. Bei der Choreographie gibt es keinen zentralen Koordinator, der die am Geschäftsprozess beteiligten Web Services aufruft. Stattdessen müssen die beteiligten Web Services selbst den Geschäftsprozess kennen und rufen sich gegenseitig selbst auf. Die Orchestration hat daher gegenüber der Choreographie Vorteile. So weiß man bei ihr z.B. wer für Geschäftsprozesse verantwortlich ist. Zudem können weitere Web Services leichter miteinbezogen werden, auch wenn sie den Geschäftsprozess nicht kennen [JMS06, S. 19 ff.].

Der Vorteil von BPEL gegenüber ähnlichen Technologien wie CORBA ist, dass diesmal alle wichtigen Hersteller BPEL und Web Services als Standard akzeptieren. Andererseits sind Technologien wie BPEL immer noch nicht ganz ausgereift und es ist nicht immer klar, in welche Richtung die unterschiedlichen Hersteller gehen. Bartonitz meint dazu:

„Für die Anwender bedeutet es, dass man sich derzeit um Standards ei-

56

gentlich nicht so richtig einen Kopf machen muss. Einerseits sind die Großen bei allen wichtigen Standardisierungen dabei und zum anderen kommt es vermutlich auch dann immer noch darauf an, „was am Ende hinten raus kommt.“ Damit soll gemeint sein, dass es keine Weltformel für Prozesssteuerungen geben kann. [Es wird] immer auf die dedizierten Anforderungen ankommen [...], gegen die [sich] die potentiellen Kandidaten [...] messen müssen [lassen] ...“ [Bar05] ⁷ .

SAP und Oracle verfolgen beide das Konzept von einer serviceorientierten Architektur und wollen ihre Funktionalitäten in Zukunft über Web Services zur Verfügung stellen. Das Marktforschungsinstitut Forrester sieht in diesem Punkt SAP mit 150 Web Services mit mySAP 2007 momentan vor Oracles Fusion Applications. Außerdem kommen bei beiden Herstellern Web Services, BPEL und Java/J2EE zum Einsatz. Allerdings gibt es durch einige Eigenentwicklungen und Erweiterungen beider Hersteller Unterschiede. Forrester rechnet damit, dass SAP mindestens ein bis zwei Jahre im Feld braucht, bis mySAP 2007 in Unternehmen eingeführt ist und seine Vorteile ausspielen kann. Forrester setzt daher das Jahr 2009 für erste in Unternehmen lauffähige mySAP 2007-Anwendungen an. Für Oracles Fusion Applications nennt Forrester das Jahr 2010. Die Marktforscher kritisieren an beiden Unternehmen, dass die Unternehmen nur unzureichend Informationen herausgeben. So seien viele Informationen von SAP sehr vage und oftmals verwirrend. Auch würden bei Produkt-Demonstrationen nur sehr kleine Ausschnitte gezeigt [RHW06].

Forrester kommt zu dem Schluss, dass beide Unternehmen ihre Kunden vor große Herausforderungen stellen und von ihnen erwarten, dass sie auf eine neue Technik mit neuem Code eingehen, bei der die wirklichen Risiken und Vorteile noch nicht abzuschätzen sind. Daher wird empfohlen, dass die Kunden, je nach dem ob sie SAP- oder Oracle-Kunde sind, SAP NetWeaver oder Oracle Fusion Middleware lizensieren, um ein wenig mit diesen neuen Technologien zu experimentieren. Beide Produkte seien als relativ günstige Lizenzen zu bekommen. Des Weiteren wird empfohlen, dass man sich mit Entwicklungen wie BPEL oder BAM (Business Activity Monitoring, Software um Geschäftsprozesse zu überwachen) auseinander setzt, die den Einstieg in eine serviceorientierte Architektur erleichtern [RHW06].

4.1.2 Der ITIL-Standard

Einen großen Einfluss auf das derzeitige IT-Management dürfte der Quasi-Standard ITIL (Information Technology Infrastructure Library) haben, „der Mitte der 80er-Jahre im Auftrag der britischen Regierung entwickelt wurde“ [Els06, S. 6]. ITIL ist besonders in England und den Niederlanden weit verbreitet [Krc05, S. 366], wird aber auch zunehmend in anderen Ländern wichtiger. Nach einer Umfrage von CIO Online im Juni 2004 antworteten auf die Frage „Planen Sie in diesem Jahr die Einführung von ITIL?“ 40%

⁷ Man fühlt sich dabei an den Versuch des Wiener Kreises erinnert, der in den 20er und 30er Jahren des letzten Jahrhunderts alle wissenschaftlichen Aussagen in eine formale Sprache wie etwa die der Physik oder Mathematik überführen wollte und damit scheiterte.

57

Tabelle 4.2: Akzeptanz von ITIL in Deutschland. Es wurden ungefähr 1000 Unternehmen

der Befragten mit Ja, 26% mit Nein, 25% mit „ITIL wird bereits eingesetzt“ und 9% mit „Nutzen [einen] anderen Standard“ [Onl04c]. Zu etwas niedrigeren, aber vermutlich repräsentativeren Ergebnissen kam eine Umfrage, die von Research & Consulting durchgeführt wurde (Vgl. Tabelle 4.2) ⁸ . Allerdings hatten 40% der befragten Unternehmen weniger als 100 Mitarbeiter. Eine Einführung des recht komplexen ITIL-Standards scheint in solchen Betrieben wenig sinnvoll.

ITIL stellt ein Best Practices-Regelwerk dar, dass sehr allgemein formuliert ist und sich deshalb auf jede Organisation anpassen lässt. „Die eigentliche Realisierung [von ITIL] muss [aber] jeder CIO für seine eigene Organisation selbst planen und durchführen“ [Els06, S. 154]. ITIL ist also kein Patentrezept. Das Ziel von ITIL ist die IT umzugestalten. Nicht mehr die technische Sicht der IT soll im Vordergrund stehen, sondern die Serviceorientierung der IT [Els06, S. 157]. Zudem gibt ITIL dem CIO einen einheitlichen Standard für die Definition von Prozessen an die Hand und gibt durch Leitlinien vor wie IT-Prozesse (Prozesse, die Geschäftsprozesse mit IT unterstützen) an Geschäftsprozesse angepasst werden sollten. Das Herzstück von ITIL sind die zehn Prozesse, die in Tabelle 4.3 dargestellt sind. „Jeder dieser Prozesse ist in sich abgeschlossen und bildet eine logische Einheit“ [Els06, S. 48]. Sie können aber untereinander über Schnittstellen in Verbindung stehen. Insgesamt definieren sie „die alltäglichen Funktionalitäten und Aufgaben des IT-Betriebes“ [Els06, S. 48].

Um die IT-Prozesse in die Praxis umzusetzen, kann z.B. auf MOF (Microsoft Operations Framework) zurückgegriffen werden, dass auf ITIL aufbaut. Insgesamt gesehen, kann man ITIL als ein Geschäftsprozessmanagement ansehen, dass speziell für die IT-Abteilung entwickelt wurde. Ein CIO, der ITIL in seiner IT-Abteilung umgesetzt hat, und zwar nicht nur auf technischer Ebene, erfüllt daher sicher wichtige Punkte des Anforderungsprofil eines CPOs.

⁸ Zahlreiche Ergebnisse aus Umfragen zu ITIL, besonders im deutschen Raum, finden sich im „ITIL-Praxisbuch“. Das Kapitel, dass diese Umfragen behandelt, ist kostenlos abrufbar unter: http://www.

58

Tabelle 4.3: Die zehn ITIL Prozesse des Service-Supports und Service-Delivery. Nach [Els06, S. 48 u. 80]

4.1.3 Der CPO in der Sicht deutscher IT-Verantwortlicher

Immer mehr IT-Verantwortliche sind davon überzeugt, dass ein CPO sinnvoll ist. In den Business Process Studien von 2005 [Gil05] und 2006 [Gil06] fragte man jeweils 150 IT-Verantwortliche, ob sie einen CPO mit zentraler Verantwortung und Entscheidungskompetenz begrüßen würden. Mit Ja antworteten 2006 58%, während 2005 erst 47% Ja angaben. Die Zahl der IT-Verantwortlichen die Nein angaben sank von 34% (2005) auf 22% (2006). Die Befragten, die keine Angabe machten, blieb mit 19% ⁹ (2005), bzw. 20% (2006) nahezu gleich. Die Befürwortung eines CPOs lag in den Umfragen von 2003 (64%) und 2004 (72%) zwar deutlich über den 58% von 2006, die Ergebnisse dürfen aber keinesfalls miteinander verglichen werden [Gil04]. 2003 und 2004 existierte noch nicht die Option „keine Angabe“, sodass die Befragten vermutlich eher für die Einrichtung eines CPOs stimmten.

Bei der Frage „Wo sollte der IT-/Prozessverantwortliche angesiedelt sein?“ spiegelten sich die Ergebnisse aus Kapitel 3 wider. Nur 25% der IT-Verantwortlichen meinen, dass der IT-/Prozessverantwortliche, also der CIO oder CPO, auf der „C-Level-Ebene (Vor-stand)“ angesiedelt sein sollte. 25% würden ihn sogar nur auf Fachabteilungsebene sehen, was lt. Sesselmann und Schmelzer [SS06, S. 136] ein Anzeichen dafür ist, dass dem Prozessmanagement nur wenig Beachtung beigemessen wird. Die Mehrheit mit 50% würde ihn am liebsten als „Schnittstelle zwischen IT und Fachabteilung“ sehen [Gil06]. Auf die Frage wie sehr sich die Befragten mit Prozessmanagement beschäftigten, ant-worteten 2006 (2005 in Klammer) 25% (17%) mit „sehr stark“, 55 % (50%) mit „stark“ und 20% (33%) mit „wenig“ [Gil06]. „Sehr stark“ war damit wieder auf dem Niveau von 2004, „stark“ sogar auf den Höchststand. Dem Prozessmanagement wurde von den IT-Verantwortlichen damit insgesamt mehr Bedeutung zugesprochen als in den vergangenen Jahren (wenn auch nur geringfügig).

mitp.de/imperia/md/content/vmi/1583/1583_kap01.pdf

⁹ In der Umfrage 2005 wurde noch zwischen „weiß nicht“ (6%) und „keine Angabe“ (13%) unterschieden, die hier einfach zusammengezählt wurden.

59

Tabelle 4.4: Für diese Umfrage wurden 194 Unternehmen befragt. Von diesen 194 sag-

Finanzdienstleistersensibler für Geschäftsprozessmanagement

In einer Umfrage von [CON05] wird zwischen Finanzdienstleistern und anderen Branchen unterschieden. Für die Umfrage wurden 800 Unternehmen angeschrieben, von denen 194 antworteten. 60 davon waren Finanzdienstleister. Hierbei stellte sich heraus, das die Finanzdienstleister sich etwas intensiver mit Geschäftsprozessmanagement beschäftigen als die übrigen Branchen. Auf die Frage, ob „es einen Chief Process Officer als Verantwortlichen für Geschäftsprozessmanagement“ gibt, antworteten z.B. 34% der Finanzdienstleister mit Ja (25% Gesamt). Dabei hatten die Herausgeber der Studie einen CPO im Blickfeld, der am ehesten dem in Kapitel 7 beschriebenen entspricht. Vgl. dazu unbedingt Tabelle 4.4, da sich der doch recht hohe Prozentsatz von 25% ¹⁰ relativiert, wenn man die Ergebnisse genauer betrachtet.

¹⁰ In der Business Process Studie von 2004 gab kein Unternehmen an, dass es die Position eines CPOs hätte [Gil04]

60

4.2 CPO-Konzepte

Unter einem CPO-Konzept verstehen wir die Vorstellungen, die ein Autor über den CPO hat. Diese Vorstellungen stehen am Anfang jedes Kapitels, dass ein Konzept beschreibt. Ihnen wird auch der meiste Platz eingeräumt. Des Weiteren sollen die Aufgaben, Kompetenzen und Verantwortungen, die jedes CPO-Konzept vorsieht, dargelegt werden. Dies kann aber nur insoweit geschehen wie der jeweilige Autor auch Hinweise auf diese drei Bereiche gibt. Da alle CPO-Konzepte auch die Anforderungen an einen zukünftigen CPO beschreiben, werden diese ebenfalls mit aufgenommen. Diese vier Punkte

1. Aufgaben

2. Kompetenzen (auch Zuständigkeit oder Befugnis genannt)

3. Verantwortung

4. Anforderungen

finden sich am Ende eines jeden Kapitels, das ein Konzept beschreibt. Damit soll eine übersichtlichere Darstellung ermöglicht werden. Aufgaben leiten sich aus den Unternehmenszielen ab und stellen eine „dauerhaft wirksame Aufforderung an einen Aufgabenträger dar, festgelegte Verrichtungen wahrzunehmen“ [OS03, S. 243]. Unter Kompetenz versteht man „die einem Aufgabenträger (Stelleninhaber) übertragenen Rechte oder Befugnisse [...] innerhalb eines vorgegebenen Handlungsspielraums Tätigkeiten bestimmter Art zur Erfüllung seiner Aufgaben vorzunehmen“ [Hah75, S 1112]. Unter Verant-wortung versteht man letztlich das persönliche Einstehen für getroffene Entscheidungen sowie erfolgloses wie erfolgreiches Handeln. Auch wer Handlungen unterlässt, kann zur Verantwortung gezogen werden [OS03, S. 245].

Dadurch, dass nicht immer Aufgaben, Kompetenzen und Verantwortung klar umrissen sind, kann nicht festgestellt werden, ob die Konzepte dem Kongruenzprinzip genügen. Nur wenn dieses Prinzip erfüllt ist, kann ein Aufgabenträger auch die ihm aufgetragenen Aufgaben optimal erfüllen. Dazu müssen ihm die nötigen Befugnisse übertragen werden. Dies ist der Fall wenn Aufgaben, Kompetenzen und Verantwortung kongruieren (übereinstimmen) [Gau66, S. 185 ff.]. Die Folgen „einer Stelle [die] falsch zusammengesetzt oder übergroß dimensioniert ist“ beschreibt Gaugler wie folgt:

„Eine Stelle, die nicht an den personalen Eigenheiten der für sie üblichen Aufgabenträger ausgerichtet ist, kann eine auch an sich gute Qualifikation des Stelleninhabers hemmen bzw. zugrunde richten. In der Führungsorganisation zeigt sich das beispielhaft bei Mehrfachunterstellungen, Kompetenzüberschneidungen und ähnlichen Organisationsmängeln. [Gau66, S. 124]“

In der Praxis ist das Kongruenzprinzip bei einer Matrix- oder Tensororganisation schon per se nicht einzuhalten. Auch die fayolsche Forderung der Einheit der Auftragserteilung (Jeder Mitarbeiter erhält nur von einem Leiter Anweisungen) und der Leitung (Ein Programm pro Leiter) fällt mit diesen neueren Organisationsformen [Fay29, S. 22 f.].

61

Gleichzeitig bemüht man sich aber im Geschäftsprozessmanagement der Einheit der Auftragserteilung durch eine Prozessorganisation gerecht zu werden. In einer Prozess-organisation wird eine andere Form der Arbeitsteilung als in einer funktionsorientierten Organisation angestrebt. In letzterer werden große Spezialisierungsvorteile erzielt, in dem man „gleichartige Funktionen (Verrichtungen) [zusammenfasst] und [...] auf orga-nisatorische Einheiten“ [BG02, S. 321] überträgt. Die mit dieser Spezialisierung verbundenen Nachteile wie Ressortegoismus, mangelnde Gesamtsicht auf das Unternehmen und unzureichende Kundenorientierung [BG02, S. 323] soll die Prozessorganisation beheben. In ihr

„werden Organisationseinheiten so gebildet, dass wichtige Geschäftsprozesse möglichst vollständig innerhalb einer einzelnen Organisationseinheit abgewickelt werden können, allerdings jeweils nur für eine beschränkte Auswahl von zu bearbeitenden Objekten“ [All05, S. 14].

62

5 Der CPO nach Schmidt und Seidel

Der CPO nach Schmidt und Seidel geht auf den Aufsatz „From CIO to CPO“ im Jahre 2001 zurück. 2003 schrieb Schmidt ¹ einen weiteren Artikel im Business Integration Journal, in dem er seine Auffassung von 2001 noch einmal bestätigte [Sch03b]. Schmidt und Seidel haben besonders in der IT-Branche Erfahrung gesammelt. So leitete Schmidt z.B. über Jahre hinweg IT-Integrations-Projekte in anderen Unternehmen als Berater. Daher ist es nicht verwunderlich, dass bei diesem CPO die technische Seite stärker gewichtet wird.

5.1 Allgemeine Vorstellungen

Schmidt und Seidel zeichneten als erste ein grobes Bild des CPO. Der CIO der Zukunft soll demnach die technische Grundlage schaffen, die eine Evolution der Geschäftsprozesse in einem Unternehmen ermöglicht:

„The CPO’s main job will be to manage the IT organization to provide a technology infrastructure that can support business process evolution in EAIenabled environment“ [SS01]

Das Wort Evolution kann in diesem Zusammenhang in seiner durchaus darwinistischen Bedeutung verstanden werden. Durch verschiedene Instrumente wie Probeläufe, Prozesskostenrechnung u.ä. soll eine Auslese der möglichst geeigneten Geschäftsprozesse stattfinden. Der zweite Treiber der Evolution neben der Auslese, die Mutation, findet natürlich nur insofern statt als dass neue Geschäftsprozesse gesucht oder erstellt werden. Die dafür nötige Flexibilität der IT-Landschaft soll der CPO durch den Einsatz von EAI-Technologie erreichen. EAI bezieht sich auf die Integration von unterschiedlichen Anwendungen innerhalb eines Unternehmens, „die nicht für eine Zusammenarbeit ent-worfen wurden und auch nur Teilaufgaben von Geschäftsprozessen abdecken, dazu zu bringen, in einheitlichen Geschäftsprozessen zusammenzuspielen“ [Kel02, S. 5]. „Dabei [wird] zwischen innerbetrieblicher und zwischenbetrieblicher Integration unterschieden. Die innerbetriebliche Integration wird auch als Enterprise Application Integration (EAI) bezeichnet, die zwischenbetriebliche Integration als Business-to-Business-(B2B)-Integration (Linthicum 2003)“ [HGRZ06, S. 51]. Allerdings wird der Begriff der EAI nicht immer eindeutig verwendet, sodass man nie ausschließen kann, dass jemand, der von EAI redet, implizite auch die Integration von externen Anwendungen meint, die z.B. einen reibungsloseren Ablauf der Wertschöpfungskette ermöglichen würden.

¹ Weitere Artikel von Schmidt findet man auf: http://www.wwintegration.com/

63

5.1.1 Die drei Mythen des CIOs

Schmidt und Seidel bennenen „drei Mythen“ im Management von IT-Systemen. Diese Mythen, die im folgenden einzeln erkärt werden, führt Schmidt in einem späteren Aufsatz auf einen in die Informatik übernommenen Reduktionismus zurück [Sch03a] ² . Eine Reduktion ist die Erklärung einer Theorie für einen Gegenstandsbereich durch eine andere Theorie, die sich mit einem anderen Gegenstandsbereich beschäftigt [Nag79, S. 338]. Ein Beispiel ist z.B. die mechanistische Auffassung der Biologie, nach der biologische Systeme, Zustände und Prozesse nichts anderes als chemische, bzw. physikalische Systeme und Zustände sind [Hem01, S. 190 ff.] ³ . An dieser Auffassung wird gelegentlich die Kritik geäußert, dass das Ganze (z.B. ein lebender Organismus) mehr als die Summe seiner Teile (z.B. die einzelnen Atome) sei ⁴ .

Unklar bleibt aber, ob Schmidt der Meinung ist, dass im IT-Management schlicht eine Reduktion auf Bestandteile der Informatik stattfindet oder ob die Informatik selbst wieder auf andere Bereiche reduziert wird. Die drei Mythen werden in „From CIO to CPO“ wie folgt beschrieben:

1. Planbasiertes Information Engineering (Plan-based information engineering). Die Unternehmens-IT kann nicht geplant werden, es sei ein Irrglaube nach einem Plan die gesamte Unternehmens-IT an die Umwelt anzupassen. In der sich schnell verändernden Wirtschaft sei es unmöglich zu wissen, welche Geschäftsprozesse morgen benötigt werden. Beim planbasierten Information Engineering gehe man aber davon aus, dass man den richtigen Weg für Geschäftsprozesse finden, planen und entwickeln könne. Diese Systeme seien dann aber nur schwer anpassbar und würden der sich schnell verändernden Wirtschaftswelt nicht gerecht.

2. Inkonsistente Daten müssen beseitigt werden. Heutige Tools für das Data-Management oder relationale Datenbankmodelle verlangen, dass redundante Daten beseitigt werden. Inkonsistente oder redundante Daten seien aber unvermeidlich, wenn Systeme auf die lokalen Bedürfnisse angepasst werden müssen. „In a process-centered world, the data is what it is. Make it as good and clean as you cost-effectively can, but don’t let dirty data get in the way of effective management“ [SS01]. Für Schmidt sind daher Informationen aus Daten nur zu gewinnen, wenn sie in den richtigen Kontext gesetzt werden (Information = Daten + Kontext). Ein Attribut wie „Current Customer“ könne z.B. für unterschiedliche

² Der ganze Abschnitt zum Thema Reduktionismus von Schmidts Artikel findet sich beinahe 1:1 auf einer holistischen Seite zur Erziehung wieder: http://members.iinet.net.au/~rstack1/wview. htm. Im Text wird daher zwar die gleiche Argumentationslinie wie von Schmidt eingeschlagen, es werden aber andere Quellen hinzugezogen...

³ Dies ist nur eine sehr vereinfachte Darstellung des Reduktionismus, siehe dazu z.B. bei Hempel das Kapitel Reduction [Hem01, S. 189 ff.] oder bei Ernest Nagel das Kapitel The Reduction of Theories [Nag79, S. 336 ff.]

⁴ Vgl. dazu den Aufsatz von Nagel [Nag72] über die Aussage „Das Ganze ist mehr als die Summe seiner Teile“. Nagel beschreibt die verschiedenen Bedeutungen von Ganzes, Summe und Teile. So ist z.B. der Satz „Das Ganze ist mehr als die Summe seiner Teile“ trivial, wenn mit Summe bei einer Melodie z.B. nur „die ungeordnete Klasse der einzelnen Töne“ wie C oder D gemeint ist [Nag72, S. 232].

64

Abteilungen ganz verschiedene Bedeutungen haben, eine EAI-Lösung sollte daher solche Fälle berücksichtigen [Sch03a, S. 5].

3. Plug-and-Play Wiederverwendbarkeit. Smith und Howard halten die Wiederverwendbarkeit von Programmteilen für einen der größten Irrtümer der CIO-Ära. Unter Plug-and-Play Wiederverwendbarkeit verstehen sie:

a) dass komplexe Probleme in kleinere und leichter handhabbare Teile zerschlagen werden. Je näher die Probleme in die reale Welt rücken, desto schwieriger erweisen sich „Divide and Counquer“ Methoden, um mit ihnen die Realität abzubilden. Bei komplexeren Problemen ist es daher oft einfacher sie als Ganzes zu betrachten, anstatt sie in kleinere handhabbare Probleme aufzuteilen.

b) Jedes einzelne Teil als eine wieder verwendbare Komponente zu programmieren. Die Wiederverwendbarkeit sei alles in allem in der objektorientierten Anwendungsentwicklung enttäuschend. Zwar lassen sich innerhalb von Klassenhierarchien durchaus Programmteile wieder verwenden, sie wurden dann aber immer für diesen speziellen Zweck geschrieben. Es gäbe in der Wirtschaftswelt keinen Fall, in dem zwei Objekte zusammen für ein Problem eine Lösung bildeten, für die sie nicht programmiert wurden.

c) Standardprotokolle, Schnittstellen und Semantiken für den Informationsaustausch zwischen Komponenten zu verwenden. Es sei noch lange nicht damit getan, dass man den gleichen Standard benutze, um miteinander zu kommunizieren. Bloß weil Engländer und Franzosen das gleiche Alphabet verwenden, können sie nicht miteinander reden. Während dieser Punkt in [SS01] noch etwas verwirrend klingt, wird in [Sch03a] schnell deutlich, worauf Schmidt und Seidel hinaus wollen:

Diese drei Mythen sollten nicht dahingehend missverstanden werden, dass Schmidt und Seidel generell gegen Wiederverwendbarkeit, objektorientierte Programmierung, Standards u.ä. wären. Diese drei Mythen sollen eher die Grenzen dieser Konzepte aufzeigen. Kritisch sehen Schmidt und Seidel eine zu zentralistische IT. Keller, Manager für wiederverwendbare Softwarekomponenten bei der Generali Group Vienna, bestätigt diese Auffassung:

„In Vorlesungen lernen wir, wie wichtig es ist, integrierte Systeme und Datenmodelle zu haben. In den 80er Jahren und auch noch in den 90ern führte das zu

65

• einheitlichen Unternehmensdatenmodellen

• unternehmensweiten, einheitlichen Entwicklungsumgebungen und

• unternehmensweiten Repositories

Man hätte am liebsten alle Systeme voll integriert. Alle Systeme sollten online auf relationalen Datenbanken arbeiten und im Endeffekt auf einer einzigen logischen relationalen Datenbank. Das ist die Vision, die immer noch Lehrmeinung ist. Heute weiß ich, dass unser Unternehmen die Euro-Umstellung nicht überlebt hätte, wenn wir ein dermaßen perfekt integriertes System gehabt hätten.“ [Kel02, S. 179]

Gegen eine integrierte, bzw. zentralistische IT, wie Schmidt und Seidel sagen würden, spricht also nicht nur der höhere Aufwand bei der Integration neuer Anwendungen; sondern auch, dass sich Fehler in einem voll integriertem System leichter fortpflanzen. Der IT-Manager hat keine Eingriffs- und Kontrollmöglichkeiten mehr:

Integrierte Systeme „funktionieren leicht nach dem »alles oder nichts«-Prinzip. Und die Zuverlässigkeitstheorie besagt, je mehr Subsysteme parallel richtig funktionieren müssen, damit das Gesamtsystem funktioniert, desto geringer ist die Wahrscheinlichkeit, dass das Gesamtsystem funktioniert. [...] Wenn Sie EAI und andere Integrationstechniken benutzen, um integrierte Systeme zu schaffen, die nur noch funktionieren, wenn alle Subsysteme gleichzeitig funktionieren und keine Batch-Fenster und Zwischenbestände mehr haben, können Sie Probleme bekommen. Fehlerbeseitigung kann dann wesentlich länger dauern und größere Teile des Gesamtsystems lahm legen“ [Kel02, S. 180].

Um den oben behandelten Mythen zu entkommen, empfehlen Schmidt und Seidel den Einsatz von EAI, um eine prozessorientierte IT-Infrastruktur zu ermöglichen. Des Weiteren empfehlen sie, dass man bei Werkzeugen für die Prozessmodellierung nicht zuviele Details verwendet werden und das die so erstellten Prozessmodelle möglichst zu jedem Zeitpunkt der Software-Entwicklung ausführbar sein sollten, da man zu komplexe Modelle nicht testen kann und so die Frage offen bleibe, welche Vor- und Nachteile ein Modell bringt [SS01].

5.1.2 Der Paradigmenwechsel vom CIO zum CPO bringt neue Wörter hervor

Schmidt meint eigentlich keinen richtigen Paradigmenwechsel, sondern eher, wenn man denn den Paradigmenbegriff ⁵ verwenden will, das Erscheinen eines neuen Paradigmas. Mit diesem neuen Paradigma gehen die folgenden neuen Begriffe einher:

⁵ siehe auch Punkt 2.4

66

• Von der Database Administration (DBA) zur Data Exchange Administration (DEA). Die Database Administration wird es nach Schmidt solange geben wie es auch Datenbanken gibt, neu wäre aber die Data Exchange Administration, die die Middleware-Infrastruktur konzentriert.

• Vom Enterprise Data Model (EDM) zum Enterprise Event Model (EEM). Das Enterprise Data Model beschreibt die Struktur, Syntax und Semantik der verschiedenen Datenbanken und des Enterprise Data Warehouses in einem Unternehmen. Das Enterprise Event Model hingegen definiert in einer Sprache wie XML den Austausch von Informationen zwischen den verschiedenen Systemen im Unternehmen und legt die formale Struktur für Geschäftsprozesse fest (Vgl. dazu Punkt 7.2.1 und 5.2.2). Neu hinzukommen soll auch ein Process Warehouse als Gegenstück zum Data Warehouse.

• Metadaten sollen in Zukunft durch Metaprozesse ergänzt werden. Dazu soll das Metadaten Repository den Geschäftsprozesse-Katalog (Vgl. auch Punkt 5.2.1) aufnehmen. Dieser Katalog ist der Bezugrahmen für alle End-to-End-Geschäftsprozesse. Außerdem sollte das Metadaten Repository in der Lage sein, alle Geschäftsprozesse auf verschiedenen Abstraktionsebenen darzustellen. Mit dem Metadaten Repository sollte man auch in der Lage sein, den Geschäftsprozess-Katalog auf verschiedenen Abstraktionsebenen zu betrachten, d.h. konkret, dass man bis auf die Ebene der einzelnen Nachrichten navigieren können sollte.

5.2 Aufgaben, Kompetenzen, Verantwortung und

Anforderungen

5.2.1 Aufgaben

Um eine flexible IT-Architektur mit Hilfe von EAI zu implementieren, sollte der CPO folgende Aufgaben wahrnehmen (nach [SS01]):

• Er sollte mit statistischen und wissenschaftlichen Methoden Geschäftsprozesse managen.

• Sollte einen Geschäftsprozesskatalog führen, in dem alle Geschäftsprozesse aufgelistet sind. Dieser Katalog sollte mit den Geschäftsereignissen und dem sogenannten „system interaction model“ abgestimmt sein, welches die Aufgabe und das Ergebnis jedes Geschäftsprozesses definiert.

• Er stellt sicher, dass die Ergebnisse vergleichbar sind und sich gewichten lassen.

• Er erstellt mehrere miteinander im Wettbewerb stehende Geschäftsprozesse und testet sie.

• Berechnet für jede Prozessimplementierung die Kosten (nach Probeläufen der Prozesse) und vergleicht diese Kosten mit den Kosten anderer Prozesse.

67

• Sortiert ineffiziente Geschäftsprozesse aus und gibt den besten Prozessen mehr Spielraum.

• Führt kontinuierlich neue Implementierungen für weitere Evaluationen ein.

• Stellt sicher, dass die IT innerhalb von Tagen oder Wochen an neue oder veränderte Geschäftsprozesse anpassbar ist.

• Legt für jeden Geschäftsprozess sinnvolle Effektivitätskennzahlen fest. Definiert, wann ein Geschäftsprozess nahezu optimal läuft. Die Geschäftsprozesse sollten danach auch in einem Ranking gewichtet werden.

• Des Weiteren erstellt er einen Katalog in dem Geschäftsprozesse und Geschäftsereignisse aufgelistet sind und einen, in dem alle Systeme, Applikationen und Interfaces aufgelistet sind. Dadurch kann dann in einer Matrix übersichtlich gezeigt werden, welche Applikationen an welchen Geschäftsprozessen beteiligt sind.

5.2.2 Kompetenzen

Über die Kompetenzen des CPOs machen die Autoren keine Angaben. Vermutlich rechnen sie damit, dass er einen ähnlichen Kompetenz- und Verantwortungsbereich wie der CIO hat, wenn sie nicht mehr Kompetenz und Verantwortung fordern. Dagegen spricht allerdings, dass sie es als das Aufgabengebiet des CPOs ansehen, alle Geschäftsprozesse zu testen, zu beschleunigen, auszusortieren oder einzuführen. Verglichen mit den anderen CPO-Konzepten in Kapitel 6 und 7 wäre dies ein gewaltiger Kompetenz- und Verantwortungszuwachs, da die Kontrolle über sämtliche Geschäftsprozesse und ihre Implementierung von den Geschäftseinheiten in die Hände des CPOs gelangen würde. Da dies sehr unwahrscheinlich ist, ist nur vorstellbar, dass die Autoren ein anderes Verständnis von Geschäftsprozessen haben. Sinnvoll scheint hier nur, dass sie unter einem Geschäftsprozess einen automatisierten Ablauf verstehen ⁶ . Automatisierte Abläufe werden z.B. in Workflow Management-Systemen ⁷ verwendet ⁸ .

5.2.3 Verantwortung

siehe Kompetenz.

⁶ Dies scheint auch logisch, weil Schmidt in Punkt 5.1.2 eine Navigationsmöglichkeit bis auf die Ebene der einzelnen Message Queues für Geschäftsprozesse fordert.

⁷ Werden stellenweise heute auch einfach in Business Process Management-Systeme umbenannt. Was nicht heißt, dass alle Business Process Management-Systeme Workflow Management-Systeme wären.

⁸ Allweyer zeigt sehr gut die Missverständnisse auf, die durch unterschiedliche Bedeutungen für Geschäftsprozesse auftauchen können [All05, S. 51 ff.]. Er unterscheidet sechs Bedeutungen von Geschäftsprozessen: Eine betriebswirtschaftlich orientierte Verwendung, eine automatisierungsbezogene Verwendung, eine schnittstellenbezogene Verwendung, eine auf die Nutzung eines Anwendungssystems bezogene Verwendung, eine auf die Software-Entwicklung bezogene Verwendung und die schlicht falsche Verwendung des Begriffes. Das Kapitel „Unterschiedliche Verwendung des Prozess-Begriffs“ aus Allweyers Buch ist auch online verfügbar unter: http://www.bpm-guide.de/articles/26

68

5.2.4 Anforderungen

Nach Schmidt und Seidel sollte ein CPO über gute Kommunikationsfähigkeiten verfügen und auch einmal Menschen aus unterschiedlichen Bereichen an einen Tisch holen können. Zudem sollte er anpassungsfähig sein, da er auch oft unterschiedlichste Anwendungen, die sich seiner Kontrolle entziehen, für Geschäftsprozesse anpassen muss.

69

6 Der CPO nach Abolhassan und

Jost

Bekannt ist dieser CPO durch Josts Artikel im Harvard Business Manager [Jos04]. Ausführlichere Aufsätze finden sich im SCHEER MAGAZIN [Sch04], sowie fast identisch in der Zeitschrift SAP-Info [Jos05]. Den besten Überblick liefert Abolhassan [Abo05]. Fragen über die Bedeutung der IT oder die Zukunft des CIOs werden hier nicht näher behandelt, auch wenn sie von Jost und Abolhassan häufig angesprochen werden. Dafür sei auf die Kapitel 2 und 3 verwiesen.

6.1 Allgemeine Vorstellungen

Die Autoren folgen Carrs Argumentation nur eingeschränkt. Jost ist der Meinung, dass Carr nur insofern Recht hat, dass das Management der IT-Infrastruktur in Zukunft unwichtiger wird. Er folgt damit eher der Argumentationslinie von Smith und Fingars „IT doesn’t Matter, Business Processes Do“ [SF03], auf das im SCHEER MAGAZIN [Sch04] sogar verwiesen wird. Smith schrieb auch den Aufsatz „From CIO to CPO via BPM“, bleibt allerdings - genauso wie in seinem Buch mit Fingar - auf einem sehr allgemeinen Level, sodass sich nichts über den CPO aus diesen Quellen gewinnen lässt. Jost beschreibt den CPO in einem Interview wie folgt:

„alles, was darüber hinaus geht [über das Management der IT-Infrastruktur] und mit Betriebswirtschaft zu tun hat, wird an Bedeutung gewinnen. Denn genau darin liegt der Mehrwert der IT: In der Effizienzsteigerung von Geschäftsprozessen. Dafür braucht man einen Verantwortlichen, der auf der Ebene der Prozesse und der Betriebswirtschaft denkt. Gleichzeitig benötigt er natürlich ein starkes strategisches IT-Know-how. Das ist der CPO“ [Jos06].

Dieses Mehr an BWL sei wichtig, damit der CPO die mitunter sehr komplexen Prozesse von Unternehmen mit Technik verbinden kann. Im Gegensatz zu Schmidt und Seidel beschränkt er sich nicht auf Geschäftsprozesse innerhalb eines Unternehmens (EAI), sondern setzt sich auch mit unternehmensübergreifenden Geschäftsprozessen auseinander [Abo05, S. 371]. Darüber hinaus sei „[d]er Chief Process Officer [...] der Enabler des Real-Time Enterprise“ [Abo05, S. 373]. Das Real-Time-Unternehmen (auch Echtzeitunternehmen genannt), soll durch „den Abbau von Medienbrüchen unterschiedlichster Art [...] Abwicklungs- und Managementprozesse signifikant beschleunig[en]“ [PH05, S. 31]. Gartner fügt in seiner neusten Definition des Echtzeitunternehmens noch hinzu, dass es

70

Ursachen und Ereignisse, die kritisch für den Unternehmenserfolg sind, sofort bei ihrem ersten Erscheinen untersucht, um so neue Chancen aufzuzeigen, Verzögerungen in Kerngeschäftsprozessen zu reduzieren und Fehlentscheidungen zu vermeiden ¹ . Dadurch, dass viele Unternehmen ihre Prozesse und ihre IT nur auf Unternehmensebene betrachten, Optimieren sie nur auf lokaler Ebene, verschenken aber das Potential durch eine engere Einbindung von Lieferanten, Entwicklungspartnern, Vertriebspartnern und Kunden [SRW05, S. 14]. Dieses Potential zu erschließen, wäre somit eine wichtige Aufgabe des CPOs, wenn man ihn als Enabler des Echtzeitunternehmens ansieht ² . Dies soll möglich werden durch Geschäftsprozessmanagement-Systeme wie IDS Scheers Aris, dass in SAPs Netweaver integriert wird:

„Diese prozessorientierte Weiterentwicklung der Unternehmens-Software schafft die Voraussetzungen, damit betriebswirtschaftliche Abläufe dynamisch verändert und neue Anforderungen schnell angepasst werden können - kurz, dass Real-Time Enterprise in den Unternehmen möglich wird.“ [Abo05, S. 374]

6.2 Aufgaben, Kompetenzen, Verantwortung und

Anforderungen

6.2.1 Aufgaben

Die Aufgaben des CPOs werden im SCHEER MAGAZIN [Sch04, S. 5] und von Abolhassan [Abo05, S. 372 f.] wie folgt beschrieben:

• relevante Geschäftsprozesse identifizieren, beschreiben und analysieren

• Geschäftsprozesse optimieren

• Die ganze Wertschöpfungskette umfassende Geschäftsprozesse aufbauen (also auch externe Partner integrieren).

• Geschäftsprozessmanagement organisieren und für Prozesse und Teilprozesse Pro-zessverantwortliche bestimmen.

• Interne und externe Anwendungen integrieren.

• Kontinuierliches Controlling der Echtzeitunternehmensprozesse einführen.

¹ „The RTE monitors, captures and analyzes root-cause and overt events that are critical to its success the instant those events occur, to identify new opportunities, avoid mishaps and minimize delays in core business processes. The RTE will then exploit that information to progressively remove delays in the management and execution of its critical processes“ [McG04].

² Dabei müssten m.E. ähnliche Überlegungen wie vor dem Auslagern von Prozessen angestellt werden, damit das Unternehmen nicht auf diesen Weg z.B. Kernkompetenzen freigibt oder durch hohe Switching Costs abhängig wird.

71

Abbildung 6.1: Drei-Stufen-Modell des Geschäftsprozessmanagements. Eigene Darstel-

Um diese Aufgaben anzugehen, soll der CPO eine Real-Time-Plattform im Unternehmen aufbauen und weiterentwickeln. Eine Plattform ist erstellt, wenn die folgenden Bedingungen erfüllt sind: Erstens (1) sollte das Design von Prozessen mit Geschäftsprozessoptimierungs-Werkzeugen wie der ARIS Process Platform möglich sein [Abo05, S. 378]. Zweitens (2) sollten im Anwendungssystem Prozesse möglichst in Echtzeit ausführbar sein. Da neben ERP-Systemen meist andere Software an Geschäftsprozessen beteiligt ist, sei eine Integration dieser Software mit Hilfe von EAI oder Web Services wichtig, um Echtzeitbedingungen im Unternehmen herzustellen. Abolhassan hält Web Services für diese Aufgabe geeigneter, da EAI-Technologie nur die Schnittstellen vereinfache, aber nicht die Ausführung einzelner Funktionen unterstütze. Durch die Integration von ARIS in SAPs Netweaver soll die Prozessintegration über alle Systeme sichergestellt werden [Abo05, S. 379].

6.2.2 Kompetenzen

Darüber wie das Prozessmanagement organisatorisch im Unternehmen aufgehängt werden sollte, macht Abolhassan keine Angaben. Dies müsse „jede Unternehmung für sich selber entscheiden, da es keine richtigen oder falschen Lösungen“ gebe. Wichtig sei aber, dass die Prozessverantwortung dezentral ist [AB05], da die Fachabteilungen sich am besten mit dem Ablauf des Tagesgeschäft auskennen. Einige Angaben über die Organisation des Prozessmanagements werden aber gemacht, so schreibt Abolhassan in einem Aufsatz mit Becker, dass dem CPO funktional Prozessberater unterstellt sind, die „vorzugsweise auf allen Stufen den Entscheidungsträgern zur Seite stehen und diese bezüglich [des] Prozessmanagement[s] unterstützen“. Darüber hinaus sind sie z.B. zuständig für Fra-

72

gen der Ausbildung im Prozessmanagement oder der Standardisierung. „Hierarchisch sind [die Prozessberater] aber dem Linienverantwortlichen unterstellt und lassen seine konkreten Anliegen in die Projekte einfliessen“ [AB05, S. 373 f.]. Wie wichtig Prozessberater sind, zeigt schon das folgende einfache Beispiel, in dem es um den Einsatz von ereignisgesteuerten Prozessketten bei einem Business Process Reengineering-Projekt in Sparkassen geht:

„Als ein erhebliches Problem sowohl in der Aufgabenbearbeitung als auch in der Umsetzung stellt sich die momentane Dokumentation der Geschäftsprozesse dar. Die ARIS-Prozessketten erweisen sich dabei als völlig ungeeignet, insbesondere in der Arbeit in Projektteams. Nur prozessgeschulte Mitarbeiter kommen mit der vorliegenden Aufbereitung zurecht. Für die Einweisung und Schulung der Mitarbeiter im Marktbereich liegt bisher keine geeignete Dokumentation vor“ [Jan03, S. 187].

Hier könnten die Prozessberater die Linienverantwortlichen sicherlich unterstützen, damit ein gemeinsames Prozessverständnis bei allen Mitarbeitern gegeben ist. Ob es eine gute Lösung ist, alle Prozesse wie im Sparkassen-Beispiel in PowerPoint-Folien aufzubereiten, sei dahin gestellt. Mit einem Drei-Stufen-Modell veranschaulichen Abolhassan [Abo05, S. 377f.] und Jost [Jos05] wie die Prozessorganisation in einem Unternehmen verankert werden soll (Vgl. dazu Abbildung 6.1):

1. Die oberste Ebene ist die Ebene des C-Level-Managements. Auf ihr sind z.B. der CEO, CFO oder COO angesiedelt. Dass die Vorstandsebene vom Geschäftsprozessmanagement überzeugt ist, sieht Abolhassan als Grundvorraussetzung an. Ideal wäre das Einrichten einer CPO-Position, um die Bedeutung des Geschäftsprozessmanagements für das Unternehmen zu unterstreichen. Des Weiteren ist der CPO zuständig für „die generelle Ausrichtung des Geschäftsprozessmanagements, die Konzeption und Einführung von Methoden, Tools und Plattformen“ [Abo05, S. 377].

2. Auf der zweiten Ebene laufen die Geschäftsprozesse ab. Diese Ebene ist, wie schon oben angesprochen, dezentralisiert. Der CPO hat nur Sorge zu tragen, dass das dezentral vorhandene Wissen über die Prozesse zentral zur Prozessverbesserung genutzt werden kann und allen Prozess-Ownern zur Verfügung steht. Dies kann z.B. über die oben angesprochenen Prozessberater geschehen.

3. In der untersten Modellebene schließt sich der Kreislauf, „die Ergebnisse der Geschäftsprozesse werden erfasst, ausgewertet und für Korrektur- und Steuerungsentscheidungen aufbereitet. Hier zeichnen sich technologische Entwicklungen ab, mit denen die Ebenen 2 und 3 verschmelzen und zu neuen Architekturen führen“ [Abo05, S. 378]. Jost spricht hier auch von einer Bündelung von EAI- und Workflowsystemen, die anschließend mit SAPs Netweaver vereint werden [Jos05].

73

6.2.3 Verantwortung

Da der CPO aus dem CIO hervorgeht, bleibt der Verantwortungsbereich des CIOs gleich. Wie sich die Verantwortung bei den neu hinzugekommenen Bereichen gestaltet, ist schwer zu sagen. Bei Abolhassan z.B. ist der Verantwortungszuwachs des CPOs gegenüber des CIOs sehr unscharf formuliert ³ : „Damit verbunden ist eine Ausweitung des Verantwortungsbereichs, denn Marktänderungen, Wettbewerbsanforderungen, technologische Entwicklungen verlangen ein permanentes Umstrukturieren der Geschäftsprozesse und das wiederum erfordert mehr Kompetenzen als lediglich die Verantwortung für die IT-Systeme“ [Abo05, S. 379].

Überlegungen lassen sich aber z.B. über die Prozessberater anstellen: Da diese hierarchisch den Linienverantwortlichen unterstellt werden, kann der CPO nicht die ganze Verantwortung für die Prozessberater tragen. Da sie ihm aber funktional unterstellt sind, dürfte er ihnen gegenüber eine Teilverantwortung haben, die sich zumindest auf die Vorgaben erstreckt, die der CPO den Prozessberatern macht. In diese Verantwortung dürften z.B. Fragen der Prozessgestaltung oder der Weiterbildung von Mitarbeitern im Geschäftsprozessmanagement fallen. Ebenso trägt er mindestens eine Teilverantwortung für die automatisierten Geschäftsprozesse und all jene Geschäftsprozesse, in deren Ausführung die IT involviert ist. Es wird allerdings schnell deutlich, dass eine genaue Festlegung von Aufgaben, Kompetenzen und Verantwortung im konkreten Fall sehr schwierig sein kann, wenn sie dem Kongruenzprinzip genügen soll.

6.2.4 Anforderungen

Jost betont immer wieder, dass der CPO sich mehr der Betriebswirtschaft hinwenden sollte als der CIO (Vgl. z.B. [Jos05] und [Jos06]), da das Geschäftsprozessmanagement zunehmend an Bedeutung gewinne [Jos05]. Neben der Betriebswirtschaft werden noch vier weitere Anforderungen von Abolhassan und Jost an den CPO gestellt:

1. Kommunikationsfähigkeit. Nur wenn es der CPO schaffe, externe wie interne Partner miteinzubeziehen, kann er erfolgreich den Wandel erreichen. Abolhassan zitiert dabei eine Studie, nach der amerikanische CIOs nur 15% ihrer Zeit auf Gespräche mit den eigenen Mitarbeitern verwenden. Dass die Kommunikationsfähigkeit wichtig ist, zeigte auch schon Kapitel 3.

2. Prozessdenken ist wichtig, damit der CPO die Wertschöpfungskette, in die sein Unternehmen integriert ist, sowohl aus betriebswirtschaftlicher wie technischer Sicht mit ihren ganzen Abläufen versteht.

3. Über Sozialkompetenz sollte der CPO verfügen, da er mitunter viele Veränderungen im Unternehmen durchführen muss. Jost spricht hier auch vom CPO als

³ Dies soll keine Kritik darstellen, da ja auch z.B. CIO-Organisationen, wie Kapitel 3 zeigte, sehr unterschiedlich organisiert sind.

74

Change Agent des Unternehmens. Bei diesen Veränderungen ist z.B. Menschenkenntnis gefragt, wenn es um die Zusammensetzung von Teams oder die Benennung von Geschäftsprozessverantwortlichen geht.

4. Unter Motivation und Innovationsfreude versteht Abolhassan: der „CIO der Zukunft [sollte] die komplette Organisation, von der Produktion, über Marketing und Vertrieb bis zum Management, in Echtzeitstimmung [...] versetzen und eine permanente Optimierungsleidenschaft [...] implementieren“ [Abo05, S. 380].

75

7 Der CPO nach Schmelzer und

Sesselmann

Die beiden Autoren definieren einen sehr stark auf das Geschäftsprozessmanagement ausgerichteten CPO und liefern das organisatorisch durchdachteste CPO-Konzept.

7.1 Allgemeine Vorstellungen

Der CPO nach Schmelzer und Sesselmann ist in einem „Unternehmen zentral verant-wortlich für das Geschäftsprozessmanagement“ [SS06, S. 133]. Andere Bezeichnungen wären etwa Prozesskoordinator oder Leiter der Stabsstelle Prozessmanagement. Die Einführung eines Geschäftsprozessmanagements übernimmt hingegen ein Geschäftsprozessmanagement-Projektleiter, der dabei von Prozessberatern ¹ unterstützt wird. Nach der erfolgreichen Einführung des Geschäftsprozessmanagments wird ein CPO eingesetzt, der sich „für die Weiterentwicklung und Integration des gesamten Geschäftsprozessmanagement-Systems“ [SS06, S.130] verantwortlich zeichnet. Optimalerweise nimmt der Geschäftsprozessmanagement-Projektleiter die Position des CPOs ein. Es ist auch möglich, dass einer der Prozessberater die Rolle des CPOs übernimmt. So wird sichergestellt, dass der zukünftige CPO mit dem Unternehmen und dem Geschäftsprozessmanagement-System vertraut ist. Nach Schmelzer und Sesselmann sollte der CPO allerdings nicht aus dem CIO hervorgehen oder ihm zugeordnet werden. Gleiches gilt für das Qualitätsmanagement. Die Autoren sehen die Gefahr, dass dann IT- oder Qualitätsfragen eine zu große Rolle spielen könnten und so wichtige Geschäftsprozessmanagementaufgaben überdecken.

Durch die Einrichtung mehrerer Gremien wird die Umsetzung von Maßnahmen in der neuen CPO-Organisation sichergestellt (Vgl. dazu Abbildung 7.1):

• Geschäftsprozessmanagement-Control Board: In diesem Board stimmt der CPO das Geschäftsprozessmanagement mit den Leitern der einzelnen Geschäftseinheiten ab. Dazu werden gemeinsame Standards festgelegt und empfohlen. Es kann aber auch um die Einbindung des Geschäftsprozessmanagement-Systems in andere Managementsysteme wie das Qualitätsmanagement gehen. Es werden auch

¹ Die Prozessberater von Schmelzer und Sesselmann unterscheiden sich geringfügig von den Prozessberatern bei Abolhassan und Jost in Punkt 6.2.2. Während die Prozessberater aus 6.2.2 die Linienchefs bei einem schon etabliertem Geschäftsprozessmanagement unterstützen, sind mit den Prozessberatern dieses Kapitels vor allem Berater gemeint, die die Einführung des Geschäftsprozessmanagement-Systems begleiten. Schmelzer und Sesselmann empfehlen, dass man als Prozessberater in erster Linie Leute aus dem eigenen Unternehmen einsetzt, damit das aufgebaute Geschäftsprozessmanagement-Know-How nicht nach der Einführung des Geschäftsprozessmanagement-Systems wieder abwandert [SS06, S. 132].

76

Abbildung 7.1: Prozessgremien innerhalb eines Betriebes. GPM steht für Geschäftsprozessmanagement. Eigene Darstellung nach: [SS06, S.130]

neue Ziele vereinbart und die „Ergebnisse von Reviews und Assessments des Geschäftsprozessmanagementsystems“ [SS06] bewertet. In erster Linie geht es aber darum, eine Plattform auf hoher Ebene für Probleme mit dem Geschäftsprozessmanagement zu haben, damit Lösungen schneller vorangetrieben werden.

• Im Managementteam sind die Geschäftsleitung, der CPO, die Funktionsleiter und die Geschäftsprozessverantwortlichen eines Unternehmens vertreten (in größeren Unternehmen gibt es Managementteams für die einzelnen Geschäftseinheiten). Dieses Team leitet aus der Balanced Scorecard die Ziele für das Geschäftsprozessmanagement ab, schlichtet Konflikte zwischen Geschäftsprozessen und Funktionen, initiiert Business Process Reengineering-Projekte, bewertet Geschäftsprozesse, führt neue ein und sortiert andere aus. Dieses Team ist insbesondere dann nötig, falls „Geschäftsprozesse und Funktionsorganisation nebeneinander existieren“ [SS06, S. 143].

• Prozessteam: Dieses Team ist das Managementteam des Geschäftsprozesses. In ihnen berät der Geschäftsprozessverantwortliche mit den Teilprozessverantwortli-

77

chen über Fragen, die den Geschäftsprozess betreffen. Abhängig von den Teilprozessen, hat das Prozessteam fünf bis acht Mitglieder.

• KAIZEN-Team: Setzt sich mit der kontinuierlichen Verbesserung einzelner Teilprozesse und Prozessschritte auseinander. Dazu werden die Kaizen-Techniken verwendet [SS06].

Ein wichtiges Ziel des CPOs ist sicherlich das Vorantreiben der Integration von Geschäftsprozessen in die Organisation. Also der Wandel des Unternehmens hin zur reinen Prozessorganisation, um die Verantwortungswechsel innerhalb der Geschäftsprozesse zu reduzieren, damit Koordinations- und Kommunikationsprobleme besser vermieden werden können [SS06, S. 124].

Nach einer Studie der FH Bonn-Rhein-Sieg und der Unternehmensberatung ACRYS CONSULT befürworten nur 26% (Gesamt), bzw. 28% (Finanzdienstleister) der Befragten, dass der Gestaltung von Geschäftsprozessen eine höhere Priorität zukommen sollte als der Aufbauorganisation. Die meisten entschieden sich mit 54% (Gesamt), bzw. 51% (Finanzdienstleister) für ein Gleichgewicht zwischen Geschäftsprozessen und Aufbau-organisation [CON05] und damit für eine Prozess-Matrix. Um die Akzeptanz für eine Prozessorganisation zu erhöhen, empfehlen Schmelzer und Sesselmann daher zu Recht, dass zuerst erst eine Matrix-Prozessorganisation eingeführt werden sollte. Wenn sich diese etabliert hat, könne dann der Wandel von der Matrix-Prozessorganisation hin zur reinen Prozessorganisation angegangen werden [SS06, S. 154] ² .

7.2 Aufgaben, Kompetenzen, Verantwortung und

Anforderungen

7.2.1 Aufgaben

Als eine der wichtigsten Aufgaben des CPOs wird das Entwickeln und Umsetzen eines unternehmensspezifischen Prozessmodells angesehen [SS06, S. 134]. Dieses Modell legt fest „wie Geschäftsprozesse im Unternehmen zu definieren“, strukturieren, dokumentieren und implementieren sind [SS06, S. 134]. So wird in ihm auch festgehalten

² Schmelzer und Sesselmann sind Befürworter einer reinen Prozessorganisation. An anderer Stelle schreiben sie:

„häufig [sind] Führungskräfte und Mitarbeiter noch nicht auf ihre Aufgaben und Verant-wortung in Prozessorganisationen vorbereitet. Ausnahmen bilden Fertigung und Logistik, für die Prozessorientierung in den meisten Fällen Realität ist. Handlungs- und Nachholbedarf haben dagegen Marketing, Vertrieb, Forschung und Entwicklung, Service und kaufmännisches Controlling. Ihnen fällt es schwer, sich mit dem Geschäftsprozessmanagement anzufreunden“ [SS06, S. 72 f.].

Prozessorientierung ist allerdings nicht immer sinnvoll. So überwiegen z.B. bei Abteilungen wie der Forschung und Entwicklung meist die Spezialisierungsvorteile [Reb97, S. 275 f.], [All05, S. 15f.]. Vgl. auch das Fazit (Kapitel 10)

78

„welche Verantwortliche[n], Aufgabenträger und Gremien“ eine Rolle im Geschäftsprozessmanagement spielen und wie man beim Optimieren und Controlling von Prozessen vorzugehen hat.

Ein solches Unternehmensprozessmodell sollte immer für jedes einzelne Unternehmen entwickelt werden. Entweder leitet man dafür aus einem Referenzmodell ein Modell ab oder man entwickelt ein eigenes. Ein solches Modell umfasst „Standards, auf deren Basis die Geschäftsprozesse in den Geschäftseinheiten eines Unternehmens festgelegt werden“ [SS06, S. 209]. Ein solches Modell zeigt Abbildung 7.2. Auf Ebene 0 wird kate-gorisiert nach Prozessklassen (z.B. Managementprozesse, operative Geschäftsprozesse, primäre/sekundäre Prozesse), die wiederum Prozessgruppen enthalten (z.B. „operative Geschäftsprozesse“ enthält die Prozessgruppen CRM, SCM etc.). Auf den nächst tieferen Ebenen werden diese Kategorien dann weiter aufgegliedert. Prozessgruppen enthalten Geschäftsprozesse und Geschäftsprozesse bestehen wiederum aus Teilprozessen. In der dritten Ebene werden Prozessvarianten für die versch. Teilprozess- oder Prozessschrittebenen festgelegt. Alle weiteren Ebenen sind dann von den einzelnen Geschäftsbereichen zu spezifizieren. Der CPO trägt dafür Sorge, dass die Geschäftsprozesse nach dem Unternehmensprozessmodel standardisiert und harmonisiert werden. Des Weiteren organisiert der CPO Trainings für die Zielgruppen des Geschäftsprozessmangement, koordiniert und konzipiert unternehmensübergreifende Geschäftsprozesse, vertritt das Unternehmen in externen Gremien des Prozessmanagement, organisiert und leitet das Geschäftsprozessmanagement-Control Board, stimmt die IT-Strategie mit der Prozessstrategie ab, „übernimmt das Assessment des unternehmensweiten Geschäftsprozessmanagements [und führt] unternehmensweite Leistungsvergleiche und Benchmarks der Geschäftsprozesse“ [SS06, S. 135] durch.

7.2.2 Kompetenzen

Anders als bei den CPOs, die in den zwei vorangegangenen Kapiteln besprochen wurden, übernimmt dieser CPO nicht die Aufgaben, Kompetenzen und die Verantwortung des CIOs. Dieser CPO lässt sich daher isoliert von anderen Funktionen betrachten. Der Kompetenzbereich dieses CPOs wird aus dem weiter oben Behandelten deutlich. Zu ihm zählt die Entwicklung eines Unternehmensprozessmodells, die Leitung des Geschäftsprozessmanagement-Control Boards und die Trainings für Mitarbeiter. Je nach dem wie ausgeprägt die Prozessorganisation ist, schrumpft oder wächst die Bedeutung des CPOs. Das Unternehmensprozessmodell und die Zuständigkeiten bleiben zwar gleich, aber die Bedeutung der Prozessverantwortlichen wächst, je stärker die Geschäftsprozesse in die Organisation integriert sind. Tabelle 7.1 zeigt, welche Verant-wortung die Prozessverantwortlichen je nach Integrationsgrad der Geschäftsprozesse in der Organisation haben.

Je nach Größe des Unternehmens empfehlen die Autoren den Einsatz von CPOs in den einzelnen Unternehmensbereichen. Hier ist dann die Frage zu klären, ob hier dann wirklich dezentralisiert wird und die einzelnen CPOs in ihren Unternehmensbereichen z.B. jeweils eigene Unternehmensprozessmodelle ausarbeiten sollten. Des Weiteren ist zu beachten, dass „[d]ie formale Kompetenzausstattung [...] wenig [nutzt], wenn auf or-

79

Tabelle 7.1: Verantwortung in der Prozessorganisation. Diese Darstellung geht davon

7.2.4 Anforderungen

Nach Sesselmann und Schmelzer sollte der CPO ein Studium der Betriebswirtschaftslehre, des Wirtschaftsingenieurwesens oder der Wirtschaftsinformatik an einer Universität oder einer Fachhochschule absolviert haben oder über eine vergleichbare Ausbildung

81

verfügen. Darüber hinaus sollte er Kenntnisse im Qualitätsmanagement, Prozessmanagement sowie der strategischen und operativen Planung haben. Im Bereich des Geschäftsprozessmanagements sollte er schon Erfahrungen gesammelt haben als Prozess-verantwortlicher, Prozessberater oder Geschäftsprozessmanagement-Projektleiter. Außerdem ist es wichtig, dass er bereits Erfahrungen als Moderator, Coach und Trainer hat. Zu guter letzt sollte er analytisch und konzeptionell denken können, anpassungsfähig sein, sich gut integrieren und kommunikativ sein [SS06, S. 135].

82

8 Erste CPOs

In diesem Kapitel sollen CPOs vorgestellt werden, die sich möglichst den besprochenen CPOs der drei vorangegangenen Kapitel zuordnen lassen. Ein CPO, der wirklich exakt einem der besprochenen CPO-Konzepte entspricht, wurde nicht gefunden. Da viel des hier Besprochenem auf Success-Storys o.ä. beruhen kann, ist mangelnde Objektivität in diesem Kapitel nicht auszuschließen. Oftmals haben CPOs auch nicht ansatzweise die Kompetenz und Verantwortung, die ihnen in den drei besprochenen CPO-Konzepten zugestanden wird. Auch sollte bei Vergleichen das Kürzel des Chief Process Officers nicht mit dem des Chief Purchase Officers oder des Chief Product Officers verwechselt werden.

8.1 CPOs nach Schmelzer und Sesselmann

CPOs, die dem CPO von Schmelzer und Sesselmann nahe kommen, sind am verbreitesten. Das beste Beispiel für einen CPO stellt sicher Richard Butler von Electrocomponents dar. 2000 wurde er zusammen mit Ian Mason in das Board des Unternehmens aufgenommen. 2001 wurde er CPO und Mason COO. 2002 wurde Mason CEO und die alte COO-Funktion von Mason wurde aufgelöst. Während Butler 2001 noch die Kerngeschäftsprozessfunktion (core business process function) inne hatte, wurde 2002 sein Kompetenz- und Verantwortungsbereich auf alle Kern- und Unterstützungsprozesse des Unternehmens ausgedehnt ¹ [Har03]. Seit 2002 war Butler außerdem Mitglied des „Group Executive Directors’ Committee“ [Ele02] und seit 2003 zusätzlich Mitglied im „Treasury Committee“ [Ele03]. Butler ist damit organisatorisch sogar an einer höheren Stelle aufgehangen als von den drei besprochenen CPO-Konzepten empfohlen. Die Stelle ist vergleichbar mit der eines Vorstandes in Deutschland. Im Juni 2005 kündigte allerdings Richard Butler bei Electrocomponents und die Position des Chief Process Officers wurde nicht neu besetzt [Ele06] ² .

¹ Unter der folgenden URL findet man Butlers CPO-Report von 2003: http://www.ir.electroc omponents.com/electrocomponents/storage/annrep03/chiefsprocess.pdf, Letzter Zugriff am 02.11.06.

² In einer öffentlichen Bekanntmachung heißt es dazu:

„To drive forward our strategy and ensure that the programme is delivered within the 3year time frame, Electrocomponents is reorganising its internal management structures. As a consequence of this reorganisation the role of Chief Process Officer, an Executive Director role fulfilled by Richard Butler, will cease to exist.

Richard has played a major role in the evolution of our strategy and fully supports these changes. As his role is now nearing completion, Richard has tendered his resignation from the Board and will leave the Board on 30 June 2005“ [Ele05].

83

Ebenfalls einen Chief Process Officer hat Borland mit Bill Curtis ernannt [Bor06]. Curtis sagt, dass der klassische CPO zwischen CIO und den Geschäftseinheiten sitze und Workflows bereichsübergreifend integrieren würde. Curtis sieht sich daher als Klebstoff zwischen den Geschäftsprozessen einer Organisation und der IT [Tyn05, S. 15]. Dafür muss er sowohl die Sprache der IT als auch die der BWL beherrschen:

„The critical role is to integrate the two worlds inside the company - the side that wants to move forward with Six Sigma and continuous improvement, and the side that wants to go in with large-scale automation systems [such as] SAP and Oracle[.] You’ll often find that both worlds aren’t talking to each other“ [Tyn05, S. 15].

Inwiefern Curtis dem CPO nach Schmelzer und Sesselmann nahe kommt, ist schwer zu sagen. Die meiste Zeit arbeitet Curtis von zu Hause aus oder besucht die IT-Abteilungen von Borlands Kunden um sicherzustellen, dass die IT-Abteilungen die gleichen professionellen Geschäftsprozesse wie im restlichen Unternehmen integrieren.

8.2 CPO nach Schmidt, Seidel, Abolhassan und Jost

Klaus-Hardy Mühleck ist CIO des Volkswagen Konzerns. Er soll hier als Beispiel für einen CPO dienen, der zwischen den CPO-Konzepten aus Kapitel 5 und 6 anzusiedeln ist. Mühleck begann seine Karriere als Elektroingenieur bei Siemens und wechselte später zu Mercedes. Bei Mercedes hatte er zuletzt die Position eines Bereichs-CIO inne. 2001 wurde er CIO der AUDI-Group und setzte dort in der ersten Markensparte VWs eine IT-Strategie um, die er zusammen mit Schacher, dem damaligen VW-CIO, entwickelte. 2004 ging Schacher in den Ruhestand und Mühleck wurde CIO des Volkswagen-Konzerns. Seitdem setzt er die AUDI-Strategie in den anderen Sparten des Konzerns um und entwickelt sie weiter. Diese „Strategie steht auf drei Standbeinen“ [Com05b]:

• Dies ist zum einen die Standardisierung der VW-IT, d.h. dass die unterschiedlich gewachsenen IT-Landschaften des Konzerns vereinheitlicht werden und man auf Eigenentwicklungen verzichtet.

• Zudem sollen die Geschäftsprozesse der einzelnen Marken- und Ländergesellschaften vereinheitlicht ³ werden, um so die Effizienz zu steigern. Zusätzlich sollen integrative Systeme bereitgestellt werden.

• Und drittens möchte man „Wertschöpfungsbeiträge durch die Einführung innovativer IT-Systeme für CRM oder Forecast-Management an der Schnittstelle zu den Zulieferern realisieren.“

³ Wieweit dies in der Praxis betrieben wird, ist unklar. Schließlich ist die Betreuung eines Bentley-Kunden etwas anderes als die eines VW-Kunden. Vielleicht ist auch nur ein einheitlicher Geschäftsprozessstandard gemeint.

84

8.2.1 Veränderung der CIO-Organisationsstruktur

Die Idee für die Umgestaltung der CIO-Organisation lässt sich teilweise bis 2002 zurückverfolgen. Seit Ende 2002 steht IT bei AUDI für Integrations-Technologie [Onl04a]. Dies erinnert an Schmidt und Seidels alternative Bezeichnung für den CPO, den Chief Integration Officer („to avoid creating a new acronym“) [SS01]. 2004 war die neue Organisation noch nicht fertig. Das sieht man z.B. daran, dass die Rolle des „process owners“ (Prozessverantwortlicher) noch nicht definiert war [Onl04a]. Dies hat sich seit mindestens Mitte 2005 geändert. Die neue CIO-Konzern-Organisationsstuktur gleicht zwar auf den ersten Blick dem Aufbau der CIO-Organisationsstruktur bei AUDI [Müh02], die ja auch auf den restlichen VW-Konzern übertragen werden sollte, wurde aber um einige Rollen erweitert (Abbildung 8.1 zeigt die neue CIO-Organisation des VW-Konzerns). Dies ist vor allem die Rolle des Chief Technology Officers und die der Process Integration Officers. Der Chief Technology Officer ist in erster Linie technisch versiert. Er beobachtet den IT-Markt und ist für 14 sogenannte IT-Kompetenzfelder zuständig (z.B. serviceorientierte Architektur und Business Intelligence). Der Chief Technology Officer legt zudem die konzernweiten Technologiestandards fest [Com05d]. Die Aufgaben des Process Integration Officer beschreibt Mühleck wie folgt:

„Wir haben vier Process Integration Officers (PIOs) etabliert, die für die konzernweit definierten Kernprozesse sowohl die Prozesslandschaften als auch die IT-Systemportfolios verantworten. Die PIO-Struktur basiert auf insgesamt 21 Fachkompetenzfeldern. Im PIO-Bereich Produktionsprozesse gibt es beispielsweise die Fachkompetenzfelder CAD/CAM, virtuelle Techniken zur Fahrzeugentwicklung und Stücklisten-Management. Im Bereich Kundenauftragsprozess sind das unter anderem die Stücklistenauflösung und die Fabriksteuerung. Diese Kompetenzfelder wurden für den gesamten Konzern

85

Tabelle 8.1: IT-Ausgaben von Volkswagen im Vergleich zu anderen Unternehmen. *Quel-

definiert, sind aber jeweils in einer Marke beheimatet. Dadurch stellen wir sicher, dass die Prozess- und Systemarbeit einheitlich läuft und nicht jeder Unternehmensbereich seine eigene Systemwelt aufstellt.“[Com05d]

Es fällt dabei auf, dass die Themen in erster Linie technischer Natur sind, aber mit den Werkzeugen des Geschäftsprozessmanagement angegangen werden. Eine komplette Prozessunterstützung des VW-Konzerns durch Mühleck lässt sich nicht feststellen, es ist aber vorstellbar, dass er das in der IT-Abteilung mit Geschäftsprozessmanagement gesammelte Know-How später auch für Geschäftsprozessmanagement in anderen Bereichen einsetzen kann. Sehr erfolgreich ist Mühleck mit seiner drei Säulen-Strategie bei AUDI gewesen. Die VW-Tochter gilt mittlerweile als Benchmark in der Branche was die IT-Ausgaben betrifft (Vgl. Tabelle 8.1). So liegen die IT-Kosten pro Auto bei 200-250 Euro. Auch das IT-Budget liegt bei AUDI mit 0,77% vom Umsatz (2004) besonders niedrig. Zwar zeigten die IT-Produktivitätsstudien, die in Kapitel 2 behandelt wurden, dass IT-Kosten nicht mit Produktivität in Verbindung stehen müssen, einige weitere Faktoren bei AUDI lassen aber darauf schließen, dass die IT recht effizient eingesetzt wird. So hat Mühleck schon zu Beginn seiner CIO-Laufbahn bei AUDI eine umfangreiche IT-Qualifizierungsmaßnahme durchgeführt, die z.B. mit dem „Initiativpreis für Aus- und Weiterbildung“ der Otto Wolff von Amerogon-Stiftung und dem „Weiterbildungsaward 2002“ der Zeitschrift „management & training“ ausgezeichnet wurde [Müh02]. Die IT-Qualifizierungsmaßnahme wurde für alle 44 000 Mitarbeiter („von der Produktion bis ins Top-Management“) der Werke Ingolstadt und Neckarsulm durchgeführt. Dies sind weit über 80% aller Mitarbeiter der AUDI AG.

86

Weitere Indizien für eine effiziente IT-Nutzung könnte das Verhältnis Mühlecks zu anderen AUDI-, bzw. VW-Managern sein. Legt man die Ergebnisse der Stichproben aus Kapitel 3 zugrunde, die sich mit der CEO/CIO-Beziehung beschäftigten, so müsste es eine gute Beziehung zwischen ihm und den Vorstandsvorsitzenden von AUDI gegeben haben ⁴ . Zumindest die Akzeptanz der IT konnte Mühleck bei AUDI steigern, in einem Interview meinte er dazu: „Mittlerweile sind wir nicht nur ein Ansprechpartner bei IT-Umsetzungsprojekten im Unternehmen, wir werden auch zunehmend als gleichberechtigter Partner zu den automobilen Kernkompetenzen wie Entwicklung, Logistik, etc. wahrgenommen“ [Onl04b]. Nach eigenen Angaben genießt Mühleck auch beim VW-Vorstand vollstes Vertrauen. Auf die Frage, ob es leicht war, den Prozessgedanken beim Vorstand zu etablieren, antwortete er in einem Interview:

„Hier erfahre ich volle Unterstützung durch den Vorstand. Er will die IT nicht nur für die Kostenreduzierung einsetzen, sondern sich darüber hinaus auch vom Wettbewerb differenzieren. Ich habe engen Kontakt zum Vorstand und bin seit 1. Juli auch Mitglied der Konzernleitung. Das war eine große Anerkennung für mich. Ich bin seit 24 Jahren in der Automobilbranche tätig, mit dem Thema Prozessorientierung befasse ich mich schon seit 1988. Irgendwann hatte ich es fast aufgegeben und mich gefragt, ob es die Branche schaffen würde, dieses Potenzial zu erkennen. Im Volkswagenkonzern darf ich nun erleben, dass diese Disziplin wirklich ernst genommen und die Weichen richtig gestellt werden.“ [Com05d]

8.2.2 Das Geschäftsprozessmodell bei VW

Das Geschäftsprozessmodell des Volkswagen-Konzerns besteht in der Hauptsache aus drei Kernprozessen. Diese werden durch „Steuerungs[aktivitäten] und unterstützende Aktivitäten“ flankiert [Müh05, S. 30]. Abbildung 8.2 stellt diese Aktivitäten als Managementprozesse dar. „Innerhalb [der] Kernprozesse geht es um die Bündelung der wertschöpfenden Prozesse von der Fahrzeugentwicklung, über die Beschaffung, den Produktionsprozessen und der Logistik bis hin zur Vermarktung der Produkte“ [Müh05, S. 30]. Als nicht gerade einfach gestaltet sich dabei das Optimieren von unternehmensübergreifenden Geschäftsprozessen. Ein wichtiges Ziel für Mühleck ist dabei die Integration der Partner in die Gesamtprozesskette. Eine Rolle spielt dabei z.B. die ehemalige VW-Tochter Gedas, die nun zur T-Systems gehört und das Gros ihres Umsatzes mit IT-Dienstleistungen für VW bestreitet [Com05c]. Damit das Geschäftsprozessmanagement im VW-Konzern in geordneten Bahnen abläuft, hat man zum einen einen Vorstandsausschuss für Prozesse gegründet. Darüber hinaus gibt es mehrere sogenannte „Process-Councils“. Diese Strukturierung erinnert sehr an Schmelzer und Sesselmanns verschiedene Gremien. Um das Geschäftsprozessmanagement auch „[i]nnerhalb der CIO-Organisation

⁴ Da Winterkorn zum 01.01.07 den Vorstandsvorsitz von Volkswagen übernimmt, dürfte es bei Volkswagen zumindest weiterhin eine gute CEO/CIO-Beziehung geben.

87

Abbildung 8.2: Prozessorganisation bei AUDI aus dem Jahr 2002. Da Mühleck die glei-

88

9 Vergleich und Bewertung der

einzelnen Konzepte

In diesem Kapitel sollen die drei CPO-Konzepte einem Vergleich und einer Bewertung unterzogen werden. Anschließend werden die Vorteile und Nachteile der Institutionalisierung des Geschäftsprozessmanagements durch einen CPO behandelt (Punkt 9.2.1). In Punkt 9.2.2 wird der Frage nachgegangen, wann welcher CPO ernannt werden sollte.

9.1 Vergleich der Konzepte

Um den Vergleich der drei CPO-Konzepte anschaulicher zu machen, habe ich die Konzepte zusammen mit zwei anderen IT-Management-Konzepten in einem dreidimensionalen Raum eingeordnet. Diese Einordnung ist natürlich willkürlich und soll nur zeigen wie ich die verschiedenen Konzepte relativ zueinander einschätze. Die zwei anderen Konzepte sind die des Data-Processing-Managers und des CIOs. Synnott (Vgl. Kapitel 3) ordnete diese Konzepte nach der 80/20-Regel der Betriebswirtschaft und der IT zu [Syn87, S. 31]. Der CIO beschäftigt sich also zu 80% mit der Betriebswirtschaft und zu 20% mit IT, beim DP-Manager ist es genau anders herum.

Tabelle 9.1: Vergleich der unterschiedlichen CPO-Konzepte.

Diesen dreidimensionalen Raum zeigt Abbildung 9.1. Er gliedert sich in die drei Dimensionen IT, Geschäftsprozessmanagement und Betriebswirtschaft. Da sich Synnott nur auf die IT und die Betriebswirtschaft bezog, werden der DP-Manager und der CIO nur innerhalb dieser zwei Dimensionen angesiedelt. Heute würde Synnott sicherlich

89

auch dem Geschäftsprozessmanagement eine größere Rolle zumessen. Alle anderen CPO-Konzepte werden wie der CIO und DP-Manager strikt so zwischen der IT und BWL aufgeteilt, dass die Summe aus beiden 100 ergibt. Dem Geschäftsprozessmanagement kommt daher eine besondere Rolle zu, da man das Geschäftsprozessmanagement sowohl der IT als auch der Betriebswirtschaft zuordnen kann. Deshalb wurde darauf verzichtet, dass die Summe aus IT, BWL und Geschäftsprozessmanagement 100 ergeben muss. Kurz: die dritte Dimension soll nur zeigen inwieweit sich der jeweilige CPO mit Geschäftsprozessmanagement beschäftigt. Im folgenden soll erklärt werden, warum die CPOs so einge-ordnet wurden wie sie eingeordnet sind:

CPO nach Schmidt und Seidel: Durch den recht technischen Fokus von Schmidt und Seidel, wird dieser CPO genau zwischen der BWL und IT angesiedelt. Bei diesem CPO besteht die Gefahr, dass er Geschäftsprozessmanagement zu sehr nur als IT-Aufgabe auffasst, wenngleich Schmidt und Seidel zumindest bei der Implementierung von Geschäftsprozessen einen sehr pragmatischen Ansatz zeigen. Der aber auch nötig ist, da Schmidt und Seidel ihren CPO in erster Linie aus ihrer Erfahrung heraus konstruierten, die sie in IT-Projekten sammelten. Zumindest Schmidt hat viele große EAI-Projekte bei verschiedenen Unternehmen geleitet. Dadurch ist auch erklärbar, weshalb Schmidt und Seidels CPO für die Implementierung oder Ablösung von Geschäftsprozessen (Geschäftsprozesse hier im Sinne vollautomatisierbarer Prozesse) zuständig ist. Als IT-Projektleiter wollen Schmidt und Seidel vermutlich eine schnelle und kontrollierbare Integration der Geschäftsprozesse. Das Geschäftsprozessmanagement wird bei diesem CPO niedriger als bei den anderen eingestuft. Auch wenn der Unterschied zwischen diesem CPO und dem von Abolhassan und Jost sehr schwammig ist. Dennoch meine ich bei Schmidt und Seidel die geringste Betonung der Kundenorientierung von Geschäftsprozessen festzustellen.

CPO nach Abolhassan und Jost: Da Jost immer wieder betont, dass für den CIO der Zukunft betriebswirtschaftliche Aspekte immer wichtiger werden (Vgl. dazu Punkt 6.1), wurde der BWL ein deutlich größeres Gewicht als der IT zugesprochen. Allerdings wurde dabei nicht vom CIO-Konzept Synnots ausgegangen, da sich Jost und Abolhassan nicht auf diesen CIO beziehen. Auch das Geschäftsprozessmanagement siedelte ich höher als bei Schmidt und Seidels CPO an.

CPO nach Schmelzer und Sesselmann: Diesem CPO wird ein besonders großer Bereich in der BWL zugesprochen, da die Autoren empfehlen, dass der CPO nicht dem CIO zugeordnet werden sollte. Da der CPO dennoch in regelmäßigem Kontakt mit dem CIO stehen muss, um zu sichern, dass die IT die Geschäftsprozesse unterstützt, muss sich auch dieser CPO mit IT-Themen auseinandersetzen, die über den üblichen IT-Gebrauch hinausgehen. Der Bereich des Geschäftsprozessmanagements ist natürlich bei diesem CPO besonders ausgeprägt, da er sich in erster Linie wirklich nur mit Geschäftsprozessmanagement beschäftigt.

90

Abbildung 9.1: Die Abbildung zeigt die Einordnung der drei behandelten CPO-Konzepte

9.2 Einsatz der Konzepte

In den folgenden Unterpunkten sollen zwei Fragen behandelt werden, die von entscheidender Bedeutung für den Einsatz von CPO-Konzepten sind:

• Ist die Institutionalisierung des Geschäftsprozessmanagements in einem Unternehmen durch einen CPO sinnvoll?

• Sollte der CIO zum CPO werden oder sollte der CPO neben dem CIO als eigenständige Funktion etabliert werden?

9.2.1 Die Institutionalisierung des Geschäftsprozessmanagements

Man muss sich die Frage stellen, was die Stelle des CPOs so besonders macht, schließlich gibt es ja auch keinen Chief Functional Officer, also einen Verantwortlichen für die geordnete Organisationsgestaltung aller Funktionen nach einheitlichen Standards. Dies ist eigentlich Aufgabe des CEOs. In diesem Punkt geht es daher um die Frage, in welcher Form das Geschäftsprozessmanagement überhaupt institutionalisiert wird und welche Vor- und Nachteile eine Institutionalisierung des Geschäftsprozessmanagements durch einen CPO mit sich bringt.

Wie wird Geschäftsprozessmanagement in der Regel institutionalisiert?

Die Institutionalisierung des Geschäftsprozessmanagement im Unternehmen spielt in vielen Geschäftsprozessmanagement-Büchern bestenfalls eine untergeordnete Rolle. Oft wird nur die Rolle verschiedener Teams angesprochen, die selbstständig z.B. im Rahmen eines kontinuierlichen Prozessmanagements die Prozesse weiter vorantreiben und optimieren sollen. Auch der Prozessverantwortliche wird oft angesprochen. Eine allen Geschäftsprozessen übergeordnete koordinierende Funktion wird allerdings selten erwähnt. Während diese Funktion bei Business Reengineering-Projekten vom Projektleiter übernommen wird, scheint sie in der Literatur nach der Durchführung der Projekte zu entfallen. Daher lässt sich auch die momentane Situation innerhalb der Unternehmen schwer einschätzen. Aufschluss geben die Ergebnisse der in Kapitel 4 behandelten Studie der FH Bonn-Rhein-Sieg und der Unternehmensberatung ACRYS CONSULT (Vgl. Tabelle 4.4) [CON05]. Nach dieser Studie haben zumindest 25% aller Unternehmen eine übergeordnete Funktion über alle Geschäftsprozesse, wobei die drei vorgestellten CPO-Konzepte fast durchgängig mehr Aufgaben wahrnehmen. Ein anderes Bild wirft der Business Process Report 2005 auf [Gil05]. Nach ihm ist für das Geschäftsprozessmanagement in 57% aller Fälle der IT-Leiter, in 34% aller Fälle die Geschäftsführung und in weiteren 34% aller Fälle der Fachabteilungsleiter zentral für das Geschäftsprozessmanagement zuständig. In 20% aller Fälle ist unklar wer zuständig ist und in weiteren 29% und 11% ist der Prozessverantwortliche oder der Controlling-Leiter zuständig. Auch hier lässt sich

92

also nicht annähernd beziffern, in wie vielen Fällen tatsächlich das Geschäftsprozessmanagement zentral institutionalisiert ist. In 20% aller Fälle ist es überhaupt nicht zentral organisiert und in den restlichen Fällen könnten mehrere Bereiche oder Führungskräfte zuständig sein oder das Geschäftsprozessmanagement wird nur dezentral gehandhabt, falls z.B. nur Prozessverantwortliche zuständig sind.

Vorteile und Nachteile des CPOs

Die hier genannten Vor- und Nachteile sind unabhängig von den jeweiligen CPO-Konzepten zu verstehen. Ein Vorteil des CPOs ist sicherlich, dass durch ihn das Geschäftsprozessmanagement einen zentralen Ansprechpartner erhält und dass es durch verbindliche Standards in geordneten Bahnen ablaufen kann. Der Trend hin zur zentral organisierten IT (Vgl. Punkt 3.4) spricht ebenfalls für einen CPO, da einheitliche Prozessstandards und ein Unternehmensprozessmodell das Anpassen der IT an Prozesse erleichtern dürfte. Des Weiteren stellt der CPO sicher, dass bei zukünftigen Projekten, die die Prozessorganisation betreffen, auf einen „Pool von Vorgehensweisen, Instrumenten und Mitarbeiterwissen [...] zurückgegriffen werden kann“ [NPW02, S. 332]. Dieses Wissen zur Vorgehensweise würde sicherlich verloren gehen, wenn sich das Wissen über Geschäftsprozessmanagement durch fehlende Koordination in den einzelnen Divisionen verselbstständigt.

Außerdem kann ein CPO Prozessinteressen sicherlich besser durchsetzen als eine andere Form der Institutionalisierung des Geschäftsprozessmanagements. „[D]ie Praxis [zeigt] immer wieder, dass diese Querschnittsfunktion [die Funktion, die bereichsübergreifend für das Geschäftsprozessmanagement zuständig ist] von den Fachbereichen nicht akzeptiert wird und die Kompetenzen in der Regel nicht ausreichen, die Prozessinteressen auch gegen Bereichsinteressen durchzusetzen“ [FV06, S. 289]. Die ibo Beratung und Training GmbH kam bei ihren Prozessmanagement-Assessments zu dem Ergebnis, dass nur 15% aller Unternehmen „bei der Umsetzung ihrer Konzepte zur Prozessver-antwortung tatsächlich ihre Ziele“ erreichen [FV06, S. 289]. Auch gab nur „ein Drittel der Befragten bei den ibo-Assessments“ an, dass sie über ein Prozessmanagementsystem verfügen, dass sie kontinuierlich verbessern. Auch würden die Prozessmanager häufig nicht ausreichend geschult und es fehlt an einer standardisierten Vorgehensweise. Dies könnte durch eine CPO-Position, die dem Kongruenzprinzip genügt, sicherlich besser gestaltet werden.

Man könnte die Notwendigkeit für einen CPO auch durch den Koordinationsaufwand erklären der entsteht, wenn eine Matrix aus Geschäftsprozessen und Funktionen angestrebt wird. Ein Nachteil des CPOs ist sicherlich, dass mit ihm eine neue Funktion geschaffen wird, die weitere Vorschriften für die Manager der anderen Funktionen oder Geschäftsprozesse schafft.

9.2.2 Die Ernennung eines CPOs

Sollte der CIO zum CPO werden oder sollte der CPO neben dem CIO als eigenständige Funktion etabliert werden? Oder anders formuliert: Abolhassan/Jost vs. Schmel-

93

zer/Sesselmann ¹ . Pauschal lässt sich diese Frage nicht beantworten. Daher möchte ich hier eine Hypothese aufstellen, die eine weniger willkürliche Entscheidung zwischen diesen beiden Konzepten herbeiführt. Diese Hypothese steht unter der Annahme, dass generell eine Institutionalisierung des Geschäftsprozessmanagements in einem Unternehmen durch einen CPO sinnvoll ist. Die Hypothese hat einen einfachen Aufbau, sie besteht nur aus einer Wenn- und einer Dann-Komponente. Wenn alle Bedingungen der Wenn-Komponente (R 1 − R 4 ) erfüllt sind, trifft die Dann-Komponente zu. Da es zu erwarten ist, dass nur ein Teil der Bedingungen erfüllt ist, wird in Tabelle 9.2 eine weitere Differenzierung vorgenommen. Die Hypothese lautet:

Wenn:

R 1 = Das Unternehmen ist in einer IT-intensiven Branche tätig (z.B. Versicherungsbranche).

R 2 = Der CIO hat eine Art Prozessmanagement (z.B. ITIL) für die IT-Abteilung aufgebaut.

R 3 = Der CIO entspricht annähernd dem Idealbild des synnotschen CIOs oder dem, der von Kitzis und Broadbent entworfen wurde. Eine Erklärung dazu folgt im Text.

R 4 = Der CIO hat Kenntnisse im Geschäftsprozessmanagement.

Dann:

S 1 = CIO sollte CPO werden und in den Vorstand aufgenommen werden. CPO bedeutet hier CIO + Aufgaben-, Kompetenz- und Verantwortungsbereich des CPOs nach Schmelzer und Sesselmann.

Dann und nur dann wenn diese Bedingungen erfüllt sind ² , könnte man den CIO also als CPO in den Vorstand aufnehmen. Diese Anforderungen dürften allerdings nur wenige CIOs und Unternehmen erfüllen. Während die Bedingungen R 1 , R 2 und R 4 noch recht eindeutig sind, ist R 3 eher unscharf formuliert. Eine Möglichkeit wäre, dass man CIOs den Online-Fragebogen ³ von Gartner ausfüllen lässt und von der Punktezahl abhängig macht, ob ein CIO R 3 genügt. Möchte man diese Bewertung nicht dem CIO selbst

¹ Der CPO nach Schmidt und Seidel findet bei dieser Frage keine Beachtung, da er mir zum einen eher für IT-Projekte geeignet scheint, bei denen es um die Integration von Geschäftsprozessen in einem überschaubaren Rahmen geht. Zum anderen erscheint mir der CPO nach Abolhassan und Jost organisatorisch durchdachter zu sein. Evtl. ist dieser CPO allerdings als Zwischenstufe überlegenswert.

² Eine Formalisierung wäre zwar möglich: (x)((R1(x) ∧ R2(x) ∧ R3(x) ∧ R4(x)) ⊃ S1(x)), bietet aber

keine weiteren Vorteile (Formalisierung nach [vK67, S. 111 ff.]). Diese Formalisierung könnte sogar einen falschen Eindruck vermitteln. Es handelt sich hier nur um eine Handlungsempfehlung, die natürlich prüfbar sein sollte. Es handelt sich aber nicht um ein Gesetz, dergestalt, dass wenn R1, R2, R3 und R4 für einen CIO (CIO = x) gilt, sich automatisch ein CIO in einen CPO verwandelt...

³ Von Gartner wurde ein Online-Fragebogen für CIOs online gestellt, der sich nach Kitzis und Broadbents Buch richtet. Wer den Fragebogen ausfüllt, wird am Ende in einem Portfolio eingeordnet. Außerdem werden die durchschnittlichen Antworten der anderen CIOs angegeben (Nicht-CIOs werden gefiltert). Der Fragebogen ist online abrufbar unter: www.gartnerpress.com/newcioleader, letzter Zugriff am 11.11.06.

94

überlassen, bleibt nur noch die Möglichkeit, dass man einige Messkriterien ermittelt, die ungefähr den CIO, der R 3 genügt, abbilden (Hinter den einzelnen Punkten sind Studien angegeben, die schon versuchten, die einzelnen Punkte zu messen):

• Berichtet der CIO direkt an den CEO?

• Wie stark wird der CIO in die strategische Planung miteinbezogen? Ein Indika-tor dafür ist nach Watson z.B. ob und wie CIO und CEO regelmäßig miteinander sprechen, z.B. face to face, telefonisch oder ob sie nur über Memos, E-Mails usw. kommunizieren [Wat90]. Andere Anregungen findet man bei: [SLMF92], [AE92], [EHH03], [EH00].

• Wie bewerten andere Manager die Arbeit des CIOs? [EHH03], [EH00].

• Schafft es der CIO seine Ziele normalerweise einzuhalten?

• Empfinden gleichrangige Manager das Erreichen dieser Ziele als Vorteil für sich selbst?

• Wurde der Sprung von einer technisch orientierten IT zu einer serviceorientierten IT geschafft (z.B. ITIL eingeführt?)?

• Hat die Geschäftsführung Vertrauen in den CIO? [EHH03], [EH00].

• Wie stark steigert die IT die Produktivität im Unternehmen? [HB96].

• Wird das Personal gut im Umgang mit der IT geschult?

Vergleicht man die vier Bedingungen (R 1 − R 4 ) mit den Anforderungsprofilen der drei CPO-Konzepte, so stellt man fest, dass in der Liste Anforderungen wie gute Kommunikationsfähigkeit, hohe Sozialkompetenz, Flexibilität usw. fehlen. Dies ist Absicht, da man sie bei der Auswahl eines CPOs m.E. nicht überbewerten sollte. Für den CPO ist wichtig, dass er sich mit anderen Managern gut abstimmen kann. Ob ein Manager dazu in der Lage ist, kann man aber nicht an irgendwelchen Äußerlichkeiten festmachen, z.B. ob er über rhetorische Fähigkeiten verfügt, extrovertiert oder introvertiert ist usw.. Oder wie Peter Drucker sagt: „I soon learned that there is no „effective personality““ [Dru85, S. 21 f.] ⁴ . In R 4 wird ebenfalls angeführt, dass der CIO möglichst dem idealen CIO von Broadbent und Kitzis oder Synnott entsprechen müsse. Dies gilt nur im Rahmen der gerade gemachten Einschränkungen. Ebenfalls keine Beachtung soll die von Broadbent

⁴ „Among the effective executives I have known and worked with, there are extroverts and aloof, retiring men, some even morbidly shy. Some are eccentrics, others painfully correct conformists. Some are fat and some are lean. Some are worriers, some are relaxed. Some drink quite heavily, others are total abstainers. Some are men of great charm and warmth, some have no more personality than a frozen mackerel. There are a few men among them who would answer to the popular conception of a „leader.“ But equally there are colorless men who would attract no attention in a crowd. Some are scholars and serious students, others almost unlettered. Some have interests, others know nothing except their own narrow area and care for little else. Some of the men are self-centered, if not indeed selfish. But there are also some who are generous of heart and mind“ [Dru85, S. 22].

95

Tabelle 9.2: Die Tabelle zeigt Handlungsempfehlungen. In der linken Spalte werden

und Kitzis geforderte hohe emotionale Intelligenz finden, die nötig sei, damit ein CIO Einfluss ausüben kann [KB04, S. 27 ff.] ⁵ . Als Merkmale sollen daher eher vorzugsweise

⁵ Die emotionale Intelligenz wird vor allem abgelehnt, da sich Kitzis und Broadbent auf Goleman berufen. Golemans emotionale Intelligenz wird als sogenanntes „mixed model“ beschrieben, da es nur eine Ansammlung von mehreren Fähigkeiten wie Sozialkompetenz oder Selbstmotivation ist [NF05, S. 31 ff.]. Goleman behauptete, dass sich der Unterschied zwischen fähigen und unfähigen Führungskräften zu 90% an diesem Modell der emotionalen Intelligenz festmachen lässt [KB04, S. 27]. Diese Behauptung wurde bis heute durch keine empirische Studie bestätigt. Auch sonst lassen sich keine wirklich überzeugenden empirischen Studien finden, die eine hohe Übereinstimmung zwischen emotionaler Intelligenz und effektiven Führungskräften zulassen. Allerdings konnte man eine Übereinstimmung zwischen zufriedenen Mitarbeitern und Managern mit hoher emotionaler Intelligenz festsstellen. Diese Mitarbeiter leisteten aber nicht bessere Arbeit, bloß weil sie zufriedener waren. Zudem sind viele Untersuchungen methodisch mangelhaft, so dürfen Manager z.B. meist ihre emotionale Intelligenz selbst einschätzen [Ric05, S. 103 ff.]. Es „kann [daher sicherlich] festgehalten werden, dass die Bedeutung von [emotionaler Intelligenz] für [die] Führung nicht gerade überzeugend ist“ [Ric05, S. 104]. Stattdessen soll in der Hypothese eher der Commonsense-Einstellung Druckers gefolgt werden (es gibt keine effektive Persönlichkeit). Gegen die Forschung an der emotionalen Intelligenz ist zwar nichts einzuwenden, sie ist aber, um mit Arnold Gehlens Vokabular zu sprechen, nicht mehr als eine Zauberformel, die die komplexe Realität für den Personaler reduziert und ihm so schwierige Entscheidungen abnehmen kann. M.E. ist die emotionale Intelligenz genauso fragwürdig wie der Intelligenzquotient, wenn es um die Besetzung von Führungspositionen geht.

96

die oben genannten Punkte eingesetzt werden.

Sind eine oder mehrere dieser Bedingungen nicht erfüllt, sollte man unter Berücksichtigung von Tabelle 9.2 überdenken, ob man den CIO zum CPO macht. Auf jeden Fall seine Aufnahme in den Vorstand, die dann aber sowieso kaum zur Debatte stehen dürfte. Sollte begründeter Verdacht bestehen, dass der CIO das Prozessmanagement in erster Linie als eine IT-Sache und damit zu technisch sehen sollte, sollte lieber eine Stabstelle für Prozessmanagement direkt unter dem CEO eingerichtet werden. Falls ein CIO keine der vier Bedingungen erfüllen kann, ist anzunehmen, dass generell etwas in einem Unternehmen falsch läuft, sei es, dass der CIO unfähig ist, sei es, dass der CIO in seiner Arbeit behindert wird. Klar ist sicherlich, dass in den Fällen, in denen ein CPO nach Schmelzer und Sesselmann eingerichtet wird, die strategische Rolle des CIOs nach Synnott eingeschränkt wird und vom CPO übernommen wird. Die vorgestellte Hypothese lässt sich letztlich auf zwei Wegen widerlegen ⁶ :

1. Die aus der Dann-Komponente abgeleitete Handlungsempfehlung bestätigt sich nicht. Z.B. ein CIO, für den die Bedingungen R 1 , R 2 , R 3 und R 4 gelten, wird zum CPO ernannt und die neu geschaffene Position ist weniger erfolgreich als die des CIOs.

2. Die Bedingungen der Wenn-Komponente sind nicht erfüllt und es wird dennoch eine sehr erfolgreiche CPO-Funktion geschaffen. In diesem vermutlich nicht unwahrscheinlichen Falle müsste eine Änderung der Wenn-Komponente vorgenommen werden. Optimalerweise sollte sie dabei möglichst weit gefasst sein, um einen höheren Grad der Allgemeinheit und Prüfbarkeit zu erreichen. Auch wenn es nicht unwahrscheinlich ist, dass die Wenn-Komponente zu eng gefasst ist, liegt die große Schwierigkeit darin, dass die Gültigkeit der Dann-Komponente erhalten bleibt.

⁶ Unter der Annahme, dass die Institutionalisierung des Geschäftsprozessmanagements durch einen CPO sinnvoll ist. Ist diese Annahme falsch, ist auch die Hypothese falsch oder muss durch weitere Randbedingungen in der Wenn-Komponente erweitert werden.

97

10 Fazit

Diese Arbeit konnte sicherlich zeigen, dass die Institutionalisierung des Geschäftsprozessmanagements im Unternehmen eine große Chance für viele CIOs ist, die eigene Position zu sichern und den eigenen Kompetenzbereich auszudehnen. Ob dies in jedem konkreten Fall für ein Unternehmen sinnvoll ist, ist m.E. zu verneinen. Einer IT, die ihre Hausaufgaben nicht gemacht hat, sollte man nicht voreilig mehr Aufgaben übertragen. Es sollte in diesem Fall erst untersucht werden, welche Gründe es für das Defizit der IT gibt. Diese Gründe sollten dann Vorrang haben. Kapitel 3 und 2 haben gezeigt, dass die Gründe für Defizite in der IT sehr vielfältig sein können und nicht immer in einer schlechten Arbeit der IT begründet sind.

Neben der Frage, ob und wie ein CPO eingesetzt werden sollte, ist eine weitere Frage von viel größerer Bedeutung: Wann sollte die Prozessorientierung Vorrang vor der funktionalen Spezialisierung haben? Rebstock empfiehlt eine Prozessorientierung immer dann, wenn Prozesse über die Grenzen mehrerer Funktionen hinweglaufen und diese Funktionen sich aus eher einfachen Tätigkeiten zusammensetzen. Bei Funktionen, die eine hohe Professionalisierung erreicht haben, sollte auf eine Prozessorientierung eher verzichtet werden [Reb97, S. 275 ff.]. Ein Unternehmen sollte diese Frage für sich beantwortet haben, bevor es eine Stelle kreiert, die sich anschließend mit der Prozes-sorientierung des Unternehmens auseinandersetzt (z.B. bei der Erstellung des Unternehmensprozessmodells). Alternativ könnte man diese Frage natürlich auch dem CPO überlassen. Es scheint aber wenig ratsam zu sein, den Manager des Geschäftsprozessmanagements darüber entscheiden zu lassen, wann Prozessorientierung sinnvoll ist. Um ein Gegengewicht braucht man sich aber keine Sorgen machen, da Manager von Funktionen mit hoher Spezialisierung sich nicht ohne weiteres „entspezialisieren“ lassen, sprich: Ihre Funktionen für Prozesse in Stücke zerschlagen lassen.

Bei all dem sollte aber nicht vergessen werden, dass für die Produktivität der IT das IT-Personal von größter Bedeutung ist. Allein dadurch, dass man einen CIO zum CPO macht, wird man nicht signifikant die IT-Produktivität erhöhen. Genauso scheint es wenig sinnvoll zu sein mit dem CPO eine reine Prozessorganisation anzustreben. Prozes-sorientierung ist allerdings, wie oben dargelegt, ein wichtiges Instrument, dass allein schon durch seine Tendenz zur Dezentralisierung die IT-Produktivität steigern kann. Man sollte nicht ignorieren, dass es viele Faktoren gibt, die eine hohe IT-Produktivität befördern. Diese Faktoren (z.B. Dezentralisierung, vgl. 3.5) existieren aber unabhängig von der Frage, ob ein CIO oder ein CPO im Unternehmen die IT leitet. Daher ist die Quintessenz der Hypothese aus Punkt 9.2.2 auch, dass ein CIO den Wandel zum CPO nur anstreben sollte, wenn diese Faktoren größtenteils sichergestellt sind. Alles andere würde vermutlich keine große Besserung bringen und den CIO evtl. mit zu vielen Veränderungsprojekten überfordern. In diesem Fall kann es daher sinnvoller sein, den CPO

98

direkt als Stabstelle unter dem CEO anzusiedeln. So wie es Schmelzer und Sesselmann empfehlen.

Leider konnten nicht alle relevanten Aspekte des Themas angesprochen, geschweige denn ausführlich behandelt werden. So fehlt z.B. eine systematische Durchleuchtung aller Artikel, die ein Abgesang auf den CIO sind. Nach einer anschließenden Kategorisierung hätte man z.B. die so entstandenen Kategorien der Reihe nach abhandeln können. Auch die sehr unübersichtliche Situation des Marktes für Geschäftsprozessmanagement-Systeme, die vielen Standards in diesem Bereich, die Abgrenzung zu Workflow-Systemen und ihr Einfluss auf das Geschäftsprozessmanagement, wurden bestenfalls am Rande be-handelt. Der Leser dieser Arbeit könnte fast den Eindruck bekommen, es gäbe nur ARIS. Auch Themen wie Prozesscontrolling, Organisation, Psychologie, Wissensmanagement, Business Alignment, strategisches IT-Management, Mitarbeiterentwicklung und andere Weiterentwicklungsmöglichkeiten des CIOs als die vorgestellten CPO-Konzepte wurden kaum oder gar nicht behandelt. Diese Arbeit ist, um einen Satz Poppers aufzugreifen, nur wie eine Taschenlampe, die einen Teil dessen, was wir mit dem Etikett „Vom CIO zum CPO“ versehen, beleuchtet. Gleichzeitig lässt sie den Rest im Dunkeln. Trotz oder gerade wegen all dieser Unsicherheiten gilt letztlich was Walther Rathenau am 07.07.1902 in seiner Abschiedsrede sagte als er die Abteilung Zentralisationen bei AEG verliess. Man ersetze einfach „kaufmännische und Ingenieur-Bildung“ durch „betriebswirtschaftliche und Informatik-Bildung“:

„Wir haben nicht in erster Linie Kaufleute und Ingenieure nötig, sondern wir haben Menschen nötig, die zwar eine kaufmännische und Ingenieur-Bildung haben, daneben aber etwas Besseres sind, nämlich Menschen von gesundem Menschenverstand“ [Wal65, S. 188].

99

Literaturverzeichnis

[AB05]

[ABH04] Ali Arsanjani, Bernhard Borges, and Kerrie Holley. Service-Oriented Architecture. DM Direct Newsletter, 2004. http://www.dmreview.com/arti cle_sub.cfm?articleId=1013602, letzter Zugriff am 06.11.06. 54

[Abo05] Ferri Abolhassan. Vom CIO zum Chief Process Officer. In Bernd Kuhlin and

[AE92]

[AG05a] AUDI AG. Geschäftsbericht 2004, 2005. http://www.audi.de/etc/m edialib/cms4imp/audi2/company/financial_information/pdf .Par.0036.File.pdf, letzter Zugriff am 14.11.06. 86

[AG05b] Volkswagen AG. Geschäftsbericht 2004, 2005. http://www.volkswage n-ir.de/fileadmin/vw-ir2/dokumente/berichte/2005/Gberic ht_2004_de.pdf, letzter Zugriff am 14.11.06. 86

[AH02] Rob Aalders and Peter Hind. Management für IT-Leiter. Wiley-VCH Verlag GmbH, Weinheim, 2002. 35

[AKM01] Mani Agrawal, T.V. Kumaresh, and Glenn A. Mercer. The false promise of mass customization. THE McKINSEY QUARTERLY, (3):62-71, 2001. 15

[Alb91] Hans Albert. Traktat über kritische Vernunft. J.C.B. Mohr (Paul Siebeck), UTB für Wissenschaft, Tübingen, 1991. 9

[All05]

[Arm80] Paul Armer. SHARE-A Eulogy to Cooperative Effort. Annals of the History of

[Bar05]

[Bau97] Wilhelm Baum. Paul Feyerabend - Hans Albert. Briefwechsel. Fischer Taschenbuch Verlag GmbH, Main, 1997. 9

[BBG ⁺ 04] Jörg Becker, Klaus Backhaus, Heinz Lothar Grob, Thomas Hoeren, Ste-

[BC03]

[BG02]

[BHB02] Timothy F. Bresnahan, Lorin Hitt, and Erik Brynjolfsson. Productivity, Profit

[BJZ92] Andrew C. Boynton, Gerry C. Jacobs, and Robert W. Zmud. Whose Respon-

[BLP89] Knut Bleicher, Diethard Leberl, and Herbert Paul. Unternemungsverfassung

[BM04a] Erik Brynjolfsson and Ken McGee. Interview. Erik Brynjolfsson, 2004. 50

[BM04b] Burson-Marsteller. In Vorständen fehlt Technologie-Kompetenz. Die Karriere-

[Bor06]

[BRBB04] Freimut Bodendorf, Susanne Rebra-Bissantz, and Christian Bauer. There’s

[Bry03]

[Car03]

[Car04]

[Cez05] Wolfgang Cezanne. Allgemeine Volkswirtschaftslehre. Oldenbourg Wissenschaftsverlag GmbH, München, 2005. 11, 26, 27, 28

[CK03]

[Com05a] Computerwelt. T-Systems kauft Gedas, 2005. http://www.compute

[Com05b] Computerwoche.

[Com05c] Computerwoche.

[Com05d] Computerwoche. Volkswagen-CIO Klaus-Hardy Mühleck: „VW hat das

[CON05] ACRYS CONSULT.

[Dea87] John Dearden. The Withering Away of the IS Organization. Sloan Manage-

[Deu06] Statistisches Bundesamt Deutschland. Volkswirtschaftliche Gesamtrechnun-

[DHLK06] Miriam Daum, Oliver Häberle, Inge Lischka, and Helmut Krcmar. THE CHIEF

[Dru85] Peter F. Drucker. The Effective Executive. The Definitive Guide to Getting the Right Things Done. HarperCollins, New York, USA, 1985. 32, 33, 95

[DSSW04] Kendall B. Davis, Brian L. Scanlon, Jeremy D. Schneider, and Oded Weiss.

[Ear96]

[EEF96] Michael J. Earl, Brian Edwards, and David F. Feeny. Configuring the IS Func-

[EH00]

[EHH03] Harvey G. Enns, Sid L. Huff, and Christopher A. Higgins. CIO Lateral Influ-

[Ele02]

[Ele03]

[Ele05]

[Ele06]

[Els06]

[Eri02]

[Eur06]

[Fay29]

[FES92] David F. Feeny, Brian R. Edwards, and Keppel M. Simpson. Understanding the CEO/CIO Relationship. MIS Quarterly, 16(12):435-447, 1992. 45, 46

[FV06]

[Gau66] Eduard Gaugler. Instanzenbildung als Problem der betrieblichen Führungsorganisation. Berliner Buchdruckerei Union GmbH, Berlin, 1966. 61

[Gil04]

[Gil05]

[Gil06]

[Gla65]

[Gor99] Robert J. Gordon. Has the „New Economy“ Rendered the Productivity Slow-

[Gor00] Robert J. Gordon. Does the „New Economy“ Measure up to the Great Inven-

[Grü97] Ansgar Gründler. Computer und Produktivität. Das Produktivitätsparado-

[Gro06] Deutsche Börse Group. Geschäftsbericht 2005, 2006. http://deutsche -boerse.com, letzter Zugriff am 05.10.06. 40

[GS02]

[Hah75] Dietger Hahn. Kompetenz. In Eduard Gaugler, editor, Handbuch des Per-

[Har03]Paul Harmon. The Chief Process Officer. 2003. http://www.bptrends. com/, Artikel war nicht mehr im Internet auffindbar. 83

[HB96]

[Hei96]

[Hei01]

[Hem01] Carl Gustav Hempel. The Philosophy of Carl G. Hempel. Studies in Science,

[HGRZ06] Sebastian Herden, Jorge Marx Gomez, Claus Rautenstrauch, and Andre

[Hop90] Max D. Hopper. Rattling SABRE - New Ways to Compete on Information. Harvard Business Review, 1990. 7, 10

[Ins01]

[Jan03]

[JMS06] Matjaz B. Juric, Benny Mathew, and Poornachandra Sarang. Business Process

[Jos04]

[Jos05]

[Jos06]

[JW05]

[KB04]

[Kel02]

[Krc05]

[Kuh76] Thomas S. Kuhn. Die Struktur wissenschaftlicher Revolutionen. Suhrkamp Taschenbuch Verlag, Frankfurt am Main, 1976. 25

[Lam04] Josef Lamberti. Deutsche Bank’s IT revolution. McKinsey on IT, (4):18-22, 2004. 40

[Mah04] John Mahoney. Demands for Business Growth Make CIOs Reallocate Their

[McG04] Ken McGee. Gartner Updates Its Definition of Real-Time Enterprise,

[McN03] Scott McNealy.

[MFB95] Francisco J. Mata, William L. Fuerst, and Jay B. Barney. Information Techno-

[Müh02] Klaus H. Mühleck. Unternehmensweite IT-Qualifizierung. Pflicht oder Kür

[Müh05] Klaus Hardy Mühleck. Business-Enabler gesucht. Wie die IT unternehmens-

[Mie04] Thorsten Mieze. Beyond Carr - und sie bewegt sich doch. In Hans Peter

[MJ86]

[MM04] David Mark and Eric Monnoyer. Next-generation CIOs. The McKinsey

[Mor96] Peter W. G. Morris. Project Management: Lessons from IT and Non-IT Pro-

[Nag72] Ernest Nagel. Über die Aussage: »Das Ganze ist mehr als die Summe seiner

[Nag79] Ernest Nagel. THE STRUCTURE OF SCIENCE. Problems in the Logic of Scientific

[Nas03] Harvey Nash. CIO / IT Director Market Survey 2003. Is the worst over?,

[Nas04] Harvey Nash. CIO / IT Director Market Survey 2004. The DNA of a

[Nas05] Harvey Nash. THE ANNUAL HARVEY NASH CIO MARKET SURVEY,

[Nas06a] Harvey Nash. 2007 Strategic Leadership Survey - A CIO Perspective,

[Nas06b] Harvey Nash.

[NF05]

[Nor02] Klaus North. Wissensorientierte Unternehmensführung. Wertschöpfung durch

[NPW02] Stefan Neumann, Christian Probst, and Clemens Wernsmann. Kontinuier-

[Oas06] Oasis. Web Services Business Process Execution Language Version 2.0 Public

[Oer02] Peter Oertli. Der Fall: Warum Coca-Cola in Indien hartes Lehrgeld bezahlte.

[Off01]

[Onl04a] CIO Online. Konzern-CIO setzt auf duale Führungsstrukturen. VW gibt sich

[Onl04b] CIO Online. Nur Gestalter haben Platz im gehobenen Management. Mühleck:

[Onl04c] CIO Online. Planen Sie in diesem Jahr die Einführung von ITIL?, 2004.

[Onl04d] CIO Online. Stellenwert der Unternehmens-IT wächst. CIOs landen in der

[Onl05a] CIO Online. CIO der Zukunft. Die neue IT-Elite, 2005. http://www.cio. de/strategien/808221/index.html, letzter Zugriff am 05.10.06. 52

[Onl05b] CIO Online. Konzern-CIO setzt auf duale Führungsstrukturen. VW gibt sich

[Onl06] CIO Online. Die neue CIO-Generation, 2006. http://www.cio.de/n ews/802437/index.html. 7

[OS03]

[pc06]

[Per03]

[PH97]

[PH05]

[Pil97]

[Pil98]

[PK93]

[Pop04] Karl R. Popper. Ausgangspunkte. Meine intellektuelle Entwicklung. Piper Verlag GmbH, München, 2004. 9

[Pop05] Karl R. Popper. Logik der Forschung. Mohr Siebeck, Tübingen, 2005. 9

109

[Por04]

[PS03] Christian Petri and Annete Stannat. Trends in der Unternehmens-IT. Informatik-Spektrum, 23(3):227-237, 2003. 7, 30

[Qua06] Karin Quack.

[RD90]

[Reb97] Michael Rebstock. Grenzen der Prozeßorientierung. zfo (Zeitschrift für Organisation + Forschung), 16(12):272-278, 1997. 78, 98

[RHW06] John R. Rymer, Paul Hamerman, and R Ray Wang. Oracle Versus SAP In Enterprise Applications: Let The Battle Of Architectures Begin!, 2006. 57

[Ric05]

[Sch00]

[Sch03a] John G. Schmidt. EAI Methodology. The Theory of Application Integration,

[Sch03b] John G. Schmidt. The Software Ecologist. The New Language of Integration. Business Integration Journal, (8):48, 2003. 63

[Sch04] IDS Scheer. Vom CIO zum CPO. SCHEER MAGAZIN, (2):4-8, 2004. 70, 71

[Sch06a] August-Wilhelm Scheer.

[Sch06b] IDS Scheer. Konzernweites IT-Architektur-Management bei Volkswagen,

[SF03]

[SG81]

[SLMF92] Charlotte S. Stephens, William N. Ledbetter, Amitava Mitra, and F. Nelson

[Soi06]

[SR02]

[SRW05] Dieter Spath, Thomas Renner, and Annette Weisbecker. Unternehmensüber-

[SS01]

[SS06]

[Syn87] William R. Synnott. THE INFORMATION WEAPON. Winning Customers and

[Tyn05]

[vB05] Matthias v. Bechtolsheim. Der CIO in verändertem Umfeld - Brauchen Unter-

[vBD04] Matthias v. Bechtolsheim and Fabian Dömer. Brauchen Sie den CPO (Chief

[vK67] Franz v. Kutschera. Elementare Logik. Springer-Verlag, 1967. 94

[vLB04] Zwanet van Lubek Bader. Vom Technikfreak zum Dienstleister und Problemlöser. io new management, (12):32-35, 2004. 35, 37

[vS80]

[vW05]

[W3C04] W3C. Web Services Architecture, 2004. http://www.w3.org/TR/ws-a rch/wsa.pdf, letzter Zugriff am 07.11.06. 54, 55, 56

[Wal65] Walther Rathenau. WALTHER RATHENAU SCHRIFTEN. Berlin Verlag, 1965. 99

[Wat90] Richard T. Watson. Influences on the IS Manager’s Perceptions of Key Issues:

[Wit72]

[yCF06] Pei yu Chen and Chris Forman. Can Vendors Influence Switiching Costs

Index

Aufgabe, 61

B2B-Integration, 63 BPEL (Business Process Execution Language), 56

Choreographie, 56 CIO (Chief Information Officer), 34 Commodity, siehe Massenware, 11 CPO (Chief Process Officer) nach Abolhassan und Jost, 70 Lose Kopplung, 55 nach Schmelzer und Sesselmann, 76

nach Schmidt und Seidel, 63 CPO-Konzept, 61

DEA (Data Exchange Administration), 67 Nachhaltigkeit von Wettbewerbsvorteilen, Differenzierung, 14 16 DP-Manager (Data Processing Manager), 34

Orchestration, 56

EAI (Enterprise Application Integration),

Prozessorganisation, 62

63

Prozessteam, 77

EDM (Enterprise Data Model), 67 EEM (Enterprise Event Model), 67 Reduktionismus, 64 Einheit der Auftragserteilung, 61

Einheit der Leitung, 61

Funktionsorientierte Organisation, 62

Geschäftsprozessmanagement-Control Board, 76 Unternehmensprozessmodell, 79

Heterogenität, 16 Verantwortung, 61

Interface, 55 Web Service, 54 IT-Produktivitätsparadoxon, 18 auf Unternehmensebene, 22

113

Eidesstattliche Erklärung

Hiermit versichere ich, dass ich die Arbeit selbst erstellt und alle wörtlichen wie sinngemäßen Zitate kenntlich gemacht habe.

Neuweiler, 2. März 2007