Department Informatik der Universität Hamburg...Department Informatik der Universität Hamburg -...

Department Informatik der Universität Hamburg - Arbeitsbereich „Angewandte und Sozialorientierte Informatik“ (ASI) -

Diplomarbeit

SAP im Mikropolis-Modell

Analyse des SAP-Technikentwicklungspfades auf der Grundlage sozialwissenschaftlicher

Techniktheorien und des Mikropolis-Modells

Erstbetreuer: Prof. Dr. Arno Rolf

Zweitbetreuer: Dipl. Wirt. Inf. Paul Drews

Thomas Müller Studiengang: Wirtschaftsinformatik Lange Straße 38 Matrikelnummer: 5559433 20359 Hamburg Abgabedatum: 11.11.2010 Telefon: 040 / 41287254 E-Mail: [email protected]

I

Inhaltsverzeichnis

Abbildungsverzeichnis ........................................................................................................... IV

Abkürzungsverzeichnis .......................................................................................................... VI

1. Einleitung .............................................................................................................................. 1

1.1 Fragestellung und Relevanz der Thematik ....................................................................... 4

1.2 Methodisches Vorgehen ................................................................................................... 4

1.3 Überblick über die Arbeit ................................................................................................. 6

2. Sozialwissenschaftliche Techniktheorien und das Mikropolis-Modell ........................... 7

2.1 Technikdeterminismus ..................................................................................................... 7

2.2 Akteur-Netzwerk-Theorie ................................................................................................ 8

2.2.1 Der Weg zur Akteur-Netzwerk-Theorie .................................................................... 9

2.2.2 Die Grundlagen der Theorie und der Übersetzung .................................................. 10

2.3 Mikropolis-Modell ......................................................................................................... 13

2.3.1 Soziotechnischer Kern - erfolgreiche Übertragung operationalisierter Handlungen

auf Informationstechnik .................................................................................................... 14

2.3.2 Mikrokontext - Technikentwicklung im Wechselspiel der Akteure ........................ 15

2.3.3 Makrokontext - einflussreiche Strukturen und Leitbilder in der Gesellschaft ......... 19

2.3.4 Prozesse und Pfade der Technikentwicklung und -nutzung .................................... 21

3. Die SAP AG und die SAP-Software .................................................................................. 24

3.1 Die Entwicklung der SAP-Software unter Berücksichtigung der SAP AG ................... 24

3.1.1 SAP R und SAP R/2 - das Mainframe System ........................................................ 24

3.1.2 SAP R/3 - die Client-Server-Strategie ..................................................................... 27

3.1.3 SAP seit der Zeit des Internets ................................................................................. 31

3.1.3.1 mySAP.com - die Idee des Mehrproduktunternehmens ................................... 31

3.1.3.2 Business Suite 7 - die serviceorientierte Architektur ....................................... 34

3.1.3.3 SAP Business byDesign - das On-Demand-Produkt ........................................ 38

3.1.4 SAP weltweit ........................................................................................................... 39

3.1.4.1 SAP und die Partnerstrategie ............................................................................ 40

3.1.4.2 SAP als global integriertes Unternehmen ........................................................ 43

II

3.2 Die Einführung von SAP-Software am Beispiel von SAP R/3 in Unternehmen ........... 47

3.2.1 Gründe der Einführung ............................................................................................ 48

3.2.2 Methoden und Erfolgsfaktoren der Einführung ....................................................... 50

3.2.2.1 Vorgehen und Projektmanagement .................................................................. 50

3.2.2.2 Key User und Promotoren ................................................................................ 56

3.2.2.3 Externe Berater ................................................................................................. 57

4. Analyse der SAP-Technikentwicklung mittels sozialwissenschaftlicher

Techniktheorien und dem Mikropolis-Modell .................................................................... 59

4.1 SAP aus Sicht des Technikdeterminismus ..................................................................... 59

4.1.1 SAP zur Zeit von SAP R und SAP R/2 - die Gründungszeit ................................... 59

4.1.2 SAP zur Zeit von SAP R/3 und dessen Einführung in Unternehmen ...................... 62

4.1.3 SAP 2002 bis 2009 und die Globalisierung ............................................................. 64

4.1.4 Ergebnisse der Analyse und Bewertung .................................................................. 65

4.2 SAP aus Sicht der Übersetzung als Teil der Akteur-Netzwerk-Theorie ........................ 66

4.2.1 Problematisierung .................................................................................................... 67

4.2.2 Interessement ........................................................................................................... 70

4.2.3 Enrolment ................................................................................................................. 71

4.2.4 Mobilisierung ........................................................................................................... 72

4.2.5 Dissidenz .................................................................................................................. 73

4.2.6 Ergebnisse der Analyse und Bewertung .................................................................. 74

4.3 SAP im Mikropolis-Modell ............................................................................................ 76

4.3.1 Die Technikentwicklung aus soziotechnischer Perspektive .................................... 76

4.3.2 Innovationen als Ergebnis von Wechselwirkungen zwischen Akteuren ................. 82

4.3.3 SAP im gesellschaftlichen Kontext ......................................................................... 90

4.3.4 Pfade der erfolgreichen und misslungenen SAP-Innovationen im Zeitverlauf ....... 94

4.3.4.1 Der SAP-Technikentwicklungspfad im Mikropolis-Modell ............................ 94

4.3.4.2 Der Techniknutzungspfad Büro ..................................................................... 101

4.3.4.3 Die Schnittstellen zwischen dem SAP-Technikentwicklungspfad und dem

Techniknutzungspfad Büro ........................................................................................ 103

4.3.5 Ergebnisse der Analyse und Bewertung ................................................................ 105

III

5. Eine vergleichende Zusammenführung des Technikdeterminismus und der Akteur-

Netzwerk-Theorie mit dem Mikropolis-Modell ................................................................ 108

5.1 Technikdeterminismus und das Mikropolis-Modell .................................................... 108

5.2 Akteur-Netzwerk-Theorie und das Mikropolis-Modell ............................................... 109

6. Schlussfolgerungen und offene Fragen .......................................................................... 112

Literaturverzeichnis ............................................................................................................. 116

Ehrenwörtliche Erklärung .................................................................................................. 125

IV

Abbildungsverzeichnis

Abb. 01: Prozentualer Umsatz von ERP-System-Verkäufern (vgl. AMR Research 2007) ...... 1

Abb. 02: Umsatz der SAP AG bis 2009 (eigene Darstellung, vgl. Campbell-Kelly 2003, S.

192 und SAP 2001-2009) ........................................................................................................... 2

Abb. 03: Mitarbeiter der SAP AG bis 2009 (eigene Darstellung, vgl. Campbell-Kelly 2003, S.

192 und SAP 2001-2009) ........................................................................................................... 2

Abb. 04: Kundenanzahl der SAP AG (eigene Darstellung, vgl. Hohlmann 2007, S. 48, SAP

Geschichte 1-4, SAP Daten und Siegele 2009, S. 81 und 235) .................................................. 3

Abb. 05: Phasen der Übersetzung (eigene Darstellung) .......................................................... 11

Abb. 06: Das Dreieck des Interessements (Callon 1996, S. 153) ........................................... 12

Abb. 07: Die Sicht auf den soziotechnischen Kern (Vorlesung Rolf 2010, S. 21) ................. 15

Abb. 08: Wechselwirkungen zwischen Organisation und Informatiksystem (Vorlesung Rolf

2010, S. 36) .............................................................................................................................. 16

Abb. 09: Die Innovationsspirale (Vorlesung Rolf 2010, S. 37) .............................................. 17

Abb. 10: “The Duality of Technology” nach Orlikowski (Rolf 2008, S. 113) ....................... 18

Abb. 11: Der Mikro- und Makrokontext der Mikropolis-Plattform (Rolf 2008, S. 25) .......... 20

Abb. 12: SAP AG um 1972 (eigene Darstellung) ................................................................... 26

Abb. 13: Faktoren, Strategien und Leitbilder für SAP R und SAP R/2 (eigene Darstellung) 27

Abb. 14: Architektur SAP R/3 (Hohlmann 2007, S. 57) ......................................................... 29

Abb. 15: Faktoren, Strategien und Leitbilder für SAP R/3 (eigene Darstellung) ................... 30

Abb. 16: Faktoren, Strategien und Leitbilder für mySAP.com (eigene Darstellung) ............. 34

Abb. 17: SAP Marktplatz (SAP Marktplatz 2010) .................................................................. 35

Abb. 18: Architektur SAP Business Suite 7 (Hohlmann 2007, S. 58) .................................... 36

Abb. 19: Faktoren, Strategien und Leitbilder für SAP Business Suite 7 (eigene Darstellung)37

Abb. 20: Faktoren, Strategien und Leitbilder für Business byDesign (eigene Darstellung) ... 39

V

Abb. 21: Partnerstrategie der SAP AG (von Arb 1997, S. 56) ................................................ 40

Abb. 22: Bedeutung des Partnerstatus für Unternehmen (RAAD in Computerwoche 2010) . 43

Abb. 23: Entwicklungszentren und deren Aufgaben (eigene Darstellung) ............................. 47

Abb. 24: Auslösende Faktoren der Einführung von SAP R/3 (von Arb 1997, S. 244) ........... 48

Abb. 25: Ausschlaggebende Argumente für SAP R/3 (von Arb 1997, S.249) ....................... 49

Abb. 26: Traditionelles SAP-Vorgehensmodell (von Arb 1997, S. 161) ................................ 51

Abb. 27: Rangfolge der Akzeptanzfaktoren - Erfolg als abhängige Variable (Wolter 2006, S.

211) ........................................................................................................................................... 53

Abb. 28: Matrix der wechselseitigen Beeinflussung der Erfolgsfaktoren (Wolter 2006, S. 213)

.................................................................................................................................................. 54

Abb. 29: Rangfolge der Einführungsstrategien (Wolter 2006, S. 243) ................................... 54

Abb. 30: Reziproke Systementwicklung (Hohlmann 2007, S. 77) ......................................... 58

Abb. 31: Wirkung von SAP auf Unternehmen (eigene Darstellung) ...................................... 66

Abb. 32: Phasen der Übersetzung (eigene Darstellung) .......................................................... 67

Abb. 33: Obligatorischer Passagepunkt (eigene Darstellung) ................................................. 70

Abb. 34: Akteur-Netzwerk von SAP (eigene Darstellung) ..................................................... 74

Abb. 35: SAP-Technikentwicklungspfad - erster Zeitabschnitt: MIAS, SAP R und SAP R/2

(eigene Darstellung) ................................................................................................................. 96

Abb. 36: SAP-Technikentwicklungspfad - zweiter Zeitabschnitt: SAP R/3 (eigene

Darstellung) .............................................................................................................................. 97

Abb. 37: SAP-Technikentwicklungspfad - dritter Zeitabschnitt: SAP Business Suite 7 und

Business byDesign (eigene Darstellung) .................................................................................. 99

Abb. 38: SAP im Mikropolis-Modell (eigene Darstellung) .................................................. 106

VI

Abkürzungsverzeichnis

ANT Akteur-Netzwerk-Theorie

ASAP Accelerated SAP

BAPI Business Application Programming Interfaces

BI Business Intelligence

BPR Business Process Reengineering

BomP Bill of Materials Processing

Copics Communication-Oriented Production Information and Control

System

CRM Customer Relationship Management

ERP Enterprise Resource Planning

ESOA Enterprise Service Oriented Architecture

HP Hewlett Packard

IT Informationstechnik

MIAS Material Information and Accounting System

MRP Material Requirement Planning

OPP Obligatorischer Passagepunkt

PICS Production Information and Control System

SAA System-Anwendungs-Architektur

SCOT Social Construction of Technology

SCM Supply Chain Management

SST Social Shaping of Technology

TEP Technikentwicklungspfad

TNP Techniknutzungspfad

WWW World Wide Web

1

1. Einleitung

„Man kann heute kein Produkt mehr entwickeln, vertreiben oder warten ohne IT. Aus Ge-

schäft ist Technologie geworden und aus Technologie Geschäft.“ (Siegele 2009, S. 262)

Diese Aussage von George Colony, Chef des Marktforschungsinstituts Forrester Research,

betont die vorhandene und weiter wachsende Verwobenheit der Technik mit den Unterneh-

men. Die SAP AG ist eine der Firmen, deren tägliches Geschäft ausschließlich die Entwick-

lung, Einführung und Verbreitung von Informationstechnologie (IT) ist und deren Innovatio-

nen jene Verwobenheit besonders tragen und fördern. Ihre Software ist die Grundlage für

Prozesse und Geschäftsabwicklungen vieler tausend Unternehmen und wird als Enterprise

Ressource Planning-System (ERP-System) oder betriebswirtschaftliche Anwendungssoftware

bezeichnet (vgl. Abts und Mülder 2002, S. 58 und 164f). Die SAP-Software umfasst Funktio-

nen aus mehreren Unternehmensbereichen und strukturiert diese nach Geschäftsprozessen.

Ihre Aufgabe ist es, verschiedene Funktionen, Aufgaben und Daten in ein Informationssystem

zu integrieren. ERP-Systeme zeichnen sich durch eine Standardisierung von Prozessen aus,

wodurch Produktivitätsgewinne, eine Erleichterung der Koordination, eine Entlastung der

Führungskräfte und die Stabilität der Organisation herbeigeführt werden sollen. Die SAP AG

hat bei der Entwicklung dieser Software die besondere Position inne, auf der einen Seite

Technikentwickler und auf der anderen Seite Gestalter unternehmensbezogener Prozesse zu

sein. Das Unternehmen hat es geschafft, sich seit seiner Gründung im Jahr 1972 von einem

nationalen zu einem internationalen Unternehmen zu wandeln und gilt heute als Marktführer

für betriebswirtschaftliche Anwendungssoftware (vgl. Abbildung 01).

Abb. 01: Prozentualer Umsatz von ERP-System-Verkäufern (vgl. AMR Research 2007)

2

Der Umsatz steigerte sich vom ersten Jahr mit 300.000 Euro auf über 10 Milliarden im Jahr

2009 (vgl. Abbildung 02).

Abb. 02: Umsatz der SAP AG bis 2009 (eigene Darstellung, vgl. Campbell-Kelly 2003, S.

192 und SAP 2001-2009)

Die Mitarbeiterzahl wuchs stetig, von ehemals neun Mitarbeitern im Jahr 1972 auf 1.367 Mit-

arbeiter im Jahr 1989 und nicht einmal zehn Jahre später auf 12.856 Mitarbeiter. 2008 erreich-

te die Zahl der Mitarbeiter mit 51.544 ihren Höhepunkt (vgl. Abbildung 03).

Abb. 03: Mitarbeiter der SAP AG bis 2009 (eigene Darstellung, vgl. Campbell-Kelly 2003, S.

192 und SAP 2001-2009)

3

Parallel dazu verhielt sich die Kundenentwicklung bei der SAP AG wie folgt: Im Gründungs-

jahr 1972 zählte die SAP AG schon drei Kunden, deren Zahl ein Jahr später bereits auf 40

gestiegen war (vgl. SAP Geschichte 1). 1982 waren es schon 240 Kunden und zehn Jahre spä-

ter 2.800 (vgl. SAP Geschichte 2 und Hohlmann 2007, S. 48). Bis 2004 verzeichnete die SAP

AG 24.000 Kunden, 2008 über 76.000 und 2009 95.000 (vgl. Siegele 2009, S. 235, SAP Ge-

schichte 4 und SAP Daten). Zu den Kunden der SAP AG gehören viele erfolgreiche Unter-

nehmen, zum Beispiel IBM, Intel, Microsoft, Philips, HP, Telekom, Pacific Gas (PG&E),

Coca-Cola, Burger King, Anheuser-Busch, Intel, Apple, Microsoft, Bahlsen und die Esso AG

(vgl. Meissner 1997 S. 12, 82, 96f, 118 und Abbildung 04).

Abb. 04: Kundenanzahl der SAP AG (eigene Darstellung, vgl. Hohlmann 2007, S. 48, SAP

Geschichte 1-4, SAP Daten und Siegele 2009, S. 81 und 235)

Diese Erfolgsgeschichte ist bereits in verschiedenen Arbeiten angesprochen, dokumentiert

und bewertet worden.1 Neben dieser positiven Bilanz kann die Einführung der SAP-Systeme

als ERP-System aber auch mit Problemen in der anwendenden Organisation verbunden sein,

wie mit einer Verminderung der Anpassungsfähigkeit der Firma an nicht geplante Prozesse,

zu hohen Umstellkosten wegen zu geringer Flexibilität, Motivations- und Identifikationsprob-

lemen der Mitarbeiter mit dem neuen SAP-System (vgl. Gronau 2004, S. 5) und mit zu langen

Einführungszeiten (vgl. von Arb 1997, S. 46). In mehreren Studien standen aus diesem Grund

die Erfolgsfaktoren bei der Einführung der SAP-Software, die diese Schwierigkeiten lösen

und die Akzeptanz für die Software bei den Mitarbeitern schaffen können, im Mittelpunkt.2

Insgesamt stellt sich die Frage nach einem möglichen Rezept der SAP AG und ihrer Software,

mit diesem man auch die Zukunft erfolgreich bestreiten kann - nach den Pfaden, welche die

SAP-Technikentwicklung beschreitet.

1 Zu diesen Abhandlungen gehören unter anderem Plattner et al. 2000, Siegele 2009, Meissner 1997 und Leim-bach 2008. 2 Zu diesen Studien gehören unter anderem Wolter 2006, Hohlmann 2007 und von Arb 1997.

4

1.1 Fragestellung und Relevanz der Thematik

Greift man die Metapher des Rezepts für den Erfolg der SAP-Technikentwicklung weiter auf,

ist ebenso zu fragen, welche Zutaten die SAP AG verwendet hat, woher diese kommen und

welchen Anteil sie an der Qualität und am Geschmack des Produktes haben oder welche und

wie viele Köche ihren Beitrag leisteten. Auf die SAP AG und ihre Software übertragen: Wo-

rin liegen die Ursachen für eine Technikentwicklung und wer beeinflusst diese? Existieren

Abhängigkeiten oder bestimmte Einflussfaktoren? Antworten auf diese Überlegungen sind

wegen des unvorhersehbaren, darwinistischen Prozesses der komplexen Entwicklung von

SAP nicht leicht zu geben, wie Hasso Plattner bestätigt. “When people ask how we planned

all this, we answer ‘We didn’t. It just happened.’ ” (Campbell-Kelly 2003, S. 191) Aus die-

sem Grund verwende ich in dieser Arbeit bei der Analyse der SAP-Technikentwicklung The-

orien, die sich generell mit Technikentwicklung und Innovationsprozessen von IT auseinan-

der setzen und meine Erläuterungen theoretisch fundieren. Die verschiedenen Gedanken bün-

deln sich in den zu klärenden Fragen: Warum und unter welchen Bedingungen, Strategien

oder Methoden, entwickelt die SAP AG ihre Produkte und in welcher Relation steht diese

Entwicklung zu Akteuren und der Gesellschaft? Was führt die SAP-Technikentwicklung auf

den Weg hin zu einer Innovation und wie gestaltet sich dieser Pfad? Das Ziel dieser Arbeit ist

die Darstellung und Erklärung der SAP-Technikentwicklung mittels der sozialwissenschaftli-

chen Techniktheorien, Technikdeterminismus und Akteur-Netzwerk-Theorie (ANT), und

schwerpunktmäßig dem Mikropolis-Modell mit der Erstellung eines SAP-

Technikentwicklungspfades. Das spezielle Interesse an diesem breiteren Fokus liegt darin, die

Entstehung und Durchsetzung der SAP-Softwareentwicklung nicht nur aus einer theoreti-

schen Perspektive zu erörtern, sondern durch Anwendung mehrerer Theorien und einer des-

halb differenzierteren Analyse auf ein und denselben Gegenstand (SAP AG und SAP-

Software) einen Überblick und eine Vergleichbarkeit der verschiedenen Ansätze zu erarbei-

ten. Die Ergebnisse dessen können die Grundlage für eine verknüpfende Betrachtung der

Techniktheorien schaffen oder sie ausschließen. Diesem Vorhaben, die sozialwissenschaftli-

chen Techniktheorien mit dem Mikropolis-Modell wenn möglich zu verbinden, wird sich

ebenfalls in ersten Schritten genähert.

1.2 Methodisches Vorgehen

Mit einer möglichst breiten theoretischen Basis und damit einem weit gefassten Analyserah-

men beabsichtige ich so viele potentielle Erklärungsmuster und Beschreibungsmöglichkeiten

von SAP-Technikentwicklungen zu erfassen, wie es für die Beantwortung der gestellten Fra-

gen nötig ist und der Umfang dieser Arbeit zulässt. So gehen die Technikdeterministen von

einer Kraft in der Technik aus, die sich entweder sofort oder zu einem späteren Zeitpunkt auf

die Gesellschaft auswirkt. Durch ihre Auseinandersetzung mit der einseitigen Wirkung von

Technik auf die Gesellschaft stellt ihre Theorie einen Pol dar, der vor allem aufgrund seiner

5

möglichen Abgrenzung zu anderen Theorien herangezogen wird. Demgegenüber steht die

ANT, eine der verschiedenen Strömungen der Science and Technology Studies. Sie stellt alle

handelnden Akteure, ob menschlich oder nicht-menschlich, auf eine ontologische Stufe und

spricht ihnen den gleichen Anteil an der Entstehung von Technik zu. Die Betonung liegt hier

auf den Netzwerken, in die Akteure eingebunden und ohne diese keine Identitäten oder Hand-

lungspotentiale vorhanden sind. Der Fokus in dieser Arbeit beschränkt sich hinsichtlich der

ANT auf die Anwendung der Übersetzung und ihren fünf Phasen Problematisierung,

Interessement, Enrolement, Mobilisierung und Dissidenz. Das Mikropolis-Modell als dritte

Techniktheorie stellt ein Analyse- und Gestaltungsmodell für IT in Organisationen und Ge-

sellschaft dar. Akteure agieren in Unternehmen mit IT, reflektieren diese und fördern oder

wirken entgegen. Aus diesen Handlungen verfestigen sich die Strukturen entweder indem die

Akteure danach handeln oder sie aufbrechen. Die Wechselwirkungen bei IT-Entwicklungen

und -Einführungen zwischen IT-anwendenden Organisationen, Informatiksystem und Gesell-

schaft werden auf den drei Ebenen soziotechnische Perspektive, Mikro-und Makrokontext

und Prozesse & Pfade beschrieben. Im Gegensatz zu bereits erforschten Techniknutzungspfa-

den liegt der Fokus dieser Arbeit auf dem SAP-Technikentwicklungspfad, einem bisher noch

wenig theoretisch erarbeiteten Untersuchungsfeld. Als offene und transdisziplinäre Theorie

umfasst das Mikropolis-Modell bereits andere Ansätze und theoretische Grundannahmen, es

kann deshalb zusätzlich zur Erklärung der SAP-Technikentwicklung hinsichtlich einer Integ-

ration des Technikdeterminismus oder der ANT in das Modell untersucht werden. Das Mik-

ropolis-Modell bildet wegen dieser genannten Aspekte den theoretischen Schwerpunkt meiner

Arbeit. Der Erklärungsgehalt der verwendeten Theorien sollte bestenfalls so hoch sein, dass

sich die Technikentwicklung der SAP-Software und die Einführung der SAP-Software in Un-

ternehmen darin jeweils vollständig wiederfinden, was für jeden Ansatz zu prüfen gilt.

Meine Ausführungen über den Technikdeterminismus stützen sich hauptsächlich auf

Rammert, W.: „Technik aus der soziologischen Perspektive 2: Kultur, Innovation, Virtuali-

tät.“ Bei der weiteren Beschäftigung mit dem soziologischen Techniktheorien wurde ich stark

von den Ausführungen von Bammé, A.: „Science and Technology – Ein Überblick“ und den

Aussagen bei Degele, N.: „Einführung in die Techniksoziologie“ inspiriert, die mir die ANT

als eine derzeit aktuelle Form der sozialwissenschaftlichen Techniktheorien vermittelten. Da-

raufhin vertiefte ich das Studium um die ANT, welche sich vor allem auf die Theorie der

Übersetzung von Callon, M.: „Einige Elemente einer Soziologie der Übersetzung: Die Do-

mestikation der Kammmuscheln und der Fischer der St. Brieuc-Bucht.“ konzentrierte. Das

Mikropolis-Modell als dritte Theorie erschloss sich durch die Seminare und Vorlesungen, die

ich an der Universität Hamburg im Fachbereich Informatik verfolgte.

Die einführende Beschreibung der SAP-Technikentwicklungswege in Daten und Fakten be-

zieht sich einerseits auf Literaturquellen und andererseits auf qualitative wie quantitative Stu-

dien zur Einführung der SAP-Software. Sie fasst die verfügbaren Informationen über das Un-

ternehmen SAP AG und dessen Technikentwicklung vor dem Hintergrund der drei Theorien

6

zusammen. Das Unternehmen SAP wird in dieser Arbeit vollständig mit seinem aktuellen

juristischen Namen SAP AG bezeichnet. Beziehen sich die Überlegungen oder die Analyse

sowohl auf das Unternehmen als auch untrennbar von diesem auf die SAP-Software ist auf

eine nähere Bestimmung verzichtet und nur SAP verwendet. Insgesamt gehe ich in dieser

wissenschaftlichen Arbeit deskriptiv vor. Die Entwicklung wird ohne Bewertung auf Normen

dargestellt und analysiert, eine reine Beschreibung und Erklärung der SAP-

Technikentwicklungspfade mittels der sozialwissenschaftlichen Techniktheorien und des

Mikropolis-Modells stehen im Vordergrund.

1.3 Überblick über die Arbeit

Die theoretische Einbettung erfolgt in Kapitel 2, da aus den jeweiligen Grundannahmen der

Theorien die breit gefächerte Sichtweise auf Technikentwicklungen herausgestellt wird. In

Kapitel 3 verfolge ich die SAP-Entwicklung und die Einführung der SAP-Software über die

Jahre hinweg und stelle einschneidende Innovationen oder bedeutende Handlungen vor.

Schon hier wird auf die Beschreibung von SAP initiierten Handlungen oder solchen, die auf

SAP wirken, Wert gelegt. Jedem Zeitabschnitt und damit der Technikentwicklungen folgt

eine Zusammenfassung wichtiger Faktoren, Leitbilder und Strategien. In Kapitel 4 werden

dann die theoretischen Prämissen auf die Entwicklungsprozesse angewandt und auf ihren je-

weiligen Erklärungsgehalt hin untersucht. Hierbei stehen sowohl Innovationen als auch Fehl-

entwicklungen und Brüche im Fokus der Analyse. Das Mikropolis-Modell gestaltet sich hier-

bei umfassender, da neben der Anwendung auf den Ebenen die Erarbeitung des SAP-

Technikentwicklungspfades in Anlehnung an den Techniknutzungspfad Büro erfolgt. Die

Ergebnisse der Anwendung aller drei Theorien werden im 5. Kapitel dazu benutzt, Argumente

für oder gegen eine Eingliederung des Technikdeterminismus oder der ANT in den Orientie-

rungsrahmen des Mikropolis-Modells zu erarbeiten. Allerdings haben diese Ausführungen

lediglich einen einführenden Charakter, die Analyse der Gemeinsamkeiten und Unterschiede

ist demnach nicht abgeschlossen und vor allem auf die Auseinandersetzung mit der Technik-

entwicklung um die SAP AG beschränkt. Abschließend konzentriere ich mich auf die kriti-

sche Auswertung der Ergebnisse und die sich eröffnenden Fragestellungen.

Für die Lektüre seien mir vom Leser mögliche Wiederholungen hinsichtlich der SAP-

Technikentwicklung nachzusehen, da sich aufgrund der Analyse eines Untersuchungsgegen-

standes mittels dreier verschiedener Theorien Überschneidungen minimieren aber nicht ver-

meiden ließen und eine zu starke, subjektive Beschränkung der Analysebasis umgangen wer-

den sollte.

7

2. Sozialwissenschaftliche Techniktheorien und das Mikropolis-Modell

Die sozialwissenschaftlichen Techniktheorien und das Mikropolis-Modell bieten einen Erklä-

rungsrahmen für die Beziehung zwischen Technik und der Gesellschaft an. Ich beginne mit

der Beschreibung des Technikdeterminismus und der Aussage, dass die Technik eine Kraft

inne hat, welche die Gesellschaft leitet. Die direkte Kritik an dieser Annahme findet sich zu-

erst in der Wissenschaftsforschung und wird in den Social Shaping of Technology (SST-)

Theorien weiter ausgearbeitet. Ich fokussiere mich hier auf die ANT und die Beschreibung

jener. Anschließend ziehe ich das Mikropolis-Modell heran, welches im Gegensatz zu den

erst genannten Erklärungsansätzen beziehungsweise Theorien einen heuristischen Orientie-

rungsrahmen darstellt. Jede Theorie gibt Analysemuster an die Hand um die Entwicklung der

Technik in der Gesellschaft zu verstehen. So stellt der Technikdeterminismus die Formen und

Grade der Wirkung von Technik auf die Gesellschaft, die ANT die Übersetzung und das Mik-

ropolis-Modell die strukturgebenden Elemente, soziotechnische Perspektive, Mikro- und

Makrokontext und Prozesse und Pfade, zur Verfügung.

2.1 Technikdeterminismus

Wie sind die gesellschaftlichen Folgen der Technik einzuschätzen? Was bringen die Schrift-

technik, der Steigbügel, der Buchdruck, die elektronischen Medien usw. für die Entwicklung

der Gesellschaft? Den Aussagen der Technikdeterministen nach liegt der Technik eine sub-

versive Kraft zugrunde, nach der sich die Gesellschaft zu richten hat. Dabei „[…] macht [es]

keinen Unterschied, ob aus optimistischer Sicht die Technik als Motor des Fortschritts oder

aus pessimistischer Sicht als Sachzwang angesehen wird; hinter beiden Sichtweisen auf die

Technikfolgen steckt die Annahme eines Technikdeterminismus.“ (Rammert 2000, S. 48)

Man kann drei Ausdifferenzierungen dieser Sichtweise benennen: den starken, den etwas

schwächeren und den weichen Technikdeterminismus.

Die Betonung auf die reine Sachlichkeit der Artefakte benennt den stark technischen Deter-

minismus. Hiernach gelten technische Innovationen als Bedingung für die Durchsetzung von

gesellschaftlichen Veränderungen. Pferd, Eisenbahn, Auto, und Flugzeug beispielsweise ver-

kleinern die Räume, verändern die Kriegsführung und erhöhen die Tempoanforderungen im

Alltag (vgl. Virilio 1989). Die etwas schwächere Form des Technikdeterminismus entsteht

durch die stärkere Betrachtung zeitlicher Differenzen, wonach Erfindungen und technische

Neuerungen den Entwicklungen auf anderen gesellschaftlichen Feldern vorrausgehen. In die-

sem Zusammenhang stehen die Aussagen des bedeutendsten Vertreters dieser Programmatik,

William F. Ogburn. Er prägte den Begriff des sozialen Wandels für die gerichtete Verände-

rung der Gesellschaft mit der Eigenentwicklung einzelner Bereiche. „Sozialer Wandel findet

dann statt, wenn die Entwicklung in einem Bereich andere gesellschaftliche Bereiche zu einer

Anpassung zwingt, zumindest aber sie unter Anpassungsdruck setzt. […] Technische Erfin-

dungen üben einen Zwang zur Anpassung auf Wirtschaft und andere soziale Institutionen aus;

8

diese Impulse setzen sich mit umso geringerer Geschwindigkeit fort, je ferner ein Lebensbe-

reich von der Technik ist. Kulturelle Institutionen sind damit in der Reihenfolge der

Veränderer die Schlusslichter.“ (Scheuch 2003, S. 148) Das Hinterherhinken der gesellschaft-

lichen hinter der technischen Entwicklung, das Zurückbleiben des Kulturellen wird mit cultu-

ral lag bezeichnet (vgl. Ogburn 1950). Seit der Gründung der Technikfolgenabschätzung3 im

Jahr 1936 basieren die heutigen Technikvorhersagen und die Technikfolgen-Forschung im

Grunde noch immer auf dieser Theorie (vgl. Rammert 2000, S. 49). Der weiche Technikde-

terminismus hingegen berücksichtigt die Wechselwirkungen zwischen der Technik und den

sozialen Formen in der Form stärker, so dass erst eine Verknüpfung der Technik mit der Ge-

sellschaft Technostrukturen erschafft. Diese stehen folglich für die Verbindung der techni-

schen Möglichkeiten mit den gesellschaftlichen Eigentumsverhältnissen, ökonomischen Ord-

nungen, politischen Regimes und kulturellen Orientierungsmustern. Diese Strukturen zeich-

nen den zukünftigen Weg der Entwicklung vor; es entsteht ein lock in, eine Fesselung an ein-

mal beschrittene Pfade der Technikentwicklung. Den Prozess, dass die Gesellschaft der Tech-

nik folgt, wird bei dem weichen Technikdeterminismus als technische Trägheit beschrieben

(vgl. Rammert 2000, S. 50). Ein Beispiel hierfür ist die Veränderung der Arbeit vom Hand-

werk zur Maschinenbedienung in der Fabrik (vgl. Braverman 1977).

All diesen Aussagen nach handelt es sich bei der Technik um etwas Außersoziales. Sie befin-

det sich in der Umwelt der Gesellschaft und steht mit ihr in einer Ursache-Wirkung-

Beziehung. In diesem Bezugsrahmen stehen die Schlagwörter Technik als Sachzwang, techni-

sche Gesellschaft und Technokratie (vgl. Degele 2002, S. 38). In diesem Sinne besteht eine

Vorherrschaft der Technik gegenüber der Gesellschaft. Die Technik erscheint den Menschen

als alternativloses Ereignis, auf das sie keinen Einfluss haben. Insofern kann man die Technik

als ein Politikum betrachten, da sie nicht neutral in der Gesellschaft steht, sondern den jewei-

ligen Besitzern einer Technologie völlige Handlungsfreiheiten einräumt. Die Herrschaftsam-

bitionen der Besitzer werden wiederum durch Technik gestützt.

2.2 Akteur-Netzwerk-Theorie

In den siebziger Jahren versuchte die Wissenschaftsforschung die Ansätze von dem Technik-

determinismus durch verschiedene Studien zu widerlegen. „[…] der späte Ludwig Wittgens-

tein hat uns belehrt, dass sogar die rigoroseste symbolische Technik, die mathematische Lo-

gik, auf Sprachspiele des Alltags angewiesen ist.“ (vgl. Rammert 1998, S. 300) Beispiele für

die Vielfältigkeit solcher Sprachbeispiele finden sich in Wittgensteins „Philosophische Unter-

suchung“ von 1953 unter anderem in § 23 „[…] eine Hypothese aufstellen und prüfen […]

Darstellen der Ergebnisse eines Experiments durch Tabellen und Diagramme […] ein ange-

3 Die Technikfolgenabschätzung liefert seit dem Jahr 1936 einen regelmäßigen Trendreport über zukünftige Erfindungen und ihre Folgen an die US-Amerikanische Regierung (vgl. Rammert 2000, S. 49).

9

wandtes Rechenexempel lösen […]“ Des Weiteren hat sich unter anderem4 Schegloff mit Re-

geln in der Alltagskommunikation konzentriert beschäftigt und Kausalitäten herausgearbeitet

(vgl. Schegloff 1972, S. 346). „In other words, there are constraints on the „contents“ of a

speaker’s remarks once a conversational course is entered into […]” (Schegloff 1972, S. 378)

Gemeinsam ist diesen Überlegungen die Berücksichtigung von Sprache und Kommunikation

als Faktoren in der Analyse von Alltagshandlungen und auf naturwissenschaftlichen Ebenen -

der Einbezug von Sozialem. Diese angenommene Beteiligung der kommunizierenden und

dadurch mitwirkenden Akteure in der Wissenschaftsforschung wurde auch in der Technikfor-

schung übernommen und so gingen aus diesem Bereich verschiedene Ansätze, wie das Edin-

burgh Strong Programme (ESP) und das Empirical Pogramme of Relativism (EPOR) hervor.

Im Folgenden wird ausgehend von diesen Ansätzen die weitere Entwicklung hin zur ANT

beschrieben und anschließend im Speziellen auf die Übersetzung eingegangen.

2.2.1 Der Weg zur Akteur-Netzwerk-Theorie

Die Ansätze ESP und EPOR, die dem Technikdeterminismus entgegengesetzt wurden, zielten

darauf ab, naturwissenschaftliche Theorien und Forschungen als soziale und interessengebun-

dene Konstruktionen zu demaskieren (vgl. Bammé 2009, S. 129). Das wissenschaftliche Wis-

sen ist empirisch unterdeterminiert: „Wissenschaftliches Wissen ist kontingentes Wissen. Zu

jedem Problembereich kann es im Prinzip verschiedene, funktional äquivalente Theorien ge-

ben. Aus diesem Grund ist wissenschaftliche Forschung ein prinzipiell offener, unabgeschlos-

sener Prozess. Es gibt kein absolutes, erst recht kein empirisches Kriterium, das ein für alle-

mal die Wahrheit einer theoretischen Aussage entscheidet.“ (Bammé 2009, S. 43) Vielmehr

hat die Durchsetzung wissenschaftlicher Erkenntnisse ihre Ursachen ebenfalls in dem Verfü-

gen über finanzielle Ressourcen und in den vorhandenden Machtverhältnissen. So setzten

Pons und Fleischmann, zwei Elektrochemiker, mit der Veröffentlichung ihrer Arbeiten, die

auch die Kernphysik betraf, ihre Glaubwürdigkeit aufs Spiel, weil „[…] kein Wissenschaftler

hoffen durfte, eine so mächtige und fest im Sattel sitzende Gruppe wie die Physiker heraus-

fordern zu können […]“ (vgl. Collins 1999, S.95) Damit erweist sich wissenschaftliches Ar-

beiten als flexibel und nicht determiniert. Diese Flexibilität strukturierte Collins, ein Vertreter

des EPOR-Ansatzes, in seinem Drei-Phasen-Modell, welches die Verbundenheit der For-

schung mit der Gesellschaft aufzeigen sollte. Als Erstes wird die interpretative Flexibilität der

Versuchsdaten nachgewiesen, zweitens der Schließungsmechanismus vorgestellt, der potenti-

ell offene Debatten zu einem Abschluss bringt, drittens der Schließungsmechanismus mit ei-

ner weit gefassten sozialen und politischen Struktur verknüpft (vgl. Collins 1985, S. 25f).

Die Technikforschung der achtziger Jahre nimmt die Ansätze der Wissenschaftsforschung

wieder auf und geht ebenfalls in Abgrenzung zu den technikdeterministischen Ansätzen von

einer weit reichenden Verwobenheit von Technischem und Sozialem aus (vgl. Bammé 2009,

4 Seine Arbeiten lehnen sich an die von Goffman und Sacks an (vgl. Schegloff 1972, S. 348).

10

S. 129). Die Technik wirkt demnach nicht länger von außen, sondern ist integraler Bestandteil

der menschlichen Vergesellschaftung; die Gesellschaft kann nicht ohne ihre technische Ver-

mittlung begriffen werden (vgl. Rammert 1998, S. 301). Umgekehrt durchdringt in diesem

Ansatz das Soziale auch die Technik. Die SST ist geboren. Sie versucht durch verschiedene

empirische Studien nachzuweisen, dass die Verwendung von Technik gesellschaftlich gestalt-

bar ist (vgl. Bammé 2009, S. 129). Als typische Vertreter hierfür gelten die Social Constructi-

on of Technology (SCOT) und die ANT. Das Vorgehen bei SCOT zu skizzieren, hilft die in

einem eigenen Kapitel erläuterte ANT besser zu verstehen. SCOT beschreibt den Prozess der

sozialen Konstruktion von wissenschaftlichem Wissen in der harten Wissenschaft und gibt

damit eine Erklärung für die Entwicklung der Technik durch soziale Akteure. Dabei wird das

Drei-Phasen-Modell aus EPOR genutzt und auf die Entwicklung von Technik wie folgt an-

gewendet (vgl. Bijker et al. 1987, S. 40f): Bei der interpretativen Flexibilität sehen unter-

schiedliche soziale Gruppen oder Akteure verschiedene Dinge in ein und demselben Artefakt5

und bringen ihre eigenen Interpretationen mit in die Entwicklung ein. Die beteiligten Gruppen

verändern die Artefakte in einem alternierenden, nicht-linearen Prozess der Variation und

Selektion von Designs und Problemkonstruktionen. Der Schließungsmechanismus, zweite

Phase, selektiert die verschiedenen Möglichkeiten und bringt, in der dritten, bei der Stabilisie-

rung die verschiedenen Konflikte zu einem Abschluss. Die Entwicklung des Fahrrads zum

Beispiel verlief von dem Hochrad über das Fahrrad mit Vorderradantrieb hin zu dem heutigen

durch das Hinterrad angetriebene (vgl. Bijker et al. 1987, S. 28f). Bis zum Endprodukt waren

die technischen Entwicklungen Ergebnisse von Konflikten und Interessensaushandlungen

zwischen den Akteuren. Im Verlauf dieses Prozesses gab es immer weniger Alternativen zur

Auswahl. Nach der Selektion verschiedener Möglichkeiten einigten sich die beteiligten Grup-

pen auf die endgültige Interpretation, die so genannte Schließung und Stabilisierung. Damit

erweitert sich insgesamt der Blick auf die Durchsetzung von technischen Innovationen um die

Einflüsse von sozialen Gruppen auf diese und die Probleme mit denen die Gruppen in diesen

Prozessen zu kämpfen haben.

2.2.2 Die Grundlagen der Theorie und der Übersetzung

Charakteristisch für die ANT ist der Versuch der Konstruktion einer symmetrischen Anthro-

pologie, welche die Trennung zwischen Natur und Gesellschaft, Technik und Sozialem,

Internalismus und Externalismus, menschlichen und nicht-menschlichen Akteuren verwirft

(vgl. Latour 2007, S.121f und 124). Sie stellt die natürlichen, sozialen und technischen Gege-

benheiten auf eine gemeinsame ontologische Stufe und spricht ihnen den gleichen Status zu.

Durch diese Symmetrie wird nicht mehr behauptet, dass Technik etwas Außersoziales ist und

sich Soziales allein durch Soziales erklärt (vgl. Bammé 2009, S. 106). Die soziale Ordnung ist

rein soziologisch „[…] nicht mehr angemessen zu verstehen, weil die überhandnehmenden

5 Unter einem Artefakt wird all jenes bezeichnet, was von Menschenhand geschaffen wurde.

11

Prozesse der Technisierung sowohl physischen Materialien, Texte, Maschinen, Organisatio-

nen, Anweisungen, geografischen Widerständen usw. in ein alles übergreifendes Netz

„seamless web“ einweben.“(Ebenda) Die zentralen Einheiten in diesem Netz sind die Aktan-

ten, denen darin – gleichgültig ob Mensch oder Sache – Handlungsfähigkeit zugesprochen

wird. Zur Verdeutlichung dieser These gebe ich einige Überlegungen hinsichtlich der Frage

wieder, ob die Waffe oder der Mensch tötet (vgl. Latour 1998, S. 33f). Die Antwort nach der

ANT lautet, dass weder die Schusswaffe noch der Mensch tötet. Die Waffe hat nicht allein die

Bestimmung einen Menschen zu töten, sondern besitzt von sich aus ein weit größeres An-

wendungsspektrum. Die interpretative Flexibilität aus dem Drei-Phasen-Modell von EPOR

und SCOT findet hier ihre Anwendung. Die Waffe modifiziert den Träger (aus dem braven

Bürger wird ein Mörder) und das Objekt (aus dem Sportgerät wird ein Mordinstrument). Es

entsteht ein Hybrid-Aktant aus Waffe und Schütze, die zusammen handeln, hier morden. Die-

ses gemeinsame Agieren und verbunden in einem Netzwerk handeln wird bei der ANT Über-

setzung genannt. Es entsteht eine Verbindung, die in dieser Form vorher nicht da war.

Die Übersetzung oder der Prozess des Netzwerkbildens ist vergleichbar mit der interpretati-

ven Flexibilität, der Schließung und Stabilisierung des Drei-Phasen Modells, welches durch

SCOT aus der Wissenschaftsforschung in die Technikforschung geholt wurde (vgl. Bammé

2009, S. 107 und Degele 2002, S. 133f). Die fünf nicht überschneidungsfreien Phasen der

Übersetzung beschreiben das Handeln unter zeitlichem Aspekt bei der Netzwerkbildung (vgl.

Callon 1996, S. 146f). Der Begriff Netzwerk ist in diesem Zusammenhang nicht als reines

Aufzeigen von Beziehungs- oder Verbindungskonstellationen zu verstehen, sondern als ein

Handlungskontext, in dem Akteure hinsichtlich der Technikentwicklung nur gemeinsam et-

was bewirken.

Abb. 05: Phasen der Übersetzung (eigene Darstellung)

1. Bei der Problematisierung werden unterschiedliche Verbündete angeworben, um Allianzen

zu bilden und damit die eigenen Interessen durchzusetzen. Dies erfolgt durch eine Verschie-

bung der Ziele anderer Akteure hin zur Stützung der eigenen. Der Punkt, an dem sich die Ak-

teure den eigenen Interessen beugen und eine Allianz möglich erscheint, wird obligatorischer

Passagepunkt (OPP) genannt.

12

2. Die zweite Phase beschreibt das Interessement, jene Menge von Handlungen durch die ein

Akteur versucht, die Identität anderer Akteure zu beeinflussen. Dabei baut dieser Akteur

Schranken zwischen sich und jenen anderen Akteuren auf, die ebenfalls um den interessieren-

den Akteur konkurrieren. A interessiert B und deshalb schwächt A die Verbindungen und

Beziehungen von B zu den Akteuren C, D und E (vgl. Abbildung 06).

Abb. 06: Das Dreieck des Interessements (Callon 1996, S. 153)

3. In der dritten Phase, dem Enrolment, wird der Prozess des Interessments durch eine Folge

multilateraler Verhandlungen und Strategien begleitet und kann dadurch den Interessen des

Akteurs zum Erfolg verhelfen.

4. Die darauf folgende Phase, die Mobilisierung, ist vergleichbar mit dem Wahlverfahren zur

Bestimmung eines Sprechers und der Repräsentation mehrerer Akteure durch diesen einen.

Die Handlungen und Verhandlungen aus der vorherigen Phase führen zu einem Konsens, der

die verschiedenen Akteure und ihre jeweiligen Beziehungen zu einem zwingenden Netzwerk

verknüpft.

5. Abschließend kann noch in der fünften Phase die Dissidenz erfolgen. Die Repräsentativität

des Sprechers wird in Frage gestellt, Kontroversen um Manifestationen kommen auf, wo-

durch Allianzen auseinander fallen können. Diese Phase ist jedoch nicht obligatorisch die

letzte, denn der Ablauf des Phasenmodells kann bereits zwischendrin immer wieder von neu-

em beginnen.

Demgemäß beschreibt die Übersetzung den Versuch eines Akteurs, die Interessen aller Ak-

teure den eigenen gleichzuschalten. Die beteiligten Akteure mit ihren Interessen und Konflik-

ten sind gleichzeitig Elemente und Resultate des durch die Übersetzung neu formierten Netz-

werkes. Der dominante Akteur versucht durch Delegationsprozesse den anderen am Netzwerk

Beteiligten bestimmte Rollen und Funktionen zuzuweisen oder sie in bestehenden zu bestäti-

13

gen. Durch die symmetrische Anthropologie von ANT weiten sich die Delegationsprozesse

auf menschliche und nicht-menschliche Akteure aus und es gehen immer mehr Regelungen

sozialer und zwischenmenschlicher Art auf Objekte oder technische Artefakte über. Die Ak-

teure können einerseits selbst aus der Technik bestehen, als Hybrid-Akteur auftreten, oder

andererseits kann die Technik selbst die Verbindungen zwischen den Akteuren härtend auf-

rechterhalten. Der Grad der Konsistenz und Festigkeit dieser Verbindungen unterscheidet sich

nach Art der Delegationsprozesse und danach wie stark diese zwischen den Akteuren wirken.

Die Durchsetzung der Technik in der Gesellschaft hängt nicht von dem einzelnen Akteur oder

Hybrid-Akteur ab, sondern von den Verbindungen zu dem beteiligten Netzwerk, ohne jenes

die Akteure handlungsunfähig bezüglich der Technikentwicklung wären. Durch die Überset-

zung mit der symmetrischen Anthropologie können Kollektive beliebiger Größenordnung

beschrieben und verglichen werden.

2.3 Mikropolis-Modell

Die Entstehungsgeschichte des Mikropolis-Modells ist mit dem Jahr 1985 verbunden und

dem damals von Arno Rolf und Herbert Kubicek veröffentlichtem Buch „Mikropolis - mit

Computernetzen in die Informationsgesellschaft“ (vgl. Kubicek und Rolf 1985). Dort wurden

die Entwicklung der Telekommunikation und ihre gesellschaftlichen Auswirkungen analy-

siert. Der Begriff Mikropolis, die Zusammenfügung von Mikroelektronik und Polis6, verweist

auf die Herausforderung bei der Schlüsseltechnologie IT die Wechselwirkungen zwischen

sozialen und technischen Implikationen zu berücksichtigen. An dem Department Informatik

der Universität Hamburg wird das Mikropolis-Modell gelehrt und weiterentwickelt. Es bietet

ein Analyse- und Gestaltungsmodell für IT-Entwicklung und -Nutzung an. Hierbei werden die

tief greifenden Prozesse des gesellschaftlichen, kulturellen, ökonomischen und politischen

Wandels von der individuellen bis zur globalen Ebene in die Betrachtung und Bewertung mit

einbezogen. Das sich damit befassende Buch „Mikropolis 2010: Menschen, Computer, Inter-

net in der globalen Gesellschaft“ von Arno Rolf erörtert die vielfältigen und komplexen

Wechselwirkungen zwischen dem Einsatz von IT und sozialen und organisatorischen Zu-

sammenhängen (vgl. Rolf 2008, S. 5f). Das Mikropolis-Modell ist in das Mikropolis-

Netzwerk eingebunden, welches eine transdisziplinäre Plattform für den multidisziplinären

Austausch von Wissenschaftlern und Praktikern mit dem Ziel bietet, eine gemeinsame Spra-

che über Fachgrenzen hinweg zu finden.

Das Mikropolis-Modell enthält drei strukturgebende Elemente. Der soziotechnische Kern

umfasst „[…] die Wechselwirkungen von menschlicher und technischer Symbolverarbeitung

[…]“ (vgl. Rolf 2008, S. 96). Der Mikro-und Makrokontext betrachtet die IT-Entwicklung

und Nutzung in ihrem Umfeld. Der Mikrokontext fokussiert hierbei die Wechselwirkungen

auf der Ebene der IT-Produzenten im Informatiksystem und der IT-Nutzer in IT-anwendenden

6 Polis steht für das altgriechische Wort Stadt oder Staat.

14

Organisationen. Der Makrokontext rückt dazu gesellschaftliche Phänomene7 in das Blickfeld,

welche wiederum mit dem Mikrokontext in Wechselwirkung stehen. Die Prozesse und Pfade

sind das dritte strukturgebende Element und stellen die aus dem Mikrokontext (inklusive so-

ziotechnische Perspektive) und dem Makrokontext gewonnenen Erkenntnisse in einer zeitli-

chen Entwicklung dar. Die Technikentwicklungs- und nutzungspfade erweitern die Analyse

demzufolge um eine historische Perspektive, welche bei der Einschätzung zukünftiger Ent-

wicklungen helfen kann und soll (vgl. Rolf 2008, S. 95f).

2.3.1 Soziotechnischer Kern - erfolgreiche Übertragung operationalisierter Handlungen

auf Informationstechnik

Die Überführung von menschlichen Handlungen in technologische Artefakte und die Auswir-

kung dieses Vorgangs auf die Handlungen von und zwischen Menschen beschreibt die sozio-

technische Perspektive. Das menschliche Handeln findet unter bestimmten Bedingungen statt

und jede Situation ist einmalig (situiertes Handeln). Durch Beobachtungen sollen jedoch jene

Handlungen beschrieben werden, die bereits zu Routine geworden sind und wiederholt statt-

finden (Operationen). Hat man die Operationen identifiziert, bildet man daraus die autoopera-

tionale Form und schreibt sie abschließend kontextunabhängig in Algorithmen und Program-

men fest. Eben dieser Gesamtprozess von der Beobachtung im Anwendungskontext bis hin

zum Schreiben von Algorithmen und Programmen, die keinen unmittelbaren Bezug mehr zum

Anwendungskontext enthalten, nennt sich Dekontextualisierung. Der Bezug zum Kontext

wird erst durch die Rückführung und Interpretation der Algorithmen und Programme von

anwendenden Akteuren wiederhergestellt. Hierfür steht die Bezeichnung der

Rekontextualisierung. Dabei müssen die technischen Resultate wieder von Menschen in eige-

ne Handlungen eingebunden und ihr Verhalten an dem formalen Modell ausgerichtet werden.

Tradierte Handlungen müssen überdacht und neu strukturiert werden, woraus Nebenfolgen

resultieren können. Zum Beispiel treten Probleme bei der Aneignung der Programme auf, die

bis zu einer Verweigerung der Nutzung führen. Des Weiteren werden möglicherweise Ratio-

nalisierungen und Umverteilungen der Arbeit durch Programmierer ausgelöst. Der Gesamt-

prozess der De- und Rekontextualisierung wird in Abbildung 07 grafisch dargestellt.

7 Gesellschaftliche Phänomene sind unter anderem gesellschaftliche Normen, Werte, rechtliche Regelungen und Phänomene wie Deregulierung sowie Globalisierung. Sie werden an dieser Stelle lediglich erwähnt und in den Ausführungen zum Makrokontext genauer erörtert.

15

Abb. 07: Die Sicht auf den soziotechnischen Kern (Vorlesung Rolf 2010, S. 21)

Die De- und Rekontextualisierung sind gleichzeitig eine Destruktion und erneute Konstrukti-

on des jeweiligen Kontextes. „Das Neue, auch das Bessere, erwächst immer aus der Destruk-

tion des Alten. Durch die technische Auflösung gegebener Lebenszusammenhänge wird eben

auch freigeräumt, werden Verkrustungen aufgebrochen, wird Raum geschaffen für Anderes.“

(Sesink 2003, S. 61) Dieses Prinzip ist auch Teil der Innovationsspirale aus dem Mikrokon-

text. Die Einbettung der soziotechnischen Perspektive in diesen wird von dieser Seite aus

vollzogen.

2.3.2 Mikrokontext - Technikentwicklung im Wechselspiel der Akteure

Im nun folgenden Mikrokontext wird der soziotechnische Kern um die Betrachtung der

Wechselwirkungen (Pfeile in Abbildung 08) zwischen den beteiligten Akteuren, dem Infor-

matiksystem (rechts), der IT-Projektorganisation (mittig) und den IT-anwendenden Organisa-

tionen (links) erweitert. Unter dem Informatiksystem verstehen sich einerseits die IT-

Forschungs- und Entwicklungseinrichtungen, zum Beispiel Universitäten oder private sowie

staatliche Forschungseinrichtungen und andererseits die IT-Hersteller, zum Beispiel die SAP

AG oder IBM. Ziel dieser Akteure ist es, den bestehenden Wissen- und Erkenntnisstand per-

manent in Frage zu stellen, um etwas Neues zu entwickeln. Die IT-anwendenden Organisati-

onen stehen für die Nutzer der IT-Produkte, welche private Unternehmen und auch öffentliche

Verwaltungen sind. Die Kommunikation zwischen den Organisationen und dem Informatik-

system äußert sich neben direkten Anfragen und Kontakten ebenfalls in laufend gebildeten

Projekten, in denen die Organisations- Prozess-, Unterstützungs- und IT-Architektur der Un-

ternehmen neu gestalten werden.

16

Abb. 08: Wechselwirkungen zwischen Organisation und Informatiksystem (Vorlesung Rolf

2010, S. 36)

Innovationsentwicklungen lassen sich zu einem beträchtlichen Teil aus den Wechselwirkun-

gen von Informatiksystemen und Organisationen erklären. Die IT-Hersteller, -Forschung und

-Entwicklung sind verantwortlich für den technology push. Dieser bezeichnet das kontinuier-

liche Offerieren einer Vielzahl von neuen Modellen, Methoden und Produkten an die Organi-

sationssysteme. Damit reagieren sie auf Anfragen oder lösen diese aus und sie beobachten

außerdem die IT-Strategien der Organisationen, um Erfolgspotentiale für die Zukunft zu er-

kennen. Die Organisationen sorgen hingegen für den demand pull, das ständige Aussenden

von Signalen in Form von Anfragen, Anforderungen, Beobachtungen des Marktes, Studieren

der Fachpresse, Messebesuchen und Informationssammlung von Unternehmensberatern und

Softwarehäusern. Das Informatiksystem kann demzufolge sein technology push so ausrichten,

dass die anwendenden Organisationen ihre notwendigen Informationen in den entsprechenden

Arenen, zum Beispiel durch die Presse und durch Messen, für den demand pull erhalten. Die

Akteure beobachten sich gegenseitig, versuchen so Marktchancen zu nutzen und aktuelle Be-

darfe zu erkennen oder zukünftige zu prognostizieren. Aus dem Angebot der Informatiksys-

teme, der Nutzung dessen durch Organisationen und aus der wechselseitigen Beobachtung der

Organisationen und des Informatiksystems entsteht eine dynamische Spirale: die Innovations-

spirale (vgl. Abbildung 09). Diese beobachtenden, IT-entwickelnden und innovationstreiben-

den Aktivitäten fördern zwar vorerst viele kleine Erkenntnisse und Modifikationen der beste-

henden Lösungen, diese schreiten jedoch durch die beständige Technikentwicklung der Inno-

vationsspirale immer weiter voran und können so in radikalen Innovationen münden. Damit

aus einer IT-Invention eine Innovation wird, muss diese am Markt ihren Absatz finden. Das

wiederum hängt einerseits davon ab, ob die jeweiligen Akteure diese akzeptieren, kaufen und

bedienen können und andererseits davon, wie ausgeprägt die Marktmacht des Herstellers oder

dessen Marketingaktivitäten sind. Die Dynamik dieser Spirale wird von verschiedenen Fakto-

ren beeinflusst: unter anderem von der Wettbewerbssituation auf den Märkten, der For-

schungsinfrastruktur, dem Vorhandensein eines Innovationsmilieus, der Akzeptanz der Kon-

sumenten, der Benutzerfreundlichkeit und von der Markenmacht der Hersteller (vgl. Rolf

2008, S. 147).

17

Abb. 09: Die Innovationsspirale (Vorlesung Rolf 2010, S. 37)

Das Menschenbild der beteiligten Akteure basiert nicht auf dem homo oeconomicus8 oder

homo technicus9, sondern berücksichtigt Merkmale wie Fairness, Vertrauen, Solidarität, aber

auch Eigeninteresse. Dabei handeln die einzelnen Akteure durchaus nicht friedlich in den ver-

schiedenen Arenen. Sie sind vielmehr von individuellen Interessen, Wertvorstellungen und

Emotionen geleitet, die sie nach Möglichkeit durchsetzen wollen. Gleichwohl können die Ak-

teure ihre einzelnen Handlungen untereinander koordinieren, sich zusammenschließen und

werden so vom außenstehenden Betrachter als eine Einheit wahrgenommen, als eine kollekti-

ve Handlungseinheit. Das Informatiksystem ist zum Beispiel eine kollektive Handlungsein-

heit, in dem wiederum die IT-Hersteller sowie Wissenschaftler an Universitäten und For-

schungseinrichtungen miteinander koordinieren, aber auch konkurrieren. Die Interessen und

Absichten der Akteure sind oft nicht explizit erkennbar, dagegen implizit in Leitbilder und

Metaphern ausgedrückt und durch sie interpretierbar. Dabei generieren mächtige Akteure10

Leitbilder, in denen sich Orientierungen, Werte, Sinn sowie Zeitgeist bündeln und nutzen de-

ren Macht, um ihre Interessen frühzeitig in eine Richtung zu lenken. Beispiele für Leitbilder

sind Arbeitszerlegung, Prozessorientierung, Modularisierung und Outsourcing. Im positiven

8 Die Theorie um den homo oeconimicus geht von einem egoistisch-rational handelnden Menschen aus. 9 Die Theorie um den homo technicus besagt, dass er von dem technischen Fortschritt überzeugt ist und diesen sofort und freudig nutzt. 10 Es kann sich um große Firmen, Autoren der Managementliteratur sowie Unternehmensberater handeln.

18

Fall können sie Orientierungs- und Vermittlungshilfen sein, welche die Komplexität der glo-

balen Ökonomie reduzieren. Im negativen Fall fehlt den Leitbildern die nötige Akzeptanz und

sie werden damit zu Nahtstellen für Brüche und Optionen.

Die Handlungen der Akteure sind jedoch nicht beliebig, sondern begrenzt durch Strukturen.

In diesem Zusammenhang wird auf die Strukturationstheorie von Giddens und deren Erweite-

rung bei Orlikowski Bezug genommen (vgl. Rolf 2008, S. 110f). Die Strukturationstheorie

von Giddens thematisiert die Wechselwirkung, die Dualität von Handlung und Struktur (vgl.

Giddens 1997, S. 67f). Die sozialen Akteure produzieren und reproduzieren durch ihre Hand-

lungen die Bedingungen (Struktur), die ihr Handeln ermöglichen. Strukturen sind sowohl das

Medium als auch das Ergebnis sozialen Handelns (vgl. Giddens 1997, S. 77). Unter Handeln

wird der teils bewusste, teils unbewusst verändernde oder stabilisierende Eingriff der Akteure

in die soziale Welt verstanden. Die Akteure handeln reflexiv, sie beziehen Vergangenes, Ge-

genwärtiges, zukünftig Erwartetes und das Verhalten anderer sowie vorhandene Strukturen in

ihre Handlungen mit ein. Strukturen sind institutionelle, dauerhafte Gegebenheiten wie Re-

geln und Ressourcen. Zu diesen zählen auch Organisationen, die immer wieder neu, rekursiv

über das organisierte und reproduzierte Handeln der Akteure aufrecht erhalten werden. Die

Akteure können jederzeit in das soziotechnische Gebilde eingreifen und die Strukturen verän-

dern oder sie bestätigen. Die Flexibilität der Handlungen der Akteure ist mit der interpretati-

ven Flexibilität aus SCOT vergleichbar. Ähnlich wie bei der Schließung in dem Drei-Phasen-

Modell erfolgt eine Stabilisierung der Handlungen, welche sich später zu einer Struktur ver-

härten. Dieses Zusammenspiel von Handlung und Struktur erweitert die reine

akteursorientierte Perspektive, wie sie SCOT vorgegeben hat, um eine strukturorientierte

Sichtweise (vgl. Rolf 2008, S. 111). Orlikowski fügt dieser Dualität die Ebene der Technik

hinzu. Das dadurch entstehende Dreieck zeigt die Abbildung 10 ‚The Duality of Technology‘.

Abb. 10: “The Duality of Technology” nach Orlikowski (Rolf 2008, S. 113)

19

IT bzw. Software entsteht durch Handeln von Akteuren (Pfeil a). Gleichzeitig ist sie Medium

menschlichen Handelns; erst sie ermöglicht bestimmte Handlungen und schränkt gleichzeitig

andere ein oder unterbindet diese (Pfeil b). Wenn Akteure Software entwickeln und anwen-

den, stützen sie sich dabei auf und richten sich nach Strukturen, Regeln und Leitbildern der

jeweiligen Organisation (Pfeil c). Innerhalb dieses Prozesses werden Regeln und Strukturen

bestätigt oder verändert (Pfeil d). Das ‚?‘ zeigt an, dass die Wirkung von Technik, also Soft-

waresysteme, auf die Organisationen nicht eindeutig bestimmt ist (vgl. Rolf 2008, S. 113 und

Pfeil ?).

Die Organisationen enthalten auf der einen Seite die relativ stabilen Organisationsstrukturen

und andererseits die flexiblen Handlungen bzw. Nutzungskontexte, in denen die Akteure in-

novativ und kreativ handeln müssen. Der zur Struktur geronnene Teil der Organisation kann

in Operationen gefasst und formalisiert werden. Der innovative Teil benötigt jedoch die Po-

tentiale der Mitarbeiter, Software unterstützt lediglich ihre Tätigkeiten. Eine Formalisierung

dieser flexiblen Handlungen wäre für die Ziele der Organisation sogar kontraproduktiv. Die

Handlungsfreiheit der Mitarbeiter würde durch den begrenzten Rahmen der Software einge-

engt und dadurch kreatives Arbeiten erschwert werden. Hier spricht man von einer notwendi-

gen Formalisierungslücke. Die vorläufige Formalisierungslücke hingegen identifiziert die

standardisierten Prozesse, die nach einer weiteren technischen Entwicklung oder zu einem

späteren Zeitpunkt entgegen der vorherigen Annahmen und Möglichkeiten automatisiert wer-

den können. Eine Unterscheidung zwischen diesen beiden Formalisierungslücken kann nur

aus der jeweiligen Situation heraus bestimmt werden, die Bestätigung der Annahme zeigt sich

erst im Zeitablauf als richtig oder falsch, ist jedoch für den Erhalt der Innovationsfähigkeit

einer Organisation bedeutend. Für den Fall, dass eine solche Einschätzung in notwendige und

vorläufige Formalisierungslücke nicht adäquat getroffen wurde, kann eine Softwareeinfüh-

rung scheitern, das Unternehmen nach der Softwareeinführung durch schlechte Prozesse ge-

lähmt oder die Innovationsfähigkeit gebremst sein.

2.3.3 Makrokontext - einflussreiche Strukturen und Leitbilder in der Gesellschaft

Der Makrokontext setzt die Organisationen und das Informatiksystem, die Akteure aus dem

Mikrokontext, in Wechselwirkungen mit dem gesellschaftlichen Umfeld. Dieses ist geprägt

von zum Beispiel Werten, Gesetzen, Kulturen, Global Governance, Welthandelsorganisati-

ons-Strategien, der Arbeitswelt, dem Arbeitsmarkt und der Lebenswelt (vgl. Abbildung 11).

Hier rücken speziell gesellschaftliche Phänomene ins Blickfeld, die zunächst nicht unmittel-

bar mit der Techniknutzung und Technikentwicklung in Zusammenhang gebracht werden.

20

Abb. 11: Der Mikro- und Makrokontext der Mikropolis-Plattform (Rolf 2008, S. 25)

„Informatiksystem, Organisationen und ihre Akteure sind, metaphorisch gesprochen, von ei-

ner [von beiden Seiten durchlässigen] Membran umhüllt in die Gesellschaft eingebettet.“ (vgl.

Rolf 2008, S. 116) Auf der einen Seite nehmen das gesellschaftliche Umfeld in Form von

makroökonomischen Theorien, rechtlichen Wertsetzungen, Traditionen und Wissenschafts-

und Bildungssystemen Einfluss auf Organisationen und den Prozess der Entwicklung und

Nutzung von IT. Diese wird dadurch gelenkt, beschleunigt oder gehemmt. Auf der anderen

Seite rufen Innovationsprozesse unter dem Einfluss des Informatiksystems im Zusammenspiel

mit den IT-anwendenden Organisationen gesellschaftliche Spannungen und Anpassungen

hervor. Dabei müssen sich beide Seiten, der Mikrokontext und die Gesellschaft, den immer

neuen Bedingungen stellen, zum Beispiel erhöhten Qualifikationsanforderungen im Bildungs-

system oder der Schaffung oder dem Wegfall von Arbeitsplätzen. In der Vergangenheit, nicht

zuletzt im Technikdeterminismus, wurden vorschnelle Ursache-Wirkungs-Beziehungen zwi-

schen Technik und Gesellschaft definiert, die jedoch selten eindeutig möglich waren. Den-

noch spielen die Informationstechniken auch aus der Sicht des Makrokontextes eine zentrale

Rolle oder sind zumindest ein unverzichtbares Medium, welche die Gesellschaft als Ganzes

maßgeblich verändern kann. Die Informationstechnologien sind das Mittel, welches die

Transformation von der nationalen zur globalen Ökonomie vorantreibt und gleichzeitig das

Werkzeug für ökonomisch-technische Rationalisierungen (vgl. Rolf 2008, S. 117).

21

2.3.4 Prozesse und Pfade der Technikentwicklung und -nutzung

Die Prozesse und Pfade sind eine weitere Ebene im Mikropolis-Model. Die Pfade der IT-

Nutzung und -Entwicklung in diesem Orientierungsrahmen veranschaulichen alle Entschei-

dungsprozesse, Ereignisse und Veränderungen, Innovationen, Technikentwicklungen und

Technikanwendungen. Dementsprechend stellen sie die Wechselwirkungen innerhalb der so-

ziotechnischen Perspektive, dem Mikro- und Makrokontext eingebettet in den historischen

Kontext dar. Durch die zeitliche Betrachtung der erfolgreichen und untergegangenen Pfade

der Technikentwicklung und -nutzung zeigt sich die Qualität der Wechselwirkungen zwischen

dem Informatiksystem, den Organisationen und den Akteuren im Kontext der Gesellschaft.

Der Blick auf die IT-Entwicklung und -Nutzung erweitert sich um die Frage nach den Verlie-

rern und Gewinnern in bestimmten zeitlichen Abschnitten. Es lassen sich Aussagen darüber

treffen, inwieweit die entwickelte Technik und deren Anwendung die Strukturen in Organisa-

tionen prägten und zur Basis für weitere technische Entwicklungen wurden. Das Mikropolis-

Modell betrachtet so IT-Entwicklung und -Nutzung in einem umfassenderen Blickfeld, wobei

gerade die Betrachtung der zeitlichen Entwicklung in dynamischen Kontexten auch bei der

Einschätzung zukünftiger Entwicklungen und Innovationen helfen kann (vgl. Rolf 2008,

S.95f). Unter Pfaden versteht man allerdings keine eng begrenzte, lineare Strecke, sondern

einen Weg mit vielen möglichen Verzweigungen, Alternativen, Optionen und auch Enden

(vgl. Rolf 2008, S. 133). Angelehnt an die strukturtheoretische Sicht auf Pfade11 geht man bei

der Pfadentstehung von emergenten Ereignissen aus. Dabei ist die Gestaltung des Pfades ein

sozialer Prozess, geprägt von den Entscheidungen strategisch handelnder Akteure und Orga-

nisationen. „[…] vergangene Ereignisse [rufen] Folgeereignisse [hervor], Erfolge generieren

positive Rückkopplungen in Form neuer Erfolgschancen.“ (Rolf 2008, S. 134) Diese Entwick-

lungsprozesse wirken selbstverstärkend auf den Pfadverlauf. Da sich Pfade in sozialen Syste-

men durch das Agieren der Akteure herausbilden, ist ihr Verlauf ebenfalls von den verfestig-

ten gesellschaftlichen Strukturen abhängig. Aus diesem Grund lassen sie sich nicht zielgerich-

tet steuern, sondern lediglich beeinflussen. Diese Pfadabhängigkeit lässt sich nur mittels vor-

heriger Pfadanalyse für andere Entwicklungen nutzbar machen. Dabei ist besonders den Pfad-

korrekturen und -abweichungen ein Lernpotential für die Zukunft immanent. Innerhalb der

Ebene ‚Prozesse und Pfade‘ spricht man von Technikentwicklungspfaden (TEP) und Tech-

niknutzungspfaden (TNP). Obwohl in den Ausführungen des Mikropolis-Modells zur dritten

strukturgebenden Perspektive der Fokus eher auf den TNP gelegt wird, ist es für bestimmte

Untersuchungen nur möglich, Aussagen über die Techniknutzung abzuleiten, wenn die Ana-

lyse auf Basis des TEPs erfolgte. Die Begründung dafür liegt in der Definition der einzelnen

Pfade und deren theoretischen Abgrenzung zueinander.

11 Hierbei wird auf den Analyseansatz von Windeler 2003 Bezug genommen, der die Pfadtheorie um struktur-theoretische Einflüsse erweitert.

22

Die Komponente TEP ist in jenen Studien notwendig, welche sich mit der Technikentwick-

lung und -nutzung eines oder mehrerer IT-Hersteller aus dessen oder deren Perspektive befas-

sen. Der TEP12 „ […] entwickelt sich in Wechselwirkung mit Anforderungen von Organisati-

onen, eingebettet in gesellschaftliche Regulierung, Leitbilder und globalem ökonomischen

Wettbewerbsdruck.“ (Rolf 2008, S. 85) Im Gegensatz zu der technikdeterministischen Sicht-

weise auf Technikentwicklung spielen technische Sachzwänge im Mikropolis-Modell bei der

Technikentstehung nur eine von vielen Rollen. Die Analyse erfolgt in diesem Zusammenhang

auf den Ebenen der soziotechnischen Perspektive und des Mikro- und Makrokontextes über

einen festgelegten Zeitraum. Man erhält dadurch einen tief greifenden Einblick in den Motor

der IT-Entwicklung und die dort liegenden Formalisierungspotentiale und Formalisierungslü-

cken. Der Pfad der Technikentwicklung ist kein gerader, sondern ein verzweigter, der mitun-

ter verschiedene Weichenstellungen und Irrungen beinhaltet (vgl. Windeler 2003, S. 321).

Diese Betrachtung ermöglicht die Unterscheidung in erfolgreiche und untergegangene Tech-

nikentwicklungen, zwischen einer Techniknutzung und Technikfehlentwicklung. Es können

Rückschlüsse auf die Bedingungen von erfolgreichen Innovationen gezogen werden, auf die

Qualität der Wechselwirkungen zwischen Akteuren in einer Gesellschaft.

Wechselt der Fokus allerdings von der Sichtweise der IT-Hersteller zu der Sichtweise der

Organisationen hinsichtlich der Nutzung von IT, argumentiert man im Bereich des TNPes.

Die Darstellung der IT-Nutzung kann dabei für eine einzelne Organisation oder mehrere, eine

Branche, eine Volkswirtschaft oder gar eine globale Wissensökonomie interpretiert werden

(vgl. Rolf 2008, S. 133). Der TNP Büro, wie von Arno Rolf geschildert, erzählt demnach von

der Nutzung der IT im Büro von Organisationen über die Zeitspanne vom Kontor zur Netz-

werkökonomie im Hinblick auf die Entwicklung und Veränderung der Arbeitsorganisationen.

Wie in diesem Pfad werden auch in anderen TNPen die bestehenden Wechselwirkungen in-

nerhalb der soziotechnischen Perspektive, zwischen den Organisationen und dem Informatik-

system und der Gesellschaft rückblickend im historischen Kontext verfolgt (vgl. Rolf 2008, S.

104). Im Mittelpunkt der Betrachtungen stehen die sich am Markt und in Organisationen

durchgesetzten Produkte, Leitbilder, Modelle, Methoden und Werkzeuge, so dass Pfade der

erfolgreichen und misslungenen Innovationen erkennbar werden. Der TNP spiegelt „[…] die

zur Struktur geronnenen Handlungen der Sieger wieder […]“ (Rolf 2008, S. 133). Der Blick

auf die Verlierer und Niederlagen innerhalb der IT-Nutzung kann dagegen wichtige Informa-

tionen über zukünftige Innovationen liefern.

Dass die Priorität im Mikropolis-Modell bis jetzt auf den TNP gesetzt wurde, liegt nicht da-

ran, dass der TEP weniger relevant ist. Vielmehr steht in der Theorie das Anliegen im Vor-

dergrund, die Entstehung von vergangenen Innovationen oder Fehlentwicklungen verstehen

und erklären zu können, um daraus Erkenntnisse für zukünftige Prozesse zu gewinnen. Dieses

Ziel lässt sich nach der Pfadtheorie eher aus der Analyse der Nutzungspraxis von Technik in

12 Dieser wird auch IT-Entwicklungspfad genannt.

23

Organisationen als richtungsweisender Parameter von Pfaden erreichen, demnach vorzugs-

weise durch die Auseinandersetzung mit dem TNP. Um allerdings den kurvenreichen und

verzweigten Pfad einer Technikentwicklung von ihrem Ursprung über die Markteinführung

bis zu ihrer Bestätigung als Innovation besser fassen und beschreiben zu können, ist es not-

wendig sich mit der gesamten Technikentwicklung eines Produktes oder einer Serie von Pro-

dukten eines Herstellers auseinander zu setzen. So gewährleistet man mehr Innovationen oder

Fehlentwicklungen aufzuzeigen, und zwar auch jene, welche nur eine Rolle in wenigen Orga-

nisationen spielen oder nicht durch den TNP erfasst werden. Es erschließt sich durch die Per-

spektive des TEP ein neuer Bereich der Prozesse und Pfade im Mikropolis-Modell. Die enge

Verbindung zwischen dem TEP und dem TNP bietet außerdem neue Ansatzpunkte für Unter-

suchungen der Technikentwicklung und -nutzung aus Sicht des Mikropolis-Modells.

24

3. Die SAP AG und die SAP-Software

Meine Darstellung der Entwicklung von SAP und die Untersuchung der Einführung von der

Software SAP R/3 in Unternehmen basiert auf der Grundlage der Theorien des Technikdeter-

minismus, der ANT und des Mikropolis-Modells. Dies bedeutet es werden die Effekte von

Technik als alleiniger Treiber, alle menschlichen wie nicht-menschlichen Akteure und die

verschiedenen zeitlichen Arenen, in denen gehandelt wird, betrachtet. Die behandelte Litera-

tur wird auf die zu der Entwicklung ihrer Produkte beitragenden Handlungen der SAP AG

oder im Umfeld der SAP AG hin untersucht. Am Ende eines jeden Punktes fasse ich die ele-

mentaren Faktoren, Strategien und Leitbilder in einer selbst erstellten Grafik oder in einem

gesondert stehenden Satz zusammen. Die Interpretation der gesammelten Kriterien nach dem

Technikdeterminismus, der ANT und dem Mikropolis-Modell erfolgt in Kapitel 4 und wird

dort den Theorien entsprechend aufgeschlüsselt und gegebenenfalls erweitert.

3.1 Die Entwicklung der SAP-Software unter Berücksichtigung der SAP AG

Die Technikentwicklung der SAP AG behandelt den Zeitraum von ihrem Gründungsjahr

1972 bis zum Anfang des Jahres 2010. Die einzelnen Kapitel richten sich nach den wichtigen

Softwarereleases der SAP AG, welche sich dem Zeitablauf folgend aneinander reihen. Die

Darstellung des Weges zum weltweit agierenden Unternehmen folgt in einem eigenen Ab-

schnitt, da hier ein zeitlicher Querschnitt über alle Entwicklungsschritte von SAP gezogen

wird und so die einzelnen Handlungen des Unternehmens SAP AG über die Jahre kompakter

dargestellt werden können.

3.1.1 SAP R und SAP R/2 - das Mainframe System

Die Anfänge der Firma Systemanalyse und Programmentwicklung, aus dem später die Kurz-

form SAP wurde, liegen in der Zeit der Aufbruchsstimmung der Softwareindustrie kurz nach

dem unbundling, dem crucial inflection point der Entwicklung der Softwareindustrie (vgl.

Campbell-Kelly 2003, S. 114). Das unbundling bezeichnet den Schritt des bisherigen Mono-

polisten IBM im Juni 1969, Software getrennt von der Hardware und nicht länger als Bündel

zu verkaufen. Zusätzlich zu dieser Entscheidung konzentrierte sich IBM auf die Sparte der

Hardware und in Folge dessen wuchsen die Einkünfte aller Anbieter aus dem Verkauf auf

dem Softwaremarkt vom Jahre 1969 bis 1975 von geschätzten $20 bis $50 Millionen auf $400

Millionen an (vgl. Campbell-Kelly 2003, S. 109 und 115f). In dieser Zeit versuchte der ehe-

malige IBM-Mitarbeiter Claus Wellenreuther seine in der IBM-Zeit geschriebene Software

für Finanzbuchhaltung eigenständig zu verkaufen. Er gründet die Firma Systemanalyse und

Programmentwicklung (Meissner 1997, S. 24). Parallel arbeiteten Hasso Plattner und Dietmar

Hopp für IBM an der Installation des neuen IBM /370 Rechners und in dem Zuge an einem

Realtime ordering System (RoS) in dem Werk Imperial Chemistry Industrie (ICI) in

25

Östringen. Nach Fertigstellung dieses Systems waren die Manager von ICI daran interessiert,

das Nachfolgesystem Material Information and Accounting System (MIAS) zu erstellen, wel-

ches das alte Lochkartensystem ersetzen sollte. Die Pläne wurden von IBM zurückgewiesen

und so boten die ICI-Manager diese Plattner und Hopp als privaten Auftrag mit einem mögli-

chen Umsatzvolumen von 600.000 DM an (vgl. Platt00 S.21 und Campbell-Kelly 2003, S.

192). Neben den beiden Genannten interessierten sich auch Klaus Tschira und Hans-Werner

Hektor, ebenfalls für IBM tätig, für das Projekt. Um den Auftrag annehmen und umsetzen zu

können, begeisterten Hector, Hopp, Plattner und Tschira den Unternehmer Wellenreuther da-

für, gemeinsam ein Standardsoftwaresystem für die ICI zu entwickeln. Zusammen gründeten

sie am 1.April 1972 das neue Unternehmen Systemanalyse und Programmentwicklung GbR

(vgl. SAP Geschichte 1 und Meis09 S.32). Durch diesen Schritt vereinen die fünf ihre lang-

jährigen Erfahrungen: Wellenreuther brachte das Wissen um den Umgang mit der Buchhal-

tungssoftware mit, Plattner und Hopp hatten bereits ein System erfolgreich in einem Unter-

nehmen eingerichtet, Tschira war Experte im Betriebssystem DOS und Hector galt als Spezia-

list der Fertigungssteuerung. Neben diesen Kompetenzen waren die vorhandenen Geschäfts-

kontakte, wie der erste Auftrag bei der ICI, der Traktorhersteller John Deere, der Autozuliefe-

rer Freudenberg und der Baufirma Bilfinger+Bilfinger, förderlich.

Das erste gemeinsame Projekt MIAS war ausgerichtet auf eine Standardsoftware, die Echt-

zeitverarbeitung von Daten und die abteilungsweite Integration dessen als innovative Pro-

duktplanung. Das Wort ‚Standard‘ bedeutete die Unterstützung und Automatisierung von

Standardabläufen, die in vielen Firmen gleich waren, wie eben der Einkauf, die Warenwirt-

schaft und die Buchhaltung (vgl. Meissner 1997, S. 21f). Es basierte auf einer nur einmal vor-

handen Datenbank, von der die drei Komponenten Einkauf, Warenwirtschaft und Buchhal-

tung ihre Informationen in Echtzeit bezogen. Diese Form der Datenverarbeitung stellte eine

wesentliche Verbesserung gegenüber der bis dato vorherrschenden Batchverarbeitung von

Daten in Großunternehmen dar. Dieses neue Verfahren erlaubte es, Daten von einem Termi-

nal direkt zu dem Mainframe zu schicken und nicht länger über den zeitraubenden Umweg

der Batchlisten (vgl. Meissner 1997, S. 38f und Siegele 2009, S. 37f). Die Ideen dahinter wa-

ren allerdings nicht neu, sondern IBM entwickelte bereits in den 50er Jahren das Bill of Mate-

rials Processing (BomP) und das Production Information and Control System (PICS), durch

die in den 60ger Jahren in Amerika wie auch in Deutschland die Konzepte einer integrierten

Datenverarbeitung bekannt wurden. Die Softwareprodukte scheiterten jedoch an der damali-

gen, stark limitierten Rechenkapazität. Im Jahr 1972 veröffentlichte IBM das Communication-

Oriented Production Information and Control System (Copics), ein Handbuch für Manager,

das den Prozess der integrierten Datenverarbeitung beschrieb. Diese Arbeit wurde später

durch Jeffrey Miller, Linda Sprague und Joseph Orlicky erweitert und der Öffentlichkeit als

Produktionsplanungsprogramm Material Requirement Planning (MRP) vorgestellt. Das Pro-

dukt MIAS der SAP AG entsprach dem Leitbild MRP (vgl. Leimbach 2008, S. 64). Die

Gründer der SAP AG konnten das von Hopp und Plattner eingerichtete IBM-Mainframe Typ

26

/370 direkt für die Entwicklung der Software nutzen. Darüber hinaus lernten die SAP-

Gründer von der ICI alles über deren Einkauf, Warenwirtschaft und Buchhaltung und bauten

aus diesem Wissen ihre Software. So wurde MIAS für die ICI und aus der ICI heraus entwi-

ckelt, eine Entwicklung direkt beim Kunden (vgl. Siegele 2009, S. 54f). Ein entscheidender

Vorteil für die weitere Entwicklung von SAP bestand in dem Vertrag zwischen der SAP AG

und der ICI, der neben einer Nutzung des Großrechners der Firma auch den Weiterverkauf der

erstellten Software erlaubte. Die ICI gestattete den Gründern der SAP AG die fertig gestellten

Komponenten anderen Kunden auf ihrem Mainframe vorzustellen (vgl. Meissner 1997, S.42).

Eine solche Präsentation eines lauffähigen Systems vor anderen Kunden war der Beginn der

Pilotprojektstrategie. Erfolgsfördernd war zudem die Mitnahme der Kontakte auf Vorstands-

ebene aus der Zeit von IBM, wodurch neue Systeme oder neue Komponenten direkt den Ent-

scheidern anderer Unternehmen präsentiert werden konnten.13 Abbildung 12 gibt eine Über-

sicht über das verschlungene Verhältnis der Beziehungen von der SAP AG mit dem MIAS in

der Gründungszeit.

Abb. 12: SAP AG um 1972 (eigene Darstellung)

Aus dem MIAS wurde später das SAP R, dessen Name auf den damals verwendeten Bezeich-

nungen einzelner Komponenten beruhte. Die Komponente Buchhaltung wurde als erste fertig

gestellt und erhielt dementsprechend den Namen RF für Realtime Financials. Im Jahr 1974

zählte die SAP AG mit dem System SAP R 40 Kunden und stellte von dem Betriebssystem

DOS auf OS um (vgl. SAP Geschichte 1). In den folgenden Jahren hatte sich auf dem Main-

frame-Markt langsam die neue Generation des Mainframe IBM /370 durchgesetzt, welche den

Vorgänger IBM /360 ersetzte. Diesem hatte IBM ein neues Programmsystem zur Datenbank

und Dialogsteuerung hinzugefügt, welches die Engpässe in der Verarbeitung von Prozessen

behob. Mit Hilfe dieser Performancesteigerung konnten viele Probleme in der SAP-

Softwareentwicklung gelöst und an ein eigenständiges Standardprodukt gedacht werden. In

diesem Zuge begann die Arbeit an dem neuen System SAP R/2 im Jahre 1978 mit einer ge-

planten Entwicklungszeit von sechs bis acht Jahren (vgl. Campbell-Kelly 2003, S. 193f). Zu

13 Hier wird auf die generelle SAP Methode verwiesen, welche auf der Mundpropaganda, den Kontakten auf Vorstandsebene und der Hilfe von Pilotkunden aufbaut (vgl. Meissner 1997 S.102).

27

dieser Zeit schaffte sich die SAP AG selbst zwei Rechner an, einen eigenen IBM-Großrechner

vom Typ /370 und einen Siemens-Großrechner vom Typ 7738 mit dem Betriebssystem

BS2000 (vgl. Meissner 1997, S. 49). 1981 stellte die SAP AG dann die Software SAP R/2

sowohl auf Basis der Mainframerechner von IBM als auch der Siemensrechner vor. Dieses

System erhielt in den nächsten Jahren spezielle Komponenten für Produktplanungssysteme.

Diese Erweiterung umfasste die Funktionen des Konzepts Material Requirement Planning II

(MRPII), welches den MRP-Inhalten noch Planungsebenen voranstellte (vgl. Leimbach 2008,

S. 66). SAP R/2 lief im Jahr 1993 in 70 Firmen in Amerika, bei 1800 Kunden weltweit und

zur Spitzenzeit schaffte es das SAP R/2 auf 2.200 Installationen (vgl. Plattner et al. 2000, S.

27 und Siegele 2009, S. 81).

Abb. 13: Faktoren, Strategien und Leitbilder für SAP R und SAP R/2 (eigene Darstellung)

3.1.2 SAP R/3 - die Client-Server-Strategie

Die Hintergründe des Produktwechsels zu der neuen Produktgeneration System SAP R/3 lie-

gen in dem Vorstoß von IBM, einen Wechsel von der Computerreihe /370 hin zu der neuen

Generation AS/400 einzuleiten. IBM präsentierte 1987 auf einer Konferenz in Frankfurt am

Main sein neuartiges Rechnerkonzept AS /400, die System-Anwendungs-Architektur (SAA),

auf Basis der neuen Programmiersprache C und die Ablösung von hierarchischen hin zu rela-

tionalen Datenbanken (vgl. Plattner et al. 2000, S. 29f). Um wettbewerbsfähig zu bleiben, sah

sich die SAP AG nun in der Pflicht, das alte System SAP R/2 auf die neue Basis der Pro-

grammiersprache C vollständig umzuschreiben. Die Entwicklung zu SAP R/3 war damit ein-

geleitet. Dafür wurde das herstellerunabhängige Betriebssystem Unix, das sich bereits lang-

sam gegenüber IBM auf dem Markt einen Namen gemacht hatte, eingesetzt. Die SAP AG

erprobte das neue System auf den Rechnern der IBM-Konkurrenten DEC und Hewlett Pa-

28

ckard (HP). Die Version SAP R/3 war jedoch anfangs nicht auf diesen kleinen Rechnern im

vollen Umfang lauffähig, sondern benötigte für die erfolgreiche Umsetzung14 die aktuellste

Rechnergeneration von der Firma HP (vgl. Meissner 1997, S. 71f). Die Integration von SAP

R/3 führte zu einem neuen Architekturmodell, zur „[…] Erfindung der dreischichtigen Client-

Server-Architektur […]“. (Platt00 S.32) Dieses Stufenmodell bestand aus einer Datenbank,

einem Anwendungsserver und einem Präsentationsserver als oberste Stufe (vgl. Meissner

1997, S. 74f). Zuvor wurden die Eingaben meist auf textbasierten, grün-schwarzen Bild-

schirmen erledigt. Die entwickelten Client-Server-Systeme boten bunte Benutzeroberflächen,

wurden grafisch (Client Seite). Das war die für alle sichtbare Seite der Innovation von dem

SAP-Produkt. Im Hintergrund lief die benötigte Programmlogik (Server Seite) (vgl. Siegele

2009, S. 177f). Diese Weiterentwicklung von einem Mainframe zu mehreren parallelen Rech-

nereinheiten hatte folgende technische Vorteile: Jeder einzelne Prozess war abgeschirmt von

den anderen und konnte somit isoliert betrachtet und verbessert werden. So konnte das Risiko,

dass ein kleines Programm das ganze System gefährdet, minimiert werden. Die Überlegungen

SAP R/3 nicht für die SAA von IBM weiterzuentwickeln, beruhte auf der Ästhetik der Client-

Server-Architektur und dem Auftreten technischer Probleme bei dem System AS/400 - das

Debuggen des Mainframes blockierte die Prozessoren (vgl. Plattner et al. 2000, S. 90). Die

SAP AG stellte sich selbst unter den großen Erfolgsdruck, der Öffentlichkeit ihr System SAP

R/3 auf der CeBit 1991 vorstellen zu können. Sie setzten sich deshalb eine Deadline für die

Entscheidung SAP R/3 entweder auf dem AS/400 lauffähig zu machen oder bei Fortbestehen

der technischen Probleme auf den Unix-Rechnern zu präsentieren. Die rechtzeitige Fertigstel-

lung verdankte das System SAP R/3 dem Ziel seiner Konstrukteure, auf der Hannover Messe

vorgestellt zu werden (vgl. Plattner et al. 2000, S. 33). Zencke sprach 1991 noch vor der Ce-

Bit die revolutionäre Idee aus, das ganze SAP Paket vom Großrechner auf die Minicomputer

zu verpflanzen; die Entscheidung fiel demnach zugunsten der Unix-Rechner und gegen den

AS/400 (vgl. Siegele 2009, S. 192). Auf der CeBit wurde dieses Konzept allerdings vor dem

Publikum geheim gehalten und das neue Produkt noch als Mainframe-Produkt mit der Aussa-

ge vorgestellt: der Großrechner stehe in Walldorf und sei mit den Terminals auf der CeBit

verbunden (vgl. Plattner et al. 2000, S. 98). Die Abbildung 14 zeigt die Struktur des Systems

SAP R/3 mit einer relationalen Datenbank und der Neustrukturierung der Datenstruktur. Die

Systembasis, die so genannte Middleware, wurde auf Basis von C neu programmiert. Die

Anwendungen von SAP R/3 sind vollständig in der eigenen Programmiersprache ABAP/4

realisiert worden und stellten die verschiedenen Komponenten des Systems dar.

14 Obwohl HP die neue Rechnergeneration erst kurz vor der Messe CeBit an die SAP AG auslieferte und das System SAP R/3demnach “fünf vor zwölf“ darauf lauffähig wurde (vgl. Meissner 1997 S. 74).

29

Abb. 14: Architektur SAP R/3 (Hohlmann 2007, S. 57)

Diese Architektur weckte die Idee, SAP R/3 auf der Ebene kleiner bis mittelständischer Un-

ternehmen zu positionieren und für Großunternehmen SAP R/2 weiterzuentwickeln. Aller-

dings war der erste Interessent für das System SAP R/3 die Großfirma Würth, die 1991 einen

Umsatz von zwei Milliarden Dollar machte und ihr größtes Lager in Deutschland hatte. SAP

R/3 etablierte sich entgegen des angepeilten Marktsegments als direktes Konkurrenzprodukt

zu SAP R/2. Das Pilotprojekt für SAP R/3 startete bei der kleinen Firma Kamura aus Däne-

mark (vgl. Plattner et al. 2000, S. 34f). Hasso Plattner weist in der Beurteilung der Pilotphase

auf den direkten Kommunikationsprozess mit dieser Firma hin. Die Nähe zum Kunden wäh-

rend der Einführung der Software SAP R/3 lässt sich danach als ein Schlüsselfaktor für die

SAP AG charakterisieren. 1992 erfolgte auf der Anwendermesse Sapphire in Orlando die

Freigabe für Amerika. Das System SAP R/3 wurde mit dem Marketingversprechen angekün-

digt, dass es vor dem ursprünglich festgesetzten Veröffentlichungstermin verfügbar sein wür-

de. Daraufhin unterschrieb Convex, neben anderen interessierten Großunternehmen, auf der

Messe als erster Kunde (vgl. Plattner et al. 2000, S. 37). Für den Vermarktungserfolg in Ame-

rika war nicht zuletzt das Leitbild Business Reengineering, auch genannt Business Process

Reengineering (BPR), verantwortlich, welches im Jahr 1993 von Michael Hammer und James

Champy konzipiert und von den großen Wirtschaftsprüfungsunternehmen in den USA welt-

weit verbreitet wurde (vgl. Hammer und Champy 1996). Ziel sollte es sein, durch eine inte-

grierte Datenbank allen Mitarbeitern gleichzeitig Informationen zugänglich zu machen, ihnen

spezielle Programme zur Leistungsverbesserung zur Seite zu stellen und durch die zentrale

Speicherung von Lieferantendaten Einkaufsvorteile zu erzielen (vgl. Hammer und Champy

1996, S. 112f und 122). BPR verlangte nach einem Konzept der integrierten Software und

30

nach der Einführung einer Standardsoftware als technische Voraussetzung für die Reorganisa-

tion in Geschäftsprozesse (vgl. Hammer und Champy 1996 S. 124). Durch sein integriertes

Echtzeit-Standardsystem entsprach die SAP-Software diesem sich etablierenden Leitbild (vgl.

Hohlmann 2007, S. 16 und Plattner et al. 2000, S. 38). Zusätzlich bot die SAP AG eine Inter-

nationalität in Form der einfachen Anpassbarkeit auf verschiedene Ländersprachen und Ge-

gebenheiten seiner Produktreihe an, was sogar von dem Konkurrenten Ray Lane, Vizepräsi-

dent von Oracle, gewürdigt wurde (vgl. Siegele 2009, S. 83). Neben den Marketingstrategien

Produktvorankündigung, Verkörperung des Leitbildes BPR und Internationalität nutzte die

SAP AG 1993 die auf die USA angepasste Geschäftspraktik des provisionsbasierten Arbei-

tens (vgl. Plattner et al. 2000, S. 41). Diese weitere Strategie zur Verbreitung von SAP R/3 in

Amerika führte zur Abwanderung von qualifizierten Mitarbeitern anderer Organisationen hin

zu der SAP AG. Pilotprojekte oder so genannten Flaggschiff-Firmen sollten das lauffähige

Produkt präsentieren und den Markt weiter öffnen (vgl. Meissner 1997, S. 251f). So kam es

1994 zu einer Zusammenarbeit von der SAP AG und Microsoft mit dem Ziel, die Unix-

Derivate im Servermarkt durch Windows NT als Server, Windows 95 als Betriebssystem und

SQL als Datenbankstandard abzulösen. Diese Konfiguration wurde dann in einem solchen

Pilotprojekt bei Hoechst im Jahr 1996 erfolgreich eingeführt.

Abb. 15: Faktoren, Strategien und Leitbilder für SAP R/3 (eigene Darstellung)

31

3.1.3 SAP seit der Zeit des Internets

Mit dem Internet veränderte sich das Informationswesen gravierend und das wirkte sich auf

viele Bereiche der Gesellschaft und der Technikentwicklung aus (vgl. Rolf 2008, S. 46). Seit

1993 gelang dieser Technik der Durchbruch und seitdem “boomt“ das World Wide Web

(WWW). Die SAP AG wurde ebenfalls mit dieser Innovation konfrontiert und reagierte auf

die veränderten Anforderungen der neuen Situation. Allerdings überraschte sie diese Technik-

entwicklung, was sich in den eigenen Entwicklungen zeigen sollte.

„Das Internet habe ich nicht kommen sehen. Ich habe es einfach nicht gesehen. Und plötzlich

war es da.“ (Hasso Plattner in Plattner et al. 2000, S. 43)

3.1.3.1 mySAP.com - die Idee des Mehrproduktunternehmens

In der Anfangszeit des Internetbooms versuchte die SAP AG das System SAP R/3 auf die

neuen Herausforderungen einzustellen. Hierfür definierte die SAP AG mit Microsoft 1996 die

Business Applikation Programming Interfaces (BAPI). Dabei handelte es sich um standardi-

sierte Schnittstellen, welche Regeln festlegten, nach denen der Informationsaustausch zwi-

schen den Anwendungsprogrammen funktionierte. Diese Technologie wurde zusammen mit

Microsoft erarbeitet und mit Bill Gates auf der Messe Sapphire präsentiert (vgl. Plattner et al.

2000, S. 44, Siegele 2009, S. 89 und Meissner 1997, S. 95). Durch diese Verbindungspunkte

konnten andere Hersteller an SAP-Systeme andocken und eine frühe Form des E-Commerce

über das Internet wurde möglich. In Version SAP R/3 3.1 führte man die Technologie der

BAPI ein und SAP R/3 Version 4.0 erhielt ein integriertes E-Commerce Modul (vgl. Meissner

1997, S. 254). Die Möglichkeit des Internets wurde erkannt und die Unternehmensinformatik

über die Unternehmensgrenzen und Konzerngrenzen hinweg bis zum Kunden, Endverbrau-

cher und Geschäftspartner ausgeweitet. Die eigene Programmiersprache ABAP/4 erweiterte

sich um Java und Active-X (vgl. Meissner 1997, S.262). Des Weiteren wurde das neue Modul

Human Ressources mit dem Employee-Self-Service entwickelt, welches den Mitarbeitern er-

laubte ihre eigenen Daten wie Adresse und Bankverbindungen zu pflegen und diese Vorgänge

nicht mehr über die Personalabteilung laufen ließ (vgl. Meissner 1997, S. 265). 1997 stellte

die SAP AG die komplette Dokumentation von SAP R/3 in das Internet, so dass alle relevan-

ten Informationen für die Kunden und Partner schnell erreichbar waren (vgl. Meissner 1997,

S. 257). Mit diesen Vorstößen konnte sich SAP anfangs zu Recht zu den Early Adopter15 zäh-

len. Entgegen dieser Vorreiterfunktion nahmen die Mitarbeiter das Unternehmen SAP AG als

zu groß und unbeweglich wahr. Kritik an der Verhaftung der SAP AG in der Old Economy

wurde immer lauter geäußert (vgl. Siegele 2009, S. 90). Das Grundproblem, mit dem die SAP

AG demnach zu kämpfen hatte, war, dass sie immer das Ziel vor Augen hatte, auf die Anfor-

15 Als Early Adopter werden diejenigen bezeichnet, die Trends vor der Masse erkennen und diese für ihre eige-nen Produkte nutzen.

32

derungen der Kunden zu hören und dadurch die Nachfrage nach innovativen Ideen, die neuer-

dings gefordert wurden, nicht befriedigte (vgl. Plattner et al. 2000, S. 43f). Das neue Konzept

der Stock Options, durch das Mitarbeiter an dem Erfolg der Firma beteiligt werden, wurde

von der SAP AG ebenfalls nicht mit übernommen. Wegen des schlechten Images, fehlenden

Visionen und ohne Stock Options wanderten viele junge Mitarbeiter und “kluge Köpfe“ zu

anderen “hipperen“ Marktanbietern ab (vgl. Siegele 2009, S. 86f). Neue Trends fanden so

noch weniger ihren Weg in das Unternehmen. Die SAP AG erkannte diese Problematik je-

doch rechtzeitig, löste diese allerdings trotz solider Finanzen nicht durch den Aufkauf dieser

innovativen Firmen, sondern wollte aus eigener Kraft wachsen. Daraufhin gründete die SAP

AG ein Entwicklungsstudio in Palto Alto, Silicon Valley, mit der Aufgabe neue Trends auf-

zuspüren und vor allem die komplizierte deutsche Software zu vereinfachen (vgl. Siegele

2009, S. 88). In diesem Zusammenhang versuchte die SAP AG 1999 mit einem Namens-

wechsel von SAP R/3 in mySAP.com zu punkten. Das Logo wechselte analog zu e-bay zu

einem verspielten und kinderzimmerfarbenen Logo. In der Internetgemeinde setzten diese

Schritte jedoch eher negative Zeichen. Sie unterstellte der SAP AG die Technik Internet nicht

ernst zu nehmen und von einem Early Adopter zu einem Me-too Player16 zu verkommen (vgl.

Siegele 2009, S.91f). In dieser misslichen Lage und konfrontiert mit den vielen neuen Mög-

lichkeiten musste die SAP AG schnell handeln und setzte neben dem BAPI auf das neue

Konzept der Objektorientierung. Es sollte ein Business Framework geschaffen werden, wo-

durch sich einzelne Module von dem System SAP R/3 unabhängig voneinander installieren

ließen (vgl. Meissner 1997, S. 85). Das mächtige integrierte Gesamtpaket wurde entzerrt. Die

SAP AG stand kurz davor, ein Mehrproduktunternehmen zu werden (vgl. Plattner et al. 2000,

S. 162f). 1998 kündigte die SAP AG dem Markt im Zuge der Welle der Best-of-Breed17-

Produkte die Module der Produktreihe New Dimension an. Diese konnten mit dem System

SAP R/3 verknüpft werden, aber auch unabhängig davon laufen. Auf der Messe Sapphire im

Jahre 1999 entging die SAP AG bei der Präsentation von mySAP.com knapp einem peinli-

chem Fehlschlag (vgl. Siegele 2009, S. 94f). Die SAP-Software und die angekündigten Mo-

dule konnten nur mit Hilfe der Firma Toptier18 auf der Messe präsentiert werden und eine

Verbindung der SAP-Software mit dem Internet vorweisen. Durch den fraglichen Vorteil der

unabhängigen Installierbarkeit verlor das System SAP R/3 seinen integralen Bestandteil, das

integrierte Standardsystem. Dieser Fehler der SAP AG kostete das Unternehmen fast den

größten Wettbewerbsvorteil. Ab diesem Zeitpunkt kämpfte die SAP AG wie andere Konkur-

renten dieser Branche damit, die neu erstellten Module wieder zu integrieren. 2001 kaufte die

16 Unter einem Mee-too Player wird derjenige bezeichnet, der die gleichen Produkte wie andere Unternehmen anbietet. 17 Best-of-Breed ist ein Oberbegriff für Customer Relationship Management (CRM) und Supply Chain Manage-ment (SCM). Andere Unternehmen wie Siebel Systems und i2 boten schon vorher fertige Produkte für CRM und SCM an. (vgl. Siegele 2009, S. 86) 18 Toptier ist ein kleines israelisches Softwareunternehmen, das auf Portalsoftware spezialisiert ist.

33

SAP AG Toptier mit dem neue Hoffnungsträger Shai Agassi für 379 Millionen $. Parallel zu

dieser Entwicklung entlang der Objektorientierung versuchte die SAP AG Internetshops für

Unternehmen direkt in die Software SAP R/3 einzubauen. Diese Aufgabe sollte das zusam-

men mit Intel neugegründete Tochterunternehmen Pandesic lösen (vgl. Plattner et al. 2000, S.

251). Da die traditionellen Partner19 der SAP AG allerdings kein Interesse zeigten, dieses

Produkt auf dem Markt zu verkaufen, endete die Zusammenarbeit mit Intel 2001 (vgl. Siegele

2009, S. 224). Der Bereich der Best-of-Breed-Produkte wurde dadurch keineswegs aufgege-

ben, sondern mit der Entwicklung eines Marktplatzes für Unternehmen und Kunden daran

weiter gearbeitet. Die bis hier ausgeführten Entscheidungsfehler in den letzen vier Jahren hat-

ten nur deshalb für die SAP AG geringere Folgen, weil neben dem Internet auch das Jahr-

2000-Problem die Unternehmen beschäftigte und mit dessen Lösung die SAP AG zu der Zeit

ordentlich Geld verdiente (vgl. Meissner 1997, S. 267f und Hohlmann 2007, S. 63). Die ehe-

mals zweistellige Datumsangabe in alten Softwareversionen war nicht fähig den Wechsel der

Jahrtausendwende korrekt wiederzugeben, sondern blieb in der Zeitangabe des 19ten Jahr-

hunderts verhaftet. Im Gegensatz dazu waren die Versionen SAP R/2 ab Release 5.0 und SAP

R/3 bereits mit einem vierstelligen Datum ausgestattet und letzteres konnte sogar zweistellige

Datumsangaben in vierstellige übersetzen. Die Unternehmen sahen sich vor der Entscheidung

entweder ihre alte Software umschreiben zu lassen, wobei der Aufwand von 1,5 Dollar pro

Codezeile geschätzt wurde, oder lieber gleich auf ein neues System umzuschalten (vgl.

Meissner 1997, S. 274). Viele entschieden sich für letzteres, für die SAP-Software. Neben

dieser Umsatzquelle ließ auch das Wechselspiel zwischen börsennotierten Unternehmen und

Finanzmärkten die Nachfrage nach Software aus dem Hause SAP AG anschwellen.20 Nach

dem Platzen der Dotcom-Blase im Frühjahr 2001 konnte sich die SAP-Software auf dem

Markt erfolgreich platzieren, da viele Unternehmen versuchten ihre wild gewachsenen Soft-

warestrukturen zu bändigen und dabei auf Konsolidierung der Softwareprodukte setzten. In

der Annahme, dass die SAP AG ein integriertes Gesamtpaket verkauft, setzten die Unterneh-

men wieder auf diesen Anbieter der Gesamtsoftware, statt auf ein Flickwerk von verschiede-

nen Spezialanbietern (vgl. Siegele 2009, S. 72). Die SAP AG besann sich nicht zuletzt des-

halb auf ihre Stärken, so dass der Dotcom-Blase die oben ausgeführten Produkte New Dimen-

sion vollständig zum Opfer fielen und vom Markt verschwanden. Der Weg hin zum Mehrpro-

duktunternehmen schien zu diesem Zeitpunkt gestoppt (vgl. Siegele 2009, S. 95).

19 Unter den traditionellen Partner werden hier die Beratungspartner verstanden, die genauer im Unterkapitel 3.1.4.1 erläutert werden. 20 Die börsennotierten Unternehmen waren abhängig von der Zufriedenheit der Shareholder und die Einführung des Leitbildes BPR in die Unternehmen zeigte den Willen der Unternehmer zur Verbesserung der Unterneh-mensleistung. Die Umsetzung des BPR erfolgte wiederum oft über die Einführung der SAP-Software.

34

Abb. 16: Faktoren, Strategien und Leitbilder für mySAP.com (eigene Darstellung)

3.1.3.2 Business Suite 7 - die serviceorientierte Architektur

Seine Marktposition baute das Unternehmen SAP AG trotz zwischenzeitlich verpasster Chan-

cen vorwiegend zu Zeiten des Internetbooms auf und schaffte es gleichzeitig die Grundlagen

für die heutige SAP-Software zu legen. Auf dem Weg zu der serviceorientierten Architektur

begann die SAP AG die Entwicklung an einer mit dem Internet verbundenen Marktplatz

Software, welche auf den technischen Kenntnissen des Business Frameworks und der Objekt-

orientierung gründete (vgl. SAP Geschichte 3). Durch sie sollten Unternehmen mit Kunden

problemlos in Kontakt treten können und für jeden ein Portal geschaffen werden, welches nur

diejenigen Funktionen anbietet, die für die Rolle des Mitarbeiters im Unternehmen nötig sind.

Der Marktplatz ermöglichte dem Unternehmen Daten intern wie extern einzubinden und so

Beziehungen zu und die Kommunikation mit anderen Unternehmen herzustellen. Als Markt-

prinzip für die Zukunft galt das Collaborative Business (vgl. Plattner et al. 2000, S. 265). Als

Beispiel diente der Beschaffungsvorgang, der vorher von einer ganzen Abteilung bearbeitet

wurde und nun von jedem einzelnen Mitarbeiter unternehmensweit erledigt werden konnte.

Der Mitarbeiter befand sich selbst in der Verantwortung, die Preise im Internet zu vergleichen

oder das Preis-Know-How anderer Systeme zu nutzen und anschließend seine Ergebnisse in

diesen Marktplatz einzubringen. So informierte ein integrierter Marktplatz jederzeit über die

besten Preise und Beziehungen von und zu externen Partnern (vgl. Plattner et al. 2000, S. 228

und S. 237f). Die Technologie dahinter und das effiziente Austauschen von Preisinformatio-

nen ermöglichte das neue Dateiformat XML. Durch dieses integrierten sich Systeme der Ver-

käufer direkt in die der Kunden (vgl. Plattner et al. 2000, S. 228). Neben der Beschaffung

konnte die Planung für den zukünftigen Bedarf von dem System automatisch ermittelt wer-

den, da es wusste, wie lang die Bereitstellungszeiten der Zulieferer für die benötigte Ware

35

war. Dadurch erfolgte eine Just-in-Time-Planung der Güter und die Unternehmen benötigten

keine Sicherheitslager mehr. Bei Auslagerung der Beschaffungsprozesse auf ein externes Lo-

gistikunternehmen mussten diesem Zugänge zu dem mySAP.com-System und zu allen Daten

der Planung ermöglicht werden (Plattner et al. 2000, S. 240f).

Eine Version dieses Marktplatzes ist bis heute bei der SAP AG selbst in Betrieb und öffent-

lich zugängig (vgl. Abbildung 17).

Abb. 17: SAP Marktplatz (SAP Marktplatz 2010)

Der SAP Marktplatz teilt sich in folgende Bereiche auf: SAP Developer Network - für die

Entwickler an der SAP-Software, Business Process Expert Community - Treffpunkt für Ma-

nager zur Verbesserung ihrer Kommunikation untereinander und Industry Value Networks -

Diskussionsplattform für IT-Dienstleister und SAP AG Kunden21. Neben diesen Bereichen

der Innovationsgemeinschaften aus dem Geschäftskundenbereich kümmert sich dieses Portal

auch um die Eingliederung von Freiberuflern und um die an der SAP-Software interessierten

Menschen. Für jene ist die Innovationsplattform Innocentive mit eingebunden und bietet ei-

nen Raum, in dem sie sich mit SAP-Projekten beschäftigen können (vgl. Innocentive 2010).

Die engere Zusammenarbeit mit den Geschäftskunden und freiberuflichen Mitarbeitern er-

möglicht SAP einen Vorteil. Die Software erhält von den Kunden notwendige Verbesse-

rungsvorschläge, welche sich bei Umsetzung direkt positiv auf die Marktposition des SAP-

Produkts auswirken. 21 Ein für Nichtkunden gesperrter Bereich des SAP Marktplatzes, in denen Kunden der SAP AG miteinander diskutieren, zum Beispiel welche Funktionen den Anwendungen der Firma noch fehlen und wie sich die jeweili-gen Branchen weiterentwickeln werden.

36

Die Verbindung von Business Framework und der Objektorientierung führte parallel zu der

Entwicklung des Marktplatzes auch zur Entstehung der neuen Technik Enterprise Service

Oriented Architecture (ESOA). Das Konzept ESOA wurde in Palto Alto von Vishal Sikka

persönlich erarbeitet und lief bis zu seiner Umbenennung unter dem Namen SAP 3.0 (vgl.

Siegele 2009, S. 188f). Damit Kunden auch weiterhin, wie bei mySAP.com gewohnt, ihre

eigenen Anwendung bauen, ihre Geschäftsprozesse anpassen und durch Schnittstellen mit

anderen Programmen verknüpfen konnten, wurde der Dienst Netweaver konstruiert. Über

diesen kommunizierten die in kleinere Module aufgeteilten Softwarekomponenten. Es handel-

te sich um die integrierte Schnittstelle der Komponenten, deren lose Kopplung darüber koor-

diniert wurde (vgl. Woods 2005, S. 37f). Netweaver fungierte als Middleware zwischen der

Datenbank, der Systemsoftware und den darauf aufsetzenden SAP-Modulen (vgl. Abbildung

18). Das in mySAP.com umbenannte SAP R/3 wurde ab 2002 auf diese neu entwickelte Ar-

chitektur umgeschrieben und seit 2006 unter dem Namen SAP Business Suite 7 verkauft (vgl.

Woods 2005, S. 16).

Abb. 18: Architektur SAP Business Suite 7 (Hohlmann 2007, S. 58)

Diese Übertragung der Architektur auf SAP Business Suite 7 bot den Vorteil eines stabilen

Kerns, der dennoch flexibel an andere Systeme angepasst werden konnte. Diese Software

umfasste die Kern-Komponenten der Buchhaltung und des Finanzwesens, den Bereich Perso-

37

nalwirtschaft und operative Bereiche. Zusätzlich zu diesen Standardprodukten für alle Unter-

nehmen gab es die so genannten Industrie Specifics, auf Firmen einer Branche zugeschnittene

Produkte. Das Konzept ESOA mit der Komponente Netweaver und dem Marktplatz ermög-

lichte der SAP AG erst jetzt den Einstieg in den Markt der Best-of-Breed-Produkte, obwohl

dieser schon zu der Zeit des Internetbooms als der neue Wachstumsmarkt der betriebswirt-

schaftlichen Software galt. Einen starken Zuwachs in diesem Bereich erhielt die SAP AG

dann zusätzlich 2008 durch den Kauf von Business Objects (vgl. SAP Daten).

Je mehr Unternehmen SAP-Software nutzten, desto größer waren die Anreize für andere Fir-

men, es ihnen gleichzutun. Aus dem Verkauf der SAP-Software ergaben sich positive Fakto-

ren, die wiederum die Nachfrage steigerten. Bei der Überschreitung einer kritischen Masse

von Unternehmen, die SAP-Software nutzten, entstand darüber hinaus aus einem einfachen

Vorteil ein Netzeffekt. Dieser beschreibt genau den Mehrwert bei der Vernetzung von Gegen-

ständen oder Diensten.22 Von Beobachtern wird angenommen, dass die SAP-Software seit der

Verknüpfungsmöglichkeit BAPI und der Marktplatzsoftware diese kritische Masse überschrit-

ten hat und die Verkäufe durch diesen Effekt weiter angefacht wurden und werden (vgl.

Hohlmann 2007, S. 62 und Siegele 2009, S. 71).

Abb. 19: Faktoren, Strategien und Leitbilder für SAP Business Suite 7 (eigene Darstellung)

Die SAP-Strategien des global integrierten Unternehmens und der Partnerstrategie sind in der

Abbildung 19 mit aufgeführt, da sie bereits als Erfolgsfaktoren das Handeln der SAP AG be-

stimmten. Die Erläuterungen zu diesen finden sich allerdings erst unter Punkt 3.1.4, wie in der

Einleitung zu Unterkapitel 3.1 erläutert.

22 Ein Beispiel hierfür ist das Telefon, welches alleine keinen Nutzen hat, sondern erst durch die Vernetzung einen generiert.

38

3.1.3.3 SAP Business byDesign - das On-Demand-Produkt

Die Geschichte von Business byDesign begann zeitgleich mit der Entwicklung hin zur ESOA

im Jahr 2002 und mit dem Vorhaben, ein Produkt zu schaffen, was kleine und mittelständi-

sche Betriebe ohne die Hilfe von Beratern installieren und produktiv nutzen können. Compu-

ter-Laien sollten durch ein Frage-und-Antwort-System die Geschäftsprozesse für das eigene

Unternehmen selber generieren, welche per Maus grafisch erstellt und in die gewünschte

Formation gezogen werden (vgl. Siegele 2009, S. 194). Ziel war es, die Software auf eine CD

zu begrenzen. Peter Zencke entwickelte die grundlegende Architektur für dieses neue Pro-

dukt, auf der ein derart komplexes System laufen konnte (Projekt Vienna). Dies führte aller-

dings zu einer Software, die sich nicht auf die geplante Kapazität einer CD beschränkte und

zu schwierig für die Installation durch Laien angesehen wurde. Um den Umfang der Software

zu verbergen, installierte die SAP AG die Software auf Server und verkaufte diese anstelle

einer CD (Projekt Kayak unter der Leitung von Shai Agassi). Für dieses Produkt fanden sich

jedoch nur zwei Kunden und so wurde die Idee der vorinstallierten Software verändert (vgl.

Siegele 2009, S. 204). Ab 2006 sollte diese in den Rechenzentren der SAP AG laufen und die

Kunden über das Internet einen Zugriff auf die Nutzung der SAP-Software erhalten, das SAP-

On-Demand. Dies ermöglicht die neue Technik der Virtualisierung, die es erlaubt, mehrere

Betriebssysteme auf einer Hardware laufen zu lassen und somit Hardware durch Software

virtualisiert. Daraus folgt, dass die Unternehmen nach Kauf der SAP-Software kein eigenes

Rechenzentrum mehr benötigen, sondern die SAP AG für jedes Unternehmen einen eigenen

Server aufstellen würde. Statt der üblichen Lizenzgebühr und einer monatlichen Wartungs-

kostenpauschale finanziert sich das Produkt über eine monatliche Nutzungsgebühr pro Nutzer

von 149 Dollar. Eine erste Vorabversion von Business byDesign wurde am 19. September

2007 im Nokia-Theater in New York präsentiert (vgl. SAP Geschichte 4). Zu einem Verkauf

dieses Produktes kam es jedoch bis heute nicht (Stand Anfang 2010). Gründe für das Aus-

bleiben der Software sind der hohe Kostenaufwand für den Aufbau des On-Demand-Dienstes,

das Bereitstellen einer großen Anzahl von Servern, die Schaffung eines gut ausgebildeten

telefonischen Supportzentrums, da die Manager das Produkt alleine installieren sollen und

ihnen keine Hilfe von externen Beratern mehr zugesprochen wird, und der Aufbau einer neu-

en Verkaufsorganisation, da die Beratungspartner nicht mehr für dieses Produkt benötigt wer-

den (vgl. Siegele 2009, S.195 und 206). Business byDesign mit dem Konzept des On-

Demand-Dienstes trifft genau das derzeitige Schlagwort in den Medien, das Cloud Compu-

ting. Das Ziel von diesem ist, die Bindung an ein Softwaresystem zu brechen und die Nutzung

vieler unterschiedlicher ERP-Systemen gleichzeitig nebeneinander zu erlauben. Gleichzeitig

könnten Daten aus anderen Systemen wie Handhelds und mit RFID-ausgestattete Produkte

problemlos hinzukommen.

39

Abb. 20: Faktoren, Strategien und Leitbilder für Business byDesign (eigene Darstellung)

3.1.4 SAP weltweit

Das stete Wachstum der SAP AG ist nicht zuletzt auf ihre Internationalisierung zurückzufüh-

ren. Schon vor SAP R/2 setzte das Unternehmen John Deere im Jahr 1978 das System SAP

RF in europäischen und afrikanischen Tochterfirmen ein und übernahm damals die Überset-

zung der Softwaresprache ins Französische in Eigenleistung (vgl. Plattner et al. 2000, S. 23f).

Dabei ging die SAP AG zwei Wege, um international Fuß zu fassen. Zum einen exportierten

deutsche Firmen SAP-Software auf ihre ausländischen Tochterfirmen. Zum anderen trugen

ausländische Tochterunternehmen in Deutschland das SAP-System in ihre internationalen

Mutterkonzerne, wie beispielsweise bei der ICI (vgl. Leimbach 2008, S. 67). Dadurch wuchs

die Anzahl der SAP-Installationen international umso mehr, je erfolgreicher sich die SAP

national entwickelte. 1984 wurde in der Schweiz die SAP (International) AG gegründet und

weitere Dependancen folgten (vgl. Meissner 1997, S. 55). Im Jahr 1989 erwirtschaftete die

SAP AG 25% ihres Umsatzes außerhalb Deutschlands, 2008 waren es nur noch 19% des Um-

satzes innerhalb Deutschlands (vgl. SAP 2009 und Leimbach 2008, S. 67). Die Anforderun-

gen an die SAP-Software wuchsen mit der Zahl der ausländischen Unternehmen. Die Soft-

werker mussten sich mit dem Einstieg in das internationale Finanzwesen auf neue Formen des

Zahlungsverkehrs, auf Währungsfragen und länderspezifische Bilanzierungsvorschriften ein-

stellen (vgl. Meissner 1997, S. 54). Ein reines Übersetzen der Benutzeroberfläche deckte

demnach nicht gleichzeitig die ausländischen Gepflogenheiten ab. Eine Buchhaltungssoftware

beispielsweise musste auf die Vorschriften des jeweiligen Landes abgestimmt sein. Zur Lö-

sung dieser neuen Aufgaben benötige man mehr Mitarbeiter, die sich die SAP AG auf ver-

schiedene Art und Weise beschaffte. Die SAP AG baute Partnerschaften zu anderen Firmen

auf, welche die Software anpassten und in andere Unternehmen integrierten - Nutzung der

Mitarbeiter anderer Firmen. Weitere Mitarbeiter gewannen sie durch die Gründung von Ent-

wicklungsstudios weltweit - Anwerbung von Mitarbeitern durch Unternehmensausweitung.

40

3.1.4.1 SAP und die Partnerstrategie

Schon sehr früh in der Geschichte der SAP AG wurden Partnerschaften geschmiedet. Nach

dem Marktstart von SAP R/2 im Jahr 1981 überließ die SAP AG die Implementation dieser

Software dem EDV-Studio Ploenzke aus Wiesbaden, heute CSC Ploenzke AG. 1982 wurde

zusätzlich ein Bündnis mit der Plaut AG geschlossen, die nach Aussagen von Plattner die

Entwicklung der SAP-Module RK und R/3-CO maßgeblich mitbestimmt hatte (vgl. Meissner

1997, S. 52f und 195). Der Chef des Partnerprogramms der SAP AG 1996, Alexander Ott,

koordinierte das Partnerprogramm und die Schulung der Partnerfirmen. So ließen die großen

Beratungsunternehmen23 ihre Mitarbeiter in den 60 SAP-Ausbildungszentren24 in Dallas und

Toronto ausbilden. Das Beratungsunternehmen Price Waterhouse errichtete 1996 sogar auf

eigene Kosten in Philadelphia ein internationales SAP-Schulungszentrum (vgl. Meissner

1997, S. 126f). Neben diesen Stätten erlernen Studenten mittlerweile auch an Universitäten

ihr Wissen um die SAP-Software. Der Status eines SAP-Beraters kann über die SAP AG

Tochterfirma AsseT GmbH kostenpflichtig erworben werden (vgl. Meissner 1997, S. 216).

Insgesamt bestand und besteht die Möglichkeit sich bei der SAP AG als Vertriebs-, Entwick-

lungs-, Logo-, Technologie- und Hardwarepartner sowie als SAP-Softwarehaus zertifizieren

zu lassen (vgl. Abbildung 21).

Abb. 21: Partnerstrategie der SAP AG (von Arb 1997, S. 56)

Die Vertriebs- und Entwicklungspartner, heutiger Name SAP Software Partner, entwickelten

und boten von der SAP AG zertifizierte Ergänzungsprodukte zu den SAP-Systemen an. Da-

durch entstanden neben den Erweiterungen aus dem Hause SAP AG viele spezielle Standard- 23 Diese Beratungspartner werden in diesem Unterkapitel später genauer erläutert. 24 Hier wird auf den durch Quellen nachgewiesenen Stand von 1995 zurückgegriffen (vgl. Meissner 1997 S. 126).

41

pakete für ganze Branchen oder Anwendungsgebiete. Die speziellen Module für gesamte

Branchen bekamen den Namen Industrie Specific (vgl. Meissner 1997, S. 62). Für die verein-

fachte Einführung und die Erweiterung der SAP-Produkte hat das Partnerunternehmen IDS

Scheer gesorgt und Standards gesetzt. Das dort entwickelte ARIS Toolset erlaubte es, Ge-

schäftsabläufe vor der Einführung zu testen und zu analysieren. Dabei spielten ereignisge-

steuerte Prozessketten eine große Rolle, die Warnungen bei Fehlern und die Optimierung von

Geschäftsabläufen ermöglichten. Diese Neuerung machte IDS Scheer zum Marktführer bei

den BPR-Softwarewerkzeugen im Jahre 1997 mit 7.000 verkauften Lizenzen. Ein Grund da-

für war auch die nahtlose Integration in das System SAP R/3 (vgl. Meissner 1997, S. 208f).

Die SAP AG hielt an der IDS Scheer eine Sperrminorität von 25,3% und sorgte mit dieser

Beteiligung für eine starke Einflussnahme auf die zukünftig entwickelten Produkte. Für eine

bessere Zusammenarbeit untereinander gründete die SAP AG mit ihren Vertriebs- und Ent-

wicklungspartnern Tochterfirmen. Für die SAP-Softwarebetreuung von öffentlichen Verwal-

tungen, Banken und Versicherungen wurde mit der Software AG ein gemeinsames Tochter-

unternehmen die SAP System Integration GmbH gegründet, an der die SAP AG einen Anteil

von 60% hielt (vgl. Meissner 1997, S. 157f). Mit Siemens kooperierte die SAP AG über ein

Joint Venture mit der SRS GmbH in Dresden.

Die Beratungspartner, in der Abbildung 21 ‚Logopartner‘ genannt, unterstützten Unterneh-

men bei der Implementierung und Schulung an dem SAP-System. Der Vorteil, dass SAP-

Systeme ohne die Funktionalität zu verlieren in verschiedenen Ländern an die dortigen Ge-

pflogenheiten angepasst werden konnten, nahm der wachsende Markt für IT-Dienstleistungen

dankend an. Die SAP-Produkte wurden damit nicht nur von der SAP AG, sondern auch von

verschiedenen anderen Firmen mit in deren Beratungsprogramm aufgenommen und in Orga-

nisationen eingeführt. Der Hauptgrund dafür war, dass die Lizenzkosten, die an die SAP AG

gingen, einen wesentlich kleineren Teil der Implementierungskosten für Unternehmen aus-

machten, als das was an den Beratungspartner ging (vgl. Meissner 1997, S. 193). Das Ver-

hältnis entsprach 1:5 bis 1:10. Um ihren Ruf als objektive Berater dennoch aufrecht erhalten

zu können, argumentierten sie gegenüber ihren Kunden nicht mit der Partnerschaft, vielmehr

mit der Orientierung am Marktführer SAP AG. Sie priesen außerdem die SAP-Software als

Mittel der Reorganisation an - das BPR. Somit bestand offiziell keine direkte Vertriebspart-

nerschaft. Durch die Zusammenarbeit mit diesen Consultingfirmen erreichte die Verbreitung

der SAP-Produkte eine neue Dimension. Die Firmen galten wiederum für die SAP AG als

Türöffner zur Akquise neuer Kunden, da sie als etablierte Berater direkt an der Unterneh-

mensspitze ansetzten und keine Überzeugungsarbeit bei den EDV-Abteilungsleitern leisten

mussten (vgl. Meissner 1997, S. 92f). 1996 arbeitete die SAP AG mit den damals so genann-

ten Big Six zusammen, den alten amerikanischen Wirtschaftsprüfungsgesellschaften beste-

hend aus: Arthur Andersen, Cooper & Lybrand, Ernst & Young, ICS/Deloitte & Touche,

KPMG und Price Waterhouse. Heute sind von diesen ehemalige sechs nur noch die Big Four

übrig: Aus ICS/Deloitte & Touche entstand Deloitte Touche Tohmatsu, aus Cooper &

42

Lybrand und Price Waterhouse wiederum PricewaterhouseCoopers, Ernst & Young und

KPMG. Neben diesen großen Beratungsunternehmen knüpfte die SAP AG weitere Partner-

schaften mit vielen anderen Consultingbetrieben, wie den bereits oben genannten CSC

Ploenzke, Plaut AG und IDS Scheer. Hierbei vermischten sich die Funktionen von Beratungs-

und Entwicklungspartnern. Wie zum Beispiel bei der Price Waterhouse, die neben der reinen

Beratungstätigkeit spezielle Software oder Schablonen für die vereinfachte Einführung von

SAP-Modulen entwickelten (vgl. Meissner 1997, S. 195). Die Anzahl der externen Bera-

tungspartner belief sich nach einer Schätzung25 aus dem Jahr 1996 auf 18.000. Dazu zählten

unter anderem das Debis Systemhaus, Siemens Nixdorf Informationssysteme, Software AG

und VW Gedas. Die SAP AG selbst beschäftigte außerdem zu dieser Zeit intern 3.000 Fach-

leute in einem eigenen Beratungshaus (vgl. Meissner 1997, S. 190). Als Kommunikations-

plattform für seine Partner bot die SAP AG erstmals 1990 die Messe Sapphire an (vgl. Meiss-

ner 1997, S. 115).

Technologiepartner waren Anbieter verschiedener Softwaretechnologien, von deren Zusam-

menarbeit die SAP AG profitierte (vgl. Meissner 1997, S. 251). Für eine reibungslose Ver-

knüpfung der SAP-Software mit anderer Software benötigte die SAP AG das Wissen um de-

ren Funktionen. Nur so konnte die fehlerfreie Funktionalität der SAP-Software gewährleisten

werden. Die Kooperation mit Softwarehersteller garantierte eine nahtlose Zusammenarbeit

des SAP-Systems hinsichtlich anderer Komponenten, wie im Falle Microsoft hinsichtlich

Windows NT und der Office Suite. Microsoft als SAP AG Kunde war selbst auch daran gele-

gen, Produkte von Microsoft mit der SAP-Software zu verweben. Gemeinsam entwickelten

sie das Programm Duett und verbanden so einmal mehr die Office Anwendungen mit SAP-

Systemen (vgl. Siegele 2009, S. 217). Eine ähnliche Situation lag bei der Firma Autodesk vor,

die zuerst Kunde bei der SAP AG war, dann ihre CAD-Software für die SAP-Software an-

passte und dies als Verkaufsargument für beide Seiten nutzbar machte (vgl. Meissner 1997, S.

113f).

Die Kooperation mit den Hardwarepartnern sollte die Lauffähigkeit und den Gebrauch der

SAP-Produkte auf der Computerhardware gewährleisten (vgl. Meissner 1997, S. 74). Dabei

wurde mit den Hardwareherstellern wie Bull, IBM, Siemens Nixdorf, HP, Digital Equipment

und Sun eng zusammengearbeitet. Für die Entwicklung der Software SAP R/3 wurden an-

fangs die Rechner von Digital Equipment genutzt und danach die Rechner von HP bevorzugt

Das SAP-Systemhaus oder value added reseller war die Bezeichnung für kleine und mittel-

ständische Unternehmen, die SAP-Produkte verkauften und darüber hinaus Beratung, Schu-

lung, Support und ein SAP konformes Produkt anboten (vgl. von Arb 1997, S. 57). Diese vie-

len kleinen Firmen offerierten eigene Programme zur Unterstützung der Einführung oder Er-

weiterung der SAP-Suite (vgl. Meissner 1997, S. 93).

25 Meissner geht von rund 3.000 Fachleuten im Beratungsgeschäft bei der SAP AG aus und von 18.000 externen SAP-Beratern weltweit (vgl. Meissner 1997 S. 190).

43

Eine neuere Untersuchung26 ergab, dass trotz der Kosten, die ein Partnerstatus abverlangt, die

Bedeutung der Verbindung mit der SAP AG 51% der Unternehmen als sehr wichtig und 28%

als wichtig einschätzten (vgl. Computerwoche 2010 und Abbildung 22). Diese Partnerstrate-

gie spricht für ein wichtiges SAP-Erfolgskonzept.

Abb. 22: Bedeutung des Partnerstatus für Unternehmen (RAAD in Computerwoche 2010)

3.1.4.2 SAP als global integriertes Unternehmen

Die SAP AG versuchte den Weg des global integrierten Unternehmens zu gehen, um die bes-

ten Kräfte aus allen Teilen der Welt bündeln und damit den internationalen Anforderungen an

die SAP-Produkte mit einem internationalen Team begegnen zu können. Dabei wurde ver-

sucht eine Balance zwischen dem Glauben an das globale Dorf und die Unüberwindbarkeit

von kulturellen Unterschieden zu halten. Die Abgrenzung dieser Idee von den früheren multi-

nationalen Konzernen sieht der IBM Chef Sam Palmisano darin, dass global integrierte Un-

ternehmen als eine Einheit mit einer einheitlichen Strategie handeln, Arbeit auf Regionen in

der Welt verteilen, wo sie am billigsten oder besten verrichtet wird und die daraus kombinier-

ten Produkte weltweit vertreiben (vgl. Siegele 2009, S. 128f). Um dem Anspruch an ein glo-

bal integriertes Unternehmen gerecht zu werden, bildete die SAP AG weltweit Entwicklungs-

zentren, denen zwar je nach Kompetenz bestimmte Aufgabenbereiche übertragen wurden, die

sich dennoch als einheitliches Unternehmen koordinierten. So fand man die SAP AG außer in

26 Eine Untersuchung von RAAD zum Thema marketing spending, die im Januar 2010 bei 80 Partnern der SAP AG durchgeführt wurde (vgl. Computerwoche 2010).

44

Walldorf in Palto Alto, Tokyo, Bangalore, Ra’anana, Budapest, Sofia, Shanghai und Mont-

real. Diese Standorte können entsprechend einer Art Fit Map nach Eigenschaften und Fähig-

keiten geordnet werden, wonach sich wiederum die Zuteilung der verschiedenen Projekte

richtet. So setzen sich heute noch Produkte aus einzelnen Stückwerken der verschiedenen

Entwicklungszentren zusammen, wie zum Beispiel das Business byDesign27. Um daraus wie-

der ein integriertes Gesamtpaket zu schnüren, mussten und müssen alle Abteilungen über den

Erdball hinweg eng zusammenarbeiten. So entstehen über Ländergrenzen hinaus Projekt-

teams, so genannte virtuelle Teams, die sich zu Projektbeginn das erste Mal und oft das letzte

Mal während des Projektzeitraums persönlich treffen. Die tägliche Arbeit wurde und wird mit

Hilfe von Kommunikations- und Kollaborationswerkzeugen erledigt, wie mit Videotelefonie,

Online Verzeichnissen und anderen Internetdiensten (vgl. Siegele 2009, S. 135). Eine große

Errungenschaft dieses Prozesses bestand darin, dass die SAP AG durch die weltweite Auftei-

lung der Entwicklungszentren eine Supportabdeckung von allen Zeitzonen schaffte. Die Zu-

sammenarbeit über Kultur- und Ländergrenzen hinaus barg allerdings auch Nachteile und

Schwierigkeiten, es entstanden Kommunikationskosten und eine hohe Anforderung an die

soziale und emotionale Intelligenz von Mitarbeitern. Die SAP AG wollte diese Reibungsver-

luste auf einem erträglichen Maß halten und schulte deshalb Mitarbeiter durch das Global

Diversity Office und bestellte als Oberaufseher einen Chief Operation Officer, der gleichzeitig

Arbeitervertreter war. Dabei scheint die SAP AG den Zielkonflikt zwischen der Einhaltung

von Arbeiterinteressen und die Durchsetzung des Lean Managements28 hingenommen zu ha-

ben (vgl. Siegele 2009, S. 244). Im Folgenden wird eine Übersicht über die einzelnen Ent-

wicklungszentren gegeben und soweit möglich anhand ihrer Aufgaben in Ausführungs-, Ent-

wicklungs-, Produktplanungs- und Produktstrategie-Standorte sowie als Powerhouse29 klassi-

fiziert (vgl. Siegele 2009, S.121).

Deutschland: Die Anfänge von der SAP AG finden sich in Walldorf, von wo aus die ersten

Kundenkontakte geknüpft worden sind. Dieses Hauptquartier ist deshalb aus historischen

Gründen für das große Ganze und bei komplexen Problemen zuständig. Es werden hier 50%

der Entwicklungsarbeit erledigt, Softwarebestandteile aus Indien eingearbeitet und das Benut-

zerdesign nach Vorgaben aus Palto Alto programmiert. Damit erfüllt Walldorf die Vorausset-

zung für ein Powerhaus, welches zwar bestimmte Aufgaben abgegeben hat, aber immer noch

alle Aufgabengebiete der IT-Entwicklung abdeckt. Hier findet man einen hohen Grad an Mit-

arbeitertreue zu dem Unternehmen (vgl. Siegele 2009, S. 153f). Die durchschnittliche Be-

triebszugehörigkeit ist mit 8,6 Jahren höher als der Konzerndurchschnitt mit 5,4 Jahre. Mit

27 Siegele beschreibt hier, dass das Entwicklungsbüro in Indien für die Benutzeroberfläche, in Shanghai für die Anpassung an die verschiedenen Branchen und in Walldorf für die Business Logic, die Systemplattform, zustän-dig ist (vgl. Siegele 2009 S.134). 28 Lean Management soll für ein schlankes Unternehmen mit weniger Führungskräften mit Entscheidungsgewalt sorgen. Die Funktion des Arbeitsvertreters stützt hingegen die Interessen der Belegschaft. Hierzu sagt Stefan Kohl, der Vorsitzende des SAP-Betriebsrates. „[…] das ist ein wenig wie Verteidiger und Staatsanwalt in einer Person […]“ (vgl. Siegele 2009 S.244/245). 29 Das Powerhouse umfasst alle Prozesse der IT Produktentwicklung.

45

einer Wahrscheinlichkeit von 2,2 % besteht ein extrem niedriges Risiko von Kündigungen

und dem Wechsel zu anderen Unternehmen. Zu Deutschlands Qualitäten zählt die Annahme,

dass durch die ingenieursmäßige Herangehensweise und die industrielle Standardisierung die

Qualität und Zuverlässigkeit höher sei als anderswo (vgl. Siegele 2009, S. 158). Darüber hin-

aus gehört zum deutschen Entwicklungszentrum die Zentrale für die Globalization Services,

welche die sprachliche Anpassung der SAP-Programme an mindestens 30 Sprachen und der

Software an das Recht und Gesetz vieler Länder koordiniert. Hier erfolgt die grobe Modifizie-

rung des Systems, für Detailarbeiten verlässt sich die SAP AG hingegen auf die Arbeit seiner

Partner und Firmen vor Ort (vgl. Siegele 2009, S. 138f).

USA / Frankreich: Die Verbindung zu den USA entstand mit der Einführung des Produktes

SAP R/2 und wurde 1988 aus dem erstes Büro in den USA, aus Wayne Philadelphia, gesteu-

ert (vgl. Campbell-Kelly 2003, S. 194). Damals sollte die direkte Nähe zur ICI und zu einem

Flughafen den Erfolg bringen. Später wurde ein Entwicklungszentrum in Palto Alto, Silicon

Valley, für den Bereich Design gründete und in New York für das globale Marketing gebaut.

In Palto Alto arbeitete man unter der Leitung von Vishal Sikka, dem Chief Technology Offi-

cer, ebenso an dem Projekt SAP 3.0, der ESOA (vgl. Siegele 2009, S. 188). In dieser innova-

tionsgetriebenen Branche wurden die schnellen Ideen aus Amerika gebraucht (vgl. Siegele

2009, S. 158). Im Jahr 2008 kaufte die SAP AG die Firma Business Objects und damit ein

französisch-amerikanisches Unternehmen mit über 6.000 Mitarbeitern in den USA und Frank-

reich für 4,8 Milliarden Euro (vgl. Computerwoche 2007 und Siegele 2009, S. 153). Business

Objects zählte zu den führenden Anbietern im Markt für Business Intelligence (BI)-Produkte,

die im SAP-Bereich noch nicht stark genug vertreten waren. Dadurch erschloss sich eine neue

Produktpalette für die SAP AG. Die Zusammenarbeit der USA und Frankreich mit Deutsch-

land ist auf den Ebenen der Produktplanung und Produktstrategie zu positionieren.

Japan: Die Strategie nach Japan zu gehen wurde im Jahr 1991 mit der Einschätzung angegan-

gen, einen potentiellen großen Markt vor sich zu haben (vgl. Computerwoche 1991a). Die

Anpassung des SAP-Systems an den japanischen Markt dauerte drei Jahre und war die größte

Investition zur damaligen Zeit. Die SAP AG setzte auf ein rein japanisches Team, welches die

Aufgabe übernahm die SAP-Software auf die Double-Byte-Version30 zu heben. Der Entwick-

lungsstandort passte das SAP-System an den japanischen Raum an. Japan entwickelte sich im

Laufe der Zeit nach Amerika und Deutschland zum drittgrößten Markt (vgl. Plattner et al.

2000, S. 48). Die langjährige Verbindung Japans mit Deutschland, die ähnliche industrieba-

sierte Aufstellung des Landes, eine hohe Stabilität des Arbeitsmarktes und ein hohes Niveau

des Bildungssystems31 sprechen für eine gute und gewünschte Zusammenarbeit, speziell im

Bereich der Entwicklung.

30 Die japanische Sprache ist eine Silbensprache und dadurch reserviert diese, im Gegensatz zu der deutschen Sprache, zwei Bytes im Arbeitsspeicher, anstatt nur einem. 31 Strambach vergleicht die deutsche und japanische Softwareindustrie, welche sich durch die Gemeinsamkeiten Industrienation, Arbeitsmarkt und Bildungssystem auszeichnen (vgl. Strambach 2008, S. 147f).

46

Indien: Die SAP AG betreibt einen Campus in Bangalore mit 3.500 Mitarbeitern und einen

zweiten in Gugaon nahe Neu Delhi mit 700 Mitarbeitern. Insgesamt arbeiten 4.500 Mitarbei-

ter in Indien für die SAP AG. Für die Entscheidung nach Indien zu gehen, sprach die Steuer-

befreiung von IT-Firmen bis 2009 und der leere und zu teure Arbeitsmarkt für Softwareent-

wickler in Deutschland (vgl. Siegele 2009, S. 112f). Bangalore bot mit seinem Global Educa-

tion Center der Firma Infosys die größte Betriebsuniversität der Welt und damit jedes Jahr

eine halbe Millionen Absolventen für Informatik und Elektrotechnik. Die Eingliederung die-

ser Fachkräfte in die IT-Firmen erfolgte nach dem Bild der Human Supply Chain, welches die

Industrialisierung der IT-Dienstleistung darstellte: Die Betriebsuniversität produzierte eine

Masse an bereitwilligen Mitarbeitern auf einem Leistungsniveau. Diese Menge an Arbeitern

benötigte man für die vielen kleinen Schritte, in die der Prozess der zu entwickelnden Soft-

ware aufgeteilt wurde. Durch die sich wiederholenden Lernabschnitte sollte ein Mindestmaß

an Qualität eingehalten oder im Idealfall eine ständige Verbesserung des Produktes erreicht

werden. So beschränkte sich die Arbeit der indischen Entwickler auf die Wartung und Pflege

der Software, wie die Suche nach Datumsfeldern im Quellcode, um das Jahr-2000-Problem zu

lösen (vgl. Siegele 2009, S. 109f). Zwei weitere Vorteile für die Zusammenarbeit mit dem

Rest der Welt waren die geringen Kommunikationskosten, was sich aus der Beherrschung der

englischen Sprache und der digitale Verbindung mit dem Westen ergab, und die noch verhält-

nismäßig geringen Lohnkosten. Probleme bereiteten dagegen die schlechte Infrastruktur des

Landes und die hohe Fluktuation der Mitarbeiter, die sich jedoch positiv auf die Preisentwick-

lung der Lohnkosten auswirkte (vgl. Siegele 2009, S. 110f und 120f). Die Aufgaben Indiens

beschränken sich nicht mehr nur auf die Ausführung von Anweisungen, vielmehr entwickeln

sie mittlerweile das eigene Produkt Employee-Self-Service.

Israel: Das Entwicklungszentrum in Ra’anana entstand vor allem durch den Kauf der Firma

TopTier 2001, welche zu diesem Zeitpunkt Shai Agassi gehörte, einem späteren Anwärter auf

die oberste Führungsposition der SAP AG. Der Vorteil von Israel lag in der stark technisch

geprägten Ausbildung der Menschen. Aufgrund des militärischen Einflusses lag der Schwer-

punkt auf der Fernmeldetechnik und der Chip-Herstellung für die Mobilfunkindustrie. Die

Projekte in Israel umfassen die technischen Grundlagen eines IT-Produktes. Sie programmier-

ten zum Beispiel eine Plattform für den Austausch und Verbund von SAP-Software mit ande-

ren Herstellern, wie Microsoft. Für das Ballungsgebiet von Tel Aviv, in dem Ra’anana liegt,

zählte das Israel Venture Capital Research Center für das Jahr 2008 3.300 Start-Ups. Diese

hohe Zahl bescheinigt den großen kreativen Output der Region (vgl. Siegele 2009, S. 130f).

Ungarn und Bulgarien: Die Entwicklungszentren boten einerseits eine geografische Nähe zu

Deutschland, andererseits sollte es dort hoch spezialisierte Entwickler geben und die Lohn-

kosten eher niedriger sein (vgl. Siegele 2009, S. 133).

China: Shanghai werden bis jetzt lediglich Arbeiten zur sprachlichen Anpassung für bestimm-

te Regionen und Branchen übertragen. Das entstehende Know-How nutzen andere Zentren.

47

Kanada: Das Entwicklungsstudio in Montreal wurde mit Hilfe von Subventionen für IT-

Firmen aufgebaut (vgl. Siegele 2009, S. 134).

Abb. 23: Entwicklungszentren und deren Aufgaben (eigene Darstellung)

Der Gewinn der SAP-Strategie, eine weltweite Aufteilung hin zu einem global integrierten

Unternehmen, liegt in der Ingenieurskunst aus Deutschland, der Kreativität aus den USA und

Frankreich, der qualitativ hohen Ausbildung in Japan und Israel, der industriellen Informatik

bei den Indern, den Subventionen aus Kanada und der billigen Lohnarbeit in Bulgarien, Un-

garn und China.

3.2 Die Einführung von SAP-Software am Beispiel von SAP R/3 in Unternehmen

Die bisherigen Ausführungen über Produktentwicklungen von SAP-Software beinhalteten die

Planung und Umsetzung im Unternehmen SAP AG und deren Verbreitung auf dem Markt

durch externe Partner. Des Weiteren wurden Faktoren für oder gegen die Einführung von

SAP-Software in Organisationen herausgearbeitet. Doch wie verhält sich der Prozess der Ein-

führung nachdem sich Organisationen für SAP-Software entschieden haben? Die Beantwor-

tung dieser Frage wird im Folgenden am Beispiel von SAP R/3 gegeben. Die Sichtweise auf

die SAP-Software ändert sich von dem Unternehmen SAP AG zu den anwendenden Organi-

sationen. Es findet allerdings kein Perspektivwechsel statt, sondern eine Erweiterung des

Blickfeldes auf die Entwicklungsprozesse der SAP-Software in Unternehmen. Die gesonderte

Darstellung der Einführung der Software SAP R/3 ist der hohen Anzahl32 Studien um diesen

Bereich geschuldet. In der Anfangszeit von SAP hielten sich sowohl bei dem Produkt MIAS

als auch bei SAP R und SAP R/2 die Studien um die Einführung dieser Software noch in

Grenzen. Das System SAP R/3 hingegen hat auf dem Markt so großen Absatz gefunden und

eine so weitreichende Entwicklung durchlaufen, dass eine ausführlichere Beschreibung der

Strategien und Methoden der Einführung von SAP R/3 möglich ist. Der erste Teil des Kapi-

tels beschäftigt sich mit den in Studien genannten Gründen der Einführung von SAP-

Software. Darauf aufbauend werden die theoretischen Grundlagen der SAP-

Softwareeinführung und deren unterschiedliche Ausprägungen dargestellt und erläutert. Der

32 Die Studien um die SAP-Einführungen sind unter anderem Wolter 2006, Hohlmann 2007 und Jackwerth 2009.

48

Kriterienkatalog für die Analyse anhand der sozialwissenschaftlichen Techniktheorien und

des Mikropolis-Modells wird dementsprechend um die Erfolgsfaktoren aus diesem Teil er-

weitert.

3.2.1 Gründe der Einführung

Die quantitative Studie von von Arb33 zu den Gründen der Einführung von betriebswirtschaft-

licher Software im Allgemeinen und zu den Motiven für die Wahl von SAP-Software im

Konkreten kann Aufschluss über die Ansichten der Unternehmen geben (vgl. Abbildung 24

und Abbildung 25). Als Anlässe für die Erneuerung oder Neuanschaffung einer betriebswirt-

schaftlichen Software wurden als bedeutende Haupttreiber die veraltete bisherige DV-

Infrastruktur, die erweiterte Funktionalität der neuen Software, die Einsparung von Entwick-

lungs- und Wartungskosten und die Verfügbarkeit von neuer Technologie angenommen (vgl.

von Arb 1997, S. 243f).

Abb. 24: Auslösende Faktoren der Einführung von SAP R/3 (von Arb 1997, S. 244)

Zur Entscheidung für die Software SAP R/3 führten das Ziel der Abdeckung betriebswirt-

schaftlicher Anforderungen, der hohe Integrationsgrad der einzelnen Module, das Potential

für Weiterentwicklungen, der flexible Einsatz im Bezug auf die Anpassungsfähigkeit, die Of-

fenheit der Systemarchitektur und die Marktstellung/ -position der SAP AG.

33 Es handelt sich um eine quantitative Studie - Befragung von 95 Schweizer-Unternehmen zum Einsatz SAP R/3.

49

Abb. 25: Ausschlaggebende Argumente für SAP R/3 (von Arb 1997, S.249)

Weitere Studien zu diesem Thema umfassten differenziertere Beweggründe als die vorher

quantitativ abgefragten. So haben in der Studie von Hohlmann34 zur Einführung von SAP-

Software fünf von zwölf Unternehmen angegeben, dass SAP R/3 auf Veranlassung des Vor-

standes, der Konzernspitze, des IT Direktors der Konzernzentrale, einer Stadt oder der Mut-

tergesellschaft beruhten. Zusätzliche Einflussfaktoren waren die Wirtschaftlichkeitsrechnung,

das Werkzeug zur Umsetzung einer Verwaltungsreform, der Umstieg von der Kameralistik

auf die doppelte Buchführung, das Jahr-2000-Problem und zweimal die Erreichung der tech-

nischen Grenzen des Altsystems (vgl. Hohlmann 2007, S. 209f). Grundsätzlich beschrieben

alle befragten Firmen eine Abhängigkeit gegenüber der Technologie und insbesondere von

dem Technologiehersteller SAP AG (vgl. Hohlmann 2007, S. 220f). Die Umfrage von

Jackwerth35 zeigte, dass zwei von drei Einführungsprojekten eines Unternehmens auf der Ent-

scheidung der Konzernleitung beruhten, das dritte auf technischen Gründen (vgl. Jackwerth

34 Die qualitative Studie von Hohlmann über die Einführung von SAP-Produkten in 12 Unternehmen wurde anhand von Desk Research und Experteninterviews durchgeführt (vgl. Hohlmann 2007). 35 Die qualitative Studie von Jackwerth begleitete die Einführung von SAP-Produkten bei drei SAP-Einführungsprojekten (vgl. Jackwerth 2009).

50

2009, S. 65f). Die Studie von Buxmann und König36 aus dem Jahr 1997 besagt, dass die Ent-

scheidung über die Einführung von SAP-Produkten in circa 63 % der Fälle durch die Unter-

nehmensleitung getroffen wurde und die Fachabteilungen allein nur mit 5% daran beteiligt

waren (vgl. Buxmann und König 1997, S. 334f). Darüber hinaus spielten für die Einführung

von SAP R/3 noch die Grenzen des Altsystems, Netzeffekte und der Einfluss von Beratern

eine entscheidende Rolle (vgl. von Arb 1997, S. 244 und Hohlmann 2007, S. 62f). Neben dem

Positiven für die SAP-Software gab es auch einzelne Gegenargumente zur Einführung. Diese

betrafen die zu hohe Komplexität, die mangelnde Anpassungsflexibilität an Unternehmens-

strukturen, die fragwürdige Mittelstandsfähigkeit, der Einsatz von veralteten Technologien,

die lange Einführungszeit, die zentrale Datenhaltung und die schlechte Qualität neu ausgelie-

ferter Versionen (vgl. von Arb 1997, S. 46 und Wolter 2006, S. 60f). Die SAP AG war sich

dieser problematischen Einschätzungen durch anwendende Organisationen bewusst und trat

diesen mit den bereits genannten Maßnahmen entgegen: den SAP-Softwareeinführungen in

der Presse mittels success storys, dem Leistungsumfang der Software, der Softwarearchitektur

und der Stellung der SAP AG am Markt.

3.2.2 Methoden und Erfolgsfaktoren der Einführung

Ist die Entscheidung von Unternehmen für die Software der SAP AG gefallen, sollten die bes-

ten Voraussetzungen für eine erfolgreiche Einführung der Technik geschaffen werden. Hier-

für steht sowohl das SAP-Vorgehensmodell als Empfehlung für das Projektmanagement zur

Verfügung als auch die Strategien der IT-anwendenden Organisationen selbst.

3.2.2.1 Vorgehen und Projektmanagement

Allgemein lässt sich erst einmal festhalten, dass die projektspezifische Organisation in Projek-

ten37 unter der Aufsicht des Projektmanagements38 erfolgte, welches die Managementunter-

stützung für das Projekt in dem Unternehmen festlegte. Bei der Organisation der Einführung

des SAP R/3 Projektes boten sich das reine Projektmanagement, das Matrix-

Projektmanagement oder das Einfluss-Projektmanagement an. Ersteres fasst alle beteiligten

Mitarbeiter in einer zeitlich befristeten Organisationseinheit zusammen und wird von einem

Projektleiter geführt. Diese Form des Managements wird bei großen, komplexen sowie lang

andauernden Aufgaben genutzt. Bei dem Matrix-Projektmanagement überschneiden sich die

Kompetenzen der Leitungssysteme, was den Mitarbeiter den Verbleib in der Fachabteilung

und gleichzeitig die Mitarbeit im Projekt erlaubt. Das Einfluss-Projektmanagement beruht nur

36 Die Studie von Buxmann und König umfasst die Untersuchung der SAP-Einführung von 220 Unternehmen im europäischen Raum (vgl. Buxmann und König 1997). 37 Ein Projekt ist ein „[…] Vorhaben, das im Wesentlichen durch Einmaligkeit der Beteiligung in ihrer Gesamt-heit gekennzeichnet ist, wie z.B. Zielvorgabe, zeitliche, personelle oder andere Begrenzungen, Abgrenzung ge-genüber anderen Vorhaben, projektspezifische Organisation.“ ( DIN 69901 S. 155) 38 Projektmanagement ist die „[…] Gesamtheit von Führungsaufgaben, -organisation, -techniken und – mitteln für die Initiierung, Definition, Planung, Steuerung und den Abschluss von Projekten.“ (DIN 69901 S.158)

51

auf der nebenamtlichen und beratenden Funktion des Projektleiters. Aufgrund der beschränk-

ten Weisungs- und Entscheidungsbefugnisse würden auf die Organisation längere Einfüh-

rungszeiten und eine Demotivation der Mitarbeiter zukommen (vgl. Wolter 2006, S. 119).

Dieses Projektmanagement war für die SAP R/3 Einführung ungeeignet, fand bei den Unter-

nehmen kaum Berücksichtigung und wird deshalb hier in meinen Ausführungen vernachläs-

sigt. Die Geschäftsleitung hielt dabei in allen Organisationsformen die Fäden im Hintergrund

zusammen und stellte so eine effiziente Koordination des Projektmanagements sicher. Der

Lenkungsausschuss des Projektmanagements überwachte die ihm unterstellten Projektleiter

und sorgte für den Informationsaustausch und die Akzeptanz untereinander. Die Projektleiter

waren wiederum verantwortlich für die einzelnen Projektteams. Das Projektmanagement

konnte sich bei der Einführung von SAP R/3 entweder nach dem traditionellen Vorgehen oder

an der am häufigsten verwendeten Methode Accelerated SAP (ASAP)-Modell ausrichten39.

Das traditionelle Vorgehensmodell der SAP AG teilte die Projektaktivitäten in vier Phasen

auf: erstens die Organisation und Konzeption, zweitens die Detaillierung und Realisierung,

drittens die Produktionsvorbereitung und viertens der Produktivbetrieb (vgl. Abbildung 26).

Abb. 26: Traditionelles SAP-Vorgehensmodell (von Arb 1997, S. 161)

Dieses Modell entsprach dem klassischen Wasserfall-Vorgehensmodell, welches eine iterati-

ve Vorgehensweise der einzelnen Schritte mit möglichen Rückkopplungen zwischen den ein-

zelnen Entwicklungsphasen vorgibt. Der erste Schritt der Organisation und Konzeption be-

fasste sich mit der Vorbereitung des Projektes - die Einführung der Software SAP R/3 im

39 Es existieren verschiedene andere Einführungsmethoden, die ebenfalls für die SAP R/3 anwendbar wären. Diese sind in der Dissertation Methodenkern des Business Engineering von Höning 2009 zusammengefasst.

52

Zeitraum x. Dabei führten die Projektleiter ihre Projektteams an und sorgten für die entspre-

chenden Schulungen dieser. So konnten die Teams angeleitet und qualifiziert an der Einrich-

tung eines Testsystems, der Erstellung eines Anforderungskataloges an das System sowie der

Erstellung und Verabschiedung eines Soll-Konzeptes arbeiten. Im zweiten Schritt, der Detail-

lierung und Realisierung, beschäftigten sich die Akteure mit der Organisation selbst und er-

mittelten deren Stammdaten, Prozesse und Funktionen. Diese Ergebnisse wurden anschlie-

ßend umstrukturiert und in SAP R/3 Geschäftsprozessen abgebildet. Diese Prozesse unterlie-

fen anschließend Tests, wurden mit Systemerweiterungen verbunden und erneut getestet. Wa-

ren alle Arbeiten korrekt durchlaufen, stand am Ende das geprüfte und für die Produktivset-

zung freigegebene und fertig eingestellte System zur Verfügung. In der Produktionsvorberei-

tung, dem dritten Schritt, installierte man die notwendige Hard- und Software, erstellte die

Dokumentationen für die Anwender, schulte diese und übertrug die Daten und Systemeinstel-

lungen aus dem alten in das neue System. Der vierte Schritt, der Einsatz des Systems im Pro-

duktivbetrieb, konnte nun entweder anhand der Step-by-Step- oder der Big-Bang-

Einführungsstrategie vorgenommen werden. Die Step-by-Step-Einführungsstrategie ging von

der modulweisen oder regionalen Einführung aus. Aus diesen zeitlich versetzten Einführun-

gen konnten Rückkopplungen mit den Mitarbeitern entstehen, die sich auf die Verbesserung

des Endproduktes auswirkten. Diese Einführungsstrategie unterstützte dabei Prototyping-

Aktivitäten40, wodurch frühzeitig Fehler bei der Einführung erkannt und diese ebenfalls dank

Rückkopplungen bekannt gemacht und gelöst werden konnten. Die Big-Bang-

Einführungsstrategie hingegen legte die Einführung des SAP-Produktes an einem Stichtag in

dem gesamten Unternehmen fest, die Mitarbeiter waren dadurch vor vollendete Tatsachen

gestellt und die Einflussnahme eingeschränkt (vgl. Wolter 2006, S. 148).

Die ASAP-Methode basierte zwar auf dem traditionellen Vorgehensmodell, war allerdings

angereichert mit einer zusätzlichen Sammlung von Praxiserfahrungen, Best Practices, sowie

Integration von Projektmanagementaufgaben. Ziel dieser Methode war, es die Dauer und die

Kosten von SAP R/3 Einführungsprojekten zu minimieren und gleichzeitig die Qualität der

Einführung zu verbessern. Es lagen drei wesentliche Phasen zu Grunde: die Prozessorientie-

rung, die referenzprozessbasierte Implementierung und die Big-Bang-

Implementierungsstrategie. Die Prozessorientierung beschrieb das gesamte betriebliche Han-

deln als Kombination von Prozessen und eine Ableitung dieser in Geschäftsprozesse. Diese

Phase war mit dem Vorgehen in der Detaillierung und Realisierung des traditionellen Vorge-

hensmodells vergleichbar. Anders war dagegen die referenzbasierte Implementierung (Best

Practices), unter der man eine Nutzung der von der SAP AG vorgegebenen Referenzprozesse

mit vorformulierten Standardfunktionalitäten verstand. Das bedeutete, das Unternehmen griff

auf von der SAP AG vordefinierte Standardprozesse zurück und richtete danach seine Ge-

schäftsprozesse aus. Hatte sich die Organisation für die ASAP-Methode entschieden, erfolgte

40 Der Einsatz von Prototypen in der Softwareentwicklung lässt ein Feedback zu, wodurch eine schnellere Feh-lererkennung und ein besseres Endergebnis möglich werden können.

53

die Einführung dementsprechend an einem Stichtag nach der Implementierungsstrategie Big-

Bang (vgl. Wolter 2006, S. 128f).

Die Besonderheit solcher Einführungsprojekte, unabhängig ob nach der traditionellen- oder

der ASAP-Methode vorgegangen wurde, lag darin, dass die Software SAP R/3 während des

Einführungsprojektes relativ leicht an die sich verändernden Bedürfnisse angepasst werden

konnte. Nach Abschluss der Einführung war dies nur noch begrenzt möglich und das Ergebnis

des Einführungsprojektes markierte den weiteren Bewegungsraum der Organisation. So wur-

de das System bei einer unpassenden, falschen Einführung statt zu einer Lösung zu einem

Problem. Die Unternehmen konnten dann nur erschwert bis gar nicht auf Überraschungen

reagieren oder Ausnahmesituationen verarbeiten, wie die Ergebnisse aus der qualitativen Stu-

die von Hohlmann ergaben (vgl. Hohlmann 2007, S. 238). Ob die Einführung von SAP R/3

erfolgreich oder weniger erfolgreich war, hing von unterschiedlichen Faktoren ab, die sowohl

beim traditionellen Vorgehensmodel als auch bei der ASAP-Methode berücksichtigt werden

mussten. Die quantitative Befragung41 von Bearing-Point-Mitarbeitern ermittelte sieben Er-

folgsfaktoren für das Projektmanagement. Es handelte sich danach um die Einführungsstrate-

gie, die Managementunterstützung, die Kommunikation, die Qualifikation, die Partizipation,

die Zufriedenheit und die Unternehmenskultur (vgl. Wolter 2006, S. 211). In Abbildung 27

sind die Erfolgsfaktoren mit den höchsten Erfolgsaussichten zuerst angegeben. Die höchsten

Erfolgswahrscheinlichkeiten bei der Durchführung des Projektes zur SAP-Einführung ließen

sich durch eine gut gewählte Einführungsstrategie mit 19,2% fast gleichauf mit der Manage-

mentunterstützung und der Qualifikation mit 18,2% erzielen.

Abb. 27: Rangfolge der Akzeptanzfaktoren - Erfolg als abhängige Variable (Wolter 2006, S.

211)

41 Die quantitative Studie von Wolter 2006 basiert auf der Befragung von über 200 Mitarbeitern des Beratungs-unternehmens Bearing-Point.

54

Die Faktoren wirkten jedoch nicht für sich alleine, sondern agierten untereinander in einer aus

einseitigen und wechselseitigen Beziehungen bestehenden Matrix (vgl. Abbildung 28). Die

Managementunterstützung beispielsweise wirkte einseitig auf Kommunikation, Qualifikation,

Zufriedenheit und Partizipation und wechselseitig auf die Unternehmenskultur.

Abb. 28: Matrix der wechselseitigen Beeinflussung der Erfolgsfaktoren (Wolter 2006, S. 213)

Die Einführungsstrategien galten als stärkstes Mittel zur Akzeptanzsteigerung bei der Einfüh-

rung von SAP R/3. Die Unternehmensberater bewerteten das Prototyping und einen kombi-

niertes regionales wie modulweises Roll Out als erfolgsversprechend, welches sich in der tra-

ditionellen Vorgehensweise wiederfand. Die ASAP-Methode basierte auf der Nutzung von

Best Practices und der Einführungsstrategie Big-Bang. Die Verwendung der Best Practices

ergab in der gleichen Befragung eine hohe Zustimmung, wohingegen die Big-Bang-

Einführungsstrategie in der Reihenfolge der besten auf dem letzten Platz rangierte. Die Big-

Bang-Strategie hatte aus der Sicht von über 50% der Befragten einen negativen bis stark ne-

gativen Einfluss auf die Erfolgswahrscheinlichkeit der SAP-Softwareeinführung (vgl. Abbil-

dung 29).

Abb. 29: Rangfolge der Einführungsstrategien (Wolter 2006, S. 243)

55

Der Begriff Managementunterstützung stand für die gute Zusammenarbeit der Personen des

Projektmanagements und trug zur Förderung der Akzeptanz des Projektes bei. Die Vorbild-

funktion signalisierte den Mitarbeitern die Wichtigkeit des Projektes. Dabei wurden die aktive

und regelmäßige Teilnahme an Projektausschusssitzungen und der Wille zur Entscheidungs-

findung besonders hervorgehoben. Hier konnte das Management durch Kommunikation als

Multiplikator der Überzeugungskraft wirken, da eine erhöhte Akzeptanz der Aussagen des

Managements bei den Mitarbeitern vorherrschte. Abgesehen von der Mitarbeiterzustimmung

war das stärkste Mittel des Managements seine hierarchische Position, die Durchsetzungskraft

und Macht mit sich brachte. Diese Betrachtungen führten zu der Erkenntnis, dass die Beteili-

gung des oberen und mittleren Managements an solchen Projekten maßgeblich den Erfolg

beeinflusste. In der Praxis wurde in der Studie von Buxmann und König festgestellt, dass

Führungskräfte meist als Initiatoren der Projekte zu identifizieren waren.

Maßnahmen der Qualifikation bereiteten die Mitarbeiter auf die bevorstehenden Veränderun-

gen vor und halfen Ängste vor möglicher Überforderung abzubauen. Die Qualifikation wurde

mittels der Qualifikationsinstrumente erreicht. Hier halfen unter anderem Schulungen, Off-

the-job-Trainings und Workshops. Ziel war es, SAP-Technikwissen aufzubauen und seine

Konservierung für das Unternehmen zu gewährleisten.

Instrumente der Kommunikation spielten eine zentrale Rolle für die Initiierung, Konzipierung

und Stabilisierung einer Veränderung. Das große Potential der Kommunikationsinstrumente

war, Aufmerksamkeit zu erzeugen, bei der Fehlerdiagnose zu helfen, Träger von Verände-

rungsbotschaften zu sein und allgemein die Akzeptanz für das neue Projekt zu schaffen (vgl.

Wolter 2006, S. 229). Die Kommunikation betraf den gesamten Prozess der Einführung und

die Kommunikationsinstrumente waren die elementaren Glieder, welche einen wechselseiti-

gen Informationsaustausch koordinierten. Meetings, Workshops und Aushänge unterstützten

die Kommunikation und ermöglichten auch die Qualifikation, Motivation und Organisation

der Mitarbeit und Berater.

Eine hohe Partizipation der Mitarbeiter zum Projekt war erfolgsentscheidend für die Einfüh-

rung der Software. Die gute Zusammenarbeit mit den Mitarbeitern bei der Festlegung und

Formulierung der Projektziele, bei der Erstellung des Anforderungskataloges, bei der Grob-

und Feinkonzeptionierung des zukünftigen Systems sowie bei der Diskussion und Entschei-

dung der möglichen Lösungsansätze beeinflussten das Projektergebnis. Anregungen und Kri-

tik der Fachabteilungen sollten im Implementierungsprozess aufgenommen und berücksich-

tigt werden. Dies hätte eine starke Beziehung zwischen den Mitarbeitern und dem Vorge-

hensmodell zur Folge gehabt und Feedback-Schleifen ergeben, wie in der traditionellen Ein-

führungsmethode empfohlen. In Wirklichkeit wurde das Projekt meist trotzdem als Top Down

Initiative dem Unternehmen aufgedrückt und mittels der ASAP-Methode durchgeführt, so

dass die Mitarbeiter eher wenig oder gar keinen Einfluss auf die Auswahl und die Adaption

der neuen Softwarelösung hatten (vgl. Wolter 2006, S. 237 und S.243). Um hier dennoch die

Partizipation und die Zustimmung zu dem Projekt zu steigern und somit Ablehnung zu ver-

56

hindern, wurde an der Motivation der Mitarbeiter gearbeitet. Deren Beteiligung an Entschei-

dungsprozessen sollte sich auf die Mitarbeiter positiv und produktiv auswirken. Die Instru-

mente der Kommunikation, Qualifikation und Motivation waren der Kit, der die Einführungs-

strategien zusammenhielt, und ein elementarer Bestandteil jeder SAP-Softwareeinführung

(vgl. Wolter 2006, S. 229f, Hohlmann 2007, S. 227f und Promberger 2006, S. 344).

Die Unternehmenskultur spielte bei der direkten Einführung von SAP R/3 eine eher geringfü-

gige Rolle. Dieser Faktor hatte zwar für die langfristige Unternehmensgestaltung einen hohen

Stellenwert, konnte bei der relativen Kürze eines SAP-Projektes aber vernachlässigt werden

(vgl. Wolter 2006, S. 228).

Die Zufriedenheit der Mitarbeiter wirkte sich häufig auf die Motivation der Mitarbeiter aus.

Anreizsysteme mit sanktionierenden und belohnenden Maßnahmen wurden benötigt, um Ein-

fluss auf die Partizipation der Mitarbeiter auszuüben.

3.2.2.2 Key User und Promotoren

Ein Vorteil des Matrix-Projektmanagements war das zweigeteilte Arbeitsverhältnis der Pro-

jektteilnehmer, die durch zusätzliches Wissen und Kenntnisse des operativen Geschäfts der

Fachabteilungen besonders die Erfolgsfaktoren Qualifikation, Kommunikation und Partizipa-

tion unterstützten (vgl. Bär 2001, S. 205). Diese Akteure, die zeitgleich in den Fachabteilun-

gen und an dem SAP-Projekt arbeiteten, nannte man Key User oder Super User. Sie definier-

ten sich über ihre ausgeprägten Fach- und Prozesskenntnisse der jeweiligen Fachabteilung.

Außer dieser Mehrarbeit bildeten sie soziale und informelle Netzwerke, sie trafen sich zum

Beispiel abteilungsübergreifend nach der Arbeit. Über diese alten Kanäle wurden Informatio-

nen, das Wissen zwischen den Akteuren, ausgetauscht (vgl. Hohlmann 2007, S. 227). Die Key

User wurden in fast allen Unternehmen anerkannt und für sehr wichtig für ein erfolgreiches

Projektmanagement erachtet (vgl. Hohlmann 2007, S. 214, Promberger 2006, S. 343 und

Meissner 1997, S. 205).

Promotoren waren die institutionalisierten Key User und teilten sich in die drei Arten Macht-,

Fach- und Prozesspromotoren auf (vgl. Witte 1973, S.14f). Ihr Aufgabengebiet bestand aus

verschiedenen Funktionen und Leistungen in der gesamten Firma mit dem hauptsächlichen

Ziel, die Barrieren der Mitarbeiter gegenüber der Neuerung SAP R/3 zu überwinden. Die

Machtpromotoren galten als Paten und Sponsoren des Veränderungsprozesses, welche über

Sanktionsmechanismen42 den notwendigen Nachdruck für erfolgreiches Arbeiten verleihen

und eine Vorbildfunktion erfüllen sollten. Diese starke Bedeutung für die Einführung erlang-

ten sie durch die Durchsetzungsmacht und die Vorbildfunktion als Multiplikator im Kommu-

nikationsprozess. Die Fachpromotoren definierten sich durch spezielles Expertenwissen, wel-

ches zu alternativen Lösungsvorschlägen führen konnte. Ihre Kompetenzen sorgten für

Glaubwürdigkeit bei der Durchsetzung von neuen Vorschlägen. Das Expertenwissen war die

42 Es können zum Beispiel Abmahnungen, Streichung von Boni, Überstundenverordnun vorgenommen werden.

57

Machtquelle für die Überwindung von Widerständen, die sich dem Fachpromotor entgegen-

stellten. Die Prozesspromotoren als Prozessbegleiter sorgten für die projektinterne Koordina-

tion und übten eine Moderationsfunktion aus. Dabei waren Kenntnisse der Organisation, der

Führungskräfte und Strukturen elementar. Sie sicherten sich den nötigen Respekt von den

Kollegen und überwanden so die Barrieren der Mitarbeiter zu dem Einführungsprojekt. Genau

wie die Fachpromotoren konnten auch die Prozesspromotoren extern angeworben werden

(vgl. Wolter 2006, S. 244f). Der gleichzeitige Einsatz aller drei Promotoren galt als ein er-

folgsversprechendes Instrument bei der Implementierung von SAP-Software. Die Promotoren

wirkten am besten im Verbund und wenn sie sich untereinander abstimmten (vgl. Wolter

2006, S. 261). Sie leisteten gemeinsam einen wertvollen Beitrag zur Schaffung der Akzeptanz

des neuen Systems (vgl. Wolter 2006, S. 279).

3.2.2.3 Externe Berater

Sowohl bei dem reinen wie auch bei dem Matrix-Projektmanagement bestand die Gruppe der

an der Einführung der Software SAP R/3 beteiligten Akteure meist nicht nur aus den Mitglie-

dern des Unternehmens, sondern erweiterte sich um die externen Berater, zum Beispiel um

die Unternehmensberatungsgesellschaften. Eine Unternehmensberatung sollte das Erfah-

rungsdefizit in einem Unternehmen ausgleichen und wurde deshalb als professionelle entgelt-

liche Dienstleistung in Anspruch genommen. Die Berater stellten eine Entscheidungshilfe für

den Mandanten dar, ein wesentliches Merkmal dieser Dienstleistung. Dabei war eine partner-

schaftliche Kommunikation und Interaktion unerlässlich, bei der die Berater in führend-

helfender Weise dem Mandanten zur Seite standen (vgl. Kröber 1991, S.31f). Dieser komple-

xe Beratungsprozess verhalf einem SAP-Projekt zwar oft zu einem Erfolg, konnte jedoch

durch die starke Kopplung aneinander auch Konflikte auslösen. Aus der qualitativen Untersu-

chung von Hohlmann43 geht hervor, dass externe Beratern von allen Unternehmen durchge-

hend eingesetzt wurden und generell zu der Einführung von SAP-Projekten dazugehörten. Die

Unternehmen waren abhängig von dem Wissen und der Erfahrung interner wie auch externer

Mitarbeiter. Beim Einkauf des Expertenwissens kam es nicht nur auf dasjenige fehlende Wis-

sen um die Einführung der Standardprozesse der SAP-Software an, sondern auch auf die als

aufwendig beschriebene Anpassung der SAP-Standardsoftware an die betrieblichen Aufga-

ben. Zwar wollten sich sieben von zwölf untersuchten Unternehmen44 explizit nach dem SAP-

Standard richten und dadurch Modifikationen im System vermeiden. Keines der untersuchten

Unternehmen konnte sich indessen rein daran halten (vgl. Hohlmann 2007, S. 215 und 232f).

Ein beutender Fall in diesem Kontext war der Abschluss eines Kooperationsvertrags von ei-

43 Die quantitative Studie von Hohlmann aus dem Jahr 2007 beschäftigt sich mit den sozialen Auswirkungen technischer Systeme und hierbei speziell der Software SAP R/3 auf die Organisationen. Es wurden insgesamt 12 Organisationen bei der Einführung der SAP-Software begleitet und deren Besonderheiten festgehalten. 44 Diese sieben Unternehmen waren ein Fahrzeughersteller, ein Flächenfertiger, eine Vermarktungsgesellschaft, eine Stadtreinigung, ein Logistikdienstleister und zwei Hochschulen (vgl. Hohlmann 2007 S. 213).

58

nem großen Fahrzeughersteller mit der SAP AG selbst als externen Berater (vgl. Hohlmann

2007, S. 77f). Diese Partnerschaft führte dazu, dass der externe Berater SAP AG nach prob-

lematischer Einführung die neue Software korrigieren und in seiner parallelen Funktion als

Softwarehersteller umgehend die Standardprozesse auf die Anforderungen des Anwenders hin

entwickeln konnte. Diese Kooperation war für den Fahrzeughersteller ein entscheidender Er-

folgsfaktor der Einführung der SAP-Software, aber auch dank der Rückkopplungen ein Ent-

wicklungspotential für die SAP-Software. Umgekehrt liefen einige der hierbei entstandenen

Prozesse und Strukturen in spätere SAP-Standardrelease ein (vgl. Abbildung 30). Diese Zu-

sammenarbeit stellte in dem Set der untersuchten Unternehmen jedoch eine einzigartige Form

der Zusammenarbeit zwischen der Organisation und der SAP AG als externer Berater dar.45

Abb. 30: Reziproke Systementwicklung (Hohlmann 2007, S. 77)

Generell verringerte sich die Abhängigkeit von den externen Beratern im Laufe des Projektes.

In den Köpfen der Mitarbeiter und der Berater entstand während des Projektzeitraumss neues

Wissen. Diese Lerneffekte führten zu beschleunigten Abschlüssen von Projekten und zu kriti-

scheren Beraterauswahlverfahren. In diesem Zuge wurden immer häufiger extern eingekaufte

Berater dauerhaft abgeworben oder eher ein Wechsel zu anderen Beratungsorganisation mit

mehr Erfahrung zu spezifischen Problemen vollzogen (vgl. Hohlmann 2007, S. 222f). Eine

Kombination aus Promotoren und externen Beratern übte einen starken Einfluss auf den er-

folgreichen Abschluss von Einführungsprojekten aus (vgl. Wolter 2006, S. 273). Insgesamt

betrachtet, änderte sich in den SAP R/3 einführenden Unternehmen die Aufbauorganisation

durch die Übernahme von Unternehmensberatern, durch die Gründung eigener Abteilungen

für die Organisation des SAP-Systems und durch die Personalanstellung für den Aufbau der

SAP-Betreuung (vgl. Hohlmann 2007, S. 96, 137 und 218).

45 Aus Sicht der SAP AG würde man von der Entwicklung beim Kunden sprechen.

59

4. Analyse der SAP-Technikentwicklung mittels sozialwissenschaftlicher

Techniktheorien und dem Mikropolis-Modell

Ich werde mich im folgenden Kapitel, aufbauend auf den Techniktheorien aus dem zweiten

Kapitel und der Beschreibung der Technikentwicklung der SAP AG aus Kapitel 3, analysie-

rend Stück für Stück an die fast 40-jährige, komplexe Entwicklung des Multimilliarden Euro

Unternehmens SAP AG herantasten und die gewonnen Ergebnisse dieser Untersuchung prä-

sentieren. Ich gehe dabei den Fragen nach, ob die Entwicklung nur aufgrund der inneren Kraft

der Technik stattgefunden oder ob auch ein Wechselspiel von Technik, Akteuren oder Gesell-

schaft46 die SAP-Strukturen geformt und die SAP-Software beeinflusst hat. Die ermittelten

Entwicklungsabschnitte der SAP AG, wie die Zeit des Mainframes, die Zeit der Client-

Server-Systeme, das Internet, die Globalisierungsstrategien und der derzeitige, werden theore-

tisch eingebettet beziehungsweise vor dem Hintergrund des Technikdeterminismus, der ANT

und des Mikropolis-Modells untersucht und erklärt. Des Weiteren sollen die Gründe der Ein-

führung der SAP-Software in Unternehmen mit den Erfolgsfaktoren Projektmanagement, Key

User und Promotoren sowie externe Berater betrachtet und eingeschätzt werden.

4.1 SAP aus Sicht des Technikdeterminismus

Nach der Theorie des harten Technikdeterminismus ändert sich die Gesellschaft aufgrund der

Auswirkungen von Technik unmittelbar, bei dem etwas schwächeren nach einem cultural lag

und nach dem weichen Technikdeterminismus mit einer technischen Trägheit. Auf SAP be-

zogen würde man technikdeterministisch demnach wie folgt erklären: Die Anpassung an eine

Technik verändert die Handlungen der Gesellschaft und damit die der SAP AG als Teil derer.

Das Handeln der SAP AG umfasst die Entwicklung der SAP-Software, die demzufolge dem

Druck von Technik folgt und wiederum selbst als Innovationstechnik auf die Gesellschaft

wirkt. Diesen Annahmen wird jetzt fragend nachgegangen: Ob und wenn ja welche Technik

hat zu den Entwicklungen der SAP-AG geführt? Welche subversive Kraft der Technik trieb

die SAP-Technikentwicklung voran? Wirkte die Software der SAP AG auf die Gesellschaft

unmittelbar, nach dem cultural lag, nach der technischen Trägheit oder nach keiner der drei

Varianten? Oder andersherum gefragt, reagierte die SAP AG als Teil der Gesellschaft und

dadurch mit Softwareentwicklungen auf bestimmte Techniken nach den drei Möglichkeiten

des Technikdeterminismus und wenn ja, auf welche?

4.1.1 SAP zur Zeit von SAP R und SAP R/2 - die Gründungszeit

Die allgemeine Entwicklung der Software zur Gründungszeit der SAP AG bis zum Jahr 1987

ging mit einem Wechsel von dem Batchverarbeitungssystem zu der integrierten Echtzeit-

46 Hier sei noch einmal auf das Verständnis des Begriffs Gesellschaft hingewiesen, der Organisationen und Un-ternehmen einschließt.

60

Standardsoftware einher. Die verwendete Hardware der SAP-Systeme war bis 1977 strikt an

IBM gebunden und erst ab jenem Jahr knüpfte die SAP AG eine Verbindung zu Siemens und

erweiterte damit seine technologische Basis (vgl. Leimbach 2008, S. 66). Dadurch bestand

eine Beziehung zwischen der SAP AG und den einzigen zwei signifikanten Hardwareherstel-

lern für Computerhardware. Dieser Verbundenheit blieb die SAP AG bis zu der Ankündigung

eines neuen Technologiewechsels von IBM auf AS/400 1987 treu. In den 60ger Jahren wur-

den die Softwaresysteme BomP und PICS als Konzept der integrierten Datenverarbeitung

kombiniert. Dieses Vorhaben wurde zusammen mit dem Echtzeitverarbeitungssystem RoS

von der SAP AG im Produkt MIAS bei der ICI, dem ersten Auftrag der SAP AG, verwirklicht

und umgesetzt. Dieser Technikpfad mündet in SAP R auf der Hardwareplattform IBM /360,

gefolgt von SAP R/2 auf dem IBM /370 und dem Siemens Typ 7738. Die Entwicklung an

MIAS ist aus technikdeterministischer Sicht mit der Wirkung von Technik, die von den Vor-

arbeiten bei IBM und der sich daraus entwickelten Technikidee der integrierten Echtzeitver-

arbeitung ausging, dahingehend zu erklären, dass die SAP-Gründer als Teil der Gesellschaft

und ihr Handeln ebenfalls diesen technischen Visionen folgten. Durch das auf Technik basie-

rende Leitbild MRP verstärkte sich die Entwicklung an dem Produkt MIAS - die Handlungen

der SAP AG wurden in eine bestimmte Richtung geleitet, die Vorgänger BomP und PICS

übten einen sanften Druck entsprechend dem schwächeren Technikdeterminismus aus. MIAS,

SAP R und SAP R/2 veränderten unmittelbar die Ablauforganisation in Unternehmen. Die

SAP-Software gewährte die allgemeine Verfügbarkeit von Echtzeit-Informationen, struktu-

rierte die Organisation neu nach Geschäftsprozessen und ermöglichte zum Beispiel damit

nicht nur monatlich oder jährlich einen Abschluss der Konten, sondern permanent (vgl. Platt-

ner et al. 2000, S. 51f). Die stetige Buchhaltung machte den aufwendigen Monatsabschluss

überflüssig.

„Wir haben sehr früh damit begonnen, die Art und Weise, wie Firmen geführt werden,

zu verändern. Wir haben z.B. die Weise verändert, wie Firmen in Deutschland ihre

Buchhaltung machen. Wir haben einige grundlegende Prinzipien des Rechnungswe-

sens verändert. […] Wir hatten also ein technisch einwandfreies System, das die Leute

zwang, ihre Vorgehensweisen zu ändern.“ (Hasso Plattner in Plattner et al. 2000, S.

51)

Diesen Zwang der Technik und seine direkten Auswirkungen auf gesellschaftliche Organisa-

tionen beschreibt der starke Technikdeterminismus. Doch diese SAP-Technikentwicklungen

brachten nicht nur Vorteile für die Organisationen, sondern begrenzten ebenso deren Hand-

lungsfreiräume. Die Wünsche der Kunden wurden zwar angehört und in Gremien diskutiert,

doch bestimmten am Ende die Softwarehersteller, was entwickelt wurde. Die Aussage von

Hasso Plattner stützt diese Annahme:

61

„Wir sind nämlich in den ganzen 70er und 80er Jahren nur beschränkt auf den An-

wender eingegangen. […] Das ist ja das, was die Mainframe-Welt, die zentrale Daten-

verarbeitungswelt an Arroganz gegenüber dem Anwender ausgestrahlt hat.“ (Plattner

et al. 2000, S. 103)

Allerdings hingen die Entscheidungen nicht allein von dem Wollen der SAP-

Softwareentwickler ab, vielmehr grenzten die strengen Vorgaben der Hardware die Software-

entwicklung stark ein. Die starre Haltung der damaligen Technik ging auch in die Hand-

lungsweise47 des Unternehmens über, welches eine SAP-Technik einführte. War die Stan-

dardsoftware erst in dem Unternehmen installiert, hatte sie die Eigenschaft, vor der Einfüh-

rung fasst beliebig anpassbar zu sein, aber danach Änderungen der Geschäftsprozesse nur

noch mit großem Aufwand möglich zu machen. „Software, die an Organisation "angepaßt"

werden kann, ist wie flüssiger Beton. Sie wird in die Organisation "gegossen" und härtet dort

aus. Danach kann sich die Struktur der Organisation nur noch dort bewegen, wo sie sich

schon während der Aushärtung bewegt hat.“ (Brödner et al. 2002, S. 17) Die durch die SAP-

Software vorgegebenen Strukturen und deren Festigkeit ließen alternative Technikeinführun-

gen nur mit großem Aufwand, mit einer technischen Trägheit, verfolgen, so dass von dem

technischen Druck des etwas schwächeren Technikdeterminismus, in diesem Fall ausgehend

von der SAP-Software, gesprochen werden kann. Die Gedanken hinter der Technik wurden in

Leitbildern und Schlagworten zusammengefasst, nach dem sich die Unternehmen richten

konnten. Da MRP und MRP II durch die Technik, auf der sie beruhten und die jene gleichzei-

tig beinhaltete, in der Gesellschaft verbreitet und etabliert wurden, wuchs wiederum der

Druck auf die Unternehmen, also auch auf die SAP AG, diesen Leitbildern zu entsprechen

und somit dem Pfad der Technik zu folgen.

Der Technikdeterminismus beschreibt und erklärt bis hierhin die SAP-Entwicklung in ihren

Wirkungsweisen auf die Gesellschaft und damit auf sich selbst als Teil davon. Allerdings fin-

den sich bei näherer Anwendung dieser Theorie Brüche oder Alternativen in der Argumenta-

tionslinie, wenn es darum geht, die Technikentwicklungen und ihre Auswirkungen in ihren

Ursachen und Bedingungen zu beschreiben. So ist ein wesentlicher Auslöser für die Entste-

hung der SAP AG die unbundling-Entscheidung im Zusammenhang mit dem damaligen

Hard- und Softwaremonopolisten IBM. Diese Entscheidung wurde vom Amerikanischen Jus-

tizministerium angeleitet, da IBM unter dem Verdacht stand, seine Software unter Marktpreis

zu verkaufen (vgl. Campbell-Kelly 2003, S. 109). Bis dahin konnte IBM seine Monopolstel-

lung durch die Bündelung von Hardware und Software halten. Durch die erzwungene Auflö-

sung dieser Verbindung entstand die Voraussetzung für die Gründung der SAP AG und die

Weiterentwicklung der Technik von dem RoS zu dem lauffähigen MIAS. Weiterhin lässt sich

im Zusammenhang mit der Durchsetzungskraft der Technik MIAS, statt mit der subversiven

47 Hinsichtlich der Handlungsfreiheit verweise ich auf die Struktur der Organisation durch angepasste Software bei Brödner et al. 2002 S. 17.

62

Kraft der Technik, ebenso mit der Monopolstellung der SAP AG zu der Zeit argumentieren

(vgl. Computerwoche 1991b). Insgesamt finden die herausgearbeiteten Kriterien und Strate-

gien, wie die Mitnahme der Erfahrungen und Geschäftskontakte von IBM hin zu der SAP

AG, die Pilotprojektstrategie, Mundpropaganda, Geschäftskontakte und die Partnerstrategie

keinen hinreichenden Erklärungskontext.

4.1.2 SAP zur Zeit von SAP R/3 und dessen Einführung in Unternehmen

Die Produktentwicklung von SAP R/2 auf SAP R/3 beruhte auf dem Vorstoß von IBM, eine

neue Mainframeplattform AS /400 herausbringen zu wollen. Dieser geplante Wechsel der

Hardware verlangte eine vollständige Neuprogrammierung des bestehenden Systems. Im glei-

chen Zuge erlangte das herstellerunabhängige Betriebssystem Unix weitere Beliebtheit und

wurde bei der Programmierung des neuen Systems SAP R/3 verwendet. Die Entscheidung für

die Client-Server-Architektur auf Basis der Unix-Technik und der dazugehörigen Hardware

beruhte auf der Verfügbarkeit und Funktionsfähigkeit dieser neuen Technik. In den SAP

Softwaresystemen war die Nutzung von standardisierten Prozessen mit einer integrierten Da-

tenbank im Gesamtsystem von Beginn an bereits vorhanden. Diese Idee etablierte sich in den

Organisationen und wurde durch das Leitbild BPR abgebildet, welches parallel eine hohe Be-

liebtheit erlangte. Das Leitbild wurde durch die SAP-Software in die Unternehmen getragen

und wirkte dort als Träger dieses neuen Modells und schaffte immer mehr Organisationen

nach seinem Abbild (vgl. Siegele 2009, S. 65 und Hohlmann 2007, S. 228). Die SAP-

Software wirkte demnach mit einem cultural lag über die Verbreitung des Leitbildes auf die

Organisationen. Dies entspricht den Thesen des etwas schwächeren Technikdeterminismus,

wonach sich in der Gesellschaft, also auch in Organisationen und Unternehmen, die Formen

der Technik zeitversetzt durchsetzen. Im Jahr 2000, noch vor dem Platzen der Dotcom-Blase,

beschreibt der Wirtschaftinformatiker Professor Scheer die Entwicklung bei der SAP AG:

„Ich glaube, dass zwischen der Hardwareinnovation, der Softwaretechnologieinnova-

tion und der Anwendungsinnovation zeitliche Abstände bestehen. Die Anwendungsin-

novation braucht sicherlich die längste Zeit, um eine neue Technik zu verarbeiten.“

(Scheer in Plattner et al. 2000, S. 111/112)

Mit der Softwaretechnologieinnovation ist das Internet gemeint, welches zeitversetzt die An-

wendungsinnovationen auslöste, im Falle von der SAP AG mySAP.com durch BAPI. Die

SAP AG konnte sich aus technikdeterministischer Sicht der Kraft des Internets nicht entzie-

hen und berücksichtigte diese deshalb in ihren Handlungen, sprich in ihrer Technik. Bei der

quantitativen Untersuchung48 der Gründe für eine betriebswirtschaftliche Software und der

Wahl des SAP-Produkts zählten ausnahmslos technische Gründe und bestätigen hiermit den

48 Hier wird verwiesen auf die Studie von von Arb 1997.

63

Druck der Technik auf die Unternehmen. Auch bei den qualitativen Befragungen49 beschrie-

ben grundsätzlich alle untersuchten Firmen eine Abhängigkeit von Technologie und insbe-

sondere der des Technologieherstellers SAP AG. Bei der Untersuchung von Wolter zur Ein-

führung der SAP-Software in die Unternehmen wurde die Implementierungsstrategie Big-

Bang als die am häufigsten benutzte Methode hervorgehoben, die von einem generellen Ver-

trauen auf Technik ausgeht (vgl. Wolter 2006, S. 242f). Die Ergebnisse der Wolter Befragung

scheinen im Widerspruch zur Untersuchung der Erfolgsfaktoren im Projektmanagement zu

stehen, bei der dieser Strategie eine stark negative Bewertung hinsichtlich der Erfolgswahr-

scheinlichkeit im Unternehmen attestiert wurde, so dass dies ebenfalls nur mit Vertrauen in

die Technik seitens der Unternehmensberater erklären werden kann.

In der bisherigen Analyse zu SAP R/3 und der Einführung der SAP-Software existieren starke

zeitliche Sprünge. Die SAP-Technikentwicklung ist nicht vollständig beschrieben, denn die

Anwendung auf den Technikdeterminismus fasst nur die Teile der SAP AG, die sich in den

Erklärungskontext der Theorie einbinden lassen. Aufgrund der theoretischen Annahmen müs-

sen andere Teile der Entwicklung unberücksichtigt bleiben. Deshalb sind bei der Entwicklung

um SAP R/3 das provisionsbasierte Arbeiten, die Internationalität des Produkts und die Mes-

sen mit der Produktvorankündigung nicht erfasst. Der Flop der Produktreihe New Dimension,

das Verpassen von neuen Trends wie Best-of-Breed und das schlechte Image von SAP zur

Zeit des Internetbooms konnten ebenfalls nicht mit Technik als Ursache erklärt werden. Zu-

dem erfasst der Technikdeterminismus nicht die Handlungen der SAP AG und deren Bedin-

gungen im Hinblick auf das Jahr-2000-Problem, das Platzen der Dotcom-Blase und die Welle

der Konsolidierungen der Unternehmen. Die gegenüber Big-Bang besser bewertete Methode

Step-by-Step beinhaltet, wie bereits ausgeführt, die Rückkopplung von Mitarbeitern, die aller-

dings in dem Erklärungsansatz ausgeklammert sind. Im Gegensatz zur Big Bang-Strategie

lässt sich die Step-by-Step-Methode demzufolge nicht eindeutig durch die Theorie beschrei-

ben. Die Erfolgsfaktoren Managementunterstützung, Kommunikation, Qualifikation, Zufrie-

denheit und Partizipation, genauso wie die Zusammenarbeit mit Key Usern und Promotoren

und den externen Beratern beruhen im Verständnis des Technikdeterminismus allein auf

Technik und ihren Erfordernissen. Dabei wird jedoch nicht darauf eingegangen, wie aus die-

sen Prozessen rückwirkend Einflüsse für die Technik entstehen können, die es nach der ANT

und dem Mikropolis-Modell gibt. Der Technikdeterminismus erklärt vor allem die Wirkung

von Technik auf die SAP AG als Teil der Gesellschaft und demnach auf ihre Technikentwick-

lung. Die Ideen und Ergebnisse aus menschlichen Aktivitäten in der SAP AG und um sie her-

um werden hingegen vernachlässigt, wodurch die Analyse die genannten Lücken aufweist.

49 Hier wird verwiesen auf die Studie von Hohlmann 2007.

64

4.1.3 SAP 2002 bis 2009 und die Globalisierung

Die SAP-Entwicklungen der letzten acht Jahre umfassen zum einen den Weg von dem Busi-

ness Framework mit der Objektorientierung hin zu einer serviceorientierten Architektur

(ESOA), die zusammen mit dem Marktplatz als ein mächtiges Verbindungswerkzeug den

globalisierten Unternehmen mitgegeben wurde. Erneut hatte sich die Technik Internet auf die

Entwicklung der SAP-Produkte stark ausgewirkt. Die Konnektivität und Erreichbarkeit als

Eigenschaften des Internets wurden von den Organisationen und der SAP AG aufgegriffen

und fanden über die Software wiederum Einzug in die Unternehmen. Die mit dem Marktplatz

aufgebauten Netzeffekte verstärkten die Verbreitung der SAP-Software und damit der Tech-

nik in Organisationen, Unternehmen und in der Gesellschaft. Die Globalisierung der SAP AG

und die Nutzung von Partnern waren demnach weitere Ergebnisse der Anpassung der SAP

AG und ihrer Software an die Verbreitung der Technik Internet. Die weltweite Vernetzung

formte die SAP AG. Sie analysierte ihre eigene Organisationsstruktur und verarbeitete sie in

ihrer Software, die dann von Unternehmen auf der ganzen Welt eingesetzt wurde. Die Unter-

nehmen nutzten die erweitere Verbindungs- und Kontrollmöglichkeit der Software und

schlossen erst Lieferanten und dann ihre Kunden an das System an. Die SAP-Software etab-

liert sich mehr und mehr und veränderte die Organisationen nach ihren Werten und ihrer

Struktur. Im Bezug auf das Internet lässt sich aufgrund dessen Sachzwangs und seiner unmit-

telbaren Wirkung auf die Handlungsweise der Akteure von dem starken Technikdeterminis-

mus sprechen. Im Laufe der Entwicklung und Etablierung des Internets verwob sich diese

Technik mit der Gesellschaft derart, dass mittlerweile aufgrund der technischen Trägheit

kaum andere Pfade beschritten werden können. Analog dazu entwickelte sich die Software

der SAP AG, die auf Basis ihrer Netzeffekte Organisationen in Richtung der SAP-Anwender

drängt. „Das Fehlen dieser Geräte [Software], der dazugehörigen Infrastruktur und der Kom-

petenz, diese richtig zu bedienen, bedeutet dann einen Ausschluss von der gesellschaftlichen

[unternehmerischen] Teilhabe.“ (Rammert 2006, S.16)

Parallel zur ESOA verfolgte die SAP AG den anderen Weg hin zu Business byDesign. Dabei

setzte die SAP AG auf die neue Technik der Virtualisierung von Hardware durch Software,

was ein On-Demand-Angebot des Produktes ermöglichen sollte. Dieses Vorgehen entspricht

heute dem Leitbild Cloud Computing, welches langsam in den Medien und Unternehmen be-

kannt wird. Der Standpunkt von Leo Apotheker, ehemaliger Chef der SAP AG, zu der langen

Entwicklungsphase von Business byDesign ist:

„Nehmen Sie den Dreamliner […] der wird ja auch weltweit gebaut. Und das ist ein

bisschen komplizierter, als sich die Leute das vorgestellt haben. Doch früher oder spä-

ter wird der Dreamliner fliegen. Technologie ist nun mal so.“ (Siegele 2009, S.

246/247)

65

Dieses geäußerte Vertrauen in die neue Produktlinie und die Nutzung neuer Technik passt zur

technikdeterministischen Sichtweise. Nach der technikdeterministischen Folgenbestimmung,

scheint ein Versagen dieser Technik nicht möglich, weil das Internet zusammen mit dem neu-

en Leitbild Cloud Computing und die SAP-Software die Gesellschaft bereits nach eigenem

Vorbild geformt und beeinflusst haben.

In Hinblick auf die Erklärungslücken lässt sich die Technik Internet und ihre Auswirkungen

auf die Entwicklung der Gesellschaft scheinbar zuerst sehr gut analysieren. Doch wurde die

Internationalisierung und Globalisierung der SAP AG nicht durch die Technik Internet ausge-

löst, sondern setzte, wie im Unterkapitel 3.1.4 ausgeführt, schon Jahre vorher mit den Partner-

strategien und dem Aufbau von Entwicklungsstudios ein. Diese Strategien können ebenso mit

dem Wunsch nach Ausbau von Marktmacht durch Effizienzsteigerung per Kostenreduktion

und Verbreitung durch Internationalisierung begründet werden. Außerdem lässt sich keine der

beiden Technikentwicklungen als Produkt einer verbesserten Konnektivität nachweisen und

so allein auf den Treiber Internet reduzieren. Es ist ebenfalls fraglich, ob sich das Internet als

Technikinnovation auch zukünftig in der Gesellschaft uneingeschränkt durchsetzen wird oder

ob nicht Entscheidungen von Akteuren im Hinblick auf Datenschutzbestimmungen oder Ju-

gendschutzgedanken reglementierend eingreifen, statt dass die Technik determiniert. Genauso

relevant ist die Überlegung, ob sich die SAP AG als Global Player dauerhaft in den Werten

der Gesellschaft positiv wiederfindet. Über das neue Produkt Business byDesign ist noch kei-

ne abschließende Beurteilung möglich. Es muss sich erst am Markt behaupten und sich die

Annahme, Technik verhelfe diesem zum Erfolg, zeigen und bestätigen.

4.1.4 Ergebnisse der Analyse und Bewertung

Die vorgestellten Aussagen der Chefs der SAP AG und von dem Wirtschaftinformatiker Pro-

fessor Scheer weisen der Technik eine große und vor allem nicht zu unterschätzende Bedeu-

tung für die Gesellschaft zu. Es finden sich konsequent in jeder Epoche in Gesellschaften

Leitbilder (zum Beispiel MRP oder BPR) wieder, die entweder aus dem Entwicklungsweg

von Technik (auch von SAP) entstanden sind oder zumindest durch diesen beeinflusst wur-

den. Inwieweit solche Leitideen von Akteuren geschaffen, getragen oder durch Umwelt- und

Gesellschaftsbedingungen begünstigt wurden, fragt der Technikdeterminismus allerdings

nicht und bleibt dadurch den Beweis für die Ausschließlichkeit des Technikeinflusses schul-

dig. So lassen sich entgegen der Leitbilder MRP und BPR das Leitbild Prozessorientierung

nicht unmittelbar nur auf Technik zurückzuführen. Die technikdeterministische Sichtweise

wirft einen stark einseitigen Blick auf die Technik der SAP AG und deren Wirkung, blendet

andere umfangreiche Gebiete dagegen vollständig aus. Für die Entwicklung von SAP stellt

die Theorie folgenden Erklärungsansatz zur Verfügung: SAP AG, ursprünglich an die Hard-

ware von IBM gebunden, löste sich davon aufgrund neuer Technik. Der angenommene tech-

nology push durch BomP und PICS zog die Entwicklung der SAP-Software MIAS, SAP R

66

und SAP R/2 und die Einführung dieser in Unternehmen nach sich, weil sich jene aufgrund

des Technikdrucks der SAP-Software nicht entziehen konnten. Ebenso oder zumindest ähn-

lich vollzog es sich mit den weiteren SAP-Technikentwicklungen. Die Prozesse der Anpas-

sung bei den Unternehmen erfolgte jeweils unmittelbar, zeitversetzt dem cultural lag entspre-

chend, mit der technischen Trägheit oder sind immer noch nicht abgeschlossen, sondern fol-

gen weiterhin (nach technikdeterministischer Sicht) rein der Technikentwicklung (vgl. Abbil-

dung 31).

Abb. 31: Wirkung von SAP auf Unternehmen (eigene Darstellung)

Eine vollständige Erklärung der Entwicklung von SAP ist nach dieser Theorie jedoch nicht

möglich, da im Mittelpunkt vor allem die Wirkung der Technik auf die Gesellschaft, auf die

SAP AG als Teil dieser, steht. Woher diese Wirkung und ihre Kraft kommen, ist nicht Ge-

genstand der theoretischen Auseinandersetzungen. Deshalb bietet der Technikdeterminismus

für die Beschreibung der SAP-Technikentwicklung und ihren Bedingungen sowie ihres Wir-

kungsursprungs nur einen unzureichenden Erklärungsrahmen. Dies verdeutlichen die Brüche

und Lücken in der Analyse. Sie weisen auf einen komplexeren Zusammenhang der Akteure

und der Gesellschaft mit der Technik hin - auf eine Welt aus Einflussfaktoren, Strategien,

gesellschaftlichen Leitbildern, Marktmacht, Fehlentwicklungen, individuellen Entscheidun-

gen und gesellschaftlichen Einflüssen.

4.2 SAP aus Sicht der Übersetzung als Teil der Akteur-Netzwerk-Theorie

Die ANT berücksichtigt mehr Faktoren für die Beschreibung der Zusammenhänge von

Technikentwicklung und Gesellschaft als der Technikdeterminismus, unter anderem dass

menschliche und nicht-menschliche Akteure handeln. Durch die fünf Phasen der Übersetzung

bildet sich ein seamless web in das alle handelnden Akteure verwoben sind (vgl. Abbildung

32).

67

Abb. 32: Phasen der Übersetzung (eigene Darstellung)

Wendet man die Übersetzung auf die SAP AG an, ergibt sich folgendes Bild: In der Proble-

matisierungsphase erfolgt die Definition der Akteure mit ihren unterschiedlichen Interessen.

Der Hauptakteur SAP versuchte, diese Interessen nach den eigenen Zielen bis zum obligatori-

schen Passagepunkt (OPP) zu leiten. In der zweiten Phase, dem Interessement, beeinflusst

SAP durch verschiedene Handlungen die Identitäten der Akteure, so dass Verbindungen zu

anderen Akteuren aufgelöst werden. Der Hybrid-Akteur SAP muss die Unternehmen, die

Leitbilder und die Partner zum OPP führen, um den Verkauf und die Einführung der SAP-

Software sicherzustellen und voranzutreiben. In der dritten Phase, dem Enrolment, wird der

Prozess des Interessments durch eine Folge multilateraler Verhandlungen begleitet und kann

dadurch den Interessen des Hauptakteurs SAP und den der anderen Akteure zum Erfolg ver-

helfen. Die Mobilisierung beschreibt den getroffenen Konsens der Akteure unter der Leitung

des Hauptakteurs. Alle beteiligten sprechen sich für den Hybrid-Akteur SAP aus. Dieses Er-

gebnis kann in der Dissidenz wieder aufgebrochen werden. Der Prozess ist jederzeit wieder-

holbar und die einzelnen Phasen nicht immer überschneidungsfrei, eher im Gegenteil.

4.2.1 Problematisierung

Nach der ANT sind Akteure nur in Netzwerken handlungskompetent und gewinnen durch sie

ihre Handlungsidentität. Um alle Beteiligten innerhalb des SAP-Netzwerkes zu klassifizieren,

dem Netzwerk zuordnen zu können, wird sich im Vorfeld SAP als Hybrid-Akteur und dessen

Umfeld angeschaut und seine Handlungen mit und um menschliche beziehungsweise nicht-

menschliche Akteure beobachtet. Anschließend teile ich alle Agierenden, wie in der Überset-

zung beschrieben, zur besseren Übersicht und zum besseren Verständnis ihrer Rollen im

SAP-Technikentwicklungsprozess in Gruppen ein, welche mit ihren Interessen und Zielen

nun vorgestellt werden.

Hauptakteur - SAP:

Die SAP AG setzt sich als Hybrid-Akteur aus dem Netzwerk der Gründer, der Mitarbeiter

und der SAP-Standardsoftware zusammen. Hybrid-Akteur deshalb, weil SAP zweigeteilt die

Handlungen des Unternehmens und der Software umfasst. Die SAP-Software entstand durch

die Handlungen der SAP AG und deren Agieren basierte wiederum auf der Software SAP.

68

Aus der anfangs kleinen Firma entwickelte sich ein global integriertes Unternehmen mit einer

starken Verbindung zu vielen unterschiedlichen Partnern weltweit. Die Technikentwicklung

begann mit MIAS und setzte sich über SAP R, SAP R/2, SAP R/3, mySAP.com, New Dimen-

sion bis hin zu der SAP Business Suite 7 fort. Die ERP-Software beinhaltete den neuesten

Stand der Technik und setzte sich insofern aus einem Technologie-Mix der verschiedenen

Zeitabschnitte zusammen. Grundlage war das Echtzeit-System mit der Standardisierung von

Geschäftsprozessen, verknüpft mit selbst oder von Partnern entwickelter Softwaretechnik und

dem Einfluss neuer Softwaretechnologien am Markt. Verschiedene Leitbilder fanden über die

Zeit ihren Weg in die SAP-Standardsoftware, wodurch sich seit jeher eine Überschneidung

von dem Akteur ‚Leitbilder‘ mit dem Hauptakteur SAP ergab. Dabei knüpfte SAP Kontakte

zu verschiedenen globalen Partnern, um die eigene Software durch sie weiterentwickeln, ver-

kaufen und die Implementation in Unternehmen durchführen zu lassen. Das zentrale Interesse

von SAP lag auf dem Verkauf und der Installation der eigenen Software. Der Einsatz von

Erfolgsfaktoren begünstigte dabei die Einführung der SAP-Software.

Akteur - Unternehmen:

Die Kunden der SAP AG wollten ihre betrieblichen Abläufe besser in den Griff bekommen

und suchten nach passender Software. Dabei lagen verschiedene Interessen der Unternehmen

zugrunde beziehungsweise unterschiedliche Ansprüche an die Software. Diese sollte die ver-

altete bisherige DV-Infrastruktur ersetzen, erweiterte Funktionalitäten anbieten, Einsparung

von Entwicklungs- und Wartungskosten bewirken und neue Technologie verfügbar machen.

Oftmals verordnete die Chefetage dem eigenen Betrieb ein Softwaresystem, um organisatori-

schen Wandel nach neuen Leitbildern zu erzwingen und nicht nur um Geschäftsabläufe zu

digitalisieren. Dieses Interesse weist auf die Verknüpfung des Softwaresystems mit dem Ak-

teur ‚Leitbilder‘ hin. Unternehmen achteten auf die SAP-Software, die Konkurrenzprodukte

und die Leitbilder, die zur jeweiligen Zeit im Umlauf waren und installierten das System,

welches für sie als das vielversprechendste galt, eine einfache Implementation der Software

vorwies und die Akzeptanz der Mitarbeiter genoss. Eine besondere Rolle bei den Unterneh-

men nahmen die IT-Produzenten wie IBM ein, welche selbst SAP-Software nutzten und ande-

rerseits der SAP AG IT zur Verfügung stellten. Ihre Interessen betrafen einerseits die eigenen

Innovationen zu verwirklichen und andererseits hinsichtlich SAP-Software ähnliche wie alle

anderen Unternehmen.

Hybrid-Akteur Leitbild:

Findet eine Softwaretechnik oder Managementstrategie in der Presse oder auch unter Akteu-

ren einen großen Anklang, können daraus Leitbilder entstehen. Leitbilder sind Modebegriffe

an denen sich Unternehmen und gleichzeitig die Entwicklung der Software orientieren. Be-

griffe wie MRP, MRP II, BPR, Objektorientierung und Cloud Computing wandelten sich über

die Jahre und zeigten dadurch den technischen Wandel an, den die Produkte und Unterneh-

69

men vollziehen konnten. Die Anzahl der Delegationsprozesse, das heißt die Anzahl der Nut-

zung dieser Leitbilder in Form von Softwaretechnik und Managementstrategien war so groß,

dass wiederum andere Akteure angesprochen wurden. Dadurch kann man ihnen eine gewisse

inne liegende Kraft zusprechen - eine Art Handlungspotential. Das Interesse des Akteurs

‚Leitbild‘ lässt sich mit der in ihm verankerten Eigenschaft, des Fortbestehens durch Verbrei-

tung und weltweite Anwendung seiner selbst, beschreiben. Da die Umsetzung und Verbrei-

tung von Leitbildern nur in Kopplung an andere Akteure funktioniert, sind diese mit der Waf-

fe vergleichbar, die im Zusammenwirken mit einem Akteur Mörder zu einer Mordwaffe wer-

den kann - Ideen und Werte wirken zusammen mit dem Hybrid-Akteur SAP und den Akteu-

ren Unternehmen und Partner als Leitbilder. Sie werden demnach dann zum Hybrid-Akteur,

wenn genügend Interessierte mit ihnen in einem Netzwerk handeln.

Akteur Partner:

Der Hybrid-Akteur SAP begann im Jahr 1981 mit Partnern zusammenzuarbeiten, um die

Software in beiderseitigem Nutzen weiterzuverkaufen. Die Zusammenfassung der Partner zu

einem Akteur erfolgt aufgrund des gemeinsamen Interesses aller Partner, von dem Verkauf

und der Weiterentwicklung der SAP-Software zu profitieren. So siedelten sich viele unter-

schiedliche Partner mit ihren Produkten und Diensten um die SAP-Software an und stellten

entweder Ergänzungsprodukte, Implementationshilfe oder selbst die Softwareeinführung zur

Verfügung. Das Interesse der Partner war weitgehend davon abhängig, wie gut die Software

im Markt Resonanz fand. Kam ein besseres Produkt auf den Markt, konnten sich die Partner

für das neue interessieren und entscheiden.

Da der Hauptakteur SAP während der Entwicklungsprozesse von den Handlungen anderer

Akteure abhing, nur im Zusammenspiel des Netzwerkes technische Vorhaben und Innovatio-

nen verwirklichen konnte, versuchte er die verschiedenen Interessen der Akteure beeinflus-

send zum OPP zu führen. Das Ziel von SAP bestand darin, den Verkauf und die Implementa-

tion seiner Software voranzutreiben, wozu ihm die anderen Akteure verhelfen sollten. Die

Hindernisse der anderen Akteure, SAP-Produkte zu konsumieren, mussten deshalb von SAP

aufgelöst werden, indem es die Ziele der Akteure erfüllte oder wandelte. Der OPP bezeichnet

den Punkt an dem SAP dieses geschafft hatte und die Akteure dem Hauptakteur SAP folgten

(vgl. Abbildung 33).

70

Abb. 33: Obligatorischer Passagepunkt (eigene Darstellung)

4.2.2 Interessement

Das Vorhaben einzelner Akteure SAP zu gründen, lässt sich auf die Zusammenhänge im

Netzwerk, in das unter anderem Plattner, Hopp, Wellenreuther, Tschira und Hector zusammen

mit IBM involviert waren, zurückführen. So stieß das unbundling als Entscheidung in diesem

Netzwerk die Gründung von SAP an. Als Hybrid-Akteur interessierte SAP mittels verschie-

dener Handlungsmuster andere Akteure für den Kauf seiner Software. Um die Entstehungs-

zeit von SAP nutzten die Gründer der SAP AG die Erfahrungen und Geschäftskontakte aus

der Zeit von IBM, um ihre Software weiterzuverkaufen. Hasso Plattner und Dietmar Hopp

interessierten noch zu der Zeit bei IBM als ersten Kunden ICI aus Östringen. Die Entstehung

der Software erfolgte bei dem Kunden vor Ort und so konnte der Einfluss von Konkurrenten

auf das Unternehmen ausgeschlossen und die eigene Kundenbindung gestärkt werden. Das

Handlungsmuster Entwicklung beim Kunden war zentral für die gesamte Entwicklung von

SAP. Dieses Konzept wurde weiterentwickelt zur Pilotprojektstrategie mit der Implementati-

on von neuen Softwareprodukten direkt beim Kunden und der Vorstellung dieser erfolgrei-

chen Implementation in der Presse als Erfolgsgeschichte. Diese Strategie zog Mundpropagan-

da nach sich, welche später auch gezielt eingesetzt wurde und die Erfolgsgeschichte so noch

weiter verbreitete. Jedes dieser Muster führte zur Stärkung des Netzwerkes und zu einem

Imagegewinn, der die Unternehmen weg vom Konkurrenten hin zum eigenen Unternehmen

zog. Für das Anwerben von qualifizierten Mitarbeitern setzte SAP neben dem provisionsba-

sierten Arbeiten auf Messen wie auf die CeBit oder die eigene Anwendermesse Sapphire.

Dort begeisterte man neben neuen Mitarbeitern gleichzeitig neue Unternehmen für die SAP-

71

Software. Eine sechste Handlung Kunden zu akquirieren bestand aus der Marketingstrategie

Produktvorankündigung, die zum ersten Mal bei der Einführung des Systems SAP R/3 in den

USA genutzt wurde. Der Blick der Unternehmen wurde somit frühzeitig auf SAP gelenkt und

damit weg von den Mitbewerbern. SAP selbst veränderte seine Aufbaustruktur so, dass die

Mitarbeiter eine hohe Softwarequalität garantierten und wandelte sich zu einem global inte-

grierten Unternehmen. Die Gründung eines jeden Entwicklungsstandortes beschreibt die

Handlung, vor der Konkurrenz dort die besten Ressourcen für die Software zu generieren.

SAP setzte dabei auf flache Hierarchien, einen offenen Informationsaustausch, ständige

Lernmöglichkeiten und die Lernbereitschaft aller Mitarbeiter. Die Qualifikation der Mitarbei-

ter wurde durch eine hohe Quote von Akademikern hoch gehalten; Im Jahr 1996 lag sie bei

85% (vgl. Meissner 1997, S. 179). Für das Produkt Business byDesign versuchte SAP eine

neue Vertriebsstruktur aufzubauen und die Einführung der SAP Software durch Laien zu er-

möglichen. Die SAP-Software besaß gleichfalls wie das Unternehmens SAP AG einen eige-

nen Handlungsrahmen für die Anwerbung von neuen Kunden und beinhaltete Handlungen,

die das Interesse von anderen Akteuren anregte sowie zum Kauf anreizte. Somit war der tech-

nische Standard Grund für die Nachfrage weiterer Unternehmen: Bei MIAS, SAP R und SAP

R/2 das integrierte Echtzeit-Standardsystem, bei dem Produkt SAP R/3 die Client-Server-

Architektur, bei mySAP.com die BAPI und das Business Framework, bei SAP Business Suite

7 die ESOA mit dem Best-of-Breed und dem Marktplatz. Die Vorteile dieser Technikentwick-

lungen verschafften der Software eine gute Bewertung auf dem Markt, damit eine starke Posi-

tion gegenüber den Kunden und ließen vergleichbare Produkte anderer Anbieter im schlechte-

ren Licht erscheinen. Dies lockte erneut Partner und Unternehmen an, die von sich aus eine

Weiterentwicklung der SAP-Software vorantrieben und so das Interessment der Software am

Laufen hielten.

4.2.3 Enrolment

Im Folgenden geht es um den Kampf und die verschiedenen Tricks, die dem Interessments

zum Erfolg verhelfen sollten. Die Messen stellten von Anfang an eine Arena für die Präsenta-

tion der SAP-Software dar und interessierten schon seit der Gründung Kunden für SAP. Eine

weitere Bühne der Kämpfe war die Presse, die über Erfolg oder Misserfolg des Hybrid-

Akteurs SAP und dessen Einführung von Produkten informierte. Dabei wurde die Diskussion

über Vor- und Nachteile einerseits durch SAP selbst gesteuert, in dem sie success storys ver-

öffentlichen und andererseits durch unbewiesene Behauptungen anderer und das Verbreiten

von Gerüchten auch auf unsachlichem Niveau geführt (vgl. von Arb 1997, S. 46). Das ein

direkter Zusammenhang der Firma SAP AG und der Einführung von der SAP-Software in

Unternehmen bestand, beweist die mittelfristige Beeinflussung des Aktienkurses der SAP AG

durch Negativschlagzeilen. Partner der SAP AG verlangten nach Produkten, welche sich

leicht in Unternehmen installieren ließen, damit sie nicht zu einem anderen Produkt wechseln

72

mussten. Die Untersuchungen der Gründe für die Einführung der Software SAP R/3 zeigen,

dass die Entscheidungen deshalb nicht nur auf Basis von Wirtschaftlichkeitsrechnungen oder

den Wechsel zwischen den SAP-Produktgenerationen geschah, sondern die SAP-Software

von oben auf oktroyiert wurde. Hier spielte der Schauplatz der Beratungspartner insofern eine

große Rolle, als das sie einen enormen Einfluss auf die Unternehmensentscheidungen hatten.

Die guten Partnerschaften zu den Unternehmensberatungsgesellschaften brachten dem Haupt-

akteur SAP direkte Geschäftskontakte auf Führungsebenen. Der Verkauf musste nicht über

die EDV-Abteilungen erfolgen. Die Partnerstrategie schaffte einen Ort der Gewinnung mäch-

tiger Partner, um die sich auch die Konkurrenten der SAP bemühten. Die Verknüpfung zu den

Technologiepartnern wie Microsoft steigerte die Größe der Basis durch die verbesserte Zu-

sammenarbeit der Produkte von SAP mit den Produkten von Microsoft. Neben dem Pflegen

guter Kontakte zu Beratern und Partnern musste das Konfliktpotential bei der Einführung der

SAP-Produkte und der damit verbundenen Reorganisation der Unternehmen möglichst gering

gehalten werden. In diesem Zusammenhang spielten die Erfolgsfaktoren der SAP-Einführung

eine große Rolle, welche die Akzeptanz der Software verbessern und somit das Konfliktpo-

tential verringern konnten. Der Einsatz von Promotoren steigerte beispielsweise den Einsatz

von allen anderen Erfolgsfaktoren und half so bei der schnellen und vor allem angepassten

Umsetzung der SAP-Standardsoftware in den Unternehmen.

4.2.4 Mobilisierung

Seit dem 07.02.2010 sprechen für die Mitarbeiter und die Entwicklungsbüros weltweit

gleichberechtigt der US-Chef Bill McDermott und der Entwicklungschef Jim Hagemann

Snabe (vgl. Handelsblatt 2010). Diese beiden repräsentieren zwar die SAP AG offiziell, aus-

schlaggebend spricht allerdings vor allem die SAP-Software in einem selbstverstärkenden

Effekt, dem Netzweffekt, für sich und somit für den Hauptakteur SAP. Bei erfolgreicher Ein-

führung der Software konnten betriebswirtschaftliche Abläufe standardisiert werden und die

Manager in Echtzeit einen Überblick über den Status des gesamten Unternehmens erhalten. Je

breiter die installierte Basis der Software war, desto besser funktionierte die Konnektivität

zwischen den Unternehmen und umso mehr wuchs der Überblick eines Unternehmens über

seine Grenzen hinaus, was bessere Preise, kleine Läger und schnelleren Informationsaus-

tausch mit den anderen Unternehmen mit sich bringen konnte. Der Hybrid-Akteur SAP steht

hinter und äußert sich somit für die eigene SAP-Software. Der Akteur ‚Unternehmen‘ wird

durch das Interessement und das Enrolment verstärkt für die SAP-Software interessiert und in

den Netzwerken gehalten oder in diese weiter verstrickt. Falls die SAP-Software erfolgreich

installiert wurde, sprachen dann in dem Unternehmen die Geschäftsführer, externen Berater,

Promotoren und Key User nicht mehr nur für die Mitarbeiter und ihre eigenen Geschäftspro-

zesse und Produkte, sondern auch für den Hauptakteur SAP. Nutzt ein Unternehmen den

Partnerstatus von SAP, wählte es dadurch seinen Sprecher. Die Partnerstrategie zeigt, dass

73

SAP damit sehr erfolgreich war. Die Prinzipien der Leitbilder MRP I, II und BPR waren wie

für die Software geschaffen oder bereits in ihr vertreten. Heute spricht das Leitbild Cloud

Computing für das neuen Produkt Business byDesign. Für den Hybrid-Akteur SAP sprach

demnach ein ganzes Netzwerk von Akteuren.

4.2.5 Dissidenz

In der letzten Phase, der Dissidenz, erfolgt das Abfallen der Allianzen und eine Kontroverse

um alle Manifestationen, welche die Repräsentativität des Sprechers in Frage stellen. Das

Netzwerk um SAP besteht deshalb nur solange wie die Hindernisse der Akteure aufgehoben

werden und nichts ihren Zielen im Weg steht beziehungsweise erfolgreich Kompromisse ge-

funden werden. Diese Gefahr bestand fortwährend, dass Konkurrenten von SAP bessere

Software anbieten, neue Leitbilder aufkommen, denen SAP nicht entspricht oder die Einfüh-

rungen der Software zu häufig scheitern. Im Verlauf der SAP Unternehmens- und Software-

Entwicklung fanden sich verschiedene Punkte, bei denen eine Art Dissidenz stattgefunden

hat. SAP als Hauptakteur war im Jahr 2000 von einem schlechten Image und der Abwande-

rung von Mitarbeitern betroffen. Neue fanden SAP nicht mehr attraktiv und wählten andere

Firmen als Arbeitgeber. Ein Grund hierfür war die fehlende Mitarbeiterbindung durch Stock

Options bei der SAP AG. Eine weitere Ursache für das schlechte Image lag in dem Wechsel

des Logos von einem konservativen hin zu einem kinderzimmerfarbenen mySAP.com. Dies

suggerierte zukünftigen Arbeitnehmern, dass SAP den Trend Internet nicht ernst nähme und

neue Firmen zukunftsweisender, attraktiver seien. Die Dissidenz konnte SAP nach dem Plat-

zen der Dotcom-Blase wieder abbremsen und durch das Auftreten als global integriertes Un-

ternehmen bis heute abfedern. Die zweite innere Dissidenz des Hauptakteurs SAP betraf die

eigene Software um 1998, welche neue Kunden nicht mehr interessierte. Dem Trend um die

Produkte Best-of-Breed entsprach SAP aufgrund zu später Anpassung und technischen Fehl-

entwicklungen nicht rechtzeitig. Außerdem hatte die Produktentwicklung um New Dimension

die Plattform SAP R/3 in verschiedene Teile gesplittet und die integrierte Standardsoftware zu

einer dezentralen Standardsoftware gewandelt. Dieser Trend hin zu einem Mehrproduktunter-

nehmen verursachte einen hohen Schaden im Unternehmen, da die integrierte Plattform das

Markenzeichen von SAP war und ohne sie der feste Bestandteil, ein Vorteil in den Augen der

Kunden, verloren ging. Der Versuch, mit der Firma Pandesic in den B2C Markt vorzustoßen,

scheiterte ebenso am mangelnden Interesse von Kunden. Diese Probleme erkannte SAP da-

mals rechtzeitig, stoppte die Produkte New Dimension und behob die Fehlentwicklung durch

die neue Technik ESOA mit dem SAP Marktplatz auf Basis des Business Frameworks und

dem Netweaver. So konnte sich SAP verspätet auf dem Feld der Produkte Best-of-Breed doch

noch behaupten. Unabhängig davon wurde parallel das neue Produkt Business byDesign

mehrfach angekündigt, weckte aber bisher scheinbar nur geringfügig das Interesse der Unter-

nehmen und fand noch nicht auf den Markt. Die Dissidenz ist im Hinblick auf das Produkt

74

Business byDesign noch ungewiss. Die Einführung der SAP-Software in Unternehmen, ein

wichtiger Bestandteil des Enrolement für neue Unternehmen, verursachte trotz der Erfolgsfak-

toren oft ein größeres Problem für die SAP-anwendenden Unternehmen und barg demzufolge

ebenfalls stets die Gefahr einer Dissidenz. Die Integration dauerte in allen Bereichen einer

Firma länger, so dass diese fortwährend beschäftigt war und nicht ausreichend auf den Markt

reagieren konnte, was der Konkurrenz die Möglichkeit eines Vorteils verschaffte (vgl.

Hohlmann 2007, S. 228). Dies führte manchmal zur Abwendung von der SAP AG und zur

Abschaffung der SAP-Software. Dadurch wurde die Akquise von Unternehmen für die SAP

AG erschwert. Entlastend für diesen Umstand war, dass die Einführung von ähnlich komple-

xer Software anderer Anbieter dieselben Probleme hervorrufen konnte.


Das Modell der Übersetzung kann das dynamische Verhalten der Technikentwicklung der

SAP differenzierter darstellen als der Technikdeterminismus. Alle exemplarisch aufgestellten

Faktoren fanden in der ANT mittels der fünf Phasen der Übersetzung einen Beschreibungs-

kontext. Durch die Analyse wurde gezeigt, dass nicht nur die Technik für die Entwicklung

und die Verbreitung in der Gesellschaft verantwortlich ist, sondern viele verschiedene Hand-

lungen einzelner Akteure zusammen in einem Netzwerk agierend. Eine Abstraktion der be-

schriebenen Geschehnisse stelle ich in einem Akteur-Netzwerk von SAP dar (vgl. Abbildung

34). Auf der rechten Seite befindet sich das seamless web mit den vorhandenen, über die Jah-

re gewachsenen Akteuren, die bereits für den Hybrid-Akteur SAP sprechen. Anfangs stand

dort als SAP-anwendendes Unternehmen nur die ICI in Östringen, heute zählen sich über

90.000 Unternehmen hinzu. Der Akteur ‚Partner‘ fügte sich mit der ersten Nutzung der Part-

nerstrategie im Jahr 1982 in das offene Netz ein. Die Leitbilder stellen für den jeweiligen

Zeitraum die aktuelle Managementtheorie dar, welche SAP in den jeweiligen Zeiträumen

nutzte. In den Phasen der Übersetzung, in der Mitte der Abbildung, versucht SAP die potenti-

ellen Akteure auf der linken Seite in sein seamless web hineinzuziehen beziehungsweise ih-

nen die Rolle eines SAP-anwendenden Unternehmens in dem Netzwerk aus IT-Herstellern

und IT-Nutzern zuzuschreiben. Wenn keine Dissidenz die Phasen stört, wäre der Übergang

theoretisch nach der Mobilisierung geglückt.

Abb. 34: Akteur-Netzwerk von SAP (eigene Darstellung)

75

So entsteht ein dynamisches Verhalten des Netzwerkes, welches sich zu jederzeit vergrößern

(Problematisierung, Interessment, Enrolment und Mobilisierung), verkleinern (Dissidenz)

oder in seinen Interessen und Rollen verändern kann.

Positiv an der ANT bewerte ich, dass alle erfolgswirksamen Faktoren und Handlungen durch

das Netzwerk mit der Theorie beschrieben werden konnten, was für einen sehr hohen Erklä-

rungsgehalt spricht. Die Phaseneinteilung bot dabei eine übersichtliche und kompakte Dar-

stellungsform, obwohl eine feststehende Zuordnung zu den einzelnen Phasen und Akteuren

schwierig war, da die ANT diesbezüglich keine Reglementierung vorgibt. Sie geht lediglich

davon aus, dass alle wesentlichen Akteure und Faktoren dann erfasst sind, wenn das Netz-

werk vollständig beschrieben ist. Wann dieser Fall eintritt bleibt offen oder zumindest ohne

methodische Festlegung. Des Weiteren ließ sich die Ursachen- und Wirkungskette des Hyb-

rid-Akteurs SAP durch das Bestimmen aller beteiligten Akteure und deren Einordnung in

bestimmte Gruppen sehr gut nachzeichnen. Als Nachteilig in diesem Zusammenhang hat sich

die Formulierung der Akteure bei der ANT herausgestellt, die menschliche und nicht-

menschliche Akteure im Netzwerk auf die gleiche onthologische Stufe hebt. Ich habe als Ex-

periment Leitbilder als Hybrid-Akteur definiert, der das Wirken von nicht-menschlichen Ak-

teuren darstellen sollte. Allerdings wäre es ebenso möglich gewesen, den Einfluss der Leitbil-

der in der Phase des Interessment zu verorten, wo der Hauptakteur SAP durch die Entspre-

chung mit den Leitbildern versucht den Einfluss von Konkurrenten auf die Unternehmen ab-

zuschwächen. Diese freie Interpretationsmöglichkeit der ANT mit der Übersetzung ist so ei-

nerseits von Vorteil, da alle Einflüsse ohne Einschränkungen aufgedeckt werden können, an-

dererseits wird kein Rahmen und Werkzeug vorgegeben, an denen eine Orientierung möglich

wäre. Die Betrachtung der Entwicklung von SAP umfasst in dieser Untersuchung 38 Jahre.

Analysiert man den Gesamtzeitraum ohne Einteilung in zeitliche Abschnitte, besteht die Ge-

fahr, den Einfluss von Faktoren und Handlungen auf die Entwicklung von SAP aufgrund der

teilweise großen zeitlichen Abstände von kausal zusammenhängenden Entwicklungsereignis-

sen zu übersehen. Aus diesem Grund sollten sich Untersuchungen mit der ANT auf über-

schaubare Zeiträume beziehen, denn je größer dieser ist, desto wahrscheinlicher sind selbst-

verschuldete Lücken oder unzureichende Argumente im Erklärungskontext. Aber Brüche

können im engeren Beobachtungskontext auf Beziehungen zwischen Akteuren verweisen und

damit Netzwerkverbindungen herausstellen. Bei den New Dimension von SAP beispielsweise

zeigen sich gerade durch die Ablehnung und nicht Annahme die an der Entwicklung von

Technik zu Innovationen beteiligten Akteure, wie Unternehmen und Partner. Ein weiterer

kritischer Punkt an der vorgestellten Theorie ist, dass das Handlungskonzept allein auf die

Erfassung sichtbaren und zweckrationalen Handelns zugeschnitten ist (vgl. Degele 2002 S.

140). Emotionales Handeln und Unterlassungen sowie nicht-intendierte Handlungseffekte

werden nicht betrachtet.

76

4.3 SAP im Mikropolis-Modell

Die Untersuchung der SAP-Technikentwicklung über die Jahre fasst das Mikropolis-Modell

durch die drei strukturgebenden Ebenen. Im soziotechnischen Kontext wird die Genese der

Softwareentwicklung über die De- und Rekontextualisierung analysiert. Der Mikrokontext

erweitert den Blick auf die beteiligten Akteure und die Entstehung von Innovationen aufgrund

verschiedener Strategien. Der Makrokontext bezieht gesellschaftliche Phänomene in die Ent-

wicklung der SAP-Produkte mit ein und stellt deren Einfluss auf die Entwicklung heraus. Ab-

schließend wird in dem Punkt ‚Pfade der erfolgreichen und misslungenen SAP-Innovationen

im Zeitverlauf‘ der SAP-TEP entwickelt, der die Technikentwicklung kompakt in einem his-

torischen Kontext darstellt, und mit dem TNP Büro einen umfassenden Beschreibungsrahmen

für die Technikentwicklung und Techniknutzung der SAP AG bildet.

4.3.1 Die Technikentwicklung aus soziotechnischer Perspektive

Im Folgenden wird die SAP-Softwareentwicklung auf die De- und Rekontextualisierung hin

analysiert. Der Blick richtet sich auf das Beobachten von zu Routine gewordenen Handelns

und dessen Formalisierung. Wenn möglich wird aufgezeigt, wie die autooperationale Form

der Daten hergestellt und anhand von Algorithmen in Programme festgeschrieben worden ist.

Des Weiteren wird der Weg nachvollzogen, den die SAP-Software bei der Rückführung in die

Organisation, in das menschliche Handeln nahm und wie sie interpretiert wurde. Die dabei

entstehenden Wechselwirkungen und Nebenfolgen zwischen der SAP-Software und den an-

wendenden Akteuren stellen hier bereits die Überleitung zum Mikrokontext dar.

Bis zur Gründungszeit der SAP AG benutzten die Mitarbeiter der ICI die Pendelkarte für die

Auftragsabwicklung im gesamten Werk (vgl. Siegele 2009, S. 51f und 37f). Auf dieser wur-

den alle Handlungen, die im Laufe des Tages für die Materialwirtschaft nötig waren, doku-

mentiert. Fehlten für die Abarbeitung eines Auftrages bestimmte Materialien, so wurde dies

auf der Pendelkarte vermerkt. Diese ging dann weiter in die Einkaufabteilung, welche die

Daten des Lieferanten ergänzte. Daraufhin wanderte die Karte in die Buchhaltung, die Kos-

tenstelle, Bestellnummer und Rechnungsnummer darauf vermerkte. Bei Eingang der Liefe-

rung trat die Karte “ihre Reise“ in entgegengesetzte Richtung an. Dieser Vorgang musste für

jede Bestellung auf einer neuen Pendelkarte dokumentiert werden und nahm dann den glei-

chen Weg durch die Abteilungen. Hinzu kam, dass bei jedem Durchlauf Durchschläge für die

Eingabe im Großrechner erstellt wurden. Jede Pendelkarte wurde von Datatypisten abgetippt

und so die Angaben von dieser in Lochkarten überführt, welche meist über Nacht im Batch-

verfahren von dem Großrechner eingelesen wurden. Das Abtippen der Karten wie auch der

gesamte Prozess der handschriftlichen Ergänzungen auf der Pendelkarte war anfällig für Feh-

ler, zum Beispiel durch unleserliche Handschrift oder Tippfehler. Diese fielen erst nach der

Bearbeitung und Überprüfung im Großrechner auf, so dass die eingegebenen Daten sowie die

Pendelkarte korrigiert werden mussten. Die Auf-

77

tragsabwicklung dauerte in der Regel mehrere Tage und umfasste eine Vielzahl von Handlun-

gen, die wiederholt und routiniert abliefen. Hopp und Plattner arbeiteten im Auftrag von IBM

um 1971 in dem ICI Werk in Östringen an einer integrierten Echtzeitsoftware, dem RoS.

Hierfür beobachteten sie die Handlungen bei der Eingabe der Daten in den Großrechner durch

die Batchverarbeitung und kristallisierten dabei die routinierten und sich wiederholenden

Operationen heraus. Das Ergebnis dieser Formalisierung war die autooperationale Form der

verwendeten Echtzeitsoftware auf neu eingeführten Terminals und dem neuen Großrechner

IBM /370. Sie schufen dadurch die Möglichkeit die Daten per Echtzeit in den Großrechner

einzugeben. Parallel analysierten sie den immer gleichen Ablauf und Weg der Pendelkarte bei

jeder Bestellung durch verschiedene Abteilungen. Die autooperationalisierte Form der Pen-

delkarte stellte einen Geschäftsprozess dar, welcher dem zu bearbeitenden Weg der digitali-

sierten Gestalt der Karte entsprach. Die Funktionen der integrierten Echtzeitsoftware umfass-

ten anfangs die Eingabe von Aufträgen, die Überprüfung auf die Verfügbarkeit der dafür not-

wendigen Teile im Lager und die automatische Erstellung von Rechnungen. Auf der Basis

einer gemeinsamen Datenbank konnte jede Abteilung auf die gleichen Geschäftsprozesse zu-

rückgreifen. Die Eingabe der Daten geschah nur einmal für den jeweiligen Geschäftsprozess.

Dadurch wurde eine erste Verbindung der Abteilungen Materialwirtschaft, Auftragsmanage-

ment und Einkauf hergestellt. Die Voraussetzungen für MIAS waren gegeben, weitere Abtei-

lungen konnten in den Vorgang der Geschäftsprozesse mit eingebunden werden. Zuerst wur-

den die Abläufe der Buchhaltung in das System integriert. Da sich die Software an Standard-

prozessen ausrichtete, die in anderen Unternehmen ähnlich abgewickelt wurden, war sie auch

für weitere Firmen vor allem für die Bereiche Einkauf, Materialwirtschaft und Buchhaltung

interessant. Die abteilungsübergreifende Nutzung der Geschäftsprozesse bezeichnete Hasso

Plattner als eine Revolution für die Unternehmen, da ein Teil der Buchhaltung in den Einkauf

verlegt und der Einkauf mit dem Rechnungswesen durch ordnungsmäßige Ablage und Vor-

schriften zusammengebracht wurde (vgl. Plattner et al. 2000, S. 249). „[Die Abteilungen] […]

können nunmehr logisch zusammengefaßt werden, wodurch Personaleinsparungen möglich

werden.“ (Meissner 1997, S. 45) Die Bezeichnung der einzelnen Softwaremodule passte sich

bei der Rekontextualisierung zur leichteren Interpretation der Abläufe den vorher beobachte-

ten Organisationsstrukturen an. So stand die Komponente RF für Realtime Financials, welche

die Handlungen in der Buchhaltung wiederspiegeln sollte. Die Rekontextualisierung der SAP-

Software in das Handeln der Mitarbeiter im Werk in Östringen lässt sich dahingehend inter-

pretieren, dass die Software von den Unternehmensleitungen durch eine zukünftig zunehmen-

de Nutzung dieser positiv bestätigt wurde. Über die Rückführung der formalisierten Operatio-

nen in den Anwendungskontext der Mitarbeiter ist wenig veröffentlicht. Da sich das Interesse

und die Nutzung der Software in den nächsten Monaten und Jahren verstärkten, scheinen auf

Seiten der Anwender wenig unlösbare Anwendungsprobleme aufgetreten oder die Software

nicht vollständig abgelehnt worden zu sein. Allerdings ist anzunehmen, dass bestimmte Ar-

beitsgruppen die neuen Arbeitsprozesse kritisch bewerteten, da die Echtzeiteingabe der Daten

78

in den Großrechner einen Großteil der Arbeit der Datatypisten überflüssig machte. Der Ein-

satz dieser Software ließ die Anzahl der Arbeitsplätze schwinden und die übrigen verlangten

nach einer höheren Qualifikation. „Während hochqualifizierte Stellen hinzukommen, kann

das Wachstum weniger qualifizierter Arbeitsplätze geringer gehalten werden.“ (Meissner

1997, S.46) In der ICI erfolgte keine weitere Restrukturierung oder Änderung des Ablaufes

nach Geschäftsprozessen mehr, weil die Software die gewohnten Prozesse und das prozessge-

steuerte Vorgehen abbildete. Andere Unternehmen jedoch in denen die Software später ge-

nutzt wurde, konnten nicht länger ihre hierarchischen Strukturen beibehalten, sondern muss-

ten sich nach Prozessen und Funktionen neu ordnen. Die Weiterentwicklung des MIAS und

die darauf folgenden Komponenten, die später zu dem SAP R/2 wurden, folgten dem Muster

der Analyse der Arbeitskontexte, deren Formalisierung, deren Dekontextualisierung und der

Rückführung der SAP-Software in die Unternehmen. Dabei wurde kontinuierlich nach mögli-

chen Schließungen von Formalisierungslücken in Organisationen Ausschau gehalten. Ein

Beispiel hierfür ist die Beobachtung, dass die Planung zukünftiger Produktionsbedarfe bei

fortlaufendem Verbrauch der Rohstoffe ständig dem gleichen Arbeitsablauf folgte. Diese rou-

tinierten Tätigkeiten übersetzte SAP in eine Produktionsplanungskomponente und integrierte

diese in die Geschäftsprozesslogik der SAP-Software.

Die Analyse der Entwicklung zu dem System SAP R/3 anhand der De- und

Rekontextualisierung stellt sich entgegen der bisherigen Ausführungen schwieriger dar. Der

Grund liegt darin, dass sich der Wunsch nach einer Weiterentwicklung der Software SAP R/2

aus einer Hardwareproblematik und einem verstärkten Organisationsaufwand innerhalb der

Unternehmen ergab und weniger aus dem Ziel routinierte Handlungen der Akteure zu forma-

lisieren und durch Software zu ersetzen. Um das Jahr 1987 setzten immer mehr Organisatio-

nen in Deutschland Großrechner und hauptsächlich SAP R/2 ein. In diesen Jahren wurden

stetig mehr Abteilungen integriert und der Großrechner einer Organisation musste immer

mehr Anfragen der ebenfalls steigenden Anzahl Terminals beantworten. Die Kapazitätsgren-

zen der Großrechner wurden ausgereizt. Der Bedarf nach einer Lösung hin zu mehr Rechner-

kapazität für einen Rechner oder eine Neuverteilung der Kapazitäten auf mehrere wuchs. In-

terpretiert man in diesem Zusammenhang allerdings die Rechnerarchitektur und die darin ab-

laufenden Prozesse als Routinehandlungen in Organisationen und die Verbindung der Termi-

nals beziehungsweise der Arbeitsplatzrechner mit dem Großrechner als Verbindung der Ab-

teilungen durch Geschäftsprozesse (Pendelkarten), lassen sich die Beobachtungen der Abläufe

und die Identifikation von Operationen innerhalb der technischen Vorgänge aus der sozio-

technischen Perspektive trotzdem erklären: Die Arbeitsplatzrechner und Terminals leiteten die

eingegebenen Daten und Informationen jederzeit an den Großrechner weiter und glichen sie

dort ab. Diese Operationen des Datenverkehrs wurden im Sinne der Autooperationen und der

Algorithmen durch neue Datenflüsse über mehre Rechner ersetzt. Sowie die Batchverarbei-

tung durch die Terminals abgelöst wurde, ersetzten nun Arbeitsplatzrechner, die sich am

Markt neu etablierten Server mit dem Betriebssystem Unix, die Terminals. Die Funktionen

79

des Großrechners erfüllte nun ein Datenbankserver, von dem allerdings Aufgabenfelder auf

viele kleine verschiedene Anwendungsserver und Präsentationsserver ausgelagert wurden, die

bestimmte Anfragen und Aufgaben der Arbeitsplatzrechner erledigten. Innerhalb dieser drei-

schichtigen Client-Server-Architektur übernahmen auf Basis der Datenbank die Anwendungs-

server die Verarbeitung der Programmlogik und der Geschäftsprozesse und die Präsentations-

server boten den Mitarbeitern eine grafische Oberfläche für ihre Arbeitsplatzrechner an (vgl.

Plattner et al. 2000, S. 99 und 103). Diese neue Architektur ersetzte die Mainframe-

Architektur und wurde in den täglichen Arbeitsablauf überführt, übertragen gesagt:

rekontextualisiert. Die Kapazitätsgrenze des alten Großrechners beschränkte nicht länger die

Nutzung des SAP-Systems. Die Client-Server-Architektur bot sogar freie Kapazitäten für die

Integration weiterer Abteilungen beziehungsweise neue Chancen der weiteren

Autooperationalisierung von menschlichen Handlungen, die Schließung weiterer vorläufiger

Formalisierungslücken. Entgegen der sich potentiell möglichen Rationalisierungen ergaben

die Ergebnisse der Studie Hohlmann50, dass durch die Änderung der Aufbauorganisation der

IT-anwendenden Organisationen sogar Unternehmensberater übernommen und in den Abtei-

lungen für die Wartung der SAP-Software erstmals Personal angeworben wurde. Die Akzep-

tanz der Mitarbeiter stand vorerst weniger infrage, da sich an den betriebswirtschaftlichen

Abläufen anfangs kaum etwas änderte, sondern lediglich die Terminals durch Arbeitsplatz-

rechner ersetzt worden sind. Diese hatten den Vorteil zum einen attraktivere Farbdisplays zu

haben und zum anderen konnten seitdem mehr Mitarbeiter gleichzeitig im SAP-System agie-

ren, was für alle die Zusammenarbeit und Koordination vereinfachte.

Die SAP AG mit seinem System SAP R/3 sah sich Ende der achtziger Jahre mit der neuen

Technologie Internet konfrontiert, 1989 mit dem WWW und 1993 mit dem Mosaic-Browser.

Die Nutzung des Firmennetzes war nicht länger auf die SAP-Software beschränkt. Die Mitar-

beiter banden mehr und mehr die Informationen aus dem Internet in den Arbeitskontext mit

ein und orientierten sich an diesen. Das Unternehmensinteresse, die Bedarfe der Kunden zu

erfassen und die Zulieferer enger an die Organisation zu binden, verstärkte den Gebrauch des

Internets zusätzlich. Der Datenumfang wuchs stetig und neue Arbeitsschritte gingen in die

Struktur des Unternehmens über. Die Anforderung an die SAP AG bestand darin, die Soft-

ware dahingehend zu modifizieren, diese neuen Informationsströme mit abzudecken, die neu-

en Routinen zu formalisieren und in ihr SAP R/3 zu integrieren. Folgende regelmäßige Hand-

lungen waren in diesem Prozess zu beobachten: Das Internet veränderte den Arbeitskontext

insofern, als dass es den Unternehmen erlaubte über Unternehmensgrenzen hinweg zu kom-

munizieren und jedem Akteur auf das Netz zuzugreifen. Die dadurch entstandenen Möglich-

keiten der Informationsbeschaffung wurden zwar in die Arbeitsabläufe beim Wareneinkauf

mit einbezogen, änderten allerdings noch nichts an der Struktur der gängigen Routinehand-

lungen dieser Prozesse. Die Mitarbeiter der Einkaufabteilung handelten meist immer noch

50 In diese Betrachtung flossen die 12 quantitativ analysierten Unternehmen aus der Studie von Hohlmann 2007 ein.

80

persönlich die Preise mit den Zulieferern aus und gaben diese später in die Unternehmens-

software, häufig das System SAP R/3, ein. Die Anpassung dieser Preise erfolgte erst nach

einer erneuten Nachfrage oder durch eine entsprechende Angabe des Zulieferers per Post oder

per Telefon über seine Preisänderungen. Agierte ein Unternehmen international, so orderten

die Einkaufsabteilungen in den entsprechenden Regionen ihre Rohstoffe, glichen allerdings

die Preise der verschiedenen Zulieferer weltweit wegen der regionalen Ferne und der unter-

schiedlichen regionalen Zugehörigkeit meist nicht ab. Die Daten über die Dauer der Lieferung

der georderten Ware wurden auf Basis der Aussagen der Zulieferer und anhand von Erfah-

rungswissen vorheriger Lieferdauer geschätzt. Diese ungenauen Informationen verursachten

in den Unternehmen, um eventuelle Lieferengpässe abzufangen, teure Zwischenläger. Der

Verkauf der Produkte war beschränkt auf die traditionellen Absatzwege Einzel- beziehungs-

weise Großhandel. Den direkten Kontakt zu den Käufern der eigenen Produkte und deren

Meinungen oder Verbesserungsvorschläge fragten die Organisationen über entsprechende

Marktforschungsinstitute ab. Denen entsprechend wurden, wenn nötig, Werbekampangen

umgestaltet oder eine Produktverbesserung eingeleitet. Neben der Umgestaltung des unmit-

telbaren Arbeitskontextes ermöglichte das Internet ebenfalls, dass die Mitarbeiter von zu Hau-

se aus oder von entfernten Orten jederzeit auf die Daten in der Firma zugreifen und so fast

rund um die Uhr arbeite konnten. Diese Operationen griff die SAP AG im Sinne der

Dekontextualisierung auf und übertrug sie autooperationalisierend als Algorithmen in ihr Sys-

tem SAP R/3. Die Art der Netzverbindung zwischen dem Internet und den Akteuren übersetz-

ten die Programmierer in die Software durch Schnittstellen, so dass jetzt ebenfalls freie Ver-

bindungsmöglichkeiten der SAP-Software mit anderen Programmen geschaffen wurden. Die

Akteure mussten nicht länger den Umweg über entsprechende Programme oder den Browser

gehen, um Informationen in das SAP-System aufzunehmen, sondern konnten direkt die Daten

und Funktionalitäten externer Programme in dem System SAP R/3 nutzen. Demzufolge war

genauso eine Auslagerung der eigenen Systeme in die von externen Unternehmen möglich.

Das System SAP R/3 wurde um das entwickelte Softwaremodul Marktplatz erweitert, es

schloss das Internet direkt an die Geschäftsprozesslogik der SAP-Software an. Die manuelle

Eingabe der Preise und die Lieferdauer der Zulieferer durch die Akteure der entsprechenden

Einkaufsabteilung wurden direkt durch die Einbindung der entsprechenden Komponente des

Zulieferers in dem eigenen System autooperationalisiert. Die Preise und die Lieferdauer des

bestellten Rohstoffes mussten nicht mehr durch Mitarbeiter abgefragt werden, sie wurden von

dem Zulieferer selbst aktuell gehalten. Die großen Zwischenläger fielen weg und die Ware

konnte jetzt direkt für die Produktion eingeplant werden Supply Chain Management (SCM).

Darüber hinaus ergaben sich Skaleneffekte für weltweit agierende Unternehmen, welche über

den Marktplatz ihre Zulieferer vereinheitlichten und so bessere Preise erzielen konnten. Der

Marktplatz ermöglichte den Organisationen einen neuen Absatzkanal ihrer Produkte zu etab-

lieren, indem die eigene Produktpalette für die Kunden bereits über das Internet einsehbar und

absetzbar wurde. Hierüber eröffnete sich ein neuer Kommunikationsweg mit dem Kunden, da

81

der Marktplatz eine Plattform für die Anfragen und Wünsche dieser bereitstellte. Zusätzlich

lieferte die SAP AG mit dem Marktplatz die Analysewerkzeuge, um Kundenkontakte konti-

nuierlich zu messen. Bei Bedarf konnte umgehend mit diesen kommuniziert werden, sei es

über Werbung oder über Ausschreibungen von Produktverbesserungen durch den Kunden

selbst. Diese Form der Zusammenarbeit mit dem Kunden wird Customer Relationship Mana-

gement (CRM) genannt. Die Einbindung der Marktplatzsoftware bei der SAP AG zeigte die

Umsetzung der im Vorfeld gestellten Anforderungen an die Software insofern, als dass In-

formationen über Produkte jederzeit verfügbar und die Kunden ihre Meinungen und Wünsche

in entsprechenden Bereichen an die SAP AG herantragen konnten. Zusätzlich öffnete die

SAP-Software sich auch für die Mitarbeit der Angestellten von zu Hause aus. So wurden als

Beispiel die Prozesse der Personalabteilung durch das Produkt Employee-Self-Service für den

privaten Zugriff ermöglicht. Die Mitarbeiter pflegten darüber ihre Personaldaten in Eigenregie

ein und übernahmen die routinierte Tätigkeit der Personalabteilung; eine weitere vorläufige

Formalisierungslücke war geschlossen. Trotz der vorher beobachteten Operationen und der

sich daraus ergebenden Zielstellung für die geforderte Software existierte keine Garantie für

den IT-Entwickler eben diese erfolgreich zu programmieren. So schlug die SAP AG in der

Phase der Programmierung zuerst einen Weg ein, der aufgrund bestimmter Probleme nicht

funktionierte und ins Leere verlief, um erst im zweiten Anlauf den für sie richtigen zu finden.

Beide werden im Folgenden kurz erläutert. Bei der Erstellung des Marktplatzes entschied sich

die SAP AG anfangs für die Wandlung zu einem Mehrproduktunternehmen. Sie wollte kein

integriertes Gesamtpaket mehr verkaufen, jede einzelne Komponente der SAP-Software sollte

unabhängig voneinander installierbar sein. Ebenso wie das Internet freie Verbindungsmög-

lichkeiten der verschiedenen Rechner ermöglichte, sollte auch die SAP-Software frei von ei-

nem zentralen Kern koordiniert werden. Die daraufhin entwickelten einzelnen Komponenten

des Marktplatzes SCM und CRM sollten separat von dem System SAP R/3 genutzt werden

können. Sie wurden unter dem Namen New Dimension angekündigt, jedoch nicht auf dem

Markt veröffentlicht. Die Gründe hierfür lagen darin, dass die Anforderungen der IT-

anwendenden Unternehmen eher in Richtung des Einsatzes eines integrierten Gesamtpaketes

tendierten, als zu den Vorteilen von einzeln einsetzbaren Produkten. In diesem Zusammen-

hang scheiterten auch der Zusammenschluss mit Intel (Firma Pandesic) und der Verkaufsver-

such von CRM-Teilprodukten. Aufgrund dieser Erkenntnisse schwenkte die SAP AG zurück

zu ihrer alten Idee, dem integrierten Gesamtpaket. Ein Vorteil bei dieser Rückabwicklung

war, dass sich die SAP AG in dieser Zeit nach Platzen der Dotcom-Blase nicht länger einem

überhöhten demand pull gegenübergestellt sah. Sie konnte nun in Ruhe der Software einen

neuen Kern schreiben, der die einzelnen Komponenten wieder zusammenfügen sollte. Hierfür

setzte die SAP AG auf die Objektorientierung und entwickelte ein Business Framework, das

als neuen Kern den Netweaver besaß. Diese korrigierte Anpassung der SAP-Software machte

nun den Weg frei für die Marktplatzsoftware, die den Anwendern die nahtlose Einbindung

von externen Daten ermöglichte. Aussagen zu der Rekontextualisierung der SAP-Software

82

sind schwierig zu treffen, da in der Presse die Diskussionen um die Einführung und Auswir-

kungen der SAP-Software zweigeteilt sind. Auf der einen Seite publiziert die SAP AG die

success storys51, welche eine ausgesprochen gute Annahme der Software durch die Anwender

vermittelte. Auf der anderen Seite finden sich in der Presse Schlagzeilen52 über die negativen

Folgen der Einführung der Software, welche ihre schlechte Annahme im Anwendungskontext

wiederspiegelte. Diesbezüglich ist jedoch schwierig zu differenzieren, ob die negativen

Schlagzeilen nicht aus der schlechten Beratung bei der Einführung der SAP-Software herrüh-

ren oder die Unternehmen sich weigerten, die von der SAP-Software geforderten Unterneh-

mensprozesse anzupassen und demzufolge die SAP-Software Probleme im Anwendungskon-

text auslöste. Die Marktplatzsoftware ermöglichte eine Rationalisierung, eine Verlagerung

von Arbeitsplätzen, Skaleneffekte bei Großunternehmen und die Einbindung von Externen als

Mitarbeiter. Diese Effekte wirkten eher auf die Unternehmensleitung positiv, denn auf die

anwendenden Akteure, die teilweise um ihren Arbeitsplatz bangen mussten. Da der Absatz

der SAP-Software über die Jahre stetig anwuchs, kann dies als Indiz dafür gelten, dass die

gesteckten Ziele erfolgreich von der SAP-Software umgesetzt worden sind. Bei einer heutigen

Anzahl von 24.000 Kunden weltweit sind die Meinungen einzelner Anwender schwer zu fas-

sen und wurden meinen Recherchen nach auch noch nicht in einer globalen Studie ermittelt.

Da noch keine Version des neuen Produktes Business byDesign im Betrachtungszeitpunkt

dieser Diplomarbeit veröffentlicht wurde, kann an dieser Stelle keine fundierte Aussage über

deren De- und Rekontextualisierung getätigt werden. Bezüglich der Dekontextualisierung

wurde nur soweit nach außen kommuniziert, dass dieses System die Aufgabe der Einführung

der SAP-Software in die Unternehmen automatisieren soll, welche dann allein durch die Ma-

nager durchgeführt werden kann. Dieser komplexe Prozess und gegebenenfalls Änderungen

der Geschäftsprozesse sollen danach per Mausklick erfolgen.

4.3.2 Innovationen als Ergebnis von Wechselwirkungen zwischen Akteuren

Der Erklärungskontext beschränkte sich bisher auf die Genese der Handlungen, Operationen

und Algorithmen und erweitert sich nun um die Betrachtung der Wechselwirkungen zwischen

dem Informatiksystem und den IT-anwendenden Organisationen. Die Einordnung der SAP

AG in eine der beiden Akteursseiten ist mit einigen Überlegungen verbunden. Einerseits

pflegt sie als ein IT-produzierendes Unternehmen Verbindungen zu der IT-Forschung & Ent-

wicklung. Ziel der SAP AG ist es permanent den Wissensstand infrage zu stellen, um Neues

für die IT-anwendenden Organisationen zu entwickeln. Andererseits steht sie in der Funktion

eines IT-anwendenden Unternehmens mit IT-Herstellern in Wechselwirkung. Die SAP AG

nutzt sowohl fremde als auch eigene IT. Insgesamt kommuniziert das Unternehmen demzu-

51 Das international agierende Unternehmen Nestlé führte trotz Schwierigkeiten erfolgreich die SAP-Software weltweit ein (vgl. Siegele 2009 S. 72f). 52 Das amerikanische Wall Street Journal berichtete, dass der Hersteller Hershey Foods wegen der Umstellung auf die SAP-Software nicht rechtzeitig Süßigkeiten zu Halloween ausliefern konnte (vgl. Siegele 2009 S.67).

83

folge mit IT-anwendenden Organisationen und IT-Herstellern mal als IT-Hersteller oder an-

wendende Organisation. Dieser besondere Umstand findet in den weiteren Ausführungen Be-

rücksichtigung, auch wenn die SAP AG im Folgenden entsprechend der Definition im Mikro-

polis-Modell als IT-Hersteller klassifiziert wird. Die Kommunikation und der Austausch von

Informationen finden unter anderem in Projekten statt. Geht man von dem Modell der Innova-

tionsspirale im Mikrokontext aus, entstanden die Innovationen aus dem Zusammenspiel des

technology push durch die SAP AG und dem demand pull seitens der anwendenden Organisa-

tionen. Die Wechselwirkungen zwischen der SAP AG und den anwendenden Organisationen

müssten sich im gegenseitigen Beobachten, im Offerieren von Produkten, im Aussenden von

Signalen und Stellen von Anforderungen sowie beidseitigen Rückkopplungen wiederspiegeln.

Die Dynamik dieser Innovationsspirale wäre unter anderem abhängig von der Wettbewerbssi-

tuation auf den Märkten im Zeitraum von 1972 bis heute, der Forschungsinfrastruktur und

dem Vorhandensein eines Innovationsmilieus bei der SAP AG. Der SAP-Mikrokontext wird

vor dem Hintergrund dieser Annahmen analysiert und die Innovationsentwicklung in ihren

Ursachen und Wirkungen anhand dessen nachvollzogen.

Um die Innovation MIAS und deren Weiterentwicklung SAP R/2 zu fassen, muss die Be-

trachtung des Mikrokontextes bis zu den Anfängen der Entwicklung, bis zur Zeit vor Grün-

dung der SAP AG zurückgehen. IBM versuchte sich an der Entwicklung einer integrierten

Datenverarbeitung seit den 50er Jahren. BomP und PICS hießen die entwickelten Softwarean-

sätze, welche den bereits damals gestellten Anforderungen der IT-anwendenden Organisatio-

nen nach einem verbesserten Austausch der Daten im Unternehmen entsprechen sollten. Die-

se Software setzte sich jedoch nicht in den IT-anwendenden Unternehmen durch, da die Re-

chenkapazität der damaligen Großrechner für solch ein System nicht ausgelegt war. Erst die

Entwicklung des RoS von Hopp und Plattner im Auftrag von IBM bei der ICI in Östringen

änderte das. Auf einer Messe in Hannover präsentierte IBM das RoS und ein Mitarbeiter der

ICI in Östringen aus der Abteilung Einkauf zeigte Interesse. Er wollte das System, welches

nur für die Auftragsabwicklung geschrieben worden war, für seine Abteilung ebenfalls nutzen

(vgl. Siegele 2009, S. 36f). Diese Anfrage der ICI konnte das RoS bis dahin nicht erfüllen.

Für die notwendige Modifikation fasste die elektronische Datenverarbeitungsabteilung (EDV-

Abteilung) der ICI die Funktionen an ein neues System in einem internen Bericht zusammen:

Die Einkaufsabteilung und die Kreditoren-Buchhaltung sollten sich in einem EDV-System

integrieren lassen, ebenso wurden die Ideen von der Erfassung von Stammdaten über Termi-

nals formuliert (vgl. Siegele 2009, S. 50). Dieser Bedarf an das neue System wurde zuerst

IBM und später Hopp und Plattner als privater Auftrag unter dem Namen MIAS angeboten.

Dieser Entwicklungsschritt illustriert die Entstehung einer Innovation aus dem dynamischen

Wechselspiel zwischen dem Angebot des Informatiksystems IBM, dem Beobachten durch das

IT-anwendende Unternehmen ICI auf der Messe, dem Stellen neuer Anforderungen an das

System und an IT-Hersteller. IBM lehnte jedoch den Auftrag der ICI ab, da sie noch mit der

Konzeption des Copics beschäftigt waren. Daraufhin bot die ICI Hopp und Plattner die Ent-

84

wicklung des MIAS an. Nach heutigem Kenntnisstand verpasste IBM innovationstechnisch

gesehen eine große Chance, bezogen auf die damalige Zeit ist die Entscheidung von IBM mit

den vorgegebenen Strukturen des Unternehmens erklärbar. Das Unternehmen setzte auf den

konzentrierten Verkauf von Hardware und baute auf den Erfolg des Copics. Die Maßstäbe

von Handlungen und Entscheidungen richteten sich an diesem Denken aus. Außerdem wäre

es für den damaligen Weltmarktführer bei Hard- und Software nur schwer möglich gewesen,

die zukünftige Entwicklung ihrer betriebswirtschaftlichen Anwendungssoftware nach

Deutschland zu verlegen. Aus diesen Blickwinkeln der IBM-Handlungen und -Struktur er-

scheint die Entscheidung von IBM konsequent. Die Innovationsspirale für das MIAS drehte

sich mit der Annahme des Angebotes von Hopp und Plattner dennoch weiter. Die Dynamik

im Innovationsprozess verstärkte sich sogar durch die Faktoren Wettbewerbssituation und

Innovationsmilieu. Der Markt war seit dem unbundling frei für die Gründung von Software-

unternehmen und führte kein vergleichbares Produkt im Angebot. Des Weiteren schufen sich

die Gründer der SAP AG mit dieser ihr eigenes Innovationsmilieu: Hopp und Plattner waren

Spezialisten für Echtzeitsoftware, Wellenreuther im Bereich der Buchhaltung, Tschira mit

dem Betriebssystem DOS und Hector bei der Fertigungssteuerung. Alle arbeiteten vormals

bei IBM und brachten so direkte Kundenkontakte aus diesen Zeiten mit. Neben der Beschrei-

bung von Wechselwirkungen auf dem Markt ist es ebenfalls möglich, in den unmittelbaren

Entwicklungskontext des MIAS hinein zu zoomen und dort die gegenseitige Einflussnahme

der Akteure zu betrachten. Damit befinden wir uns zwar wieder auf der Ebene des soziotech-

nischen Kerns, erweitern allerdings die Perspektive um das genannte Zusammenspiel der Ak-

teure in dem Mikrokontext. Der Austausch der Informationen und die Entwicklung der Soft-

ware zwischen der ICI und den SAP-Gründern erfolgten auf direktem Weg bei der ICI vor

Ort. Dabei wurden die Handlungen der Mitarbeiter nicht nur einfach De- und

Rekontextualisiert, sondern bei der Rückführung der Software in die Arbeitsabläufe auftre-

tende Rückkopplungen der beteiligten Mitarbeiter gewünscht, unmittelbar registriert und Lö-

sungen dieser wieder in die Software überführt (vgl. Siegele 2009, S. 52f). Der gesamte Ver-

lauf der Entwicklung an dem MIAS bestand demnach aus dem Lernprozess der Entwickler

von kontinuierlichen Rückmeldungen der Anwender, ob das System den Anforderungen ent-

sprach oder nicht. Diese Art der Zusammenarbeit wurde in den folgenden Jahren bei weiteren

Kunden genauso angewandt und etablierte sich als Leitbild der SAP AG Entwicklung beim

Kunden. Über die Zusammenarbeit mit Kunden äußerten sich die SAP AG Chefs mehrfach:

„Es war eine Art Sammlertätigkeit“, sagte Claus Wellenreuther, „bei der am Ende nicht mehr

zu unterscheiden war, wer den Anstoß zu einer Lösung gab.“ „Es seien schließlich „Spitzen-

köpfe“ gewesen, deren Wissen wir inhaliert haben.“ „Und was man einmal gelernt hatte, das

brachte man zum nächsten Kunden schon mit.“ „Das war natürlich auch für die Firmen inte-

ressant“, sagte Hopp, „die konnten durch uns auch mal etwas Neues erfahren, nachdem wir

bei ihnen in der „Lehre“ waren.“ (Siegele 2009, S. 54/55) Tschira meinte dazu: „[…] Wir

haben bei jeder Installation dazugelernt […]“ (Meissner 1997, S. 49) Die ICI in Östringen bot

85

außer der Entwicklung beim Kunden den SAP-Gründern eine eigene Plattform an, auf der sie

ihre Software anderen potentiellen Kunden präsentieren konnten. Die SAP AG erhielt damit

neben den bisherigen (Messen, Presse usw.) eine neue Arena, um den technology push ge-

währleisten, das heißt neue Softwareangebote den IT-anwendenden Unternehmen präsentie-

ren zu können. Diese Form des Offerierens von Software etablierte sich in der SAP AG in den

folgenden Jahren als Pilotprojektstrategie. Die SAP AG orientierte sich generell nicht nur an

den IT-anwendenden Organisationen, sondern wurde ebenfalls beeinflusst von anderen IT-

Herstellern, sofern sie als mächtige Akteure in einer gemeinsamen Arena auftraten. Der

Marktführer IBM konzipierte während der Entwicklung seines angekündigten Softwarepro-

duktes Copics das Leitbild MRP. Bereits vor Einführung von Copics fand MRP über die Ma-

nagementliteratur von Jeffrey Miller, Linda Sprague und Joseph Orlicky seinen Weg in den

Markt. Das Leitbild galt als Orientierungs- und Entscheidungshilfe für die zeitgemäße Form

der EDV bei den IT-anwendenden Unternehmen. Da die SAP-Software MRP durch die erar-

beiteten Grundlagen bei IBM vollständig entsprach, präsentierte die SAP AG mit ihrer Soft-

ware den IT-anwendenden Organisationen genau das Produkt, was in der Zeit nachgefragt

wurde. MRP entwickelte sich über die Jahre weiter zu MRP II und um auch dieser Orientie-

rungshilfe für die Organisationen zu entsprechen, erweiterte die SAP AG ihre Software so,

dass auch dieses Leitbild durch ihre Produkte abgedeckt wurde. MIAS kann als Innovation

bezeichnet werden, da es am Markt angenommen wurde. Es fand einen großen Absatz durch

die Schließung von vorläufigen Formalisierungslücken und die Optimierung von Arbeitsab-

läufen. Die Tätigkeit der Datatypisten konnte durch den Einsatz von MIAS ersetzt werden.53

Meissner schreibt hierzu: „Durch die neuartige Software trug SAP in Deutschland dazu bei,

daß die monotone Datatypistentätigkeit der Großrechnerfrühzeit mehr und mehr durch an-

spruchsvolle Sachbearbeiteraufgaben abgelöst wurden.“ (Meissner 1997, S. 45) Die Innovati-

onsspirale drehte sich über die Jahre weiter und es fanden immer mehr Komponenten des wei-

terentwickelten MIAS, die Produkte SAP R und SAP R/2, ihren Weg in die Unternehmen.

Entscheidend hierfür war nicht zuletzt die wachsende Zusammenarbeit mit externen Partnern.

So erweiterte die SAP AG ihr Innovationsmilieu um die Unternehmensberatungsfirmen, wel-

che nicht nur länger ihre Software verkauften, sondern vor allem die SAP-Produkte an die

Ansprüche der IT-anwendenden Unternehmen anpassten. Diese Neuerungen fanden über

Rückkopplungen zurück in die SAP-Software, so bestimmte zum Beispiel die Plaut AG die

Module RK und R/3-CO der SAP-Software maßgeblich mit (vgl. Meissner 1997, S. 195).

Ähnlich wie bei MIAS spielten auch bei der Entwicklung und Einführung des Systems SAP

R/3 verschiedene Akteure innerhalb und im Umfeld der SAP AG eine zentrale und entschei-

dende Rolle. Der auslösende technology push ging auf einer Anwenderkonferenz von dem

mächtigen Akteur IBM aus. Dieser stellte den IT-anwendenden Organisationen und anderen

IT-Herstellern die Planung an dem Produktwechsel von dem IBM /370 Großrechner zu der

53 Der Vorgang der Formalisierung der Tätigkeit der Datatypisten wurde in der soziotechnischen Perspektive bereits genauer erläutert.

86

neuen Hardwareplattform AS/400 vor. Die SAP AG als ständiger Marktbeobachter erkannte

die sich daraufhin verfestigenden Anforderungen einer Kapazitätssteigerung auf der Kunden-

seite und begann die Weiterentwicklung von SAP R/2, die Programmierung an dem neuen

System SAP R/3. Wie in den Ausführungen zu der soziotechnischen Perspektive bereits er-

läutert, sollte das anfangs auf den Unix-Rechnern entwickelte SAP R/3 ursprünglich für den

AS/400 programmiert werden. Der Übertragungsprozess auf den Großrechner stellte sich je-

doch als schwierig heraus, so dass die Software auf den verfügbaren Unix-

Arbeitsplatzrechnern verblieb, fertig gestellt und auf jenen weiter eingesetzt wurde. Dadurch

hatte das Unternehmen für die Programmierer eine neue Forschungsinfrastruktur geschaffen,

deren Funktionalität über die Mainframearchitektur des Systems AS/400 hinausging. Diese

Client-Server-Architektur zeigte, dass sich die SAP AG, obwohl sie sich bisher an Mainfra-

meprodukten orientiert hatte, trotzdem gegen ihre bisherige Struktur und für den Wechsel der

Technologieplattform entschied. In der Entwicklung dieser Software spiegelt sich die inter-

pretative Flexibilität des Unternehmens wieder. Die SAP AG war sich ihrer innovativen Ent-

scheidung gegen ihr Image als Anbieter von Großrechnersystemen bewusst und führte den

Kunden langsam an diese neue Idee heran. So wurde die neue SAP-Architektur auf der CeBit

Messe 1991 noch vor den IT-anwendenden Organisationen zurückgehalten und man behaup-

tete sogar, die gezeigte Software laufe auf einem Großrechner außerhalb des Messegeländes

(vgl. Plattner et al. 2000, S. 98). Diese Angst gegenüber der Reaktionen der Kunden unter-

streicht die entscheidende Abhängigkeit der SAP AG als IT-Hersteller von den IT-

anwendenden Organisationen. Die Befürchtungen vor den Meinungen der Kunden, das neue

Produkt abzulehnen, wurden durch den eintretenden demand pull beseitigt. Viele Kunden

erkannten das Potential der neuen Architektur, unter anderem der Großkunde Würth. Der

technology push des Systems SAP R/3 verlief unter Verwendung unterschiedlicher Marke-

tingstrategien. Die Firma präsentierte SAP R/3 mittels der Pilotprojektstrategie, auf Messen

und Anwenderkonferenzen sowie durch die Produktvorankündigung auf dem amerikanischen

Markt. Die SAP AG agierte als mächtiger Akteur und versuchte seine Marktmacht durch

Veröffentlichungen von success storys zu verstärken. Die gesendeten Signale wurden von den

IT-anwendenden Unternehmen wahrgenommen, die Einführung der Produkte positiv beo-

bachtet und sich mehrfach dafür entschieden. Unter den am meisten genannten Gründen für

die Wahl der SAP-Software, wurde die Marktstellung/ -position genannt (vgl. von Arb 1997,

S.249 und Kapitel 3.2.1 Gründe der Einführung). Neben dieser war das in der Managementli-

teratur weit verbreitete Leitbild der Prozessorientierung ein Faktor für viele Organisationen,

sich für die Software SAP R/3 zu entscheiden. Die Unternehmen waren zu jener Zeit entspre-

chend dem Leitbild BPR daran interessiert, alte Strukturen aufzubrechen und Firmen eher

nach Unternehmensprozessen aufzubauen (vgl. Siegele 2009, S. 65 und Hammer und Champy

1996, S.47f). Diese Neustrukturierung nach Geschäftsprozessen war seit MIAS ein inhärenter

Bestandteil der SAP-Software und deshalb ein gutes Argument für den Kauf dieser. In dieser

Zeit etablierte sich die Zusammenarbeit mit externen Partnern als Partnerstrategie der SAP

87

AG. Man hatte den Effekt, dass Markenmacht auf Kunden entscheidenden Einfluss hat, er-

kannt. Aus diesem Grund wollte die SAP AG das Synergie-Potential aus einer Kooperation

zwischen mächtigen IT-Herstellern nutzen, um einerseits für den Kunden noch attraktiver zu

sein und andererseits schneller auf deren Anforderungen reagieren zu können. Beispielhaft

dafür ist die Verbindung mit Microsoft. Wie auch in anderen Zusammenarbeiten entstanden

hier zwischen den IT-Herstellern Wechselwirkungen die zu Inventionen der Weiterentwick-

lung von SAP R/3 führten. Die SAP AG und deren Technologie- beziehungsweise Hardware-

partner stellten sich gegenseitig Anforderungen, reflektierten diese und passten ihre Produkte

gegebenenfalls aneinander an. Da die beteiligten IT-Hersteller den demand pull der IT-

anwendenden Organisationen gemeinsam beobachteten und auswerteten, erhöhte sich die

Wahrscheinlichkeit bedarfsgerecht auf den Markt reagieren zu können und führte zusätzlich

zur Stärkung ihrer Marktmacht. Die IT-anwendenden Unternehmen ergaben sich diesem

Marktdruck jedoch nicht bedingungslos, vielmehr versuchten sie mit Hilfe von Unterneh-

mensberatungen für sich das bestmögliche Produkt auf dem Markt zu lokalisieren. Dadurch

nahmen die Beratungspartner die Funktionen des Beobachters und Vermittlers für die Organi-

sationen ein und hielten für diese die Innovationsspirale am Laufen (vgl. Rolf 2008, S. 104).

Dieses Vertrauensverhältnis nutzte die SAP AG insofern für die Weiterverbreitung und Wei-

terentwicklung, als dass sie ebenfalls anfingen mit Unternehmensberatungen zusammenzuar-

beiten. Sie wollten einen direkten Draht zwischen den SAP-Produkten und den IT-

anwendenden Unternehmen sicherstellen und gegebenenfalls auf die Auswahl der einzufüh-

renden Software Einfluss nehmen, aber auch schnellstmögliche Rückkopplungen des Marktes

erreichen. Die Beratungspartner empfahlen die SAP-Software mit der Begründung der SAP-

Marktführerschaft gezielt auf der Managementebene, was den oft genannten Grund, der von

oben Einführung von SAP-Produkten erklärt. 54 Obwohl das Management die Entscheidungs-

gewalt für oder gegen eine Software inne hatte, zeigen die Erfolgsfaktoren aus der Studie von

Wolter55, dass die Wahl der Projektform und die Beteiligung verschiedenster Akteure eben-

falls einen elementaren Beitrag für eine erfolgreiche Einführung leisteten. Dabei galten die

Einführungsstrategien Managementunterstützung, Qualifikation, Kommunikation und Partizi-

pation als wichtige Einflusskriterien. Jede einzelne trat mehr oder weniger in den Vorder-

grund, abhängig davon ob das traditionelle Vorgehensmodell oder die ASAP-Methode ge-

wählt worden ist. Beide Einführungsmodelle förderten in unterschiedlicher Ausprägung die

direkten Rückkopplungen mit den Mitarbeitern, welche somit ebenfalls als Erfolgsfaktoren

bezeichnet werden können. Die Weiterentwicklung der SAP-Software fand in zwei Arenen

beziehungsweise Projekten statt, bei der SAP AG als auch durch die IT-anwendenden Unter-

nehmen bei der Einführung von SAP R/3. Die einflussreiche Stellung einzelner Akteure wird

durch die Nutzung von Key Usern und Promotoren betont, da diese den Erfolg einer Einfüh-

54 Zurzeit des MIAS mussten die SAP-Gründer noch die EDV-Abteilung überzeugen, um über diesen Weg zu der Entscheidung auf Managementebene zu kommen. 55 Hier sei auf die quantitative Studie von Wolter 2006 verwiesen.

88

rung eher gewährleisteten als andere Mitarbeiter. Analog zu der Kooperation mit den Techno-

logie-, Hardware- und Beratungspartnern erfolgte die Zusammenarbeit mit den Vertriebs- und

Entwicklungspartnern. Neben den genannten Synergie-Effekten konnte die SAP AG nun die-

jenigen Arbeiten auslagern, welche dem Unternehmen unrentabel erschienen und sich im Ge-

genzug auf die entscheidenden Produkte konzentrieren. Des Weiteren bauten die Partner auf

eigene Kosten Ergänzungsprodukte um die SAP-Software.

Die weitere Entwicklung an dem Produkt SAP R/3 fiel in die Zeit, als das Internet den Markt

eroberte. Diese Innovation eröffnete den Usern zusätzliche Handlungsoptionen, so dass neue

Bedürfnisse der IT-anwendenden Unternehmen entstanden. Sie erwarteten von der Unter-

nehmens-IT eine laufende Verbindung zu dem Internet und zu anderen Unternehmen. Jeder

Arbeitsplatz sollte, wenn möglich mit dem WWW verknüpft und der Einbezug von Lieferan-

ten und Kunden reibungslos gewährleistet sein. 1996 konnte die SAP AG bereits das BAPI

vorstellen und dem demand pull der Kunden nach einer Verbindung mit dem Internet entspre-

chen. Den technology push gaben sie erneut auf Messen und über Partner.56 Damit waren al-

lerdings noch nicht alle Ansprüche der IT-Anwender befriedigt. Sie orientierte sich daher an

den Best-of-Breed-Produkten der neu aufkommenden IT-Hersteller Siebel und i2, die bereits

den Einbezug von Lieferanten und Kunden in das IT-System der Kunden versprachen. Die

Innovationsspirale von SAP drehte sich dennoch nur noch langsam und kam zeitweise ins

Stocken, weil die neuen IT-Hersteller schneller handelten und damit erfolgreich im Markt

agierten. Der Grund dafür lag in der Position, die die SAP AG auf dem Markt eingenommen

hatte. Sie reagierte bisher zeitversetzt auf Anfragen von Kunden oder Anforderungen von

Technikentwicklungen und lieferte demnach in dieser Zeit kaum Softwareangebote aus eige-

nen Visionen heraus. Hasso Plattner antwortete auf die Fragen um das Internet und der SAP

Internet Vision mit der Gegenfrage: „Was ist ihre Vision? Denn wir werden immer von den

Anforderungen unserer Kunden vorangetrieben.“ (Plattner et al. 2000, S. 43/44) Die SAP AG

musste umgehend auf ihre Entwicklungslücke reagieren, was sie auch tat. Um die Anforde-

rungen der Kunden durch ein Produkt schnellstmöglich erfüllen und ihnen zukünftig besser

begegnen zu können, wählten sie den Weg der Wandlung zu einem Mehrproduktunterneh-

men. Sie begannen die Entwicklung an dem Business Framework, welches gestützt durch das

Informatikleitbild der Objektorientierung eine Kapselung der einzelnen Produkte versprach,

die unabhängig voneinander installierbar waren. Diese angekündigte Produktreihe der New

Dimension kam jedoch nie über die Programmierungsphase hinaus, da sich nach dem Platzen

der Dotcom-Blase eine Änderung der Anwenderbedürfnisse abzeichnete. Der demand pull der

Organisationen signalisierte wieder den Wunsch nach einem integrierten System, welches die

Unternehmensprozesse bündelte. Die Zeichen der Organisation standen auf Konsolidierung

von Software. Aufgrund dieser Beobachtung stoppte die SAP AG die weitere Entwicklung

und Fertigstellung der Produkte New Dimension. Sie begab sich erneut auf den alten Pfad der

56 Hasso Plattner und Bill Gates präsentierten auf der Messe Sapphire, wie die SAP-Software mithilfe von Microsoft E-Commerce möglich machte (vgl. Siegele 2009 S.89).

89

integrierten ERP-Software und verknüpfte diese mit den Anforderungen aus den Möglichkei-

ten des Internets. Den IT-anwendenden Organisationen wurde daraufhin der Marktplatz prä-

sentiert, der jeden Arbeitsplatz mit dem WWW verknüpfte und die Lieferanten und Kunden

reibungslos einbezog. Hierüber schloss die SAP AG die Lücke in der Produktreihe Best-of-

Breed und konnte so auch in diesem Segment den Bedürfnissen des Marktes entsprechen.57

Die Innovationsspirale drehte sich wieder. Ab 2006 wurde das integrierte Gesamtsystem -

vormals mySAP.com, vormals SAP R/3 - unter dem Namen SAP Business Suite 7 verkauft.

Der Absatz verlief in allen drei Namensperioden über die Jahre anhaltend gut. Die Ursachen

dieser positiven Entwicklung liegen zum einen im Jahr-2000-Problem und zum anderen in

den Wechselwirkungen mit den börsennotierten IT-anwendenden Unternehmen und dem da-

raus entstehenden Netzeffekt. Die programmiertechnische Besonderheit des Jahr-2000-

Problems betraf das SAP-System nur rudimentär, da die SAP-Software bereits auf das vier-

stellige Datum umgestellt war. Die SAP-anwendenden Unternehmen wurden dadurch in ihrer

Entscheidung für SAP bestärkt und für neue Kunden gewann die Software an Attraktivität. Im

Zusammenhang mit den börsennotierten Kunden zeigte sich, dass die Unternehmensleitung

durch die Einführung von SAP-Produkten die Leistungen verbessern und somit den Anforde-

rungen der Shareholder folgen wollte. Mit jedem neuen Verkauf stärkte die SAP AG nicht nur

ihre Marktmacht, sondern trug zur weiteren Vernetzung der Organisationen über ihre Produk-

te bei, was wiederum immer mehr Unternehmen für SAP interessierte. Es entstand der Netz-

effekt. Die Dynamik der Innovationsspirale seit Einfluss des Internets war allerdings nicht nur

abhängig von der anfänglichen Beobachtersituation und der daraus resultierenden Reaktions-

zeit der SAP AG auf Bedürfnisse des Marktes, vielmehr auch von einzelnen Akteuren in und

um das Unternehmen SAP AG in dieser Zeit. Die Unternehmensstrategie Stock Options und

der negativ bewertete, farbenprächtige Namenswechsel zu mySAP.com banden Mitarbeiter an

andere Unternehmen und führte sogar zum Weggang eigener Mitarbeiter. Neue fanden nicht

mehr den Weg zur SAP AG und eigene kluge Köpfe wanderten ab, so dass sich das kreative

Innovationsmilieu um SAP verkleinerte. Das änderte sich zum Vorteil der SAP AG nach der

Dotcom-Blase wieder. Um zukünftig einem erneuten Mitarbeiterverlust vorzubeugen, etab-

lierte die SAP AG Innovationsgemeinschaften für die Weiterentwicklung von Software und

bezog, neben den Partnern, Freiberufler, Geschäftskunden und Entwickler verstärkt mit ein.

Die Verbindung mit der Plattform Innocentiv schaffte außerdem eine kostengünstige Mög-

lichkeit den Elan der SAP-Interessierten oder -Freiberuflern direkt zu nutzen und aus vielen

kleinen Ideen viele kleine Innovationen zu generieren, welche die Innovationsspirale am Lau-

fen halten sollten. Zusätzlich zu diesen Maßnahmen der Erweiterung des Innovationsmilieus

wuchs dieses auch durch die Gründung verschiedenster Entwicklungsbüros über Ländergren-

zen hinweg. Die Kommunikation der Entwicklungsteams untereinander erfolgte innerhalb

von Projekten und wurde über das Internet mit den nötigen Kommunikations- und Kollabora-

57 Durch den Kauf von Business Objects im Jahr 2008 integrierte die SAP AG das Business Intelligence in sein Produktportfolio.

90

tionswerkzeugen gesteuert. Die SAP AG nutzte die jeweiligen Potentiale der Akteure ver-

schiedener Länder und sicherte sich umfangreiche Rückkopplungen für die Verbesserung der

Produkte.

Da die Entwicklung hin zu der SAP Business Suite 7 nichts anderes war, als die Rückkehr zu

dem alten System SAP R/3, versuchte die SAP AG mit Business byDesign einen neuen Weg

einzuschlagen. Der Ex-SAP AG Chef Leo Apotheker äußerte sich generell hinsichtlich neuer

Wege in der Frankfurter Allgemeinen Zeitung: „In der Softwareindustrie gibt es nur zwei

Wege entweder man ist innovativ, oder man wird ein Wartungsunternehmen. Nicht innovativ

zu sein, ist keine Option für uns.“ (Siegele 2009, S. 246) Dieser Anspruch allein trug nicht die

Verantwortung für die Entwicklung einer neuen Software, vielmehr äußerten Unternehmen

ihren Unmut über die hohen Einführungskosten von SAP-Produkten durch SAP-Berater. Die-

ser Kritik trat die SAP AG insofern entgegen, als dass Business byDesign von Managern ei-

genständig integrierbar und als On-Demand-Produkt über das Internet per Nutzungsgebühr

verfügbar sein sollte. Damit trug die SAP AG nicht nur dem Bedarf der Kunden Rechnung,

sie entsprach gleichzeitig dem neu aufkommenden Leitbild der Managementliteratur, dem

Cloud Computing. Mit Business byDesign möchten sie dem Markt ein Produkt offerieren,

welches eine unproblematische Verbindung des SAP-Systems mit anderen möglich macht

und Verbindungsschwierigkeiten von mobilen Systemen und die Einbindung von RFID prob-

lemlos löst. Ob die neue Software als eine Innovation bezeichnet werden darf, wird sich mit

der Annahme oder Ablehnung durch die IT-anwendenden Organisationen bei Markteinfüh-

rung zeigen. Hasso Plattner meint zu den Möglichkeiten des Internets: „Es ist bereits zu er-

kennen, wie das Internet die Geschäftsabwicklung verändern wird. Viele menschliche Ver-

mittler werden ersetzt werden durch elektronische Vermittler. […] wird sich die Geschäfts-

abwicklung zwischen Personen und Firmen erheblich gewandelt haben.“ (vgl. Plattner et al.

2000, S. 45) Insofern beschreibt die Weiterentwicklung von SAP unter Einfluss des Internets

eine stetige Zunahme von Formalisierungen der Arbeitskontexte, welche mit der Rationalisie-

rung der Arbeit einhergeht. Bei der Analyse des Produktes Business byDesign stellt SAP

selbst die Formalisierungslücke vor - die Arbeit des IT-Beraters wurde als die vorläufige

Formalisierungslücke identifiziert. Diese soll durch das neue Produkt geschlossen werden.

Die Manager führen dann die SAP-Software ein und übernehmen damit die Arbeit der zu-

künftig überflüssigen IT-Berater. Deren Arbeit wurde durch die Software formalisiert und

kann jetzt anstatt von mehreren von einer Person erledigt werden.

4.3.3 SAP im gesellschaftlichen Kontext

In diesem Kapitel stehen die Fragen im Mittelpunkt, inwiefern die Gesellschaft auf die Ent-

wicklung der SAP AG und deren Produkte Einfluss genommen hat und umgekehrt, ob Ent-

scheidungen des Unternehmens maßgebend für Umweltentwicklungen waren. Es findet eine

Auseinandersetzung mit den vorherrschenden gesellschaftlichen Phänomenen in den jeweili-

91

gen Produktzeiten statt. Dabei wird berücksichtigt, dass sich die Macht der Umweltbedingun-

gen auch über die IT-anwendenden Organisationen äußern kann, mit denen die SAP AG im

Mikrokontext in Wechselwirkungen steht.

Im Jahr 1969 unterzog das Kartellamt des amerikanischen Justizministeriums IBM als Mono-

polisten des IT-Marktes unter dem Verdacht der Wettbewerbsverzerrung durch Preisbünde-

lung von Software an die Hardware einer Prüfung. IBM reagierte auf dieses drohende Kar-

tellverfahren und traf die strategische Entscheidung unbundling - der getrennte Verkauf von

Software und Hardware (vgl. Campbell-Kelly 2003, S. 109f). Diese Neustrukturierung des

IT-Marktes aufgrund einer politischen Einflussnahme führte als ein wesentlicher Faktor zur

Gründung vieler Softwarefirmen, darunter auch der SAP AG. Außerdem ergab sich damit

eine geänderte Auftragsvergabe der ICI in Östringen, so dass die SAP-Gründer die Möglich-

keit erhielten das Produkt MIAS zu entwickeln. Die Einführung von MIAS und dessen Nach-

folger in die IT-anwendenden Unternehmen hatten und haben wiederum den Arbeitsmarkt

und dessen Gestaltung geprägt. Es änderten sich die Arbeitsbedingungen bei den SAP-

anwendenden Unternehmen. Der Berufstand der Datatypisten löste sich nach und nach auf

und an die betreffenden Mitarbeiter wurden höhere Qualifikationsanforderungen gestellt. Im

ersten Fall galt die SAP AG in der deutschen Presse als Synonym der Arbeitsplatzvernichtung

und Mitarbeiterüberwachung. Im Jahr 1997 verteidigte dies der SAP AG Chef Hopp mit den

Worten, nicht nur Arbeitsplätze vernichtet, sondern auch welche geschaffen zu haben (vgl.

Meissner 1997, S. 46). Über die Jahre stieg der Absatz der SAP-Produkte und deren Marktan-

teil derart stark an, dass sich die erhöhten Qualifikationsanforderungen an die Mitarbeiter und

der Bedarf an Fachkräften mit SAP Wissen im deutschen und später internationalen Arbeits-

markt als allgemeine Arbeitsplatzanforderungen in vielen Unternehmensbereichen etablierten

oder zumindest als wünschenswert erachtet wurden. Die Partnerunternehmen der SAP AG

bauten Ausbildungszentren58 und die Hochschulen59 fingen an, ihre Studenten in SAP Wissen

zu schulen.

Der Produktwechsel von SAP R/2 hin zu der Client-Server-Architektur des Systems SAP R/3

kann im Kontext der Globalisierung der IT-anwendenden Unternehmen betrachtet werden

und bietet dadurch eine adäquate Erklärung für diesen Entwicklungsschritt. Die Wurzeln der

Globalisierungsleitbilder finden sich im Zusammenhang mit der makroökonomischen Theorie

des Neoliberalismus, der dem Keynesianismus gegenübersteht. Letztere nach dem National-

ökonom Keynes beruhte auf der Annahme, dass eine starke Volkswirtschaft durch Vergabe

von öffentlichen Aufträgen und sonstigen staatlichen Eingriffen die Krisenanfälligkeit des

Kapitalismus abfedern könne. Die neoliberalen Angebotstheoretiker vertraten hingegen die

These, dass der Staat den Unternehmen freie Hand lassen solle und die Maxime der Gewinn-

58 Meissner verweist auf ein internationales Schulungszentrum von Price Waterhouse in Philadelphia im Jahr 1996 (vgl. Meissner 1997, S. 127). 59 Die SAP AG arbeitet seit 1995 an der Zusammenarbeit mit den technischen Universitäten in den USA (vgl. Meissner 1997 S. 127).

92

maximierung der Unternehmen gleichzeitig dem Gemeinwohl diene. Die Steigerung der öko-

nomischen Effizienz wurde im uneingeschränkten Freihandel und in der Privatisierung gese-

hen. Ab den siebziger Jahren setzten sich die Neoklassiker in einer überwiegenden Anzahl

von Staaten durch und folgten damit den Vorreitern Chile, USA und England, die diese Lehre

bereits zu ihrer Handlungsmaxime erklärt hatten. In diesem Zuge traten die ökonomischen

Leitbilder Privatisierung, Deregulierung und Liberalisierung in den Vordergrund, welche ent-

staatlichte und liberalisierte Märkte als Ziel definierten. Diese Leitbilder prägten die Globali-

sierung in ihrer heutigen Form und wurden durch Vollzugsorgane60 in Gesetzen und Regelun-

gen der vergangenen Jahre angestrebt und umgesetzt. Die Folge war, dass der Schutz der na-

tionalen Märkte immer weiter aufgehoben und globale Maßstäbe gesetzt wurden: Durch die

Privatisierung gingen einstige Monopolbetriebe in die Hände der Privatwirtschaft über, durch

die Deregulierung wurde der Abbau nationaler Eingriffe wie Regeln, Vorschriften oder Han-

delsbeschränkungen aufgeweicht und durch die Liberalisierung wurden die Privilegien wie

Zölle und Subventionen aufgehoben (vgl. Rolf 2008 S. 117f). Die Deregulierung und Libera-

lisierung der Märkte verschaffte den Organisationen die Möglichkeit weltweit Fuß zu fassen.

Jedoch benötigten diese für die Kontrolle einer solchen Expansion auch eine entsprechende

Software, die diesen Anforderungen gerecht werden konnte. Die eingeschränkte Skalierbar-

keit der Großrechnerarchitektur war darauf nicht ausgelegt. Erst die Verteilung der Arbeitslast

durch die Client-Server-Architektur entsprach diesem Bedarf der IT-anwendenden Organisa-

tionen. Das Ziel der Globalisierung, Grenzen und Märkte zu öffnen, spiegelt sich in den An-

wendungsmöglichkeiten des Systems SAP R/3 wieder. Seine Entwicklung und Einführung ist

damit ein Mittel zur Förderung der Globalisierung.

Sowohl die Leitbilder und Strategien der Globalisierung als auch die Innovation Internet ver-

änderten die ökonomischen und kommunikativen Bedingungen der Märkte in der Gesellschaft

und prägten dadurch wiederum die Anforderungen der IT-anwendenden Unternehmen und

darüber die Weiterentwicklung der SAP-Produkte von der Produktreihe New Dimension bis

zu der SAP Business Suite 7. Allerdings ist dies kein linearer Entwicklungsverlauf, da sich

diese neuen Handlungsstrukturen innerhalb der SAP-Softwareentstehung erst neu bilden und

verfestigen oder in Frage gestellt werden mussten. Auf Seiten der SAP AG wurde anfangs ein

Weg beschritten, der den Leitbildern der Globalisierung in Verbindung mit den Möglichkei-

ten des Internets gerecht werden sollte. Sie folgten den auf dem Markt neu aufkommenden

und erfolgsversprechenden Best-of-Breed-Produkten, bestehend aus SCM und CRM. Die Lö-

sung über die unabhängige Installierbarkeit aller Produkte setzte sich allerdings in der Entste-

hung nicht durch, dagegen die Weiterentwicklung der integrierten Standardsoftware, welche

der Unternehmensleitung nach wie vor die Herrschaft über alle Geschäftsprozesse sicherte.

Die daraufhin erfolgreiche Einführung der Marktplatzsoftware entsprach diesen Vorstellun-

gen und den Maßstäben der Leitbilder der Globalisierung. Hieraus bot sich die Möglichkeit

60 Es handelt sich zum Beispiel um die Weltbank, den Internationale Währungsfond, die World Trade Organisa-tion und die Europäische Kommission.

93

einer Einbindung von Kunden und Lieferanten, welche über globale Logistikketten als Wert-

schöpfungskette in die Geschäftsprozesse der Unternehmen integriert werden konnten. Der

Marktplatz schafft es demzufolge Informationen von Kunden und Zulieferern für die Organi-

sationen verfügbar zu machen und ihnen auf hohem Aggregationsniveau einen Überblick der

weltweiten Verteilung von Ressourcen zu präsentieren. Aus dieser globalen Vernetzung her-

aus veränderte sich die Arbeitswelt in der Gesellschaft und speziell in den Organisationen,

was sich sowohl auf die SAP AG als auch auf die Produktentwicklung auswirkte. Die SAP

AG schaffte sich durch den Einbezug von Kunden über den Marktplatz so genannte Innovati-

onsgemeinschaften, die über Open Innovation an der Weiterentwicklung der SAP-

Produktreihe arbeiteten. Sie konnte so auf die kostenlose Mitarbeit der Kunden zurückgreifen.

Zudem trieb der Einbezug der eigenen Mitarbeiter in die globale Geschäftslogik der SAP AG

die damit verbundende Weiterentwicklung der SAP-Produkte durch teilweise sogar kostenlo-

ses Abschöpfen der Kopfarbeit weiter voran. Durch die Gründung von weltweiten SAP-

Entwicklungsbüros wurden die an den entsprechenden Orten herrschenden politischen wie

kulturellen Verhältnisse für die Produktentwicklung genutzt. Die SAP AG in ihrer Rolle als

Herrscher über ein Netzwerk lagerte viele Aufgaben nach verschiedenen Gesichtspunkten aus,

wobei sie damit je nachdem einen der drei Netzwerktypen abbildete. Nach Arno Rolf lassen

sich mindestens die Formen Contract Manufacturing, Contract Engineering und das Contract

Service unterschieden (vgl. Rolf 2008, S. 127f). Bei Contract Manufacturing wird die Pro-

duktion in Billiglohnländer ausgelagert, wo die Qualifikationsanforderungen gering sind und

eine Kostenrationalisierung im Vordergrund steht. Bei Contract Engineering hingegen wird

ein Netzwerk auf Grundlage des Austausches von technischem Know-How gebildet. Der

Netzwerkherrscher achtet zuerst auf die Qualität der Arbeit und legt erst dann Wert auf die

Kostenreduktion. Contract Services beschreibt die verschiedensten Auslagerungsstrategien

aus dem Dienstleitungsbereich. So wird anwendungsferne Programmierung, Buchhaltung,

Lohnabrechnung, Kundenkontakte über Callcenter und Routineberatungen bei Unterneh-

mensberatern abgegeben. Die SAP AG verschob nach dem Vorbild des Contract Manufactu-

ring einfache Programmiertätigkeiten wie die Abarbeitung von überschaubaren Programmier-

fehlern oder den Einsatz von Callcentern für einen weltweiten Support in die Billiglohnländer

Indien, Ungarn, Bulgarien und China. Technisch aufwendige Tätigkeiten wurden in denjeni-

gen Ländern erledigt, welche eine entsprechende Expertise hierzu anboten, gemäß dem

Contract Engineering. So steht das Entwicklungsstudio in den USA für innovative Produkt-

entwicklung, Israel für die Eignung bei höchst komplexen Problemen und Japan für das Wis-

sen im Umgang mit der dortigen Kalligrafie. Die Form des Contract Services zeigt sich in der

SAP AG, als dass Partnern die Aufgaben der Beratung, Verbreitung und Weiterentwicklung

der SAP-Produkte übertragen wurden. Neben den großen Vertriebs-, Entwicklungs-, Hard-

ware-, Technologie- und Logopartnern bezog die SAP AG bis heute auch viele kleine SAP-

Systemhäuser in ihre Hierarchie mit ein, so dass Großkunden und auch scheinbar unrentable

Sparten der kleinen und mittelständischen Betriebe ihre Anbindung an die SAP-Software fan-

94

den. Das Netz spannte sich weiter aus, die SAP AG folgte dem Weg hin zu einer Netzwerkor-

ganisation, einem heute noch aktuellen Leitbild innerhalb der Gesellschaft. Die Liberalisie-

rung der Märkte gewährte den steuer- und zollfreien Rückfluss der im Ausland entwickelten

Komponenten nach Deutschland. Durch Subventionsleistungen erhöhten Standorte wie Indien

und Kanada ihre Attraktivität für die SAP AG und trugen somit zu deren Globalisierung bei.

Die Handlungen der SAP AG und vor allem ihre Produkte als Teil der globalen IT-

Infrastruktur gehörten damit zu einem unverzichtbaren Medium für die Wandlung zu einer

globalen Ökonomie (vgl. Castells 2001, S. 106f und 199).

Welche Rolle die parallel zur Globalisierung auftretenden gesellschaftlichen Entwicklungen

und Phänomene wie die immer größer werdende Kluft zwischen Arm und Reich, die Errei-

chung der Effizienzsteigerung bei der Privatisierung durch Beschäftigungsabbau und Redu-

zierung der Leistungen, die durch Verlagerung und Rationalisierung einhergehende Arbeitslo-

sigkeit, die erhöhten Qualifikationsanforderungen der globalen Wissensökonomie und die

Blockaden und Abschottungen ganzer Staaten durch Zölle und Subventionen bei der IT-

Entwicklung und für die SAP AG spielen wird, ist abhängig von der zukünftigen Stärke ihrer

Wechselwirkungen in dem Mikrokontext.

4.3.4 Pfade der erfolgreichen und misslungenen SAP-Innovationen im Zeitverlauf

Im Folgenden konzentrieren sich die Ausführungen zuerst auf die Konstruktion des SAP-

Technikentwicklungspfades und danach auf das Skizzieren eines Panoramaüberblicks des

Techniknutzungspfades Büro, um anschließend auf die Parallelen und Verknüpfungspunkte

zwischen den beiden Pfaden einzugehen.

4.3.4.1 Der SAP-Technikentwicklungspfad im Mikropolis-Modell

In den vorherigen Unterpunkten wurde über die Ebenen der soziotechnischen Perspektive und

des Mikro- und Makrokontextes eine detaillierte Betrachtung der Gründe und Auslöser für die

SAP-Technikentwicklungen und der Wechselwirkungen vorgenommen. Dieser Einblick in

den Motor der SAP-IT-Entwicklung und die vorhandenen beziehungsweise geschlossenen

Formalisierungspotentiale offenbarten und erläuterten bereits im Speziellen elementare Ver-

läufe und Bedingungen innerhalb des SAP-TEPs. Darauf aufbauend bietet sich nun die Mög-

lichkeit den Querschnitt durch die genannten Ebenen noch dahingehend zu analysieren, in-

wiefern sich die Sieger und Verlierer der SAP-Technikentwicklung über den in dieser Dip-

lomarbeit festgelegten Betrachtungszeitraum abbilden lassen. Dieses Vorhaben soll nun in

einer zusammenfassenden Pfaddarstellung der Ereignisse, Veränderungen, Innovationen, Ma-

nagementleitbilder und Strategien der SAP-Technikentwicklung bis 2009 umgesetzt werden -

visualisiert in seinen Ergebnissen und dokumentierend ohne dabei stark die Einzelheiten zu

wiederholen. Dieser dadurch gewonnene SAP-TEP spiegelt durch das Herausstellen der er-

folgreichen und untergegangenen Entwicklungspfade über den Zeitablauf die SAP-

95

Technikentwicklung, wie sie sich bereits in den Ausführungen zu den Wechselwirkungen

zeigte, wieder. Eines der Ziele dieser Auseinandersetzung mit dem SAP-TEP ist die potentiel-

le Wissensgenerierung aus der Vergangenheit für zukünftige Entwicklungen und Innovatio-

nen, die den Pfaden und Prozessen im Mikropolis-Modell theoretisch zugesprochen wird und

praktisch zu überprüfen ist. Da in den wissenschaftlichen Arbeiten bisher noch keine Darstel-

lungsoptionen für TEPe im Mikropolis-Modell entwickelt worden sind, ist die Visualisierung

in meiner Arbeit angelehnt an die Überlegungen des TNPs, aber entsprechend den Faktoren

und Elemente des Untersuchungsfeldes SAP-Technikentwicklung formal angepasst und wei-

terentwickelt. Die Zeitspanne des SAP-TEPs lässt sich mittels eines Zeitstrahls abbilden, der

gleichzeitig der SAP AG und ihren innovativen Produkten entspricht. Alle neu beginnenden

und laufenden SAP-Technikentwicklungen sind als Pfade dargestellt, die bei Entwicklungs-

beginn einer neuen Software erstmals den Hauptstrang (Zeitstrahl) verlassen, im Entwick-

lungsprozess parallel verlaufen und erst bei erfolgreicher Entwicklung und Durchsetzung am

Markt wieder in den Hauptstrang integriert werden. Somit zeigt eine Integration in den

Hauptstrang den Sieger einer Softwareentwicklung an und ein Appendix den Verlierer, der

nicht mehr weiter im Unternehmenskontext produziert und genutzt wird. Die Art der Darstel-

lung beinhaltet nicht, dass in den Entwicklungsphasen gewonnenes Wissen gebunden an eine

Fehlentwicklung mit dieser verloren geht, sondern setzt die permanente Einbindung der Er-

fahrungen in den SAP Handlungskontext voraus. Der Zeitstrahl wird durch stattfindende Er-

eignissen unterteilt und die Zeitpunkte markiert, an denen elementare Entwicklungsschritte

entweder eingeleitet oder beendet wurden. Des Weiteren finden sich die auf die SAP-

Technikentwicklung stark einflussnehmenden Managementleitbilder und Strategien unter

dem Zeitstrahl. Neu erscheinende Managementleitbilder oder Strategien sind rot gekenn-

zeichnet und wechseln in der Farbe zu schwarz, sobald sie weiter die Entwicklung fundamen-

tal mitbestimmten beziehungsweise in die SAP-Handlungsstrukturen aufgenommen wurden.

Neben diesen finden sich über dem Zeitstrahl in den Abbildungen die prägenden Einflüsse

des Makrokontextes. Einerseits verlaufen dort diejenigen Pfade der IT-Entwicklungen anderer

Hersteller, welche unmittelbar oder indirekt für den Verlauf der SAP-Technikentwicklung mit

verantwortlich waren. Eindeutig zu ziehende, direkte Verbindungen sind durch entsprechende

Verknüpfungslinien gekennzeichnet, die in die SAP-Entwicklungspfade übergehen. Alle an-

deren verlaufen parallel zum Zeitstrahl der SAP-Technikentwicklung. Andererseits schweben

dagegen Leitbilder oder Themen des Makrokontextes symbolisch wie eine Wolke über dem

gesamten Zeitstrahl. Sie bestimmten demnach über einen längeren Zeitraum die Geschehnisse

und sind keinem einzelnen Zeitpunkt zuzuordnen. Zwischen dieser Wolke und der SAP-

Technikentwicklung thematisieren in eckige Klammern gesetzte Begriffe die unterschiedli-

chen Auffassungen und Nebenfolgen der vorhandenen Pfade und Prozesse. Für eine bessere

Veranschaulichung und Übersichtlichkeit ist die Einteilung des Zeitstrahls in eine Jahresskala

optisch ungleichmäßig erfolgt, was jedoch in diesem Zusammenhang vernachlässigt werden

96

kann. Dem Platzmangel ist geschuldet, dass der SAP-TEP statt in einer in drei Abbildungen

dargestellt wird.

Abb. 35: SAP-Technikentwicklungspfad - erster Zeitabschnitt: MIAS, SAP R und SAP R/2

(eigene Darstellung)

Aus dem ersten Teil des SAP-TEPs (vgl. Abbildung 35) ist ersichtlich, dass vor der Gründung

der SAP AG bereits externe Prozesse aus der IT-Entwicklung anderer Hersteller die spätere

SAP-Technikentwicklung um das Produkt MIAS stark gefördert haben. Die IBM Vorent-

wicklungen legten neben der technologischen Basis der integrierten Standardsoftware, welche

in der Anfangszeit noch das Schlagwort ‚Echtzeit‘ beinhaltete, auch die Verknüpfung zu den

damaligen Managementleitbilder MRP und MRP II fest. Die Einflüsse des Makrokontextes

im Zusammenhang mit der Gründung der SAP AG bestanden im unbundling bei IBM und

dem übernommenen globalen Leitbild der Prozessorientierung. Mit Gründung zeichneten sich

dann allerdings schon früh eigene Strategien der SAP AG ab, die die Qualität der Wechsel-

wirkungen zwischen der Softwareentwicklung und den IT-anwendenden Unternehmen auf-

zeigten. So lag der Schwerpunkt auf dem Aufbau enger Bindungen zu Kunden und auf der

Befriedigung deren Anforderungen mit dem Ziel, durch ihre Technik Formalisierungslücken

schließen zu können und um sich damit auf dem Markt zu etablieren. Die früheste Strategie

Entwicklung beim Kunden bot direkte Rückkopplungen, die für die Software nutzbar gemacht

wurden. Eine zweite Bindung zum Kunden wurde über die Messen mit den Messekontakten

aufgebaut, wo sie die Software direkt vor einem großen Publikum vorführten. Durch die Pi-

lotprojektstrategie konnten dann gezielt wichtige, potentielle Geschäftskontakte angesprochen

97

werden. Ihr Vorhaben war es einerseits Verbesserungspotential für die Weiterentwicklung der

Software zu erhalten und andererseits Mundpropaganda für die SAP-Produkte aufzubauen.

Seit SAP R/2 verstärkte die SAP AG ihre Wechselwirkungen mit den Kunden noch durch die

Partnerstrategie. Die SAP-Software fasste mit ihrer modulweisen Konstruktion und den wei-

tergeführten Entwicklungen immer mehr Abteilungen, so dass sich nach und nach die vorläu-

figen Formalisierungslücken in den IT-anwendenden Unternehmen schlossen. Neben der Pro-

zessorientierung veränderte zunehmend auch die aufkommende Globalisierung die Anforde-

rungen der IT-anwendenden Organisationen und damit die SAP-Technikentwicklung.

Abb. 36: SAP-Technikentwicklungspfad - zweiter Zeitabschnitt: SAP R/3 (eigene Darstel-

lung)

Demzufolge setzte sich die SAP AG nun mehr verstärkt mit den veränderten Bedürfnissen auf

dem internationalen Markt auseinander. Die Gründung der Büros in den USA und Japan und

der 1989 im Ausland erzielte Umsatz sind Anzeichen dafür. Die gesellschaftlichen Leitbilder

und wirtschaftlichen Möglichkeiten beeinflussten zum einen die SAP AG als Unternehmen,

insofern überhaupt weltweit aktiv zu werden und zum anderen die IT-anwendenden Organisa-

tionen, als dass ihre Anfragen an die IT-Hersteller und damit an die SAP AG darauf ausge-

richtet waren. Trotz dieser globalen Neuausrichtung blieb die SAP AG ihren Strategien hin-

sichtlich der Kundennähe und ihren in der Software umgesetzten Leitbildern treu. So lag der

Schwerpunkt auch weiterhin auf dem Kundenkontakt und kundenorientiertem Informations-

austausch auf Messen, im Speziellen ihren eigenen Anwenderkonferenzen, der Entwicklung

beim Kunden, den Pilotprojekten und der zur Struktur geronnenen Partnerstrategie. Das Er-

98

gebnis dieser Wechselwirkungen zwischen der SAP AG und den IT-anwendenden Organisa-

tionen war die Lösung des Problems der eingeschränkten Rechnerkapazität bei Großrechnern

durch die Innovation SAP R/3. Prägnant für den Entwicklungsprozess des Systems SAP R/3

war, dass die SAP AG von Beginn an zweigleisig fuhr. Die Präsentation des Systems AS /400

von IBM löste zwar die Arbeiten an der Software SAP R/3 aus, die Entwicklung fand jedoch

zusätzlich auf den Unix-Systemen statt. Diese Planung sicherte die Entwicklung des Systems

SAP R/3 ab, was sich im Nachhinein als notwendig erwies, da die Umsetzung auf den AS

/400 bis zum Jahr 1997 benötigte. Die SAP AG konnte dank des Unix-Systems SAP R/3 be-

reits 1991 auf den deutschen Markt bringen und 1993 in den USA. Neben ihren gängigen Un-

ternehmensstrategien passten sie ihre Entscheidungen und Handlungen dem internationalen

Markt an, sie führten beispielsweise für die USA das provisionsbasierte Arbeiten ein. Die

ebenfalls für den US-amerikanischen Markt eingeführte Produktvorankündigung etablierte

sich sogar als generelle Maßnahme der Produkteinführung bei der SAP AG. Ein Wettbe-

werbsvorteil des Systems SAP R/3 bestand in der Übernahme und automatischen Verwirkli-

chung des Managementleitbildes MRP II aus der Fortführung der Idee einer integrierten Stan-

dardsoftware auf Basis SAP R/2. Damit entsprach SAP R/3 bereits Merkmalen des sich später

verbreiteten Managementleitbildes BPR, was zum weltweiten Verkaufsboom beitrug. Bei der

Erfüllung der daraus folgenden, erhöhten Anforderungen der Märkte halfen der SAP AG die

sich ausweitenden Partnerschaften, ihre Partnerstrategie. Parallel zu der Entwicklung SAP R/3

verläuft der Entwicklungspfad der Innovation Internet. Der erste Berührungspunkt auf dem

SAP-Technikentwicklungszeitstrahl mit dem Internet fand in BAPI die erste Umsetzung und

sorgte für weitere SAP-Softwareverbreitung. Das System SAP R/3 mit BAPI wurde zu einem

Werkzeug für die aufkommende Netzwerkidee und damit zum Medium der Wandlung zur

globalen Ökonomie und Netzwerkorganisation.

99

Abb. 37: SAP-Technikentwicklungspfad - dritter Zeitabschnitt: SAP Business Suite 7 und

Business byDesign (eigene Darstellung)

Der Weg hin zur Netzwerkgesellschaft kann unter zwei Perspektiven der SAP-Entwicklung

gesehen werden. Zum einen wirkte sich das Leitbild auf die SAP AG als Unternehmen aus.

Die Ereignisse 2000 und 2004 der Entwicklungslinie verweisen durch die Aufzählung der

Entwicklungsbüros auf die SAP AG als global integriertes Unternehmen. Zum anderen lag

auf der SAP-Softwareentwicklung die Erwartungshaltung der IT-anwendenden Organisatio-

nen unter Einfluss des Internets und des Netzwerkgedankens. Das Besondere daran äußert

sich bis heute in der Notwendigkeit einer höheren Geschwindigkeit in der IT-Entwicklung

und in den sich stetig verändernden Bedürfnissen. Die SAP-Software wurde so Ergebnis und

gleichzeitig Mittel der verstärkten Dynamik der SAP-Innovationsspirale. Die Schnelligkeit

der Wechselwirkungen zeigte sich im Hinblick auf die Software insofern, als dass in den Jah-

ren nach der Fertigstellung des Systems SAP R/3 auf dem Zeitstrahl wesentlich mehr Ent-

wicklungen61 in kürzerer Zeit begonnen und mehr kurz aufeinander folgende Ereignisse

sichtbar wurden sowie die Strategie Open Innovation zur zügigeren Wissensgenerierung ver-

folgt wurde. Diese schnellere Reaktion auf die Anforderungen von Organisationen, der Glo-

balisierung und der Netzwerkökonomie unterstützte diese rückkoppelnd und trieb zusätzlich

zum Internet die Innovationsspirale voran. Da die SAP AG dabei weiterhin auf ihre bewähr-

ten Strategien, insbesondere den Kundenschwerpunkt setzte, bestand die erhöhte Gefahr einer

zu kurzfristigen 61 Hier wird auf die Softwareentwicklung von Business Framework, New Dimension, Marktplatz, ESOA, SAP Business Suite 7 und Business byDesign hingewiesen.

100

Reaktion hinsichtlich einer Softwareentwicklung auf vielgedeutete Anforderungen ihrer Kun-

den. Nicht zuletzt aus diesem Grund verläuft der Entwicklungspfad New Dimension trotz

technischem Know-How auf der historischen Linie als ein Appendix ins Leere. Auffallend ist

in diesem Zusammenhang der Wechsel des SAP Leitbildes BPR zum Mehrproduktunterneh-

men innerhalb der Softwareentwicklung. Erst mit der Rückkehr zur integrierten Standard-

software und dem Nutzen des Wissens um die New Dimension bei der fortgeführten Entwick-

lung des Business Framework konnte der Erfolgsweg weiter beschritten werden. Angepasst

an die Internetzeit und ihrer gewonnenen Erfahrungen entstanden der Marktplatz (SCM und

CRM62 inklusive) und Netweaver zusammen mit Business Framework unter dem Namen

ESOA, verspätet aber noch rechtzeitig für den Marktpositionserhalt, als SAP Business Suite 7.

Ein sich wiederholendes Moment ist hier das Einbinden von Wissen aus Fehlentwicklungen,

wie den Pfad New Dimension, oder verschobenen Entwicklungen wie bei der Umsetzung auf

AS /400.

Was die SAP AG ebenfalls in diesem Zeitraum bis 2009 kennzeichnet, ist die Mehrgleisigkeit

von Produktentwicklungen63. So startete 2002 die Arbeit an Business byDesign, welche 2007

zwar angekündigt, aber nicht veröffentlicht wurde, da sie bis heute nicht fertig gestellt ist. Bei

der Entwicklung dieser Software stützt sich die SAP AG ebenfalls überwiegend auf ihre Stra-

tegien, wobei die Partnerstrategie aufgebrochen und die Anzahl der Beratungspartner mini-

miert werden. Des Weiteren wird hier erstmals lediglich ein Entwicklungspfad um das neue

Leitbild Cloud Computing ergänzt. Inwiefern sich dieses für Business byDesign als Leitbild

bestätigt oder sogar auf andere Produkte übertragen wird, zeigt sich in der Zukunft, ebenso

das Datum der Fertigstellung von Business byDesign und sein Markterfolg. Gleichfalls ist

offen, ob der Kauf von Business Objects 2008 zu einem zusätzlichen Mehrproduktpfad führt

und sich damit die Pluralität der Softwareentwicklung als Strategie der SAP AG durchsetzt.

Die SAP AG befindet sich auf dem Scheideweg zwischen einer reinen Konzentration auf ihre

Kernkompetenz der integrierten Standardsoftware und einem Mehrproduktunternehmen mit

etablierten Softwarepfaden unter Zukäufen kleiner Produktsegmente zwecks Anschluss an

den Markt. Die zweite Option ist entgegen der Entscheidung von 1996 aufgrund der Beibehal-

tung ihres Leitbildes BPR in ihrem Kernsegment SAP Business Suite 7 dieses Mal potentiell

erfolgsversprechender. Die SAP AG hat die Möglichkeit aus vergangenen Pfaden und Ap-

pendixen zu lernen. Die Bewertung von zukünftigen Handlungen und Entscheidungen der

SAP AG kann unter Einbezug des SAP-TEPs dahingehend erfolgen, dass sich hier die über

die Jahre erfolgreich aufgebauten und verfestigten Strategien und Leitbilder explizieren las-

sen, welche im engen Zusammenhang mit dem Erfolg oder Nichterfolg von IT-

Entwicklungen standen. Positiv bewährt haben sich in den vergangenen Jahren: BPR, Netz-

werkorganisation, Entwicklung beim Kunden, Messen, Pilotprojekt- und Partnerstrategie, Pro-

62 SCM und CRM sind die Best-of-Breed-Produkte, die mit BI in einem Kontext genannt werden können. 63 Verwiesen sei auf SAP Business Suite 7, Business byDesign und BI.

101

duktvorankündigungen und Open Innovation. Probleme haben sich im Betrachtungszeitraum

dann ergeben, wenn die SAP AG aus ihrer engen Kundenbindung heraus zu schnell auf

Trends am Markt reagiert hat und dabei ihr Leitbild der integrierten Standardsoftware in Fra-

ge gestellt hat oder verließ.

4.3.4.2 Der Techniknutzungspfad Büro

Die hier vorgenommene Beschreibung des TNP Büro von Arno Rolf gibt einen Überblick

über die Innovationen und damit über die Sieger der Technikentwicklung im Kontext der

Nutzung der IT für das Büro. Ich wähle diesen TNP exemplarisch aus, da die SAP-Software

zentral für diesen Nutzungskontext entwickelt wurde und deswegen sich hier Anknüpfungs-

punkte mit dem SAP-TEP finden lassen müssten. Die Beschreibung fasst zwar den TNP Büro

in einem Panoramaüberblick zusammen, versucht aber dennoch die wichtigsten Punkte für

spätere Analysen im Hinblick auf die Verbindung zum TEP herauszustellen.

Der TNP Büro befasst sich mit der arbeitsorganisatorischen Entwicklung vom Kontor hin zur

Netzwerkorganisation. Vor der Industrialisierung erledigten die Kaufleute ihre Büroarbeit

meist selbstorganisiert und unter geringer Arbeitsteilung in ihrem privaten Kontor. Bis dahin

war jeder für seinen Bereich zuständig. Erst durch die Mechanisierung des Büros wurden ge-

wisse Arbeitsaufgaben wie Schreibarbeiten von ihren bisherigen Bereichen getrennt. Zu die-

ser Zeit der industriellen Revolution entstanden große Fabriken und mit ihnen stieg die Ver-

waltungsarbeit. Simultan zu dieser Veränderung wandelte sich das Büro unter der Verwen-

dung des Leitbildes der wissenschaftlichen Betriebswirtschaft von Taylor zu einem Fließ-

bandbüro. Hier war die Arbeitsorganisation hochgradig arbeitsteilig und hierarchisch organi-

siert. Anspruchsvollere Kopfarbeit wurde von routinierter Tätigkeit getrennt. Diese Maßnah-

men bereiteten den Pfad zur Prozessorganisation der 90ger Jahre vor, der eine vollständige

Reorganisation der Arbeitsabläufe beinhaltete. Im Vordergrund stand nicht länger die Organi-

sation der Unternehmen nach hierarchischen Strukturen, sondern vielmehr nach Abläufen und

Prozessen. Diese Neustrukturierung nach so genannten Geschäftsprozessen bildete das popu-

läre Managementleitbild BPR zu Beginn der 90ger Jahren ab und wurde durch Softwareinno-

vationen ermöglicht. Das SAP-Büro steht beispielhaft für diesen Wechsel von der hierarchi-

schen zur prozessorientierten Organisation. Softwaresysteme übernahmen immer mehr auto-

matisierte Standardfälle, während Restarbeiten weiterhin von qualifizierteren Mitarbeitern

erledigt wurden. Die anfängliche Automatisierung einzelner Geschäftsprozesse erstreckte sich

später in Unternehmen über ganze Standardprozesse. Das sich darin wiederspiegelnde Leit-

bild der Prozessorientierung zielte zugleich auf die softwaretechnische Vernetzung von Pro-

zessen ab. Die damit verbundene, kontinuierliche Weiterentwicklung von IT eröffnete neue

Potentiale wie den Zugriff auf Daten von überall innerhalb einer Organisation und den Einbe-

zug von Lieferanten, Kunden und Behörden. Die Software SAP R/3 erfüllte diese Anforde-

102

rungen, „[…] die Integration der bislang noch getrennten betrieblichen Informationssysteme

durch entsprechende Softwaresysteme.“ (Rolf 2008, S. 46) und etablierte sich erfolgreich in

den Organisationen.

In den darauf folgenden Jahren weitete sich die Nutzung von PCs in Organisationen und in

Privathaushalten aus. Das Internet eroberte den Markt und band die Nutzer in ein weltweites

Netzwerk ein. Auf der Basis dieser entstandenen Infrastruktur und den von ihr bereitgestellten

Möglichkeiten änderten sich Arbeitskontexte und kulturelle Gegebenheiten, neue Organisati-

onsleitbilder und IT-Strategien formten sich und wurden zu Handlungsstrukturen. Die ehe-

mals hierarchiegesteuerten Abteilungen konnten nun neu strukturiert und als Arbeitsgruppen

um Geschäftsprozesse herum eingerichtet oder in Projekten organisiert werden. Auf der einen

Seite fand sich diejenige Arbeit, welche sich mit planenden und innovativen Aufgaben be-

schäftigte, die in Projekten organisiert und in Selbstorganisation mit Ergebnisvorgaben erar-

beitet wurden - innovative Projektmodule. Auf der anderen Seite stand die operative Tätigkeit

der Akteure, die für eine Abarbeitung der laufenden Geschäftsprozesse nötig war - operative

Module. Die auf der Modularisierung basierende Teilautonomie bestimmter Bereiche ermög-

lichte sowohl die interne Auslagerung spezieller Module ins Ausland als auch die externe in

andere Organisationen wie beispielsweise Call Center, Freelancer oder virtuelle Organisatio-

nen. Letztere entstanden durch die langsame Auflösung der festen Organisationsgrenzen. Das

jeweils benötigte Arbeitsaufkommen deckten sie kurzfristig über die potentiell am Markt ver-

fügbaren Mitarbeiter, zum Beispiel Leih- und Zeitarbeiter, ab. Die Arbeitnehmer wurden ge-

genüber verschiedenster Organisationen zum Anbieter ihrer Arbeitskraft und verzichteten auf

langfristige Sicherheiten. Eine weitere Handlungsstruktur war die Überwälzung der Routine-

arbeit auf den Kunden, dessen Einbeziehung als Mitarbeiter für Routinetätigkeiten von Orga-

nisationen und dessen direkte Anbindung an die Geschäftsprozesse. Diese Strategie des mit-

arbeitenden Kunden erfährt durch das kostenlose Abschöpfen von Kopfarbeit in Form von

Open Innovation, Crowdsourcing oder Wertschöpfungspartnerschaften seine weiteren Ausdif-

ferenzierungen. Hiermit ist die Bereitschaft einer großen Zahl von Kunden an der kostenlosen

Mitarbeit und innovativen Weiterentwicklung von Produkten gemeint. Die Verfügbarkeit von

PCs und Internet zu Hause ermöglichte den Organisationen neben der Mitarbeit von Kunden

die Ausweitung der Arbeit ihrer Mitarbeiter auf die private Zeit. Büroarbeit wurde aufgrund

knapper Arbeitsplätze, der Erwartung einer 24-Stunden-Bereitschaft und der Koordination

weltweiter Unternehmensprozesse über Zeitzonen hinweg draufgesattelt. Der TNP steuerte

auf die Vision der globalen Netzwerkorganisation zu. Die Organisationen wurden demnach in

weltweite Produktions- und Dienstleistungsnetzwerke eingebettet und als Kontenpunkte be-

zeichnet, welche durch IT-gestützte Geschäftsprozesse und Workflows verbunden waren.

Aufgrund ihrer offenen Strukturen konnten die Organisationen grenzenlos wachsen und

schnell neue Knotenpunkte einbinden oder überflüssige abschalten. Die IT bot für die Kno-

tenpunkte die Infrastruktur und das Internet durch die Überwindung von Raum und Zeit eine

weltweite Verknüpfungsmöglichkeit. Die Idee bezeichnet Arno Rolf ebenso als den Übergang

103

von der Industriegesellschaft zu der globalen Informations- oder Wissensgesellschaft. Diese

Entwicklung zur Wissensökonomie wurde begleitet und geprägt von den herrschenden Leit-

bildern und Strategien: Modularisierung, Automatisierung, Überwälzen, Verlagern und Ab-

schöpfen von Kopfarbeit.

Der TNP Büro darf allerdings nicht als lineare Chronologie unter einem Sachzwang oder

festgeschriebenen Nutzungslogik verstanden werden, da jederzeit andere Optionen in der

Entwicklung oder Risse möglich waren und auch in Zukunft möglich sind.

4.3.4.3 Die Schnittstellen zwischen dem SAP-Technikentwicklungspfad und dem Tech-

niknutzungspfad Büro

Da in der Komponente ‚Prozesse und Pfade‘ im Mikropolis-Modell bisher der Schwerpunkt

auf dem TNP und bezüglich SAP auf der SAP AG als Teil des TNP Büro lag und weniger

Arbeiten zum TEP vorliegen, bietet es sich an, den Fokus in den folgenden Überlegungen auf

die Erklärungspotentiale des SAP-TEPs für Technikentwicklungen in Gegenüberstellung zum

TNP Büro zu legen. Dabei stehen die Fragen im Vordergrund, welche Schnittstellen zwischen

den beiden genannten Pfaden zu finden sind und wie sich diese begründen lassen. Wo sie

voneinander differieren und wie sie dadurch möglicherweise an verschiedenen Punkten der

Betrachtung die Innovationsprozesse unterschiedlich fassen und darlegen.

Vergleicht man die Ausführungen zu den grundlegenden Ideen und beschriebenen Faktoren

im SAP-TEP und im TNP Büro stellt man fest, dass auf beiden Pfaden das System SAP R/3

der SAP AG eine elementare Rolle spielt. Im TNP Büro steht SAP R/3 für das SAP-Büro und

im TEP dient es als Basis für alle SAP-Technikentwicklungen seit 1991. In beiden Kontexten

wird die Entstehung von SAP R/3 mit dem Leitbild Prozessorientierung erklärt. Im TNP aus

der Sicht der Nutzung und im TEP aus den Anforderungen von Organisationen. Beide Per-

spektiven sind aus den Wechselwirkungen auf den Ebenen des Mikropolis-Modells ableitbar.

Während im TNP nur die Vorentwicklung SAP R/2 erwähnt und von technischen Vorausleis-

tungen gesprochen wird, ist im TEP der gesamte Technikentwicklungsablauf von MIAS über

SAP R, SAP R/2 hin zu SAP R/3 abgebildet und erläutert. Der TNP Büro verläuft vom SAP-

Büro weiter hin zur globalen Netzwerkorganisation. Das System SAP R/3 in Form der Client-

Server-Architektur und die SAP AG werden zwar als Wegbereiter dieses Pfades zur Wissens-

ökonomie aufgeführt, anschließend allerdings nicht weiter expliziert. In den weiteren Darstel-

lungen stehen dagegen Leitbilder und Strategien, die mit dem Einzug von PCs in Organisatio-

nen, Privathaushalten und der Innovation Internet einhergehen und der daraus resultierenden

Veränderung der Arbeitsorganisation. Verbindungen zum TEP lassen sich demzufolge mit der

Gegenüberstellung der verfolgten Strategien und Leitbildern ziehen. Inwieweit finden sich im

SAP-TEP das Verlagern, Überwälzen, Draufsatteln oder Abschöpfen von Arbeit? Die Strate-

gie des Verlagerns findet sich in der Partnerstrategie der SAP AG wieder, Arbeiten wie Soft-

wareweiterentwicklung, -vertrieb und -einführung werden an die Vertriebs-, Entwicklungs-,

104

Beratungs-, Technologie-, Hardwarepartner und das SAP-Systemhaus abgegeben. Parallelen

zum Überwälzen, Draufsatteln und Abschöpfen von Arbeit lassen sich zu den Unternehmens-

strategien der SAP AG hinsichtlich ihrer Softwareentwicklung ziehen. Die Idee des mitarbei-

tenden Kunden realisierte die SAP AG durch die Entwicklung beim Kunden und die Partner-

strategie. Hier erledigten die Kunden automatisch die Bedarfsermittlung der Softwareentwick-

lung und die Partner übernahmen als Kunden eigene weiterführende Programmierungen und

direkt den Vertrieb oder indirekt das Marketing in Form von kostenloser Werbung. Im Bezug

auf das Draufsatteln von Arbeit lagen mir keine Quellen vor, die Mitnahme der Büroarbeit

nach Hause nachgewiesen hätten. Ich vermute jedoch, dass im Rahmen eines expandierenden,

kostensparenden Unternehmens und der schwierigen Arbeitsmarktsituation für IT-Angestellte

unter den Softwaremöglichkeiten des Marktplatzes und des Internets Mehrarbeit durchaus

auftrat. Eine weitere potentielle Voraussetzung für Überstunden lag nach wie vor auch in dem

weltweiten Agieren der SAP AG, die aufgrund der verschiedenen Zeitzonen rund um die Uhr

präsent sein musste. Open Innovation erfolgte bei der SAP AG über den SAP Marktplatz. Die

genannten Leitbilder und Strategien, die sowohl im TNP Büro als demnach auch im SAP-TEP

als bestimmende Faktoren auftraten, zeichneten den Weg zu der globalen Netzwerkorganisa-

tion, dem die SAP AG mit ihrer Software ebenfalls folgte. Das Unternehmen spannt bis heute

sein Netz mittels Entwicklungsbüros, seiner Partnerstrategie und Open Innovation weltweit

auf. Zudem fördert SAP die Vernetzung der Gesellschaft, indem sie den Anforderungen durch

die Globalisierung und das Internet entspricht und Software entwickelt, die diese Prozesse

wiederum vorantreiben.

Die bis hierin explizierten Schnittstellen zwischen dem SAP-TEP und dem TNP Büro kom-

men in solchen Erklärungszusammenhängen vor, die auf den Ergebnissen der Prozesse inner-

halb der Ebenen des Mikropolis-Modells basieren. Die Parallelen zwischen den beiden Pfaden

liegen danach in der Qualität der Einflussnahme von Wechselwirkungen, gesteuert durch

Leitbilder, Strategien und gesellschaftliche Entwicklungen. Dies begründet sich darin, dass

die genannten Faktoren auf alle Organisationen im Mikrokontext wirkten sowohl unmittelbar

auf IT-Hersteller, in unserem Fall die SAP AG, als auch auf IT-anwendende Organisationen

oder indirekt auf erstere über die beeinflussten und dadurch veränderten Anforderungen der

Nutzer. Der SAP-TEP und der TNP Büro beschreiben zwar zwei verschiedene Sichtweisen

auf Technik, gehen aber vor dem Hintergrund des Mikropolis-Modells von den gleichen theo-

retischen Grundannahmen aus. So liegt zwar eher im TNP Büro der Schwerpunkt auf der

Nutzung von Technik in Organisationen, dennoch spielt im SAP-TEP die IT-Nutzung in Or-

ganisationen ebenfalls eine Rolle. Setzt man bei der SAP AG das Ziel, innovativ64, im Markt

präsent und gewinnmaximierend sein zu wollen, voraus, dann muss sich die SAP AG auch

nach seinen Kunden, den IT-Anwendern und deren Nutzungsvorstellungen richten. „Das war

64 Der Ex-SAP AG Chef Leo Apotheker äußerte in der Frankfurter Allgemeinen Zeitung: „In der Softwareindust-rie gibt es nur zwei Wege entweder man ist innovativ, oder man wird ein Wartungsunternehmen. Nicht innovativ zu sein, ist keine Option für uns.“ (Siegele 2009 S.246)

105

immer mein Credo“, äußerte sich einst Hopp: „ Hört denen zu! Wenn wir auftreten wie Zau-

berlehrlinge, dann erfahren wir nie, was die brauchen [nutzen].“ (Siegele 2009, S. 54)

Die Unterschiede der beiden Pfade liegen hingegen in dem Grad der untersuchten Fragestel-

lung und in deren jeweiligen Kontexten begründet. So untersucht der TNP Büro die Nutzung

jeder Technik eingegrenzt durch den bestimmten Kontext Büro hinsichtlich des bestimmten

Merkmales Veränderung der Arbeitsorganisation unter der allgemeinen Bezugsgröße globale

Wissensökonomie (mehrere Organisationen). Der SAP-TEP beschreibt dagegen die Entwick-

lung der Technik uneingeschränkt von einem bestimmten Kontext oder Merkmal, sondern nur

unter der speziellen Bezugsgröße SAP AG als ein IT-Hersteller (eine Organisation). Aus die-

sen unterschiedlichen Perspektiven und ihren Berührungspunkten ergibt sich für die SAP-

Technikbetrachtung ein weites Untersuchungsfeld.


Das Mikropolis-Modell vertritt folgende These: „Mit dem Mikro- und Makrokontext, der Per-

spektive auf Prozesse und Pfade und der Absicht der Rekultivierung von Wechselwirkungen

ist ein Rahmen vorhanden, mit dem die Phänomene Innovation und technischer Fortschritt

besser verstanden werden können.“ (Rolf 2008, S. 145) Die Ausführungen zur SAP-

Technikentwicklung stützen diese Annahme. Die Analyse der SAP-Technikentwicklung an-

hand des Mikropolis-Modells konnte die Innovationsprozesse verdeutlichen und hat alle ge-

nannten Faktoren aus der SAP-Softwareentwicklung unter Berücksichtigung der SAP AG in

einen Erklärungsrahmen eingebunden. Das Modell mit seinen drei Ebenen dient demnach

damit nicht nur der reinen Abbildung von Entwicklungsprozessen und ihren teilnehmenden

Akteuren, sondern ermöglicht den intensiven Einblick in die Ursachen-Wirkungs-Ketten um

die SAP-Technikentwicklung herum. Zur Illustration sind die Ergebnisse der Analyse aus

diesem Kapitel in der Grafik ‚SAP im Mikropolis-Modell‘ verallgemeinert und zusammenge-

fasst dargestellt. Die Abbildung erfüllt nicht den Anspruch auf Vollständigkeit, sondern kon-

zentriert sich auf die modellhafte Veranschaulichung der wesentlichen Akteure und Wech-

selwirkungen der Ebenen.

106

Abb. 38: SAP im Mikropolis-Modell (eigene Darstellung)

Die Erarbeitung des SAP-TEPs im Mikropolis-Modell führte zu einer umfassenden Schilde-

rung der verschiedenen Einflüsse auf und ihren Folgen für die SAP-Softwareentwicklung in

einem abgesteckten Zeitrahmen. Die aufgezeigten Wechselwirkungen zwischen der Gesell-

schaft, den Akteuren und der SAP AG zeigen und charakterisieren das Handlungsmilieu, in-

dem die SAP AG ihre Technik entwickeln konnte. Die historische Einbettung und deren Vi-

sualisierung mittels des Zeitstrahls stellten die erfolgreichen Leitbilder, Strategien und Inno-

vationen heraus, ebenso wie die nichterfolgreichen und Fehlentwicklungen. Der SAP-TEP

lässt zwar keine unmittelbaren Rückschlüsse auf den TNP Büro zu, bietet allerdings mit sei-

ner detaillierten Betrachtungsweise über die SAP AG und ihre Software eine Ergänzung zum

Nutzungspfad. Er kann aber auch für sich alleine stehen, um Technikentwicklung von Unter-

nehmen und ihren Bedingungen gründlich auszuführen. Die Anwendung des Mikropolis-

Modells auf die SAP-Softwareentwicklung unterstützte die zusätzliche Ausrichtung der Pro-

zesse und Pfade auf den TEP. Die soziotechnische Perspektive, der Mikro- und Makrokontext

erklärten und veranschaulichten die Wechselwirkungen im SAP-TEP. Zu Vertiefungszwe-

cken hat man demnach immer die Möglichkeit, die Analyse der Technikentwicklung pro Pro-

dukt statt nur auf der Ebene ‚Prozesse und Pfade‘ auch auf jeder der beiden anderen struktur-

gebenden Ebenen weiterzuverfolgen. Der SAP-TEP und die differenziertere Betrachtung auf

den Ebenen zeigten, dass die SAP AG unter dem Einfluss von globalen Leitbildern stand,

welche das Unternehmen selbst und die es umgebenden Akteure in ihren Interessen und

Handlungsentscheidungen prägten. Die Innovationsspirale fasste eben diese Interessen und

107

Anforderungen als Wechselwirkungen zwischen dem IT-Hersteller SAP AG und den anwen-

denden Organisationen. In diesem Zusammenhang konnte die Presse mit den success storys,

die Messen mit dem Kontakt zum Kunden, die Unternehmen als Träger durch die Pilotprojek-

te und die Einführungsprojekte, bei denen sich der Erfolg einer Software direkt im Unterneh-

menskontext zeigte, als Arenen identifiziert werden, in denen die SAP AG und die Akteure

miteinander agieren. Mithilfe der Betrachtung auf der soziotechnischen Ebene entstand ein

besseres Verständnis im Bezug auf die Vorgänge bei Programmierungen und auf die sich po-

tentiell anschließende Schließung einer Formalisierungslücke. Außerdem ließen sich Brüche

in der Technikentwicklung wie New Dimension besser kontextuell einordnen und verstehen.

Das war deshalb wichtig, weil aus den Prozessen und Pfaden des Mikropolis-Modells Hand-

lungsstrategien für zukünftige Innovationen abgeleitet werden sollten. So konnte auch der

SAP-TEP Rückschlüsse auf erfolgreiche Leitbilder und Strategien für zukünftige Technik-

entwicklungen nahe legen.

Neben diesen Vorteilen des Mikropolis-Modells besteht jedoch bei einem solch weitgesteck-

ten Orientierungsrahmen und Einflussmöglichkeiten auf Akteure auch die Gefahr, dass bei

fehlender Quellenlage eindeutige Rückschlüsse auf Wechselbeziehungen nur schwer, unzu-

reichend oder gar nicht möglich sind. Das stände der Erarbeitung eines TEP in seinen Ursa-

che-Wirkungs-Zusammenhängen auf den Ebenen der soziotechnischen Perspektive, Mikro-

und Makrokontext entgegen und verleitet gleichermaßen leichter zu Spekulationen.

108

5. Eine vergleichende Zusammenführung des Technikdeterminismus und

der Akteur-Netzwerk-Theorie mit dem Mikropolis-Modell

Vor dem Hintergrund der SAP-Technikentwicklung werden in diesem Kapitel die Ergebnisse

der Analysen auf Basis der sozialwissenschaftlichen Techniktheorien dahingehend ausgewer-

tet, inwiefern ihr Erklärungsgehalt keine, ähnliche oder neue Erkenntnisse für das Mikropolis-

Modell erschließen. Der Frage nach einer möglichen Einbindung oder Verbindung der sozial-

wissenschaftlichen Theorien mit dem Mikropolis-Modell wird in ersten Schritten nachgegan-

gen.

5.1 Technikdeterminismus und das Mikropolis-Modell

Wie in Kapitel 2 theoretisch beschrieben und in Kapitel 4 am Beispiel von SAP angewandt,

geht der Technikdeterminismus allgemein formuliert von einer Eigengesetzlichkeit der Tech-

nik aus. Diese beruht auf der angenommenen subversiven Kraft, die der Technik innewohnt.

Der Blick auf Technik vollzieht sich unter der Annahme, dass sich die Gesellschaft immer der

Technik anpasst, ob unmittelbar, etwas schwächer oder schwach und nie umgekehrt. Jene

Adaption löst das Handeln der Akteure aus, welches wiederum der etablierten Technik ent-

lang eines Korridors folgt. Im Bezug auf die SAP-Technik konnte deren Entwicklung und

speziell deren Wirkung auf die Gesellschaft in vielen Bereichen scheinbar unter den Prämis-

sen des Technikdeterminismus erklärt werden. Allerdings stellte man bei genauerer Analyse

fest, dass bestimmte Erfolgsfaktoren, Entscheidungen und Fehlentwicklungen der SAP-

Technikentwicklung in der Argumentation nach dem Technikdeterminismus außen vor ge-

blieben sind. Der Grund dafür liegt in der begrenzten Perspektive der Theorie: Technik als

Ursache und Wirkung. Den Akteuren wird im Technikdeterminismus von vornherein die un-

abhängige Handlungsmacht abgesprochen. Fragen hinsichtlich der Einflussnahme von Akteu-

ren und Gesellschaft bleiben unbeantwortet. Deshalb schlossen sich in der Untersuchung be-

stimmte Erklärungslücken nicht beziehungsweise wurde die Möglichkeit verwehrt, den Hori-

zont zu erweitern und mal aus einer anderen Sichtweise das Erklärungspotential zuzulassen.

Eben diese fehlende Auseinandersetzung mit weiteren möglichen Ursachen und Funktionen

bestimmter Entwicklungsprozesse, -strategien und Leitbilder vermag das Mikropolis-Modell

zu erfüllen oder zumindest erfüllen zu wollen. Es ist entgegen des Technikdeterminismus we-

niger beschränkt, sondern stellt einen offenen Analyserahmen zur Verfügung. Das Mikropo-

lis-Modell ist demnach nicht auf die Eigengesetzlichkeit der Technik wie beim Technikde-

terminismus begrenzt. Es umfasst ebenfalls die Akteurs- und Gesellschaftsinteressen. Die

Theorie geht noch einen Schritt weiter und nimmt, statt einseitigem Determinismus, Wech-

selwirkungen als Ursache für Technikentwicklung an. Zwar spricht auch das Mikropolis-

Modell von Strukturen, in denen sich Akteure bewegen und von vorhandenen, einschränken-

den Technikmöglichkeiten, allerdings sind Prozesse hier umkehrbar oder veränderbar durch

Aufbruch der Strukturen und verlaufen nicht in einem starren Konstruktionskorridor. Eine

109

eindeutige Antwort auf die Frage, ob der Technikdeterminismus als gewinnbringende Theorie

in das Mikropolis-Modell einfließen kann, ist schwierig zu geben. Zum einen findet sich die

Eigengesetzlichkeit der Technik in bestimmter Form in den theoretischen Formulierungen des

Mikropolis-Modells - speziell die Formalisierung und Algorithmisierung ist ohne Technik

nicht denkbar und von den jeweiligen Möglichkeiten der Technik abhängig. Außerdem gibt es

Technikentwicklungen, die sich vorwiegend aufgrund von vorheriger Technik und deren

Wirkung auf IT-Hersteller entwickeln. Im Beispiel von SAP können alle Softwarevorentwick-

lungen zu MIAS und viele Entwicklungen um das Internet aus diesem Blickwinkel erklärt

werden. Zum anderen verstellt eine solch enge Sichtweise den Weg zu den Annahmen im

Mikropolis-Modell, welches mehr Fragen an die Umstände von IT-Entwicklungen stellt. Geht

man von der Schwerpunktsetzung hinsichtlich der Ursachen- und Wirkungsbestimmungen

aus, wären beide Theorien nicht miteinander vereinbar. Lediglich ein Öffnen des Technikde-

terminismus in Richtung der Akteurssicht könnte diese Trennung aufweichen. Aus Sicht des

Mikropolis-Modells bestehen zum Technikdeterminismus wenige Verknüpfungspunkte. Al-

lerdings kann die Annahme einer subversiven Kraft der Technik der Anwendung des Mikro-

polis-Modells insoweit nützlich sein, als dass sie den Fokus auf die Akteure immer wieder in

Frage stellt und anstößt sich mit Machtverhältnissen, ob durch Technik- oder Marktmacht,

auseinander zu setzen. Die Verwendung des Technikdeterminismus beziehungsweise viel-

mehr die Erklärungslücken bieten gute Ansatzpunkte für Fragen nach Bedingungen für Fakto-

ren, Strategien, Leitbilder und Fehlentwicklungen, mit denen sich das Mikropolis-Modell be-

sonders auseinander setzen könnte.

Vor dem Hintergrund dieser Überlegungen halte ich eine vollständige Integration des Tech-

nikdeterminismus in das Mikropolis-Modell für nur schwer möglich, eher eine kontinuierliche

Gegenüberstellung und gegenseitige Hinterfragung für konstruktiver und gewinnbringender

hinsichtlich von Ursachen und Wirkungen der Technikentwicklungen.

5.2 Akteur-Netzwerk-Theorie und das Mikropolis-Modell

Das Mikropolis-Modell definiert sich selbst als einen Orientierungsrahmen und stellt nicht

den Anspruch an eine geschlossene Theorie. Es können jederzeit neue Ansätze und Ideen da-

rin aufgenommen werden, solange sie zum Erklärungsgehalt beitragen und die Grundannah-

men mittragen (vgl. Rolf 2008, S. 26). Im Zusammenhang mit dieser Arbeit stellt sich zuletzt

noch die Frage, ob die Übersetzung der ANT in bestimmten Punkten die Aussagen des Mik-

ropolis-Modells erweitern und möglicherweise sogar als Teil in dieses aufgenommen werden

kann. Im Vergleich zum Technikdeterminismus liegt der Fokus im Modell der Übersetzung,

als Teil der ANT, nicht auf dem Determinismus von Technik, sondern auf den Handlungen

von Akteuren, die Technikentwicklungen anstoßen oder vorantreiben. Diese These findet sich

ebenso im Mikropolis-Modell wie der ähnliche Gedanke, dass Akteure in Netzwerke einge-

bunden sind und darüber erfolgreich überzeugen, wobei im Mikropolis-Modell von Wechsel-

110

wirkungen gesprochen wird. Ob dadurch die Voraussetzungen gegeben sind, beide Theorien

miteinander zu verschmelzen, kann nur der folgende Vergleich klären. Dabei wird die ANT

mit der Übersetzung aufgebrochen und ansatzweise im Detail mit dem Mikropolis-Modell in

Verbindung gebracht. Die Übersetzung mit ihren fünf Phasen wird den drei strukturgebenden

Ebenen des Mikropolis-Modells ebenso gegenübergestellt wie die menschlichen und nicht-

menschlichen Akteure der ANT mit den Akteuren des Mikropolis-Modells.

In die Technikentwicklung der SAP AG sind vor dem Hintergrund des Mikropolis-Modells

der IT-Hersteller SAP AG, die anwendenden Organisationen und Partner als Akteure invol-

viert. In der ANT spricht man vom Hybrid-Akteur SAP, da das Handeln sowohl abhängig von

dem Unternehmen SAP AG als auch dessen Software ist, von den Akteuren ‚Unternehmen‘,

‚Leitbilder‘ und ‚Partner‘, die jeweils weitere Akteure in das Netzwerk ziehen können. Inter-

pretiert man den Begriff Hybrid-Akteur so, als dass Einflüsse auf das Unternehmen SAP AG

sich auch auf die Entwicklung der SAP-Software auswirken können, wiederspricht er nicht

den Annahmen des Mikropolis-Modells. Die von mir übertragene Definition des nicht-

menschlichen Akteurs auf Leitbilder stand nicht nur in Kapitel 4 zur Diskussion, sondern

auch hier im Vergleich zum Mikropolis-Modell. Dieses schließt theoretisch nicht-

menschliche Akteure, Gegenstände und Ideen aus. Allerdings fließen die Leitbilder und gege-

bene Technikstrukturen über den Weg des Mikro- und Makrokontextes als Entscheidungsfak-

toren in die Interessen der menschlichen Akteure ein und finden eine vergleichbare Bedeu-

tung im Einfluss auf Technikentwicklung wie in der ANT.

Die strukturierte Sammlung und Auflistung aller an einer Technikentwicklung beteiligten

Akteure kann für den Analysierenden hilfreich sein und für das Mikropolis-Modell gewinn-

bringend, da über offensichtliche Wechselwirkungen hinausgehend neue Zusammenhänge

entdeckt werden können (vgl. Drews 2009 S. 3726). Die Übersetzung mit ihren fünf Phasen

ist zwar in ihrem Wortlaut noch nicht im Mikropolis-Modell vorhanden, dennoch umfassen

die einzelnen Ebenen vielfach schon die theoretischen Überlegungen und Inhalte. Die sozio-

technische Perspektive bezieht sich unter anderem mit auf die Rekontextualisierung und der

Mikrokontext beschreibt die Wechselwirkungen zwischen den Anforderungen der IT-

anwendenden Organisationen und der SAP AG. Diese Vorgehen lassen sich vergleichend

auch mittels Übersetzung beschreiben. In der Phase der Problematisierung werden die Bedin-

gungen und Anforderungen der Akteure definiert, welche so gut erfüllt sein sollten, dass sich

IT-anwendende Unternehmen für eine Software entscheiden und dementsprechend durch den

OPP gehen. Für die Erreichung des Ziels können verschiedene Strategien, zum Beispiel Ent-

wicklung beim Kunden, wie in der Phase des Interessment angewandt werden, um in der Are-

na der Unternehmenssoftware das Enrolment zu vollziehen und die Software erfolgreich zu

vermarkten (Mobilisierung). Diese Schritte finden sich ähnlich in der Innovationsspirale wie-

der. Das Wechselspiel aus technology push und demand pull kann durch die Phasen der Über-

setzung gefasst werden und verdeutlicht erneut die Verbindung zwischen den Akteuren,

111

vergleichbar mit dem Netzwerk der ANT. Die Problematisierung ist die Definition der Ak-

teure in Informatiksystem und in die IT-anwendenden Unternehmen. Um aus einer Software

eine Innovation zu machen, muss der IT-Hersteller im Mikropolis-Modell verschiedenste

Handlungen unternehmen und Strategien verfolgen. Diese lassen sich in das Interessment der

Übersetzung einordnen, welche das Beobachten und Aushandeln bis hin zum Manipulieren

beschreibt. Der Ort der Aushandlung und Kämpfe der Akteure kann sowohl mit dem Begriff

Arena als auch mit dem des Enrolment beschrieben werden. Die sich im TNP und TEP abbil-

denden Innovationen benennt die Mobilisierung ebenfalls als am Markt angenommene und

genutzte Software. Die Akteure haben sich für ein Produkt beziehungsweise den dazugehöri-

gen Akteur entschieden und gehen mit ihm ein Netzwerk ein, stehen mit ihm in Verbindung.

In der akteursbezogenen Innovationsspirale laufen die Entwicklungen unter guten Bedingun-

gen kontinuierlich weiter, wobei sie sich ebenso verlangsamen als auch zum Stillstand kom-

men können. Diese Möglichkeit aus der allgemeinen, weltweiten Innovationsspirale des

Marktes herauszufallen, hat in der Übersetzung den Namen Dissidenz. Die Ebene des Makro-

kontextes findet sich zwar so nicht in der Übersetzung, geht man allerdings von den Wech-

selwirkungen zwischen der Umwelt und den Akteuren aus, findet sich auch dieser Einfluss in

der ANT als veränderte oder bestätigte Interessen aller Agierenden wieder. Die Gesellschaft

und ihre Leitbilder wären demnach in der ANT über die geprägten Interessen der Akteure

berücksichtigt. Analog zu der zeitlichen Betrachtung des SAP-TEPs von IT-Entwicklungen,

deren Ereignissen, Strategien und Leitbildern ließen sich auch mittels der Phasen der Überset-

zung einzelne Pfade der Technikentwicklung beschreiben und erklären. Die Ausführungen

bezögen sich vor allem auf den Mikro- und nur indirekt über die Akteure auf den Makrokon-

text. Mit der Unterteilung in fünf Phasen wäre allerdings ein höherer Arbeitsaufwand verbun-

den und speziellere Quellen als Beleg notwendig, aber auch eine umfassende und tief greifen-

de Beurteilung möglich. Die in der ANT betrachteten Handlungen von Akteuren sind auch im

Mikropolis-Modell Gegenstand der Untersuchung und ähnlich charakterisiert, worin eine we-

sentliche Gemeinsamkeit zwischen den Theorien besteht. Insofern kann die Übersetzung als

methodisches Vorgehen bei der Fassung und Beschreibung der Wechselwirkungen herange-

zogen werden und durch deren Strukturierung detailliertere Erklärungsmöglichkeiten eröff-

nen. Es ist allerdings darauf zu achten, dass der freie Orientierungsrahmen des Mikropolis-

Modells durch diese Phasenstruktur nicht eingeschränkt wird und der Blick für das Handeln

der Akteure auf Basis von Handlungsstrukturen und Technik nicht verloren geht. Ebenso ver-

hält es sich mit der differenzierten Auseinandersetzung im Makrokontext und den explizit

genannten Wechselwirkungen mit der Gesellschaft, die erst die Betrachtung der IT-

Entwicklung und -Nutzung über die Zeit verständlicher erscheinen lassen und dadurch den

TEP und den TNP ermöglichen. Nach den hier entwickelten und beschriebenen Ausführungen

steht der detaillierten Auseinandersetzung der SAP-Technikentwicklung mittels der Überset-

zung im Mikropolis-Modell, speziell in Kontexten mit und über Akteure, nichts entgegen.

112

6. Schlussfolgerungen und offene Fragen

Die Untersuchung der SAP AG und ihrer Software anhand zweier sozialwissenschaftlicher

Techniktheorien und schwerpunktmäßig des Mikropolis-Modells hat den Blick auf die SAP-

Technikentwicklung aus der technikdeterminierten Perspektive sowie aus der akteurs- und

strukturorientierten eröffnet. Die zu Beginn dieser Arbeit gestellten Fragen nach dem jeweili-

gen Erklärungspotential der Ansätze für die SAP-Softwareentwicklung wurden aus differen-

zierter Sichtweise erörtert und beantwortet. Der Technikdeterminismus lieferte anfangs ein

scheinbar hohes Erklärungspotential mit eindeutiger Ursachenbestimmung. Doch die bei der

Anwendung der Theorie vermehrt auftretenden Brüche und Lücken verwiesen nach und nach

auf fehlende Argumentationsmöglichkeiten für bestimmte Prozesse, Strategien und Leitbilder.

In Gegenüberstellung zur ANT und dem Mikropolis-Modell konnte herausgestellt werden,

dass der Fokus auf Technik als Ursache und Wirkung für gesellschaftliche Veränderungen

und Handlungen den Akteur als Handlungsträger ausschloss. Die Akteure als handelnde und

einflussnehmende Faktoren bleiben im Technikdeterminismus unberücksichtigt, was den Er-

klärungsgrad stark vereinfacht und bestimmte kausale Zusammenhänge und Folgen vor-

schnell und ohne Gegenprüfung einander zuordnet. Außerdem vernachlässigt der Fokus auf

die Wirkung von Technik den Blick auf die Technikentstehung mit ihren unterschiedlichen

Intensionen, Formen und kleineren Folgen, sowie auf Fehlentwicklungen und Fehlentschei-

dungen. Ebenso bleibt die Theorie die Antwort auf die Frage, woher die Wirkung der Technik

kommt, schuldig. Trotzdem ist sie, meiner Meinung nach, in der Analyse der SAP-

Technikentwicklung nicht zu vernachlässigen, da bestimmte Handlungen nur entlang der vor-

handenen Technik möglich sind und Technik gerade in Zeiten der Globalisierung und des

Internets ein starkes Medium ist. Entgegen dem Technikdeterminismus traten bei der Anwen-

dung der Übersetzung aus der ANT weniger Brüche in den Erklärungsmustern zur SAP-

Technikentwicklung auf. Hier lag der Fokus auf den Handlungskompetenzen selbst bestimm-

ter Akteure in Vernetzung miteinander. IT-Pfade wie New Dimension, die ins Leere liefen,

konnten nun aufgrund der angenommenen Veränderbarkeit von und Rückkopplungen in Pro-

zessen erklärt werden. Das Fünf-Phasenmodell konnte die handelnde SAP und ihr Netzwerk

sehr gut fassen und ebenfalls Aufschluss über den Hybridcharakter der SAP AG und der SAP-

Software geben. Dennoch blieb im Vergleich zum Mikropolis-Modell das Gefühl, einer feh-

lenden historischen Basis, bestehen. Die gesellschaftliche und die ökonomische Entwicklung

werden in der Übersetzung nicht expliziert, sondern sind höchstens über die Interessen der

Akteure zu erfragen oder zu vermuten. Dieser Spielraum für Spekulationen und Annahmen

erschwerte diese wissenschaftliche Untersuchung. Im Zusammenhang mit der SAP-

Technikentwicklung konnte mit Hilfe der Übersetzung zwar deren Verlauf nachvollzogen,

jedoch nicht die Frage, was IT-Innovationen ausmacht (Formalisierungslücken), ausreichend

beantwortet werden. Der Bereich Dekontextualisierung und Programmierung aus dem Mikro-

polis-Modell bleibt in der ANT vernachlässigt. In Kapitel 5 wurden erste Überlegungen un-

113

ternommen, ob und wie diese Theorie für das Mikropolis-Modell konstruktiv genutzt werden

kann. Diese Verknüpfung ist aufgrund des Kriteriums ‘offenes System‘ im Mikropolis-

Modell gegeben, welches dadurch anderen Ansätzen aufgeschlossen gegenübersteht. Das

Mikropolis-Modell bietet gerade auch deshalb einen umfangreicheren Analyserahmen und

führt in Richtung einer detaillierten Argumentation von Ursache- und Wirkungsbeziehungen

hinsichtlich der IT-Entwicklungen. Die SAP-Technikentwicklung zeichnete sich in den

Wechselwirkungen auf den Ebenen der ‚soziotechnischen Perspektive‘, des ‚Mikro- und

Makrokontextes‘ und der ‚Prozesse und Pfade‘ ab und konnte in einem SAP-TEP dargestellt

werden. Der SAP-TEP und seine Visualisierung zeigten die erfolgreichen und untergegange-

nen IT-Entwicklungspfade in einem sozialen und technischen Rahmen. Diese Auseinander-

setzung mit dem bisher im Hintergrund gebliebenen TEP verweist auf ein einladendes For-

schungsfeld, das viele Erklärungspotentiale inne hat, zumal er bei gleicher Kontextbestim-

mung (Gesellschaft, Leitbilder und Akteure) in enger Verbindung zu dem TNP steht. Insge-

samt war die Analyse der SAP-Technikentwicklung auf Grundlage des Mikropolis-Modells

vor dem Hintergrund meiner Zielsetzung insofern erfolgreich, als dass für die SAP-

Technikentwicklung vor allem im TEP Strategien und Leitbilder expliziert werden konnten,

die als Faktoren das unterstützende Potential für weitere Innovationen bergen. Nicht zuletzt

deshalb besitzt der TEP nicht nur als Ergänzung zum TNP seine Existenzberechtigung, son-

dern für sich stehend als aufschlussreiches Untersuchungsgebiet. Des Weiteren konnten Ge-

meinsamkeiten und Unterschiede in der Beurteilung der SAP-Technikentwicklung durch die

Theorien erarbeitet werden, auf Basis derer ich eine Verknüpfung der Ansätze in ersten Zügen

prüfen und abwägen konnte.

Die Anwendung einzelner Parameter innerhalb der jeweiligen Theorie war nicht zu jeder Zeit

eindeutig und umgehend vorzunehmen. So verleitet das Ausblenden des Akteurs im Technik-

determinismus zu schnellen Erklärungsmustern unter dem Aspekt einer subversiven Kraft der

Technik und damit dazu, Reflexionen sowie andere mögliche Ansichten als Beweisführung

unzureichend oder gar nicht zu prüfen. Ebenso führte die Konzentration auf die Wirkung von

Technik zu fehlenden Erklärungsmustern für die Bedingungen und Einflussfaktoren der

Technikentwicklung. Die Schwierigkeit bei der Übersetzung betrifft die Definition des nicht-

menschlichen Akteurs und dessen Übertragung auf die SAP-Technikentwicklung. Der Ver-

such Leitbilder als solche zu charakterisieren, stellte sich in der Argumentationslinie als

schwierig durchzuhalten heraus, da mir in diesem Fall die Trennung zwischen dem nicht-

menschlichen Hybrid-Akteur ‚Leitbild‘ und den Interessen der Akteure nicht eindeutig genug

zu ziehen war. Deshalb ist zu fragen, inwieweit die Bestimmung von Leitbildern als Hybrid-

Akteur sinnvoll ist oder ob ihre Erfassung nicht leichter über die Interessen der anderen Ak-

teure des Netzwerkes hätte erfolgen sollen. Diese Überlegung bietet Spielraum für weitere

Überprüfungen von nicht-menschlichen Akteuren in der ANT. Alle menschlichen Akteure

mit ihren jeweiligen Interessen konnten dagegen einfacher klassifiziert werden, wobei die

Ursachen ihrer Ideen und Handlungen in der Übersetzung weniger betont sind und sich je

114

nach Quellenlage als schwierig herauszufinden erweisen. Je länger dabei ein Untersuchungs-

gegenstand oder ein Zustand her ist, desto komplizierter dürften sich persönliche Tendenzen

und Sympathien nachweisen lassen beziehungsweise ist der Manipulationsfaktor mächtiger

Akteure bei der Quellenlage und damit eine Verzerrung der Netzwerkinformationen nicht

auszuschließen. Die Eingliederung der IT-Entwicklung in das Phasenmodell auf der vorher

erarbeitenden theoretischen Basis verlief dagegen ohne größere Probleme. Nur der strukturel-

le Aufbau der Arbeit nach den ANT-Übersetzungsphasen gestaltete sich deshalb nicht ein-

fach, als dass ein mehrfach angewandter Phasenablauf Wiederholungsgefahren barg und da-

mit Eintönigkeit für den Leser. Um diesen nicht zusätzlich zu verwirren, muss man aufgrund

der möglichen Anwendung der Theorie auf jeder Ebene einer IT-Entwicklung für die jeweili-

ge Untersuchung gezielte Fragen formulieren und den Zoomfaktor festlegen. Diese Anforde-

rung stellt sich ebenfalls an das Mikropolis-Modell, welches durch seinen offenen und weit

gesteckten Rahmen über drei Ebenen ansonsten zu viele Möglichkeiten der Analyse in einer

solchen Arbeit wie dieser bietet. Die SAP AG und ihre Software konnten sehr gut in die

Wechselwirkungen auf allen Ebenen eingebunden und durch sie erklärt werden. Einzig die

klare Trennung zwischen den Ebenen, speziell zwischen der soziotechnischen Perspektive

und dem Mikrokontext, konnte nicht immer eindeutig gezogen werden. So sind die Rück-

kopplungen bei der Rekontextualisierung gleichfalls beobachtete Anforderungen IT-

anwendender Organisationen im Mikrokontext. Wiederholungen sind bei formal abgegrenzter

Betrachtung der Ebenen deshalb nicht auszuschließen, insbesondere bei der Erstellung eines

TEPs, der die Technikentwicklung im Zeitablauf auf Basis der Wechselwirkungen anhand der

anderen Ebenen beschreibt. Ähnlich wie bei der ANT habe ich festgestellt, dass bei fehlenden

Primärquellen der Weg zu eigenen Schlussfolgerungen und Interpretationen leicht zu begehen

ist. Im Hinblick auf die theoretischen Grundannahmen hätte mir eine ausführlichere Definiti-

on von Projekten und Arenen weitergeholfen, ebenso wie eine differenziertere theoretische

Auseinandersetzung mit den Prämissen eines TNPs im Unterschied zu einem TEP. Diese für

mich vorher unbefriedigende Grenzziehung entfaltete sich zu einem Anspruch innerhalb die-

ser Arbeit, dessen Verfestigung und Erweiterung noch zukünftiger Überlegungen bedarf.

Insgesamt beantwortet auch diese Untersuchung nicht nur Fragen, sondern wirft ebenfalls

neue auf: Lässt sich der von mir erstellte SAP-TEP auch auf andere IT-Hersteller in der Form

anwenden? Bestätigen sich meine Gedanken zur Verknüpfung der ANT und des Mikropolis-

Modells in Zukunft auch in anderen Kontexten als die der SAP-Technikentwicklung? Wie

umgeht oder löst man den Widerspruch, der einer 1:1 Verschmelzung des Mikropolis-Modells

mit der ANT bei der The Duality of Technology von Orlikowski und der symmetrischen Anth-

ropologie der ANT entgegensteht? Oder sollte man in diesem Zusammenhang vielmehr von

einer Verknüpfung der Theorien sprechen und auf die Betonung von Gemeinsamkeiten abzie-

len? Oder bezieht man lediglich die Begrifflichkeiten des Phasenmodells als Strukturwerk-

zeug in das Mikropolis-Modell mit ein? Diese Überlegungen zeigen, dass die Auseinanderset-

zungen mit dem TEP und mit einer potentiellen Verknüpfung der Übersetzung aus der ANT

115

mit dem Mikropolis-Modell zwei bisher wenig bearbeitete Forschungsfelder weiter geöffnet

haben.

Abschließend möchte ich noch einmal auf die Aussage von Hasso Plattner zurückkommen:

“When people ask how we planned all this, we answer ‘We didn’t. It just happened.’ ”

(Campbell-Kelly 2003, S. 191). Vor dem Hintergrund meiner Arbeit und ihren Ergebnissen

würde ich Plattner dahingehend interpretieren, dass er damit nicht gemeint haben kann, ohne

Plan gearbeitet zu haben und dem Zufall die Erfolgsgeschichte der SAP AG zuzuschreiben.

Vielmehr steckt für mich in der Äußerung der Verweis auf die erarbeiteten komplexen Ursa-

che-und-Wirkungsbeziehungen der Technikentwicklung mit ihren Bedingungen, die eine au-

tonome Planung seitens der SAP AG nicht zugelassen hätten. Ebenso erinnert ‘es sei einfach

alles passiert‘ daran, dass zum Weg hin zu einer Innovation immer auch Glück gehört bezie-

hungsweise glückliche Umstände, ob menschliche oder nicht-menschliche, ob Akteure oder

Gesellschaft. Allerdings erreichte SAP seinen Durchbruch und Gewinn nicht durch passives

Zuschauen, sondern durch aktives Handeln mittels Erfolgsfaktoren, Strategien und Leitbilder

und verhalf sich damit oft selbst zum Glück.

116

Literaturverzeichnis

Abts und Mülder 2002

Abts, D., Mülder, W.: Grundkurs Wirtschaftsinformatik. Eine kompakte und praxis-

orientierte Einführung. Braunschweig: Vieweg. 4. Auflage 2002.ISBN:3-528-35503-4

AMR Research 2007

Jacobson, S., et al.: The ERP Market Sizing Report, 2006-2011. AMR Research, ERP

2007 Market Sizing Series, Market Service Report,

http://www.gtm.sap.com/solutions/business-

suite/erp/pdf/AMR_ERP_Market_Sizing_2006-2011.pdf besucht am 24.01.2010

von Arb 1997

von Arb, R. C.: Vorgehensweisen und Erfahrungen bei der Einführung von Enterpri-

se-Management-Systemen dargestellt am Beispiel von SAP R/3. Bern: Dissertation.

1997. www.stub.unibe.ch/download/eldiss/98arb_r.pdf besucht am 14.03.2010.

Bammé 2009

Bammé, A.: Science and Technology – Ein Überblick Marburg: Metropolis-Verlag.

2009. ISBN 978-3-89518-754-4.

Bär 2001

Bär, M.: Projektmanagement bei der konzernweiten Einführung eines betriebswirt-

schaftlichen Standardanwendungssystems. Mannheim: Dissertation. 2001.

Bijker et al. 1987

Bijker, W.E., Hughes, T.P., Pinch, T.: The Social Construction of Technological Sys-

tems: New Directions in the Sociology and History of Technology. England: London.

Cambridge Massachusetts. The MIT Press. 1987. ISBN 0-262-52137-7.

Braverman 1977

Braverman, H.: Die Arbeit im modernen Produktionsprozeß. Frankfurt a.M. – New

York: Campus Verlag. 1977. ISBN: 3-593-32225-0.

117

Brödner et al. 2002

Brödner, P., Seim, K., Wohland, G.: Skizze einer Theorie der Informatik-

Anwendungen. Bad Hersfeld: 2. Arbeitstagung zur Theorie der Informatik 2002.

http://tal.cs.tu-berlin.de/siefkes/Hersfeld/HeffAG_Wohland_Bericht_15.11.02.pdf be-

sucht am 23.06.2010.

Buxmann und König 1997

Buxmann, P., König, W.: Empirische Ergebnisse zum Einsatz der betrieblichen Stan-

dardsoftware SAP R/3, In: Wirtschaftsinformatik, 39(4). 1997. S. 331-338.

Callon 1996

Callon, M.: Einige Elemente einer Soziologie der Übersetzung: Die Domestikation der

Kammmuscheln und der Fischer der St. Brieuc-Bucht. In: Bellinger, A.: AnThologie:

Ein Einführendes Handbuch zur Akteur Netzwerk Theorie. Bielefeld: transcript Ver-

lag. 1996. ISBN: 3-89942-479-4.

Campbell-Kelly 2003

Campbell-Kelly, M.: From airline reservations to Sonic the Hedgehog: a history of

the software industry. Cambridge. Massachusetts: The MIT Press. 2003. ISBN: 0-262-

03303-8.

Castells 2001

Castells, M.: Der Aufstieg der Netzwerkgesellschaft: Teil der Trilogie Das Informati-

onszeitalter. Leske + Budrich. Opladen. 2001. ISBN: 3-8100-3223-9.

Collins 1985

Collins, H. M.: Changing order: replication and induction in scientific practice. Lon-

don: Sage. 1985. ISBN: 0-8039-9757-4.

Collins 1999

Collins, H. M.: Der Golem der Forschung: Wie die Wissenschaft die Natur erfindet.

Berlin: Berliner Verlag. 1999. ISBN: 3-8270-0334-2.

Computerwoche 1991a

Computerwoche: Vom 370-Standard zu offenen Systemen – SAP auf Unix-Kurs.

03.05.1991. http://www.computerwoche.de/heftarchiv/1991/18/1139650/ besucht am

30.06.2010.

118

Computerwoche 1991b

Computerwoche: Kritik an SAP: Kunden von Beratern abhängig. 31.08.1991.

http://www.computerwoche.de/heftarchiv/1990/35/1147364/ besucht am 23.05.2010.

Computerwoche 2007

Computerwoche: Analyse: SAP verlässt den Pfad der Tugend. 09.10.2007.

http://www.computerwoche.de/software/bi-ecm/555407/index.html besucht am

13.04.2010.

Computerwoche 2010

Computerwoche: SAP-Partnerstatus – wichtig oder unwichtig? 17.03.2010.

http://www.computerwoche.de/management/it-strategie/1932050/ besucht am

18.03.2010.

Degele 2002

Degele, N.: Einführung in die Techniksoziologie. München: Fink Verlag. 2002. ISBN:

3-8252-2288-8.

DIN 69901

Deutsches Institut für Normung 69901: Projektmanagement: Netzplantechnik und

Projektmanagementsysteme; Normen. Berlin: Beuth. 2009. Taschenbuch 472. ISBN:

978-3-410-17818-7.

Drews 2009

Drews, P.: IT-Beratung zwischen transdisziplinärer Forschung und Praxis – Ein

Orientierungsrahmen. In: Fischer, S. et al.: GI Jahrestagung - Informatik 2009: Im

Focus das Leben, Beiträge der 39. Jahrestagung der Gesellschaft für Informatik e.V.

Lübeck: Proceedings. GI. Serie LNI. Volume 154. 2009. S. 3715-3729. ISBN: 978-3-

88579-248-2.

Giddens 1997

Giddens, A.: Die Konstitution der Gesellschaft: Grundzüge einer Theorie der Struktu-

rierung. Frankfurt am Main: Campus Verlag. 1997. 3. Auflage. ISBN: 978-3-593-

34744-8.

Gronau 2004

Gronau, N.: Enterprise Resource Planning und Supply Chain Management - Architek-

tur und Funktionen. Oldenbourg: Wissenschaftsverlag GmbH. 2004. ISBN: 3-486-

27265-9.

119

Hammer und Champy 1996

Hammer, M., Champy, J.: Business Reengineering – Die Radikalkur für das Unter-

nehmen. Frankfurt/Main: Campus Verlag GmbH. 6.Auflage. 1996. ISBN: 3-593-

35017-3.

Handelsblatt 2010

Handelsblatt: http://www.handelsblatt.com/unternehmen/it-medien/fuehrungswechsel-

leo-apotheker-muss-als-sap-chef-abtreten;2525867 besucht am 14.04.10.

Höning 2009

Höning, F.: Methodenkern des Business Engineering: Metamodell, Vorgehensmodell,

Techniken, Ergebnisdokumente und Rollen. Universität St. Gallen: Dissertation. 2009.

Hohlmann 2007

Hohlmann, B.: Organisation SAP – Soziale Auswirkungen technischer Systeme. TU

Darmstadt: Dissertation. 2007.

Innocentive 2010

Innocentive:

https://gw.innocentive.com/ar/challenge/browse?pavilionName=SAP&pavilionId=191

9&source=pavilion besucht am 07.04.2010.

Jackwerth 2009

Jackwerth, T.: Die Einführung von Informationssystemen und ihre Auswirkung auf die

Arbeit und Kommunikation im Unternehmen: eine empirische Untersuchung dreier

SAP-Einführungsprojekte bei einem Unternehmen aus der Transport- und Logistik-

branche. Hamburg: Kovac 2009. ISBN 978-3-8300-3868-9.

Kröber 1991

Kröber, H. W.: Der Beratungsbegriff in der Fachliteratur. In: Hofmann, M./v., Ro-

senstiel, L., Zapotoczky, K.: Die soziokulturellen Rahmenbedingungen für Unterneh-

mensberater. Stuttgart: Kohlhammer. 1991. S.1-35. ISBN: 3-17-011576-6.

Kubicek und Rolf 1985

Kubicek, H., Rolf, A.: Mikropolis: mit Computernetzen in die Informationsgesell-

schaft. Hamburg: VSA-Verlag. 1985. ISBN: 3-87975-288-5.

120

Latour 1998

Latour, B.: Über technische Vermittlung - Philosophie, Soziologie, Genealogie. In:

Rammert, W.: Technik und Sozialtheorie. Frankfurt am Main: Campus Verlag. 1998.

Theorie und Gesellschaft. Band 42. S. 29-81. ISBN 3-593-35997-9.

Latour 2007

Latour, B.: Eine neue Soziologie für eine neue Gesellschaft: Einführung in die Akteur-

Netzwerk-Theorie. Frankfurt am Main: Suhrkamp. 2007. ISBN 978-3-518-58488-0.

Leimbach 2008

Leimbach, T.: The SAP Story: Evolution of SAP within the German Software Industry.

IEEE Annals of the History of Computing. 2008. Published by the IEEE Computer

Society. 1058-6180/08

Meissner 1997

Meissner, G.: SAP - die heimliche Software-Macht: wie ein mittelständisches Unter-

nehmen den Weltmarkt eroberte. Hamburg: Hoffmann und Campe, 1997. ISBN: 3-

455-11194-7.

Ogburn 1950

Ogburn, W. F.: Social Change: with respect to culture and original nature. New York:

Viking Press, 1950

Plattner et al. 2000

Plattner, H., Scheer A-W., Wendt S., Morrow, D.: Dem Wandel voraus: Hasso Platt-

ner im Gespräch. Bonn: Galileo Press 2000. ISBN 978-3-93435-855-3.

Promberger 2006

Promberger, K.: Implementierung von ERP-Systemen an Universitäten: uni.verse –

Strategien Management der SAP-Einführung. Wien: Neuer Wissenschaftlicher Verlag.

2006. ISBN 3-7083-0379-2.

Rammert 1998

Rammert, W.: Die Form der Technik und die Differenz der Medien: Auf dem Weg zu

einer pragmatischen Techniktheorie. In: Technik und Sozialtheorie. Frankfurt am

Main: Campus Verlag. 1998. Theorie und Gesellschaft; Band 42. S. 293-326. ISBN 3-

593-35997-9.

121

Rammert 2000

Rammert, W.: Technik aus der soziologischen Perspektive 2: Kultur, Innovation, Vir-

tualität. Wiesbaden: Westdeutscher Verlag GmbH. Band 2. 2000. ISBN 3-531-13499-

X

Rammert 2006

Rammert, W.: Technik, Handeln und Sozialstruktur: Eine Einführung in die Soziologie

der Technik. Technical University Technology Studies. Working Papers. TUTS-WP-3-

2006. http://www.ts.tu-berlin.de/fileadmin/fg226/TUTS/TUTS_WP_3_2006.pdf be-

sucht am 26.02.2010

Rolf 2008

Rolf, A.: Mikropolis 2010: Menschen, Computer, Internet in der globalen Gesell-

schaft. Marburg: Metropolis Verlag. 2008. ISBN: 3-89518-645-7.

SAP 2001

SAP Geschäftsbericht 2001, Walldorf, SAP AG.

SAP 2002


SAP 2003


SAP 2004


SAP 2005


SAP 2006


SAP 2007


SAP 2008


122

SAP 2009


SAP Daten

SAP Daten: http://www.sap.com/germany/about/press/daten.epx

besucht am 04.04.2010.

SAP Geschichte 1

SAP Geschichte:

http://www.sap.com/germany/about/company/geschichte/geschichte_1.epx


SAP Geschichte 2

SAP Geschichte:



SAP Geschichte 3

SAP Geschichte:



SAP Geschichte 4

SAP Geschichte:



SAP Marktplatz 2010:

SAP Marktplatz: https://websmp101.sap-ag.de/ besucht am 09.04.2010.

Schegloff 1972

Schegloff, E. A.: Sequencing in Conversational Openings. In: Gumperz, J. J., Hymes,

D.: Directions in Sociolinguistics. USA: Holt, Rinehart and Winston, Inc. 1972. ISBN:

0-03-077745-3

Scheuch 2003

Scheuch, E.K.: Sozialer Wandel: Theorien des sozialen Wandels. Wiesbaden: West-

deutscher Verlag/GWV Fachverlage GmbH. 2003. ISBN 3-531-14070-1.

123

Sesink 2003

Sesink, W.: Wozu Informatik? Ein Antwortversuch aus pädagogischer Sicht. In: In-

formatik zwischen Konstruktion und Verwertung. Materialien zur Arbeitstagung in

Bad Hersfeld. 3.-5. S. 59-62. 2003.

Siegele 2009

Siegele, L., Zepelin, J.: Matrix der Welt: SAP und der neue globale Kapitalismus.

Frankfurt am Main: Campus Verlag. 2009. ISBN: 978-3-593-38574-7.

Strambach 2008

Strambach, S., Storz, C.: Pfadabhängigkeit und Pfadplastizität von Innovationssyste-

men – Die deutsche und japanische Softwareindustrie. In: Wirtschaftsforschung 77.

2008. S. 142-161.

Virilio 1989

Virilio, P.: Der negative Horizont: Bewegung, Geschwindigkeit, Beschleunigung.

München: Hanser. 1989. ISBN: 3-446-15005-6.

Vorlesung Rolf 2010

Vorlesungsunterlagen von Rolf, A.: Informatiksysteme im Kontext / IKON2. Hamburg.

Sommersemester 2010. Teil 1. http://www.mikropolis.org/elearning-angebote/folien-

ikon-2/.

Windeler 2003

Windeler, A.: Kreation technologischer Pfade: ein strukturationstheoretischer Analy-

seansatz. In: Schreyögg, G., Sydow, J., Koch, J.: Strategische Prozesse und Pfade.

Wiesbaden: Gabler. Managementforschung 13. 2003. S. 295-328. ISBN: 3-409-

11917-5.

Wittgenstein 1953

Wittgenstein, L.: Werkausgabe Band 1: Tractatus logico-philosophicus: Tagebuecher

1914 - 1916; philosophische Untersuchungen. Frankfurt: Suhrkamp. 1999. S. 231 -

485

Witte 1973

Witte, E.: Organisation für Innovationsentscheidungen: Das Promotoren Modell. Göt-

tingen: Verlag Otto Schwartz & Co. 1973. ISBN: 3-509-00616-X.

124

Wolter 2006

Wolter, C.: Soft Factors fokussierte Erfolgsfaktoren der SAP R/3-Implementierung.

Hamburg: Kovac. 2006. ISBN 3-8300-2459-2.

Woods 2005

Woods, D.: Enterprise Services Architecture: SAPs Bauplan für Geschäftsapplikatio-

nen der nächsten Generation. Bonn: Galileo Press. 2005. ISBN 3-89842-508-8.

125

Ehrenwörtliche Erklärung

Ich versichere, dass ich die vorstehende Arbeit selbstständig und ohne fremde Hilfe angefer-

tigt und mich anderer als der im beigefügten Verzeichnis angegebenen Hilfsmittel nicht be-

dient habe. Alle Stellen, die wörtlich oder sinngemäß aus Veröffentlichungen entnommen

wurden, sind als solche kenntlich gemacht. Alle Quellen, die dem World Wide Web entnom-

men oder in einer sonstigen digitalen Form verwendet wurden, sind der Arbeit beigefügt.

_______________________ ___________________________

Ort, Datum Unterschrift

Department Informatik der Universität Hamburg...Department Informatik der Universität Hamburg -...

Documents

Transcript of Department Informatik der Universität Hamburg...Department Informatik der Universität Hamburg -...