Das Projekt SAP: Zur Organisationssoziologie betriebswirtschaftlicher Standardsoftware 9783839433768

Citation preview

Hannah Mormann Das Projekt SAP

Sozialtheorie

Hannah Mormann (Dr. phil.), geb. 1980, lehrt und forscht am Soziologischen Seminar der Universität Luzern. Ihre Arbeitsschwerpunkte sind Organisationssoziologie und Technikforschung.

Hannah Mormann

Das Projekt SAP Zur Organisationssoziologie betriebswirtschaftlicher Standardsoftware

Dissertation, Universität Bielefeld 2014

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © 2016 transcript Verlag, Bielefeld

Die Verwertung der Texte und Bilder ist ohne Zustimmung des Verlages urheberrechtswidrig und strafbar. Das gilt auch für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und für die Verarbeitung mit elektronischen Systemen. Umschlagkonzept: Kordula Röckenhaus, Bielefeld Lektorat: Katrin Herbon Printed in Germany Print-ISBN 978-3-8376-3376-4 PDF-ISBN 978-3-8394-3376-8 Gedruckt auf alterungsbeständigem Papier mit chlorfrei gebleichtem Zellstoff. Besuchen Sie uns im Internet: http://www.transcript-verlag.de Bitte fordern Sie unser Gesamtverzeichnis und andere Broschüren an unter: [email protected]

Inhalt

Einleitung | 9

A. DIE STANDARDISIERTE SOFTWARE: DAS ORGANISATIONSMODELL DER TECHNIK 1.

Das 3-Ebenen-Modell der Software | 25

1.1 Die Datenbankebene: Von „navigationalen“ zu relationalen Datenverknüpfungen | 34 1.1.1 Hierarchische und Netzwerk-Datenbankmodelle | 35 1.1.2 Der Gegenentwurf: Das relationale Datenbankmodell | 40 1.1.3 Die Datenbeschaffung mithilfe logischer Datenbanken | 46 1.1.4 Die Softwarearchitektur: Verteiltheit und Skalierbarkeit | 49 1.2 Die Anwendungsebene: Die Modellierung ereignisgesteuerter Prozessketten | 54 1.2.1 Die Kontroverse zwischen Ingenieur und Betriebswirt: Die Echtzeitverarbeitung von Daten im Rechnungswesen | 57 1.2.2 Das Berechtigungskonzept: Die Organisation in der Software | 62 1.3 Die Darstellungsebene: Die Mehrsprachigkeit der Software | 65 1.3.1 Der Unicode-Zeichensatz | 66 1.3.2 Die Globalisierungsdatenbank | 70 2.

Die Idee für eine Standardsoftware und die Entstehungsgeschichte von SAP | 75

2.1 Die erste Entstehungsphase: Grundmodule und das Baukastenprinzip | 78 2.2 Die zweite Entstehungsphase: Die Internationalisierung der Software | 81 2.3 Die dritte Entstehungsphase: SAP als de facto-Standard | 82 3.

Die Softwareverbreitung | 85

3.1 Die neoinstitutionalistische Organisationstheorie | 88 3.2 Verordnen, Empfehlen und Nachahmen: Erklärungen der Softwareverbreitung | 90 3.2.1 Die verordnete Software: Gesetze und Konzernvorgaben | 91

3.2.2 Die empfohlene Software: Sozialisations- und Netzwerkeffekte | 93 3.2.3 Die nachgeahmte Software: Die Inszenierung von Erfolg | 96 3.3 Das Organisationsfeld SAP – Wie ein Softwarehersteller Beziehungen zwischen Organisationen konstruiert | 100 3.3.1 Das Organisationsfeldkonzept | 101 3.3.2 Referenzmarketing und Organisationsvergleiche | 104 Exkurs: „Zufriedene Kunden kennenlernen“ | 107 3.3.3 Die Herstellung von Vergleichsbeziehungen und die Theoretisierung der Organisation | 109 4.

Das Organisationsmodell von SAP und ingenieurtechnische Grundlagen im Management | 111

4.1 SAP und andere Managementkonzepte | 114 Exkurs: Das Beispiel ISO 9000 | 115 4.2 Managementingenieure und das Problem der Unsicherheitsreduktion | 118 4.2.1 Der Ingenieur Taylor und das Prinzip der Übertragung | 119 4.2.2 Auf dem Weg zu einer modernen Organisationstheorie | 121 4.3 Simons entscheidungstheoretisches Forschungsprogramm | 122 4.3.1 Organisationen als Entscheidungssysteme | 123 4.3.2 Entscheidungsprogramme in Organisationen | 126 4.3.3 Die Systemperspektive | 129

B. DIE INDIVIDUALISIERTE SOFTWARE: DIE INTEGRATION DER TECHNIK I 5.

Der systemtheoretische Untersuchungsrahmen: Luhmanns organisationssoziologische Konzepte | 135

5.1 Unsicherheitsabsorption und die Eigenlogik der Organisation | 137 5.2 Entscheidungen und Entscheidungsprämissen | 141 5.3 Die kommunikative Bearbeitung von Entscheidungsproblemen | 144 6.

Die Beratungsinteraktion: Entscheidungen als Output | 147

6.1 Konkretisierung der Anforderungen | 149 6.2 Selbstbeschreibungen der Organisation | 153 6.3 Entscheidungsprogramme in der Organisation und die Programmlogik | 155 6.4 Berechtigungen und andere Entscheidungsprobleme | 159

7.

Die Projektorganisation: Entscheidungen als Input | 165

7.1 7.2 7.3 7.4

Entscheidungen über Interaktionsformate | 166 Soziale Faktoren: Projektteilnehmer und ihre Erwartungen | 168 Zeitknappheit als konstitutives Merkmal von Softwareprojekten | 175 Prototyping und andere Strategien der Angleichung von Organisation und Technik | 179

C. DIE OPERATIVE SOFTWARE: DIE INTEGRATION DER TECHNIK II 8.

Beschreibungen der Softwareverwendung | 189

8.1 Deterministische Modelle | 190 8.2 Die Dualität der Technik | 195 8.3 Die Softwareverwendung als softwarevermittelte Kommunikation | 198 9.

Über unvollständige, verteilte und anderweitig „defekte“ Datenverarbeitung | 205

9.1 9.2 9.3 9.4

Die Software als Entscheidungsprogramm | 206 Das unvollendete Softwareprojekt | 210 Lokale Datensammlungen und (Nicht-)Informationen | 215 Die operative Software: Das Produkt eines Entscheidungsnetzwerkes | 220 Schluss | 225 Literatur | 235 Anhang | 257 Danksagung | 263

Einleitung

Betriebswirtschaftliche Standardsoftware ist für Anwendungsgebiete programmiert, „von denen von vornherein feststeht, dass ein größerer Kreis von Anwendern dieselben oder ähnliche Programme benutzen kann“ (Schneider 1997: 819f.). In den 1970er Jahren war es in Unternehmen noch üblich, Software von festangestellten Programmierern entwickeln zu lassen. Diese Software wurde eingesetzt, um Probleme in einer besonderen Arbeitsumgebung zu lösen. In Unternehmen war Individualsoftware also die Regel. Die Chancen für eine Standardsoftware, die von vielen verschiedenen Organisationen verwendet werden sollte, schätzten Marktexperten noch Anfang der 1990er Jahre eher gering ein. Individuelle Organisationen mit ihren Arbeitsabläufen und eine standardisierte Software stellten für viele Experten einen Widerspruch dar. „For many social scientists, especially those informed by sociology and anthropology, the large software suppliers like SAP should not be successful. Sociological/anthropological theory tells them that organisations are too diverse to deploy these highly generic systems. Many studies therefore end up suggesting – on the basis of difficulties and complications witnessed during fieldwork – that ERP systems and the like have no more than limited potential for extension.“ (Pollock & Williams 2009: 8)

Die ersten Module der Standardsoftware SAP wurden 1972 für die deutsche Niederlassung eines britischen Chemiekonzerns entwickelt. Als System R bzw. R/1 und später als R/2 wurde die Standardsoftware auch in anderen Unternehmen eingesetzt. Im Frühjahr 1991 stellten die Softwareentwickler von SAP einzelne Module von R/3 auf der Computermesse CeBIT in Hannover vor. Die Software verbreitete sich in den Folgejahren weltweit. Bis 2003 trug sie den Namen SAP R/3. Heute wird die Standardsoftware als SAP ERP (Enterprise Resource Planning) bzw. SAP ECC (ERP Central Component) verkauft und wird mittlerweile in über 250.000 Unternehmen und anderen Organisationen verwen-

10 | D AS P ROJEKT SAP

det. In ihrem Buch Software and Organisations. The Biography of the Enterprise-Wide System or How SAP Conquered the World kritisieren Neill Pollock und Robin Williams (2009) die einseitige Blickrichtung in der bisherigen soziologischen Forschung über Softwaresysteme wie SAP. Es gehe ausschließlich um die Anpassung standardisierter Produkte an organisatorische Umgebungen („situated and localist explanations“). Trotz methodischer Unterschiede konzentrierten sich viele Arbeiten auf die Besonderheiten des Einzelfalls und klammerten weitere kulturelle und gesellschaftliche Einflüsse und Wirkungen aus.1 Die meisten der Arbeiten seien Momentaufnahmen („snapshots“), in denen der Sieg des Lokalen über das Globale oder der Sieg des Politischen über das Technische erklärt werde.2 Die generelle Kritik von Pollock und Williams lautet daher: Der Einfluss der Angebotsseite moderner IT-Systeme auf die Nachfrageseite wird nahezu vollständig ausgeblendet. Pollock und Williams greifen in ihrer eigenen SAP-Studie auf umfangreiches empirisches Datenmaterial aus drei Jahrzehnten zurück.3 Sie nutzen das Material für eine Art biografische Schilderung von IT-Systemen („biography of artefacts framework“). Wesentliche Stationen sind die Entwicklung, der Vertrieb und die Implementierung von IT-Systemen sowie ihre Wartung und Pflege durch den Hersteller (vgl. ebd. 80ff.). Statt zu untersuchen, wie Softwareprodukte im Nachhinein an eine besondere Umgebung angepasst werden, fragen die Technikforscher, wie es Anbietern wie dem SAP-Konzern gelingt, in ihre Produkte die Verschiedenartigkeit aufzunehmen, die innerhalb von Organisationen und zwischen Organisationen verschiedener Industrien und Kul-

1

Ende der 1990er Jahre etablierte sich mit Arbeiten von McLaughlin et al. 1999, Ciborra et al. 2001, Sawyer 2000 u.a. im angelsächsischen Raum der Forschungszweig Social Study of Information Systems.

2

Die sozialwissenschaftliche Forschung über SAP und vergleichbare Software steht üblicherweise in der Tradition der sozialkonstruktivistischen Wissenschafts- und Technikforschung. Wichtige Referenzpunkte sind die sogenannten Laborstudien von Bruno Latour und Steven Woolgar (1979) sowie Karin Knorr Cetina (1984). Besonders oft werden theoretische Bezüge zur Akteur-Netzwerk-Theorie (ANT) und zu Latour (1987; 1999) als einem ihrer Hauptvertreter hergestellt (z. B. Bloomfield & Best 1992; Briers & Chua 2001; Moscove et al. 2003; Hanseth et al. 2004; Quattrone & Hopper 2005; 2006).

3

Das Material stammt von ihnen selbst sowie von Kollegen an der Universität Edinburgh. Die Autoren nennen die Forschungsprojekte von Fleck, Webster und Williams (1987-1991) sowie Pollock und Conford (1998-2001) (vgl. die Projektangaben in Pollock & Williams 2009: 14). Die Forschungsergebnisse von D’Adderio (2004), Grimm (2009) und Wang (2007) sind ebenfalls in das Buchprojekt eingeflossen.

E INLEITUNG

| 11

turen existiert. Sie fokussieren die Aushandlungsprozesse zwischen Anbietern und Abnehmern von Softwaresystemen. Im sozialen Prozess der Aushandlung artikulieren sich einerseits das standardisierte Softwareprodukt, andererseits die Individualität von Organisationen. Das Allgemeine, das für alle oder viele Organisationen gilt, und das Besondere, das nur für eine einzelne Organisation gilt, werden immer wieder neu bestimmt. Am Beispiel von Universitäten zeigen Pollock und Williams, dass standardisierte Techniken zum Einsatz kommen, die ursprünglich für andere Anwendungskontexte (nämlich für die Privatwirtschaft) entwickelt wurden.4 Die neuere Technikforschung etablierte sich in den 1980er Jahren im Anschluss an die Umbrüche in der Wissenschaftsforschung vor allem im englischsprachigen Raum. Die Wissenssoziologie in der Tradition Karl Mannheims (1929) hatte bis dahin die Naturwissenschaften und Mathematik als Forschungsgebiet weitgehend ausgeklammert, denn diesen Disziplinen wurde ein epistemologischer Sonderstatus zugewiesen.5 Der soziologischen Wissenschaftsforschung geht es nunmehr um den empirischen Nachweis der sozialen Konstituierung wissenschaftlichen Wissens auch auf jenen Gebieten, die scheinbar keine Beziehun-

4

Pollock und Williams illustrieren soziale Aushandlungs- und Übersetzungsprozesse am Beispiel der Anpassung eines betriebswirtschaftlichen Softwaremoduls für den Einsatz in Universitäten. Sie stellen fest: „ERP systems are structured around general notions such as supplier, customer and employee, and while these may share some of the characteristics of actors found in universities, they do not map straightforwardly“ (Pollock & Williams 2009: 140). Die Softwareentwickler (re-)interpretieren existierende Kategorien in der Software und Programmabläufe so, dass sie als Bausteine für den neuen Kontext wiederverwertet („re-using“) werden können. Das Softwaremodul wird zunächst für die Verwendung in einer bestimmten Hochschule spezifiziert, um es anschließend als sogenannte Branchenlösung auch anderen Hochschulen anzubieten (vgl. Pollock et al. 2007: 264).

5

Mannheim beschreibt diesen Sonderstatus so: „Während man der Aussage (um den einfachsten Urtypus anzuführen) 2 mal 2 = 4 nicht ansehen kann, durch wen und wann und wo sie so formuliert wurde, wird man es einem geisteswissenschaftlichhistorischen Werk stets ansehen, ob es etwa in den Aspektstrukturen der ‚historischen Schule‘, des ‚Positivismus‘ oder des ‚Marxismus‘ und auf welcher Stufe derselben konstituiert worden war“ (ebd.: 234). Die „harten Wissenschaften“ wurden nur dann zum Gegenstand wissenssoziologischer Untersuchungen gemacht, wenn es um die nachträgliche Erklärung naturwissenschaftlicher Irrtümer ging.

12 | D AS P ROJEKT SAP

gen zwischen dem Forschungsgegenstand und sozialen Strukturen aufweisen.6 Vertreter und Vertreterinnen ganz unterschiedlicher Disziplinen versuchten auf dem Gebiet der Technikforschung in vergleichbarer Weise nachzuweisen, dass sowohl die Herstellung als auch die Verwendung von Techniken gesellschaftlich gestaltet und von einer Vielzahl sozialer Faktoren beeinflusst ist – vom kulturellen und geografischen Umfeld ebenso wie von wirtschaftlichen, politischen und organisatorischen Rahmenbedingungen (vgl. MacKenzie & Wajcman 1985; Edge 1988; Williams & Edge 1996; Quintas 1994). Unter der Überschrift Social Shaping of Technology (SST) sind in den vergangenen drei Jahrzehnten eine Vielzahl von Arbeiten entstanden, die Techniken nicht nur als Einflussfaktoren für den Wandel von Organisationen und Gesellschaft untersuchen. Techniken selbst, ihre Herstellung und Verwendung, stehen im Fokus (vgl. Williams & Edge 1996: 856). SST ist ein mittlerweile weit verzweigtes Forschungsgebiet innerhalb der Science and Technology Studies (STS). Zu einem der einflussreichsten Aufsätze zählt The Social Construction of Facts and Artifacts Or How the Sociology of Science and the Sociology of Technology Might Benefit Each Other von Trevor Pinch und Wiebe Bijker (1987).7 Die Autoren importieren zwei zentrale Konzepte aus der Wissenschaftsforschung in die Technikforschung: die interpretative Flexibilität und die soziale Schließung. Interpretative Flexibilität in den Science Studies bedeutet, dass Forschungsergebnisse oft mehrdeutig sind. Technische Artefakte können von Akteuren bzw. relevanten sozialen Gruppen ebenfalls auf unterschiedliche Weise interpretiert werden. Die Interpretationsmöglichkeiten sind allerdings nicht beliebig. Begrenzt wird der Spielraum einerseits durch die materielle Beschaffenheit des Artefakts. Andererseits wird die Interpretation durch den sozialen Kontext bestimmt. Die

6

David Bloor von der Universität Edinburgh hatte in diesem Zusammenhang eine Vorreiterrolle. Einen entscheidenden Beitrag für eine Wissenssoziologie wissenschaftlichen Wissens lieferte er in Knowledge and Social Imagery (1976).

7

Der Aufsatz stammt aus dem Sammelwerk The Social Construction of Technological Systems: New Directions in the Sociology and History of Technology (1987). Die von Wiebe E. Bijker, Thomas P. Hughes und Trevor J. Pinch herausgegebene Aufsatzsammlung zählt zum Grundlagenwerk der sozialkonstruktivistischen Technikforschung. Bijker und seine Kollegen formulieren in der Einleitung die Gemeinsamkeiten der in den 1980er Jahren entstandenen Technikstudien: „A characteristic that all these approaches share is the emphasis on thick description, that is, looking into what has been seen as the black box of technology (and, for that matter, the black box of society). [...] This thick description results in a wealth of detailed information about the technical, social, economic, and political aspects of the case under study“. (Ebd.: 5)

E INLEITUNG

| 13

Mehrdeutigkeit von Forschungsergebnissen wird in wissenschaftlichen Kontroversen behandelt, bis irgendwann ein Konsens darüber hergestellt ist, was als Wahrheit betrachtet werden kann. Pinch und Bijker sprechen in diesem Zusammenhang von sozialer Schließung. Für die Technikentwicklung illustrieren sie in ihrem programmatischen Aufsatz einen vergleichbaren sozialen Mechanismus am Beispiel der Entstehungsgeschichte des Fahrrads.8 Generell betrachten Technology Studies die Entwicklung technischer Artefakte als alternierenden, nichtlinearen Prozess, in dem Design und Problemkonstellationen variieren und sozial ausgehandelt werden. In der Soziologie wird die Frage nach der sozialen Bedeutung einer Technik unterschiedlich interpretiert. Entweder steht der Entstehungskontext im Fokus und das technische Artefakt selbst wird als verfestigte Form des Sozialen betrachtet. Oder die soziale Bedeutung einer Technik wird in den Praktiken des Umgangs mit ihr gesucht, d.h. der Verwendungskontext steht im Fokus.9 Für Ingo Schulz-Schaeffer (1999) handelt es sich um zwei alternative soziologische Zugänge zur Technik, die unterschiedlichen Theorietraditionen folgen. Den ersten Ansatz charakterisiert er als Vergegenständlichungsperspektive und zieht eine Verbindung zur Soziologie Émile Durkheims (vgl. ebd.: 52ff.). Den zweiten Ansatz sieht er in der Tradition von Max Weber und subsumiert entsprechende Studien unter der Überschrift Enactment-Perspektive (vgl. ebd.: 64ff.). Beide Perspektiven werden im vorliegenden Buch berücksichtigt. Einerseits geht es mir bei der Rekonstruktion der Entstehungsgeschichte um den Nachweis der

8

Das Fahrrad war zunächst als Hochrad konstruiert worden, das über das Vorderrad angetrieben wurde. Ingenieure, Sportler, Frauenvereine und Hochradmechaniker hatten unterschiedliche Vorstellungen von der Nutzung des Fahrrads: als Sportgerät, als alltägliches Fortbewegungsmittel, als Freizeitbeschäftigung etc. Jede dieser Gruppen lieferte eine andere Interpretation zur Entwicklung des Rads. Im sozialen Aushandlungsprozess bildete sich ein Konsens darüber, für welches Problem das technische Artefakt eine Lösung bieten sollte. Das relativ niedrige, über das Hinterrad angetriebene Fahrrad mit Gummireifen stellte schließlich einen Kompromiss zwischen Sportlichkeit und Sicherheit dar (vgl. Pinch & Bijker 1987: 28ff.).

9

Werner Rammert formuliert den Grundsatz für seine Technikforschung beispielsweise so: „[E]rst der Umgang mit den Sachen [macht] die Technik zu einem relevanten sozialen Faktor“ (Rammert 1993: 300). Rammert geht davon aus, dass das materielle Artefakt allein Sozialwissenschaftlern wenig Aufschluss über den sozialen Charakter einer Technik geben kann. Der soziologische Zugang erfolgt hiernach indirekt, indem soziale Aushandlungsprozesse über die Bedeutung der Technik analysiert werden (vgl. ebd. 297).

14 | D AS P ROJEKT SAP

Vergegenständlichung sozialer Strukturen in den Programmen der Standardsoftware. Andererseits analysiere ich den Umgang und die Verwendung der Software in unterschiedlichen Organisationskontexten. Mit anderen Worten, am Beispiel der Verbreitung, Implementierung und Verwendung von SAP-Software wird das Zusammenspiel von Technik und Organisation untersucht. Folgende Teilfragen werden dabei beantwortet: 1) Wie modelliert die Technik eine Organisation? 2) Wie integriert eine Organisation die Technik? Die folgende Abbildung gibt das behandelte Frageschema wieder. Abbildung 1: Das Zusammenspiel von Technik und Organisation

Quelle: Eigene Darstellung

Der Begriff Technik wird in der sozialwissenschaftlichen Forschung oft in einem weiten Sinne verwendet (vgl. Rammert 1989: 725). Neben gegenständlichen bzw. Sachtechniken spricht man auch von Sozialtechniken (z. B. Techniken des Regierens), Intellektualtechniken (z. B. Techniken des Rechnens und Schreibens) und Individualtechniken (z. B. Techniken der Selbstbeherrschung). Im Folgenden soll Technik in einem engen Sinne als Sachtechnik verstanden werden. Für die meisten Soziologen bleibt diese Technik, selbst wenn sie sich mit ihr aus soziologischer Perspektive befassen, eine Blackbox, deren innere Struktur außerhalb ihres Untersuchungshorizontes liegt. Diese Einstellung stellt auf die Dauer ein Hindernis für ein umfassendes soziologisches Verständnis einer Technik wie SAP dar, die heutzutage in vielen unterschiedlichen Organisationen (z. B. Unternehmen, Behörden, Universitäts-, Kirchen- und Krankenhausverwaltungen) eingesetzt wird. Ein Hauptanliegen der vorliegenden Untersuchung ist es daher, die innere Struktur der Blackbox einer betriebswirtschaftlichen Standardsoftware wie SAP freizulegen. Dazu ist es zum einen notwendig, sich detailliert

E INLEITUNG

| 15

und intensiv mit den grundlegenden Konzepten der Software auseinanderzusetzen; zum anderen erweist es sich als zweckmäßig, auch auf die Entstehungsgeschichte der Technik genauer einzugehen. Software ist nämlich in besonderer Weise von ihrer eigenen Geschichte abhängig. Diese Abhängigkeit bewertet ein Interviewpartner, der in den 1980er und 1990er Jahren an den Entwicklungen von R/2 und R/3 beteiligt war, folgendermaßen: INTERVIEWPARTNER G: „Das Kapital, das da gebunden ist, das ist ja unser geronnenes Wissen, das in den Programmen steckt. Das kannst Du ja nicht wegschmeißen oder neu schreiben. Die Programme müssen weiterlaufen bzw. es muss ein vertretbarer Aufwand sein, um sie so umzustellen, dass sie auf dem nächsten Release wieder laufen und zwar mit derselben Produktivität.“

Die Technik SAP, so wie sie heute vorliegt und in Organisationen verwendet wird, hat eine längere Geschichte. Soziologen und Soziologinnen sollten diese Geschichte nicht nur als Technikgeschichte abtun, sondern als Mittel, um die soziale Dimension technischer Entwicklungen zu begreifen. Zu den drei Grundbegriffen, mit deren Hilfe die Technik untersucht werden soll, gehören: 1) Relationale Datenbanken, 2) die Echtzeitverarbeitung betriebswirtschaftlicher Ereignisse und 3) die Mehrsprachigkeit der Software. Diese Grundbegriffe sind nicht nur für das Verständnis der rein technischen Funktionsweise von Software im Allgemeinen wesentlich. Sie sind auch essenziell für das Verständnis des Organisationsmodells, das der Software zugrunde liegt. Die erste Teilfrage der Untersuchung lautet deshalb: Wie modelliert die Technik eine Organisation? Aus der Sicht eines Unternehmens sind Aufträge, Bestellungen, Rechnungen usw. typische Ereignisse im Organisationsalltag, die als Startereignisse für die betriebswirtschaftlichen Anwendungsprogramme von SAP fungieren. Sie lösen Prozesse bzw. Prozessketten aus. Was wann wie im Unternehmen bearbeitet werden soll, wird damit eindeutig bestimmt. Sachliche und zeitliche Unsicherheiten in der Organisation sind im Organisationsmodell der Technik auf der Grundlage sogenannter ereignisgesteuerter Prozessketten verschwunden. Soziale Unsicherheiten, die aus der Unübersichtlichkeit von Zuständigkeiten resultieren können, werden durch wohldefinierte Zugangsberechtigungen reduziert. Das klingt gut. In Wirklichkeit ist dieses technische Organisationsmodell jedoch nur ein theoretisches, nicht selten stark idealisierendes Modell dessen, was wirklich

16 | D AS P ROJEKT SAP

in Organisationen passiert. Bevor SAP-Software verwendet werden kann, muss sie gewissermaßen entstandardisiert werden. Das heißt, sie muss an die spezifischen Bedingungen einer konkreten Organisation angepasst werden. Dies geschieht über das Customizing10 von externen Softwareberatern. Schlägt man den Begriff Standardsoftware im Lexikon nach, ist unter diesem Stichwort der folgende Eintrag zu lesen: „Das Attribut Standard ist meist irreführend, da es sich selten um ein Produkt handelt, das unverändert in einem beliebigen Unternehmen eingesetzt werden kann, i. d. R. sind umfangreiche Anpassungen erforderlich“ (Hadeler et al. 2001: 3096). Diese Anpassungen betreffen Funktionen und Parameter in den Programmabläufen der Software, aber auch die Veränderung von Arbeitsabläufen in der Organisation. Dafür soll nachfolgend der Begriff Individualisierung verwendet werden, da er die Voraussetzungsfülle bezeichnet, mit der eine standardisierte Technik wie SAP in Organisationen funktionieren kann. Die Standardsoftware wird also nicht einfach standardmäßig verwendet, sondern muss für eine Organisation individualisiert werden, wenn sie funktionieren soll. Das wirft eine zweite Frage auf: Wie integriert eine Organisation die Technik? Um diese genuin empirische Frage zu beantworten, wurden 30 Experteninterviews mit Softwareentwicklern, Beratern, IT-Verantwortlichen und Softwareanwendern sowie Gesprächssequenzen einer Beratungsinteraktion ausgewertet.11 Eine Organisation, die sich für die Einführung einer Standardsoftware wie SAP entscheidet, tritt nicht bloß als Empfänger einer Lösung auf, die Softwareexperten im Voraus komplett erarbeitet haben. Die Implementierung einer Standardsoftware wie SAP funktioniert in der Praxis nicht nach einem Übertragungsmodell. Es handelt sich bei der Implementierung vielmehr um ein umfassendes Organisationsprojekt. Organisationen organisieren die Einführung der Software im Projektmodus, d.h., es werden zusätzliche Kommunikationswege eingerichtet und Mitarbeiter aus verschiedenen Abteilungen und Fachbereichen zusammengezogen, um mit externen Beratern das zeitlich befristete Vorhaben der Softwareimplementierung zu realisieren.

10 In der Wirtschaftsinformatik werden mit dem Begriff alle Anpassungen der Software bezeichnet, die keine zusätzlichen Programmierungen notwendig machen. 11 Weitere Angaben zu den Interviewpartnern und Interviewpartnerinnen finden sich im ANHANG.

E INLEITUNG

| 17

Die Einführung von SAP steht für den Versuch, Kommunikation in Organisationen stärker zu formalisieren und abteilungs- und standortübergreifend zu regeln. Betriebswirtschaftliche Zusammenhänge sollen sichtbar und Arbeitsabläufe kontrollierbar gemacht werden. Voraussetzung für die Formalisierung der Organisation mit informationstechnischen Mitteln ist das regelhaft Beschreibbare (oder Vorschreibbare) einer Situation oder eines Ablaufes. Damit die Technik SAP in Organisationen verwendet werden kann, muss sie zunächst individualisiert werden. Allgemein gesprochen ist die Standardsoftware deshalb eine „unfertige“ Technik. Sie muss verändert werden, damit sie in Organisationen funktioniert. Die Entstehung und die Verwendung einer Technik sind aus diesem Grund unzureichende analytische Kategorien für eine Organisationssoziologie betriebswirtschaftlicher Standardsoftware. Für die Analyse des Zusammenspiels von Organisation und Technik schlage ich deshalb die Unterscheidung zwischen drei verschiedenen Aspekten der Software vor: A.

B.

C.

Die standardisierte Software ist für möglichst viele Unternehmen konzipiert, ihren Programmen liegt ein entsprechend idealisiertes und abstraktes Organisationsmodell zugrunde. Die Entstehung und Verbreitungsgeschichte der Standardsoftware sind essenziell für ein Verständnis des Organisationsmodells von SAP. Die individualisierte Software wird auf der Grundlage der standardisierten Software für eine konkrete Organisation in Beratungsinteraktionen erst erzeugt. Die operative Software betrifft die Verwendung der Software von Organisationsmitgliedern, die eine flexible Anpassung an vorgegebene technische und soziale Gegebenheiten verlangt.

Die Unterscheidung zwischen standardisierten, individualisierten und operativen Aspekten der Technik strukturiert den Gesamtaufbau des Buches. Dieser folgt nicht einer üblichen, separaten Darstellungsform von Theorie und Empirie. In allen drei Teilen werden sowohl theoretische Begriffsentscheidungen getroffen als auch empirisches Datenmaterial vorgestellt und analysiert. Die skizzierte Unterscheidung impliziert zugleich unterschiedliche Methoden der Datenerhebung. Das Experteninterview ist die primäre Methode der Datenerhebung (vgl. Bogner & Menz 2005). Bei der Methode handelt es sich um eine forschungspragmatisch begründete Mischform zwischen einem explorativen und einem vorstrukturierten Forschungsvorgehen. Bei der Umsetzung bin ich den Grundsätzen der interpretativen Sozialforschung gefolgt, nämlich Offenheit und Kommunikation (vgl. Hoffmann-Riem 1980: 343f.).

18 | D AS P ROJEKT SAP

Das Prinzip der Offenheit besagt, dass die theoretische Strukturierung des Forschungsgegenstandes zurückgestellt wird, bis sich die Strukturierung des Gegenstandes durch die Forschungssubjekte selbst herausstellt. Das leitfadengestützte Interview erlaubte es den Interviewpartnern und Interviewpartnerinnen, auch Aspekte der erörterten Themenbereiche zur Sprache zu bringen, die die Interviewerin nicht erwartete. Für die Interviewpraxis war es wichtig, Fragen mit narrativer Generierungskraft zu stellen und Erzählsequenzen der Interviewten so wenig wie möglich zu beeinflussen. Andererseits hatten die Interviews auch eine klar definierte inhaltliche Ausrichtung, die einerseits durch die Adressierung der Interviewten als Experten und Expertinnen für die Softwareberatung, die Softwareimplementierung oder die Softwareverwendung und andererseits durch Leitfragen thematisch vorstrukturiert waren.12 Das Prinzip der Kommunikation besagt, dass Forscher und Forscherinnen den Zugang zu Daten nur gewinnen, wenn sie auch eine Kommunikationsbeziehung mit den Forschungssubjekten eingehen und dabei das kommunikative Regelsystem der Forschungssubjekte gelten lassen (vgl. Hoffmann-Riem 1980: 347). Beispielsweise ist in den Augen von Beratern und Beraterinnen Zeit, insbesondere die eigene Zeit, eine knappe Ressource. Das Beratungs- und Projektgeschäft zeichnet sich durch ständigen Termindruck und Zeitknappheit aus. Die Anfangssequenz des Leitfadens diente deshalb auch dazu, der dominierenden Frage-Antwort-Orientierung in der Beratung entgegenzukommen. Alle Gespräche wurden digital aufgezeichnet und transkribiert. Sie dauerten mindestens 60 und maximal 200 Minuten. Darüber hinaus wurde auf sogenannte Oral-History-Interviews aus Archiven zur Computergeschichte mit einem der SAP-Gründer und anderen Protagonisten für die Entwicklung grundlegender Konzepte der Software zurückgegriffen. Für die historische Rekonstruktion der Verbreitung und Entwicklung von SAP-Software waren zudem Zeitschriftenund Zeitungsartikel, Geschäftsberichte des Unternehmens SAP AG und journalistische Berichte (z. B. Meissner 1997; Siegele & Zepelin 2009) eine wichtige Informationsquelle – auch um die Experteninterviews vorzubereiten. Außerdem wurden Gesprächssequenzen einer Beratungsinteraktion ausgewertet, die von einem teilnehmenden Berater digital aufgezeichnet wurden. Diese Aufzeichnung wurde mir für mein Forschungsprojekt zur Verfügung gestellt. Das Transkript stellt eine wichtige Ergänzung zum übrigen Interviewmaterial dar. Die Transkripte der Experteninterviews und Gesprächssequenzen der Beratungsinteraktion sind Konstruktionen und kein reales Abbild der Gesprächssituation und der Inhalte, da Transkripttexte stets von den Wahrnehmungsmöglich-

12 Beispiele für Leitfäden finden sich im ANHANG.

E INLEITUNG

| 19

keiten und dem Kommunikationsverständnis der transkribierenden Personen abhängen. Aus Gründen der Lesbarkeit habe ich ein vereinfachtes Transkriptionssystem verwendet.13 Die Datenerhebung basierte auf dem Prinzip des theoretischen Samplings. Barney G. Glaser und Anselm L. Strauss (1998: 53) definieren diese Form der Teilerhebung. „Theoretisches Sampling meint den auf die Generierung von Theorie zielenden Prozeß der Datenerhebung, währenddessen der Forscher seine Daten parallel erhebt, kodiert und analysiert sowie darüber entscheidet, welche Daten als nächstes erhoben werden sollen und wo sie zu finden sind.“14

Beim theoretischen Sampling geht es um die Theoriegenese und nicht, wie beim statistischen Sampling, um den Theorietest. Die Auswertung des Datenmaterials zielte nicht auf die Repräsentativität für eine bestimmte Grundgesamtheit (z. B. Organisationen derselben Branche, Organisationen derselben Größe etc.). Im Vordergrund stand eine konzeptuelle Repräsentativität. Dafür habe ich das Datenmaterial in die Untersuchung einbezogen, das sich für die Entwicklung einer gegenstandsbezogenen Theorie über die Standardsoftware und ihre Verbreitung, Implementierung und Verwendung als produktiv herausstellte. Entscheidungen zur Organisation des Datenmaterials erfolgten auf Basis theoretischer Vorüberlegungen und praktischer Vorkenntnisse, die als sensibilisierende Konzepte (vgl. Blumer 1954) in die Forschung einflossen.15

13 Bei der Aufbereitung des Datenmaterials wurde die folgende Transkriptionsnotation (vgl. Deppermann 1999) verwendet: Kurze, mittlere und längere Pause sind durch die Zeichen (-), (--), (---) gekennzeichnet; Geräusche und parasprachliche Merkmale sind mit doppelten Klammern markiert; ein unverständliches Wort ist mit Klammern und Auslassungszeichen (...) und mehrere unverständliche Wörter in einem Satz sind mit doppelten Auslassungszeichen (...,...) gekennzeichnet. Gekürzte Zitate sind mit eckigen Klammern [...] kenntlich gemacht. 14 Das Zitat stammt aus The Discovery of Grounded Theory. Strategies for Qualitative Research von Barney G. Glaser und Anselm L. Strauss (1998 [1967]). Dieses Buch gilt als „Manifest der qualitativen Sozialforschung“ (Joas & Knöbl 2004: 215). Die Rede von „der“ Grounded Theory ist allerdings irreführend. Es gibt mittlerweile eine pragmatistisch inspirierte Variante von Anselm Strauss und eine empiristische Variante von Barney Glaser (vgl. Strübing 2008: 7). 15 Meine praktischen Vorkenntnisse ergaben sich aus einer mehrjährigen Tätigkeit in Bereichen der internen Kommunikation und Öffentlichkeitsarbeit in einem ITBeratungsunternehmen (vgl. Mormann 2006).

20 | D AS P ROJEKT SAP

Die Interpretation und Auswertung des Datenmaterials beschränkte sich nicht allein auf manifeste und offenkundige Textinhalte. Auch sprachlichkommunikative Aspekte der Interaktion sind in den Auswertungsprozess eingeflossen. Berücksichtigt wurden die für rekonstruktive Analysen in den Sozialwissenschaften üblichen Verfahrensmerkmale, nämlich ein sequenzanalytisches Vorgehen bei der Aufbereitung sowie eine suspensive Deutungshaltung und Datenzentrierung bei der Interpretation der Interviews und Gesprächssequenzen (vgl. Lucius-Hoene & Deppermann 2002). Im ersten Durchgang der Auswertung der Transkripte wurden Textsegmente, die einen Sinnabschnitt bilden, nacheinander analysiert. Meine Aufmerksamkeit galt dabei Besonderheiten der Wortwahl und sprachlich-grammatikalischen Auffälligkeiten sowie Interaktionseffekten, die der Interviewsituation geschuldet waren, sowie Selbst- und Fremdpositionierungen im Erzähltext. Anschließend wurden einzelne Passagen mit vorherigen Passagen im Transkript verglichen. Ziel war es, Konsistenzen, Redundanzen, Verfestigungen oder Brüche in den Erzählungen der Interviewpartner und Interviewpartnerinnen herauszuarbeiten, um zentrale inhaltliche Motive im Datenmaterial zu identifizieren. Auf diese Weise konnten subjektive Deutungsmuster der interviewten Organisationsmitglieder und Berater zu verschiedenen Problemfeldern der Softwareimplementierung und -verwendung rekonstruiert werden. Aus den Leitfragen und den im Voraus antizipierten Themenbezügen entwickelte ich Heuristiken, mit deren Hilfe sich das Datenmaterial ordnen und strukturieren ließ (vgl. Helfferich 2005; Kruse 2008). Im Folgenden soll auf die vier erwähnten Analyseschritte noch etwas genauer eingegangen werden. 1) Bei den syntaktischen und semantischen Analysen des Datenmaterials standen sprachliche Konstruktionen des Selbstverständlichen und des Begründungspflichtigen im Vordergrund. Auf syntaktischer Ebene wurde etwa auf die Verwendung von Pronomina und Passivkonstruktionen, auf Einschübe, (Re-) Formulierungen und Satzabbrüche etc. geachtet. Auf semantischer Ebene wurden dem Vokabular und Metaphern besondere Beachtung geschenkt. 2) Wie in jeder Interaktion spielen situative und sozialstrukturelle Faktoren auch in Interviews eine Rolle (vgl. Littig 2005; Trinczek 2005). Interesse muss erst geweckt und eine Vertrauenssituation hergestellt werden. Letzteres galt für alle Interviews, vor allem aber für Interviews, die mit Organisationsmitgliedern über das Projekt der Softwareimplementierung geführt wurden. Selbst- und Fremdpositionierungen waren für die Interviews und ihre Auswertung in doppelter Hinsicht bedeutsam. Einerseits ging es um die Positionierung der oder des Interviewten gegenüber der Interviewerin. Interaktionseffekte traten z. B. in Form professionell bedingter Kompetenzdarstellungen oder persönlicher Selbstdarstellungen auf. Anzeichen hierfür waren u. a. zögerliche Aussagebereitschaft zu bestimmten

E INLEITUNG

| 21

Themenfeldern, aber auch die Bereitschaft, Probleme im Unternehmen offen anzusprechen. Andererseits spielten Positionierungen der Erzählpersonen gegenüber anderen Figuren (z. B. Kollegen, Vorgesetzten, externen Beratern, Kunden etc.) eine große Rolle, weil beispielsweise auf diese Weise ein spezifisches Verständnis von Beratung zum Ausdruck gebracht wurde. 3) Motive sind wiederholt auftauchende sprachliche Bilder oder Modelle, Figuren und Positionierungen. Den Motivbegriff habe ich in einem fotografischen Sinne verwendet. „Kundenorientierung“ und „Standardisierungsinteressen der Unternehmenszentrale“ und „Unsicherheitsreduktion“ waren Beispiele für zentrale Motive, die in verschiedenen Interviewpassagen von Softwarenutzern und Beratern auf unterschiedliche Weise sprachlich zum Ausdruck gebracht wurden. 4) Die idealtypische Unterscheidung von Beratung, Belehrung und Betreuung fungierte als sensibilisierendes Konzept, das auf der Grundlage von Interviewaussagen gegenstandsbezogen weiter ausgearbeitet wurde. Eine andere Heuristik war die Unterscheidung zwischen sachlichen, zeitlichen und sozialen Sinndimensionen, die bei der Untersuchung der Projektorganisation der Softwareimplementierung zum Tragen kam. Das zentrale Gliederungsprinzip der Arbeit ist die Unterscheidung zwischen standardisierten, individualisierten und operativen Aspekten der Software. Die Kapitelfolge soll nun vorgestellt werden. Die grundlegenden Konzepte der Technik und das Organisationsmodell der Software stelle ich in TEIL A vor. Dafür unterscheide ich in KAPITEL 1 drei verschiedene Ebenen der Software: 1) die Datenbankebene, 2) die Anwendungsebene und 3) die Darstellungsebene. In KAPITEL 2 erläutere ich die Idee für eine Standardsoftware und gehe auf die Entstehungsgeschichte der SAP-Software ein. In KAPITEL 3 wird die Softwareverbreitung aus einer neoinstitutionalistischen Perspektive betrachtet. Mit diesem Ansatz rücken interorganisationale Beziehungen und das Verhältnis von Organisation und Gesellschaft in den Fokus. In KAPITEL 4 setze ich mich mit dem Organisationsmodell von SAP auseinander und zeige Verbindungen zu anderen Managementkonzepten auf. Die historischen Wurzeln technischer und ingenieurspezifischer Organisationsbilder und der Übergang zu einer modernen Organisationstheorie werden in diesem Kapitel expliziert. In TEIL B und in TEIL C wird die Frage beantwortet, wie eine Organisation die Technik integriert. In TEIL B geht es um die Implementierung und die strukturellen Besonderheiten von Softwareberatungsprojekten. Für die empirische Untersuchung wird in KAPITEL 5 zunächst ein organisationstheoretischer Rahmen entwickelt. Grundlegend dafür sind die organisationssoziologischen Arbeiten von Niklas Luhmann, der ein begriffliches Instrumentarium entwickelt hat, um die Eigenlogik von Organisationen zu erfassen. Darauf aufbauend folgt in KAPITEL 6 die Darstellung und Analyse von Gesprächssequenzen einer Bera-

22 | D AS P ROJEKT SAP

tungsinteraktion in einer Organisation. Auf der Grundlage von Interviewmaterial werden in KAPITEL 7 das Softwareprojekt und verschiedene Implementierungsstrategien von Softwareberatern untersucht. In TEIL C geht es um die Softwareverwendung. Dafür stelle ich in KAPITEL 8 zunächst einige klassische Ansätze in Organisationsforschung vor. Anknüpfend an den systemtheoretischen Untersuchungsrahmen schlage ich vor, die Softwareverwendung als softwarevermittelte Kommunikation zu untersuchen. Beschreibungen der Softwareverwendung, die von Softwarenutzern angefertigt wurden, werden in KAPITEL 9 vorgestellt und interpretiert. Zum SCHLUSS folgt die Diskussion und Zusammenfassung der Untersuchungsergebnisse zum Zusammenspiel von Organisation und Technik.

A. Die standardisierte Software: Das Organisationsmodell der Technik

1. Das 3-Ebenen-Modell der Software

Vor über 40 Jahren erschien in der Reihe IBM-Beiträge zur Datenverarbeitung ein Aufsatz mit dem etwas sperrigen Titel Auftragsabwicklung, Disposition und Versandsteuerung integriert im Realzeitbetrieb von Hermann Meier, Dietmar Hopp und Hasso Plattner (1972). In dem Aufsatz wird eine neue Technik der Datenverarbeitung für Unternehmen vorgestellt, „die Arbeitsabläufe in den einzelnen Bereichen nicht getrennt organisiert, sondern eine integrierte Organisation anstrebt, in der die verschiedenen Aktivitäten, aber auch die Informationen koordiniert zusammenfließen“ (ebd.: 4). Hopp und Plattner waren damals Mitarbeiter an einem deutschen Standort des US-amerikanischen Herstellers von Rechenanlagen International Business Machines (IBM). Einige Monate nach Erscheinen des Artikels gründeten sie mit drei weiteren Kollegen das Softwareunternehmen Systemanalyse und Programm-Entwicklung (SAP). Meier war Leiter der Datenverarbeitung der deutschen Niederlassung des Unternehmens Imperial Chemical Industries (ICI). Er erteilte kurze Zeit später dem neu gegründeten Softwareunternehmen SAP seinen ersten Kundenauftrag. Dieses Projekt war Anfang der 1970er Jahre Teil eines größeren Vorhabens. „Das Realzeitsystem für die maschinelle Auftragsbearbeitung und Versandsteuerung ist der erste Baustein in dem geplanten integrierten Gesamtsystem, das in der Endstufe auch die Organisation des Einkaufs, der Materialabrechnung und des Rechnungswesens mit umfassen soll. Die Planung für den Ausbau des Systems ist abgeschlossen, mit der Realisierung wurde bereits begonnen.“ (Meier et al. 1972: 27)

Den Begriff Software verwendeten Meier, Hopp und Plattner in ihrer Beschreibung des Realzeitsystems (System R) allerdings noch nicht. Der Begriff tauchte 14 Jahre zuvor in einem Aufsatz des US-amerikanischen Statistikers John Tukey auf.

26 | D AS P ROJEKT SAP „Today the software comprising the carefully planned interpretive routines, compilers, and other aspects of automative programming are at least as important to the modern electronic calculator as its hardware of tubes, transistors, wires, tapes and the like.“ (Tukey 1958: 1)

Die Unterscheidung zwischen Software und Hardware, wie Tukey sie vorgenommen hatte, war Anfang der 1970er Jahre noch die Ausnahme. In der Regel wurden Hardware und Software noch als Einheit begriffen. Software galt als besonderes Element der materiellen Rechneranlage, also der Hardware (vgl. Ensmenger 2010: 7f.). Für IBM, den zum damaligen Zeitpunkt marktdominierenden Hersteller von Rechenanlagen, war Software eine kostenlose Dreingabe für seine Kunden. Die Rechneranlagen von IBM, die Anfang der 1970er Jahre vor allem in großen Unternehmen zum Einsatz kamen, wurden mit dem notwendigen Zubehör wie Magnetbandeinheiten, Speicher und Drucker im Rechenzentrum des Kunden aufgestellt. Der Programmcode war eine Dienstleistung der IBMSystemingenieure, die die im Unternehmen festangestellten Programmierer unterstützten. IBM wollte auf diese Weise seine Kunden an sich binden. Insgesamt machten Zubehör und Dienstleistungen einer Rechneranlage 50 bis 75 Prozent des Lieferwertes einer elektronischen Datenverarbeitungsanlage aus (vgl. Rösner 1978: 124). Wie sich der Preis für eine Rechneranlage im Detail zusammensetzte, wurde zu diesem Zeitpunkt allerdings noch nicht aufgeschlüsselt. Gegen diese intransparente Praxis des marktbeherrschenden Konzerns wehrten sich kleinere Unternehmen, die sich auf die Herstellung von Peripheriegeräten spezialisiert hatten. Sie verklagten IBM und setzten Anfang der 1970er Jahre gerichtlich durch, dass der Konzern die Preise für Rechneranlagen, Zubehör und Dienstleistungen (Software) entbündelte und diese als separate Posten in der Rechnung aufgeführt werden mussten.1 Schließlich musste IBM mit der Ankündigung eines neuen Computersystems gleichzeitig die technischen Details veröffentlichen, die es Herstellern von Zusatzgeräten ermöglichte, dazu passende Speicher, Drucker und Magnetbandeinheiten zu produzieren. Die möglichen Konsequenzen für die Softwareentwicklung und den Markt für Softwareprodukte beschrieb ein Programmierer Ende der 1960er Jahre so:

1

Eines dieser Unternehmen war der Hersteller für Peripheriegeräte Telex Corporation, der gegen IBM prozessierte und Recht bekam. Ein deutsches Wochenmagazin berichtete: „Wegen monopolistischer Praktiken verurteilte ein US-Gericht den weltmarktbeherrschenden Computerkonzern International Business Machines Corp. zur Zahlung von 325,5 Millionen Dollar Schadensersatz.“ (Der Spiegel 39/1973: 120)

D IE

STANDARDISIERTE

S OFTWARE

| 27

„Da die Computerhersteller bislang ihre Software und sonstige Dienstleistungen kostenlos lieferten, blieb den europäischen Software-Gesellschaften ein nur relativ kleiner Markt, der sich […] vor allem auf die Entwicklung von Applikationspaketen und Programmierunterstützung für einige große Anwender, auf die Erstellung von einigen Compilern und Dienstprogrammen für die europäischen Hersteller beschränkte. [...] Die mögliche Entwicklungstendenz [der Entbündelung: H. M.] liegt damit auf der Hand: Zwischen Hersteller und Anwender von Computern werden sich möglicherweise die unabhängigen Software-Häuser als Mittler schieben.“ (Neugebauer 1969: 452; zit. n. Leimbach 2008: 180)2

Die gesetzlichen Verpflichtungen für IBM zur Entbündelung gelten in der wirtschaftshistorischen Forschung als wichtiger sozialer Einflussfaktor für die Gründung von SAP und anderen Softwareunternehmen (vgl. Leimbach 2010). IBM hatte den Folgeauftrag von ICI für die Fertigstellung eines „integrierten Gesamtsystems“ (Meier et al. 1972: 24) abgelehnt. Die Systemingenieure Hopp und Plattner sollten nämlich auch anderen IBM-Kunden für die Installation von Rechneranlagen zur Verfügung stehen (vgl. Leimbach 2007: 37). Hopp und Plattner kündigten jedoch bald bei IBM und gründeten mit drei weiteren ehemaligen IBM-Kollegen, Claus Wellenreuther, Hans-Werner Hector und Claus Tschira, das Unternehmen SAP. Das Ziel der Unternehmensgründung beschreibt Plattner (HP) rückblickend: „We left with the sole goal to develop standard software. So that was the number one goal, and we kept that goal the focus of all our undertaking in the future. That was very important and despite the first project was an individual software development, we only had standard software in our minds. And only one-and-a-half years later, after we started in 1972, we had our first issue of standard software.“ (HP Oral History 1997: 8)

Die Idee zur Entwicklung einer Standardsoftware, die für viele Aufgabenbereiche in unterschiedlichen Unternehmen verwendet werden sollte, war also bereits Anfang der 1970er Jahre geboren. Hauptmerkmal einer Standardsoftware wie SAP ist bis heute, dass es sich um ein vorgefertigtes Produkt handelt, das für einen vorab definierten Anwendungsbereich in vielen Organisationen verwendet werden kann. Eine Individualsoftware hingegen ist maßgeschneidert für eine

2

Klaus Neugebauer, der Autor des Beitrags in der Zeitschrift Bürotechnik+Automation, gründete mit anderen Programmierern zwei Jahre später selbst ein SoftwareBeratungsunternehmen. Softlab wurde 1992 von BMW und 2008 vom japanischen Telekommunikationskonzern NTT Data aufgekauft. Quelle: http://emea.nttdata.com/ de/startseite/index.html; Zugriff am 11.03.2013.

28 | D AS P ROJEKT SAP

einzelne Organisation. Die Entwickler von SAP suchten für ihre Standardsoftware nach einer allgemeinen Form der Darstellung möglichst vieler Organisationsabläufe, um diese informationstechnisch miteinander zu verzahnen. Die erste elektronische Finanzbuchhaltung stellten sie im Jahr 1973 fertig. Programmiert wurde das System RF, das die Basis für die erste Version der Standardsoftware (System R) bildete, auf dem Großrechner des ersten Kunden ICI. Der Buchstabe R stand für realtime. Die folgenden Generationen der Software wurden R/2 und R/3 genannt.3 Für die Mitarbeiter im Unternehmen ICI bedeutete das „Realzeitsystem“ (Meier et al. 1972: 27), dass Daten, die zuvor zeitverzögert über Nacht von einem zentralen Großrechner verarbeitet wurden, nun unmittelbar aktualisiert werden konnten. Das „Wesen von Realtime“ schildert ein SAP-Entwickler so: INTERVIEWPARTNER G: „Also Echtzeit damals, also realtime heißt, dass du da sitzt – was damals revolutionär war, heute jeder hat – du sitzt eben an deinem Bildterminal. Die waren damals ja auch neu. Es war ja ein Privileg am Terminal arbeiten zu dürfen. [...] Und Realtime-Verarbeitung bedeutet, du sitzt an deinem Terminal, gibst das ein und du siehst sofort die Ergebnisse. Auch die Konsequenzen einer Aktion werden sofort widergespiegelt. Also das ist das Wesen von Realtime.“

Die Begriffe realtime bzw. Echtzeit werden in der Informatik dann verwendet, wenn ein technisches System eine bestimmte Zeitanforderung erfüllen muss: „Ein Echtzeitsystem reagiert innerhalb eines vorgegebenen Zeitrahmens auf ein Ereignis. Der Terminus sagt zunächst nichts über die Geschwindigkeit eines Systems aus, er sagt nur, dass es eine – noch zu definierende – Zeitbedingung erfüllen muss.“ (Esders 2012: 352)

Das Realzeitsystem der SAP-Entwickler stellte Daten rechtzeitig zur Verfügung. Damit konnten beispielsweise die aktuellen Materialbestände eines Zentrallagers mit den Daten der Produktionsplanung abgeglichen werden. Sobald die Bestände im Lager unter eine zuvor festgelegte kritische Grenze sanken, wurden Vorgänge im Einkauf automatisch ausgelöst. Die neue Technik stellte somit die Einhaltung des Produktionsplans sicher. „Ziel dieser Konzeption“, so Meier, Hopp und

3

In den zeitgenössischen Veröffentlichungen, so Leimbach in seiner Studie über die Softwarebranche in Deutschland, wurde die Bezeichnung System R oder R/1 allerdings gar nicht verwendet. Sie sei nachträglich eingeführt worden, um die fortlaufende Entwicklung der Software seit den 1970er Jahren bis in die 1990er Jahre aufzuzeigen.

D IE

STANDARDISIERTE

S OFTWARE

| 29

Plattner (1972: 21) in ihrem programmatischen Aufsatz, „war die Entwicklung eines allgemeinen Dialogsystems mit schneller Antwortzeit, das in der Lage ist, Benutzer aus mehreren Arbeitsgebieten gleichzeitig zu bedienen.“ Das allgemeine Dialogsystem bezeichnete ein in den 1970er Jahren neues Konzept der Datenverarbeitung. Mehrere Nutzer greifen gleichzeitig auf denselben Datenbestand zu. Über eine Tastatur an einem Bildschirmterminal werden Daten eingegeben und mit anderen Daten, die aus verschiedenen Abteilungen stammen, in Beziehung gesetzt. Auf diese Weise können verschiedene Aufgaben und Arbeitsabläufe innerhalb eines Unternehmens strukturiert und automatisch aufeinander abgestimmt werden. Die Standardsoftware sollte also von mehreren Nutzern gleichzeitig in verschiedenen Abteilungen eines Unternehmens verwendet werden. Die vielen Verknüpfungen von Tabellen und Datensätzen, die in den Programmen von R/1 in den 1970er und von R/2 in den 1980er Jahren ausgeführt wurden, belasteten den Arbeitsspeicher eines Rechners allerdings in mehrfacher Hinsicht: Parallel zur Auswertung von Datensätzen aus den Datenbanken musste auch der Dialog mit den Bildschirmterminals gesteuert werden. Damals wurden Terminals erstmals in den verschiedenen Abteilungen eines Unternehmens aufgestellt. Um die dafür erforderliche Rechnerleistung gewährleisten zu können, teilten die SAP-Entwickler die Programme in Datenbankprozesse und Dialogprozesse auf. Sie waren so aufeinander abgestimmt, dass die Rechnerkapazität bestmöglich ausgenutzt werden konnte. Das Prinzip der Verteiltheit wurde in den 1990er Jahren zum Markenzeichen von SAP-Software. Die einzelnen Bestandteile der Software werden nunmehr auf drei verschiedene Ebenen verteilt: 1) die Datenbankebene, 2) die Anwendungsebene und 3) die Darstellungsebene. Das 3-Ebenen-Modell der Software ist in der folgenden Abbildung dargestellt.4

4

Die Abbildung basiert auf der Skizze des Beraters C, die er im Rahmen des Interviews anfertigte, um die Softwarearchitektur bzw. das 3-Ebenen-Modell von R/3 und der folgenden SAP-Software zu erläutern. Als R/3 1992 auf den Markt kam, gab es die Programmiersprache Java allerdings noch nicht. Auch die Nutzung von InternetTechnologien innerhalb von R/3 begann erst Mitte der 1990er Jahre.

30 | D AS P ROJEKT SAP

Abbildung 2: Das 3-Ebenen-Modell der Software

Quelle: Eigene Darstellung auf der Grundlage der Skizze eines Beraters

1) Die Datenbankebene („Database/Datamodel“) ist im unteren Teil der Zeichnung nicht bloß durch die Beschriftung „DB“ erkennbar, sondern zusätzlich an dem Gefäß-Symbol.5 Die Namen der Hersteller oder Datenbankprodukte sind darauf eingezeichnet: Oracle, IBM, MS (Microsoft). Die Auslassungspunkte weisen auf weitere Hersteller oder Datenbankprodukte bzw. Nischenprodukte für

5

Der Technikhistoriker Thomas Haigh (2007) untersucht verschiedene Metaphern, die im Zusammenhang mit der Bezeichnung data bank zu Beginn der elektronischen Datenverarbeitung in Unternehmen verwendet wurden. Das Motiv „Gefäß“ sei in der zeitgenössischen Darstellung besonders häufig verwendet worden. Datenbanken seien interpretiert worden als ein „Informationsbecken, aus dem Berichte verschiedenster Art abgezapft werden“ und „unterschiedlich große und unterschiedlich geformte Schöpfkellen eingetaucht werden“ (ebd.: 57) können.

D IE

STANDARDISIERTE

S OFTWARE

| 31

die relationale Datenbanktechnik hin.6 Mit der nächsthöheren Ebene ist die Datenbankebene über zwei Pfeile verbunden, die jeweils nach oben und unten weisen. Der linke Pfeil ist mit SQL (Standard Query Language) beschriftet und verweist auf einen Kasten, in dem die Buchstaben ABAP (Advanced Business Application Programming) eingezeichnet sind. Der rechte Pfeil weist auf einen Kasten, der mit Java beschriftet ist. ABAP und Java sind sogenannte höhere Programmiersprachen. Gegenüber Maschinensprachen oder Maschinencodes, die aus einer Folge von Zahlen bestehen, die von einem Prozessor als Befehlsfolge interpretiert werden, enthalten höhere Programmiersprachen von der Hardware abstrahierende Sprachelemente, die der menschlichen Sprache ähneln. Die Programmiersprache ABAP wurde für einen speziellen Zweck entwickelt, nämlich die Programmierung betriebswirtschaftlicher Anwendungen. Dies unterscheidet sie von der sogenannten Allzweck-Sprache Java. 2) Die Anwendungsebene („Business Logic“) umfasst die betriebswirtschaftlichen Anwendungsprogramme, die auf den Programmiersprachen ABAP und Java basieren. Sie sind in der Abbildung durch zwei gleich große Kästen symbolisiert. Zwischen diesen ist ein hochgestelltes Rechteck mit der Beschriftung ICM und „Internet Communication Mgr“ eingefügt.7 Seitlich weisen zwei kleine Pfeile nach links bzw. rechts auf die ABAP bzw. Java basierten Anwendungsprogramme. Die Programmiersprache ABAP wurde vom Softwarehersteller SAP entwickelt, um Auswertungen von Datenbanken für unterschiedliche Kundenunternehmen programmieren zu können. Ursprünglich stand das Akronym für Allgemeiner Berichtsaufbereitungsprozessor. Die betriebswirtschaftlichen Anwendungsprogramme, die in der eigenen Programmiersprache ABAP und später

6

Das US-amerikanische Unternehmen Oracle entwickelt nicht nur relationale Datenbankmanagementsysteme, sondern ist mittlerweile auch der Hauptkonkurrent des Softwareherstellers SAP auf dem Gebiet betriebswirtschaftlicher Anwendungssoftware bzw. ERP-Software.

7

Die Definition vom „Internet Communication Manager“ (ICM) im Glossar des Softwareherstellers lautet: „Der Internet Communication Manager gewährleistet die Kommunikation zwischen dem SAP-System mit der Außenwelt über die Protokoll HTTP, HTTPS und SMTP.“ (http://help.sap.com; Zugriff am 11.03.2013). Auf diesen weiteren „innertechnischen Verweisungszusammenhang“ (vgl. Joerges 1989) werde ich nicht näher eingehen, sondern mich auf einen engeren Ausschnitt der Softwarearchitektur beschränken.

32 | D AS P ROJEKT SAP

auch in Java8 geschrieben wurden, sind mit der Datenbank über SQLSchnittstellen verknüpft. SQL ermöglicht den Anwendungsprogrammen sowohl sogenannte lesende als auch schreibende Zugriffe auf die Datenbank. In der Skizze ist diese Möglichkeit durch den beidseitigen Richtungspfeil symbolisiert. Mit den Anwendungsprogrammen werden Daten also nicht nur abgerufen, Daten können auch eingegeben, verändert oder gelöscht werden. In den betriebswirtschaftlichen Programmen für unterschiedliche Anwendungsbereiche in einem Unternehmen (z. B. Einkauf, Verkauf, Personal oder Finanzen) werden verschiedene Benutzerrollen festgelegt, die verschiedene Möglichkeiten für Datenbankabfragen zulassen und einschränken. Benutzerrollen sind z. B. „Sachbearbeiter im Innendienst“, „Sachbearbeiter im Qualitätswesen“ und „Manager im Vertrieb“. 3) Die Darstellungsebene („Presentation Layer“) stellt dem Nutzer verschiedene Bildschirmmasken zur Verfügung. Die Benutzeroberfläche der Software ist mit der Ebene der Anwendungsprogramme verknüpft. In der Skizze wird diese Verknüpfung durch die zwei Linien links angezeigt, die die ABAP-Anwendungsprogramme mit zwei Rechtecken verbindet, die jeweils mit „Client – SAP GUI“ beschriftet sind. Der Begriff Client steht für ein Programm, das auf dem Rechner eines einzelnen Nutzers ausgeführt wird. GUI ist die Abkürzung für Graphical User Interface. Für unterschiedliche Bildschirmmasken und Zugriffsmöglichkeiten auf Daten (views) sorgen die Programme auf der Anwendungsebene. Die Datendarstellung der Software ist unabhängig von einem bestimmten Desktop-Rechner. Die Wolke symbolisiert eine Reihe verschiedener InternetTechnologien. Die folgende Abbildung ist ein Beispiel für die Darstellungsebene der Software.

8

Java ist eine vom Unternehmen SUN Microsystems Mitte der 1990er Jahre entwickelte Programmiersprache. SUN wurde im Jahr 2010 vom Unternehmen Oracle gekauft und Java ist mittlerweile eine eingetragene Marke des Datenbankherstellers.

D IE

STANDARDISIERTE

S OFTWARE

| 33

Abbildung 3: Die Darstellungsebene der Software

Quelle: Screenshot der Bildschirmoberfläche

Das 3-Ebenen-Modell der Software steht für eine besondere Client/ServerArchitektur. Diese Architektur zeichnet sich dadurch aus, dass oberhalb eines Datenbankservers viele Applikationsserver eingesetzt werden können. Und oberhalb der vielen Applikationsserver können noch viel mehr kleinere Rechner eingesetzt werden.9 Die meisten Softwarenutzer in Organisationen bekommen lediglich die Darstellungsebene der Software auf diesen kleineren Rechnern (z.B. PCs, Notebooks etc.) zu Gesicht. Interviewpartner G verwendet in seiner Beschreibung der Darstellungsebene der Software verschiedene Ausdrücke wie „gestatten“, „steuern“, „sperren“ und „korrigieren“. INTERVIEWPARTNER G: „Das Springen zu den Daten der Buchhaltung, dazu ist ein Bildschirmwechsel erforderlich, ist zum Beispiel nicht gestattet. Dynpros [Abkürzung für dynamische Programme: H. M.] sorgen für die Verzahnung des User Interface mit der Anwendungslogik. Weil die User Interface Programmierung hieß ja nicht nur, ich habe da jetzt irgendwie mal eine nette Maske, sondern die Frage ist ja, wie steuere ich das Verhalten der Anwender. Wie sperre ich die Felder für gewisse Eingaben. Dass ich sage, hier ist was falsch, jetzt korrigiere erst einmal dort den Fehler, dann ist das Feld eingabebereit.“

9

In KAPITEL 1.1.4 „Die Softwarearchitektur“ gehe ich auf das Merkmal der Verteiltheit näher ein.

34 | D AS P ROJEKT SAP

Die Regeln für Datenbankabfragen definiert der Softwareentwickler in den Anwendungsprogrammen. So wird beispielsweise festgelegt, welche Daten dem Softwarenutzer angezeigt werden, ob er selbst Daten eingeben kann, welche Werte und Wertebereiche dabei zulässig sind und wie diese die Datenbasis verändern. Die Technik SAP, so wie sie heute vorliegt und von zahlreichen Unternehmen und anderen Organisationen verwendet wird, hat eine lange Geschichte. Herstellung, Legitimierung und Verbreitung sind Resultat komplexer sozialer Prozesse. Um diese näher zu ergründen, sollen zunächst drei Grundbegriffe eingeführt werden: 1) relationale Datenbanken, 2) die Echtzeitverarbeitung betriebswirtschaftlicher Ereignisse und 3) die Mehrsprachigkeit der Software. Sie sind der Schlüssel zum Verständnis der rein technischen Funktionsweise der Software, dienen aber auch dem Verständnis des Organisationsmodells, das dieser Software zugrunde liegt. In TEIL A wird die in der Einleitung formulierte erste Teilfrage beantwortet: Wie modelliert die Technik eine Organisation? Dafür erörtere ich in diesem Kapitel die informationstechnischen Grundlagen und gehe auf unterschiedliche theoretische Ansätze in der Datenbankentwicklung ein.

1.1 D IE D ATENBANKEBENE : V ON „ NAVIGATIONALEN “ ZU RELATIONALEN D ATENVERKNÜPFUNGEN In der Geschichte moderner Datenbanksysteme sind die Namen Charles W. Bachman und Edgar F. Codd nicht wegzudenken (vgl. Summerfield 2009). Bachman arbeitete in den 1960er Jahren zunächst als Ingenieur und Computerspezialist im US-amerikanischen Chemiekonzern Dow Chemical, später wechselte er zu General Electric. In den 1960er Jahren wurden Programme und Daten in Unternehmen noch auf Lochkarten gestanzt, in Stapeln zusammengestellt, in ein Datenlesegerät eingelegt und die eingelesenen Daten auf Magnetbändern gespeichert. Die Datenabfrage erfolgte sequenziell, indem die auf dem Band gespeicherten Daten nacheinander gelesen wurden. Diese Zugriffsmethode war relativ umständlich, denn einzelne Datensätze wie der Kontostand, der Lagerbestand oder der Produktionsplan in einem Unternehmen konnten nicht direkt abgerufen werden (vgl. Bachman 1973: 272). Um die entsprechenden Daten auf

D IE

STANDARDISIERTE

S OFTWARE

| 35

dem Datenspeicher herauszusuchen, mussten sämtliche Dateien nacheinander überprüft werden. Mit der Weiterentwicklung der Speichermedien vergrößerte sich zwar der Datenspeicherplatz und letztlich auch die Geschwindigkeit der Datenverarbeitung, am grundlegenden Prinzip der Stapelverarbeitung änderte sich jedoch nichts. Erst durch die Vergabe verschiedener Indizes für Dateien konnten die Suchwege für einen bestimmten Datensatz abgekürzt werden. Die Magnetbänder konnten an die markierten Stellen vor- oder zurückgespult werden. Auf der Grundlage dieser indexbasierten Zugriffsmethode entwickelte Bachman Anfang der 1960er Jahre für seinen Arbeitgeber General Electric das erste Datenbankmanagementsystem IDS (Integrated Data Store), das einen direkten, vorab festgelegten Zugriff auf Datensätze ermöglichte.10 Bachmans Datenbankmodell steht für das navigationale Prinzip in der Datenbankentwicklung und soll im Folgenden vorgestellt werden. 1.1.1 Hierarchische und Netzwerk-Datenbankmodelle Von der Struktur einer Datenbank, dem Datenbankmodell, hängt ab, wie Daten gespeichert und verarbeitet werden (vgl. Ottmann & Widmayer 2011: 3). Die älteste Datenbankstruktur ordnet Datensätze hierarchisch in einer Baumstruktur an, d.h. jeder Datensatz hat genau einen Vorgänger, nur ein Datensatz bildet davon eine Ausnahme – die Wurzel der Baumstruktur. Dazu ein einfaches Beispiel.

10 Die Angaben zur Person von Bachman und seinen Arbeitgebern basieren auf der Darstellung auf der Internetseite der ACM (Association for Computer Machinery). Quelle: http://amturing.acm.org/award_winners/bachman_1896680.cfm; Zugriff am 01.03.2013.

36 | D AS P ROJEKT SAP

Abbildung 4: Das hierarchische Datenbankmodell

Quelle: Eigene Darstellung

Durch eine solche hierarchische Datenstruktur lassen sich lediglich 1:1 und 1:n Beziehungen zwischen Datensätzen darstellen. In Lehrbüchern wird diese Struktur deshalb als „Vater-Sohn-Beziehung“ bezeichnet (Noak 2009: 9). Ein Vater kann mehrere Söhne haben, ein Sohn aber nur einen Vater. Der Name des Kunden (A) bildet die Wurzel, Bestellungen und Posten bilden die Knoten des Hierarchiebaums. Jeder Kunde kann mehrere Bestellungen (A1, A2, A3) mit verschiedenen Posten (A11, A12, A21 usw.) aufgeben. Für jeden Kunden können Daten über Bestellungen und Posten abgefragt werden. Die Anzahl der Bestellungen eines bestimmten Produktes können hingegen nicht direkt abgefragt werden, sie müssen umständlich über die Kundenbestellungen ermittelt werden.11 Auf Basis dieses hierarchischen Datenbankmodells entwickelte Bachman das erste kommerzielle Datenbankmanagementsystem, das sogenannte NetzwerkDatenbankmodell. Mit ihm konnten nicht nur 1:n-Beziehungen, sondern auch m:n-Beziehungen (m, n ∈ N) dargestellt werden. Dies soll wieder an einem Beispiel illustriert werden. Zu einer Abteilung gehören mehrere Mitarbeiter, in der

11 Das erste Datenbankprodukt, das auf dem hierarchischen Datenbankmodell basierte und in mehreren US-amerikanischen Konzernen verwendet wurde, hat seinen Ursprung in einer Kooperation zwischen IBM, Rockwell International Corporation, einem Konzern für Luft- und Raumfahrttechnik, und dem Maschinenbauunternehmen Caterpillar. Die Datenbank IMS (Information Management System) war zuerst für das Apollo-Mondprogramm der NASA entwickelt worden, um die Vielzahl von Daten über die Komponenten in Stücklisten zu verwalten. Bis heute wird das Datenbankprodukt IMS weiterentwickelt. Es wird vor allem in Banken und Versicherungen eingesetzt, um Massendaten nach einem immer wiederkehrenden Abfragemuster auszuwerten (vgl. Liedloff & Bromberger 2009: 572f.; Aschenbrenner 2010).

D IE

STANDARDISIERTE

S OFTWARE

| 37

Abteilung wird an mehreren Projekten gearbeitet, an jedem Projekt arbeiten mehrere Mitarbeiter, die wiederum an mehreren Projekten beteiligt sein können (vgl. Noak 2009: 10). Diese verschiedenen m:n-Beziehungen stellte Bachman zunächst grafisch dar und entwickelte Methodenwerkzeuge (z. B. Indizes), die dem Datenbank-Programmierer helfen sollten, unterschiedliche Suchpfade in einer Datenbank zu markieren. Die Aufgabe eines Programmierers bestand für Bachman darin, spezielles Wissen aufzubauen, um sich innerhalb von Datenbanken zurechtzufinden. „There is a growing feeling that data processing people would benefit if they were to accept a radically new point of view, one that would liberate the application programmer’s thinking from the centralism of core storage and allow him the freedom to act as a navigator within a database. To do this, he must first learn the various navigational skills; then he must learn the rules of the road to avoid conflict with other programmers as they jointly navigate the database information space.“ (Bachman 1973: 270)

Für Bachman erfüllte der Programmierer die Rolle eines Navigators.12 Die von ihm entwickelte indexbasierte Zugriffsmethode vereinfachte und beschleunigte Datenbankabfragen sowie die Aktualisierung von Datenfeldern. Die wichtigste Navigationsmethode für Programmierer bestand in der Vergabe von sogenannten Schlüsseln. Ein Primärschlüssel setzt sich im Allgemeinen aus einem eindeutigen oder mehreren eindeutigen Attributen zusammen. Er ermöglicht die eindeutige Identifizierung eines Datenobjektes. Mithilfe von Sekundärschlüsseln können komplexe Abfragen von Datenbanken durchgeführt werden. Wenn viele Se-

12 Für seine Arbeiten zur Weiterentwicklung von hierarchischen Datenbankmodellen und insbesondere für seine Bemühungen zur Standardisierung auf diesem Gebiet erhielt Bachman im Jahr 1973 den Turing-Award. Der programmatische Titel von Bachmans Rede anlässlich der Preisverleihung lautete: The Programmer as Navigator. Der Preis wird jährlich von der ACM an Personen verliehen, die sich um die Entwicklung der Informatik verdient gemacht haben. Die Auszeichnung für den Ingenieur Bachman war insofern ungewöhnlich, weil dieser Preis traditionell an Wissenschaftler vergeben wird, die an Universitäten und anderen Forschungseinrichtungen tätig sind. Bachman hingegen war als Ingenieur in verschiedenen Wirtschaftsunternehmen beschäftigt und gründete später eigene Unternehmen. In der Wissenschaftsforschung wird der Begriff „research technologist“ (Joerges & Shinn 2001: 2f.) verwendet, um Forscher und Forscherinnen zu charakterisieren, die zwischen Industrie, Universitäten und anderen staatlichen Einrichtungen (z. B. Militär) angesiedelt sind.

38 | D AS P ROJEKT SAP

kundärschlüssel vergeben worden sind, ist es für den Programmierer allerdings schwer, die Übersicht zu behalten. Bachman schlug deshalb vor: „In addition to a record’s primary key, it is frequently desirable to be able to retrieve records on the basis of the value of some other fields. For example, it may be desirable, in planning ten-year awards, to select all the employee records with the year-of-hire field value equal to 1964. Such access is retrieval by secondary data key. [...] With small or medium-sized files, it is feasible for a database system to index each record in the file on every field in the record. Such totally indexed files are classified as inverted files. In large active files, however, it is not economical to index every field. Therefore, it is prudent to select the fields whose content will be frequently used as a retrieval criterion and to create secondary indices for those fields only.“ (Bachman 1973: 273)

Häufig gestellte Datenbankabfragen sollten im Netzwerk-Ansatz von Bachman vorstrukturiert werden. Der Programmierer speichert dafür die entsprechenden Datensätze in record sets. Datensätze eines record sets können mit den Datensätzen eines anderen record sets verknüpft werden. So entsteht ein gerichteter Graph. In folgenden Abbildung sind die record sets MITARBEITER und PROJEKT für eine Unternehmenseinheit (z.B. ABTEILUNG A) dargestellt. Da in dem Unternehmen mehrere Mitarbeiter in mehreren Projekten arbeiten, muss eine beidseitige Beziehung zwischen diesen Datensätzen abgebildet werden. Möglich wird dies durch das Einfügen des zusätzlichen record set MITARBEITER-PROJEKT. Hierdurch entsteht eine netzwerkartige Struktur der Datenbank.

D IE

STANDARDISIERTE

S OFTWARE

| 39

Abbildung 5: Das Netzwerk-Datenbankmodell

Quelle: Eigene Darstellung

Gegenüber einem hierarchischen Datenbankmodell zeichnet sich das NetzwerkDatenbankmodell dadurch aus, dass verschiedene Suchwege möglich sind, um einen bestimmten Datensatz abzurufen. Außerdem können verschiedene Beziehungen zwischen Daten direkt abgebildet werden, ohne einen Datensatz mehrfach speichern zu müssen. Allerdings müssen in beiden Datenbankmodellen die Beziehungen zwischen Daten und ihren Attributen bereits beim Aufbau der Datenbank festgelegt werden. Abfragen sind nur unter Zuhilfenahme von stets wiederkehrenden Mustern möglich, was die Kombinationsmöglichkeiten von Daten einschränkt. Ohne genaues Wissen über die Speicherstruktur sind Datenbankabfragen überhaupt nicht durchführbar. Bachman forderte eine ingenieurtechnische Ausbildung für Programmierer. Im Zentrum der Ausbildung sollten seiner Meinung nach die Standardisierung von Methoden und Werkzeugen zum Aufbau komplexer Datenbanken stehen (vgl. Bachman 1973: 279).13

13 Bachmans Netzwerk-Datenmodell diente 1971 als Vorlage für die Entwicklung von Datenbankmanagementsystemen und wurde von CODASYL (Conference on Data Systems Languages), einem Zusammenschluss von Vertretern der US-Regierung, des Militärs, der Privatwirtschaft und Computerherstellern unterstützt (vgl. Chamberlin 2012; Schlageter & Stucky 1983).

40 | D AS P ROJEKT SAP

1.1.2 Der Gegenentwurf: Das relationale Datenbankmodell Einen vielbeachteten Gegenentwurf zum Netzwerk-Datenmodell legte der Mathematiker Edgar F. Codd vor. Codd arbeitete im Forschungslabor des USamerikanischen Computerherstellers IBM. Dort entwickelte er die mathematisch-theoretischen Grundlagen für das relationale Datenbankmodell. Sein Artikel A Relational Model of Data for Large Shared Data Banks (1970) wurde zu einem der wichtigsten theoretischen Referenzpunkte in der Entwicklung moderner Datenbanktechniken. Codds Vorschlag löste eine Kontroverse zwischen Vertretern der etablierten Netzwerk-Datenmodelle auf der einen Seite (z. B. Bachman 1974; Sibley 1974; Lucking 1974) und Befürworten des neuen mathematischen Ansatzes (z. B. Codd & Date 1974) auf der anderen Seite aus. Der Technikhistoriker David Gugerli (2009) zeichnet diese in Konferenzberichten dokumentierte Kontroverse nach. Während Vertreter des Netzwerkmodells die technische Performanz und damit den gut kontrollierten Einsatz einer technischen Ressource in den Vordergrund rückten, argumentierten die Befürworter des relationalen Modells für die mathematische Eleganz und die Flexibilität bei der Datenbankabfrage (vgl. ebd. 75). Das Programm des relationalen Ansatzes fasst Codd im ersten Satz seines Artikels so zusammen: „Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation). [...] Activities of users at terminals and most application programs should remain unaffected when the internal representation of data is changed and even when the same aspects of the external representation are changed.“ (Codd 1970: 377)

Das Leitbild für den Entwurf der relationalen Datenbank war für Codd der „casual user“ (ebd.). Gemeint ist ein Nutzer, der ohne spezielles Programmierwissen Datenbanksysteme für flexible und spontane Abfragen verwenden sollte. Eine entscheidende Neuerung des relationalen Ansatzes im Vergleich zu konventionellen Datenbanken (Netzwerk oder Hierarchie) war, dass die logische Organisation vom materiellen Speichermedium der Datenbank abgekoppelt werden sollte. Die Verknüpfungen zwischen Datensätzen hatten nichts mit ihrer Anordnung auf dem Speichermedium zu tun, sondern waren mathematische Operationen. Wie diese Operationen materiell realisiert werden sollten, war für den Mathematiker Codd zunächst einmal kein Thema.14 Der relationale Ansatz steht für ein neues

14 Die als Gründerväter des modernen Computers geltenden Mathematiker John von Neumann und Alan Turing gingen ebenso vor. Die elementaren Abläufe eines Rech-

D IE

STANDARDISIERTE

S OFTWARE

| 41

Prinzip in der Datenbankentwicklung, das sich vom älteren, navigationalen Prinzip der hierarchischen und Netzwerk-Datenbankmodelle grundlegend unterscheidet. Donald D. Chamberlin und seine Kollegen verwenden die folgende Abbildung, um das Prinzip navigationaler Datenbanken „Fig.1(a)“ dem Prinzip relationaler Datenbanken „Fig. 1(b)“ gegenüberzustellen. Abbildung 6: Gegenüberstellung des „navigationalen“ und relationalen Datenbankmodells

Quelle: Eigene Darstellung nach Chamberlin et al. (1981: 633)

ners verortete von Neumann in hypothetischen Elementen. Turing entwickelte keinen materiellen Aufbau eines Rechners, sondern betrachtete mit einem Modell das Eingabe-/Ausgabeverhalten der Maschine. Mit der Turingmaschine („Papiermaschine“) wurde die Arbeitsweise eines Computers also zunächst simuliert (vgl. Stach 2001: 208; Heintz 1993: 106).

42 | D AS P ROJEKT SAP

Welchen Preis der Lieferant (Acme) für Schrauben (bolt, nut etc. ) verlangt, wird im Modell der navigationalen Datenbank durch den Knotenpunkt der Datensätze für Lieferanten (SUPPLIERS) und Material (PARTS) angezeigt. Die entsprechende Datenbankabfrage lautet: Welcher Lieferant bietet den günstigsten Preis für Schrauben? Bei dieser Datenbankabfrage navigiert das Programm entlang der Knotenpunkte (PRICES), bis eine Antwort auf die Frage gefunden ist. Der Programmierer hat dafür im Vorhinein exakt festgelegt, wie das Programm ausgeführt werden soll. Der Algorithmus der Datenbankabfrage ist untrennbar mit der Datenbankstruktur verbunden. Welche Informationen mit dem navigationalen System überhaupt abgerufen werden können, hängt einerseits davon ab, welche Datensätze in die Speicherstruktur übernommen wurden (contents of records), und andererseits, wie diese Datensätze bereits untereinander verknüpft sind. Problematisch ist diese Art der Datenbankabfrage deshalb, weil Daten in verschiedenen Datenbanken gespeichert sein können, in denen unterschiedliche Bezeichnungen für Datenverknüpfungen verwendet worden sind (z.B. links, sets, chains oder parents) (vgl. ebd.: 633). Eine Abfrage kann also auch ins Leere laufen oder falsche Ergebnisse produzieren, wenn Daten aufgrund ungenauer oder uneinheitlicher Bezeichnungspraktiken nicht berücksichtigt werden. Beim relationalen Datenbankmodell können Daten hingegen immer wieder neu miteinander in Bezug gesetzt werden. Dieses Datenbanksystem besteht aus Hunderten Tabellen. In diesen Tabellen werden Daten in ihre elementaren Bestandteile zerlegt, d.h. Attribute eines Datensatzes werden in den Spalten geordnet und Zeilen bezeichnen die Träger dieser Attribute. Um mathematische Relationen darzustellen, werden üblicherweise Tabellen verwendet. Tabellen werden universell verstanden und sind weniger abstrakt als Relationen. Trotzdem hat diese Darstellungsform einen Makel: Sie vermittelt den Eindruck, dass die jeweilige Position von Daten in einer Tabelle für einen Datenzugriff entscheidend ist. Tatsächlich ist der Informationsgehalt einer Tabelle von einer festen Stellordnung unabhängig. Für relationale Datenbanken ist die jeweilige Anordnung der Spalten von links nach rechts und der Zeilen von oben nach unten irrelevant. Die Unabhängigkeit von einer festen Stellordnung erläutert Codd folgendermaßen: „There is a large difference in implementation complexity between tabular systems, in which the programmer does his own navigation, and relational system, in which the system does the navigation for him, i.e., the system provides automatic navigation.“ (Codd 1981: 398)

Nicht der Programmierer, der die Datenbank in einer bestimmten Weise aufgebaut hat, leistet die Navigation, sondern das Datenbanksystem selbst. Das Er-

D IE

STANDARDISIERTE

S OFTWARE

| 43

gebnis einer Datenbankabfrage resultiert ausschließlich aus dem Wertebereich von Tabellen und nicht aus einer bestimmten Stellordnung oder einer bereits bestehenden Verlinkung zwischen Datensätzen. Komplexe Datenbankabfragen sind möglich, ohne dass der Nutzer einen entsprechenden Algorithmus für die Datensuche angeben muss. „Tell me what you want, not how to find it“, lautete von Beginn an der Grundsatz einer solchen relationalen Abfragesprache (vgl. Wade & Chamberlin 2012: 39). Die Daten waren von ihrer physischen Speicherstruktur unabhängig. Der Nutzer musste deshalb auch über keine detaillierten Kenntnisse der systemtechnischen Umsetzung der Datenspeicherung und des Datenzugriffs verfügen. Der relationale Ansatz erfordert allerdings einen mathematisch anspruchs-volleren Begriffsapparat als die Verwendung von Datenbanken, die auf den hierarchischen oder Netzwerk-Datenmodellen basiert. Modus relationaler Datenverarbeitungssysteme sind mengentheoretische Operationen. Für die relationale Abfragesprache schlug Codd acht Grundoperationen vor: Die Mengenoperationen Vereinigung (A∪B), Durchschnitt (A∩B), Differenz (A\B) und Kartesisches Produkt (A×B) sowie die zusätzlichen relationalen Operationen Selektion, Projektion, Verbund und Division (vgl. Codd 1970: 383ff.).15 „[Codd] wanted to raise the level of abstraction, and at this new level he proposed a radically different way of working with the data, through that logical view. The mapping from the logical view to the physical organization would be entirely the responsibility of the DBMS [Abkürzung für Database Management System: H. M.] [...]. [N]o more nested loops, no more pointer chasing, no more dependence on the physical structure, and significantly reduced exposure to changes in the database definition at the logical level.“ (Darwen 2012: 2)

Mit dem relationalen Ansatz können Daten auf Basis der oben aufgelisteten mathematischen Operationen theoretisch unbegrenzt miteinander kombiniert werden. Dazu ein einfaches Beispiel, das die Mengenoperationen illustriert. In den Tabellen sind jeweils Datensätze der Mitarbeiter aufgelistet, die für PROJEKT A und PROJEKT B arbeiten.

15 Das Kartesische Produkt ist eine Operation, um dieselbe Anzahl von Zeilen zweier Tabellen zu kombinieren. Mit der Projektion werden einer Tabelle bestimmte Spalten entnommen, mit der Selektion hingegen bestimmte Zeilen. Bei der Division werden die Operationen Projektion und Selektion hintereinander ausgeführt.

44 | D AS P ROJEKT SAP

Abbildung 7: Tabellarische Darstellung von Relationen

Quelle: Eigene Darstellung

Die Tabellen zeigen die Relationen RelA (Menge aller Mitarbeiter im PROJEKT A) und RelB (Menge aller Mitarbeiter im PROJEKT B). Führt man die Operation Vereinigung aus, werden alle Daten entnommen, die zu den Projektmitarbeitern und Projektmitarbeiterinnen vorhanden sind – unabhängig davon, in welchen Tabellen sie aufgeführt sind. Eine Bedingung für die Datenverknüpfung ist, dass die Tabellen semantisch identische Attribute („Name” „Vorname”, „Standort”, „Qualifikation”) enthalten. Sie sind also typenkompatibel. Die mengentheoretische Operation entnimmt den beiden Tabellen die Werte aus allen Zeilen. Der formale Ausdruck für diese Operation lautet: RelA ∨ RelB : = {t | t RelA ∨ t RelB} Mit der Operation Differenz werden Datensätze bzw. Tupel (t) entnommen, die entweder in der Tabelle PROJEKT A oder der Tabelle PROJEKT B enthalten sind. Es werden also nur Zeilen aus einer der beiden Tabellen entnommen. Die Differenz ist die Menge aller Datensätze bzw. Tupel (t), die in Tabelle A aber nicht gleichzeitig in Tabelle B enthalten sind. Der formale Ausdruck ist: RelA \ RelB : = {t | t RelA ∧ t ∉ RelB} Mit der Operation Durchschnitt werden jene Daten entnommen, die sowohl in der Tabelle Projekt A als auch in der Tabelle Projekt B enthalten sind. RelA ∩ RelB : = {t | t RelA ∧ t ∈ RelB}

D IE

STANDARDISIERTE

S OFTWARE

| 45

Das Ergebnis für das Beispiel zeigt diese tabellarische Darstellung. Abbildung 8: Tabellarische Darstellung der Ergebnisrelation

Quelle: Eigene Darstellung

Der Mathematiker Codd wollte mit dem relationalen System erreichen, dass sich potenzielle Nutzergruppen in einem Unternehmen (z. B. Programmierer, Managerin und Sachbearbeiter) untereinander über Daten und die Möglichkeiten ihrer Auswertung verständigen können. Mithilfe des relationalen Sprachkonzeptes sollte es allen Benutzern einer Datenbank möglich sein, komplexe Datenbankabfragen selbst zu formulieren. Für seine Arbeiten zu Theorie und Praxis relationaler Datenbanken erhielt Codd 1981, wie Bachman einige Jahre zuvor, den Turing-Award.16 Doch Programmierer und mögliche Abnehmer des Datenbanksystems in Unternehmen blieben dem relationalen Ansatz lange Zeit gegenüber skeptisch. Hatten sie doch in den komplexen Aufbau von Netzwerk-Datenbanken investiert. Die Umstellung auf ein relationales System war mit Kosten und Aufwand verbunden. Deshalb setzten sie auch weiterhin auf das Spezialistenwissen ihrer Programmierer, um Datenbankabfragen durchzuführen. „Instead of welcoming a theoretical foundation as providing soundness, the attitude seems to be: if it’s theoretical, it cannot be practical. The absence of a theoretical foundation for almost all nonrelational DBMS is the prime cause of their ungepotchket [jiddischer Ausdruck für Flickwerk: H. M.] quality.“ (Codd 1981: 401)

Codd hatte stets die praktischen Vorteile seines theoretischen Ansatzes betont. Er verwendete in seinen Datenbankabfragen allerdings eine Vielzahl mathematischer Terme und Symbole. Eine einfachere Abfragesprache sollte die Akzeptanz des relationalen Datenbanksystems bei potenziellen Nutzern erhöhen. Die Nutzer dieses Systems waren vor allem Programmierer, die relationale Datenbanken als technisches Hilfsmittel für die Entwicklung komplexer Anwendungsprogramme verwendeten (vgl. Haigh 2007: 81). Darunter waren auch die Entwickler von

16 Siehe hierzu die Erläuterungen in Fußnote 12 in diesem Kapitel.

46 | D AS P ROJEKT SAP

SAP, die die praktischen Vorteile des relationalen Ansatzes für die vergleichsweise einfache Datenbeschaffung für ihre komplexen betriebswirtschaftlichen Anwendungsprogramme nutzten. Darauf soll im Folgenden eingegangen werden. 1.1.3 Die Datenbeschaffung mithilfe logischer Datenbanken System R war Anfang der 1970er die Bezeichnung für zwei verschiedene Techniken. Im Unternehmen IBM war der Buchstabe R ein Platzhalter für das System relationaler Datenbanken. Im Unternehmen SAP hingegen wurde so das Realzeitsystem bezeichnet. Der Entwicklungspfad dieser beiden Techniken verlief bis Mitte der 1980er noch getrennt voneinander. Bevor auf die besondere Architektur des Realzeitsystems R/3 und seine Entstehungsgeschichte genauer eingegangen wird, folgen an dieser Stelle noch einige Erklärungen zum relationalen Datenbankmanagementsystem. System R war ein Forschungsprojekt, das im Jahr 1973 am IBM-Standort San José aufgesetzt wurde. Zwar gab es auch zuvor Entwicklungsaktivitäten zur relationalen Datenbanktechnik von IBM-Forschungsmitarbeitern. Diese waren jedoch weit über den Konzern auf verschiedene Standorte in den USA und Europa verstreut. Mit dem Projekt sollten die Arbeiten an einem Standort gebündelt werden. Ein wichtiger Baustein war die Entwicklung einer high-level search and query language (vgl. Chamberlin et al. 1981). Während Codd eine Vielzahl mathematischer Symbole und Terme genutzt hatte, um Datenbankabfragen zu formulieren, sollte im System R ein Sprachkonzept entwickelt werden, das nicht auf mathematischen Formeln, sondern auf englischen Schlagworten basierte. Die Abfragen sollten vom Nutzer über eine Tastatur eingegeben, gelesen und intuitiv verstanden werden können. Die mengentheoretischen Grundlagen des relationalen Datenbanksystems änderten dieses neue Sprachkonzept nicht, ließen die abstrakten Grundlagen jedoch einfacher erscheinen. SQUARE (Specifying Queries As Relational Expressions) war die erste Version der Sprache, kurze Zeit später folgte SEQUEL (Structured English Query Language). „SEQUEL is intended for interactive, problem solving used by people who have need for interaction with a large database but who are not trained programmers. This class of users includes urban planners, sociologists, accountants, and other professionals.“ (Astrahan & Chamberlin 1975: 580)

Auch fachfremde Nutzergruppen sollten auf Anhieb die folgende Abfrage begreifen können: „Select salary from employee where manager equals John

D IE

STANDARDISIERTE

S OFTWARE

| 47

Smith“ (ebd.). Aus dem Projekt System R ging letztlich die relationale Datenbanksprache SQL (Structured Query Language) hervor. Sie wird bis heute verwendet, um Datenbestände in relationalen Datenbanken zu bearbeiten, d.h. Daten einfügen, verändern und löschen, sowie abzufragen. Das American National Standard Institute (ANSI) erklärte SQL 1986 zum Standard für Datenbanken. Ein Jahr später nahm auch die International Organization for Standardization (ISO) die relationale Datenbankabfragesprache in ihren Standard-Katalog auf. Sie wird heute von allen Herstellern von Datenbanksystemen unterstützt, jedoch unterschiedlich im Sprachumfang und teilweise in Dialekten verwendet. Die Forschungsergebnisse aus dem Projekt System R vermarktete IBM zunächst kaum. Zwar entwickelte die Projektgruppe, die im Kern aus einem Dutzend Forschungsmitarbeitern bestand, verschiedene Prototypen. Diese wurden jedoch lediglich in drei Unternehmen installiert. Der relationale Ansatz hatte über Jahre hinweg im Konzern den Status einer experimentellen Technik (vgl. Gugerli 2007: 23). „IBM dipped a toe into the relational waters when it introduced SQL/DS, a decision support RDMS [Abk. für Relational Database Management System, H. M.] in 1981, which was based on the System R code developed at IBM’s San Jose research laboratory during the 1970s. [...] Two years later, in June 1983, the company announced DB2, its first mainstream, fully relational product. The announcement legitimatized the relational concept and was an inflection point in the ascendancy of relational technology. Before DB2, relational technology was admired by many and adopted by some, but most conservative installations stayed with their proven, no-relational products.“ (CampbellKelly 2012: 10)

Die relationale Datenbanktechnik war für IBM zunächst ein Nischenprodukt.17 Erst im Jahr 1983 veröffentlichte IBM ein relationales Datenbanksystem für seine Großrechner. Das Datenbanksystem DB2 wurde vor allem in Konzernen als sogenanntes Entscheidungsunterstützungssystem verwendet. Um das Tagesgeschäft im Unternehmen unterstützen und Geschäftsprozesse abbilden zu können, waren Datenbanktransaktionen ohne nennenswerte Zeitverzögerungen eine not-

17 Andere Unternehmen etablierten sich Anfang der 1980er in dieser Marktnische, weil sie die Technik fortentwickelten. Beispielsweise spezialisierten sich die Unternehmen Oracle und Ingres auf die Herstellung relationaler Datenbanksysteme für kleinere Rechner. Diese Rechner füllten keine Räume mehr. Sie hatten nur noch die Größe eines oder mehrerer Schränke und waren deutlich kostengünstiger als die bislang üblichen Großrechner.

48 | D AS P ROJEKT SAP

wendige Voraussetzung. Die erste Version von DB2 unterstützte die rechenintensive Online-Transaktionsverarbeitung (OLTP) noch nicht. Eine neue Version von DB2, die auch diese technische Anforderung erfüllte, war erst drei Jahre später erhältlich (vgl. Campbell-Kelly 2012: 10). Im Jahr 1987 kündigte IBM eine neue Systems Application Architecture (SAA) an, die eine Reihe neuer technischer Standards für die systemübergreifende Softwareentwicklung für IBM-Rechner erfüllte und auch die Umstellung auf eine relationale Datenbanktechnik vorsah.18 Das casual user-Nutzerkonzept für die relationale Datenbanktechnik, wie Codd es vorgesehen hatte, setzte sich allerdings nicht durch. Bachman, der in seinem Ansatz den Programmierern nicht nur bei der Entwicklung, sondern auch bei der Verwendung von Datenbankmanagementsystemen (DBMS) eine zentrale Rolle eingeräumt hatte, sollte zumindest in dieser Hinsicht Recht behalten. DBMS wurden selten direkt als (Management-)Informationssysteme für den Organisationsalltag in Unternehmen verwendet. Die Datenbanksysteme bewährten sich vielmehr indirekt – als technisches Hilfsmittel für Programmierer. So nutzten auch die Entwickler von SAP die praktischen Vorteile des relationalen Ansatzes für die vergleichsweise einfache Datenbeschaffung. Denn eine wichtige Bedingung für die Entwicklung von SAP-Software war die technische Möglichkeit zur Auswertung großer Datenmengen.19 Um möglichst einfach auf Datenmengen zugreifen zu können, integrierten die Entwickler in die Programmiersprache ABAP bereits früher das Konstrukt der logischen Datenbanken. Damit wurde auf der Datenbankebene die Logik der Datenbeschaffung von der Logik der Datenauswertung getrennt. Interviewpartner G, der seit vielen Jahren im Unternehmen SAP als Entwickler arbeitet, erläutert diese Idee. „Eine Idee ist, wir möchten der Anwendungsentwicklung die Datenbeschaffung leicht machen. Und dieser Anspruch wurde auch schon in R/2-Zeiten eingeführt, insbesondere über die logischen Datenbanken, was ein proprietäres Konstrukt war und was wunderbar funk-

18 Mit dem SAA-Konzept sollten erstmals alle IBM-Rechner und deren Betriebssysteme – vom PC über mittelgroße Rechner bis hin zu Großrechnern – informationstechnisch so vereinheitlicht werden, dass die Entwicklung von Anwendungsprogrammen für alle IBM-Rechnertypen vereinfacht werden konnte (vgl. Meissner 1997: 69). 19 Große Datenmengen bedeuteten in den 1980er Jahren einige Megabyte (106 Byte). Dasselbe Adjektiv beschreibt heute einige Petabyte (1015 Byte). Diesen technischen Fortschritt sowie seine sozialen Voraussetzungen und Folgen werden in KAPITEL 1.3 am Beispiel des Unicode-Zeichensatzes erläutert.

D IE

STANDARDISIERTE

S OFTWARE

| 49

tioniert hat, auch mit den hierarchisch organisierten Datenbeständen und später mit der relationalen Datenbank. [...] Die Idee, wir machen es der Anwendungsentwicklung, einfach auf die Datenbestände auf der Datenbank zuzugreifen, stammt aus den vorrelationalen Zeiten. Die wurde dann übertragen auf die relationalen Zeiten, indem wir dann eine SQLAnbindung gemacht haben.“

Dieselbe Datenbeschaffungslogik ist Grundlage für viele unterschiedliche Auswertungslogiken. Logische Datenbanken sind also keine Datenbanken im eigentlichen Sinne. Es handelt sich vielmehr um wiederverwendbare Programme auf der Anwendungsebene, die den betriebswirtschaftlichen Anwendungsprogrammen Daten zur Verfügung stellen. Als die Entwicklung von R/3 Mitte der 1980er Jahre begann, kombinierten die Softwareentwickler ihre komplexen betriebswirtschaftlichen Programme mit relationalen Datenbanken: „An ERP package and a relational database became the most popular option for all but the most intensive transaction-processing environments“ (Campbell-Kelly 2012: 13). Das relationale Datenbankmodell setzte sich als Standard gegenüber dem NetzwerkModell durch. Erst durch den besonderen Aufbau der Software konnten die komplexen Datenverknüpfungen auf Basis relationaler Datenbanken realisiert werden. Darauf wird im nächsten Abschnitt genauer eingegangen. 1.1.4 Die Softwarearchitektur: Verteiltheit und Skalierbarkeit Bis Anfang der 1990er Jahre basierte SAP-Software noch auf einer zentralistischen Rechnerarchitektur. R/1 in den 1970er Jahren und R/2 in den 1980er Jahren liefen auf zentralen Großrechnern. Diese Rechner waren im wortwörtlichen Sinne raumfüllend und standen im sogenannten Rechenzentrum eines Unternehmens. Zehntausende Benutzer konnten Ende der 1980er Jahre von einem Großrechner bedient werden. Es war ein Konzept mit „dem die Benutzer an einen Ort des Computers gebracht wurden, und da fand die logische Verarbeitung [von Daten: H. M.] statt“ (Plattner et al. 2000: 72). Die notwendige Rechnerleistung für die zunehmende Anzahl von Anwendungsprogrammen der Standardsoftware konnte mit diesem Aufbau allerdings nicht erreicht werden (vgl. ebd.: 73). Für die neue Softwareversion R/3 veränderten die SAP-Entwickler daher die zugrunde liegende Architektur. In der folgenden Abbildung ist die neue verteilte Rechnerarchitektur dem älteren zentralistischen Konzept gegenübergestellt.

50 | D AS P ROJEKT SAP

Abbildung 9: Zentralistische und verteilte Rechnerarchitektur

Quelle: Darstellung in Anlehnung an Diekmann & Hagenhoff (2003: 4)

In der verteilten Architektur sind mehrere (kleine) Rechner miteinander verbunden. Die einzelnen Rechner (A-X) übernehmen unterschiedliche Aufgaben (Prozess 1-n). In einem solchen Rechnerverbund oder -netzwerk werden Server und Clients unterschieden. Server bieten bestimmte Dienste (Rechnerleistungen) an und Clients nehmen Dienste vom Server in Anspruch (z.B. Datenbankabfragen). Ein einzelner Rechner im Verbund kann sowohl die Funktion eines Clients als auch die eines Servers übernehmen. Die sogenannte Client/Server-Archi-tektur wurde zum Markenzeichen von R/3. Die Verteilung auf mehrere kleinere Rechner wurde zum charakteristischen Kennzeichen von SAP-Software und später zum allgemeinen Standard in der Softwaretechnik. Die Verteilung der Programme auf viele Rechner machte es vielen Nutzern an mehreren Standorten gleichzeitig möglich, dieselbe Software zu verwenden und auf dieselben Daten zuzugreifen. Je nach Aufgabe variiert die Funktion eines Rechners im Verbund. Durch die Umstellung von einem teuren Großrechner auf kostengünstigere mehrere kleinere Rechner wird nicht nur die Rechnerleistung verteilt. Das gesamte Computersystem kann aufgrund dieser Client/Server-Architektur erweitert werden (vgl. Lassmann 2006: 496f.). Informatiker prägten dafür den Begriff der Skalierbarkeit (vgl. Hill 1990). Vertikale und horizontale Skalierbarkeit werden in der Fachliteratur voneinander unterschieden. Vertikal wird ein Rechner dann skaliert, wenn ihm Ressourcen hinzugefügt werden, indem der Speicherplatz vergrößert oder ein leistungsstärkerer Prozessor eingebaut wird. Die Steigerung der Rechnerleistung ist abhängig von der Leistungsfähigkeit der Hardware. Die Möglichkeit zur vertikalen Skalierbarkeit ist jedoch im Gegensatz zur horizontalen Skalierung begrenzt. Durch das Hinzufügen von Rechnern bzw. Knoten in

D IE

STANDARDISIERTE

S OFTWARE

| 51

einem Netzwerk verschiedener Rechner kann die Leistungsfähigkeit nahezu unbegrenzt gesteigert werden.20 Die Entwickler von SAP griffen mit der Umstellung von einer zentralistischen auf eine verteilte Rechner- und Softwarearchitektur auf eine Idee zurück, die ihren Ursprung im wissenschaftlichen Kontext der Softwareentwicklung hat. HP: „Man muss sich also vorstellen, Ende der 80er Jahre liefen die größten Systeme mit tausenden, zehntausenden Benutzern auf einer einzigen physischen Anlage. Diese hatte damals vielleicht vier oder sechs Prozessoren, aber nicht mehr. Man war also ganz beschränkt auf diese Rechnerarchitektur, und wir sind dann ausgebrochen beinahe in einem Akt der Verzweiflung und haben gesagt: Jetzt müssen wir das versuchen, was SUN so im wissenschaftlichen Bereich gerade angefangen hat: Rechnen auf ganz vielen Rechnern, d. h. Anwendungen auf ganz viele Rechner verteilen.“ (Plattner et al. 2000: 73)

IBM hielt weiterhin an einer zentralistischen Rechnerarchitektur fest. Allerdings hatte der Computerhersteller inzwischen auch mittlere, kostengünstigere Rechner in seine Produktfamilie aufgenommen. Die Entwickler von SAP planten die neue Softwareversion für mittelständische Unternehmen, weshalb R/3 auf einen kleineren IBM-Rechner (AS/400) abgestimmt wurde. HP: „Die Idee bei R/3 war, ein System für AS/400 zu entwickeln. AS/400 waren kleine Rechner, und wir wollten das untere Ende des Marktes abdecken, da R/2 am oberen Ende gut eingeführt war und wir keinerlei Pläne hatten, die R/2-Entwicklung einzustellen. R/3 sollte also das untere Ende des Marktes abdecken. Jetzt lief das System auf AS/400 aber nicht; es funktionierte physisch nicht.“ (Ebd.: 33)

Entwickelt hatten die Programmierer die einzelnen Softwarekomponenten auf mehreren kleinen Rechnern. Diese basierten alle auf dem Unix-Betriebssystem. Das Mehrbenutzer-Betriebssystem war von Ken Thompson und Dennis Ritchie (1974) programmiert worden, um die Entwicklung von Software auch auf kleineren Rechnern mit mehreren Nutzern zu ermöglichen. Thompson und Ritchie arbeiteten in den Bell Laboratories, die zum damals weltgrößten Telefonkonzern AT&T (American Telephone & Telegraph Corporation) gehörten. Gemeinsam

20 Das Internet ist ein paradigmatisches Beispiel für ein verteiltes System. Es illustriert die Bedeutung der Skalierbarkeit von Systemen, d. h. das Hinzufügen von Knotenpunkten (Rechnerressourcen), um weitere Nutzer zuzulassen. Mit ein paar wenigen Rechnern und Nutzern hat es angefangen; mittlerweile sind Millionen Rechner und Nutzer über das Internet miteinander verbunden (vgl. Bunz 2009: 27ff.).

52 | D AS P ROJEKT SAP

mit dem MIT und General Electric arbeiteten sie an einem sogenannten Mehrbenutzerbetriebssystem. Das Betriebssystem Multics (Multiplexed Information and Computing Service) scheiterte jedoch an seiner eigenen Komplexität. Es lief selbst auf den schnellsten verfügbaren Rechnern nur behäbig. Thompson und Ritchie entwickelten später im Alleingang Unix. Es zeichnete sich aus durch seine „Einfachheit, Eleganz und die leichte Bedienbarkeit“ (Ritchie & Thompson 1974). Mehrere Benutzer konnten bei einer leistungsschwächeren Hardware gleichzeitig an Datensätzen arbeiten, ohne sich dabei gegenseitig zu behindern. Obwohl das Betriebssystem für unterschiedliche Anwendungen erfolgreich getestet worden war, vermarktete Bell das Betriebssystem nicht als neues Softwareprodukt. Es war dem Mutterkonzern AT&T im Jahr 1956 in den USA aufgrund kartellrechtlicher Gründe gesetzlich untersagt worden, auf dem Markt für Computer tätig zu werden (vgl. Ceruzzi 2012: 11). Thompson und Ritchie stellten Unix, einschließlich des dazugehörigen Quellcodes, kostenlos verschiedenen Universitäten zur Verfügung. „Beyond technical considerations“, so Ritchie in einem Interview, „there were sociological forces that contributed to its success. […] [I]t appeared at a time when alternatives to large, centrally administered computation centers were becoming possible; the 1970s were the decade of the minicomputer. Small groups could set up their own computation facilities“ (Ritchie 1984: 758). Unix wurde für viele Universitäten ein wichtiges Element in der Ausbildung von Informatikern: „It was used by nearly every university database class because UNIX and PDP-11’s had become the de facto standard for computer science education“ (Rowe 2012: 59). Das Mehrfachbenutzer-Betriebssystem etablierte sich nicht nur im wissenschaftlichen Bereich, sondern auch in der kommerziellen Softwareentwicklung; so auch bei den Entwicklern beim Softwarehersteller SAP. Über 2.000 SAP-Entwickler hatten zum Programmcode für das R/3-Modul im Bereich der Fertigung beigetragen (vgl. ebd. 32). Beim Versuch diese Programmkomponenten auf einem Rechner zusammenzuführen, fiel ein Prozessor nach dem anderen aus. Die Komplexität des Anwendungsprogramms überforderte den Rechner. Die Lösung des Problems der unzureichenden Rechnerkapazität wird von Interviewpartner G rückblickend so bewertet. „Dann hatte eben jemand wirklich die geniale Idee, das soll auf dem Unix-Server laufen. Und dann hatte jemand die geniale Idee, das Pferd können wir sozusagen auch von der anderen Seite her aufzäumen. Diese Trennung zu machen und dann auch die Chance zu haben, auf einmal mit den vielen Applikationsservern, das ist ja der große Vorteil dieser Three-Tier-Client/Server-Architektur [3-Ebenen-Architektur: H. M.]. Du hast deine Da-

D IE

STANDARDISIERTE

S OFTWARE

| 53

tenbank, du hast das User-Interface und jetzt hast du auf einmal viele Applikationsserver dazwischen und du kannst skalieren.“

Die Softwareentwickler verteilten die unterschiedlichen Bausteine der Standardsoftware auf viele verschiedene kleinere Rechner. So konnte die für die Ausführung der komplexen Anwendungsprogramme notwendige Rechnerleistung doch noch erreicht werden. Statt die Anwendungsprogramme wie zuvor auf nur einem großen Rechner zu installieren, liefen diese nun auf mehreren kleineren Rechnern. Bei Bedarf konnte die Anzahl der Applikationsserver erhöht werden. Mit 200 kleineren Rechnern (workstations), die zu einem Verbund zusammengeschlossen wurden, konnte so beispielsweise die fünfzigfache Rechnerleistung eines großen Rechners (mainframe) erreicht werden (vgl. Plattner et al. 2000: 32). HP: „Wir haben eine große Erfindung gemacht, die war eigentlich für sechs oder sieben Jahre einzig in der Welt, nämlich: Wir schreiben ein System, das ein zentrales Repository hat, verteilen aber alle Repository-Elemente wie Bilder, Programme und Datendefinitionen automatisch auf alle Applikationsserver. Und wenn es eine Änderung gibt, wird diese Änderung automatisch durchgeführt, d. h. jeder Entwickler, jeder Benutzer weiß, dass er auf dem neuesten Stand des Repositories arbeitet, und es wird alle Synchronisationsarbeit automatisch vom System gemacht.“ (Plattner et al. 2000: 99)

Angekündigt worden war R/3 am Softwaremarkt für kleinere, mittelständische Unternehmen. Tatsächlich wurden die Software und ihre Client/Server-Architektur zu einem de facto-Standard für große Unternehmen. Der USamerikanische Erdölkonzern Chevron Oil war eines der ersten Unternehmen, die die verteilte Rechnerarchitektur nutzte, um die betriebswirtschaftlichen Anwendungsprogramme von SAP flexibel an unterschiedlichen Standorten und in Unternehmensbereichen verwenden zu können (vgl. Plattner 2000: 101). Den Erfolg der Umstellung der neuen Softwareversion auf ein Netzwerk kleinerer Rechner begründet Plattner nicht nur technisch. Er führt ihn auch auf den allgemeinen Trend Anfang der 1990er Jahre zurück. HP: „Wir hatten das richtige Produkt, ein UNIX-basiertes Produkt, als die ganze Welt sich zum Downsizing anschickte. Downsizing war 1992 das Modewort Nr. 1, und Anfang 1993 hatten wir ein Produkt. Es war zwar nicht perfekt, bei weitem nicht so perfekt wie das R/2-System. Aber jeder hatte die Funktionalität gesehen, die SAP liefern konnte, und man vertraute uns.“ (Ebd.: 37)

54 | D AS P ROJEKT SAP

Die relationale Datenbanktechnik stellt die informationstechnische Basis für die betriebswirtschaftlichen Anwendungsprogramme von SAP dar. Im folgenden Kapitel werden die Anwendungsprogramme der Software vorgestellt, die betriebswirtschaftliche Prozesse modellieren und Arbeitsabläufe in Organisationen so informationstechnisch miteinander verzahnen.

1.2 D IE A NWENDUNGSEBENE : D IE M ODELLIERUNG EREIGNISGESTEUERTER P ROZESSKETTEN Ein Entwickler nennt die Anwendungsprogramme das Herzstück der Standardsoftware und bezeichnet deren Entwicklung als Kerngeschäft des Softwareherstellers. INTERVIEWPARTNER G: „Das Kerngeschäft bei SAP ist [...] wirklich betriebswirtschaftlich innovative und mächtige, beim Kunden Entzücken hervorrufende Anwendungen zu bauen, ob das im Finanzwesen, im Lager oder im Einkauf ist. Das ist die Kernaufgabe, dass die Anwendungsentwickler möglichst von allem technischen Ballast freigehalten werden. Sie sollten eine Infrastruktur vorfinden, wo sie sich wirklich darauf konzentrieren können, was sind denn die betriebswirtschaftlichen Prozesse, die wir unterstützen und miteinander verzahnen wollen? Können wir das jetzt im Coding abbilden? Und ist es komplex genug?“

Um die Funktionsweise der Anwendungsprogramme beschreiben zu können, müssen zunächst einige Begrifflichkeiten geklärt werden. Für eine betriebswirtschaftliche Modellierung der Organisation in den Anwendungsprogrammen der Software sind Buchungskreise und Werke grundlegende Kategorien. Im System der Software repräsentiert ein Buchungskreis eine rechtlich selbstständige und nach gesetzlichen Vorschriften bilanzierende Organisationseinheit. Es handelt sich etwa um ausländische Tochterunternehmen innerhalb eines Konzerns. Werke stehen im System der Software für Produktionsstätten oder Filialen, die jeweils einem Buchungskreis zugeordnet sind. Einem Buchungskreis wiederum können mehrere Werke zugeordnet sein. Mithilfe dieser Kategorien werden einerseits die Ressourcen des Unternehmens wie Kapital, Betriebsmittel und Personal wertmäßig dargestellt. Für unterschiedliche Buchungskreise eines Unternehmens werden beispielsweise Monats- und Jahresabschlüsse und andere Berichte erstellt, um Aussagen über den finanziellen Zustand der Gesamtorganisation treffen zu können und Organisationseinheiten miteinander zu vergleichen. In Ländervorlagen (country templates) der Software finden u. a. gesetzliche Regeln für die Finanzbuchhaltung des jeweiligen Standortes der Organisationsein-

D IE

STANDARDISIERTE

S OFTWARE

| 55

heit Berücksichtigung. Andererseits werden Unternehmensressourcen mengenmäßig abgebildet, z. B. die Darstellung von (Roh-)Material und seine Umwandlung in Fabrikate oder Dienstleistungen. Die Organisation wird dafür in verschiedene Werke gegliedert. Diese werden jeweils einem Buchungskreis zugerechnet. Rechnungen, Lieferungen, Bestellungen etc. sind Ereignisse, die wertund mengenmäßige Zustandsbeschreibungen einer Organisation verändern. Mengenangaben können zu jeder Zeit in Werteangaben übersetzt werden.21 Die Möglichkeit zur Verkettung betriebswirtschaftlicher Ereignisse an verschiedenen Standorten des Unternehmens schildert ein Interviewpartner am Beispiel einer Kundenbestellung. INTERVIEWPARTNER P: „Wir arbeiten alle in einem Buchungskreis. Es sei denn, ich habe einen ausländischen Standort. Ja, wir haben Töchter und haben halt auch Standorte, die im gleichen Buchungskreis sind. Also es sind nicht alles Töchter. Und trotzdem haben wir ja diese Verknüpfung. Zum Beispiel wenn ein Kunde in England ein Material bestellt, was in England nicht am Lager ist, dann kommt es hierher. Das heißt, wir erzeugen entsprechende Belege im System, dass der Auftrag immer noch in England ist.“

Auf der Grundlage zentraler Datenbanken können die Materialbestände an verschiedenen Standorten miteinander verglichen werden. Sobald Material, das von einem Kunden an einem bestimmten Standort bestellt wurde, vor Ort nicht verfügbar sein sollte, wird die Bestellung automatisch an einem anderen Standort des Unternehmens ausgeführt und an den Kunden geliefert. Die entsprechenden Arbeitsabläufe im Unternehmen werden in den Programmen der Software als eine Verkettung von Ereignissen und betriebswirtschaftlichen Prozessen dargestellt. INTERVIEWPARTNER P: „Dieser Auftrag bestellt aber Ware bei uns, die hier kommissioniert wird, die hier, ich sag mal, auf den LKW geladen wird. Die kommt dann an in England und muss halt systemtechnisch und physisch weiterbearbeitet werden.“

21 Treffend charakterisiert Brita Hohlmann (vgl. 2007: 235ff.) die Software als Konversionsmedium und erläutert dies an einem konkreten Beispiel: Ein Kundenauftrag im System der Software enthält nicht nur Daten über die vom Kunden in Auftrag gegebenen Einzelpositionen und Mengen. Zusätzlich ist diesem Auftrag auch ein Kalkulationsschema hinterlegt, mit dem Steuern, Nachlässe und Deckungsbeiträge berechnet werden. Der Produktionsauftrag für die Fertigung enthält dementsprechend nicht nur Angaben zur Menge des Materials, sondern ermöglicht zugleich Kostensichten und Angaben zum Wert des Auftrags.

56 | D AS P ROJEKT SAP

Hier wird nicht nur eine handelnde Person (der Auftraggeber) mit einer Sache (dem Auftrag) identifiziert. Der Auftrag wird vielmehr als Ereignis übersetzt, das Bestandteil einer Prozesskette ist, die wiederum aus mehreren Ereignissen besteht. Das Ereignis (z.B. Auftrag eingegangen) löst eine bestimmte Funktion im System aus (z. B. Ware kommissionieren), die ein weiteres Ereignis anstößt (z. B. LKW wurde beladen). Typische Ereignisse in einem Unternehmen sind Aufträge, Bestellungen, Rechnungen und Lieferungen. Eine Prozesskette verknüpft mehrere Ereignisse in einer zuvor definierten zeitlichen und logischen Abfolge. Sie beginnt mit einem Startereignis und endet mit einem Ergebnis. Wie auf ein bestimmtes Ereignis im Unternehmen reagiert werden soll, wird im System der Software über eine Programmroutine festgelegt, indem ein logischer Operator das Ereignis mit einer Funktion verknüpft.22 So werden lesende und schreibende Zugriffe auf die Datenbank der Software in den Anwendungsprogrammen gesteuert. Gleichzeitig wird festgelegt, welche Informationsobjekte (z.B. Daten und Bildschirme) einer organisatorischen Einheit (z.B. Personen oder Personengruppen) zur Verfügung stehen. Prozesswegweiser sorgen für die Verbindung spezifischer Prozessketten. Die Methode für die Modellierung von Geschäftsprozessen mithilfe ereignisgesteuerter Prozessketten (EPK) ist von August-Wilhelm Scheer und Mitarbeitern der Informatikabteilung der Universität des Saarlandes entwickelt worden (vgl. Keller et al. 1992).23 Anfang der 1990er Jahren wurden auf diese Weise viele Hunderte Prozessketten dokumentiert. Die Entwickler von R/3 machten sich diese Methode der Modellierung von Geschäftsprozessen für ihre Anwen-

22 Es werden drei Operator-Typen unterschieden. 1) Mit einer UND-Verknüpfung wird festgelegt, dass ein bestimmtes Ereignis (bzw. eine Funktion) eingetreten sein muss, bevor eine neue Funktion (bzw. ein neues Ereignis) angestoßen wird. 2) Die ODERVerknüpfung bedeutet, dass mindestens eines der Ereignisse eingetroffen (bzw. eine der Funktionen ausgeführt) sein muss, damit ein nachfolgendes Ereignis eintreffen kann (bzw. die nachfolgende Funktion ausgeführt werden kann). 3) Die XODERVerknüpfung bedeutet, dass genau eines der Ereignisse eingetroffen sein muss (bzw. eine der Funktionen ausgeführt werden muss), damit die nachfolgende Funktion ausgeführt werden kann (bzw. das nachfolgende Ereignis eintreten kann). 23 Softwareberater benutzen die EPK-Methode bis heute, um ihren Kunden die Funktionsweise der Standardsoftware zu erläutern. Sie wird verwendet, um die standardisierten Programmabläufe zu illustrieren und das zugrunde liegende Organisationsmodell der Software mit den real existierenden Arbeitsabläufen in einem Unternehmen abzugleichen.

D IE

STANDARDISIERTE

S OFTWARE

| 57

dungsprogramme zunutze. Es entstand auf diese Weise ein umfangreiches Modell betriebswirtschaftlicher Prozesse aller Art. „The data model of the SAP software took several years to develop and is surely one of the world’s largest data models. At the start of the project, it was impossible to estimate the dimensions of the model. The immense size of the model demonstrates the highly sophisticated nature of R/3.“ (Scheer 2004: 34)

Es wäre jedoch unzureichend, die Modellierung der Organisation in den Anwendungsprogrammen der Software vorschnell als rein betriebswirtschaftlichen Ansatz zu interpretieren. Scheer beschreibt das Organisationsmodell der Software so: „It is perhaps surprising that the success of SAP has been achieved through standard business software when there is not a single business administration expert among the founders and main system developers. It is possible, though, that their lack of experience in the subject was, in fact, the secret to their success because they were open to new IT-based business ideas and were not confined by strict academic rules.“ (Ebd.: 27).

Tatsächlich wurde das Konzept der Software, zumindest in den ersten Jahrzehnten, durch die Denkweise von Ingenieuren, Naturwissenschaftlern und Mathematikern geprägt. Genauso wie ihre Nachfolger Henning Kagermann und Peter Zencke, die maßgeblich an der Produktentwicklung von R/3 beteiligt waren, hatten die Gründungsmitglieder Hans Werner Hector, Dietmar Hopp, Hasso Plattner und Klaus Tschira einen ingenieurstechnischen oder naturwissenschaftlichen Hintergrund.24 Schwerpunkt der nachfolgenden Kapitel ist daher die Auseinandersetzung mit dem vermeintlich betriebswirtschaftlichen Organisationsmodell der Standardsoftware. 1.2.1 Die Kontroverse zwischen Ingenieur und Betriebswirt: Die Echtzeit-Datenverarbeitung im Rechnungswesen R/3 war bis zum Jahr 2000 das bekannteste Produkt des Softwareherstellers. Der Buchstabe R im Produktnamen steht für das Konzept der Realtime-Daten-

24 Lediglich ein Gründungsmitglied des Softwareunternehmens hatte eine betriebswirtschaftliche Ausbildung; der Betriebswirt Claus Wellenreuther hatte das Softwareunternehmen jedoch bereits 1980 aus gesundheitlichen Gründen verlassen (vgl. Meissner 1997: 283).

58 | D AS P ROJEKT SAP

verarbeitung. Plattner und Kagermann prophezeiten in einem Aufsatz Ende der 1980er Jahre, dass die Verwendung moderner Informationstechnik wie SAP die Datenverarbeitung und die Rolle des Rechnungswesens in Unternehmen grundlegend verändern wird. „Neben seiner traditionellen Aufgabe, alle in einer Periode angefallenen Geschäftsvorfälle zu dokumentieren, übernimmt das Rechnungswesen in den Betrieben zunehmend die Funktion eines Beschaffung, Produktion und Absatz begleitenden Informations- und Controllinginstruments. Abnehmende Durchlaufzeiten in Produktion und Organisation führen zu immer kürzeren Dispositionszyklen. Als Konsequenz werden entscheidungsorientierte Informationen gefordert, die es gestatten, unmittelbar korrigierend in das laufende Geschehen einzugreifen.“ (Plattner & Kagermann 1988: 137)25

Die Aufgabe des Rechnungswesens in einem Unternehmen sollte nicht mehr länger nur darin bestehen, Geschäftsvorfälle, d.h. betriebswirtschaftliche Ereignisse, zu dokumentieren und nachträglich auszuwerten. Vielmehr sollte es „korrigierend in das laufende Geschehen“ (ebd.) eingreifen können. Eine solche Form des Controllings ist mittlerweile in vielen Unternehmen üblich. Die Bedeutung der neuen Datenverarbeitungstechnik für das Rechnungswesen wurde damals allerdings kontrovers diskutiert. Unterschiedliche Vorstellungen und Erwartungen waren mit der neuen Technik verknüpft. So wie der Ingenieur Bachman und der Mathematiker Codd26 über den Aufbau und die Nutzung von Datenbanken gestritten hatten, war auch die Kontroverse über die Bedeutung der Echtzeit-Datenverarbeitung im Rechnungswesen Ausdruck einer Konkurrenz zwischen sozialen Gruppen. Ausgelöst wurde diese Kontroverse durch die Frage, welches Problem die neue Informationstechnik eigentlich lösen soll und inwiefern sich damit Aufgaben- und Einflussbereiche für einzelne Mitglieder und Mitgliedergruppen in einer Organisation verändern.27

25 Das Zitat stammt aus einer Festschrift für Hans-Georg Plaut, der zu einem prominenten Gegner der Echtzeit-Datenverarbeitung im Rechnungswesen zählte. Siehe hierzu die Ausführungen auf den folgenden Seiten. 26 Die Kontroverse zwischen Bachman und Codd wurde in KAPITEL 1.1.2 nachgezeichnet. Siehe hierzu auch die Arbeiten des Technikhistorikers Gugerli (2007; 2009). 27 Die soziologische Accounting-Forschung hat die Bedeutung sozialer Gruppen für die Bestimmung der Funktion des Rechnungswesens und anderer kalkulativer Praktiken im Detail untersucht (z. B. Miller 1994; 1999). In sozialkonstruktivistischen, organisationstheoretischen, wirtschaftssoziologischen und mikrosoziologischen Forschungsansätzen fungiert Accounting als Sammelbegriff für Buchführung, Kostenrechnung, Bi-

D IE

STANDARDISIERTE

S OFTWARE

| 59

Zu den Gegnern der Technik der Echtzeit-Datenverarbeitung im Rechnungswesen gehörte der Unternehmensberater Hans-Georg Plaut, der als Begründer und Mitgestalter des modernen innerbetrieblichen Rechnungswesens gilt. Auf ihn geht beispielsweise die Methode der Grenzplankostenrechnung zurück. Sie ermöglicht die Zusammenstellung verschiedener Kostendaten, durch die Produktionsabläufe kurzfristig betriebswirtschaftlich geplant werden können (vgl. Müller 2001: 522).28 Der Betriebswirt Plaut hatte im Jahr 1946 das Unternehmen Plaut Consulting gegründet und sich auf die Entwicklung elektronischer Auswertungsprogramme für das Rechnungswesen spezialisiert. Bevor das Softwareunternehmen SAP in den 1990er Jahren diese Rolle übernahm, war Plaut Consulting auf diesem Gebiet europaweit Marktführer. Plaut hatte argumentiert, das Prinzip der Echtzeitverarbeitung, das auf einer unmittelbaren Datenauswertung basierte, sei für das Rechnungswesen irrelevant. Schließlich würden Abrechnungsvorgänge im Unternehmen wie Kostenplanung und Soll-Ist-Vergleiche auf Perioden bezogen konzipiert. Es genüge daher, Auswertungen im Rechnungswesen weiterhin nach der klassischen Methode der Stapelverarbeitung durchzuführen.29 Ein Dialogsystem in der Datenverarbeitung für das Rechnungswesen erschien Plaut nur in Ausnahmefällen sinnvoll, wenn es um die innerbetriebliche Kostenplanung für die Verarbeitung von Rohstoffen ging. Plötzliche Preisanstiege am Rohstoffmarkt konnten in der Echtzeit-Kostenplanung nämlich berücksichtigt werden. Die Verfechter einer umfassenden Echtzeit-Datenverarbeitung im Rechnungswesen hatten damals nur das Argument: „Wir nutzen die Echtzeitverarbeitung im Rechnungswesen, weil wir es können“ (Scheer 2004: 25f.). Die SAP-Entwickler boten also eine technische Lösung für ein organisatorisches Problem an, das bislang überhaupt nicht als Problem identifiziert worden war: die Bewertung des finanziellen Zustands der Organisation zu jeder Zeit. Um eine Echtzeit-Bewertung der Organisation durchzuführen, musste jeder noch so kleine Beleg umgehend in die Datenbank eingegeben werden. Nur so konnte zu je-

lanzwesen, Controlling und andere Managementmethoden, die von Zahlen Gebrauch machen (vgl. Mennicken & Vollmer 2007). 28 Kombiniert wurden zwei bislang unabhängige Kostenrechnungsmethoden, die in Deutschland übliche Grenzkostenrechnung und die in den USA tradierte Plankostenrechnung. 29 Damit wurden Daten sequenziell und zu einem bestimmten Stichtag (z. B. Ende der Woche, Ende des Monats etc.) automatisch ausgewertet. Mitarbeiter im Rechnungswesen waren lediglich für die pünktliche Dateneingabe zuständig. Ansonsten hatten sie keinerlei Berührungspunkte mit der EDV.

60 | D AS P ROJEKT SAP

der Zeit eine Bilanz oder eine Gewinn- und Verlustrechnung für das Unternehmen erstellt werden. Die Echtzeit-Datenverarbeitung setzte sich trotz der anfänglichen Skepsis in der Unternehmenspraxis mit der Zeit durch und veränderte damit die Prinzipien des Rechnungswesens und der Unternehmenssteuerung. Viele Aussagen Plattners belegen, dass er von einer determinierenden Wirkung der Software auf die Aktivitäten in einer Organisation überzeugt war. Das Zusammenspiel von Technik und Organisation formulierte er in einem Interview über die Entstehungsgeschichte von R/3 so: „Wir hatten also technisch ein einwandfreies System, das die Leute zwang, ihre Vorgehensweisen zu ändern“ (Plattner 2000: 51). Die Organisationsweise passte sich, so Plattner im folgenden Zitat, an eine technische Entwicklung an. „Wenn sich plötzlich die Werkzeugebene verändert, dann verändern sich auch die betriebswirtschaftlichen Methoden, dann macht man Dinge nicht mehr nur einmal im Jahr, einmal im Monat, sondern dann, wenn sie einen interessieren. Und das kann in einer Bank bedeuten, dass sie jede Sekunde eine Bilanz haben möchten und nicht mehr einmal im Jahr“ (Plattner 2000: 83).

Experten der modernen Kostenrechnung waren noch Anfang der 1980er Jahre überzeugt, dass die Buchführung keiner Echtzeit-Analyse bedürfe, weil Buchführung nun einmal an Perioden gebunden sei. Erst als es gelang, Plaut als eine der führenden Autoritäten auf dem Gebiet des betriebswirtschaftlichen Rechnungswesens von der Echtzeitverarbeitung zu überzeugen, begann sich die Echtzeit-Methode der SAP-Entwickler im Rechnungswesen von Unternehmen durchzusetzen. „[The] cooperation between the Plaut Consulting Group and SAP led to the development of a modern accounting system, worldwide distribution of which contributed more to the internationalization of German business administration than all the German academic literature about corporate accounting.“ (Scheer 2004: 28)

Doch nicht nur das Rechnungswesen veränderte sich auf der Grundlage dieser neuen Datenverarbeitungstechnik. Auch auf anderen Anwendungsgebieten in Unternehmen wurde die Echtzeit-Datenverarbeitung zum neuen Planungs- und Steuerungsmodus. Zu den organisatorischen Veränderungen im Zuge der Softwareeinführung äußert sich ein Mitarbeiter der Logistik-Abteilung eines Handelsunternehmens.

D IE

STANDARDISIERTE

S OFTWARE

| 61

INTERVIEWPARTNER P: „Ich sehe zu jedem Zeitpunkt die aktuelle Situation, die gerade da ist. Was ich vielleicht vorher nicht gehabt habe. Weil früher wurden die Aufträge oder die Kommissionierungen nicht zu dem Zeitpunkt zurückgemeldet, wo sie wirklich passiert sind. Und da gab es halt dieses Loch. Irgendwann habe ich die Lieferscheine da unten ins Lager gegeben und wenn der LKW losgefahren ist, wusste ich, die haben fertig. Das heißt, die Rückmeldung erfolgte eigentlich, weiß ich nicht, teilweise einen Tag später.“

Die Echtzeit-Datenverarbeitung setzt voraus, dass alle Arbeitsschritte dokumentiert werden und zwar „zu dem Zeitpunkt, wo sie wirklich passiert sind“ (ebd.). Mitarbeiter werden sprichwörtlich an die elektronische Leine genommen (vgl. Schulz-Schaeffer & Funken 2008: 38). Auf die Mitarbeiter im Lager, über die P berichtet, trifft diese Metapher sogar wortwörtlich zu. Denn sie sind mit mobilen Datenerfassungsgeräten (Scannern) ausgerüstet, um die Warenentnahme aus dem Lager unmittelbar im System der Software zu dokumentieren. Sie erzeugen Belege, die als betriebswirtschaftliche Ereignisse im Softwaresystem abgebildet werden (z. B. Auftrag bearbeitet, Kommissionierung erfolgt etc.). Die Anwendungsprogramme der Software bilden die Organisation jedoch nicht nur wertund mengenmäßig (bzw. betriebswirtschaftlich) ab, sondern enthalten, zumindest implizit, Verbesserungsvorschläge zur Gestaltung von Arbeitsabläufen im Unternehmen. Ein Mitarbeiter im Qualitätsmanagement meint dazu: INTERVIEWPARTNER O: „Dann hier noch eine Datenbank und da noch eine Datenbank. Um das aber zusammenzuführen, um vernünftige Informationen daraus zu kriegen, war fast gar nicht möglich oder nur mit einem ganz großen Aufwand möglich. Und ich glaube, das war die hauptsächliche Entscheidung, zu sagen, wir wollen alles in einem System vernünftig abbilden und die Prozesse da auch vernünftig abbilden und da muss man schon sagen, glaube ich, ist SAP eigentlich fast für mich das Einzige, was das vernünftig kann.“

In der Vergangenheit erfüllten Datenbanksysteme den Zweck lokaler Datensammlungen für einzelne Abteilungen und Standorte. SAP soll hingegen die Zusammenarbeit mit anderen Abteilungen und über Standorte hinweg vereinfachen und effizienter gestalten. Da die Standardsoftware auf zentralen Datenbanken basiert, ist ein organisationsspezifisches Berechtigungskonzept für die Softwareverwendung notwendig. Mit einem solchen Konzept werden auf der Anwendungsebene von SAP Einblicke und Eingriffsmöglichkeiten auf zentrale Datenbanken reguliert. Das Berechtigungskonzept der Software und seine soziale Bedeutung für die Organisation werden im nächsten Abschnitt erläutert.

62 | D AS P ROJEKT SAP

1.2.2 Das Berechtigungskonzept: Die Organisation in der Software Abhängig davon, welche Benutzerrolle Organisationsmitglieder inne haben, werden ihnen unterschiedliche Anwendungsprogramme und Datenbankabfragen für ihre Arbeit zur Verfügung gestellt. Für den Informatiker Arno Rolf (1998: 8) bildet das Berechtigungskonzept einer Software die Hierarchie einer Organisation anschaulich ab. Mithilfe von Nutzerrollen werden vertikale und horizontale Kommunikationswege der Organisation modelliert. Um das Berechtigungskonzept von SAP zu beschreiben, verwendet der Bereichsleiter der Informatik eines Automobilherstellers folgendes Bild. INTERVIEWPARTNER E: „Also das beste Beispiel ist immer das Haus. Wenn Sie ein Hochhaus haben mit Etagen und einzelnen Räumen, gibt’s normalerweise einen Generalschlüssel dafür. Das heißt, Sie schließen auf und mit dem Schlüssel können Sie in jede einzelne Etage reingehen und in jedes Zimmer. Und dieser Generalschlüssel im SAPBerechtigungskonzept ist die sogenannte SAP_ALL-Berechtigung.“

Meist ist es der IT-Administrator in einem Unternehmen, der über die genannte umfassende Berechtigung verfügt. Eine zentrale Aufgabe des Beraters während der Softwareimplementierung besteht darin, ein Berechtigungskonzept auszuarbeiten, das einer Systemprüfung durch externe Wirtschaftsprüfer standhält. Zu den rechtlichen Anforderungen im Zusammenhang mit der Softwareeinführung äußert sich ein Berater so: INTERVIEWPARTNER D: „Dann gibt es auch in der Finanzwelt Wünsche, dass jemand, der im Land A arbeitet, nicht die Finanzzahlen eines Landes B sieht. Obwohl man eigentlich in der gleichen Organisation arbeitet, aber man will da einfach sicherstellen, dass die Tricks, die jemand benutzt, um ein Unternehmen besser dastehen zu lassen, wie ein anderes Werk, einfach nicht sichtbar werden. Ja, also schreitet man da ein. Wir haben unendlich viele Bespiele, wo ja, wo ja auch in der Finanz, buchen, abbuchen, radieren von Werten, wo man sicherstellt, dass die Berechtigungen immer wieder so verteilt werden, dass das System nicht manipuliert werden kann.“

Benutzerrollen legen die jeweilige Zuständigkeit und den Informationsbedarf der Softwarenutzer fest. Organisationsinterne Zuständigkeiten, die „früher so ein bisschen schwammiger und nicht so deutlich“ (ebd.) waren, werden nun eindeutig geregelt. Um Mitarbeiter daran zu hindern, ihre Kompetenzen zu überschrei-

D IE

STANDARDISIERTE

S OFTWARE

| 63

ten, sind Softwarefunktionen und daran gekoppelte Datenbankabfragen nur eingeschränkt für sie nutzbar. INTERVIEWPARTNER E: „Sie bestellen sich was, sie kaufen das ein, sie genehmigen das, wenn Sie es bekommen und sie buchen das. Dann buchen sie es vielleicht noch auf Ihr eigenes Konto. Das ist das, was im Prinzip dann die Horrorvorstellung ist im SAP-Umfeld.“

Mit einer SAP_ALL-Berechtigung seien Tür und Tor zur Manipulation geöffnet, erklärt E im weiteren Interviewverlauf. Sein Arbeitgeber habe deshalb viel Zeit und Energie in das Berechtigungskonzept der Software investiert. Für etwa 15.000 Softwarenutzer und -nutzerinnen seien etwa 400 unterschiedliche Benutzerrollen definiert worden. Auf das Berechtigungskonzept von SAP angesprochen, bringen IT-Verantwortliche in den Interviews zum Ausdruck, dass das Misstrauen der Organisation gegenüber ihren Mitgliedern groß sei. Heruntergespielt wird hingegen, dass das Berechtigungskonzept überdies institutionelle Umwelterwartungen erfüllt. D bezeichnet diese beispielsweise als „Wünsche der Finanzwelt“ (s.o.). Faktisch ist damit jedoch ein komplexes Regelwerk gesetzlicher Vorschriften gemeint. Eine Reihe dieser Vorschriften ist in den Anwendungsprogrammen inkorporiert und soll die Anwendung des Regelwerks im Arbeitsalltag erleichtern. Die Vergabe von Nutzerrechten bei der Softwareimplementierung beschreibt E als vollkommen unproblematisch: „Also, wir haben genau nach den Arbeitsplätzen auch dann die Berechtigungen vergeben und Rollen definiert“. Auch von anderen Interviewpartnern und Interviewpartnerinnen wird die Erstellung des Berechtigungskonzeptes als rein sachlicher Vorgang beschrieben. INTERVIEWPARTNER D: „Also, was man macht ist, danach zu gucken, auf welcher Etage arbeiten die Leute und ist es jemand, der Gruppenleiter ist, der Zugriff zu mehreren Räumen braucht oder ist es ein Buchhalter, der von A bis Z arbeitet, der nur in einen Raum braucht.“

Tatsächlich wird bei der Implementierung der Software die Vergabe von Nutzerrechten diskutiert und ausgehandelt.30 Ein Zusammenhang zwischen Nutzerrechten und Nutzerkontrolle wird von den Interviewpartnern nur selten hergestellt.

30 In KAPITEL 6.4 „Berechtigungen und andere Entscheidungsprobleme“ wird die Verteilung von Berechtigungen bzw. Zugriffsrechten als Entscheidungsproblem untersucht, das in der Interaktion zwischen Beratern und Organisationsmitgliedern bearbeitet wird.

64 | D AS P ROJEKT SAP

Im folgenden Interviewausschnitt wird die Thematisierungsschwelle allerdings überschritten. INTERVIEWPARTNER O: „Weil, ich sag mal, vorher mit dem Großsystem hatte man eigentlich (--) ich sag mal (-) Kontrolle ist immer ein falsches Wort, weil ich will ja eigentlich die Mitarbeiter nicht kontrollieren, sondern ich möchte eigentlich mit ihnen besser werden. Und, also vorher, da hatte man eigentlich keine Chance mal zu sehen, ich sag mal, wenn ein Mitarbeiter immer die gleichen Fehler gemacht hat. Irgendwann ist es dann mal zufällig aufgefallen oder ein Kunde hat es reklamiert. Aber ich sag mal, heutzutage habe ich natürlich durch diese Transparenz im System, kann ich genau sehen, wer hat wann was gemacht. Und ich würde das eigentlich nicht als Kontrolle definieren, sondern schon eine Chance, ich sag mal, einen Mitarbeiter gezielt zu schulen und Fehler zu vermeiden.“

Die Softwareverwendung in Organisationen wird auf zweierlei Weise interpretiert, einmal als Kontrollinstrument, das andere Mal als Möglichkeit zur Arbeitsoptimierung. Von der ersten Lesart distanzieren sich die Interviewten eher. Stattdessen interpretieren sie die Software primär als Mittel zur Steigerung der Arbeitsleistung. Die direkte Kontrolle des Personals durch den Vorsetzten wird durch Möglichkeiten zur Selbstkontrolle abgelöst. Ein Softwareberater weist beispielsweise auf die technischen Möglichkeiten zur Kontrolle der Arbeitsleistung von Mitarbeitern hin, nennt in einem Atemzug jedoch die Betriebsräte in Unternehmen, die in alle Entscheidungen über die Softwareverwendung einbezogen werden müssten und der Umsetzung der Kontrollpotenziale der Software einen Riegel vorschieben würden. Die Kontrolle über Personen passt nicht zu einem modernen Verständnis von Organisationen. Die Kontrolle über Prozesse hingegen schon. Im nächsten Kapitel soll die Darstellungsebene der Software behandelt werden. Die Mehrsprachigkeit der Software wird – neben relationalen Datenbanken und Echtzeitverarbeitung – als drittes charakteristisches Merkmal der Technik SAP vorgestellt.

D IE

STANDARDISIERTE

S OFTWARE

| 65

1.3 D IE D ARSTELLUNGSEBENE : D IE M EHRSPRACHIGKEIT DER S OFTWARE Die Standardsoftware von SAP ermöglicht eine informationstechnische Aufbereitung von Daten, die weit über die traditionelle Darstellung der Organisation hinausgeht, wie sie etwa die doppelte Buchführung in Unternehmen repräsentiert. Ausgangspunkt für die Verwendung von SAP ist die Prämisse einer standardisierten und (zeitlich) verzögerungsfreien Kommunikation innerhalb der Grenzen einer Organisation. Die Mehrsprachigkeit der Software wird in diesem Kapitel als zentrale technische Voraussetzung vorgestellt. Dafür folgt zunächst eine kurze Erklärung zur allgemeinen Funktionsweise elektronischer Datenverarbeitungssysteme. Computer verarbeiten Buchstaben, Zahlen oder andere Zeichen als binäre Zahlen. Eine binäre Zahl ist eine Folge von Nullen (0) und Einsen (1), eine siebenstellige binäre Zahl ist z. B. 1001001. Da jede Stelle zwei verschiedene Werte haben kann, eben 0 oder 1, gibt es genau 128 verschiedene siebenstellige Binärzahlen. 7

2 = 2 × 2 × 2 × 2 × 2 × 2 × 2 = 128 Eine 7-Bit-Zeichencodierung kann also höchstens 27 verschiedene Zeichen im Computer darstellen. Allgemeiner ausgedrückt, eine n-Bit-Zeichencodierung kann 2n verschiedene Zeichen abbilden. Die Anzahl darstellbarer Zeichen kann also sehr stark wachsen, eine gute Abschätzung liefert 210 = 1.024 ≈ 1.000 = 103. Eine 30-Bit-Codierung könnte daher mehr als 103 × 103 × 103 = 109 oder eine Milliarde Zeichen wiedergeben. In den 1970er Jahren wurde zunächst eine 7-BitZeichencodierung, der sogenannte American Standard Code for Information Interchange (ASCII), von der International Organization for Standardization (ISO) als ISO 646 veröffentlicht. Von den 128 möglichen Kombinationen wurden 95 der druckbaren Zeichen durch das lateinische Alphabet in Groß- und Kleinschreibung, die zehn arabischen Ziffern sowie einige Satzzeichen repräsentiert. Die übrigen 43 Kombinationen waren für Zeilen- und Seitenumbrüche sowie andere Steuerzeichen reserviert. International war dieser Standard jedoch keineswegs: Zeichen anderer Schriftsysteme konnten mit dieser Codierung nicht dargestellt werden, auch fehlten die Buchstaben å, ä, ü, ö oder ñ, die im schwedischen, deutschen oder spanischen Alphabet vorkommen. In den 1980er Jahren setzte sich deshalb ein erweiterter ASCII-Zeichensatz durch. Mit der 8-Bit-Zeichencodierung konnten nun 28 = 256 Zeichen dargestellt werden. Auf dieser Basis wurde eine neue Maßeinheit für Daten eingeführt, nämlich die Einheit Byte. Acht Bit entsprechen einem Byte. Einige nationale Va-

66 | D AS P ROJEKT SAP

rianten dieses Standards ISO 8859 machten auch die Darstellung kyrillischer, griechischer und thailändischer Zeichen möglich (vgl. Pargman & Palme 2009: 180ff.). Aufwendig blieb der Datenaustausch zwischen Computern, die verschiedene nationale Codierungen nutzten. Es gab nämlich Hunderte unterschiedliche Systeme. 1.3.1 Der Unicode-Zeichensatz Ende der 1980er Jahre begannen die Arbeiten an einem neuen Kodiersystem. Den ersten Entwurf dafür schrieb Joseph D. Becker, der bei Xerox, einem USamerikanischen Unternehmen für Drucktechnologie, arbeitete. Zur Erfordernis eines universellen Zeichensatzes sagt Becker: „Since there are vastly more than 28=256 characters in the world, the 8-bit byte has become a useless commodity in the context of modern international/multilingual character encoding. [...] What is needed is a new international/multilingual text encoding standard that is workable and reliable as ASCII, but that covers all the scripts of the world.“ (Becker 1988: 2f.)

Unicode ist die Bezeichnung für die von Becker vorgeschlagene allgemein gültige Codierung von Zeichen („unified“, „unique“, „universal“ ebd.). Die Entwicklung des vermeintlich universellen Zeichensatzes begann Anfang der 1990er Jahre. Im Jahr 1991 wurde das sogenannte Unicode-Konsortium gegründet. Erklärtes Ziel des Konsortiums von US-amerikanischen Computer- und Softwareherstellern sowie einer Forschungseinrichtung31 war es, unterschiedliche und inkompatible Codierungen in verschiedenen Ländern aufzuheben und gegen ein einheitliches System einzutauschen. Einen ersten Vorschlag für das Zeichensystem hatte der Xerox-Mitarbeiter Becker bereits im Jahr 1988 vorgelegt. Grundlage für die erste Version von Unicode war eine 16-Bit-Codierung, mit der im Prinzip 65.536 verschiedene Zeichen darstellbar waren. 216 = 2 × 2 × 2 × 2 × 2 × 2 × 2 × 2 × 2 × 2 × 2 × 2 × 2 × 2 × 2 × 2 = 65.536

31 Gründungsmitglieder sind die folgenden neun Unternehmen bzw. Organisationen: Apple Computer, GO Corporation, IBM, Metaphor Computer Systems (Ableger von Xerox), Microsoft, Next Computer, Novell, The Research Libraries Group und SUN Microsystems.

D IE

STANDARDISIERTE

S OFTWARE

| 67

Damit rückte die Darstellbarkeit aller Sprachen und Zeichensysteme der Welt in Reichweite. Allerdings codierten die Unicode-Entwickler nicht alle Sprachen, weil sie diese teilweise als nicht wertvoll genug erachteten. So ließ Becker in seinem ersten Entwurf keinen Zweifel an der Priorisierung bestimmter Sprachen. „Unicode gives higher priority to ensuring utility for the future than to preserving past antiquities. Unicode aims in the first instance at the characters published in modern texts (e. g. in the union of all newspapers and magazines printed in the world in 1988), whose number is undoubtedly far below 214 = 16.384. Beyond those modern-use characters, all others may be defined to be obsolete or rare, these are better candidates for private-use registration than for congesting the public list of generally-useful Unicodes.“ (Becker 1988: 3)

Becker erstellte eine Rangfolge der wichtigsten Zeichensysteme der Welt. Diese Rangfolge spiegelte den Anteil der jeweiligen Sprachgruppen am weltweiten Bruttosozialprodukt wider. Abbildung 10: Klassifizierung der Zeichensysteme der Welt

Quelle: Darstellung in Anlehnung an Becker (1988)

Zwölf Jahre später wurde diese für einen universellen Code extrem selektive Konzeption zumindest implizit zurückgenommen, als der Präsident des UnicodeKonsortiums, Mark Davis, in einer Pressemeldung am 29. Februar 2000 Folgendes erklärte: „The adaption of Unicode enables computer users to read and write documents in their own native languages, and this new version extends the ability to virtually all corners of the globe.“ (Unicode 2000; Hervorh., H. M.)32

32 Quelle: http://www.unicode.org/announcements/pr-3.0.html; Zugriff am 20.03.2013.

68 | D AS P ROJEKT SAP

Überschrieben war diese offizielle Meldung des Zusammenschlusses verschiedener Computer- und Softwarehersteller mit dem Satz: „Unicode Standard Extends to All World Languages“. Die Formulierung „all corners of the globe“ (ebd.) legt nahe, dass der Entwicklung des Unicodes eine bestimmte Weltvorstellung zugrunde lag, nämlich die Vorstellung von Zentrum und Peripherie. Unicode basierte zu diesem Zeitpunkt bereits auf einer 32-Bit-Zeichencodierung. Es konnten also weit über vier Milliarden Zeichen (232 = 4.294.967.296) dargestellt werden. Während Becker als wichtigstes Kriterium für die Aufnahme eines Zeichensystems in den Unicode noch den Beitrag zum Bruttosozialprodukt betrachtete, den die Benutzerländer dieses Zeichensystems erbrachten, spielte nun die Anzahl ihrer potenziellen Nutzer eine wichtige Rolle. Sprachgemeinschaften mit mehr als fünf Millionen Mitgliedern sollten systematisch in das universelle Zeichensystem aufgenommen werden. Kleinere Gemeinschaften fanden eher zufällig einen Platz im System, etwa durch die individuellen Anstrengungen einzelner Personen (vgl. Anderson 2005: 17).33 Es ist davon auszugehen, dass die im Unicode-Konsortium weiterhin besonders einflussreichen Computer- und Softwarehersteller bis heute nur ein geringes Interesse daran haben, kleinere Sprachgemeinschaften in den Unicode aufzunehmen, weil sie als Absatzmarkt für Computer und Softwareprodukte nicht relevant sind. Die Entwickler von SAP machten sich die Entwicklung vom ASCII zum Unicode zunutze, um in den 1990er Jahren die Benutzeroberfläche von R/3 in verschiedene Sprachen zu übersetzen. Unicode machte es erst möglich, dieselbe Software an unterschiedlichen Standorten zu verwenden: INTERVIEWPARTNER N: „Und warum wir uns jetzt für SAP entschieden haben. Tja, das ist eine gute Frage. Ich denke, es gibt natürlich einmal die ganz Struktur des SAP Systems, die Möglichkeiten des SAP Systems, alleine die Standardfunktionalitäten, die Möglichkeiten es zu erweitern. Die Möglichkeit, SAP weltweit einzuführen, also sprich mit Unicodes in verschiedene Sprachen, also dass ich auf dem SAP theoretisch in Chinesisch arbeite und gleichzeitig in Russisch und in Deutsch und in Englisch. Dass das alles möglich ist, dass ich unterschiedliche Sprachen installieren kann und für so ein internationales Unternehmen wie S. bleibt dann fast gar keine Alternative mehr übrig.“

33 Ein Beispiel dafür ist die Script Encoding Initiative. Die US-amerikanische Linguistin Deborah Andersen und andere Wissenschaftler der Universität Berkeley setzen sich dafür ein, dass auch ökonomisch weniger interessante Zeichensysteme von kleinen Sprachgemeinschaften oder historische Zeichensysteme im Unicode abgebildet werden. Ihren Appell richtet Andersen vor allem an Wissenschaftler und Wissenschaftlerinnen. Quelle: http://linguistics.berkeley.edu /~dwanders/; Zugriff am 24.03.2013.

D IE

STANDARDISIERTE

S OFTWARE

| 69

Die Mehrsprachigkeit ist eine fundamentale Bedingung für das Funktionieren einer Standardsoftware wie SAP, die in Unternehmen mit Standorten in mehreren Ländern eingesetzt werden soll. Von den Entwicklern erfordert die Mehrsprachigkeit von Software erhebliche Anstrengungen, vor allem bei der Darstellung von Sprachen, die auf unterschiedlichen Zeichensystemen basieren. Plattner illustriert dies am Beispiel der Übersetzung der SAP-Software vom Deutschen ins Japanische. „That was a big challenge. That was a humongous challenge. That was the highest investment for one single task or single objective we ever undertook. We invested for three years to build a fully blown two-digit double byte character version [Bezeichnung für eine 16-Bit-Zeichencodierung: H. M.] of the system, and their every single word is in Japanese. All documentation, all screens, everything, all people working in this office in Japan are Japanese, and Americans and Germans are only sitting in a back office. We were rich enough to afford this, and we did this, and now Japan is our third-largest market. It’s USA, then Germany, then Japan.“ (HP Oral History 1997: 24)

Natürlich vereinfacht diese Beschreibung den Übersetzungsvorgang, denn eine Wort-für-Wort-Übersetzung vom Deutschen ins Japanische ist gerade nicht möglich. Plattner behauptet implizit, die Übersetzungsregeln von einem in das andere Zeichensystem seien eindeutig bestimmbar. INTERVIEWPARTNER D: „SAP hat ja im Prinzip als Grundsprache Deutsch oder Englisch, aber wenn jetzt bestimmte Sachen, zum Beispiel Masken übersetzt werden müssen und die im Standard eigentlich drin sein sollen, gibt’s da richtige Übersetzungsteams.“

Die Übersetzung von SAP in eine andere Sprache betrifft nicht nur Textelemente der Benutzeroberfläche; sie setzt auch die Übersetzung der mehr als zwei Millionen Zeilen umfassenden Online-Dokumentation voraus, die für jede Sprachversion als Leitfaden für die Benutzung der Software zur Verfügung gestellt wird. Damit die Textelemente (z. B. Feldbeschreibungen und Listenüberschriften) verschiedener Sprachen mit derselben Software dargestellt werden können, werden sie in einer Tabelle außerhalb der eigentlichen Programme gespeichert. Die Tabelleninhalte sind aus dem Quelltext der Programme heraus als Konstanten abrufbar. Je nachdem, welche Sprache der Benutzer verwendet, können automatisch die passenden Texte ausgewählt und dargestellt werden.

70 | D AS P ROJEKT SAP

R/3 gab es in den 1990er Jahren in insgesamt 23 Sprachversionen.34 Damit dieselbe Software an mehreren Standorten einer Organisation verwendet werden kann, sind jedoch nicht nur unterschiedliche Sprachversionen notwendig. Nicht nur Textelemente der Benutzeroberfläche müssen übersetzt werden, sondern auch zahlreiche wirtschaftliche, steuergesetzliche, kalendarische und metrische Besonderheiten müssen in den Anwendungsprogrammen der Software berücksichtigt werden, die an den jeweiligen Standorten der Organisation gelten. Die Herstellung sogenannter Länderversionen von SAP wird im Folgenden behandelt. 1.3.2 Die Globalisierungsdatenbank Die Darstellbarkeit unterschiedlicher Währungssysteme, die in den Anwendungsprogrammen der Software parallel abgebildet und mithilfe aktueller Währungskurse übertragen werden können, ist für eine Standardsoftware wie SAP besonders wichtig. Darüber hinaus müssen auch internationale Maßeinheiten abgebildet werden. In den Anwendungsprogrammen werden zahlreiche rechtliche Regeln aus den verschiedenen nationalen Umfeldern berücksichtigt. Beispielhaft seien hier die Personalwirtschaft und das Finanzwesen mit ihren rechtlichen Spezifika an den verschiedenen Standorten eines Unternehmens genannt. Diese resultieren u. a. aus den unterschiedlichen nationalen Systemen der Besteuerung und Sozialversicherung. Mit den lokalen Anforderungen an die Standardsoftware von SAP haben sich auch die Wirtschaftsjournalisten Ludwig Siegele und Joachim Zepelin (2009: 139) auseinandergesetzt. „Der harte Kern der Software ist überall gleich. Aber er ist mit einer Globalisierungsschicht überzogen, in der alle lokalen Eigenheiten gespeichert sind und die praktisch wie ein Filter wirkt, durch den alle Daten hindurch müssen.“

Die „Globalisierungsschicht“ (ebd.) beschreibt E im folgenden Interviewausschnitt weniger metaphorisch als Globalisierungsdatenbank. Es handelt sich dabei um die Grundlage für die Abbildung und Modellierung eines an mehreren Standorten operierenden Unternehmens. Die Datenbank und ihrer Dateneinträge

34 Ende der 1990er Jahre gab es die Standardsoftware in den folgenden Sprachversionen: Chinesisch (Mandarin), Dänisch, Deutsch, Englisch, Finnisch, Französisch, Griechisch, Hebräisch, Italienisch, Japanisch (Kanji), Koreanisch, Niederländisch, Norwegisch, Polnisch, Portugiesisch, Russisch, Schwedisch, Slowakisch, Slowenisch, Spanisch, Tschechisch, Türkisch und Ungarisch.

D IE

STANDARDISIERTE

S OFTWARE

| 71

ermöglichen es der Organisation überhaupt erst, lokale Eigenheiten in den betriebswirtschaftlichen Abläufen an einem Standort zu registrieren und aufzunehmen. INTERVIEWPARTNER E: „Also es sind nicht alle Länder [deren lokale Eigenheiten in der Globalisierungsdatenbank dargestellt werden: H. M.]. Knapp 50 von über 200 Ländern auf der Welt. Aber es sind die kritischen Länder. Die Globalisierungsdatenbank wird laufend aktualisiert. Es ist ein interessantes Tool, weil da kriegen sie zumindest schon mal einen Eindruck, wo sie wirklich drauf aufpassen müssen, wenn sie in ein Land gehen wie Russland, was sind die Top 5 Legal Changes, die immer wieder abverlangt werden und die können sie dann mit Hinweisen direkt standardmäßig implementieren. Es kann aber auch durchaus sein, dass man sagt okay, das lohnt sich nicht. Der Change ist uns zu teuer. Dann muss der Kunde halt eine individuelle Anpassung fahren.“

Keineswegs werden alle Länder der Welt in die Globalisierungsdatenbank der Software aufgenommen. Vielmehr beschränkt man sich auf 50 „kritische Länder” (ebd.). Nach welchem Kriterium diese Auswahl erfolgt, expliziert E nicht. Die Globalisierungsdatenbank von SAP listet die gesetzlichen Bestimmungen verschiedener Länder auf, die mit entsprechenden Einstellungen in den Anwendungsprogrammen der Standardsoftware automatisch berücksichtigt werden können. INTERVIEWPARTNER E: „Sie können für die Länder, die eine Länderversion haben, Check fahren, welche legalen steuerlichen und ja, zollrechtlichen Anforderungen da gebraucht werden. Das heißt, sie können wirklich, sie kriegen ein Makro aufgemacht. Da klicken sie an, welche Länder sie interessieren im Vergleich oder vielleicht interessiert sie auch nur ein Land. Dann gibt’s aus der finanztechnischen, aus der materialwirtschaftlichen Sicht bestimmte Standard-Formulare, die hinterlegt sein müssen. Es gibt aber auch Abweichungen pro Land und diese Abweichungen und Hinweise dazu werden quasi in dieser Globalisierungsdatenbank zur Verfügung gestellt.“

Ausgangspunkt zur Angleichung von länderspezifischen Anforderungen an die Software ist eine bereits bestehende Softwareversion für ein Land. Spezifische lokale Merkmale im Bereich Finanzen und Materialwirtschaft werden demzufolge als Abweichungen interpretiert. Im folgenden Interviewausschnitt begründet C die weltweite Verbreitung von SAP-Software, die ja zunächst für Unternehmen in Deutschland entwickelt worden war, damit, dass die Software, im Vergleich mit Softwareprodukten amerikanischer Provenienz, von Vornherein darauf eingestellt war, besonders komplexen lokalen Ansprüchen zu genügen.

72 | D AS P ROJEKT SAP INTERVIEWPARTNER C: „In Deutschland war das überhaupt nie ein Thema, weil die deutsche Personalabrechnung mit unseren schönen Steuergesetzen so schwierig ist, dass die meisten, alle kläglich dran gescheitert sind, die aus Amerika kamen. Die konnten es nicht. Da konnte das System das nicht. Mittlerweile soll es gehen. Ich kenne keinen, der es hat. Ist natürlich schlecht, wenn du ein Land nicht kannst personalabrechnungstechnisch, das auch noch ein großes Industrieland ist. Also ich sag jetzt mal, die G8 sollte man können, bei den großen Firmen dieser Welt.“

Während E noch vage von kritischen Ländern spricht, die in die Globalisierungsdatenbank der Standardsoftware aufgenommen worden seien, stellt C eine präzise Minimalforderung auf, die aus seiner Sicht von einer Standardsoftware erfüllt sein sollte: „G8 sollte man können [...]“ (ebd.). Die Bezeichnung G8 ist die Abkürzung für die Gruppe der Acht, mit der die acht wirtschaftlich und politisch führenden Nationen der Welt bezeichnet werden. Dazu zählen Deutschland, Frankreich, Italien, Japan, Kanada, Vereinigtes Königreich (UK), Vereinigte Staaten (USA) und Russland. Interviewpartner C nutzt diese politische Kategorie, um verschiedene Softwaresysteme hinsichtlich der Darstellbarkeit rechtlicher Regeln in der Personalwirtschaft miteinander zu vergleichen. Die Bedeutung des europäischen Entstehungskontextes der Software betont auch Plattner im folgenden Interviewausschnitt. Er vergleicht SAP mit US-amerikanischen Konkurrenzprodukten hinsichtlich der Darstellbarkeit verschiedener Währungssysteme. „We not only can do in one system Japanese, but we also can do Chinese, Korean, and all the other double bytes. It’s still work to do this. But – and this flexibility was a selling point. It’s multi-currency. That’s the biggest advantage for a European company. The Americans – we forgot to talk about this. American knows only there’s dollar in English. We know the many currencies, and now we get another currency, a Euro, and we get it on top, parallel. No one in America can understand that we deal with two currencies here in one country. And then we have different currencies in each country. So that’s a complexity the American software doesn’t handle well.“ (HP Oral History 1997: 24)

Die Vielfalt lokaler Steuergesetze in den Anwendungsprogrammen und ihre Darstellung an der Softwareoberfläche liefern einen weiteren Beleg für die Bedeutung des deutschen bzw. europäischen Entstehungskontextes. Von Anfang an prägte das technische Problem der gleichzeitigen Darstellbarkeit verschiedener Sprachen, Währungen und gesetzlicher Regeln die Softwareentwicklung im Unternehmen SAP und begünstigte die Herstellung einer globalisierten Standardsoftware.

D IE

STANDARDISIERTE

S OFTWARE

| 73

INTERVIEWPARTNER J: „Wenn man sich diese Supply-Chain-Ketten anguckt, die Lieferketten, dann ist der Informationsfluss ja immer rückwärts gerichtet. Also ich muss von möglichst weit vorne Informationen einsammeln, um bei mir dann, bei meinen Planungen drauf Rücksicht nehmen zu können. Das heißt also, ich habe meinen Warenfluss, ich habe meinen Informationsfluss und Informationsfluss ist halt das, wo SAP von betroffen ist und da gibt’s halt verschiedenste Anforderungen, sowohl was die legale Seite anbelangt als auch was die physische Seite anbelangt. Legale Seite heißt, eine globalisierte Software muss in der Lage sein, länderspezifische Anforderungen abzudecken, also zum Beispiel im Bereich Buchhaltung, im Bereich Personalwesen oder Außenhandel, Zollabwicklungen und eine globale Software muss halt in der Lage sein, diese ganzen Supply-Chain, diese ganzen Lieferketten zu steuern.“

Die Globalisierungsdatenbank, die einige Standorte bzw. Länder berücksichtigt, andere hingegen ignoriert, belegt auch heute noch ein spezifisches Globalisierungsmuster der Software, das auf einem hochselektiven Weltausschnitt der Wirtschaft basiert. Betrachtet man die Mehrsprachigkeit am Beispiel Unicode aus einer soziologischen Perspektive, dann wird deutlich, dass auch die Herstellung informationstechnischer Standards keinesfalls auf rein technische Aspekte zu reduzieren ist. Die Herstellung und die Legitimierung der Technik SAP sind vielmehr Resultate komplexer sozialer Prozesse. In dem Aufsatz Do Artifacts Have Politics? stellt Langdon Winner (1999 [1980]) das in der Techniksoziologie wohl bekannteste Beispiel dafür vor, wie Soziales in technische Artefakte hineingelegt werden kann: „Die Brücken des Robert Moses“ (Joerges 1999). Technische Artefakte, so argumentiert Winner am Beispiel der Brücken, verkörpern gesellschaftliche Strukturen. Weder technische noch finanzielle Gründe sprachen für den Bau der besonders niedrigen Brücken, die in den 1930er Jahren eine Verkehrsanbindung zwischen New York City und den Stränden von Long Island schufen. Ihre niedrige Höhe machte die Durchfahrt für öffentliche Busse unmöglich. Sozial schwächere Bevölkerungsteile, die auf den öffentlichen Nahverkehr angewiesen waren, so Winners Folgerung, wurden systematisch von der Nutzung der exklusiven Strände von Long Island ausgeschlossen. „Because choices tend to become strongly fixed in material equipment, economic investment, and social habit, the original flexibility vanishes for all practical purposes once the initial commitments are made. In that sense technological innovations are similiar to legislative acts or political foundings that establish a framework for public order that will endure over many generations.“ (Winner 1999: 32)

74 | D AS P ROJEKT SAP

Kritiker wie Bernward Joerges (1999) werfen Winner vor, dass sich nicht zweifelsfrei belegen lässt, ob mit dem Bau der Brücken tatsächlich eine soziale Distinktionsabsicht verfolgt wurde und welche Rolle dabei die Interessen einzelner Personen spielte. Joerges zählt Winners Interpretation gar zu einem festen Bestandteil technik- und stadtsoziologischer Folklore. Nichtsdestotrotz ist Winners Aufsatz, in dem er die soziologische Relevanz materieller Artefakte (Techniken, Gebäude etc.) herausarbeitet, weit über die Grenzen techniksoziologischer Forschung hinaus berühmt geworden. So wie Winner heben auch andere Autoren Ähnlichkeiten zwischen einem technischen Artefakt und sozialen Normen und Regeln hervor. Technik ist aus dieser Vergegenständlichungsperspektive ein soziologischer Tatbestand.35 Demzufolge können technische Artefakte „derselben Kategorie sozialer Tatbestände [zugewiesen werden] [...] wie die immateriell institutionalisierten Verhaltensregeln und -zwänge“ (Linde 1972: 17). Die Entwicklung des US-amerikanischen Kodiersystems ASCII und seine Fortentwicklung zum Unicode sind ein gutes Beispiel für die Vergegenständlichungsperspektive. Die Benachteiligung nicht-englischer Sprachen und Sprachgemeinschaften im Internet haben Daniel Pargman und Jacob Palme (2009) in dem Aufsatz ASCII Imperialism untersucht. Sie zeigen, wie Soziales in eine vermeintlich neutrale Technik hinein gelegt wird. Die Software und ihre Anwendungsprogramme repräsentieren ebenfalls, so konnte in diesem Kapitel gezeigt werden, einen hochselektiven Weltausschnitt. Die Herstellung von Länderversionen folgte zunächst einem bestimmten Muster der Globalisierung, das die Interessen und Internationalisierungsstrategien einer Handvoll multinationaler Konzerne widerspiegelt. Grundlegend für die Entwicklung der Technik war jedoch die Idee für eine Standardsoftware, die von vielen unterschiedlichen Organisationen verwendet werden sollte. Diese Idee wird im nächsten Kapitel erörtert.

35 Durkheim definiert diesen folgendermaßen: „Ein soziologischer Tatbestand ist jede mehr oder minder festgelegte Art des Handelns, die die Fähigkeit besitzt, auf den Einzelnen einen äußeren Zwang auszuüben; oder auch, die im Bereich einer gegebenen Gesellschaft allgemein auftritt, wobei sie ein von ihren individuellen Äußerungen unabhängiges Eigenleben besitzt.“ (Durkheim 1984: 114)

2. Die Idee für eine Standardsoftware und die Entstehungsgeschichte von SAP

Die betriebswirtschaftlichen Anwendungsprogramme der Software sind in verschiedene Module gegliedert: Modul FI für die Finanzbuchhaltung, Modul CO für das Controlling, Modul MM für die Materialwirtschaft, Modul SD für den Verkauf und den Vertrieb, Modul PP für die Produktionsplanung und Modul HR für die Personalverwaltung eines Unternehmens. Über vordefinierte Schnittstellen sind diese Module zu einem komplexen System verknüpft. Obwohl weitere Module und Komponenten im Laufe der Jahre hinzugekommen sind, bilden die aufgezählten Module weiterhin den Kern der Standardsoftware.1 Das Organisationsmodell der Software wurde nicht am Reißbrett entwickelt. Zunächst wurden Arbeitsabläufe konkreter Vorbilder modelliert; Beschreibungen unterschiedlicher Organisationen wurden in den Programmen festgehalten. Die Idee für das Konzept der Standardsoftware erläutert Plattner (1997: 112) in einem Interview so: „Ich habe bis vor einem Jahr behauptet, wir müssen nur die unendlich vielen Organisationsmuster der Firmen so lange übereinanderlegen, bis wir ein Muster erkennen. Dann können wir daraus eine Standardsoftware entwickeln.“

1

CRM und SRM sind nur zwei Beispiele. Diese Abkürzungen stehen nicht für Bereiche in einem Unternehmen, sondern eher allgemein für Managementkonzepte: CustomerRelationship-Management und Supply-Chain-Management. Deutlich wird daran, dass mithilfe von SAP-Anwendungsprogramme nicht nur organisationsinterne Arbeitsabläufe modelliert werden, sondern auch organisationsübergreifende Arbeitsabläufe informationstechnisch gestaltet werden sollen.

76 | D AS P ROJEKT SAP

Diese Beschreibung erweckt den Eindruck, dass für die Herstellung des Organisationsmodells der Software objektive Kriterien entscheidend waren. Stellt man das von Plattner beschriebene Organisationsmodell bzw. „Muster“ (ebd.) grafisch dar, ergibt dies das folgende Bild: Abbildung 11: Herstellung des Organisationsmodells (a)

Quelle: Eigene Darstellung

Die gestrichelte Linie markiert ein vermeintlich neutrales Modell, das in „unendlich vielen Organisationsmuster(n)“ (ebd.) enthalten ist. Es handelt sich bei diesem Organisationsmodell um den kleinsten gemeinsamen Nenner von existierenden Beschreibungen von vielen verschiedenen Organisationen. Da davon ausgegangen wird, dass es sich beim Organisationsmodell der Software um das Ergebnis eines sozialen Aushandlungsprozesses handelt, muss ein anderes Bild gezeichnet werden.

D IE

STANDARDISIERTE

S OFTWARE

| 77

Abbildung 12: Herstellung des Organisationsmodells (b)

Quelle: Eigene Darstellung

Wieder durch eine gestrichelte Linie dargestellt, ist das Organisationsmodell der Software diesmal nicht aus den verschiedenen bereits existierenden Mustern abzuleiten. Es werden zwar viele Muster eingeschlossen, einige Muster werden jedoch nicht vollständig berücksichtigt. Welche Kriterien bei der Herstellung des Organisationsmodells der Software zugrunde gelegt wurden, kann dieser bildlichen Darstellung nicht entnommen werden. Die Herstellung und Verbreitung sind in der Entstehungsgeschichte von SAP miteinander verzahnt, denn viele verschiedene Unternehmen, die der Softwarehersteller zu seinen Kunden zählte, waren an der Herstellung des Organisationsmodells der Software beteiligt.2 Auf den folgenden Seiten gehe ich auch auf die Unternehmensgeschichte ein, weil sie im Fall von SAP untrennbar mit der Softwaregeschichte verknüpft ist. Den Markterfolg des Softwareherstellers SAP begründet der Wirtschaftshistoriker Timo Leimbach (2007) mit vier Faktoren: 1) Das Unternehmen SAP hat sich auf die marktdominierende Hardware von IBM konzentriert. 2) SAP hat eng mit Schlüsselkunden zusammengearbeitet. 3) Die Internationalisierung des Unternehmens SAP ist über Kunden- und Partnerunternehmen organisiert worden.

2

In den Programmen von Standardsoftware wie SAP spiegeln sich, so auch Pollock und Williams (2009: 129ff.), die Besonderheiten von Unternehmen und Branchen wider, in denen die Software bereits installiert wurde.

78 | D AS P ROJEKT SAP

4) Lange Zeit hielt der Softwarehersteller an der Idee eines Produktunternehmens fest und überließ komplementäre IT-Dienstleistungen anderen Partnerunternehmen als Geschäftsfeld. Leimbach gliedert die Unternehmensgeschichte von SAP in drei Phasen. In den Jahren 1972 bis 1981 wird das Unternehmen aufgebaut und die erste Version der Software (R/1) wird entwickelt. Die Jahre 1982 bis 1994 stehen sowohl für die Internationalisierung des Unternehmens als auch für die Internationalisierung der Software. R/2 wird vor allem in grenzüberschreitend tätigen Konzernen eingesetzt. Seit Mitte der 1990er Jahre zählt das Unternehmen SAP zu einem der weltweit größten Softwarehersteller. R/3 hat mittlerweile den Status eines de facto-Standards für große und mittlere Unternehmen. Das Organisationsmodell der Software ist das Produkt einer Verbreitungsgeschichte. Die folgenden Ausführungen belegen diese These. Die Darstellung der Verbreitungsgeschichte basiert auf Interviews mit Beratern und Entwicklern, Publikationen des Softwareunternehmens (z.B. Plattner et al. 2000), Presseberichten und Fachartikeln (z.B. Die Computerwoche) sowie journalistischen Darstellungen der SAP-Unternehmensgeschichte (z.B. Siegele & Zepelin 2009; Meissner 1997).

2.1 D IE ERSTE E NTSTEHUNGSPHASE : G RUNDMODULE UND DAS B AUKASTENPRINZIP In enger Zusammenarbeit mit ihrem ersten Kunden Imperial Chemical Industries (ICI) programmieren und testen die Entwickler von SAP im Jahr 1972 ihre Anwendungsprogramme für die Finanzbuchhaltung und die Materialwirtschaft des Unternehmens. Das erste Softwaremodul RF entwickeln sie noch auf dem firmeneigenen Großrechner von ICI. Die in diesem Modul gebündelten Anwendungsprogramme für das Rechnungs- und Finanzwesen eines Unternehmens stellen die Grundlage für die erste Version der Software (System R bzw. R/1) dar. Bei ICI werden erstmals Daten aus der Finanzbuchhaltung und der Materialwirtschaft in Echtzeit verknüpft und verarbeitet. Im Jahr 1973 wird bei ICI die Finanzbuchhaltung eines Unternehmens erstmalig vollständig elektronisch abgewickelt. Zwei Jahre später erweitert man das System der Software um zwei Module. Bestandsbuchführung und Rechnungsprüfung organisiert ICI nun ebenfalls elektronisch. Die Bedeutung der Organisation ICI für die Entwicklung der Standardsoftware resümiert man beim Softwarehersteller SAP in einer Unternehmenspublikation Jahre später so:

D IE

STANDARDISIERTE

S OFTWARE

| 79

„Working on behalf of the German office of a British multinational also drove home the need to solve problems of global business from the beginning. While its American rivals would struggle years later to retrofit their native products to use abroad, SAP’s applications had been prepared for multiple currencies and governments all along.“ (SAP 2004: 3)

Der Allgemeine Berichtsaufbereitungsprozessor (ABAP) wird erstellt, um das Auswerten von Daten bei ICI nach festgelegten Kriterien zu automatisieren. Später wird ABAP zu einer höheren Programmiersprache ausgebaut.3 Nicht nur die Programmiersprache ABAP hat ihren Ursprung im ICI-Projekt. Auch die Darstellungsmöglichkeiten für unterschiedliche Währungen sowie die Berücksichtigung länderspezifischer Vorschriften, die für die Arbeitsabläufe in einem multinationalen Konzern wie ICI relevant sind, fließen in das ursprüngliche Organisationsmodell der Software ein. Noch hat dieses Modell konkrete Organisationen zum Vorbild. Es bietet eine Vergleichsgrundlage, um die Arbeitsabläufe in anderen Unternehmen, die sich nach und nach für die Einführung von SAP-Software entscheiden, entweder an dieses Modell anzupassen oder das Organisationsmodell der Software entsprechend zu erweitern. Um möglichst viele Geschäftsprozesse im System der Software abbilden und miteinander verzahnen zu können, empfehlen die Entwickler von SAP ein Vorgehen nach dem Baukastenprinzip: „Ein störungsfreier Informationsfluß [in Organisationen: H. M.] kann nur durch eine schnittstellenfreie Kopplung aller Teilsysteme zu einem integrierten Gesamtsystem gewährleistet werden. Allerdings würden einige Jahre benötigt für den Aufbau eines solchen Systems. [...] Gefordert ist hier die EDV-technische Modularität, die eine Einführungsstrategie nach dem Baukastenprinzip ermöglicht, entsprechend den strategischen Erfordernissen des Unternehmens.“ (Plattner & Kagermann 1988: 139)

Darüber hinaus erachten sie das Prinzip der Übertragung als grundlegend für die Softwareentwicklung und das zugrunde liegende Organisationsmodell. Es gewährleistet die Verzahnung unterschiedlicher Anwendungsgebiete in einem Unternehmen und sorgt dafür, dass die verschiedenen Fachgebiete in einem Unternehmen in den Programmabläufen der Software modelliert werden können. „Ähnliche Funktionsbausteine benachbarter Anwendungen stehen quasi als Gleichteile zur Verfügung und können auf das eigene Arbeitsgebiet übertragen werden. Die meisten Entwicklungen auf dem technisch-naturwissenschaftlichen Sektor der letzten Jahrzehnte be-

3

Seither steht das Akronym ABAP für Advanced Business Application Programming.

80 | D AS P ROJEKT SAP ruhen auf dem Prinzip der Übertragung bewährter Arbeitstechniken und Methoden.“ (Ebd.: 156)

Das aus dem technisch-naturwissenschaftlichen Bereich stammende Prinzip instruiert nicht nur die Entwicklung der Standardsoftware; es spielt auch bei der Modellierung konkreter Arbeitsabläufe bei der Softwareeinführung eine zentrale Rolle. Ein Berater erläutert das Vorgehen bei der Modellierung von Arbeitsabläufen. INTERVIEWPARTNER A: „Ein Beispiel aus der Modellierung war, dass wir zusammen gesessen haben und der im Umfeld der Beschaffung, der Einkäufer, der Leiter Einkauf, dann gesagt hat, ja heute läuft eigentlich der gleiche Prozess in zwei verschiedenen Abteilungen. Einmal ist es im Einkauf, ja, wenn es aber ein anderes Thema ist, ich kaufe also kein PC oder kein Bleistift, sondern ich kaufe Produktionsmaterial oder eine Anlage, dann läuft das heute in der Arbeitsvorbereitung.“

Das Organisationsmodell der Software basiert auf abstrakten Beschreibungen von Arbeitsaufgaben und Tätigkeiten. Diese sind unabhängig von konkreten Inhalten und Personen. Auf der Grundlage solcher Beschreibungen werden auch die Nutzerrollen für die Software erstellt. Das Berechtigungskonzept der Software für ein Unternehmen wird entwickelt, indem Aufgaben, die an unterschiedlichen Stellen in der Organisation von mehreren Mitarbeitern ausgeführt werden, als gleichartig identifiziert und entsprechend zusammengefasst werden. INTERVIEWPARTNER A: „Da heißt, der Mensch ist Beschaffer, bei uns heißt er Einkäufer. Da haben wir gesagt, da legen wir das zusammen. Der heißt jetzt nur noch Beschaffer. Das sind so typische Veränderungen, die dann dadurch passieren. Man sagt, okay eigentlich identifizieren wir erst im Unternehmen zwei gleiche Prozesse. Die machen eigentlich das gleiche. Wir wollen das aber nicht in Zukunft mehr unterscheiden. Die Rolle ist ja eigentlich die gleiche. Also legen wir die Rolle zusammen.“

Dass das Prinzip der Übertragung nicht nur die Softwareentwicklung, sondern auch die Definition von Organisationsrollen kennzeichnet, wird an dieser Stelle deutlich. Das System R bzw. R/1 wird in den folgenden zwei Jahren in 24 weiteren deutschsprachigen Unternehmen implementiert. Dazu zählen auch zwei österreichische Unternehmen. Für eines dieser Unternehmen wird ein zusätzliches Modul für die Anlagenbuchhaltung entwickelt. Dieses Programm wird ein Jahr später in das bestehende Softwarepaket integriert. Im Jahr 1979 wird R/2 der Öffentlichkeit vorgestellt. Die Entwickler erweitern die Urform der Software

D IE

STANDARDISIERTE

S OFTWARE

| 81

um weitere Module für die Kostenrechnung und danach für die Planung und Steuerung von Produktionsabläufen in Unternehmen. Auch die Arbeit an einem Modul für die Personalwirtschaft beginnt. Eine französische Länderversion der Software für die Buchhaltung wird erstellt. Für den Kunden John Deere wird die Software in die englische und französische Sprache übersetzt, um sie an mehreren europäischen Standorten zu verwenden. Im Jahr 1980 verwenden bereits 50 der 100 größten deutschen Unternehmen die Standardsoftware. In den 1980er Jahren wird das Organisationsmodell der Software um weitere Anwendungsbereiche und Programmbausteine ergänzt; auch Produktionsabläufe und die Personalverwaltung werden nun in den betriebswirtschaftlichen Anwendungsprogrammen modelliert.

2.2 D IE ZWEITE E NTSTEHUNGSPHASE : D IE I NTERNATIONALISIERUNG DER S OFTWARE Aufträge verschiedener europäischer Tochterunternehmen deutscher Chemiekonzerne und US-amerikanischer Erdölkonzerne sorgen dafür, dass Anfang der 1980er Jahren die Darstellungsebene der Software in verschiedene europäische Sprachen übersetzt wird und national unterschiedliche rechtliche und steuergesetzliche Regeln auf der Anwendungsebene berücksichtigt werden. Beispielsweise wird eine japanische Länderversion der Standardsoftware erstellt, denn viele High-Tech-Unternehmen an der US-amerikanischen Westküste unterhalten enge Geschäftsbeziehungen mit japanischen Zulieferunternehmen oder gründen Tochterunternehmen in Japan. Die Mehrsprachigkeit wird zu einem wichtigen Entscheidungskriterium bei der Auswahl der Software.4 Das deutsche Technologieunternehmen Heraeus implementiert 1983 R/2 für die Planung und Steuerung seiner Produktionsabläufe. Andere Unternehmen verwenden die Anwendungsprogramme von SAP in der Personalwirtschaft. R/2 wird inzwischen von 60 der 100 größten deutschen Unternehmen verwendet, um Arbeitsabläufe in ihren Unternehmensbereichen miteinander zu verzahnen und die Kommunikation mithilfe der Software standortübergreifend zu organisieren. Im Jahr 1985 können Unternehmen die Standardsoftware theoretisch an Standorten in 15 verschiedenen Ländern verwenden. Die Internationalisierung von R/2 folgt einem besonderen Muster. Dieses Muster wird durch einige wenige Unternehmen vorgezeichnet, denn die Liste der Länderversionen ist deckungsgleich mit den Standorten der zum damaligen Zeitpunkt größten Kunden des Software-

4

Vergleiche hierzu die Erläuterungen in Kapitel 1.3 „Die Darstellungsebene“.

82 | D AS P ROJEKT SAP

herstellers.5 Es spricht also einiges dafür, dass es in den 1970er und 1980er Jahren existierende Beziehungen zwischen dem Softwarehersteller und einzelnen Unternehmen sind, die die Softwareentwicklung und das Organisationsmodell der Software entscheidend prägen.

2.3 D IE DRITTE E NTSTEHUNGSPHASE : SAP ALS DE FACTO -S TANDARD Die Entwicklungsarbeiten für R/3 beginnen bereits Mitte der 1980er Jahre. Vorgestellt wird die neue Softwareversion im Jahr 1991 auf der CeBIT-Messe.6 Eines der ersten Unternehmen, das sich Anfang der 1990er Jahre für R/3 entscheidet, ist das dänische Unternehmen Kamura, Tochterunternehmen eines finnischen Düngemittelherstellers. Mit R/3 sollen eigentlich Produktionsunternehmen mittlerer Größe als Neukunden gewonnen werden. Das erste Unternehmen, das in den USA Interesse zeigt, ist jedoch der Konzern Chevron Oil. Zu diesem Zeitpunkt ist das Erdölunternehmen in mehr als 180 Ländern tätig. In einem Interview berichtet Plattner, wie SAP die Konzernleitung schließlich von der neuen Software überzeugen konnte. „We fought for six weeks. We flew Chevron over to this little Kamura Company in Denmark – big Chevron, little Kamura, dealing with that fertilizer. It’s a fertilizer producer. Big upstream, downstream oil company – number ten in the U.S. We won. We won against Oracle; we won against G.D. Edwards, SSA, and all the other ones because they wanted a Unix system and that means now R/3 is in the big league. R/3 is on top of R/2 and we had to change all our development plans. We couldn’t stop it anymore. A gold rush started because we were lucky again.“ (HP Oral History 1997: 18)

5

Neben zehn europäischen Ländern, den USA und Kanada sind Kuwait, Trinidad/Tobago und Südafrika in dieser Liste aufgeführt. In der Unternehmensgeschichte nennt der Softwarehersteller US-amerikanische Erdölunternehmen und den Landmaschinenhersteller John Deere als Schlüsselkunden für die Weiterentwicklung der Standardsoftware in den 1980er Jahren. Kuwait und Trinidad zählen zu den wichtigen erdölexportierenden Ländern, Südafrika gilt als eines der weltgrößten Exportländer für Agrarprodukte.

6

Die CeBIT gilt bis heute als weltgrößte Computermesse. Das Centrum der Büro- und Informationstechnik war zunächst ein Teil der seit 1947 jährlich stattfindenden Hannover Messe. Seit 1986 ist die CeBIT eine eigenständig Messe (vgl. Tasch 1997).

D IE

STANDARDISIERTE

S OFTWARE

| 83

Kamura dient als Modellorganisation, um die Funktionsweise der Anwendungsprogramme anderen Unternehmen vorzuführen. Auf den ersten Blick werden vollkommen unterschiedliche Unternehmen miteinander verglichen. Der Größenunterschied zwischen den Unternehmen (z. B. Anzahl der Softwarenutzer und Unternehmensstandorte) spielt bei dem Organisationsvergleich Kamura vs. Chevron Oil jedoch nur eine untergeordnete Rolle. Die verteilte Rechnerarchitektur ermöglicht eine horizontale Skalierbarkeit des Systems der Software. D.h., durch das Hinzufügen und Entfernen von Rechnern können dieselben Anwendungsprogramme sowohl in kleineren Unternehmen mit wenigen Softwarenutzern als auch in großen Unternehmen mit vielen Softwarenutzern verwendet werden.7 Obwohl R/3 ursprünglich für mittlere Unternehmen konzipiert worden war, entscheiden sich in den 1990er Jahren vor allem international tätige Konzerne für die Standardsoftware.8 Zahlreiche Unternehmen ziehen nach. Mitte der 1990er Jahre hat der Softwarehersteller besonders hohe Umsatzsteigerungen.9 Organisationen können zu diesem Zeitpunkt bereits zwischen branchenspezifischen Vorlagen (templates) der Software wählen. Die Softwareimplementierung überlässt der Softwarehersteller in dieser dritten Phase anderen IT-Dienstleistungsunternehmen. Zu diesem Zeitpunkt wird SAP-Software bereits als sogenannte Plattform-Technik vermarktet. Dies führt zur Öffnung des Marktes für betriebswirtschaftliche Software für Anbieter von Nischenprodukten und zur Zusammenarbeit zwischen SAP und kleineren Softwareherstellern, die sich auf besondere Anwendungsbereiche spezialisiert haben. Deren Softwareprodukte lassen sich über standardisierte Schnittstellen mit den SAP-Anwendungsprogrammen verknüpfen (vgl. Koch 2000; Sprott 2000; Sawyer 2001). Wenngleich einzelne Unternehmen bis heute als Modellorganisation für die Fortent-

7

Vergleiche hierzu die Erläuterungen in KAPITEL 1.1.4 „Die Softwarearchitektur“.

8

Dies spiegelt sich beispielsweise in der folgenden Auflistung wider, die einer offiziellen Darstellung der SAP-Unternehmensgeschichte entnommen ist: Burger King, Chevron Oil, Coca Cola, Daimler Benz, Deutsche Post, Deutsche Telekom, Dow Chemicals, DuPont, Freudenberg, General Motors, Grünzweig und Hartmann, Hewlett Packard, Hoechst, IBM, ICI, John Deere, Microsoft, Mobil, Nestlé, Rothändle, Visteon und Würth. Auswahlkriterium für diese Zusammenstellung ist die öffentliche Bekanntheit der Unternehmensnamen. Es fehlt allerdings entsprechendes Datenmaterial, um genauer zu untersuchen, ob und inwieweit diese Unternehmen konkreten Einfluss auf die Softwareentwicklung genommen haben.

9

Vergleiche hierzu die Angaben zur Umsatzentwicklung des Softwareherstellers im ANHANG.

84 | D AS P ROJEKT SAP

wicklung der Software wichtig sind, hat sich die Art der Beziehung zwischen dem Softwarehersteller und den Nutzern der Software verändert. Anwendergemeinschaften spielen eine zunehmend wichtige Rolle. Intermediäre Organisationen schieben sich zwischen das Softwareangebot und die Softwarenachfrage. Beratungsunternehmen vermitteln zwischen Angebot und Nachfrage. Eine in der anwendungsorientierten Literatur häufig vorgebrachte generelle Kritik an den Herstellern standardisierter Softwareprodukte wie SAP lautet deshalb, dass diese sich nur ein unvollständiges Bild machen und wenig Verständnis für den konkreten IT-Bedarf von Organisationen haben. Softwarehersteller würden sich bei ihrer Produktentwicklung auf Marktanalysten und Berater verlassen. Sie selbst haben gar keinen direkten Kontakt mehr zu den potenziellen Anwendern ihrer Software. Pollock und Williams (vgl. 2009: 34) sprechen von einer Verschiebung der Produktentwicklung in ein zunehmend öffentliches Forum. Die verschiedenen Aktivitäten von Softwareherstellern beschreiben sie unter der Überschrift „managing of communities“ (ebd.). Die Verbreitungsgeschichte der Technik soll im nächsten Kapitel aus einer organisationstheoretischen Perspektive betrachtet werden.

3. Die Softwareverbreitung

Zu Beginn meiner Feldforschung bat ich einige Interviewpartner und Interviewpartnerinnen um ihre Einschätzung, warum man sich in ihrem Unternehmen für die Einführung von SAP-Software entschieden hat. Die Softwareentscheidung für SAP war von den Unternehmen, deren Repräsentanten befragt wurden, bereits in den 1990er Jahren getroffen worden. Zu dieser Zeit waren sowohl der Softwarehersteller SAP als auch die Software R/3 bereits am Markt etabliert.1 Interviewpartnerin W, Leiterin einer Informationsabteilung, führt vor allem technische Faktoren an. INTERVIEWPARTNERIN W: „1993 kam glaube ich das erste R/3-Release auf den Markt. Da war man sozusagen, wenn man auf ein neues System musste, was ja in vielen Unternehmen nahe lag, auf der sicheren Seite. Spätestens mit dem Jahr 2000, war es natürlich eine risikoaverse Entscheidung, sich für SAP zu entscheiden. Das spielt, denke ich, von den Entscheidern her eine Rolle. Die Entscheidung war risikoavers, weil es alle gemacht haben. Selbst wenn es Mist gewesen wäre, mit der Entscheidung, wäre man zumindest in guter Gesellschaft gewesen. Wenn ich einen Exoten wähle, von dem ich voll überzeugt bin, dann bin ich voll verantwortlich. Da ist das Risiko des Köpfens größer und geköpft wird gerne schon mal.“

In den 1990er Jahren waren viele Unternehmen gezwungen, ihre elektronische Datenverarbeitung auf eine neue Generation von System- und Anwendungssoft-

1

Dies kann an der Umsatzentwicklung und den Mitarbeiterzahlen festgemacht werden. Im ANHANG sind die Umsätze und Mitarbeiter nach Angaben aus Geschäftsberichten und Pressemeldungen der SAP AG für den Zeitraum 1972 bis 2011 aufgelistet. 1989 und 1994 sind Geschäftsjahre, zu denen der Umsatz im Vergleich zum Vorjahr besonders stark anstieg.

86 | D AS P ROJEKT SAP

ware umzustellen, in deren Programmierzeilen ein vierstelliges Datumsformat verwendet wurde. Um Speicherplatz zu sparen, hatten Programmierer in den 1950er und 1960er Jahren noch eine zweistellige Jahresangabe verwendet. „Future generations of programmers continued to use the MM/DD/YY and other limited date formats simply because those were the standards set by their predecessors. Only in the 1990s did the realization spread that what was once a feature had now become a bug“, so Paul N. Edwards (1998) in einer techniksoziologischen Analyse des Jahr-2000-Problems. Die fehlenden zwei Stellen bei der Jahresangabe wären zum Jahreswechsel 1999/2000 zum Problem geworden. Der Computer zählte nämlich nur bis zum 31.12.99 korrekt. Der 1. Januar 2000 würde als 01.01.00 registriert und folglich als 1. Januar 1900 vom Rechner interpretiert werden. Deshalb mussten die Grundeinstellungen der Programme und Datenbestände nachträglich auf das vierstellige Format für die Jahresangabe umgestellt werden. Nur so würde es nicht zu falschen Sortierungen und Berechnungen von Datensätzen kommen. Diese einfach anmutende Veränderung war mit erheblichen Kosten verbunden. Aufwendig wurde sie durch die Vielzahl der Programme, ihre wechselseitigen Abhängigkeiten und die häufig unzureichende oder fehlende Dokumentation vieler Softwareprogramme, die über einen Zeitraum von 20 oder mehr Jahren entstanden waren (vgl. Ensmenger 2010: 227). Die R/3-Software, die Anfang des Jahres 1993 am Markt erhältlich war, erfüllte die notwendige technische Anforderung, mit vier Stellen für die Angabe des Jahres zu operieren. Für ein Unternehmen ist die Entscheidung für ein Softwareprodukt wie SAP mit verschiedenen Unsicherheiten verknüpft. Unsicherheit herrscht einerseits darüber, welche konkreten Anforderungen eine Organisation an die Software stellt.2 Andererseits gibt es Unsicherheit darüber, welche Funktionalitäten eine Software überhaupt besitzt und welche Funktionalitäten erweitert werden können (vgl. Fleck et al. 1990). Der Bereichsleiter der IT-Abteilung eines anderen Unternehmens begründet die Softwareentscheidung für SAP mit den guten Wartungs- und Pflegemöglichkeiten der Software, die auch ihre problemlose Weiterentwicklung umfassen. INTERVIEWPARTNER F: „Und auch, weil du dann halt weißt, du hast eine Lösung, die auch in dem Sinne, wo du auch Unterstützung bekommst, wo du auch davon ausgehen kannst, die wird weiterentwickelt. Wenn du irgendwie so eine exotische Lösung nimmst, ist halt

2

Auf das Problem der Explikation konkreter Anforderungen an die Software und ihre Anwendungsprogramme wird in KAPITEL 6.1 „Die Konkretisierung der Anforderungen“ eingegangen.

D IE

STANDARDISIERTE

S OFTWARE

| 87

die Gefahr, dass ja, weißt du vielleicht nicht, vielleicht gibt es die Firma gar nicht mehr in drei Jahren und dann stehst du da mit einer Superlösung zwar, aber keiner kann dir mehr weiterhelfen dann. Und wenn du halt siehst, deine fünf Konkurrenten, die Größten, die haben das alle und bei denen funktioniert es gut, dann ergibt es sich, dann könnte es dich auch dazu bewegen zu sagen ja, dann nimmst du es auch. Es kann natürlich auch sein, dass du sagst, dann will ich es erst recht nicht. Aber was anderes, wirklich besseres gibt’s auch nicht.“

Die Marktführerschaft oder zumindest eine starke Marktposition werden oft als Indiz dafür gewertet, dass Wartungsverträge eingehalten werden können, die Weiterentwicklung der Software gesichert ist und auch bei finanziellen Problemen des Softwareherstellers diese Dienstleistung nicht eingestellt wird. Die ökonomische Erfolgsträchtigkeit und technische Zukunftssicherheit von Softwarelösungen sind dennoch nur schwer einzuschätzen (vgl. Alves & Finkelstein 2003: 474; Kumar et al. 2003: 795ff.). Für Organisationen spielt es deshalb eine entscheidende Rolle, was andere Unternehmen aus dem Umfeld für zukunftssicher und effizient halten (vgl. Glückler & Armbrüster 2003: 270ff.). Dass die Softwareentscheidung nach dem Vorbild anderer im Umfeld des Unternehmens getätigt wurde, thematisieren sowohl F als auch W in ihren Aussagen. Das Risiko, eine Investitionsentscheidung zu treffen, die sich für das Unternehmen nicht auszahlt, bleibt dennoch bestehen. Inwieweit sich die Investition gelohnt hat, ist letztlich nur schwer zu überprüfen. W nimmt an, dass der Entscheider für eine mögliche Fehlentscheidung nicht oder zumindest weniger verantwortlich gemacht werden könnte („das Risiko des Köpfens“), wenn er sich an Softwareentscheidungen anderer Unternehmen orientierte. In den 1960er Jahren galt der Satz „Nobody ever got fired for buying IBM“ (Stokes 2000: 4). Dieser Satz kann seit den 1990er Jahren auf die Produkte des Softwareherstellers SAP umgemünzt werden. Interviewpartner R schildert die Entscheidungssituation ähnlich: „Also überall stand da SAP, das Tool schlechthin, was will ich denn da verkehrt machen“. Die Auswertung der Interviews mit verschiedenen IT-Entscheidern legen den Schluss nahe, dass nicht die Entscheidung für SAP, sondern die Entscheidung gegen SAP mittlerweile begründungspflichtig geworden ist. Von großer Bedeutung für die starke Verbreitung von SAP-Software in den 1990er Jahren, d.h. für die Softwareentscheidung vieler Unternehmen, sind interorganisatorische Beziehungen. Um diese These theoretisch zu untermauern, sollen in den folgenden Abschnitten grundlegende Konzepte der neoinstitutionalistischen Organisationstheorie erörtert werden.

88 | D AS P ROJEKT SAP

3.1 D IE NEOINSTITUTIONALISTISCHE O RGANISATIONSTHEORIE In den 1970er Jahren rückte eine Reihe von organisationstheoretischen Arbeiten den Kontext bzw. die Umwelt von Organisationen in den Untersuchungsfokus. Die Organisationsforschung erlebte eine Phase grundlegender theoretischer Erneuerung. Der bisherige Schwerpunkt in der Organisationsforschung hatte vor allem auf intraorganisatorischen Beziehungen gelegen. Nicht Einzelorganisationen, sondern Organisationspopulationen rückten nun in den Fokus der Organisationsforschung. Der Satz „The major factors that organizations must take account of in their environments are other organizations“ stammt von Howard Aldrich (1979: 265) und repräsentiert das Paradigma interorganisatorischer Beziehungen in der soziologischen Organisationsforschung.3 Im American Journal for Sociology erscheinen kurz hintereinander zwei richtungsweisende Aufsätze: The Population Ecology of Organizations von Michael Hannan und John Freeman (1977) und Institutionalized Organizations: Formal Structure as Myth and Ceremony von John W. Meyer und Brian Rowan (1977). Sowohl Hannan und Freeman als auch Meyer und Rowan arbeiten zu diesem Zeitpunkt an der Stanford University in Kalifornien. Sie beschäftigen sich allerdings mit zwei konkurrierenden Theorieprojekten. Im populationsökologischen Ansatz von Hannan und Freeman wird untersucht unter welchen Umweltbedingungen sich Organisationspopulationen entwickeln. Es wird davon ausgegangen, dass Organisationsstrukturen träge sind. Organisationen innerhalb einer Population, deren Organisationsstrukturen dem Wettbewerb nicht standhalten, sterben oder sie besetzen eine neue Nische und es entsteht eine neue Organisationspopulation. Im Folgenden konzentriere ich mich auf den neoinstitutionalistischen Ansatz, den zweiten erwähnten Aufsatz. Die Arbeit von Meyer und Rowans gilt als programmatisches Fundament der neoinstitutionalistischen Organisationstheorie. Dieser Ansatz bildet den theoretischen Bezugsrahmen zur Erklärung der Softwareverbreitung. In Institutionalized Organizations stellen Meyer und Rowan die Frage: Warum ähneln sich Organisationen in ihren formalen Strukturen so stark? Für Meyer und Rowan erfüllen formale Organisationsstrukturen nicht primär die Funktion einer möglichst effizienten Problembearbeitung innerhalb einer Organisation. Sie rücken mit ihrem Erklärungsansatz vom technisch-funktionalistischen Para-

3

Dies gilt beispielsweise auch für die Arbeiten von Oliver E. Williamson (1975) zur Transaktionskostentheorie und die Arbeiten von Jeffrey Pfeffer und Gerald Salancik (1978) zur Ressourcenabhängigkeit zwischen Organisationen.

D IE

STANDARDISIERTE

S OFTWARE

| 89

digma in der Organisationsforschung ab. Die Ähnlichkeiten von Organisationen, egal in welchem Umfeld sie agieren oder in welcher Situation sie sich befinden, wird damit erklärt, dass Organisationen in ihren formalen Strukturen moderne Ideen und Prinzipien des Managements aufgreifen. Organisationsmodelle und Managementkonzepte werden eher adaptiert und verbreiten sich, desto stärker sie mit rationalistischen Werten assoziiert werden. „It seems obvious that organizing ideas linked to central rationalistic values travel better than ideas less linked to these highly legitimated goals. Organizations are to produce outcomes rationally, efficiently, and effectively: this is centrally legitimated in terms of the Western, and now world, project of progress. Thus ideas justified in terms of enhanced organizational outcomes travel better than ideas justified in other terms.“ (Meyer 1996: 250)

Nicht die möglichst effiziente Problembearbeitung in Organisationen, sondern die Erzielung von Legitimität durch die Adaption formal-rationaler Strukturen stehen im Vordergrund. Indem Organisationen Erwartungen aus der gesellschaftlichen Umwelt erfüllen und ihre Organisationsstrukturen entsprechend angleichen, verschaffen sie sich Legitimität und erhöhen ihre Überlebenschancen.4 Meyer und Rowan (1977) machen bereits im Untertitel ihres Beitrags deutlich, wie sie das Konzept der formalen Organisationsstrukturen verwenden: Formal structures as myth and ceremony. Sie gehen davon aus, dass Organisationen Formalstrukturen als „prefabricated formula“ und „packaged codes“ (ebd.) aus ihren institutionellen Umwelten übernehmen. „Institutionalized products, services, techniques, policies, and programs function as powerful myth, and many organizations adopt them ceremonially. But conformity to institutionalized rules often conflicts sharply with efficiency criteria; conversely, to coordinate and control activity in order to promote efficiency undermines an organization’s ceremonial conformity and sacrifices its support and legitimacy. To maintain ceremonial conformity, organizations that reflect institutional rules tend to buffer their formal structures from the uncertainties of technical activities by becoming loosely

4

Am Beispiel der Organisation Schule illustrieren Meyer und Rowan die Übereinstimmung von Organisationsstrukturen mit gesellschaftlich institutionalisierten Organisationsmustern. In einer Reihe von Projekten in der Bildungsforschung war ihnen aufgefallen, dass wichtige Akteure im Bildungssystem (Lehrer, Schulleiter, Aufsichtsbeamten) in ihrer Grundüberzeugung zur Rolle der Schule und ihrer eigenen Rolle innerhalb der Schule mit gesamtgesellschaftlichen Ansichten übereinstimmten. Rowan ist bis heute in der Bildungsforschung tätig (vgl. Dierkes & Zorn 2005: 313).

90 | D AS P ROJEKT SAP coupled, building gaps between their formal structures and actual work activities.“ (Ebd.: 341).

Es geht also nicht darum, wie Formalstrukturen effektiv zur Bewältigung von Aufgaben beitragen. Formalstrukturen und deren Übernahme signalisieren vor allem die Übereinstimmung der Organisation mit gesamtgesellschaftlich institutionalisierten Organisationsbildern. Um bestehende Inkonsistenzen zwischen Umwelterwartungen und Erfordernissen der organisationsinternen Problembearbeitung abzumildern, entkoppeln Organisationen ihre formalen Strukturen von ihren Aktivitätsstrukturen. Über diese Strukturen, die hinter der dekorativen Fassade der Formalstrukturen liegen, erfährt man allerdings kaum etwas. Meyer und Rowan weisen lediglich darauf hin, dass Organisationen auf „practical considerations“ (ebd. 357) reagieren und entsprechend handeln. In dem vielzitierten Aufsatz werden zwei verschiedene Thesen vorgestellt: 1) Organisationen erhalten Ressourcen aus ihren relevanten Umwelten nur dann, wenn sie gesellschaftlich geteilte Regeln und Vorstellungen, also Institutionen, inkorporieren (Legitimitätsthese). 2) Um bestehende Widersprüche zwischen formalen Regeln und Effizienzerfordernissen abzumildern, kommt es zur losen Kopplung formaler Strukturen und Handlungen (Entkopplungsthese). Mit meinen Überlegungen zur Verbreitung von SAP knüpfe ich primär an die Legitimitätsthese an. Diese These greifen auch Paul DiMaggio und Walter Powell (1983) in The Iron Cage Revisited: Institutional Isomorphism and Collective Rationality in Organizational Fields auf.5 Um interorganisationale Beziehungen genauer in den Blick zu nehmen, verknüpfen sie den Erklärungsansatz von Meyer und Rowan mit anderen organisationstheoretischen Forschungsansätzen. Darauf soll im folgenden Kapitel eingegangen werden.

3.2 V ERORDNEN , E MPFEHLEN UND N ACHAHMEN : E RKLÄRUNGEN DER S OFTWAREVERBREITUNG DiMaggio und Powell stimmen mit Meyer und Rowan grundsätzlich darin überein, dass der Strukturwandel in Organisationen immer weniger auf Wettbewerbsprozesse und Effizienzsteigerungen zurückgeführt werden kann, sondern auf die Sorge von Organisationen um soziale Legitimität und politische Unter-

5

Neben der Arbeit von Meyer und Rowan (1977) gilt dieser Aufsatz als zentraler Bezugspunkt für die neoinstitutionalistische Organisationsforschung (vgl. Hasse & Krücken 2005: 22; Walgenbach & Meyer 2008: 22ff.; Greenwood et al. 2008: 3ff.).

D IE

STANDARDISIERTE

S OFTWARE

| 91

stützung. Sie unterscheiden drei grundlegende Mechanismen zur Erklärung der Isomorphie von Organisationen: „We identify three mechanisms through which institutional isomorphic change occurs, each with its own antecedents: 1) coercive isomorphism that stems from political influence and the problem of legitimacy; 2) mimetic isomorphism resulting from standard responses to uncertainty; and 3) normative isomorphism, associated with professionalization. This typology is an analytic one: the types are not always empirically distinct.“ (DiMaggio & Powell 1983: 150)

Inwieweit die von Powell und DiMaggio explizierten sozialen Mechanismen Zwang („coercive isomorphism“), Nachahmung („mimetic isomorphism“) und normativer Druck („normative isomorphism“) zur Erklärung der Softwareverbreitung beitragen können und welche Belege sich dafür im Datenmaterial finden, soll im Folgenden vorgestellt werden. Unter der Überschrift „Die verordnete Software“ werden Abhängigkeitsbeziehungen einer Organisation mit anderen Organisationen beschrieben, die zur Einführung der Standardsoftware geführt haben können. Unter der Überschrift „Die empfohlene Software“ thematisiere ich Netzwerkbeziehungen zwischen Organisationen und unter der Überschrift „Die nachgeahmte Software“ rekonstruiere ich Beobachtungsbeziehungen zwischen Organisationen, die zur Erklärung der Softwareverbreitung aus einer neoinstitutionalistischen Perspektive beitragen. 3.2.1 Die verordnete Software: Gesetze und Konzernvorgaben DiMaggio und Powell räumen in ihren Überlegungen zur Strukturangleichung von Organisationen dem Staat und den Möglichkeiten staatlichen Zwangs einen hohen Stellenwert ein. Rechtliche Vorgaben, wie das Vertragsrecht, das Steuerrecht, das Gesellschaftsrecht oder das Aktienrecht, prägen Organisationsstrukturen und schränken den Spielraum verschiedener Organisationsformen ein.6 Der

6

Den staatlichen Einfluss auf Organisationsentscheidungen und Strukturangleichungsprozesse zwischen Organisationen untersuchen Frank Dobbin und John Sutton (1998) am Beispiel des Human-Resources-Management in US-amerikanischen Unternehmen. Obwohl staatliche Vorgaben nicht die Art und Weise definieren, wie Organisationen diese Vorgaben umsetzen sollen, bilden sich trotzdem einheitliche Organisationsstrukturen. Am Fall gesetzlicher Auflagen zur Gleichbehandlung von Arbeitnehmern untersucht Lauren Edelman (1992) Strukturangleichungsprozesse zwischen Organisatio-

92 | D AS P ROJEKT SAP

staatliche Einfluss auf die Verbreitung von SAP wird in Selbstbeschreibungen des Softwareherstellers ebenfalls thematisiert. Ein neues Bilanzrichtliniengesetz habe dafür gesorgt, dass sich viele Unternehmen Mitte der 1980er Jahre für die Einführung von SAP-Software entschieden hätten. Für das Jahr 1986 ist in der Unternehmensgeschichte der folgende Eintrag zu lesen: „Ein neues Bilanzrichtliniengesetz ist die Ursache für einen stürmischen Auftragseingang. Rund 100 Neuaufträge gehen für die SAP-Anlagenbuchhaltung ein.“7 Hauptziel dieser Richtlinien war es, die Vorschriften über den Inhalt und die Gliederung des Jahresabschlusses und die Publizitätspflicht von Kapitalgesellschaften im Einzelnen aufeinander abzustimmen. Zur Beantwortung der Frage, warum sich gerade SAP und kein anderes vergleichbares Softwareprodukt so erfolgreich am Markt etablieren konnte, liefert ein solches Argument jedoch keine ausreichende Erklärung. Vielversprechender ist die folgende These (vgl. DiMaggio und Powell 1983: 154): „Je größer die Abhängigkeit einer Organisation von einer anderen Organisation, desto stärker wird sie sich hinsichtlich ihrer Strukturen, ihrer Kultur und ihres Verhaltens jener Organisation angleichen, von der sie abhängig ist.“8

Zwei Typen von Abhängigkeitsbeziehungen zwischen Organisationen können unterschieden werden. Die erste interorganisatorische Beziehung betrifft die Abhängigkeit zwischen einem Großkonzern und seinen Lieferanten. Mitte der 1990er Jahre hatten viele Großkonzerne die Software R/3 bereits eingeführt.9 Je mehr Konzerne die Standardsoftware einsetzten, desto stärker wurde auch der Druck auf Zulieferunternehmen, sich ebenfalls für dasselbe Softwareprodukt zu entscheiden (vgl. Rolf 1998: 120). Die Abwicklung von Geschäftsprozessen zwischen den Unternehmen sollte mithilfe derselben Software vereinheitlicht und vereinfacht werden. Eine Softwareeinführung kann zwar nicht formell verordnet werden, allerdings kann die Verwendung informell zum entscheidenden Kriterium für die Auswahl von Lieferanten und Kooperationspartnern werden.

nen. Erin Kelly und Frank Dobbin (1999) tun dies am Beispiel von Richtlinien zum Mutterschaftsurlaub. 7

Quelle: http://www.sap.com/corporate-de/our-company/history/1982-1991.epx; Zugriff am 01.10.2013.

8

Die deutsche Übersetzung dieser Hypothese von DiMaggio und Powell ist dem Lehrbuch von Peter Walgenbach und Renate Meyer (2008: 36) entnommen.

9

Vergleiche hierzu KAPITEL 2.3 „Die dritte Entstehungsphase: SAP als de factoStandard“.

D IE

STANDARDISIERTE

S OFTWARE

| 93

Eine Abhängigkeit anderer Art betrifft die Abhängigkeit zwischen der Unternehmenszentrale und ihren Tochterunternehmen. Die Softwareeinführung von R/3 in einer Reihe US-amerikanischer Mutterkonzerne Anfang der 1990er Jahre ist auf die Ressourcenabhängigkeit zwischen Organisationen zurückzuführen. Zu den ersten SAP-Kunden in den USA zählten ICI America, DuPont, Dow Chemical und andere Firmen in der Öl-, Chemie- und Pharmaindustrie. Deren europäische Tochterunternehmen hatten die Softwareversion R/2 bereits im Einsatz. Bei der Einführung von SAP konnten diese Konzerne auf Erfahrungswissen bei der Implementierung und Verwendung der Technik zurückgreifen.10 3.2.2 Die empfohlene Software: Sozialisations- und Netzwerkeffekte Strukturähnlichkeiten zwischen Organisationen begründen DiMaggio und Powell mit der zunehmenden Professionalisierung in der modernen Gesellschaft (vgl. 1983: 155). Sie stellen dazu zwei Hypothesen auf: „Je stärker sich eine Organisation bei der Auswahl ihrer Mitglieder auf akademische Zeugnisse verlässt, desto größer ist das Ausmaß, in dem sie sich anderen Organisationen in ihrem Feld angleicht.“ „Je mehr sich die Manager einer Organisation in Berufs- und Wirtschaftsverbänden engagieren, desto größer ist das Ausmaß, in dem sich diese Organisationen anderen Organisationen in ihrem Feld angleichen.“11

Die Hypothesen stehen für unterschiedliche Erklärungsstrategien innerhalb der neoinstitutionalistischen Organisationsforschung. Einerseits geht es um die professionelle Sozialisation von Organisationsmitgliedern (Sozialisationseffekte). Andererseits geht es um die Vernetzung des Personals mit dem Personal anderer Organisationen (Netzwerkeffekte). Beide Thesen sollen nun auf das Beispiel der Softwareverbreitung angewendet werden. 1) Berufsschulen und Universitäten gelten als Entstehungsorte für professionelle Normen. Hier werden Organisationsmodelle und Modelle des Organisierens vermittelt und das zukünftige Personal von Unternehmen entsprechend so-

10 Der Technikhistoriker Campbell-Kelly beschreibt diesen Prozess als Dominoeffekt (vgl. 2003: 196). 11 Die deutsche Übersetzung der Hypothesen von DiMaggio und Powell wurde von Walgenbach und Meyer (2008: 39-40) übernommen.

94 | D AS P ROJEKT SAP

zialisiert. Diesen sozialen Mechanismus macht sich auch der Softwarehersteller zunutze. Er stellt seine Softwareprodukte beispielsweise im Rahmen des SAP Global University Alliances Program Universitäten, Fachhochschulen, Berufsakademien und anderen Schulen für die Lehre und Ausbildung von Studierenden und Schülern zur Verfügung. Weltweit sollen es nach Angaben des Unternehmens 200.000 Studierende und 1.000 Hochschulen und Schulen sein, die sich an diesem Ausbildungsprogramm beteiligen. Louis Marienthal (1975: 117) konnte ähnliche Sozialisationseffekte in einer Untersuchung zur Verbreitung von IBMProdukten in den 1970er Jahren feststellen. „We have a vicious circle in our industry. An important reason for IBM’s dominant position in the computer industry is the influence of IBM on computer personnel which in turn helps to sustain IBM’s dominant position in the industry. The clearest example of this interaction is where it all begins: most computer people receive their first training with IBM equipment and techniques. Obviously IBM schools train for IBM, in order to attract students, private schools feature IBM; and in order to describe the real world, most public school texts feature examples of IBM. Clearly, most feel that IBM training leads to jobs.“

SAP unterscheidet sich in diesem Punkt nicht von anderen Software- und Hardwareproduzenten, die ähnliche Programme ins Leben rufen. 2) Berufsverbände, Wirtschaftsverbände und andere berufliche Netzwerke spielen für die Definition und Verbreitung von Organisationsmodellen ebenfalls eine zentrale Rolle (vgl. DiMaggio & Powell 1983: 156).12 Über personale Netzwerke verbreiten sich Ideen nämlich besonders schnell.13 Netzwerkbeziehungen zwischen Mitgliedern eines Wirtschaftsverbandes, die oft in vergleichbaren Positionen in verschiedenen Organisationen tätig sind, werden deshalb auch als Diffusionskanäle bezeichnet (vgl. Strang & Sine 2001). Weitere Diffusionskanäle sind Aufsichtsratsposten, die Mitgliedschaft in business roundtables und

12 Es gibt viele relevante Untersuchungen zur Stärke von schwachen Verbindungen („the strength of weak ties“, Granovetter 1973), strukturellen Löchern („structural holes“, Burt 1992) oder dem Phänomen der „small world“ (Watts 1999). 13 Für David Strang ist die Übertragbarkeit von Erkenntnissen der Netzwerkforschung auf die Organisationsforschung allerdings problematisch. Schließlich gebe es kein Äquivalent für „Face-to-face“-Begegnungen von Individuen innerhalb von Organisationen: „Only a tiny fraction of the members of two organizations can directly interact with each other at any given time. While individuals meet, in some fundamental sense, as wholes, organizations generally connects as parts. Much research thus seeks to locate interorganizational ties that matter“ (Strang 2010: 7).

D IE

STANDARDISIERTE

S OFTWARE

| 95

Alumni Clubs, Peer-Groups und städtische, regionale sowie nationale Verbände.14 Warren Boeker (1997) beschreibt beispielsweise die Auswirkungen von Personaltransfers im Management auf den Wandel von Unternehmensstrategien; Gerald Davis (1991) analysiert die Verbreitung von Strategien gegen (feindliche) Firmenübernahmen (poison pills) und Netzwerke von Aufsichtsratsmitgliedern. Zwischen den SAP-Gründern und Vertretern der ersten Kundenunternehmen lassen sich ebenfalls personale Netzwerkbeziehungen rekonstruieren. So hatte beispielsweise Klaus Tschira, einer der fünf Gründungsmitglieder von SAP, die Unternehmen John Deere und Freudenberg bereits als IBM-Systemingenieur betreut und betreute sie auch als SAP-Unternehmer weiter.15 In ihrer Studie zur weltweiten Verbreitung von ERP-Software unterstreichen Neill Pollock und Robin Williams (2009: 210ff.) die Bedeutung von sogenannten Vermittlern. Sie untersuchen das Marktforschungsunternehmen Gartner Group als exemplarischen Fall, um die Rolle von Analysten und Beratern bei der Formierung der Technik und des Marktes für ERP-Software zu verdeutlichen. Für die Softwareverbreitung spielen doch vor allem die Partnerschaft des Softwareherstellers mit Beratungsunternehmen eine wichtige Rolle (vgl. Westrup & Knight 2000: 641). HP: „Wir wollten immer eine Softwareentwicklungsfirma bleiben. Wir wollten nicht zu beratungsorientiert werden und uns zu einer Beratungsfirma entwickeln, die sich keine Softwareentwicklung mehr leisten kann. [...] Also war es natürlich, Partnerschaften mit den Big Six einzugehen. [...] SAP hat integrierte Anwendungen auf den Markt gebracht, und die Big Six haben uns dabei geholfen, dieses Konzept zu verbreiten [...] und Überzeugungsarbeit bei den großen Unternehmen zu leisten.“ (Plattner et al. 2000: 38)

Ende der 1980er Jahre hatten Wirtschafts- und Steuerprüfungsunternehmen die IT-Beratung zu einem ihrer wichtigsten Geschäftsbereiche ausgebaut. Zu den „Big Six“ (ebd.) der Branche zählten in den 1990er Jahren die USamerikanischen und britischen Beratungsunternehmen Arthur Andersen, Coo-

14 David Strang wertete gemeinsam mit seiner Kollegin Mary C. Still (Still & Strang 2009) Artikel zur Verbreitung von Managementkonzepten aus, die im Zeitraum von 1990 bis 2005 in den Zeitschriften Administrative Science Quarterly, American Journal of Sociology, American Sociological Review und Organization Science erschienen sind. 15 Auf bestehende persönliche Netzwerke der Gründer von SAP weist der Journalist Gerd Meissner (1997) in seinem Buch zur Unternehmensgeschichte von SAP mehrfach hin.

96 | D AS P ROJEKT SAP

pers & Lybrand, Deloitte & Touche, Ernst & Young, KPMG Peat Marwick und Price Waterhouse (vgl. Caldwell 1996). 3.2.3 Die nachgeahmte Software: Die Inszenierung von Erfolg In The Iron Cage Revisited stellen DiMaggio und Powell mit der Nachahmung einen dritten sozialen Mechanismus vor, um die Strukturangleichung von Organisationen zu erklären. Sie (1983: 155) formulieren die folgende These: „Je unsicherer und uneindeutiger der Zusammenhang zwischen den eingesetzten Mitteln und Zielen einer Organisation ist, desto größer ist das Ausmaß, in dem die betreffende Organisation jene Organisationen als Modelle heranzieht, die sie als erfolgreich wahrnimmt.“16

Organisationen haben nur selten eine direkte Verbindung zu denjenigen Organisationen, die sie nachahmen. Interorganisatorische Beziehungen, die für die Softwareverbreitung eine zentrale Rolle gespielt haben, sollen im Folgenden als Beobachtungsbeziehungen beschrieben werden. Für die Herstellung dieses Typs von Beziehungen eignen sich sogenannte Erfolgsgeschichten (success stories). Diese Geschichten zirkulieren als Rezeptwissen oder best practices in Büchern und Fachzeitschriften. Unternehmensvertreter stellen sie sich mitunter gegenseitig auf Konferenzen vor. Ein Beispiel dafür ist das jährlich stattfindende Treffen der Deutschen SAP-Anwendergemeinschaft (DSAG). Der Vorläufer der DSAG wurde in den 1980er Jahren zunächst als „Selbsthilfeverein“ gegründet: „[...] in dem Sinn, dass man sich untereinander austauscht, wie geht ihr mit bestimmten Themenstellungen um. Oder, um mit der SAP in Kontakt zu treten. Was habt ihr denn jetzt vor?“ (Interviewpartner B). Heute unterteilt die DSAG als Dachverband für verschiedene SAP-Anwendergemeinschaften im deutschsprachigen Raum ihre Aktivitäten in drei Bereiche: 1) Vermittlung zwischen dem Softwarehersteller und Anwenderunternehmen, 2) Vernetzung und Wissenstransfer zwischen Anwenderunternehmen und 3) Ausbildung und Weiterbildung im fachlichen Kontext der SAP-Software. Beispiele für Vortragstitel auf einer DSAG-Konferenz sind: „Erfahrungsbericht: Einführung Change Request Management in einem Konzern“, „Sichere Prozesse bei der Leiterplattenentwicklung dank SAP Integration der Mentor Graphics Tools“ oder „Best in Class Liquidity Management – Effektive Liquidi-

16 Die deutsche Übersetzung dieser Hypothese von DiMaggio und Powell stammt von Walgenbach und Meyer (2008: 37).

D IE

STANDARDISIERTE

S OFTWARE

| 97

tätssteigerung mit SAP BI“. Aus einer neoinstitutionalistischen Perspektive betrachtet, haben diese Geschichten folgende Funktion: „Organizations seldom have direct experiences of the organizations or practices they imitate and refer to. What they imitate are rationalizations – stories constructed by actors in the ‚exemplary’ organization, and their own translations of such stories. What spreads are not experiences per se, but standardized models and presentations of such practices.“ (Sahlin-Andersson 1996: 78)

Es geht darum, Erfolge für das Unternehmen und für den Softwarehersteller zu präsentieren. Dass die erfolgreiche Implementierung und Verwendung der Software durch das anwendende Unternehmen selbst präsentiert wird, ist ein wichtiger Bestandteil des Referenzmarketing des Softwareherstellers. Success stories stellen ein eigenes kommunikatives Genre dar. Die Geschichten werden oft von Beratungsunternehmen oder dem Softwarehersteller selbst in Auftrag gegeben. Gespickt sind sie mit Zitaten von im Implementierungsprojekt beteiligten Managern und Mitarbeitern. Warum sich Organisationen an dieser Form der Berichterstattung beteiligen, die scheinbar ausschließlich den Marketinginteressen des Softwareherstellers dienen oder Beratungsunternehmen von Nutzen sind, kann mit John W. Meyer beantwortet werden. „In most societies at most times, competing organizations keep their success to themselves: they see few advantages in helping aliens and competitors. Secrecy seems more rational than publicity. Why does this change in the modern organizational world, so that organizations glory in depicting themselves as successful instances of organization in general [...]? [...] Because modern organizations legitimate themselves as specific instances of models (i. e. sets of ideas) that are universally true, progressive, and rational, they not only use exogenous ideas, but turn their own structures and practices into such ideas.“ (Meyer 1996: 245)

Für Meyer ist jegliche Form der Zurschaustellung von Erfolgen ein Phänomen der modernen Organisationswelt. Er unterscheidet die organisationsinterne und organisationsexterne Legitimität (vgl. ebd.). Die Pressemeldung eines Unternehmens zur erfolgreichen Softwareeinführung kann sowohl Bestandteil der internen Kommunikation als auch der Öffentlichkeitsarbeit eines Unternehmens sein. Im ersten Fall sollen Organisationsmitglieder davon überzeugt werden, dass die Softwareimplementierung ein Beispiel für eine gute und zeitgemäße Unternehmensführung ist. Die Öffentlichkeitsarbeit soll die stakeholder eines Unter-

98 | D AS P ROJEKT SAP

nehmens ebenfalls davon überzeugen.17 Dass Organisationen sich selbst und ihre Entscheidungen der Öffentlichkeit präsentieren, erklärt Meyer mit dem allgemeinen Streben nach Legitimität in der Gesellschaft. DiMaggio und Powell begründen ihre Nachahmungsthese darüber hinaus mit den Erkenntnissen der Organisationsforschung. Sie greifen auf grundlegende Konzepte von James March und Johan Olsen (1976) und Richard Cyert und March (1963) zurück, die im Anschluss an die Arbeiten von Herbert Simon (1947) das Forschungsprogramm der verhaltenswissenschaftlichen Entscheidungstheorie ausgebaut haben. „The modeled organization may be unaware of the modeling or may not desire to be copied; it merely serves as a convenient source of practices that the borrowing organization may use. […] When organizational technologies are poorly understood (March and Olsen, 1976), when goals are ambiguous, or when the environment creates symbolic uncertainty, organizations may model themselves on other organizations. The advantages of mimetic behavior in the economy of human action are considerable; when an organization faces a problem with ambiguous causes or unclear solutions, problemistic search may yield a viable solution at little expense (Cyert and March, 1963).“ (DiMaggio & Powell 1983: 151) [Hervorh., H. M.]

Unter den Bedingungen von Unsicherheit und Uneindeutigkeit versuchen Entscheider mit möglichst geringem Aufwand, nach geeigneten Lösungen zu suchen. Mögliche Strategien der Unsicherheitsbewältigung sind routinierte Entscheidungen und Entscheidungsverfahren, die relativ einfachen Kausalmodellen folgen (vgl. Kette & Mormann 2015). Die Nachahmung von anderen als erfolgreich wahrgenommenen Organisationen gilt in der modernen Organisationsforschung als eine rationale Entscheidungsstrategie. „Solving a problem efficiently usually involve doing things you have previously done successfully, or copying someone else’s successful solution. Whether we want to know how to produce shoes, how to fight wars, how to invest money, how to build bridges, or how to make love, the best way to improve our own capabilities normally is to imitate the technologies of others who have had successful experience doing the same thing.“ (March 1999: 333)

Je unsicherer es Entscheidern einer Organisation erscheint, dass die eingesetzten Mittel, etwa die Einführung einer bestimmten Software, zur Erreichung eines

17 Damit sind beispielweise Aktionäre, (potenzielle) Kunden und Geschäftspartner gemeint.

D IE

STANDARDISIERTE

S OFTWARE

| 99

vorgegebenen Ziels führen, desto wahrscheinlicher ist es, dass sie die Entscheidung nach dem Vorbild anderer im Umfeld der Organisation treffen. Die Aussagen der Interviewpartner, die zu Beginn des Kapitels ausführlich zitiert wurden, stützen die zentrale These der verhaltenswissenschaftlichen Entscheidungstheorie, nach der die Softwareverbreitung als Nachahmungsphänomen zu interpretieren ist. INTERVIEWPARTNERIN W: „Die Entscheidung war risikoavers, weil es alle gemacht haben. Selbst wenn es Mist gewesen wäre mit der Entscheidung, wäre man zumindest in guter Gesellschaft gewesen [...].“ INTERVIEWPARTNER F: „Und wenn du halt siehst, deine fünf Konkurrenten, die Größten, die haben das alle und bei denen funktioniert es gut, dann ergibt es sich, [...] dann nimmst du es auch [...].“

Der These zur Nachahmung wurde in der Rezeption von DiMaggio und Powells Aufsatz überproportional viel Aufmerksamkeit geschenkt (vgl. Greenwood et al. 2008: 2ff.). Mark S. Mizruchi und Lisa C. Fein (1999) rekonstruieren in The Social Construction of Organizational Knowledge. A Study of the Uses of Coercive, Mimetic, and Normative Isomorphism die Rezeptionsgeschichte. In der nordamerikanischen Organisationsforschung, so zeigen sie in ihrer Meta-Analyse, liegt der Schwerpunkt auf der Erforschung kognitiver Aspekte. Regulative und normative Aspekte hingegen bleiben unterbelichtet, obwohl diese Aspekte empirisch kaum auseinandergehalten werden können. Nachahmung, so wird im Folgenden argumentiert, ist jedoch nicht bloß ein sozialer Mechanismus unter anderen, sondern eine zentrale Kategorie bei der Erforschung der modernen Organisationswelt. „DiMaggio und Powell behaupten [...], daß mimetische Isomorphie ein Zeichen von Unsicherheit sei: Menschen ahmen einander nur nach, wenn sie nicht wissen, wie sie sich verhalten sollen. Betrachtet man die Tatsache, daß Unsicherheit eine Grundvoraussetzung menschlicher Existenz ist, so unterschätzt diese Erklärung doch die Allgegenwart der Mimesis. Hier sind die Einsichten von Gabriel Tarde von großer Wichtigkeit. Nachahmung ist keine Residualkategorie, sondern eine zentrale Kategorie für diejenigen, die am Verständnis der gegenwärtigen Organisationswelt interessiert sind [...].“ (Czarniawska 2009: 376f.)

Folgt man der hier vorgeschlagenen Argumentationslinie, dann findet Nachahmung nicht nur in der Gesellschaft statt. Gesellschaft ist Nachahmung (vgl. Tar-

100 | D AS P ROJEKT SAP

de 2003: 98).18 Mit den drei Mechanismen der Strukturangleichung von Organisationen wurde ein zentrales Theorem der neoinstitutionalistischen Organisationsforschung auf das Beispiel der Verbreitung von SAP angewendet. Ins Zentrum gerückt wurden Beziehungen zwischen Organisationen: Abhängigkeitsbeziehungen, Netzwerkbeziehungen und Beobachtungsbeziehungen. Um die Bedeutung interorganisationaler Beziehungen für die Verbreitung von SAP noch deutlicher zu machen, greife ich im nächsten Kapitel auf ein weiteres neoinstitutionalistisches Konzept zurück, das ebenfalls von DiMaggio und Powell eingeführt wird: Das Organisationsfeld.

3.3 D AS O RGANISATIONSFELD SAP – W IE EIN S OFTWAREHERSTELLER B EZIEHUNGEN ZWISCHEN O RGANISATIONEN KONSTRUIERT Die These zur Strukturangleichung von Organisationen wurde zu einer Masterhypothese in der neoinstitutionalistischen Organisationsforschung. Dass DiMaggio und Powell darüber hinaus organisationstheoretisch interessante Thesen entwickelt haben, wird oft ausgeblendet oder bleibt zumindest vernachlässigt. Die einseitige Rezeption beklagt einer der Autoren selbst so: „Somewhat to my surprise, [...] papers [...] cited our paper as support for the proposition that all organizations become like all others, regardless of field. Somehow the network argument that we authors regarded as so central had been deleted in the paper’s reception. Within a few more years, the paper had turned into a kind of ritual citation, affirming the view that, well, organizations are kind of wacky, and (despite the presence of collective rationality in the paper’s subtitle) people are never rational.“ (DiMaggio 1995: 395)

Um Strukturähnlichkeiten nicht nur zwischen einzelnen Organisationen, sondern auch innerhalb eines Organisationsfeldes zu erklären, stellen DiMaggio und Powell insgesamt zwölf Hypothesen auf. Sie greifen dafür auf Forschungsergebnisse zur Ressourcenabhängigkeit von Organisationen (z.B. Pfeffer & Salancik 1978) zurück und reformulieren grundlegende Annahmen der verhaltenswissen-

18 Tarde verwendet Nachahmung in einem umfassenden Sinne. In seinem Hauptwerk Die Gesetze der Nachahmung (2003[1890]: 38) unterscheidet er verschiedene Formen der Nachahmung: die naive oder überlegte Nachahmung, die Nachahmung durch Belehrung, Erziehung oder Gehorsam. Vergleiche Christian Borch und Urs Stäheli (2009) zur neueren Rezeption von Tarde in der Soziologie.

D IE

STANDARDISIERTE

S OFTWARE

| 101

schaftlichen Entscheidungstheorie (z.B. March & Olsen 1976; Cyert & March 1963). Zudem beziehen sie sich auf zentrale Ergebnisse aus der Netzwerkforschung (z.B. Laumann et al. 1978). Um die externen Einflüsse bezeichnen zu können, die struktur- und formgebend auf eine Organisation wirken, führen DiMaggio und Powell das Konzept der organizational fields ein. Dieses Konzept ist der Ausgangspunkt für ein empirisches Forschungsprogramm, das die Beziehungen einer Organisation zu anderen Organisationen in den Mittelpunkt der Organisationsanalyse rückt. Das Organisationsfeldkonzept wird im Folgenden verwendet, um zu illustrieren, wie der Softwarehersteller das Organisationsmodell seiner Software dazu verwendet, Beobachtungs- und Vergleichsbeziehungen zwischen Organisationen zu forcieren. Dafür stelle ich Feldkonzept zunächst genauer vor und erläutere danach beispielhaft Aktivitäten des Softwareherstellers, die dabei unterstützen, das Organisationsfeld SAP zu konstituieren. 3.3.1 Das Organisationsfeldkonzept Ein Organisationsfeld steht DiMaggio und Powell zufolge für all diejenigen Organisationen, die mit der im Zentrum einer Untersuchung stehenden Organisation konkurrieren, kooperieren oder mit ihr auf andere Art und Weise interagieren. „By organizational field, we mean those organizations that, in the aggregate, constitute a recognized area of institutional life: key suppliers, resource and product consumers, regulatory agencies, and other organizations that produce similar services or products.“ (DiMaggio & Powell 1983: 148)

In der neoinstitutionalistischen Organisationsforschung hat das Feldkonzept eine zentrale und zugleich ambivalente Bedeutung. Einerseits werden so institutionelle Umwelterwartungen konkretisiert, die struktur- und formgebend auf eine Organisation wirken. Andererseits werden Organisationsfelder und ihre Entstehung selbst zu zentralen Untersuchungseinheiten gemacht.19 Gradmesser für die Entstehung eines Organisationsfeldes sind der Umfang der Interaktion zwischen Organisationen, daraus entstehende Herrschafts- und Koalitionsmuster, das Informationsaufkommen und schließlich das Bewusstsein bei den beteiligten Organisationen für eine gemeinsame Unternehmung (ebd.: 148). Das Feldkonzept kann

19 Am Beispiel von Kunstmuseen in den USA untersucht DiMaggio (1991) die Herausbildung eines Organisationsfeldes und rekonstruiert das Beziehungsmuster von Stiftungen, professionellen Vereinigungen, staatlichen Projektträgern und Universitäten.

102 | D AS P ROJEKT SAP

als Erweiterung des neoinstitutionalistischen Forschungsansatzes der Meyerschen Schule betrachtet werden. „The institutionalization approach associated with John Meyer and his students posits the importance of myths and ceremony but does not ask how these models arise and whose interests they initially serve. Explicit attention to the definition and elaboration of organizational fields should answer this question.“ (Ebd.: 157)

Blickt man auf die Rezeptionsgeschichte von The Iron Cage Revisited, fällt allerdings auf, dass das dort vorgeschlagene Feldkonzept oft zurechtgestutzt wird. Organisationsfelder fungieren in vielen Arbeiten eher als Platzhalter für Organisationen derselben Branche oder für Organisationen mit vergleichbaren Strategien, mit ähnlicher Größe oder ähnlichem Status. Zum Beispiel wird dieselbe Finanzierungsform dazu benutzt, Organisationsfelder als Untersuchungseinheiten zu präsumieren. Überblicksartig stellt Richard W. Scott (1987) empirische Arbeiten vor, die auf DiMaggio und Powells Feldkonzept rekurrieren, um Organisationsumwelten eindeutig zu identifizieren. Feldgrenzen werden scheinbar exakt bestimmt, weil Kontakte und Austauschbeziehungen zwischen Organisationen quantifiziert werden können. Offensichtlich handelt es sich um ein variables Konstrukt von Organisationsforschern und Organisationsforscherinnen. Die Verwendung kritisiert DiMaggio (1991: 267) in einer späteren Veröffentlichung. „Where institutional processes have the greatest impact on organizational change, such fields are not simply investigator’s aggregative constructs, but are meaningful to participants and include specialized organizations that constrain, regulate, organize, and represent at the level of the field itself.“

Eine eher pragmatische Verwendung des Feldbegriffs in der aktuellen empirischen Organisationsforschung beobachten auch Eva Boxenbaum und Stefan Jonsson (2008). Die Begriffe organizational fields und societal sectors werden, so ihre Beobachtung, praktisch synonym verwendet. Dabei stehen der Feld- und der Sektorbegriff für zwei grundverschiedene Strategien, um die Entstehung und Verbreitung von Organisationsmodellen zu erklären. 1) W. Richard Scott und John W. Meyers (1991) Bestimmung der Organisationsumwelt als gesellschaftlicher Sektor basiert auf existierenden Klassifikationssystemen, wie beispielsweise der US-amerikanischen Standard Industrial Classification (SIC) zur Bestimmung von Industriezweigen.20 Meyer

D IE

STANDARDISIERTE

S OFTWARE

| 103

Classification (SIC) zur Bestimmung von Industriezweigen.20 Meyer und Scott halten fest, dass „[t]he SIC classification principle helps deal with problems of boundary definition for societal sectors“. Sie fügen ihrer Definition ergänzend hinzu, dass „the concept of societal sector is broader than that of industry for we wish to include also those organizations comprising the set of the focal industry group – those organizations that support and/or constrain their activities“ (ebd.: 119). Die Zugehörigkeit zu einem Sektor ist im Erklärungsmodell von Scott und Meyer eine exogene Variable, d.h. die Adaption von Ideen, Managementpraktiken und Organisationsmodellen wird von der Sektorzugehörigkeit beeinflusst. 2) In der von DiMaggio und Powell inspirierten Felder-Forschung (z. B. Hoffman 1999; Hoffman & Ocasio 2001) richtet sich hingegen das Augenmerk auf Organisationen, die sich selbst mit anderen Organisationen in Beziehung setzen. Die gemeinsame Stoßrichtung von Arbeiten, die das ursprüngliche Feldkonzept weiterentwickelt haben, fassen Melissa Wooten und Andrew Hoffman (vgl. 2008: 136) zusammen. Betont wird die aktive Rolle von Organisationen bei der (Re-)Formation von Organisationsfeldern. Organisationale Prozesse der Interpretation rücken in den Fokus der Aufmerksamkeit. Wooten und Hoffman stellen an anderer Stelle fest, dass „[...] fields must be seen, not as containers for the community of organizations, but instead as »relational spaces« that provide an organization with the opportunity to involve itself with other actors“ (ebd.: 138). Beide Begriffe, gesellschaftlicher Sektor und Organisationsfeld, und die aus ihnen resultierenden Erklärungsstrategien für Strukturangleichungsprozesse sind nicht aufeinander reduzierbar und sollten deshalb auch terminologisch unterschieden werden. Geht man nämlich von Meyer und Scotts Sektorbegriff aus, sind Organisationen primär Adressaten eines übergeordneten und übergreifenden kulturellen Bezugssystems. Strukturangleichungen zwischen Organisationen, beispielsweise die Verbreitung von SAP in Organisationen, wird auf diese Weise top-down erklärt. Legt man hingegen den Begriff des Organisationsfeldes von DiMaggio und Powell zugrunde, wird die aktive Rolle von Organisationen stärker betont. Ein Organisationsfeld wird über Beobachtungs- und Vergleichsbeziehungen von Organisationen konstituiert. Strukturangleichungen wie die Verbreitung von SAP werden aus dieser Perspektive bottom-up erklärt. Es sind Organisationen, die sich selbst mit anderen Organisationen in Beziehung setzen. Ob das über das Organisationsmodell von SAP konstituierte Feld für die im Untersuchungsfokus stehende Organisation selbst relevant ist, wird für den Beob-

20 SIC ist ein seit den 1930er Jahren existierendes Klassifikationssystem. Mittlerweile ist es allerdings durch das North American Industry Classification System (NAICS) abgelöst worden.

104 | D AS P ROJEKT SAP

achter erst dann sichtbar, wenn diese Organisation ihre Entscheidungen mit Bezug auf die anderen Organisationen trifft. Ein möglicher Schauplatz von Entscheidungen ist das Softwareprojekt (vgl. TEIL B). Am Beispiel des Referenzmarketings des Softwareherstellers soll im Folgenden illustriert werden, wie die Konstitution eines Organisationsfeldes vom Softwarehersteller aktiviert wird. 3.3.2 Referenzmarketing und Organisationsvergleiche Auf der Website und in Broschüren des Softwareherstellers werden viele namhafte Organisationen aufgelistet, die im Laufe der Unternehmensgeschichte als Kunden gewonnen werden konnten.21 Für die Vermarktung der Software und ihre Verbreitung spielen Referenzen eine zentrale Rolle. Auf die Bedeutung des Marketings für den Erfolg von Standards weisen auch Geoffrey Bowker und Susan Leigh Star (2000: 14) hin. „There is no natural law that the best standard shall win [...]. The standards that do win may do so for a variety of other reasons: they build on an installed base, they had better marketing at the outset, or they were used by a community of gatekeepers who favored their use.“

In der IT-Branche ist ein Referenzmarketing üblich.22 Eine Grundannahme dabei ist, dass sich potenzielle Kunden während der Kaufentscheidungsphase eher an den Erfahrungen anderer Kunden orientieren, als auf das Produktversprechen des Anbieters verlassen. Die Idee für ein Referenzmarketing entspricht dem sozialpsychologischen Konzept der reference group (vgl. Hyman 1942). In der Soziologie wurde dieses Konzept von Robert K. Merton (1968) aufgegriffen, um das soziale Umfeld zu bezeichnen, mit dem sich eine Person identifiziert. An den Normen und Wertvorstellungen dieses Umfeldes misst eine Person ihr eigenes Verhalten und macht sich dessen Ziele und Einstellungen zu eigen. Voraussetzung für die Wahl einer Bezugsgruppe ist ein Minimum an wahrgenommener oder auch nur eingebildeter Gemeinsamkeit. Antizipative Sozialisation bedeutet in diesem Zusammenhang, dass Normen und Werte einer Bezugsgruppe übernommen werden, weil Personen den Wunsch oder die mehr oder weniger be-

21 Siehe die Erläuterungen zur Entstehung des Organisationsmodells in KAPITEL 3.1. 22 Vergleiche hierzu die Definition von Referenzmarketing des Bundesverbandes Informationswirtschaft, Telekommunikation und neue Medien e. V. (BitKom). Quelle: http://bitkom.org/files/documents/bms_referenzmarketing_neu.pdf; Zugriff am 11. 01. 2014.

D IE

STANDARDISIERTE

S OFTWARE

| 105

gründete Hoffnung haben, einer Gruppe tatsächlich einmal anzugehören (vgl. Merton 1968: 337). In der Unternehmenskommunikation des Softwareherstellers wird diese Idee praktisch angewendet. Beispielhaft ist dafür der Auszug einer Pressemeldung, der in leicht abgewandelter Form in vielen weiteren Veröffentlichungen des Softwareherstellers zu lesen ist. Die vergleichende Funktion der Bezugsgruppe für (potenzielle) Kunden wird folgendermaßen ausgedrückt: „Über 55.000 SAP-Mitarbeiter in mehr als 50 Ländern betreuen rund 183.000 Kunden auf der ganzen Welt. Drei Viertel der Forbes-500-Unternehmen, 80 Prozent der im Dow Jones Sustainability Index gelisteten Unternehmen und 85 Prozent der 100 wertvollsten Marken weltweit (Top 100 most valued brands in the world) nutzen heute Software von SAP.“ (Pressemeldung des Softwareherstellers vom 2. April 2012).

Der Softwarehersteller stellt seine Software zunächst auf Grundlage quantitativer Angaben („in mehr als 50 Ländern“, „183.000 Kunden auf der ganzen Welt“) als de facto-Standard vor.23 Bereits im zweiten Satz werden die Adaptoren des Standards und deren Vorbildlichkeit herausgestellt. Vorbildfunktion haben die Adaptoren aufgrund ihrer Zugehörigkeit zu einer bestimmten Kategorie von Unternehmen. Die erstgenannte Kategorie, „Forbes-500-Unternehmen“, bezeichnet die Gruppe der 500 größten US-amerikanischen Unternehmen, die das Wirtschaftsmagazin Forbes jährlich in einer Rangliste veröffentlicht. Die Unternehmensgröße misst sich an Kennzahlen wie Umsatz, Nettogewinn, Aktiva, Marktwert und Mitarbeiteranzahl. Obwohl seit dem Jahr 2003 eine weitere Liste veröffentlicht wird, die die 2.000 größten (börsennotierten) Unternehmen der Welt in eine Rangfolge bringt („Forbes Global 2000“), verwendet der Softwarehersteller in seinen Beschreibungen auch knapp zehn Jahre später die ursprüngliche Kategorisierung. Die Rangliste „Forbes-500-Unternehmen“ hat anscheinend einen besonderen Wiedererkennungswert. Die zweite Kategorie ist der „Dow Jones Sustainability Index“. Korrekterweise müsste der Plural verwendet werden, denn es handelt sich um mehrere Indizes. Im Unterschied zur Forbes-Liste werden nicht ausschließlich ökonomische, sondern auch ökologische und soziale Bewertungskriterien bei der Erstellung der Rangliste gewichtet. Es gibt Indizes für

23 Ein de facto-Standard wird im Gegensatz zu einem de jure-Standard nicht von offiziellen Stellen oder übergeordneten Instanzen bestimmt, sondern erweist sich als Standard aufgrund seiner faktischen Verbreitung. Vergleiche hierzu KAPITEL 2.3 „Die dritte Entstehungsphase: SAP als de facto-Standard“.

106 | D AS P ROJEKT SAP

Länder, Regionen, Branchen und Strategien.24 Die dritte Kategorie, „100 wertvollste Marken weltweit“, bezeichnet ein Ranking, das sieben verschiedene Faktoren eines Unternehmens prüft und verschiedene Kriterien mithilfe eines Punktesystems von 80 bis 100 bewertet. Die Gewichtung der Kriterien wird als Betriebsgeheimnis betrachtet und nicht veröffentlicht. Die Zeitung Financial Times und andere Akteure in der europäischen Wirtschaftspresse veröffentlichen diese Rangliste einmal jährlich. Die Rangfolge der „100 wertvollsten Marken weltweit“ wird mithilfe eines Markenbewertungsverfahrens des Marktforschungsunternehmens Interbrand erstellt. Der jeweilige Rang eines Unternehmens in diesem Ordnungssystem orientiert sich u. a. an betriebswirtschaftlichen Kennzahlen, dem Ausbildungsgrad der Mitarbeiter und der Anzahl für Patente. Darüber hinaus fließt die Messung von positiven Assoziationen von Konsumenten und Anlegern mit der Marke in die Bewertung ein.25 Der Softwarehersteller konstruiert in seiner Darstellung der erfolgreichen Verbreitung von SAP Beziehungen zwischen Organisationen (Beobachtungsund Vergleichsbeziehungen). Welche 85 dieser 100 aufgelisteten Unternehmen SAP-Softwareprodukte verwenden, wird nicht spezifiziert. Es wird auch nicht präzisiert, für welche Anwendungsbereiche die Software in den Unternehmen verwendet wird. Der Softwarehersteller verwendet ein Scheinargument und verknüpft zwei gemeinsam auftretende Merkmale zu einer Kette aus Ursache und Wirkung. Hergestellt wird ein einfacher Kausalzusammenhang zwischen Unternehmenserfolg und der Verwendung von SAP-Software.26 Wie der Softwarehersteller mit seinen Referenzmarketing, Beziehungen zwischen Organisationen aktiviert, soll anhand der Darstellung der Software auf den Internetseiten des Softwareherstellers erläutert werden.

24 Den Dow Jones Sustainability Index, der 1999 im Rahmen eines Kooperationsprojektes von einem Schweizer Unternehmen und dem Verlagshaus Dow Jones zum ersten Mal definiert wurde, nutzen vor allem Finanzunternehmen, um auf dieser Grundlage Investitionsentscheidungen zu treffen. Quelle: http://www.sustainability-index.com; Zugriff am 02.04.2014. 25 Für die Bestimmung eines Markenwertes gibt es neben dem Bewertungsverfahren von Interbrand eine Reihe verschiedener Datenmodelle, denen jeweils unterschiedliche Bewertungskriterien zugrunde gelegt werden. 26 Dass auch die eigene Marke den Platz 25 in der Rangfolge der „wertvollsten Marken“ einnimmt, untermauert die Marketingstrategie des Softwareherstellers zusätzlich.

D IE

STANDARDISIERTE

S OFTWARE

| 107

Exkurs: „Zufriedene Kunden kennenlernen“ Die Überschrift ist zugleich eine Aufforderung an den Besucher. Die Präsentation von Kundenberichten erreicht man über einen Klick auf der Startseite der Website des Softwareherstellers. Abbildung 13: Beobachtungsordnung des Softwareherstellers

Quelle: http://www.sap.com/germany/customer-testimonials; Zugriff am 10.10.2013

Die drei zentralen Begriffe „Kunde“, „Zufriedenheit“ und „Kennenlernen“ werden im Text folgendermaßen expliziert: Es sind „mehr als 100.000 Kunden aller Größen und aus allen Branchen“, die die Software verwenden. Die Zufriedenheit der Kunden wird daran festgemacht, dass Unternehmen „erfolgreich mit SAPProdukten arbeiten“ und „durch den Einsatz von SAP-Produkten und -Dienstleistungen Mehrwert generieren“. Mit Kennenlernen ist das Lesen von Kundenberichten gemeint. Um sich Kundenberichte anzeigen zu lassen und zu sortieren, sind im linken Fenster fünf Kategorien aufgelistet: „Geschäftsprozesse“, „Geschäftsanalysen“, „Technologien“, „Branchen“ und „Services“. Um sich passen-

108 | D AS P ROJEKT SAP

de Kundenberichte anzeigen zu lassen, werden diese Kategorien durch weitere Kriterien spezifiziert. Da das Suchkriterium „Enterprise Resource Planning“ aktiviert ist, erscheint es im abgebildeten Screenshot in weißer Schrift vor grauem Hintergrund. Die Kundenberichte, die das Suchkriterium „Enterprise Resource Planning“ erfüllen, sind im Hauptfenster aufgelistet. Gemeint sind damit Unternehmen und andere Organisationen, die sich für die Einführung von ERPSoftware entschieden haben. Die Suche nach Kundenberichten liefert 158 Ergebnisse. Diese Treffer werden bündelweise aufgelistet. Im Screenshot sind sieben dieser Berichte sichtbar. Die Gemeinsamkeiten der aufgelisteten Unternehmen bestehen darin, dass sie das Softwareprodukt „Enterprise Resource Planning“ verwenden, ihren bzw. ihre Standort(e) innerhalb von „Europa“, möglicherweise in „allen Ländern“ haben und sich selbst als „kleine und mittelständische Unternehmen“ einstufen. Diese Gemeinsamkeiten sind das Ergebnis einer Auswahl entsprechender Kriterien eines drop-down-Listenfeldes. Das Organisationsproblem, das mit der Software in einem konkreten Unternehmen gelöst werden soll, wird in zwei, maximal drei Sätzen schlagwortartig umschrieben. Organisationsprobleme, für die die Software Lösungen bereithält, sind etwa „Unternehmenswachstum“, „Produktionsabläufe“, „Fertigung“, „Fusion“, „internationale Niederlassungen“. Neben diesen Beschreibungen sind Fotos angeordnet, die entweder eine einzelne Person oder mehrere Personen zeigen. Man könnte auf den ersten Blick vermuten, dass es sich um Bildaufnahmen der Mitarbeiter der aufgelisteten Unternehmen handelt. Tatsächlich zeigen die Fotos jedoch Models, die einer Bilddatenbank entnommen sind. Dieselben Fotos werden teilweise für unterschiedliche Kundenberichte verwendet. Es handelt um Platzhalter für PDF-Dateien oder Videos, die ausführlichere Informationen über die Implementierung von SAP in verschiedenen Organisationen enthalten. Über einen Klick auf das Foto oder den Unternehmensnamen können diese abgerufen werden. Auf der Internetseite des Softwareherstellers werden Organisationen als Modelle für die Implementierung und Verwendung der Standardsoftware präsentiert. Auf einer anderen Seite werden das Referenzkundenprogramm und die Möglichkeiten zur Teilnahme erläutert. Zu lesen ist dort der Satz: „SAP Referenzkunden sind geschätzte Ansprechpartner für andere Unternehmen, Journalisten und Analysten.“ Es wird wieder ein einfacher kausaler Zusammenhang zwischen zwei Ereignissen hergestellt: Vertreter des Unternehmens werden zum geschätzten Ansprechpartner, weil in ihrem Unternehmen SAP-Software verwendet wird. Der Softwarehersteller offeriert Organisationen, die zu ihren Kunden zählen, eine Reihe von Möglichkeiten, ihre „Erfolgsgeschichte“ zu kommunizieren. Aufgezählt werden etwa Gastbesuche, Referenztelefonate mit Interessenten

D IE

STANDARDISIERTE

S OFTWARE

| 109

und potenziellen Geschäftspartnern, Internetseminare für Gruppen, Konferenzvorträge, Presse- und Analysteninterviews sowie Referenzbroschüren: „SAPfinanziert und professionell aufbereitet – immer in Abstimmung mit Ihnen“, „Nach einem kurzen Interview wird ein professionell getexteter SAPAnwenderbericht erstellt“. Aus einer neoinstitutionalistischen Perspektive kann die Beteiligung von Unternehmen an der beschriebenen Form des Marketings vor allem damit erklärt werden, dass bereits die Zurschaustellung von Erfolg rational und ein Kennzeichen moderner Organisationen ist (vgl. Meyer 1996).27 Darüber hinaus werden so auch Beziehungen zwischen Organisationen hergestellt. Zumindest wird dies mit dem Zitat eines Unternehmensvertreters („Wir haben enorm vom SAP Referenzkundenprogramm profitiert. Durch den intensiven Kontakt mit anderen Unternehmen entstanden neue Ideen, Herausforderungen und Lösungen“) suggeriert. Dass es sich dabei nicht um den Originalton eines Herrn XY von der Bosch und Siemens Hausgeräte GmbH handelt, sondern um eine von ihm zwar freigegebene, jedoch von Fachleuten aufbereitetes Zitat handelt, ist wahrscheinlich. Schließlich wird die professionelle Bearbeitung der Kundenberichterstattung auf denselben Seiten angekündigt. 3.3.3 Die Herstellung von Vergleichsbeziehungen und die Theoretisierung der Organisation Bei aller Marketingstrategie bleibt die Frage: Warum sollte ein Entscheider, der auf der Suche nach einer Softwarelösung für seine Organisation ist, seine Entscheidung von der Aussage des Marktführers für Dönerproduktion oder eines französischen Energiekonzerns abhängig machen. Die Antwort gibt SahlinAndersson (1996: 71): „Actors tend to compare their organizations with others considered to be similar in one way or another. Also, they compare organizations with other organizations or models that display some characteristics which seemingly make them successful or potentially successful. In other words, local actors compare their organizations with organizations which fit their hopes and expectations for the future. The difference between one’s own situation and the one with which one is compared becomes then a definition of the problem.“

Vergleiche sind ein konstitutives Merkmal sozialer Ordnung. Die soziale Ordnungsleistung von Vergleichen zeigt sich in den unterschiedlichsten gesellschaft-

27 Vergleiche zu diesem neoinstitutionalistischen Argument KAPITEL 3.2.3. „Die nachgeahmte Software“.

110 | D AS P ROJEKT SAP

lichen Bereichen. Die sozialwissenschaftliche Forschung behandelt den Vergleich, so argumentiert Bettina Heintz (vgl. 2008; 2010) in ihren Arbeiten über den Vergleich als soziale Operation, in der Regel nur als kognitiven Akt und nicht als kommunikatives Phänomen. Es wird zwar von sozialen Vergleichen gesprochen, sozial sind nur die Vergleichseinheiten (Personen, Organisationen etc.) und Vergleichskriterien (z.B. Einkommen, Reputation und Publikationen). Das Phänomen selbst, so Heintz, wird als mentaler Vorgang und nicht als beobachtbares kommunikatives Ereignis aufgefasst. „Sozial anschlussfähig sind Vergleiche erst dann, wenn sie kommuniziert werden“ (ebd. 2010: 163). Sie knüpft damit an Luhmanns systemtheoretisches Kommunikationskonzept an. Wie eine vergleichende Beobachtung zwischen zunächst unverbundenen Einheiten Beziehungen anhand eines gemeinsamen Kriteriums herstellt, illustriert sie am Beispiel von Hochulrankings. Rankings und andere Statistiken repräsentieren für Heintz typische Vergleichsarrangements. Solche Arrangements herzustellen, setzt eine Vielzahl von Entscheidungen und Bearbeitungsschritten voraus, die mit erheblichen Standardisierungsleistungen verbunden sind. Die Herstellung der Vergleichbarkeit sozialer Einheiten ist das Ergebnis einer sozial voraussetzungsvollen Kategorisierung. Ein Beispiel für eine besonders wirkmächtige Kategorie ist die formale Organisation. David Strang und John W. Meyer (1993) haben sich mit dieser und anderen kulturellen Konstruktionen und ihrer Bedeutung für Diffusionsprozesse auseinandergesetzt. Das Konzept der formalen Organisation stellen sie als eine besonders erfolgreiche Form der Theoretisierung vor. Damit ist ein sozialer Prozess gemeint, in dem die reale Welt, die sich durch Vielfalt auszeichnet, transformiert wird und miteinander vergleichbare Einheiten hervorbringt. Am Beispiel von Reformen des öffentlichen Verwaltungssektors illustrieren Nils Brunsson und Kerstin Sahlin-Andersson (2000) ebenfalls die soziale Wirkmacht des Modells formaler Organisation. Sie arbeiten heraus, inwiefern einzelne Aspekte des Modells hervorgehoben und im Zuge von Reformprojekten konstruiert werden: „The reforms can [...] be decribed as a way of turning public services into organizations, or at least into something closer to this than before“ (ebd.: 723). Der Softwarehersteller fördert ebenfalls den Glauben in Unternehmen, Verwaltungen, Universitäten etc., dass Organisationen vieles gemeinsam haben. Die Standardsoftware macht in ihren Programmen konkrete Vorschläge zur Organisationsgestaltung. SAP bringt ein bestimmtes Organisationsmodell in Umlauf. Auf dieses Modell und seine ingenieurtechnischen Grundlagen gehe ich im nächsten Kapitel weiter ein.

4. Das Organisationsmodell von SAP und ingenieurtechnische Grundlagen im Management

Um die Akzeptanz für die Technik bei verschiedenen Nutzern und Nutzergruppen zu erhöhen, hatten die Vertreter des relationalen Ansatzes in der Datenbankentwicklung algebraische Zeichen durch Wörter ersetzt.1 Die Nutzer von relationalen Datenbanken in Unternehmen sollten eigene Abfragen an das Datenbanksystem formulieren können. Die Entwickler von SAP schoben zwischen die Ebene der Datenbank und die Ebene der Datendarstellung die sogenannte Anwendungsebene. Über die Programmlogik und das Berechtigungskonzept der Software wird festgelegt, wie Daten miteinander verknüpft und kombiniert werden und wer auf welche Daten zugreifen darf. Ereignisgesteuerte Prozessketten beschreiben Arbeitsabläufe über Abteilungsgrenzen und Standorte hinweg. Die Organisation wird als Prozessorganisation modelliert. Aufträge, Bestellungen, Rechnungen usw. sind in diesem Modell typische Ereignisse im Unternehmen, die als Startereignisse fungieren und zuvor definierte Prozesse bzw. Prozessketten auslösen. Was wann wie in der Organisation bearbeitet werden soll, wird damit eindeutig bestimmbar. Im folgenden Interviewausschnitt wird die Organisation sogar mit den in den Programmen der Software modellierten Prozessen gleichgesetzt. INTERVIEWPARTNER M: „Es gibt Kern- und Kernfolgeprozesse, wo man wirklich sagt, ich starte links und ende rechts. Quer durchs Unternehmen durch. Und wo dann jeder auch

1

In KAPITEL 1.1 „Die Datenbankebene“ wurde erläutert, wie die Entwickler von SAP ihre betriebswirtschaftlichen Anwendungsprogramme mit dem relationalen Ansatz für Datenbanken kombinierten.

112 | D AS P ROJEKT SAP verstanden hat, ach ja ich muss ja in der Montage das und das berücksichtigen, weil das und das reinkommt.“

Sachliche und zeitliche Unsicherheiten in der Organisation sind im Organisationsmodell der Software auf der Grundlage ereignisgesteuerter Prozessketten verschwunden. Die verbliebene soziale Unsicherheit, die aus der Unübersichtlichkeit von Zuständigkeiten in der Organisation resultieren kann, wird durch wohldefinierte Zuständigkeiten und Benutzerrollen absorbiert. Diese Beschreibung des Organisationsgeschehens basiert auf einem traditionellen Organisationsverständnis. Die Software ist demnach ein Instrument, um Arbeitsabläufe effizienter zu gestalten. Das Unternehmen wird mit Hinweis auf seine Ziele und die für diese Ziele zur Verfügung stehenden Mittel bestimmt. Ein Grundbegriff vieler moderner Managementkonzepte ist die Kundenorientierung. Um global wettbewerbsfähig zu sein, so die Kernaussage, ist es notwendig, Kundenwünsche zur Richtschnur sämtlicher Vorgänge in einer Organisation zu machen. Der Kunde gilt als zentrale Autorität des Wirtschaftsgeschehens.2 Die Softwarenutzer und Softwarenutzerinnen, die zur Einführung und Verwendung von SAP befragt wurden, gehen von einem ähnlichen Ansatz aus. Sie charakterisieren organisationsinterne Arbeitsabläufe als Wertschöpfungsprozesse und Wertschöpfungsketten, die von ihrem Ende, d.h. vom Kunden her zu denken sind. INTERVIEWPARTNER O: „SAP macht auch mehr Arbeit in gewissen Bereichen. Aber ich glaube, wenn man das über den ganzen Prozess sieht, glaube ich, dass die Firma S., also als Gesamtes eher einspart in den Prozessen als mehr machen muss. Und es ist schneller. Ganz klar, es ist nicht immer vorteilhaft, dass es schneller und ersichtlicher ist. Ist klar. Aber im Endeffekt ist es ja für unsere Kunden und da muss es auch schnell und vernünftig sein.“

Ebenso gut hätten O und die anderen Interviewpartner und Interviewpartnerinnen von Aufgaben und Arbeitsabläufen sprechen können, doch sie verwenden

2

Die Idee der Kundenorientierung und ihre organisatorischen Konsequenzen beschreibt Stephan Voswinkel (2013: 147) so: „Kundenorientierung soll nicht nur die Organisation auf die Kunden und ihre Wünsche, sondern auch die Kunden und ihre Wünsche auf die Organisation orientieren. Der Kunde soll gebunden und damit die Konkurrenz eingeschränkt werden. Gerade die Machtressource, die der Markt dem Kunden bietet, die Möglichkeit, den Anbieter ohne Begründungszwang und ohne Kosten zu wechseln, wird ihm so entzogen.“

D IE

STANDARDISIERTE

S OFTWARE

| 113

stets den Prozessbegriff. Kundenorientierung ist ein Wert an sich, der persönliche Nachteile und den zusätzlichen Aufwand rechtfertigt, der mit der Softwareeinführung verbunden ist. Im weiteren Verlauf des Interviews beschreibt O, wie SAP es ermöglicht, den Kunden über den Arbeitsfortschritt im Unternehmen im Detail zu informieren. Er berichtet von seiner Tätigkeit im Vertriebsinnendienst. „Vorher muss man sich das so vorstellen, hatte man wirklich, man hat einen Auftrag erfasst und da hat dann auch eine Verfügbarkeitsprüfung stattgefunden. Wenn das im Auftrag halt auf L stand, dann wussten wir okay, wir haben jetzt die Kommissionierung angestoßen. Wir hatten hinten auch im Endeffekt einen Status, dass das jetzt begonnen hatte. Aber wir konnten jetzt nicht genau im Einzelnen sehen, wo, wie weit stehen wir denn schon.“

Zwar sei ein Kundenauftrag auch vor der Einführung von SAP bereits elektronisch erfasst und die Bestelldaten automatisch mit den Daten des Materiallagers abgeglichen worden, über den Arbeitsfortschritt in anderen Abteilungen des Unternehmens sei der Vertriebsinnendienst allerdings nicht informiert gewesen. Aus diesem Grund habe der Vertriebsinnendienst dem Kunden auch keine Auskunft über den Status seiner Bestellung geben können: „Das war einfach nur so eine Black Box für uns im Verkaufsinnendienst und dem Kunden konnten wir auch noch nichts kommunizieren“ (ebd.). Auf den folgenden Seiten erläutere ich die Verbindung von SAP mit anderen Managementkonzepten. Der sogenannte Managementtrend in den 1990er Jahren Business Process Reengineering steht im Mittelpunkt der Betrachtung. Anschließend gehe ich auf die historischen Wurzeln modernen Managements in Organisationen ein. Zentraler Bestandteil heutiger Managementpraxis ist die Unsicherheitsreduktion mittels moderner IT wie SAP. Vermutlich ist Unsicherheitsreduktion das Problem aller Managementkonzepte. Kein anderes Problem war und ist für die Beschreibung von Organisationen wohl so relevant. Dies gilt jedoch nicht nur für Managementansätze, sondern auch für unterschiedliche Ansätze der modernen Organisationstheorie. Dass die Idee der Unsicherheitsreduktion ideologisch im Ingenieurwesen verwurzelt ist, wird von Organisationsforschern allerdings selten reflektiert.

114 | D AS P ROJEKT SAP

4.1 SAP

UND ANDERE

M ANAGEMENTKONZEPTE

Wie die vielfältigen Möglichkeiten der Datenkombination, die auf der Grundlage der relationalen Datenbanktechnik geschaffen worden waren, in den Anwendungsprogrammen genutzt werden sollen, darauf gibt ein Anfang der 1990er Jahre bekannt gewordenes Managementkonzept eine scheinbar eindeutige Antwort. In Reengineering the Corporation: A Manifesto for Business Revolution (1993) führen Michael Hammer und James Champy das Konzept Business Process Reengineering (BPR) ein.3 BPR steht für ein besonders wirkmächtiges Organisationsmodell. Hiernach sollen Organisationen so umgebaut werden, dass sie in der Lage sind, stärker und schneller als zuvor auf Kundenwünsche und Kundenerwartungen zu reagieren. Die US-amerikanischen Unternehmensberater Hammer und Champy propagieren dafür eine intensivere Nutzung von Informationstechniken wie SAP. Um Geschäftsprozesse in Unternehmen zu vereinfachen, fordern sie dazu auf, abteilungsspezifische Arbeitsabläufe in ihre einzelnen Bestandteile zu zerlegen, diese für verschiedene Standorte und Unternehmensbereiche zu vereinheitlichen und mithilfe moderner IT wieder zusammenzufügen, um so Arbeitsabläufe effizienter zu gestalten. Mithilfe moderner Informationstechniken wie SAP, so der Tenor von BPR, können Unternehmen schneller und direkter auf Kundenwünsche und Kundenerwartungen reagieren. Der Kunde wird damit auch innerhalb der Organisation zum Souverän erklärt. Die Expansion der Software Anfang der 1990er Jahre begründet der Technikhistoriker Martin Campbell-Kelly in From Airline Reservations to Sonic the Hedgehog. A History of the Software Industry (2003) mit dem aufkommenden Managementtrend Business Process Reengineering (BPR). Als Beleg für den Zusammenhang zwischen BPR und dem Markterfolg von SAP führt er an, dass der Softwarehersteller den Großteil seines Umsatzwachstums in den 1990er Jahren in den USA erwirtschaftete (vgl. Campbell 2003: 197). Inwieweit die Verbreitung von SAP tatsächlich auf diesen Managementtrend zurückgeführt werden kann, lässt sich nur vermuten. Michael Hammer, Co-Autor des Managementklassikers, stellt rückblickend einen umgekehrten Zusammenhang fest: „SAP software was one of the major forces behind the growth of the process phenomenon“ (Hammer 2004: 89). Ob SAP tatsächlich zur Verbreitung des Ma-

3

Das Buch wurde in 15 Sprachen übersetzt und der 1990er Jahre zu einem der meistverkauften Managementbücher (vgl. Schwuchow 2007: 24ff.). Weil BPR über einen längeren Zeitraum den Managementdiskurs prägt, bezeichnet der skandinavische Organisationsforscher Kjell Røvik (2002: 113) das Managementkonzept auch als „Superstandard“.

D IE

STANDARDISIERTE

S OFTWARE

| 115

nagementkonzeptes oder umgekehrt BPR wesentlich zur Verbreitung der Standardsoftware beigetragen hat, kann nicht nachgewiesen werden, auch wenn Hammer behauptet: „SAP software was one of the major forces behind the growth of the process phenomenon. Initially, though, the company itself wasn’t particularly aware of it. Most technologies are poorly understood in their early days. When a new technology comes along, we tend to see it only as a tool to solve old problems [...]. When Hasso Plattner and his colleagues developed SAP software, it is not certain that they fully grasped its transformative effect.“ (Hammer 2004: 89)

In Hammer und Champys „Manifest“ wird ein eindeutiger kausaler Zusammenhang zwischen Technik und organisatorischem Wandel hergestellt. Für die Autoren besitzt die Software eine eigene Logik, die von Entwicklern von SAP selbst allerdings erst im Nachhinein entdeckt wurde. Hammer verwendet ein technikdeterministisches Argument, demnach technischer Fortschritt kulturelle und soziale Anpassungen hervorruft. Die Verwendung moderner Informations- und Kommunikationstechnik wie SAP führt dazu, dass Unternehmen stärker und schneller auf Kundenwünsche reagieren können. Arbeitsabläufe können effizienter gestaltet werden. Dieser auch in den Organisationswissenschaften üblichen Effizienzperspektive, stellt der Neoinstitutionalismus ein auf Fragen der Legitimität ausgerichtetes Forschungsprogramm gegenüber.4 Ein prominentes Fallbeispiel in der neoinstitutionalistischen Forschung ist die ISO 9000er-Serie (vgl. Walgenbach 2000; Brunsson & Jacobsson 2000; Brunsson et al. 2012). Der weltweit anerkannte Standard für das Qualitätsmanagementsystem dient als Beispiel par excellence, wie sich Organisationen mit der Übernahme vermeintlich rationaler Strukturen Legitimität verschaffen. Da das zugrunde liegende Organisationsmodell zahlreiche Überschneidungen zum Organisationsmodell von SAP aufweist, gehe ich im Folgenden näher darauf ein. Exkurs: Das Beispiel ISO 9000 Die International Organization for Standardization (ISO) wurde 1947 mit dem Ziel gegründet, die internationale Koordination in der Industrie zu fördern. Craig Murphy und JoAnne Yates (2009) zeichnen in ihrer historischen Studie den Beitrag der ISO zum Aufbau der technischen Infrastruktur für eine globale Wirtschaft nach. Sie stellen fest, dass der Schwerpunkt der ISO-Aktivitäten, der in

4

Vergleiche hierzu KAPITEL 3.1 „Die neoinstitutionalistische Organisationstheorie“.

116 | D AS P ROJEKT SAP

der Vergangenheit bei der Standardisierung von Techniken lag, inzwischen bei der Formulierung von Verhaltensstandards für Organisationen liegt.5 Die ISO9000er-Reihe kann als eine Form der Regulierung von Organisationen betrachtet werden, die nicht auf Marktmechanismen oder Gesetzen, sondern auf sozialen Standards basiert (vgl. Brunsson & Jacobsson 2000). Gemessen an der Zahl der verliehenen Zertifikate ist ISO 9000 ein erfolgreicher Organisationsstandard. Viele Unternehmen machen das Zertifikat zur Bedingung für die Zusammenarbeit mit Lieferanten und Dienstleistern. Ob die zertifizierten Prozesse jedoch überhaupt das leisten, was sich die Abnehmer der erzeugten Produkte oder Dienstleistungen davon versprechen, garantiert ein Zertifikat nicht. Das Zertifikat erfüllt vor allem eine wichtige Signalfunktion: „To the wider external world, it sends a signal that an organization runs a ‚tight ship‘ according to a rationally ordered and widely recognized model“ (Mendel 2006: 140). ISO 9000 repräsentiert ein Organisationsmodell, das auf den folgenden Annahmen basiert.6 ANNAHME 1:

Organisationen sind von ihren Kunden abhängig und sollten daher gegenwärtige und künftige Kundenbedürfnisse verstehen, sie sollten die Anforderungen der Kunden erfüllen und danach streben, die Kundenerwartungen zu übertreffen.

ANNAHME 2:

Führungskräfte

sorgen

für

die

einheitliche

Zielsetzung

und

Ausrichtung der Organisation. Sie sollten ein internes Umfeld schaffen und aufrechterhalten, in dem die Mitarbeiter sich voll und ganz für die Erreichung der Ziele der Organisation einsetzen können. ANNAHME 3:

Die Mitarbeitenden sind auf allen Ebenen der prägende Faktor der Organisation. Ihre umfassende Einbeziehung ermöglicht es, ihre Fähigkeiten zum Vorteil der Organisation zu nutzen.

ANNAHME 4:

Ein gewünschtes Ergebnis lässt sich effizienter erreichen, wenn Tätigkeiten und dazugehörige Ressourcen als Prozess geleitet und gelenkt werden. Die Organisation besteht aus klar definierten und von Personen kontrollierbaren Prozessen.

5

Neben dem Qualitätsmanagementsystem ISO 9000 zählen Standards für CSR (Corporate Social Responsibility) und Umweltstandards ebenfalls zum aktuellen Schwerpunkt der ISO.

6

Es handelt sich um eine Übersetzung der ISO-9000-Grundsätze, die in den Dokumenten ISO 9000:2005 und ISO 9004:2009 aufgelistet sind. Quelle: http://www.iso.org/ iso/home/store/quality_publications.htm; Zugriff am 15.11.2013.

D IE

ANNAHME 5:

STANDARDISIERTE

S OFTWARE

| 117

Prozesse, die miteinander in Wechselwirkung stehen, als System zu erkennen, zu verstehen und zu steuern, trägt dazu bei, die Ziele der Organisation effektiv und effizient zu erreichen.

ANNAHME 6:

Die kontinuierliche Verbesserung aller Leistungen sollte eine ständige Aufgabe der Organisation sein.

ANNAHME 7:

Wirksame Entscheidungen beruhen auf der Analyse von Daten und Informationen.

ANNAHME 8:

Eine Organisation und ihre Lieferanten sind voneinander abhängig. Beziehungen zum gegenseitigen Nutzen erhöhen die Wertschöpfung beider Seiten.

Das ISO-Organisationsmodell lässt sich folgendermaßen zusammenfassen: Der Organisationszweck besteht vornehmlich in der Erfüllung bzw. Übererfüllung von Kundenerwartungen. Die Organisation und ihr Management sind letztlich Werkzeuge bzw. Mittel zur Zielerreichung. Das Management definiert hiernach Teilziele, stellt die notwendigen Mittel zur Erreichung dieser Ziele und des übergeordneten Gesamtziels zur Verfügung, schafft zielfördernde Kontextbedingungen. Die Entscheidungsfindung in Organisationen erfolgt ausschließlich nach sachlichen Gesichtspunkten. Außerdem wird in den Grundannahmen eine bestimmte Wertorientierung zum Ausdruck gebracht: die Idee kontinuierlicher Verbesserung. Grundlegend für das ISO-Modell ist, dass die Organisation als weitgehend geschlossene Systeme operieren. Die Vielfalt möglicher Umweltbezüge einer Organisation beschränkt sich auf Kundenerwartungen und Lieferantenbeziehungen. Konzeptuell ist das ISO-Organisationsmodells, so der Organisationsforscher Staffan Furusten (2000) in The Knowledge Base of Standards (2000), im Taylorismus verwurzelt. Die Grundsätze der wissenschaftlichen Betriebsführung (scientific management) des Ingenieurs Frederick W. Taylor sind die Forderung nach Ordnung und das Bestreben, Arbeitsabläufe möglichst vollständig zu formalisieren. ISO 9000, BPR und SAP basieren auf demselben Deutungsmuster der Organisation, das seine ideologischen Wurzeln im Ingenieurwesen hat. Anfang des 20. Jahrhunderts wurde die Organisation von Taylor und anderen Managementingenieuren erstmals explizit zu einem Wissensobjekt gemacht. Im nächsten Kapitel stelle ich den ingenieurtechnischen Ansatz von Taylor vor, der in den Organisationswissenschaften als Startpunkt für die theoretische Auseinandersetzung mit Organisationen gilt (vgl. z.B. Kieser 2014). Am Beispiel von Herbert A. Simons verhaltenswissenschaftlicher Entscheidungstheorie soll an-

118 | D AS P ROJEKT SAP

schließend gezeigt werden, inwiefern auch modernen Organisationstheorien ein ingenieurtechnisches Denkmuster zugrunde liegt.

4.2 M ANAGEMENTINGENIEURE UND DAS P ROBLEM DER U NSICHERHEITSREDUKTION In der Managementforschung zählen die historischen Untersuchungen von Alfred D. Chandler (1977) zu einem der wichtigsten theoretischen Bezugspunkte zur Erklärung des Aufkommens moderner Unternehmensführung. In The Visible Hand. The Managerial Revolution in American Business beschreibt der Historiker die Entstehung professionellen Managements in Unternehmen als Antwort auf neue technische, kaufmännische und organisatorische Herausforderungen.7 Er sieht das Berufsbild des Managers begründet in der zunehmenden Größe USamerikanischer Unternehmen zu Beginn des 20. Jahrhunderts. Einen dazu alternativen organisationssoziologischen Erklärungsansatz stellt Yehouda Shenhav mit Manufacturing Rationality (1999) vor. Die Einrichtung von Managementstellen führt Shenhav – ebenso wie Chandler – auf gestiegene Anforderungen unternehmerischer Effizienz zurück. Darüber hinaus erklärt er sie jedoch durch die zunehmende Professionalisierung von Ingenieuren. Darunter sind Aktivitäten einer Berufsgruppe zu verstehen, die Inhalte und Rahmenbedingungen für ihre Arbeit selbst zu definieren. Die Entstehung modernen Managements ist Shenhav zufolge auf die Bemühungen von Ingenieuren zurückzuführen, ihren Kompetenzbereich in Betrieben zu erweitern. Der Zuständigkeitsbereich von Ingenieuren weitete sich zu Beginn des 20. Jahrhunderts zusehends von Maschinen auf die Führung und Kontrolle des gesamten Unternehmens aus. Shenhavs These stützt sich auf eine Inhaltsanalyse von Zeitschriftenbeiträgen, die in den Fachjournalen American Machinist (AM), Engineering Magazine (EM) und ASME Transactions (AT) im Zeitraum zwischen 1880 und 1930 veröffentlicht wurden.8 In diesen Zeitschriften wurde die

7

Chandler (1977; 1984) untersucht u. a. die Chemieunternehmen Imperial Chemical Industries (ICI) und Du Pont. Er expliziert an diesen Beispielen die Entwicklung von einem Einprodukt-Unternehmen zu einem Großunternehmen mit mehreren Produktsparten. Das dabei entwickelte Organisationsmodell der Spartenstruktur (multidivisional structure) hat Chandler zufolge die Restrukturierung vieler Großunternehmen weltweit bestimmt.

8

AM wurde 1877 in New York gegründet, EM 1891 ebenfalls in New York und ab 1896 folgte eine britische Ausgabe. AT wurde von der American Society of Mechani-

D IE

STANDARDISIERTE

S OFTWARE

| 119

Funktionsweise von Organisationen und deren Management erstmals explizit zum Thema und einem breiten Publikum zugänglich gemacht. Viele der dort erschienenen Beiträge beschäftigen sich aus einer Ingenieurperspektive mit Unsicherheit und Unsicherheitsreduktion in Organisationen. Wie Problembeschreibungen auf technischen Gebieten auf soziale Zusammenhänge übertragen wurden, soll im nachfolgenden Kapitel an einem Beispiel illustriert werden, das von einem besonders prominenten Vertreter der Managementingenieure zu Beginn des 20. Jahrhunderts stammt: Frederick W. Taylor. 4.2.1 Der Ingenieur Taylor und das Prinzip der Übertragung Zu einem der führenden Repräsentanten des ingenieurtechnischen Denkansatzes in der Organisationstheorie wird Frederick W. Taylor mit seinem Ansatz der wissenschaftlichen Betriebsführung (vgl. Taylor 2006) gezählt. Ordnung und politische Stabilität im Unternehmen sind Taylor zufolge durch Systematisierung und Standardisierung erreichbar. Nur auf diese Weise kann ein reibungsloser Ablauf der Produktion gewährleistet werden. Einem breiteren Publikum wird der Ingenieur Taylor mit dem Vortrag A Piece-Rate System. Being a Step Toward Partial Solution of the Labor Problem (1895) bekannt. Er hielt den Vortrag vor der American Society of Mechanical Engineers (ASME) in Detroit. Anschließend wurde der Vortrag auch in der ASME Transactions und anderen Fachzeitschriften abgedruckt. Taylor schlägt vor, Stückpreis und Stücklohn nach wissenschaftlich neutralen Kriterien festzulegen. Eine zentrale Rolle spielen dabei Zeitund Bewegungsstudien. „Weil die Festlegung auf genauer Kenntnis der Arbeit und nicht mehr oder weniger auf Erraten beruht, fällt das Motiv für das Zurückhalten der Leistung und das sogenannte Bummeln und damit die Versuchung den Arbeitgeber bezüglich der für die Arbeit benötigten Zeit zu täuschen vollständig weg, sodass auch die wichtigste Ursache für Unstimmigkeiten und Streit zwischen der Betriebsleitung und den Leuten wegfällt.“ (Taylor 1895: 858; zit. n. Hebeisen 1999: 83)

Taylor macht einen Vorschlag zur Reduktion von Unsicherheit im Unternehmen. Mit dem „Ein-Stücklohn-System“ versucht er die Arbeitsabläufe nicht nur möglichst effizient zu gestalten, sondern primär den Betriebsfrieden zwischen Arbeitgebern und Arbeitnehmern sicherzustellen. In seinen Augen stellen Arbeits-

cal Engineers herausgegeben. Auch der Berufsverband für Maschinenbauingenieure ASME wurde 1880 gegründet und hat heute noch seinen Sitz in New York City.

120 | D AS P ROJEKT SAP

unterbrechungen den größten Unsicherheitsfaktor für einen reibungslosen Produktionsablauf dar. Bislang basierten Lohnsysteme auf der Idee, finanzielle Anreize für einen höheren Produktionsausstoß und bessere Arbeitsergebnisse zu schaffen. Taylor hingegen ist bereit, höhere Löhne unter der Bedingung zu zahlen, dass alle Arbeiter einheitliche Leistungsstandards akzeptierten, die auf der Grundlage „wissenschaftlicher“ Methoden festgelegt werden.9 Der ideologische Konflikt zwischen Kapital und Arbeit wird auf diese Weise neutralisiert. Die Gefahr von Arbeitskämpfen stellt hiernach kein politisches Thema mehr dar. Taylor konstruiert es als Problem, das mithilfe der Anwendung „wissenschaftlicher“ Methoden gelöst werden kann. Taylors vorgeschlagene Methoden erhalten allerdings nicht die erhoffte Aufmerksamkeit. Den meisten Teilnehmern im Publikum erscheint die Realisierung von Taylors System zu aufwendig (vgl. Hebeisen 1999: 85). Die SystemÜberlegungen von Taylor sind dennoch bedeutsam, weil sie ein paradigmatisches Beispiel dafür sind, dass Ingenieure nicht mehr länger nur für die Beseitigung technischer Unsicherheiten im Betriebsablauf zuständig sein wollen. Sie beschäftigen sich nunmehr auch mit der Reduktion organisatorischer Unsicherheiten. Zu Beginn des 20. Jahrhunderts wird die Unternehmensführung und Planung eines Unternehmens zu einem zentralen Betätigungsfeld von Ingenieuren. Die Begriffe System und Systematisierung werden in den von Shenhav (s.o.) ausgewerteten Fachzeitschriften noch in einem umfassenden und allgemeinen Sinne als Ordnungsprinzipien verwendet. Später wird das Unternehmen selbst als technisches System betrachtet, das imstande ist, körperliche und motivationale Beschränkungen von Individuen zu kompensieren. Die frühen Managementtraktate verfügen noch über keine kohärente Theorie. Es sind Industrieberater oder leitende Angestellte in Unternehmen, die einzelne Leitsätze und normative Empfehlungen für die Gestaltung von Organisationen formulieren. Verbreitung finden diese Schriften zunächst in großen US-amerikanischen Unternehmen wie Du Pont, AT&T oder Standard Oil of New Jersey. Als Beispiele seien James D. Mooney und Alan C. Reileys The Principles of Organization (1939) sowie Luther Gulick und Lyndall Urwicks Papers on the Science of Administration (1937) genannt. Mooney und Reiley hatten beispielsweise Führungspositionen

9

Die Bezeichnung Scientific Management übernahm Taylor erst später von Louis Brandeis, der als Richter des Obersten Gerichtshofs in den USA v. a. mit der Reform von Gesetzen im Bereich industrieller Beziehungen beschäftigt war. Brandeis hatte in den Vorträgen von Taylor das Wort wissenschaftlich so oft gehört, dass er schließlich über Taylors Arbeiten als wissenschaftliche Betriebsführung berichtete (vgl. Shenhav & Weitz 2000: 383).

D IE

STANDARDISIERTE

S OFTWARE

| 121

bei General Motors inne (vgl. Massie 1966: 387), Gulick gehörte als anerkannter Experte für Verwaltungsprozesse zum Beraterstab des US-Präsidenten Franklin D. Roosevelt (vgl. Simon 1991: 269). Gemeinsam ist den Leitsätzen der frühen Managementliteratur, dass sie alle von einem Bild der Organisation ausgehen, in dem Individuen zunächst nicht vorkommen, sondern erst in einem zweiten Schritt implementiert werden. Dasselbe gilt auch für die softwarebasierte Modellierung der Organisation, wie sie SAP repräsentiert. Betriebswirtschaftliche Ereignisse werden miteinander verkettet und lösen Prozesse im System der Software aus. Mit ereignisgesteuerten Prozessketten wird festgelegt, was wann und wie in einer Organisation geschieht. Diese Form der Systematisierung hängt ab von einer hohen Reglementierung und dichten Dokumentation sozialer Abläufe. Sie setzt voraus, dass jede Situation regelhaft beschrieben werden kann. Abweichungen vom regelhaft Erfassten sollen vermieden werden. Wer was wie wann in welcher Reihenfolge bearbeiten soll, ist ein Frageschema, das zumindest im System der Software eindeutige Antworten zulässt. 4.2.2 Auf dem Weg zu einer modernen Organisationstheorie Mit den von Taylor und seinen Nachfolgern Luther Urwick und Lyndall Gulick formulierten Grundsätzen der Organisationslehre setzt sich Herbert A. Simon kritisch auseinander. Simon gilt als Begründer der verhaltenswissenschaftlichen Entscheidungstheorie und damit als Wegbereiter einer modernen Organisationstheorie. In Proverbs of Administration (1946) weist er auf die Unmöglichkeit hin, eine generalisierte Präferenz für die effiziente Gestaltung von Organisationen zu etablieren. Das grundlegende Problem der klassischen Verwaltungslehre und ihrer Prinzipien besteht darin, so Simon, dass so getan wird, als ob es ein Leitprinzip gibt. Tatsächlich lassen sich bloß eine Reihe von Kriterien auflisten, mit deren Hilfe administrative Problemsituationen adäquat beschrieben werden können. Erst unter Zuhilfenahme des Kriteriums der Effizienz lassen sich dann Entscheidungen treffen. Bereits in diesem frühen Aufsatz skizziert Simon Grundzüge eines umfassenden Forschungsprogramms, das auf der Annahme beruht, Regelmäßigkeiten im menschlichen Verhalten mittels sorgfältiger empirischer Analysen nachweisen zu können. Induktives Vorgehen sowie die Trennung faktischer Aussagen von Werturteilen werden zum Maßstab für die Wissenschaftlichkeit einer Organisationstheorie erhoben (vgl. Mormann 2015: 640ff.). Simons entscheidungstheoretisches Forschungsprogramm und seine Systemperspektive werden im nächsten Kapitel vorgestellt. Dabei werde ich mich

122 | D AS P ROJEKT SAP

nicht nur auf seine organisationstheoretischen Beiträge, sondern auch auf seine Arbeiten zur Künstlichen Intelligenz-Forschung beziehen.

4.3 S IMONS ENTSCHEIDUNGSTHEORETISCHES F ORSCHUNGSPROGRAMM „[F]or [his] pioneering research into the decision-making process in economic organization“ wird Simon 1978 als erstem Nicht-Wirtschaftswissenschaftler der Nobelpreis für Wirtschaftswissenschaften verliehen (vgl. Carlson 1978). In vielen Lehrbüchern für Organisationstheorien findet dieser Umstand Erwähnung. Weniger bekannt ist jedoch, dass Simon auch zu den Begründern der Künstlichen Intelligenz (KI) zählt. Gemeinsam mit Allen Newell und J. Clifford Shaw entwickelt er in den 1950er Jahren den Logic Theorist (Newell & Simon 1956), eines der ersten KI-Programme, das imstande ist, selbstständig Theoreme der formalen Logik zu beweisen. Einige Jahre später stellen sie mit dem General Problem Solver (Newell & Simon 1961) ein Computerprogramm vor, das als Weiterentwicklung des LT gelten kann. Simons Arbeiten auf dem Gebiet der Künstlichen Intelligenz haben, so argumentiere ich im Folgenden, auch seine organisationstheoretischen Überlegungen stark beeinflusst. „For a relatively brief but enormously productive time as a young man he labored to bring behavioral realism to the theory of organization and the firm, and that period can properly be claimed by economics. The last and longest part of his career was devoted to cognitive science, and his mature years belong properly to psychology. But for Simon these periods were all of one piece. He was a student of human decision making.“ (Augier & March 2004: 5)

Simon hat sich auf unterschiedlichen Wissensgebieten mit dem Problem des Entscheidungsverhaltens von Individuen und ihrer Modellierung auseinandergesetzt. Sein entscheidungstheoretisches Forschungsprogramm soll im Folgenden vorgestellt werden, da es den Übergang zu einer modernen Organisationstheorie markiert. Von Niklas Luhmann werden zentrale Konzepte und Begriffe für eine Soziologie der Organisation adaptiert. In TEIL B greife ich auf Luhmanns systemtheoretischen Ansatz zurück, um die Implementierung der Standardsoftware aus einer genuin organisationssoziologischen Perspektive zu analysieren. Zunächst soll jedoch Simons originäres Konzept der Organisation als Entscheidungssystem vorgestellt werden. Entscheidungsprogramme, die Simon zufolge für das Design von Organisationen als Entscheidungssysteme von zentraler Be-

D IE

STANDARDISIERTE

S OFTWARE

| 123

deutung sind, expliziere ich anschließend. Danach gehe ich auf seine Systemperspektive ein, die in der sozialwissenschaftlichen Organisationsforschung bisher unzureichend rezipiert wurde. 4.3.1 Organisationen als Entscheidungssysteme Simons Forschungsinteresse gilt dem Entscheidungsverhalten von Individuen. Organisationen sind Orte, an denen Entscheidungen von Individuen koordiniert und programmiert werden. Die Theorie der begrenzten Rationalität (bounded rationality) ist der Kern von Simons Überlegungen zum Entscheidungsverhalten. Die begrenzte Rationalität von Individuen führt er auf deren begrenzte kognitive Fähigkeiten zurück. Kein Mensch ist in der Lage, objektiv rationale Entscheidungen zu treffen, weil niemand sämtliche Entscheidungsalternativen und Konsequenzen eines Entscheidungsverhaltens vollständig überblicken kann. Simon unterscheidet verschiedene, durch Ziel- und Mittelkategorien definierte Rationalitäten. „[W]e can only speak of rationality relative to a frame of reference” (March & Simon 1958: 138). Persönlich rational sind hiernach Entscheidungen, wenn sie auf persönliche Ziele des Individuums ausgerichtet sind. Subjektiv rational sind Entscheidungen, sobald sie den Grad der Zielerreichung im Verhältnis zum tatsächlichen Wissen des Individuums maximieren. Organisatorisch rational ist eine Entscheidung dann, wenn sie auf die Organisationsziele hin ausgerichtet ist (vgl. Simon 1981: 111f.). Organisationen stellen für Simon eine Entscheidungsumwelt für Individuen dar. Obwohl er Organisationen als Entscheidungssysteme bezeichnet, beschreibt er doch vor allem das Entscheidungsverhalten von Individuen und ihre Beeinflussung durch die organisatorische Entscheidungsumwelt. Als zentrale Einflussmechanismen der Organisation zählt er Regeln der Arbeitsteilung, Routinen, Hierarchien, Informationswege und die Sozialisation der Organisationsteilnehmer auf. Diese Mechanismen können die Informationsverarbeitung und das Entscheidungsverhalten von Individuen so prägen, dass sie sich rational im Sinne der Ziele der Organisation verhalten. Organisationen fungieren Simon zufolge als Korrektiv für die begrenzte Rationalität von Individuen. Während Taylors Ansatz für eine wissenschaftliche Betriebsführung auf die körperlichen und motivationalen Grenzen der Arbeiter abstellt, rückt Simon die kognitiven Grenzen von Organisationsteilnehmern und ihre mögliche Erweiterung durch die Organisation in den Mittelpunkt. Obwohl Simons zweites organisationstheoretisches Hauptwerk, das er mit James G. March verfasst, von Organisationen handelt, enthält das Buch keine Definition von Organisation: „[Wir meinten,] es sei einfacher“, so March in einem Interview, „das Phänomen jeweils nach und nach zu spezifizieren, statt es

124 | D AS P ROJEKT SAP

vorweg definitiv zu fixieren“ (2001: 21). In Organizations werden stattdessen eine Reihe von Einflussvariablen und Annahmen über das Entscheidungsverhalten von Individuen in Organisationen in der Form konditionaler Sätze (WennDann-Sätze) aufgelistet. Diese Darstellungsform erleichtert die Übersetzung von Thesen in die formale Sprache der Mathematik. Das Buch ist erfolgreich, weil die Autoren unterschiedliche Forschungsfelder in den Organisationswissenschaften systematisieren. Allerdings bleiben Simon und March die empirischen Belege für ihre theoretischen Annahmen schuldig. Selbstkritisch bemerkt Simon (1991) dazu, dass viele Phänomene des menschlichen Verhaltens zwar für jedermann zugänglich und Bestandteil alltäglicher Erfahrungen seien, diese aber weder mit Mikroskop noch mit Geigerzähler oder Radiodetektoren nachgewiesen werden können. Die Sozialwissenschaften profitierten zwar davon, zugleich litten sie aber auch darunter, das menschliche Verhalten nicht messbar machen zu können. Das meiste Wissen über Organisationen – auch das Wissen, das als wissenschaftlich gekennzeichnet sei – basiere daher lediglich auf subjektiven Beobachtungen und Erfahrungen. Simon vertritt den Standpunkt, die Sozialwissenschaften benötigen ein ebenso solides mathematisches Fundament wie die Naturwissenschaften. Die Mathematik betrachtet er aus der Perspektive eines Ingenieurs oder Physikers und weniger aus der eines reinen Mathematikers. Er versteht die Mathematik nicht als ein Mittel zur Verifizierung („logic of verification“), sondern als eine Form nicht-verbalen Denkens für die Entdeckung von komplexen Zusammenhängen („logic of discovery“; Simon 1977). In ähnlicher Weise nutzt er auch die elektronische Datenverarbeitungstechnik für seine Forschung. Schon zu Beginn seiner wissenschaftlichen Laufbahn in den 1930er Jahren arbeitete er mit dem Computerhersteller IBM zusammen, um das technische Equipment für Datenauswertungen für seine ersten Forschungsprojekte mit Clarence Ridley zu nutzen.10 Die Theorie der begrenzten Rationalität ist nicht nur Ausgangspunkt für Simons organisationstheoretische Überlegungen, sondern auch für seine Beschäftigung mit dem Computer.11 Für Simon ist der Computer nicht nur ein techni-

10

Simon war Assistent von Ridley, der als Experte für die Reform von Stadtverwaltungen hohes Ansehen genoss. Ridley und Simon befassten sich damals mit Untersuchungen der staatlichen Fürsorgebehörden. Sie sollten beispielsweise die optimale Fallanzahl für Sozialarbeiter bestimmen, damit diese möglichst effektiv ihrem Auftrag nachkommen konnten (vgl. Ridley & Simon 1938).

11

Außerdem beschäftigte sich Simon in Fiscal Aspects of Metropolitan Consolidation (Simon 1943) mit indirekten Effekten steuerlicher Anpassungen auf das Entschei-

D IE

STANDARDISIERTE

S OFTWARE

| 125

sches Hilfsmittel zur Datenauswertung. Computersimulationen dienen ihm als Mittel für die Entdeckung von Zusammenhängen im Entscheidungsverhalten von Individuen. Im Laufe der Jahre verschiebt sich sein Forschungsinteresse von einer Theorie individuellen Entscheidungsverhaltens hin zur Untersuchung symbolischer Problemlösungsprozesse. Wie einleitend bereits erwähnt, entwickelt Simon mit Allen Newell und J. Clifford Shaw 1956 den Logic Theorist (Newell & Simon 1956). Der LT ist imstande, wichtige Theoreme von Whitehead und Russells Principia Mathematica (1910–1913) zu beweisen. Simon und seinen Kollegen geht es beim LT nicht darum, dass Computerprogramme bestimmte Aufgaben für den Menschen übernehmen und ihn somit ersetzen sollen. Vielmehr soll das menschliche Vorgehen beim Problemlösen genauer charakterisiert und auf dem Computer simuliert werden.12 Der LT gilt bis heute als Meilenstein auf dem Weg zur Entwicklung der Künstlichen Intelligenz. Rückblickend bezeichnet Simon die Jahre 1955 und 1956 als die wichtigsten in seinem Leben als Wissenschaftler (vgl. Simon 1991: 198ff.). Etwa zur selben Zeit arbeitet er zusammen mit James March und Harold Guetzkow an dem Buch Organizations (March & Simon 1958), das als eine Fortsetzung und Erweiterung von Administrative Behavior (Simon 1947) anzusehen ist. Dieses zweite organisationstheoretische Hauptwerk entsteht in der Zeit, in der Simon als Professor am Carnegie Institute of Technology in Pittsburgh an einem Forschungsprojekt der Graduate School of Industrial Administration (GSIA) arbeitet.13 Die interdisziplinäre Graduiertenschule hat Simon maßgeblich in den 1950er Jahren mit aufgebaut. „Carnegie both molded Simon

dungsverhalten. Bereits zu diesem Zeitpunkt schlug er eine Brücke zwischen der ökonomischen Theorie und seiner Theorie begrenzter Rationalität (vgl. 1991: 82). 12

KI gilt als multidisziplinäres Forschungsgebiet. Teilweise wird KI näher an die Disziplin der Informatik gerückt. Sie widmet sich einerseits der Entwicklung von Programmen zur Bearbeitung von Problemen, deren Lösungen menschliche Intelligenz voraussetzen. Andererseits wird sie als Anwendungsgebiet der (Kognitions-)Psychologie beschrieben. KI wird dann definiert als die Erforschung menschlicher Intelligenz mithilfe von Computermodellen.

13

Die an der GSIA beteiligten Sozialwissenschaftler hatten keinerlei Managementausbildung oder vergleichbare Berufsausbildung. Sie hielten die amerikanische Berufsausbildung im Bereich der Wirtschaft jedoch für unterentwickelt und wollten die Managementausbildung professionalisieren und wissenschaftlich fundieren. Es gab zwei Schwerpunkte: Organizational Behavior und Quantitative Management Science.

126 | D AS P ROJEKT SAP

and was molded by him“ (Augier & March 2004: 15).14 In diesem intellektuellen Umfeld entsteht mit A Behavioral Theory of the Firm von Richard Cyert und James March (1963) ein weiterer Klassiker der modernen Organisationsforschung. Nach Organizations widmet sich Simon nur noch gelegentlich organisationstheoretischen Fragestellungen. Er wendet sich primär der KI-Forschung und den Computerwissenschaften zu. „For me, there was no question of turning back to my earlier interesting, but much less exciting, research on organizational decision making. In computer programming languages, I found tools that classical mathematical languages had not provided for exploring the processes of human thinking and for attaining accuracy and rigor in the behavioral and social sciences.“ (Simon 1991: 214)

Die Verwendung des Programmbegriffs, die im folgenden Kapitel vorgestellt wird, ist ein Beispiel dafür, wie Simon Erkenntnisse aus der KI-Forschung auf seine organisationstheoretischen Überlegungen überträgt bzw. er diese miteinander verknüpft. 4.3.2 Entscheidungsprogramme in Organisationen Entscheidungen werden in Organisationen auf die Schultern vieler Individuen (decision maker) verteilt. Der Output von A wird zum Input für B, B verlässt sich auf die Richtigkeit der Entscheidung von A und kann sich so auf seine Entscheidung konzentrieren. Die Entscheidung von B wird wiederum zum Input für C usw. (vgl. Simon 1997: 25). Grundlegend für solche Entscheidungsketten sind das Wissen und die Kompetenzen einzelner Organisationsteilnehmer. Das Wissen einer Organisation steckt aber nicht nur in den Köpfen von Individuen, sondern in den Entscheidungsprogrammen der Organisation. Simon entlehnt den Programmbegriff aus der Informatik, verwendet ihn organisationstheoretisch jedoch in einem weiteren Sinne. „I have borrowed the term program from the computer trade, and intend it in the sense in which it is used there. A program is a detailed prescription or strategy that governs the sequence of responses of a system to a complex task environment. Most of the programs that govern organizational response are not as detailed or as precise as computer programs.

14

Er blieb dort bis zu seinem Tod im Jahr 2001. Die private Forschungsuniversität firmiert mittlerweile unter dem Namen Carnegie Mellon University.

D IE

STANDARDISIERTE

S OFTWARE

| 127

However, they all have the same intent: to permit an adaptive response of the system to the situation.“ (Simon 1960: 6)

Anfang der 1960er Jahre entwickelt er mit Alan Newell ein zweites KIProgramm, mit dem kognitive Problemlösungsprozesse auf dem Computer simuliert werden können. Die Grundlage für den General Problem Solver (GPS) bilden Protokolle über sogenannte Thinking-Aloud-Test. Für solche Protokolle müssen Versuchspersonen während der Bearbeitung von Aufgaben Auskunft darüber geben, was sie gerade denken und welche Teilaufgabe sie gerade bearbeiten (vgl. Ericsson & Simon 1980). Simon beschreibt den GPS folgendermaßen: „It is called GPS not because it can solve any kind of problem – it cannot – but because the program itself makes no specific reference to the subject matter of the problem. GPS is a program that can reason in terms of means and ends about any problem that is stated in a certain general form.“ (Simon 1960: 27)

Das generelle Problemlösungsverfahren, das mit dem GPS simuliert werden soll, beschreibt Simon an einem einfachen Beispiel: Beim Zelten im Wald stellen wir fest, dass wir einen Tisch benötigen. Wir fragen uns, wie das Problem gelöst werden kann, einen Tisch im Wald zu beschaffen? Benötigt wird eine flache horizontale Oberfläche aus Holz. Wir fragen uns, was der Unterschied ist zwischen dem, was wir benötigen, und dem, was wir bereits haben. Bäume, die um uns herum sind, sind hochgewachsen, vertikal und zylinderartig aus Holz und im Boden verwurzelt. Hingegen handelt es sich bei einem Tisch um eine kleinere, horizontale und bewegliche Fläche aus Holz. Es gibt also Unterschiede in der Beweglichkeit, Größe und Beschaffenheit zwischen dem, was wir haben, und dem, was wir benötigen. Wir fragen uns, welche Werkzeuge uns zur Verfügung stehen, um diese Unterschiede zu reduzieren. Um einen Baum von seinen Wurzeln im Boden abzutrennen. Verfügen wir bspw. über Äxte? Wenn wir über eine Axt verfügen, können wir das das erste Subproblem unseres Problems zu lösen, nämlich ein Objekt, das fest mit dem Untergrund verbunden ist, in ein Objekt zu verwandeln, das davon losgelöst ist (vgl. ebd.). Ein Problem kann dann gelöst werden, wenn das Ziel definiert und Unterschiede zwischen Soll- und Ist-Zustand ermittelt werden. Die verfügbaren Mittel werden danach so eingesetzt, dass der zuvor bestimmte Unterschied zwischen Soll- und Ist-Zustand reduziert werden kann. Ein zentraler Aspekt des beschriebenen Problemlösungsverfahrens ist die Unterteilung in Teilprobleme. Dieses Vorgehen bzw. Verfahren entspricht der Funktionsweise von Organisationen,

128 | D AS P ROJEKT SAP

wie sie Simon auch in seinen organisationstheoretischen Arbeiten beschrieben hat. Gesamtziele der Organisation werden in Teilziele zerlegt und so aufeinander abgestimmt, dass sie zum Erreichen des zuvor definierten Gesamtziels beitragen. Die Erkenntnisse der verhaltenswissenschaftlichen Entscheidungstheorie überträgt Simon in The New Science of Management Decision (1960) auf die Verwendung elektronischer Datenverarbeitungstechnik in Organisationen. Er unterscheidet zwischen programmierten und nicht-programmierten Entscheidungen in Organisationen. In Organisationen, so vermutet Simon, werden nicht-programmierte Entscheidungen durch programmierte Entscheidungen zunehmend verdrängt. Programmierte Entscheidungen haben den Vorteil, dass sie die Koordination in Organisationen erleichtern und zur Stabilisierung der Organisation beitragen. Programmierte Entscheidungen können die Organisation gegenüber ihrer Umwelt jedoch unflexibel machen, wenn sie dann getroffen werden, wenn eigentlich nicht-programmierte Entscheidungen angemessen wären. Damit sind Entscheidungen für einmalige und schlecht strukturierte Probleme oder Grundsatzentscheidungen gemeint. Geeignete Entscheidungstechniken subsumiert Simon unter Begriffe wie „Urteilsvermögen“, „Intuition“ und „Kreativität“ (ebd.). Auch Faustregeln stellen für ihn zulässige Verfahren dar, mit deren Hilfe nicht-programmierte Entscheidungen getroffen werden können. Simon ergänzt diese traditionellen Entscheidungstechniken mit modernen Entscheidungstechniken. Darunter versteht er eine professionelle Managementausbildung und den Einsatz computergestützter heuristischer Verfahren. In diesem Zusammenhang erwähnt er auch das von ihm und Newell entwickelte Programm GPS (vgl. Simon 1960: 8, 29). In die Kategorie der programmierten Entscheidungen fallen traditionell Gewohnheiten, Routinen und standardisierte Arbeitsabläufe. Den Organisationsmitgliedern werden bestimmte Informationen zur Verfügung gestellt und Ziele und Erwartungen so vermittelt, dass sie in ihre Entscheidungen im Arbeitsalltag einfließen. Organisationsstrukturen entlasten die Mitglieder teilweise sogar vollständig von jeder individuellen rationalen Wahl, weil sie nur Regeln anwenden und Programme ausführen. In der Organisationspraxis werden diese traditionellen Entscheidungstechniken nun durch moderne Entscheidungstechniken ergänzt. Darunter fasst Simon EDV-Techniken und Verfahren des Operations Research, die zur Erhöhung der Qualität von Entscheidungsprozessen in Organisationen beitragen. Seine optimistische Einschätzung des Nutzens von Computern in Unternehmen relativiert Simon in seinen späteren Arbeiten. Die anfängliche Begeisterung für moderne Datenverarbeitungstechniken, so Simon in einer Neuauflage von Administrative Behavior in den 1980er Jahren, sei schon bald einer großen Ernüchterung gewichen.

D IE

STANDARDISIERTE

S OFTWARE

| 129

„[D]ie bloße Existenz einer Vielzahl von Daten ist kein hinreichender Grund, sie in einem einzigen, umfassenden Informationssystem zu sammeln. Das Problem liegt tatsächlich genau in der entgegengesetzten Richtung: Es ist ein Verfahren zur Zerlegung von Entscheidungsproblemen zu finden, so daß die verschiedenen Komponenten jeweils ihren relevanten Datenquellen zugeordnet werden können.“ (Simon 1981: 307)

Implizit weist Simon an dieser Stelle auf die praktische Bedeutung der verhaltenswissenschaftlichen Entscheidungstheorie hin. Er ist zwar der Überzeugung, dass „[m]it der schnellen Entwicklung der Informationsverarbeitungstechnologie Entscheidungsprozesse in Organisationen sehr viel anspruchsvoller und rationaler [werden] als sie es in der Vergangenheit waren“ (ebd.: 317). Um Organisationen mittels moderner IT gestalten zu können, so Simon, „muß [zuerst] eine Analyse des Entscheidungssystems und seines Datenbedarfs stattfinden; erst dann kann ein begründeter Versuch unternommen werden, die Datensysteme zu definieren, die den Entscheidungsprozeß unterstützen können“ (ebd.). Im nächsten Kapitel wird auf die Systemperspektive eingegangen, die Simons entscheidungstheoretischen Ansatz für eine Theorie der Organisation zugrunde liegt. 4.3.3 Die Systemperspektive Üblicherweise wird Simon nicht als Repräsentant eines systemtheoretischen Ansatzes in der Organisationsforschung betrachtet.15 Simons Systembegriff ist dafür wohl zu vage. Darüber ist sich Simon selbst im Klaren, wenn er die Bedeutung von Operation Research-Methoden für das Entscheidungsverhalten in Organisationen beschreibt: „Along with some mathematical tools operations research brought into management decision making a point of view called systems approach. The systems approach is no easier to define than operations research for it is a set of attitudes and a frame of mind rather than a definite and explicit theory. At its vaguest, it means looking at the whole problem [...]. Somewhat more concretely, it means designing the components of a system and making individual decisions within it in the light of the implications of these decisions for the system as a whole [...].“ (Simon 1960: 15)

Simon unterscheidet hier zwischen dem Ganzen des Systems und seinen Teilen bzw. Komponenten. Die Teile sind „individual decisions“ (ebd.), die durch das Systemdesign in eine Beziehung zum Ganzen gesetzt werden. Simon verwendet

15 Eine Ausnahme ist die Arbeit von Prewo et al. (1973: 222ff.).

130 | D AS P ROJEKT SAP

also eine implizite Definition des Systembegriffs. Zentrale Komponente ist der Begriff des Systemdesigns. Der Begriff „designing“ (ebd.) steht für jede Form zielgerichteter Aktivität, die die Differenz zwischen einem Ist- und einem SollZustand überbrücken soll. Nicht nur Ingenieure, sondern auch Manager, Architekten, Ärzte und Politiker arbeiten in für Simon typischen Professionen, die sich in diesem Sinne mit dem Design von Systemen befassen (vgl. Simon 1969: 111). Das Management einer Organisation hat die Aufgabe, Organisationsstrukturen so zu gestalten, dass sie ihre Mitglieder sowohl mit sachlichen Informationen als auch mit Wertprämissen ausstatten, die es ihnen ermöglichen, organisatorisch rationale Entscheidungen zu treffen. Zwar ist eine rationale Wahl zwischen verschiedenen Zielen im Allgemeinen nicht möglich, die Wahl verschiedener Mittel, um ein gegebenes Ziel zu erreichen, hingegen schon. Die Führung einer Organisation hat deshalb die Aufgabe, Ziele für die Mitglieder der darunter liegenden Organisationsebenen festzulegen und die notwendigen Entscheidungen auf die Wahl der Mittel zu beschränken. Allerdings gibt es, so Simon, keine Garantie dafür, dass die getroffenen Entscheidungen optimal für das organisatorische Gesamtziel sind. In der Organisationspraxis werden befriedigende Lösungen für ein oder mehrere Teilprobleme gesucht. Das Prinzip des satisficing16 erläutert er an einem konkreten Beispiel. „Beispielsweise können Plankosten als Beschränkungen für einen Betriebsleiter gesetzt werden. Sollte er feststellen, daß seine Maßnahmen diesen Beschränkungen nicht genügen, so wird er nach Möglichkeiten suchen, um seine Kosten zu senken. Größere Fertigungslose können ihm als Mittel zur Erreichung dieses Zwecks geeignet erscheinen. Größere Fertigungslose kann er erreichen, wenn die Anzahl der Produktionsvarianten verkleinert wird; deshalb schlägt er eine Produktstandardisierung als Lösung seines Kostenproblems vor. Vermutlich wird er diese Lösung aber nicht durchführen, bevor er sie anhand der durch die Absatzteilung eingeführten Beschränkungen geprüft hat. Mögliche Einwände sind, daß die Weigerung, spezielle Kundenwünsche zu erfüllen, zu Absatzeinbußen führen wird.“ (Simon 1981: 286)

Während sich Organisationswissenschaftler und Organisationswissenschaftlerinnen damit zufriedengeben könnten, die Organisation als Entscheidungssystem zu analysieren, sollten laut Simon Manager dazu in der Lage sein, die Ergebnisse des Gesamtsystems auf der Grundlage eines oder mehrerer Organisationsziele zu bewerten und entsprechend zu verändern. Insofern übernimmt ein Manager also

16

Der Begriff setzt sich zusammen aus den englischen Wörtern satisfying (befriedigend) und suffice (genügen).

D IE

STANDARDISIERTE

S OFTWARE

| 131

die Aufgaben eines Systemdesigners. Dem Manager soll mit der verhaltenswissenschaftlichen Entscheidungstheorie ein Werkzeug zur Analyse von Entscheidungsprozessen in Organisationen und der zweck- und zielgerichteten Anpassungen dieser Entscheidungsprozesse an die Hand gegeben werden. Mit Simon kann man zu der Einsicht gelangen, dass sich Softwareberater nicht nur als Systemdesigner, sondern auch als Organisationsforscher betätigen sollten. Diese Einschätzung teilt Bettina Heintz (1995), wenn sie in einem Beitrag zum Verhältnis von Informatik und Soziologie die folgende Frage formuliert: „Ist die Informatik eine formale Wissenschaft, eine Ingenieurswissenschaft oder eine Sozialwissenschaft? Geht es in der Informatik um formale Symbolmanipulation, um die Implementation von formalen Strukturen oder um das Verstehen von sozialen Prozessen? Oder vielleicht um alles zusammen?“ (Ebd.: 15).

Bemühen sich SAP-Berater um das „Verstehen von sozialen Prozessen“ (ebd.) und betätigen sie sich in diesem Sinne als Organisationsforscher? Softwareberater, so werde ich im zweiten Teil des Buches zeigen, beschäftigen sich primär damit, wie Organisationen sein sollen und weniger damit wie sie sind. Bei der Implementierung einer Standardsoftware wie SAP geht es nicht primär um die Analyse eines Entscheidungssystems und seines Datenbedarfs. Es geht vor allem um die (Re-)Modellierung von Arbeitsabläufen. Die neoinstitutionalistische Organisationstheorie bot in TEIL A den primären organisationstheoretischen Bezugsrahmen. Die für den neoinstitutionalistischen Ansatz grundlegenden Konzepte – Legitimität, Strukturangleichungsmechanismen und Organisationsfeld – waren instruktiv, um die Softwareverbreitung und den Erfolg des Organisationsmodells der Software aus einer soziologischen Perspektive zu erklären. Die Innenwelt von Organisationen kam dabei allerdings nur unzureichend in den Blick. Um die faktischen Verhältnisse in Organisationen untersuchen zu können, müssen nämlich auch Strukturen jenseits der formalen Strukturen einer Organisation in die soziologische Analyse einbezogen werden. Für die Untersuchung der Integration der Technik in Organisationen wird der systemtheoretische Ansatz von Niklas Luhmann grundlegend sein. Luhmann bezieht sich in seinen organisationstheoretischen Beiträgen maßgeblich auf die Arbeiten von Simon bezieht. Im Gegensatz zu Simon kappt er jedoch die ingenieurtechnischen Wurzeln seiner organisationstheoretischen Konzepte.

B. Die individualisierte Software: Die Integration der Technik I

5. Der systemtheoretische Untersuchungsrahmen: Luhmanns organisationssoziologische Konzepte

Im Zentrum der Theorie organisierter Sozialsysteme von Niklas Luhmann steht der Begriff der Unsicherheitsabsorption. Er tritt an die Stelle der Zweckorientierung und ersetzt damit ein wesentliches Prinzip der traditionellen Organisationstheorien (vgl. Luhmann 2000: 184). Die Zweck-Kategorie spielt in der systemtheoretischen Organisationssoziologie nur noch eine untergeordnete Rolle. Diesen Paradigmenwechsel kommentiert Luhmann (2005a: 57) folgendermaßen: „Jedermann orientiert sein Handeln, wenn er es rational explizieren und verständlich machen will, an Zwecken und begründet es als geeignetes Mittel. Aber ihre einstige Geltung als letzter Bezugspunkt für wissenschaftliche Analysen des Handelns hat die ZweckKategorie eingebüßt.“

Trotzdem wird in der systemtheoretischen Organisationsforschung nicht gänzlich auf die Zweck-Kategorie verzichtet. Sie wird als eine durch die Organisation selbst konstituierte Variable in die Untersuchung wieder eingeführt (vgl. Luhmann 1977: 126ff.). Zwecke sind programmatische Festlegungen, über die eine Organisation selbst entscheidet. Wenn und solange Zwecke vorhanden sind, strukturieren sie die Entscheidungen in einer Organisation (ebd.: 257ff.). Sie ermöglichen es der Organisation, sich auf gewisse Ziele zu konzentrieren und andere auszublenden. Faktisch wechseln Organisationen jedoch zwischen verschiedenen Zwecken und Zielen, auch scheinbar priorisierte Zwecke und Ziele ändern sich.1 Typische Unternehmenszwecke wie Gewinnmaximierung, Profita-

1

Je nach Typ kann der Zweck einer Organisation stark variieren, was insbesondere auch von ihrer Finanzierung abhängt. Unternehmen finanzieren sich über den Verkauf

136 | D AS P ROJEKT SAP

bilität und Kundenzufriedenheit sind bloß abstrakte Verhaltenserwartungen und Werte. Sie lassen offen, was in einer konkreten Situation von den Organisationsmitgliedern eigentlich erwartet wird. Die Möglichkeit, Zwecke nach Außen in verschiedener Weise darzustellen, hilft Unternehmen und anderen Organisationen mit widersprüchlichen Umwelterwartungen umzugehen. Luhmann erklärt Zwecke deshalb zu einem wichtigen Bestandteil der Organisationsfassade, die der „Darstellung des Systems für Nichtmitglieder“ (1964a: 108) dient.2 Aus diesem Grund überrascht es nicht, dass die Darstellung der Softwareimplementierung in den von mir geführten Interviews – zumindest zu Beginn der Interviewsituation – eng an Organisationszwecke gekoppelt werden. So wird die Einführung von SAP beispielsweise als Mittel zur Erhöhung der Kundenorientierung des Unternehmens thematisiert.3 Die Leistungsfähigkeit der Systemtheorie für ein soziologisches Verständnis moderner Datenverarbeitungstechniken in Organisationen schätzte Luhmann in seinen vor über 40 Jahren erschienenen Arbeiten eher pessimistisch ein. „Reduktion von Komplexität auf entscheidungsfähige Problemgrößen war [...] bisher das kritische Organisationsproblem [...]. Was geschehen kann, wenn dieses Definieren und Umdefinieren und Aufsplitten und Kleinarbeiten der Probleme auf neuartige Methoden umstellt, als Gesamtprozess konstruiert und konsequent rationalisiert, ja nach Möglichkeit auf Maschinen übertragen wird, ist selbst mit ungemilderter Spekulation nicht erfassbar.“ (Luhmann 1977: 256)

Die relationale Datenbanktechnik und die EPK-Methode zählen sicher zu den wichtigsten „neuartige[n] Methoden“, mit denen heute versucht wird, „Gesamtprozess[e] [zu] konstruier[en] und konsequent [zu] rationalisier[en]“ (ebd.). In

ihrer Produkte und Dienstleistungen. Andere Organisationstypen hingegen finanzieren sich über Mitgliederbeiträge oder Alimentierungen, was wesentlich ihre Zwecksetzung bestimmt. Kirchen, Schulen, Universitäten, Verwaltungen und Vereine besitzen im Vergleich zu Unternehmen deshalb keine so hohe Entscheidungsautonomie hinsichtlich ihrer Zwecksetzung (vgl. Kette 2012: 26). 2

Für das alltägliche Organisieren sind Programme entscheidender. In seiner posthum veröffentlichten Aufsatzsammlung Organisation und Entscheidung (2000) wird die Zweckkategorie in Gestalt des Begriffs Entscheidungsprogramme eingeführt. Luhmann unterscheidet zwischen Zweckprogrammen und Konditionalprogrammen. Vergleiche hierzu die Erläuterungen in KAPITEL 5.2 „Entscheidungen und Entscheidungsprämissen“.

3

Siehe hierzu das KAPITEL 4.1 „SAP und andere Managementkonzepte“.

D IE

INDIVIDUALISIERTE

S OFTWARE

| 137

diesem Buch sind die Softwareberatung und das Projekt der Implementierung von SAP-Software Schauplatz für Rationalisierungsversuche von Organisationen, wie sie Luhmann aus einer systemtheoretischen Perspektive auf einer eher abstrakten Ebene beschrieben hat. Für die empirische Untersuchung dieser Schauplätze schlage ich eine systemtheoretische Rahmung vor, die „das-so-undauch-anders-möglich-sein“ der Integration der Software nicht auf einzelne Personen, sondern auf die Eigenlogik der Organisation zurückführt, die sich für die Einführung von SAP entschieden hat. Auf den folgenden Seiten wird zunächst die Idee der Eigenlogik sozialer Systeme im organisationstheoretischen Werk von Niklas Luhmann vorgestellt. Dies soll anhand einer Auswahl grundlegender Begriffe und Konzepte erfolgen: 1) Unsicherheitsabsorption, 2) Entscheidungsprämissen und 3) Kommunikation.

5.1 U NSICHERHEITSABSORPTION DER O RGANISATION

UND DIE

E IGENLOGIK

Bevor die Standardsoftware implementiert und verwendet werden kann, wird die Software selbst zum Gegenstand von Entscheidungen. Softwareberater und ausgewählte Organisationsmitglieder entscheiden darüber, inwieweit das abstrakte Organisationsmodell der Software an organisationsspezifische Gegebenheiten und Anforderungen angepasst werden soll. Aus einer systemtheoretischen Perspektive geht es dabei nicht um die Durchsetzung von Interessen einzelner Personen oder von Personengruppen. Es existieren im kommunikativen Geschehen der Projektarbeit keine Intentionen oder Motive, sondern nur Kommunikation, an die weitere Kommunikation anschließt und die auf vorhergehender Kommunikation aufbaut. Die formalen Strukturen einer Organisation spielen dabei eine zentrale Rolle. Um diese Strukturen beschreiben zu können, wird auf den folgenden Seiten ein systemtheoretisches Begriffsrepertoire vorgestellt. Zunächst soll das für die systemtheoretische Organisationsforschung grundlegende Konzept der Unsicherheitsabsorption expliziert werden. Luhmann gelingt es, seine skeptische Einstellung gegenüber Versuchen der gezielten Steuerung komplexer sozialer Zusammenhänge organisationstheoretisch zu begründen. Entscheidungen in der Organisation bleiben kontingent, d. h., sie können in einer gegebenen Situation „so-aber-auch-anders“ ausfallen (vgl. Martens & Ortmann 2014: 408). Luhmann rückt die Bedeutung der Eigenlogik von Organisationen ins Zentrum seiner soziologischen Analysen. Sein genuin soziologisches Konzept der Unsicherheitsabsorption entwickelt er im An-

138 | D AS P ROJEKT SAP

schluss an die verhaltenswissenschaftliche Entscheidungstheorie von Simon und anderen Autoren. „Gemeinsam ist diesem Interesse [für das Entscheiden: H. M.] eins: der erwachte Sinn für die Überforderung des Menschen durch die Welt. Dadurch ergibt sich ein zunehmend bewußtes Bedürfnis für [...] Prozesse der Reduktion von Komplexität.“ (Luhmann 2005b:103).

In diesem Zitat formuliert Luhmann das Kernargument seiner allgemeinen Theorie sozialer Systeme: Alle sozialen Systeme zeichnen sich durch die Fähigkeit aus, die Komplexität der Welt durch die Bildung von Strukturen zu reduzieren. Komplexitätsreduktion wird auf unterschiedliche Weise hergestellt, da verschiedene Systeme auch mit verschiedenen Arten von Komplexität konfrontiert sind. Organisationen gelingt die Komplexitätsreduktion beispielsweise über die Differenzierung von Entscheidungszuständigkeiten. Die Bündelung des Informationspotenzials entlastet an einer Stelle von der Verantwortung, passende Informationsquellen selbst auswählen zu müssen. In Organisationen wird unterstellt, dass eine Information zutrifft, wenn sie von der zuständigen Stelle kommt. Komplexitätsreduktion in Organisationen basiert letztlich auf Fiktionen: „[e]twa [auf der] Fiktion, dass der Sachverständige kompetent war, dass die Kundenberatung durch Firmen eine ausreichende Entscheidungsgrundlage bietet oder dass Konsens erreicht war, wenn einer Entscheidung zugestimmt wurde“ (Luhmann 2000: 189). Angesichts der Vielzahl von möglichen Entscheidungsalternativen tragen Organisationsstrukturen dazu bei, Komplexitäten und Unsicherheiten bezüglich der richtigen Entscheidung in Organisationen zu absorbieren und die zur Verfügung stehenden Wahlmöglichkeiten für Organisationsmitglieder erheblich einzuschränken. Den Begriff der Unsicherheitsabsorption übernimmt Luhmann von March und Simon, die den Begriff in Organizations (1958) verwenden. Die spezifisch systemtheoretische Adaption des Grundbegriffs erläutert Luhmann in Organisation und Entscheidung (2000: 184f.). „Sie [Unsicherheitsabsorption: H. M.] findet [...] hauptsächlich in sozialen Beziehungen statt, nämlich immer dann, wenn eine Entscheidung sich an einer anderen orientiert. Es ist nur eine andere Form des Sachverhalts, wenn man Organisationen als Systeme beschreibt, in denen Entscheidungen andere Entscheidungen beobachten. Der Begriff der Unsicherheitsabsorption beschreibt, anders gesagt, die Sukzession von Entscheidungen, den Entscheidungsprozess. Die Unsicherheitsabsorption ist also in den Entscheidungsprozess selbst eingebaut, sie ist nichts anderes als ein Erfordernis seiner Sequenzialität.“

D IE

INDIVIDUALISIERTE

S OFTWARE

| 139

Aus einer systemtheoretischen Perspektive findet Unsicherheitsabsorption immer dann statt, wenn sich eine Entscheidung an einer anderen Entscheidung in der Organisation ausrichtet. Unsicherheitsabsorption passiert, sobald Entscheidungen als Entscheidungsprämissen akzeptiert werden (vgl. Luhmann 1993: 299). Durch diese Form der Verknüpfung von Entscheidungen gelingt es Luhmann, organisationstheoretisch zu begründen, wie sich die Organisation selbst als emergente Ordnung und soziales System hervorbringt. Alles, was für den Bestand von Organisationen wichtig ist, wird zum Gegenstand von Entscheidungen. „Alles andere – Ziele, Hierarchien, Rationalitätschancen, weisungsgebundene Mitglieder, oder was sonst als Kriterium angesehen worden ist – ist demgegenüber sekundär und kann als Resultat der Entscheidungsoperationen des Systems angesehen werden. Alle Entscheidungen des Systems lassen sich mithin auf Entscheidungen des Systems zurückführen.“ (Luhmann 2000: 63)

In einer Reihe organisationstheoretischer Beiträge untersucht Luhmann das Problem der Unsicherheitsabsorption und die Problemlösung durch die Bildung von formalen und informalen Organisationsstrukturen. In früheren Arbeiten bezeichnet er seinen Untersuchungsansatz als funktionalen Strukturalismus oder Äquivalenzfunktionalismus und grenzt sich so von Talcott Parsons (Parsons 1951) und dessen Strukturfunktionalismus ab. Dieser dominierte die Soziologie bis in die 1960er Jahre (vgl. Luhmann 1967: 616ff.; Stichweh 2011). Aus Parsons’ Perspektive wird nach den Funktionen gefragt, die von Strukturen erbracht werden müssen, um den Systembestand zu sichern. Luhmann hingegen ordnet den Strukturbegriff dem Funktionsbegriff unter. Nicht die Bestandserhaltung ist für ihn oberstes Bezugsproblem der soziologischen Analyse. Auch geht er nicht davon aus, dass soziale Systeme stets über ein verbindliches, kollektiv geteiltes Norm- und Wertemuster verfügen. Stattdessen begreift Luhmannn Komplexität als das soziologische Problem schlechthin. Komplexitätsreduktion wird dann zum abstrakten Bezugsproblem, das Organisationen und alle anderen sozialen Systeme betrifft. Die Lösung dieses Problems liegt in der Bildung sozialer Systeme und ihrer jeweiligen Strukturen. Luhmann verwandelt auf diese Weise Parsons’ funktionalistische Theorie in eine funktionale Methode (vgl. Luhmann 1964b).4 In Soziale Systeme. Grundriß einer allgemeinen Theorie expliziert er diese Methode:

4

Vergleiche hierzu die Ausführungen in Luhmann as Organization Theorist (Seidl & Mormann 2014: 128ff.).

140 | D AS P ROJEKT SAP „Die funktionale Analyse benutzt Relationierungen mit dem Ziel, Vorhandenes als kontingent und Verschiedenartiges als vergleichbar zu erfassen. Sie bezieht Gegebenes, seien es Zustände, seien es Ereignisse, auf Problemgesichtspunkte, und sucht verständlich und nachvollziehbar zu machen, daß das Problem so oder auch anders gelöst werden kann. Die Relation von Problem und Problemlösung wird dabei nicht um ihrer selbst willen erfasst; sie dient vielmehr als Leitfaden der Fragen nach anderen Möglichkeiten, als Leitfaden der Suche nach funktionalen Äquivalenten [...]. Die Ergiebigkeit der funktionalen Methode und der Erklärungswert ihrer Resultate hängen davon ab, wie die Beziehung zwischen Problem und möglicher Problemlösung spezifiziert werden kann.“ (Luhmann 1984: 83f.)

Am Beispiel von Hierarchien in Organisationen soll das Prinzip der funktionalen Analyse illustriert werden. Die Hierarchie in einer Organisation kann mehrere Funktionen erfüllen. Wenn man sagt, Hierarchien in Unternehmen sollen flach sein und dies damit begründet, dass Entscheidungen rascher getroffen werden können, dann heißt das, dass die Funktion der Hierarchie, wie sie hier gesehen wird, ein Transportnetz für Informationen ist. Hierarchien können jedoch auch als Karrierefaktoren von großer Bedeutung sein. Da man in flachen Hierarchien nicht weit aufsteigen kann, sind es andere Strukturen, wie die Entsendung an ausländische Standorte, die die Hierarchien als Karrierefaktor ersetzen.5 Hierarchien gelten neben Zwecken als konstitutive Merkmale von Organisationen. In den Sozialwissenschaften war es lange Zeit üblich, Organisationen entweder als Zweckverband (Zweckmodell der Organisation) oder als eine hierarchische Ordnung (Befehlsmodell der Organisation) zu betrachten. Luhmann führt die klassischen Organisationsmerkmale, Zwecke bzw. Ziele und Hierarchie, hingegen als gleichrangige Strukturmerkmale in den systemtheoretischen Ansatz der Organisationsforschung ein. Außerdem fügt er mit der Kategorie Personal eine drittes Strukturmerkmal hinzu (vgl. Luhmann 2000: 256ff., 279ff., 302ff.). Im folgenden Kapitel soll mit der Trias Entscheidungsprogramme, Kommunikationswege und Personal ein Schema vorgestellt werden, das sich für die organisationssoziologische Beschreibung und Analyse der Softwareimplementierung besonders gut eignet.

5

Die funktionale Analyse wird beispielsweise von Hendrik Vollmer (2004) auf den Fall des organisierten Rechnens angewendet.

D IE

5.2 E NTSCHEIDUNGEN

UND

INDIVIDUALISIERTE

S OFTWARE

| 141

E NTSCHEIDUNGSPRÄMISSEN

Die Einführung von SAP-Software ist von einem systemtheoretischen Standpunkt aus betrachtet ein Organisationsprojekt par excellence. Schließlich wird mit den betriebswirtschaftlichen Anwendungsprogrammen der Software ein abteilungsübergreifendes Entscheidungsprogramm in Unternehmen eingeführt. Arbeitsaufgaben in verschiedenen Bereichen werden dadurch strukturiert und Arbeitsabläufe abteilungs- und standortübergreifend stärker miteinander verzahnt. Mithilfe von Anwendungsprogrammen und dem jeweiligen Berechtigungskonzept für die Softwareverwendung werden Absprachen zwischen Abteilungen, zwischen Vorgesetzten und Untergebenen, zwischen Kollegen sowie zwischen zentralen und dezentralen Organisationseinheiten stärker verregelt und teilweise automatisiert. Damit die Softwareoberfläche von Organisationsmitgliedern jedoch bedient und Auswertungen angestoßen werden können, müssen Schulungskonzepte ausgearbeitet, mitunter sogar neues Personal mit entsprechender Qualifikation eingestellt werden. Die Programmstruktur einer Organisation, verstanden als Gesamtheit von Entscheidungsprogrammen, stellt regulative Bedingungen für richtige und fehlerhafte Entscheidungen für Organisationsmitglieder zur Verfügung. Hierbei werden Zweck- und Konditionalprogramme voneinander unterschieden: Zweckprogramme zielen auf einen bestimmten Output, Konditionalprogramme begrenzen bei einem bestimmten Input den Spielraum für richtiges Entscheiden. EDVSysteme, betriebswirtschaftliche Zielsysteme oder Dienstanweisungen gehören zu typischen Entscheidungsprogrammen in Organisationen. Software wie SAP und elektronische Datenverarbeitungssysteme generell sind für Organisationen allerdings nicht per se Entscheidungsprogramme. Damit sie als Entscheidungsprämisse zum Tragen kommen, müssen sie auch operativ verwendet werden. Konkurrierende Entscheidungsprogramme in Organisationen verunmöglichen es mitunter, dass die Software überhaupt als Entscheidungsprämisse für weitere Entscheidungen fungieren kann. Identifiziert der Organisationsforscher die Software vorschnell mit einem Entscheidungsprogramm, verschenkt er die Möglichkeit, Software als Informationsquelle für die Organisationsanalyse zu nutzen. Dafür ist ein weiterer Typ von Entscheidungsprämissen instruktiv. Über Kommunikationswege legt eine Organisation fest, wie organisatorisch verbindliche Entscheidungen getroffen werden. Wer an welchen Entscheidungen beteiligt wird und welche Dienstwege einzuhalten sind, wird über die Einrichtung von Kommunikationswegen festgelegt. In Organisationen kommen unterschiedliche Formen der Regelung von Kommunikationswegen vor. Hierarchien legen beispielsweise fest, wer wem Bericht erstattet. Die Aufgabenteilung sieht

142 | D AS P ROJEKT SAP

vor, wer was bearbeitet und die Informationswege, wer wen informiert. Mitzeichnungsrechte stehen für Kommunikationswege, die an die Gleichrangigkeit beteiligter Stellen geknüpft sind. Ein weiteres Beispiel für die Einrichtung zusätzlicher Kommunikationswege in Organisationen ist das Projekt. Da die Softwareimplementierung im Projektmodus organisiert wird, werde ich darauf noch genauer eingehen.6 Durch das Personal werden Entscheidungen in einer Organisation ebenfalls vorstrukturiert. Idealerweise werden Personen nicht deshalb zu Mitgliedern einer Organisation, weil sie besonders gemocht werden, sondern weil sie für bestimmte Aufgaben Qualifikationen mitbringen. Durch Personalrekrutierung legt das Management einer Organisation fest, wer dazu gehört und wer nicht. Organisationen haben darüber hinaus über Versetzungen und Entlassungen die Möglichkeit, die Personalstruktur zu verändern. Fragen der Personalverwaltung haben Luhmann zufolge lange Zeit im Schatten der anderen Formen von Entscheidungsprämissen gestanden. Die Unterordnung von Personalfragen habe zu Fehleinschätzungen geführt. „[...] Organisationspläne und Aufgabenbeschreibungen“, so Luhmann (2000: 280), „lassen sich leicht, praktisch mit einem Federstrich ändern. Dagegen ist das Agglomerat von individuellen Selbsterwartungen und Fremderwartungen, das als ‚Person‘ identifiziert wird, schwer, wenn überhaupt umzustellen.“ Demzufolge werden Weiterbildung und andere Personalentwicklungsmaßnahmen als Möglichkeiten zur Veränderung in Organisationen oft überschätzt. Ob und wie die Standardsoftware implementiert und verwendet wird, beeinflussen Personen und ihr Wissen in einem hohen Maße, Es ist also entscheidend, welche Mitarbeiter als Key-User in das Organisationsprojekt der Softwareimplementierung involviert sind. Ob „Leute, die vor 40 Jahren Buchhalter gelernt haben“ (Interviewpartner W), an Entscheidungen im Zusammenhang mit der Softwareimplementierung beteiligt oder Hochschulabsolventen der Betriebswirtschaftslehre, die bereits im Studium den Umgang mit der Software kennengelernt haben, macht einen Unterschied. Eine weitere Entscheidung ist für das systemtheoretische Organisationsverständnis von besonderer Bedeutung: Die Entscheidung über die Organisationsmitgliedschaft. Vor allem in Luhmanns frühen organisationstheoretischen Arbeiten (vgl. Luhmann 1964a) zählt Mitgliedschaft zu einem zentralen Konzept, an das die Unterscheidung zwischen formalen und informalen Organisationsstrukturen geknüpft ist. Die Mitgliedschaft in einer Organisation geht einher mit bestimmten Verhaltenserwartungen, die eine Organisation als Bedingung für den Eintritt und den Verbleib in der Organisation formuliert. Diese Erwartungen

6

Siehe hierzu die Beschreibungen in KAPITEL 7 „Die Projektorganisation“.

D IE

INDIVIDUALISIERTE

S OFTWARE

| 143

werden von Luhmann als formalisierte Strukturen bzw. formale Organisationsstrukturen bezeichnet. Die Entscheidung zur Mitgliedschaft in einer Organisation zeigt die ausdrückliche Bereitschaft einer Person, die formalen Strukturen und Regeln dieser Organisation anzuerkennen. Formale Organisationsstrukturen verweisen auf spezifische erwartbare Handlungen der Mitglieder einer Organisation, sie beschreiben sinngemäße Einstellungen für ein angemessenes Verhalten. Formale Regeln in Organisationen können bis zu einem gewissen Grad flexibel und strategisch eingesetzt werden: „Eine Regel dient dem, der einen Vorteil aus ihr zieht, als Waffe, wenn er sie zitiert, und als Tauschobjekt, wenn er das Zitieren unterläßt“ (Luhmann 1964a: 310). Als Common Sense in der Organisationssoziologie gilt, dass „[...] die Dynamik des Organisierens sich nur verstehen lässt, wenn sich die Betrachtung nicht nur auf sichtbare Verhaltensregeln, festgeschriebene Strukturen und schriftlich fixierte Erwartungen richtet, sondern auch auf informelle Strukturen, die sich in keinem Handbuch, Leitfaden und in keiner Arbeitsanweisung finden lassen“ (v. Groddeck & Wilz 2015: 10). Nicht jede Erwartung an ein Mitglied kann formalisiert werden. Trotzdem haben auch nicht-formalisierte und nicht-formalisierbare Erwartungen an Mitglieder für die Organisation eine ordnungsbildende, stabilisierende und strukturierende Funktion. Diese fasst Luhmann unter der Überschrift der informalen Organisationsstrukturen. Informalität wird in anderen Organisationstheorien meistens ex negativo definiert, d. h., alles, was in Organisationen nicht formal geregelt ist, gilt als informal bzw. informell (ebd.: 7). Dies bezeichnet mitunter jedoch sehr Unterschiedliches. Unter der Überschrift Informalität oder informale Organisationsstrukturen werden nicht regulierte oder scheinbar unstrukturierte Zonen der Organisation untersucht. Dazu zählen spezifische Umgangsformen von Personen, aber auch die persönliche Beziehungsarbeit in Arbeitskontexten oder das Wir-Gefühl in Organisationen (z. B. Goll 2008: 153). Luhmann weist in seinen frühen Schriften dem Begriffspaar Formalität/Informalität einen zentralen Stellenwert zu. Aus einer systemtheoretischen Perspektive reduzieren formale und informale Strukturen die Komplexität von Organisationen und absorbieren Unsicherheit, indem sie die Bandbreite des möglichen Verhaltens von Organisationsmitgliedern einschränken und zur Orientierung beitragen. Organisationen zeichnen sich hiernach durch Koexistenz von zwei verschiedenen Strukturtypen (formal/informal) innerhalb eines Systems aus. Organisationen funktionieren nur deshalb, weil informale Strukturen dysfunktionale Folgen der formalisierten Ordnung der Organisation kompensieren und ausbalancieren.

144 | D AS P ROJEKT SAP

5.3 D IE

KOMMUNIKATIVE B EARBEITUNG VON E NTSCHEIDUNGSPROBLEMEN

Luhmann grenzt sich von Erklärungsansätzen ab, die Entscheidungen im psychologischen Sinne zu erfassen versuchen. Für ihn sind Entscheidungen keine psychischen Ereignisse oder bewusstseinsinterne Selbstfestlegungen, sondern soziale Ereignisse. „Was immer eine Entscheidung „ist“: innerhalb von Organisationssystemen kommt sie nur als Kommunikation zu Stande. Für uns ist demnach die Entscheidung ein kommunikatives Ereignis und nicht etwas, was im Kopf eines Individuums stattfindet“ (Luhmann 2000: 141).

Was für Kommunikationen gilt, gilt ebenso für Entscheidungen. In Luhmanns organisationstheoretischen Überlegungen tritt der Begriff der Entscheidung an die Stelle, die in seiner allgemeinen Sozialtheorie mit dem Begriff der Kommunikation besetzt ist (vgl. Luhmann 2000: 63). Soziale und psychische Prozesse werden im systemtheoretischen Ansatz strikt auseinandergehalten. Gleichzeitig wird ihr wechselseitiges Bedingungsverhältnis beschrieben. Soziale Systeme wie Organisationen und Interaktionen können nicht auf psychische Prozesse zurückgeführt werden, sie reproduzieren sich ausschließlich über Kommunikation. Ohne Bewusstsein ist Kommunikation indes undenkbar. Kommunikative Prozesse sind schon deshalb auf Bewusstsein angewiesen, weil nur das Bewusstsein, nicht aber die Kommunikation selbst, sinnlich wahrnehmen kann. Weder mündliche noch schriftliche Kommunikation funktioniert ohne Wahrnehmungsleistungen. Der Umweltkontakt zwischen psychischen und sozialen Systemen wird durch Sprache und kognitive Schemata ermöglicht (vgl. Luhmann 2005c: 110ff.). Kommunikation wird im Alltagsverständnis und in den Sozialwissenschaften üblicherweise als Handlung aufgefasst, und zwar als Mitteilungshandlung. Wenn man jedoch Kommunikation ausschließlich als Mitteilungshandlung begreift, verfehlt dies den emergenten sozialen Charakter von Kommunikation. Kommunikation reduziert sich auf eine Handlung und damit letztlich auf psychische Absichten. Aus systemtheoretischer Perspektive ist jedoch nicht das psychische System Urheber der Kommunikation. Der Erfolg von Kommunikation wird auch nicht als störungsfreie Übertragung vom Sender zum Empfänger oder als Verständigung modelliert. Stattdessen verweist Kommunikation auf die Anschlüsse des Nacheinanders kommunikativer Akte. Luhmann (1988: 884) hat dafür den Satz geprägt: „Nur die Kommunikation kann kommunizieren“. Er definiert Kommunikation als Verknüpfung von Information, Mitteilung und Verstehen.

D IE

INDIVIDUALISIERTE

S OFTWARE

| 145

Kommunikation kommt dann zustande, wenn eine Information, eine Mitteilungsweise und eine Verstehensmöglichkeit ausgewählt worden sind. Bei den Komponenten handelt es sich wohlgemerkt nicht um Operationen der beteiligten Personen, vielmehr sind sie Bestandteile der Kommunikation selbst. Die Kommunikation transportiert keine Bedeutungen als Bewusstseinsinhalte, sondern regt zu Bewusstseinsleistungen an. Das charakteristische Merkmal von Kommunikation ist ihre Unwahrscheinlichkeit. Die Unwahrscheinlichkeit von Kommunikation macht Luhmann (2005d: 30f.) an drei für die Kommunikation grundlegenden Problemen fest: 1) Es ist unwahrscheinlich, dass eine mitgeteilte Information verstanden wird. 2) Es ist unwahrscheinlich, dass eine mitgeteilte Information ihre Empfänger erreicht. 3) Die Annahme von Kommunikationsangeboten ist unwahrscheinlich. Kommunikativer Erfolg bedeutet aus einer systemtheoretischen Perspektive, dass der Adressat den Inhalt der Kommunikation (Information) als Prämisse für das eigene Verhalten übernimmt. In der Softwareberatung ist die Kommunikation auf konkrete Entscheidungsprobleme zugeschnitten. Der Beratene bzw. die beratene Organisation werden als Entscheider konstitutiert. In Skizzen zu einer Soziologie der Beratung stellt Rainer Schützeichel (2004) neben der Beratung verschiedene Formen der Wissensvermittlung vor. Beratung definiert er folgendermaßen: „Es handelt sich um thematisch bzw. sachlich auf Entscheidungsprobleme fokussierte, zeitlich limitierte Kommunikationen zwischen einem Alternativen offerierenden Ratgeber und einem um Entscheidungen ringenden Ratsuchenden.“ (Schützeichel 2004: 277)

Schützeichel kombiniert den systemtheoretischen Kommunikationsbegriff mit dem sozialkonstruktivistischen Konzept der kommunikativen Gattung von Thomas Luckmann (1986).7 Hiernach sind kommunikative Vorgänge weder vollkommen spontan, noch vollständig durch Gattungsmuster bestimmt. Neben der Beratung behandelt Schützeichel zwei weitere Kommunikationsmuster, die ebenfalls auf die Wissensvermittlung zugeschnitten sind und auf Entscheidungs-

7

Beispiele für kommunikative Gattungen sind die Predigt und das Interview, die in einer mehr oder weniger verbindlichen Weise vorgeben, wie kommunikative Probleme gelöst werden. Hierbei sind bestimmte Abläufe einzuhalten. Sie zeichnen sich aus durch spezifische Binnen- und Außenstrukturen. Die Binnenstruktur betrifft die Auswahl von Themen, Mitteilungsweisen, Redezugbestimmungen sowie Worten und Phrasen. Die Außenstruktur betrifft das Verhältnis zur sozialstrukturellen Umwelt. Soziale Rollen und Milieus tragen beispielsweise zur Außenstruktur gattungsspezifischer Kommunikationen bei (vgl. Luckmann 1986: 201ff.).

146 | D AS P ROJEKT SAP

probleme in Organisationen angewendet werden können: 1) Belehrung und 2) Betreuung. Im Datenmaterial zur Implementierung und Individualisierung der Standardsoftware finden sich auch Beispiele für diese kommunikativen Muster. Deshalb sollen sie genauer vorgestellt werden. 1) Das Kommunikationsmuster der Belehrung ist auf die Übernahme von Situationsdefinitionen zugeschnitten. Es basiert auf der Einsicht des Gegenübers, dass der Andere besser weiß, wie entschieden werden sollte. Voraussetzung hierfür ist, dass Maßstäbe für die Unterscheidung in richtige und falsche Entscheidungen existieren und auch geltend gemacht werden. Im Fall der Softwareimplementierung kann dieses Kommunikationsmuster in der Interaktion zwischen Berater und Organisationsmitgliedern beobachtet werden. Die Standardsoftware und ihre Vorlagen (templates) werden als best practices charakterisiert. Es wird argumentiert, dass die Programmabläufe in der standardisierten Software auf jahrzehntelanger Erfahrung in verschiedenen Projekten und Unternehmen gründen. In der belehrenden Kommunikation zwischen Softwareberatern und Organisationsmitgliedern wird die Information mitgeteilt, dass das Organisationsmodell der standardisierten Software aus diesem Grund so wenig wie möglich zu verändern ist. 2) Betreuung ist ein weiteres kommunikatives Muster für die Wissensvermittlung. Selektions- und Entscheidungsmöglichkeiten werden im Vorhinein beschnitten. Die Organisationswirklichkeit erscheint den Teilnehmern des Softwareprojektes möglicherweise als klar strukturierbarer Sachverhalt, der bloß aufgedeckt und danach in den Programmstrukturen der Software abgebildet werden muss. Faktisch wird die Wirklichkeit jedoch erst in den Beschreibungen von Organisationsmitgliedern und Beratern kommunikativ hergestellt. Der Berater ist hier klar im Vorteil: Während Organisationsmitglieder aus ihrem Organisationsund Geschäftsverständnis heraus lediglich vage Anforderungen an die Software formulieren können, ist der Softwareberater in der Lage, detaillierte Beschreibungen der Arbeitsabläufe vorzuschlagen. Diese folgen primär der Programmlogik der Software. Der Berater kann konkrete Vorschläge unterbreiten, weil er über das entsprechende Softwarewissen verfügt bzw. weiß, wo er im System der Software zu suchen hat. Für die Charakterisierung der Tätigkeit des Softwareberaters, so zeige ich im nächsten Kapitel, ist Betreuung mitunter die treffendere Bezeichnung. In der Interaktion zwischen Organisationsmitgliedern und Softwareberatern können sowohl kommunikative Muster der Beratung als auch Muster der Belehrung und Betreuung beobachtet werden. Es geht dabei um Entscheidungsprobleme, die das Customizing der Software und die Anpassung der Organisation an die Technik betreffen.

6. Die Beratungsinteraktion: Entscheidungen als Output

Die Implementierung der Software muss in Organisationen „durch das Nadelöhr einer Interaktion unter Anwesenden“ (Luhmann 1972: 148). Keineswegs handelt es sich dabei bloß um die Analyse eines Entscheidungssystems und seines Datenbedarfs. Die Softwareimplementierung ist weitaus komplexer. Der Vorteil des gewählten systemtheoretischen Untersuchungsansatzes liegt darin, dass auch die Interaktion unter den Mitgliedern einer Organisation und Beratern innerhalb derselben Theorie behandelt werden kann. „Die Bedeutung der soziologischen Fragestellung liegt vor allem darin, daß die Differenzierung von Organisation und Interaktion nicht mehr nur als Bremseffekt, als Entgleisung organisierter Absichten und Weisungen, als Widerstand und Sabotage gesehen wird, sondern zugleich als Motivquellen, als elastische Anpassung an konkrete Situationen, als Auffangmöglichkeit für unvermeidliche Widersprüche in der Organisationsstruktur.“ (Luhmann 1972: 148)

Organisationen reproduzieren sich ausschließlich über ihre eigenen Entscheidungen. Interaktionen hingegen tun dies über Kommunikation, die auf der wechselseitigen Wahrnehmung der anwesenden Teilnehmer basiert. Bei einer Kommunikation unter Anwesenden (Kieserling 1999) handelt es sich also um eine eigene Form der Systembildung.1 Nicht alles, was in der Interaktion zwischen Be-

1

Luhmann schlägt mit der Unterscheidung Interaktion, Organisation, Gesellschaft (Luhmann 2005e) eine Typologie sozialer Systeme vor, mit der unterschiedliche so-

148 | D AS P ROJEKT SAP

ratern und Organisationsmitgliedern kommuniziert wird, nimmt dabei die Form von Entscheidungen an. In der Beratungsinteraktion ist – wie auch in anderen Formen der Interaktion in Organisationen – zwischen offizieller Kommunikation (die als Entscheidung präsentiert wird) und inoffizieller Kommunikation (die explizit nicht als Entscheidung interpretiert wird) zu unterscheiden. Die Interaktion mit den Organisationsmitgliedern des Kundenunternehmens ist ein besonders wichtiger Aspekt der Beratung. Zwar gibt es zahlreiche interaktionsfreie oder interaktionsarme Tätigkeiten, doch stehen diese stets im direkten Bezug zur Erbringung der Beratungsleistung, die in der Face-to-Face-Interaktion stattfindet (vgl. Kühl 2008). Diese wird auf unterschiedliche Weise strukturiert: 1) dyadisch als Beratungsgespräch zwischen einem Berater und dem Key-User einer Abteilung oder 2) im Team als Beratungsgespräch zwischen Softwareexperte und Vertretern unterschiedlicher Abteilungen. Im Mittelpunkt der folgenden empirischen Analyse der Softwareimplementierung in einer Organisation steht ein Projekttreffen zwischen einem Softwareberater und dem Team der Organisation. An diesem konkreten Beispiel lässt sich das Verschachtelungsverhältnis zwischen Organisation und Interaktion empirisch beobachten und beschreiben. Bevor eine Standardsoftware wie SAP in Organisationen verwendet werden kann, muss sie gewissermaßen entstandardisiert werden, d. h., sie muss an die spezifischen Bedingungen einer konkreten Organisation angepasst werden. Die Software kann also nicht standardmäßig verwendet werden. Soll sie funktionieren, muss sie für eine Organisation individualisiert werden. Auf den folgenden Seiten werden Gesprächssequenzen eines Projekttreffens vorgestellt, das im Rahmen der Softwareberatung in einem Unternehmen stattfand. Teilnehmer waren die folgenden Personen: der Leiter der Controlling-Abteilung, der Produktionsleiter, ein Mitarbeiter aus dem Vertrieb, ein Mitarbeiter aus der Informationstechnik des Unternehmens Seating Company (Pseudonym) sowie ein Berater eines IT-Dienstleisters, der mit der Implementierung von SAP von der Unternehmensleitung beauftragt wurde. Das Gespräch dauerte insgesamt etwa 90 Minuten. Es gliedert sich in zehn Sequenzen, von denen nun kurze Passagen vorgestellt werden.2 Seating Company ist ein Hersteller von Sitzen und Sitzsystemen für Bahnen und Busse. Das Unternehmen hat Tochtergesellschaften in Polen, Frankreich, den Niederlanden und den USA sowie Vertriebsstandorte in Öster-

ziologische Forschungszweige in eine Theorie sozialer Systeme integriert werden können. 2

Zur Aufbereitung des Datenmaterials und zur verwendeten Transkriptionsnotation siehe EINLEITUNG.

D IE

INDIVIDUALISIERTE

S OFTWARE

| 149

reich, der Schweiz, Ungarn und Slowenien. Außerdem unterhält es ein Joint Venture in Russland und kooperiert mit anderen Herstellern in Italien, Spanien, der Türkei, Griechenland und Australien. Die fertigen Produkte liefert das Unternehmen u. a. an einen Bushersteller mit Sitz an der deutsch-polnischen Grenze. Die Montage der Bussitze wird von Mitarbeitern und Mitarbeiterinnen dieses Kunden selbst übernommen. Seating Company liefert in diesem Fall also sogenannte Halbfabrikate aus. Der Bushersteller wird im betriebswirtschaftlichen Sinne nicht nur als Kunde, sondern auch als Lieferant betrachtet, weil die Mitarbeiter des Busherstellers selbst die Montage der Sitzsysteme übernehmen und so zu einem Mehrwert des Produktes beitragen. Normalerweise fällt die Fertigstellung des Sitzsystems in den Aufgabenbereich der Produktion von Seating Company. Wie die Auswertung der Gesprächssequenzen auf den folgenden Seiten zeigen wird, ist die Doppelrolle dieses Kunden für die Abbildung von Arbeitsabläufen in den Programmabläufen der Software folgenreich.

6.1 K ONKRETISIERUNG

DER

A NFORDERUNGEN

In SEQUENZ 1 eröffnet der Berater die Interaktion mit der Frage: „Was wollen wir mit dem Ganzen erreichen?“ Das Ziel der Beratungsinteraktion ist die Konkretisierung unternehmensspezifischer Anforderungen an die Software. Der Berater klickt währenddessen durch einzelne Bildschirmmasken. Diese werden über das Notebook des Beraters mit einem Beamer an die Wand projiziert, so dass alle Teilnehmer seiner Navigation durch das System der Software folgen können. SEQUENZ 1 Berater:

Unternehmensstruktur ((Klick)), Vertriebswerkzuordnung ((Klick)). Ich weiß gar nicht, ob wir das brauchen. Wir können es dann aber auch noch einmal neu zuordnen. Sollte kein Problem sein. Jetzt wollen wir mal die Anforderungen notieren. Was wollen wir mit dem Ganzen erreichen?

Produktion:

Was wir erreichen wollen?

Berater:

Hmmh.

Produktion:

Eine saubere, vernünftige, systemtechnische und systemgesteuerte Abwicklung.

Berater:

Das ist ein bisschen sehr allgemein formuliert.

Vertrieb:

Genau. Aber alles das, was uns hilft, nicht außerhalb des Systems zu

150 | D AS P ROJEKT SAP arbeiten, was wir heute ja tun. Heute machen wir alle Kundenbereitstellungen außerhalb des Systems. Produktion:

Weil wir keinen Prozess haben dafür.

Der Berater navigiert entlang verschiedener Kategorien an der Softwareoberfläche („Unternehmensstruktur“, „Vertriebswerkzuordnung“). Es handelt sich um Kategorien, die ihm vom System der Software zur Beschreibung von Organisationen angeboten werden. Diese Kategorien strukturieren die Gesprächsführung des Beraters und die Analyse des Datenbedarfs der Organisation Seating Company weitgehend vor. Die standardisierte Software fungiert als Referenzobjekt, mit dessen Hilfe sowohl über die Anpassungen der Software als auch über die Anpassungen der Organisation etwas ausgesagt und entschieden werden soll. Normalerweise verfügt der Softwareberater nicht über detaillierte Kenntnisse der systemtechnischen Datenspeicherung und des Datenzugriffs. Er findet auf der Ebene betriebswirtschaftlicher Anwendungsprogramme durch die Entwickler von SAP bereits festgelegte Datenverknüpfungen vor. Auf der Ebene der Anwendungsprogramme sind die Möglichkeiten für die Verknüpfung und Kombination von Datensätzen also weitgehend vorstrukturiert.3 Diese Art der Vorstrukturierung wird auf der Darstellungsebene der Software durch den Aufbau der Bildschirmoberfläche und die Abfolge von Bildschirmmasken sichtbar. Dem Berater wird eine Liste möglicher Parameter und Datenverarbeitungsregeln am Bildschirm angezeigt.4 Diese Liste hat eine baumartige Struktur, die verschiedene Anwendungsbereiche der Software und Unternehmensbereiche darstellt (Controlling, Vertrieb, Einkauf etc.). Die vom Berater im Beratungsgespräch aufgegriffene Kategorie Vertriebswerke repräsentiert eine Organisationseinheit im System der Software. Werk ist die Bezeichnung für einen Standort des Unternehmens. Die Bezeichnung Vertriebswerk spiegelt darüber hinaus eine innerbetriebliche Verantwortungsstruktur wider. In diesem Fall sind die Mitarbeiter der Vertriebsabteilung verantwortlich für die Bereitstellung von Waren zur Auslieferung und den Verkauf an den Kunden und berechtigt, bestimmte Programmabläufe (Prozessketten) in der Software auszulösen. In einem Produktionswerk sind entsprechend die Produktionsmitarbeiter verantwortlich für die Fertigung von Fabrikaten und berechtigt entspre-

3

Der Aufbau der Software anhand des „3-Ebenen-Modells“ wurde in KAPITEL 1 erläutert. Analog zur Unterscheidung der Datenbankebene, der Anwendungsebene und der Darstellungsebene wird zwischen SAP-Basisentwicklern, SAP-Anwendungsentwicklern und SAP-(Modul-)Beratern unterschieden.

4

Von SAP-Beratern wird diese Liste auch als Implementation Guide bezeichnet.

D IE

INDIVIDUALISIERTE

S OFTWARE

| 151

chende Daten einzugeben. Hinter den Bezeichnungen Vertriebswerke und Produktionswerke verbergen sich im System der Software verschiedene Datenbankabfragen (z. B. „In welchen Zuständigkeitsbereich fällt die Herstellung des Produktes xy?“, „Für wen müssen Produkte xyz bereitgestellt sein?“ oder „Welche Produkte müssen wann hergestellt sein?“). Der Berater informiert die anwesenden Organisationsmitglieder in dieser ersten Sequenz über die Möglichkeit der Individualisierung von Datenbankabfragen. Er selbst wird erst beim Durchklicken der Bildschirmmasken über die Voreinstellungen der Software auf die Möglichkeit einer Vertriebswerkzuordnung aufmerksam. Die Entscheidung, ob die Zuordnung von Datensätzen vorgenommen werden soll, verschiebt der Berater allerdings auf einen späteren Zeitpunkt. Stattdessen fordert er die übrigen Interaktionsteilnehmer dazu auf, die Anforderungen des Unternehmens an die Funktionsweise der Software zu benennen. Die in der Interaktion getroffenen Entscheidungen erhalten durch ihre Protokollierung („Jetzt wollen wir mal die Anforderungen notieren.“) Verbindlichkeitscharakter. Protokolle spielen in der Softwareberatung deshalb eine wichtige Rolle. Zumindest wird dies in mehreren Interviews mit Softwareberatern behauptet, die diese als Teil der „Spielregeln“ zwischen Kunde und Beratungsunternehmen verstanden wissen wollen. Es handelt sich dabei nicht um Gesprächsverlaufsprotokolle, sondern um Gesprächsergebnisprotokolle. Der Berater verwendet in der Frage nach dem Projektziel ein inklusives Wir und schließt damit sich selbst (als Sprecher) und die Organisationsmitglieder der Seating Company (als Angesprochene) ein. Der Produktionsleiter wiederholt die Frage des Beraters, um Zeit zu gewinnen. Seine Antwort („Eine saubere, vernünftige, systemtechnische und systemgesteuerte Abwicklung“) ist dann allerdings wenig informativ.5 Mit der Aneinanderreihung von Adjektiven gibt er keine falsche Antwort; sie fällt jedoch so allgemein und abstrakt aus, dass der Berater daraus keine Hinweise für die Konkretisierung der organisationsspezifischen Anforderungen an die Technik ableiten kann. Diese sind jedoch notwendig, um das Customizing der Standardsoftware vornehmen zu können.

5

Die Wörter „sauber“ und „vernünftig“ werden nicht nur in den vorgestellten Gesprächssequenzen häufig verwendet, auch in den Interviews mit Beratern und Softwarenutzern wurden diese Adjektive häufig gebraucht, um die Softwareverwendung in Organisationen und ihren potenziellen Nutzen zu beschreiben. Das Adjektiv „systemtechnisch” passt in den ingenieurswissenschaftlichen Kontext der Softwareimplementierung, denn es geht um die technische Verknüpfung einzelner Module der Software über standardisierte Schnittstellen. Die „systemgesteuerte Abwicklung“ steht für die Automatisierung bestimmter Arbeitsschritte mithilfe der Software.

152 | D AS P ROJEKT SAP

Der Vertriebsmitarbeiter pflichtet dem Einwand des Beraters („Das ist ein bisschen sehr allgemein formuliert“) bei. Doch auch seine Antwort fällt allgemein aus.6 Er verwendet in seinem Redebeitrag mehrmals den Ausdruck „außerhalb des Systems“. Offensichtlich handelt es sich hierbei um das allgemeine Problem, für das in der Softwareberatung eine Lösung gefunden werden soll. Dieses Problem konkretisiert der Vertriebsmitarbeiter am Beispiel von sogenannten Kundenbereitstellungen. Diese Aufgabe habe man im Unternehmen bisher ohne eine Software abgewickelt. Daraufhin ergänzt der Produktionsleiter, dass dafür auch kein Prozess definiert worden sei. Der Prozessbegriff wird nicht nur als Synonym für Arbeitsabläufe verwendet, sondern steht für ein zentrales Beispiel softwareinduzierter Systematisierung. Die Verkettung von Ereignissen und Prozessen als spezifische Form der Modellierung von Arbeitsabläufen im System der Software wird hier offenbar. Arbeitsabläufe in einem Unternehmen werden in Ereignisse und Prozesse übersetzt.7 Im System der Software lautet das Startereignis für den Prozess Kundenbereitstellung folgendermaßen: „Material ist geliefert“. Die Software reagiert darauf mit einer festgelegten Programmroutine. Diese lautet „Material bewerten“. Für die verbale Beschreibung von Ereignissen im Organisationsmodell von SAP wird eine Partizipialkonstruktion verwendet. Die durch Ereignisse ausgelösten Funktionen werden hingegen mit einer aktiven Verbkonstruktion ausgedrückt. Sobald Material an den Kunden geliefert wurde, verändern sich automatisch die Daten über den Warenbestand im Materiallager der Produktion. In der SEQUENZ 2 beschreibt der Leiter der Controlling-Abteilung diese im Organisationsmodell der Software übersetzten Arbeitsabläufe. SEQUENZ 2 Controlling:

Wir wollen ja nur eine saubere Verknüpfung der Vorgänge erreichen. Wir wollen ja nur nachvollziehen, welches Material wurde dorthin geliefert und wie ist das Material nach Lieferung an den Kunden bestandsmäßig nachzuvollziehen. Ich kann nicht irgendwo später eine Riesenlücke haben.

6

Mit dem Wörtchen genau kann auch etwas anderes als Zustimmung signalisiert werden. Wer genau sagt, will meist gar nicht so genau wissen, sondern gibt dem anderen zu verstehen: ‚Ich finde richtig, dass Sie etwas sagen, egal, was Sie sagen’ (vgl. Geyer 2013: 78f.).

7

Zum Prinzip der ereignisgesteuerten Prozesskette siehe die Ausführungen in KAPITEL 1.2 „Die Anwendungsebene“ und zum Modell der Prozessorganisation KAPITEL 4.

D IE

INDIVIDUALISIERTE

S OFTWARE

| 153

Produktion:

Eine sinnvolle logistische Kette.

Controlling:

Genau. Eine sinnvolle logistische Kette, damit das nachvollziehbar ist.

Dem Controller geht es um eine lückenlose Dokumentation von Arbeitsabläufen sowie die Möglichkeit der nachträglichen Auswertung von entsprechenden Unternehmensdaten. Es geht ihm nicht so sehr darum, „unmittelbar korrigierend in das laufende Geschehen ein(zu)greifen“ (Plattner & Kagermann 1988: 137), wie es das Konzept der Standardsoftware eigentlich vorsieht.8 Diese Aufgabe überlässt er anderen Abteilungen. Im Hinblick auf die Definition des Projektziels der Softwareimplementierung demonstriert der Controller Einigkeit mit dem Produktionsleiter. Er bringt in der Gesprächssequenz sein spezifisches Informationsinteresse zum Ausdruck, das mithilfe der Software erfüllt werden soll. Geknüpft ist dieses Interesse primär an seine Organisationsrolle und eben nicht an seine Person. Inwiefern die Ebenen Organisation und Interaktion ineinander verschachtelt sind und welche Konsequenzen dies für die Anfertigung formaler Selbstbeschreibungen der Organisation hat, darüber geben die Gesprächssequenzen Auskunft, die im nächsten Abschnitt vorgestellt werden.

6.2 S ELBSTBESCHREIBUNGEN

DER

O RGANISATION

In SEQUENZ 3 fertigt der Berater anhand der vorkonfigurierten Programmabläufe der standardisierten Software eine Beschreibung der Arbeitsabläufe von Seating Company an. PVB ist die Abkürzung für Produktionsversorgungsbereich. Damit ist eine Datenbankabfrage gemeint, mit der ein Softwarenutzer darüber informiert wird, welche Materialmengen einzelnen Arbeitsplätzen zugeteilt werden müssen, damit ein zuvor bestimmtes Endprodukt hergestellt werden kann. SEQUENZ 3 Berater:

((Klick)) Wir brauchen keinen PVB. Wir bilden doch deren Produktion nicht ab. Das interessiert uns doch gar nicht. Dieser Materialfluss im WM, wer soll denn das buchen?

Produktion:

Ja, aber die Frage ist, ich muss ja auch irgendwo die Materialien sehen.

8

Vergleiche hierzu die Erläuterungen in KAPITEL 1.2.1 zum Konzept der Echtzeitverarbeitung.

154 | D AS P ROJEKT SAP Berater:

Sie sehen nur, dass es da ist und danach wird es weggebucht. ((Klick)) Wir gucken in einen Auftrag einfach mal rein. Wenn man jetzt mal so einen Auftrag nimmt. (-) Den hier. Den Fertigungsauftrag. So sieht der aus. Der besteht aus (---) zwei Vorgängen und einer Reihe ziemlich großer Mengen von Komponenten. Jetzt schon mal die erste Frage. Die ganzen Schüttgüter, die können wir uns eigentlich sparen, oder?

Produktion:

Schüttgüter sind weg. Die müssen bei denen dort liegen.

Die Teilnehmer der Interaktion beschreiben die Organisation Seating Company als geschlossenes System, das aus klar definierten und von Personen kontrollierbaren Prozessen besteht. Arbeitsabläufe können mithilfe der Software als unternehmensübergreifende Geschäftsprozesse modelliert werden. Die Markierung von Organisationsgrenzen ist aus diesem Grund umso wichtiger. In den Programmabläufen der Software soll sich auch die Grenze zwischen Unternehmen und Kunden bzw. Lieferanten widerspiegeln („Wir bilden doch deren Produktion nicht ab.“). Um den Materialfluss zwischen Seating Company und Bushersteller abbilden zu können, so der Berater in seinem Redebeitrag, müsste ein zusätzliches Softwaremodul, Warehouse Management (WM), implementiert werden. Mit seiner Frage danach, wer das buchen solle, problematisiert er die Verantwortlichkeit für die Dateneingabe bzw. Änderungen der Datengrundlage. Mit dem Wort buchen wird eine Aufgabe bezeichnet, die traditionell in der Buchhaltung liegt, nämlich die Aufzeichnung von Geschäftsvorfällen, die im Unternehmen an bestimmte Werte geknüpft sind. In der vorgestellten Gesprächssequenz drückt auch der Produktionsleiter ein rollenspezifisches Informationsinteresse aus, das sich vom Informationsinteresse eines Controllers unterscheidet. Während der Controller SAP als Planungs- und Kontrollsystem begreift, ist die Software für den Produktionsleiter ein System, das das Personal von geistigen und manuellen Arbeiten entlastet und bei kurzfristigen dispositiven Entscheidungen unterstützt.9 Statt dem Produktionsleiter nur

9

Die Wirtschaftsinformatik unterscheidet zwischen den Funktionen Verwalten, Disponieren, Planen und Kontrollieren. Sie klassifiziert EDV-Systeme entsprechend als Administrations- und Dispositionssysteme, die auf unteren und mittleren Managementebenen eingesetzt werden, und Planungs- und Kontrollsysteme, die auf mittleren und oberen Managementebenen verwendet werden. Die SAP-Standardsoftware hat den Anspruch, sämtliche Anwendungsbereiche in einem Unternehmen zu unterstützen. Aus Sicht der Wirtschaftsinformatik ist sie deshalb eine „multifunktionale“ Anwendungssoftware (vgl. Lassmann 2006: 448).

D IE

INDIVIDUALISIERTE

S OFTWARE

| 155

verbal zu erläutern, welche Daten an der Bildschirmoberfläche der Software dargestellt werden, zeigt der Berater ihm, wie ein Fertigungsauftrag im System der Software modelliert wird. Er schließt die Frage an, ob die Auftragsdaten dem Softwarenutzer tatsächlich so detailliert angezeigt werden sollten, wie es im System der standardisierten Software vorgesehen ist. Der Produktionsleiter thematisiert mit seiner Antwort erneut die Organisationsgrenze von Seating Company und unterscheidet zwischen der physischen und der buchhalterischen (symbolischen) Grenze des Unternehmens. Schüttgüter, d. h. kleine Materialkomponenten wie Schrauben und Unterlegscheiben, werden dem Kunden vor Ort zur Verfügung gestellt. Der Materialwert wird dann pauschal festgelegt und bei der Bewertung von Halbfabrikaten berücksichtigt. Obwohl die Materialkomponenten also physisch bereits beim Kunden liegen, werden sie buchhalterisch zum Inventar der Seating Company gezählt.

6.3 E NTSCHEIDUNGSPROGRAMME IN DER O RGANISATION UND DIE P ROGRAMMLOGIK In der vierten Gesprächssequenz vergewissert sich der Berater zunächst, ob seine Interpretation des Projektziels der Softwareimplementierung mit der Vorstellung der anwesenden Teilnehmer übereinstimmt. SEQUENZ 4 Berater:

Aber wir reden im Grunde genommen vor allem über Materialbewertungen.

Produktion:

Richtig. Nur über Materiale. {{gleichzeitig} Alles andere}

Berater:

{{gleichzeitig} Wir haben ja} keine Löhne dort.

Controlling:

Produktion und so das brauchen wir gar nicht haben. Wir können die Produktion als Blackbox machen, wie auch immer. Aber ich brauch das Material und die Bewertungen. Und ich brauch die Materialbewegungen, damit wir sauber sind. Denn sonst haben wir ein Problem alleine durch die Inventuren beziehungsweise Wirtschaftsprüfungen, wenn ich die Materialbewegungen nicht sauber abwickeln kann.

Berater:

Also Transparenz der Bestände und Materialbuchungen.

Der Berater bringt die bisher durch die Organisationsmitglieder vage formulierten Projektziele auf den Begriff: Materialbewertungen. Der Produktionsleiter

156 | D AS P ROJEKT SAP

stimmt dieser Zusammenfassung zu und setzt zu weiteren Ausführungen an, was alles nicht in den Programmabläufen der Software modelliert werden sollte. Der Berater schaltet sich jedoch mit einem konkreten Beispiel dazwischen und signalisiert den Teilnehmern damit seine Rolle als Gesprächsleiter. Löhne sind in den betriebswirtschaftlichen Anwendungsprogrammen der Standardsoftware eine zentrale Kategorie. Sie stellen den Produktionsbereich in einer Organisation dar. Löhne für Produktionsmitarbeiter werden zu den Produktionskosten hinzugezählt. Sie bilden die Grundlage für eine wertmäßige Abbildung der Produktion von Unternehmen. Der Berater scheint diesen Aspekt aus der Abbildung im System der Software ausklammern zu wollen und fordert die Anwesenden zu einer Bestätigung dieser Entscheidung auf. Der Controller bestätigt die Entscheidung als Organisationsentscheidung: „Produktion und so das brauchen wir gar nicht haben“. Er konkretisiert nochmals sein rollenspezifisches Informationsinteresse. Dieses besteht in der nachträglichen Bewertung und der Feststellung von Planabweichungen. Die Notwendigkeit für Materialbewertungen und den Nachweis von Materialbewegungen begründet er damit, dass „Inventuren bzw. Wirtschaftsprüfungen“ (ebd.) in der Organisation stattfinden. Eine Inventur ist eine körperliche oder eine buchmäßige Bestandsaufnahme aller Vermögensgegenstände und Schulden eines Unternehmens. Eine körperliche Bestandsaufnahme erfolgt zu einem bestimmten Zeitpunkt durch Messen, Wiegen und Zählen. Bei einer buchmäßigen Inventur werden die finanziellen Forderungen, Wertpapiere und andere Vermögenswerte eines Unternehmens zusammengestellt. Das bereits bewegte Material bzw. das an den Kunden gelieferte Material zählt buchmäßig zum Inventar der Seating Company. Eine körperliche Inventur weicht von dieser Inventarisierung ab, denn das Material befindet sich nicht mehr im Lager, sondern beim Kunden vor Ort. Normalerweise wird der Begriff Blackbox verwendet, um deutlich zu machen, dass ein Beobachter über den inneren Aufbau eines Systems nichts weiß oder/und sich nicht dafür interessiert. Der Controller verwendet den Begriff hier, um deutlich zu machen, dass die konkreten Arbeitsabläufe des Kunden für Seating Company ohne Bedeutung für die Modellierung der Organisation sind. Im weiteren Verlauf der Interaktion wird diese Blackbox trotzdem etwas geöffnet. In SEQUENZ 5 wird nämlich darüber diskutiert, wie Produktionsmitarbeiter bei ihrer Arbeit vorgehen und welche Daten der Seating Company sie dafür aus dem System der Software benötigen. SEQUENZ 5 Berater:

Die arbeiten ja dort nicht mit den Fertigungspapieren, oder?

D IE

Produktion:

INDIVIDUALISIERTE

S OFTWARE

| 157

Nein, die sollen nicht mit den Fertigungspapieren (-). Doch, die müssen sogar mit den Fertigungspapieren arbeiten. Entschuldigung. Ja, da stehen alle Hinweise drauf, wie sie das System zusammenbauen müssen.

Berater:

Okay.

Aufschlussreich ist diese Sequenz vor allem deshalb, weil hier deutlich wird, dass diejenigen, die Entscheidungen über die Softwareimplementierung in einem Arbeitsbereich vorbereiten und treffen, gar nicht unbedingt wissen, wie in diesem Bereich tatsächlich gearbeitet wird. Man beschäftigt sich also nicht so sehr mit einem Ist-Zustand, der in einen Soll-Zustand überführt werden soll. Stattdessen operiert man von Vornherein mit einem Soll-Zustand der Organisation bzw. mit der Modellierung und dem Design einer Organisation. Berater greifen dabei meistens auf ein oberflächliches und abstraktes Organisationswissen zurück. Sie sind angewiesen auf die Informationen von den Mitgliedern der Organisation. Die an der Beratungsinteraktion teilnehmenden Organisationsmitglieder verfügen jedoch nicht zwangsläufig über ein konkretes Organisationswissen. Der Produktionsleiter kommt im geschilderten Fall mit dem operativen Tagesgeschäft selbst kaum in Berührung. Der Berater springt ein und beschreibt die Abbildung der Arbeitsabläufe im System der Software, obwohl er selbst über kein konkretes Organisationswissen verfügt. SEQUENZ 6 Berater:

Gut. Also, das heißt im Grunde genommen, von der Sache her, da sie ja nicht wissen, was sich dort abspielt und sie vermutlich auch keine Informationen darüber ziehen wollen, erstmal, kann man eigentlich sagen, am Ende des Tages wird rückgemeldet.

IT:

Wer meldet rück? Und wie? Also die über den Terminal oder was?

Berater:

Können sie machen. Man kann über den Terminal gehen oder man kann auch sagen, okay, es wird hier direkt bei uns im Werk gemacht.

IT:

Die schicken eine E-Mail oder was? Dass sie fertig sind. Eine EMail, weil wir ja die Bestände wissen.

Berater:

Was heißt E-Mail? Ich meine (--) sie brauchen keine E-Mail schicken. Sie können das selbst machen. Die können zurückmelden. Sie sehen ja im System rückgemeldet wurde oder nicht. [...]

Mit dem Begriff Rückmeldung ist die Dateneingabe gemeint, mit der Datensätze in den zugrundeliegenden Datenbanken verändert werden. Die Eingabe von Da-

158 | D AS P ROJEKT SAP

ten („Wann und wie viele Sitze wurden montiert?“) hat Effekte auf die Arbeitsabläufe in mehrere Abteilungen. In den Programmabläufen werden sie als Ereignisse übersetzt, die automatisch verschiedene Funktionen auslösen (z. B. Erstellung der Papiere für den Versand von Fertigfabrikaten, Erstellung der Rechnung für den Kunden). Die Rückfragen des IT-Mitarbeiters lassen erkennen, dass es an dieser Stelle eigentlich weiterer Erklärungen durch den Berater bedürfte. Die Bedeutung des Wortes Rückmeldung im Kontext von SAP scheint dem IT-Mitarbeiter nicht geläufig zu sein. Er versteht den SAP-Begriff als Synonym für den Versand einer E-Mail. In der Sprache von Entwicklern und Beratern bedeutet die Vokabel Rückmeldung hingegen, dass der Stand der Bearbeitung von Vorgängen und Vorgangselementen im System der Software dokumentiert wird, um so Prognosen für den weiteren Ablauf von Arbeitsschritten zu ermöglichen. Die Mitteilung der Information zum Arbeitsstand erfolgt also mittels Software und nicht mithilfe klassischer Verbreitungsmedien wie E-Mail oder Telefon. Der IT-Mitarbeiter fordert konkretere Angaben zur notwendigen technischen Ausstattung, doch der Berater geht darauf nur äußert vage ein. Auf die Nachfragen des IT-Mitarbeiters geht der Berater nicht weiter ein, sondern wechselt das Thema. Er übernimmt damit wieder die Gesprächsführung. Die Arbeitsabläufe einer Organisation werden im System der Software nicht nur als zeitliche Abfolge von Tätigkeiten abgebildet, sondern als ereignisgesteuerte Prozessketten. Diese Form der Systematisierung ermöglicht einen Abgleich zwischen dem Organisationsmodell der Software und der Beschreibung konkreter Arbeitsabläufe in einer Organisation. Sie erlaubt darüber hinaus den Vergleich mit anderen Organisationen. Die Arbeitsabläufe bei einem Automobilzulieferer, einem Chemieunternehmen oder einem Zuckerproduzenten unterscheiden sich nicht mehr grundlegend voneinander, sobald konkrete Abläufe und Aufgaben in den abstrakten Kategorien des Organisationsmodells der Software beschrieben werden. Der Softwarehersteller SAP und die Softwareberater und beraterinnen arbeiten mit Gleichheitsunterstellungen. Es ist offensichtlich, dass der Berater über kein konkretes Organisationswissen verfügt. Auch die anwesenden Interaktionspartner verfügen ebenfalls über keine ausreichenden Informationen darüber, wie im Bereich der Fertigung tatsächlich gearbeitet wird. Hier geht es nicht um eine sachlich adäquate Abbildung von existierenden Entscheidungsprogrammen, sondern um Beschreibungen von Arbeitsabläufen, die primär in die programmtechnische Welt der Software passen und dort ohne größeren Aufwand abgebildet werden können.

D IE

INDIVIDUALISIERTE

S OFTWARE

| 159

6.4 B ERECHTIGUNGEN UND ANDERE E NTSCHEIDUNGSPROBLEME Eine Organisationsentscheidung darüber herbeizuführen, wer berechtigt ist, die Funktion für den Versand an den Kunden in den Anwendungsprogrammen der Software auszulösen, kristallisiert sich als eines der konkreten Ziele des Projekttreffens heraus. In der folgenden Gesprächssequenz thematisiert der Softwareberater einen zentralen Aspekt der Individualisierung der Standardsoftware. Es geht um das Berechtigungskonzept, das den Anwendungsprogrammen der Software zugrunde liegt. Festgelegt wird mit dem Berechtigungskonzept, von wem und wie diese Programme verwendet werden dürfen. Damit sollen Datentransaktionen eingeschränkt und die Datenbanken des Unternehmens vor unberechtigtem Zugriff geschützt werden. SEQUENZ 7 Berater:

[...] Die Frage ist ja, wer stößt den Versand an?

Produktion:

Und das muss an der Stelle auch qualifiziert erfolgen.

Berater:

Alles, alles. Ich sag ja, ich weiß nicht wie groß das Volumen ist, dass da abgewickelt wird, aber alles, was da getan wird, muss irgendjemand qualifiziert im Zugriff haben. Und da bezweifle ich, dass man das von hier aus alles machen kann. Das kann ich mir nicht vorstellen. Weil dann müssen sie wahnsinnig viel kommunizieren mit Telefonhörer und was weiß ich, mit allen, um zu sagen, wo stehen wir denn gerade. Also die Frage ist schon, ob ich nicht irgendjemanden hab, der dort diese Dinge tut. Also zumindest mal diese Rückmeldungen macht.

Mit Versand ist in diesem Fall nicht das Versenden von Waren im eigentlichen Sinne gemeint. Die Halbfabrikate sind von der Seating Company bereits an den Kunden ausgeliefert worden. Der Kunde (ein Bushersteller) montiert selbst die Sitze und trägt so zur Fertigstellung des Produktes (Sitzsysteme) bei. Der Versand ist die Bezeichnung für eine Funktion in den Programmabläufen der Software. Die Programme manipulieren die Datensätze in der Datenbank des Unternehmens so, dass die Fabrikate nicht mehr länger zum Bestand des Unternehmens Seating Company gezählt werden, sondern in den Besitz des Kunden übergegangen sind. Dabei werden unterschiedliche Datensätze entsprechend neu miteinander verknüpft. Auf dieser Grundlage werden automatisch Rechnungen erstellt und an den Kunden verschickt.

160 | D AS P ROJEKT SAP

Der Produktionsleiter spricht in dieser Gesprächssequenz die notwendige Qualifikation der Personen an, die die Manipulation der Datensätze auslösen dürfen. Der Berater macht deshalb auf das Entscheidungsproblem aufmerksam, wie die Zugriffsrechte für die Softwareverwendung vergeben werden sollen. Er schlägt vor, eine konkrete Person mit dieser Aufgabe zu betrauen, um die Kommunikation zu vereinfachen. Die Produktionsmitarbeiter des Busherstellers hat man bislang als Beplante in den Programmabläufen berücksichtigt. Sie wurden als Personalressourcen für Montagearbeiten und zugleich als Personalkosten für das Unternehmen abgebildet. In dieser Gesprächssequenz werden Mitarbeiter zum ersten Mal als Berechtigte thematisiert. Genauer gesagt, es soll darüber entschieden werden, inwieweit die Mitarbeiter des Kunden zur Verwendung der Software von Seating Company berechtigt sind und damit auch Zugriff auf Unternehmensdaten erhalten. SEQUENZ 8 Berater:

Die Frage ist schon tatsächlich berechtigungstechnisch. Wenn sie da einen Terminal haben, wie viel kann derjenige dort. Wollen sie, dass der alles kann?

Controller:

Nee. Je weniger, desto besser.

Produktion:

Ja, ja.

Berater:

Aber wie wollen sie es einschränken? Das ist jetzt eine Frage, mit der wir uns auch mal intensiv beschäftigen sollten. Ach so. Ich sag mal, wie schnell sind sie an einer Zeichnung für einen Konkurrenten von ihnen. Da guckt der rein und sagt, wieso, das was er da sieht. Wobei man aber auch jetzt sagen kann (--). Okay, die Frage ist, lassen wir es zu, dass er auf die Grunddaten kommt (--). Was kriegt er?

Die Zugriffsberechtigung ist ein zentraler Aspekt der Softwareimplementierung. Der Berater stellt die rhetorische Frage: „Wollen sie, dass der alles kann?“ Der Controller antwortet gemäß seiner Organisationsrolle. Die anschließende Äußerung des Produktionsleiters ist entweder eine sachliche Bestätigung oder ein etwas ironischer Kommentar auf die Antwort des Controllers („Je weniger, desto besser“). Dem Berater genügt keine der beiden Reaktionen. Er drängt die anwesenden Teilnehmer zu einer Antwort auf seine Berechtigungsfrage und fordert ihnen eine Entscheidung ab, indem er auf das Risiko für das Unternehmen hinweist, den ein uneingeschränkter Datenzugriff auf die Software mit sich bringen würde.

D IE

INDIVIDUALISIERTE

S OFTWARE

| 161

Im bisherigen Gesprächsverlauf wurde die Herstellung von Transparenz über Arbeitsabläufe als Lösung eines Organisationsproblems behandelt, wie Arbeitsabläufe mithilfe der Software effizienter gestaltet werden können. Nun wird die hergestellte Transparenz selbst zum Organisationsproblem, weil auch NichtMitglieder bzw. nicht autorisierte Personen Einblicke in Unternehmensdaten bekommen können. SEQUENZ 9 Berater:

Man könnte überlegen oder wir könnten uns überlegen, dass wir tatsächlich eine Konzepttransaktion machen, die ihm gar nicht die Möglichkeit bietet, irgendwo

nachzugucken.

Wenn

wir

den

Zeichnungsdruck schon hätten, dann hätte ich gesagt, mit dem Druck der Fertigungspapiere kommt automatisch meine Zeichnung. Vertrieb:

Keine Ahnung, da bin ich nicht wirklich informiert in diesem Moment.

IT:

Keine Ahnung.

Produktion:

Lassen sich mich damit in Ruhe, weil das ist nicht meine Baustelle. Das ist Chefsache. Und Chefsache, da halte ich mich raus. Da krieg ich immer einen Rüffel, wenn ich mich da einmische.

Berater:

Gut, gut. Weil dann können wir nämlich sagen, wir drucken von hier, stoßen den Druck an. Er kriegt die Fertigungspapiere inklusive der Zeichnungen, die dafür notwendig sind. Er hat morgens seine ganzen Sachen dort liegen und er kriegt nur noch die Rückmeldung ans Terminal. Nichts anderes mehr.

Der Berater macht in SEQUENZ 9 einen Vorschlag, wie man das zuvor formulierte Problem der Zugriffsberechtigung lösen könnte. Mit der von ihm vorgeschlagenen Konzepttransaktion wird eine Folge von Programmschritten zusammengefasst, die notwendig ist, um zuvor definierte Verknüpfungen von Datensätzen herzustellen und das Ergebnis dieser Datenverknüpfungen in einem bestimmten Format anzeigen zu lassen. Die Datensätze (Grunddaten), auf denen die Zusammenstellung von Daten in einem bestimmten Format (z.B. Fertigungspapiere) basiert, sind für den Softwarenutzer nicht einsehbar. Dem Softwarenutzer wird lediglich eine Benutzeroberfläche angezeigt, die „ihm gar nicht die Möglichkeit bietet, irgendwo nachzugucken“. Um die Personengruppe zu bezeichnen, die auf Daten zugreifen und sie verändern können, haben sowohl der Berater als auch die anderen Teilnehmer bislang Pronomen im Plural verwendet. Der Berater wechselt plötzlich in den Sin-

162 | D AS P ROJEKT SAP

gular: „Er kriegt die Fertigungspapiere“ und „[E]r kriegt nur noch die Rückmeldung ans Terminal“. Der Berater spricht nicht mehr länger über die Produktionsmitarbeiter des Busherstellers, sondern versucht, die Benutzerrolle „Externer Mitarbeiter“ im System der Software zu spezifizieren. Die Abbildung von Arbeitsabläufen in den Programmabläufen der Software funktioniert nur, wenn die Organisation selbst regelhaft beschreibbar ist. Die idealisierte Wirklichkeit des Organisationsmodells der Software schließt ein entsprechendes Verhalten der Softwarenutzer ein. Inwieweit ein adäquates Verhalten von Softwarenutzern vorausgesetzt werden kann, wird hier zum ersten und einzigen Mal problematisiert. Aufschlussreich ist die Sequenz auch deshalb, weil nicht nur über organisatorische Themen gesprochen wird, sondern die Organisation und ihre hierarchischen Strukturen in der Interaktion selbst sichtbar werden. So äußert sich der Produktionsleiter zum Entscheidungsproblem der Zugriffsberechtigung deshalb nicht, weil es nicht in seinem Zuständigkeits- und Kompetenzbereich liegt: „Das ist Chefsache [...] da halte ich mich raus“. Zu diesem Zeitpunkt wird die organisatorische Rahmung der Interaktion in der Interaktion selbst zum Thema gemacht. Die Teilnehmer der Interaktion sind Organisationsmitglieder. Die formale Mitgliedschaftsrolle ist entscheidend dafür, welche Entscheidungen von den Teilnehmern in der Interaktion für die Organisation überhaupt getroffen werden können. Eine typische Struktur einer Interaktion in Organisationen, die auch für die vorgestellte Beratungsinteraktion zutrifft, beschreibt Kieserling (1994: 173): „Viele Interaktionen beginnen [...] mit einer Frage und nähern sich ihrem Ende, sobald diese beantwortet oder wenigstens in Anschlußfragen kleineren Formats transformiert worden ist, die dann an einen anderen Kreis von Adressaten zu richten sind“. Auch der Berater leitet das Ende des Projekttreffens ein, indem er auf eine zentrale Aufgabe von Softwareberatern hinweist: die Erstellung eines Prototyps für die individualisierte Software. SEQUENZ 10 Berater:

Also, wenn wir jetzt noch feststellen wollen, ob das Ganze so gut ist, wie wir uns das vorstellen, müssen wir uns fast überlegen, einen Prototypen aufzubauen so auf die Schnelle. Weil da sind einige Fragen dabei, die kann ich jetzt so, ohne dass ich es getestet hab (-). Da kann ich mich jetzt auch nicht hinstellen. Das will ich ganz ehrlich sagen. Weil auch zu viele Detail-Dinge zu berücksichtigen sind. Also da wäre die Frage, ob wir uns die Mühe machen, das Werk 1100 anzulegen. Wir müssen ja nicht die ganze Stückliste, wir

D IE

INDIVIDUALISIERTE

S OFTWARE

| 163

können es ja vereinfacht halten. Und dann werde ich mal einen Kundenauftrag anlegen und das Ding durchsetzen.

Bei einem Prototyp handelt es sich um einen bestimmten Programmabschnitt im System der Software, der auf der Grundlage echter Unternehmensdaten und organisationsspezifischer Einstellungen getestet wird. Die in der Beratungsinteraktion bisher nur vage formulierten Anforderungen sollen mithilfe verschiedener Prototypen für einzelne Programmabläufe in weiteren Projekttreffen konkretisiert werden. Überdies soll überprüft werden, ob die beschriebenen Arbeitsabläufe kohärent und damit systemtechnisch überhaupt modelliert werden können. Auf diese Weise wird die Reaktion des technischen Systems auf Veränderungen des Organisationsmodells getestet. Die folgende vom Informatiker Frederick P. Brooks10 stammende Beschreibung trifft auch auf SAP-Software zu. „Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine“ (Brooks 2011: 199). Diesen Sachverhalt drückt der Berater allerdings ziemlich umständlich aus. Er unternimmt mehrere Anläufe, um die anwesenden Projektbeteiligten von der Notwendigkeit eines Prototyptests zu überzeugen und diesen zu rechtfertigen. Zunächst spielt er den Arbeitsaufwand für die Erstellung des Prototyps herunter („auf die Schnelle“). Dann thematisiert und begründet er wiederum den Aufwand („Mühe machen“). Offenbar tritt der Berater hier nicht bloß als Berater, sondern auch als Verkäufer einer Dienstleistung auf. In seiner Rolle als Verkäufer endet er taktisch klug mit dem Vorschlag, den Aufwand und damit die Kosten für die Erstellung des Prototyps möglichst gering halten zu können („wir können es ja vereinfacht halten“). Der Berater verwendet – wie an vielen anderen Stellen im Beratungsgespräch auch – ein inklusives Wir. Dadurch bringt er zum Ausdruck, dass er bei der Erbringung seiner Dienstleistung auf die Mitarbeit der Organisationsmitglieder angewiesen ist. Diese Leistung betrifft einerseits die Spezifizierung des Projektziels und andererseits die Planung des weiteren Ablaufs der Softwareimplementierung. Diese Planung setzt Entscheidungen der Organisation voraus. Das Ziel des Projekttreffens ist es, Entscheidungen zu treffen, die nicht bloß den Teilnehmern der Interaktion, sondern der Organisation zugerechnet werden kön-

10 Der IBM-Entwickler wurde mit The Mythical-Man Month. Essays on SoftwareEngineering (2011 [1975]) auch außerhalb von Fachkreisen in der Informatik bekannt. Das Buch zählt mittlerweile zu einem Klassiker der Projektmanagementliteratur. Brooks prägte den Satz: „Adding manpower to a late software project makes it later“ (ebd.: 25).

164 | D AS P ROJEKT SAP

nen. Es geht also um Organisationsentscheidungen als Output der Interaktion. Im nächsten Kapitel wird es darum gehen, dass Organisationsentscheidungen auch Input für die Interaktion zwischen Softwareberater und anderen Projektbeteiligten sind. Die beratene Organisation gibt nämlich den Rahmen vor, wie die Zusammenarbeit zwischen Organisationsmitgliedern und externen Beratern organisiert werden soll. Entscheidungen über das Customizing der Standardsoftware werden in sozialer, zeitlicher und sachlicher Hinsicht vorstrukturiert.

7. Die Projektorganisation: Entscheidungen als Input

Den Beratungsauftrag im Rahmen einer Softwareimplementierung fasst ein Interviewpartner lapidar zusammen: „Dann sagt man also, so und so sieht das aus und da wollen wir hin“. In Wirklichkeit gehen der Einführung von SAP ein aufwendiges Softwareprojekt und zahlreiche Organisationsentscheidungen voran. Ein Team aus Softwareberatern und ausgewählten Organisationsmitgliedern operiert außerhalb der etablierten Organisation des Kundenunternehmens und des Beratungsunternehmens und formt eine eigene Projektorganisation. Für die Auswertung des Interviewmaterials, das in diesem Kapitel vorgestellt wird, verwende ich das Dreierschema: 1) Teilnehmer, 2) Termine und 3) Themen. Diese Heuristik basiert auf der Luhmannschen (1971; 2011) Unterscheidung zwischen sozialen, zeitlichen und sachlichen Sinndimensionen.1 Bevor das empirische Material vorgestellt wird, soll dieses Schema kurz erläutert werden. 1) Teilnehmer als sozialer Faktor: Es macht einen Unterschied, welche Personen am Softwareprojekt beteiligt sind und in Beratungsinteraktionen teilnehmen. Organisationen entscheiden im Vorhinein darüber, welche Personen in welchen Organisationsrollen an welchen Beratungsinteraktionen teilnehmen. 2) Termine als zeitlicher Faktor: Organisationen entscheiden im Vorfeld darüber, wann Beratungsinteraktionen stattfinden sollen und wie lange sie dauern dürfen.

1

Luhmann (2011: 229) kommentiert die Unterscheidung von Sinndimensionen an einer Stelle so: „Ohne irgendeine vernünftige Begründung habe ich einmal angefangen – und bis heute habe ich dafür noch keine vernünftige Begründung – zwischen sachlichen, zeitlichen und sozialen Sinndimensionen zu unterscheiden. [...] Der Begriff entfaltet sich nicht von selber in diese Dimensionen, sondern ist phänomenologisch so gesetzt.“

166 | D AS P ROJEKT SAP

Beginn und Ende von Beratungsinteraktionen werden durch die Organisation festgelegt. Sie müssen innerhalb regulärer Arbeitszeiten stattfinden und mit anderen Arbeitsterminen koordiniert werden. 3) Themen als sachlicher Faktor: Tagesordnungspunkte auf der Agenda geben den Verlauf eines Beratungsgesprächs in sachlicher Hinsicht weitgehend vor. Organisationen entscheiden im Vorfeld darüber, was zum Thema der Interaktion gemacht werden soll und in welcher Reihenfolge Themen behandelt werden. Das Projektziel wirkt entsprechend strukturierend auf Beratungsinteraktionen, die auf spezifische Themen und Entscheidungsprobleme zugeschnitten sind. Von Organisationsmitgliedern kann zwar hinter vorgehaltener Hand noch darüber diskutiert werden, ob nicht besser ein anderes ERP-System eingeführt sollte oder Bestellungen von Kunden weiterhin in Papierform bearbeitet werden sollten. Für Projektmitglieder bzw. Teilnehmer von Beratungsinteraktionen sind Äußerungen dieser Art jedoch indiskutabel. Anders als in der geselligen Interaktion, bei der sich Reihenfolge und Relevanz der zu behandelnden Themen aus der laufenden Interaktion ergeben, ist für die Teilnehmer des Beratungsprojektes eindeutig, welche Themen bei Projekttreffen und in anderen Interaktionsformaten (z.B. Workshops, Eskalationsund Prototypingsitzungen) besprochen und vor allem welche Themen nicht diskutiert werden sollen (vgl. Kieserling 1999: 373; Seidl 2005: 145ff.). Ein Softwareprojekt umfasst verschiedene Interaktionsformate in der Organisation, die sich hinsichtlich Themen, Teilnehmer und ihrer zeitlichen Abfolge und Dauer unterscheiden. Auf die Bandbreite verschiedener Interaktionsformate im Rahmen der Beratung und Implementierung der Software soll im folgenden Abschnitt genauer eingegangen werden.

7.1 E NTSCHEIDUNGEN

ÜBER I NTERAKTIONSFORMATE

Das in in KAPITEL 6 vorgestellte Projekttreffen ist in eine umfassende Projektorganisation eingebettet. Das Treffen repräsentiert eines unter vielen anderen Interaktionsformaten. Typische Formate sind in den folgenden Interviewausschnitten kursiv gesetzt. INTERVIEWPARTNER M: „Im Kick-off-Meeting müssen sich die Leute erst einmal beschnuppern, Spielregeln festlegen, Ziele des Projektes festlegen, Erwartungshaltung und so weiter. Und dann gibt es natürlich innerhalb der Projekte ganz unterschiedliche Sachen, die da aufgesetzt werden. Manchmal sind es nur gemeinsame Projekttage, das wenigstens verabredet wird, wir sind alle dienstags da. Es ist notwendig, dass wir uns zusammensetzen können. Projekttreffen sind nicht immer notwendig, aber dass wir dienstags immer die

D IE

INDIVIDUALISIERTE

S OFTWARE

| 167

Chance haben uns zusammenzusetzen. Man hat alle zwei oder drei Wochen eine bestimmte Projektroutine. Da sitzen dann alle Berater an einem Tisch. Und ab und an sind dann auch die Key-User dabei. Es gibt auch Meetings, wo nur die Projektleiter zusammensitzen. Und dann gibt’s natürlich die One-and-one-Treffen vom Berater mit seinem Key-User.“

Ein anderer Berater ergänzt diese Auflistung der verschiedenen Interaktionsformate. INTERVIEWPARTNER K: „Bei uns haben wir derzeit alle 14 Tage einen Arbeitskreis, der sich aus den Abteilungsleitern der Organisationsabteilung und unserer Projektleitung zusammensetzt. Dort haken wir nicht nur Budgets ab, sondern wir sprechen über alle Integrationsthemen. Also das ist das Steuerungsgremium des Projektes, das als Integrationsstelle und als Schiedsstelle fungiert. Dann ist es so, dass es darüber hinaus einen Lenkungskreis gibt. Man hat mehr Hierarchien und man ist sehr schnell in der Breite, weil einfach eine höhere Anzahl von Menschen miteinander kommunizieren muss.“

Oft erfährt man bereits über die Selbstbeschreibung der Interaktion, wie die Kommunikation von den anwesenden Teilnehmern der Interaktion thematisch strukturiert wird (z. B. Eskalationssitzung oder Prototypingsitzung) oder die Selbstbeschreibung informiert über den Teilnehmerkreis der Interaktion (z. B. Steuerungsgremien und Lenkungskreise). Der Lenkungskreis gilt als höchstes Organ in der Projektorganisation einer Softwareimplementierung und ist in der Regel mit Teilnehmern besetzt, die der Geschäftsleitung der beratenen Organisation und dem Management des Beratungsunternehmens angehören. Konflikte während der Softwareimplementierung zwischen Organisationsmitgliedern, aber auch zwischen Beratern und Beratenen werden qua Entscheidung in diesen Interaktionsformaten beendet. Der Begriff Lenkungskreis wird in der Projektmanagementliteratur oft verwendet. Er setzt sich aus zwei Komponenten zusammen. Die erste Komponente (Lenkung) impliziert, dass eine Richtung vorgegeben wird. Die zweite Komponente (Kreis) hebt die Richtung wieder auf bzw. führt zur Ausgangsposition zurück. Diese Widersprüchlichkeit auf semantischer Ebene kann oft auch auf einer strukturellen Ebene beobachtet werden. In der anwendungsorientierten Literatur über Projektmanagement wird das Verhältnis der Projektorganisation (temporäre Organisation) und der Linienorganisation (permanente Organisation) als Dilemma diskutiert bzw. in seiner „Dualität zweier konkurrierender und grundsätzlich konfliktträchtiger Hierarchieprinzipien“ (Heintel & Krainz 2001: 15) beschrieben. Ein zentrales Problem der Projektorganisation kann darin gesehen werden, dass Projektleiter nicht oder nur begrenzt mit Weisungsbefugnissen ausgestattet sind. Die Organisationshier-

168 | D AS P ROJEKT SAP

archie schlägt im Konfliktfall die Projekthierarchie (vgl. Kühl 2011: 106). Mit einem demonstrativen Verweis auf ihre hierarchische Position im Unternehmen können Vorgesetzte in Diskussionen zwischen Projektbeteiligten eingreifen und damit Konflikte beenden bzw. diese für beendet erklären. Die Situationsdeutung obliegt dem Ranghöheren. Er oder sie kann also darüber entscheiden, wann eine „Diskussion zu Ende diskutiert [ist]“.2 Interviewpartner Q thematisiert die Schwäche der Projektorganisation gegenüber der Organisationshierarchie folgendermaßen: INTERVIEWPARTNER Q: „Also die Mäuerchen um die einzelnen Module, wer jetzt nicht so direkt immer an dem Projekt beteiligt ist, sind manchmal doch noch da. Also wir haben ja immer noch Dinge, die wir optimieren müssen und da manche Fürsten halt in den einzelnen Abteilungen, die halt Chefs sind, sagen dann nicht mein Bereich, nicht mein Bereich und das interessiert mich alles nicht. Das ist halt manchmal immer noch da. Aber SAP verlangt das einfach ne. SAP sagt, das ist ein integratives System durch alle Module durch und dann müsst ihr halt zusammenarbeiten.“

Im nächsten Kapitel soll auf die soziale Dimension der Projektorganisation genauer eingegangen werden, d.h., die personelle Zusammensetzung des Softwareprojektes steht im Vordergrund.

7.2 S OZIALE F AKTOREN : P ROJEKTTEILNEHMER IHRE E RWARTUNGEN

UND

Die Projektorganisation setzt sich aus Organisationsmitgliedern der beratenen Organisation (Abteilungsleiter, Sachbearbeiter, Geschäftsführer etc.) und Softwareberatern (Modulberatern, Modulentwicklern, Projektleitern, Teilprojektleitern) eines oder mehrerer externer Beratungsunternehmen zusammen. Was von ihm und seinen Kollegen und Kolleginnen im Rahmen einer Softwareimplementierung von der Organisation erwartet wird, erläutert Berater A. INTERVIEWPARTNER A: „Also der Kunde will ja erst mal seine Prozesse selber in den Griff kriegen. Am Anfang bekomme ich immer Aussagen zu hören nach dem Motto: Wir wollen nicht, dass ihr uns SAP aufdrückt. Also wir wollen das nicht so machen. Also er-

2

Dieser Ausspruch stammt vom Projektleiter einer Hochschule während eines Workshops mit Softwareberatern und anderen Projektmitgliedern im Rahmen eines SAP-Implementierungsprojektes (vgl. Mormann & Willjes 2013: 36).

D IE

INDIVIDUALISIERTE

S OFTWARE

| 169

zählt uns bitte nicht, wie SAP funktioniert. Wir wollen erstmal von dem ausgehen, was wir hier machen und dann sagt ihr uns, wie der Markt, wie andere das machen. Und dann guckt mal, wie wir es hier machen.“

Es geht um die Beschreibung organisationsspezifischer Arbeitsabläufe; die Arbeitsabläufe des Unternehmens sollen nicht durch die in den Programmabläufen der Standardsoftware vordefinierten Prozesse bestimmt werden. „Wir wollen nicht, dass ihr uns SAP aufdrückt“, ist das Losungswort, nach dem im Implementierungsprojekt zwei Parteien unterschieden werden: „wir“ (Organisationsmitglieder) versus „ihr“ (Softwareberater). Softwareberatern wird zum einen ein Expertenwissen zugesprochen, das die technische Funktionalität der Software betrifft. Zum anderen sollen Berater über das Wissen darüber verfügen, wie andere Organisationen ihre Arbeitsabläufe mithilfe der Software gestalten. Dieser zweiten Wissensform, so zumindest die Einschätzung von Interviewpartner A, gibt der Kunde sogar den Vorrang. Zu den Aufgaben des Softwareberaters sagt Interviewpartner D: „Zum einen musst du natürlich, also die Anforderungen vom Kunden müssen abgedeckt sein. Parallel dazu schaust du dir das aber im SAP an. Du hast so einen Riesenkatalog, da hast du wirklich im Prinzip, da drinnen hast du den Standard oder, wie soll ich sagen, (--) die Prozesse, eigentlich die optimierten Prozesse. Was wirklich quasi von verschiedenen Firmen, von verschiedenen Projekten, da eigentlich reingeflossen ist. Dann hat man so eine Bibliothek gemacht, so einen Prozesskatalog. Und dann versucht man natürlich beim neuen Kunden jetzt möglichst viel davon wiederzuverwenden. Weil zum einen kannst du dann sagen, das da drin, das ist eigentlich Best Practice oder das ist das, was im Prinzip andere große Kunden erfolgreich auch verwenden, was sich bewährt hat. Zum zweiten sind die Prozesse, so wie sie da drin stehen, die kannst du dann eben bereits vorkonfiguriert in SAP haben. Das heißt, je mehr du davon nehmen kannst, desto weniger musst du nachher noch anpassen im SAP.“

Scheinbar geht es in der Softwareberatung gar nicht in erster Linie darum, wie Kundenanforderungen abgedeckt, sondern wie sie aufgedeckt werden.3 Die Selbstdarstellung von Interaktionsteilnehmern wird von Luhmann als soziale Unsicherheitsabsorption bezeichnet. Ihre Funktion für das soziale System der Interaktion erläutert er folgendermaßen: „Wer es fertig bringt, als sicher zu erscheinen, gewinnt Vertrauen und Achtung. Er produziert Informationen, an

3

Vgl. hierzu die Analyse der Gesprächssequenzen von Berater und Organisationsmitgliedern in KAPITEL 6.1 „Konkretisierung der Anforderungen“.

170 | D AS P ROJEKT SAP

denen sich andere orientieren. Darin liegt einer jener automatischen Stabilisatoren, welche die elementare Sozialordnung [z. B. die Beratungsinteraktion: H. M.] ausbalancieren, indem sie zugleich Persönlichkeitsfunktionen und soziale Funktionen erfüllen [...]“ (Luhmann 1964a: 189). Die von Odo Marquard (1974: 341ff.) stammende Wortschöpfung Inkompetenzkompensationskompetenz bringt auf den Punkt, was ein Softwareberater über seine Rolle in der Interaktion mit Organisationsmitgliedern der beratenen Organisation berichtet. INTERVIEWPARTNER C: „Da sind Sachen um mich rumgeflogen, die habe ich nie, die habe ich nicht verstanden. Und dann musst du dich halt, das ist so ein bisschen die Kunst, du musst dich halt immer gut verkaufen. Also wenn der Kunde mal den Eindruck hat, dass du gar nichts weißt, dann ist das halt schlecht als Berater. Und das ist aber auch ganz interessant. Also mir hat das am Anfang einen Riesenspaß gemacht. Am Ende habe ich dann gesagt, das ist ja eigentlich katastrophal, weil die zahlen einen Haufen Geld dafür, dass da ein Experte kommt und das ist gar kein Experte. Und außerdem erzeugt das auch sehr viel Stress.“

Der Berater unterscheidet zwischen der Darstellung von Expertenwissen und der Zuschreibung von Expertenwissen. Er tut dies nicht nur am Beispiel anderer, sondern auch an seiner eigenen Person. Weil die Kunden von ITDienstleistungen in den vergangenen Jahren ebenfalls Expertenwissen aufgebaut haben, seien auch die Erwartungen an die Kompetenzen von Softwareberatern gestiegen. INTERVIEWPARTNER C: „Die Berater haben profitiert davon, also der Markt ist ja Ende der 90er Jahre explodiert. Da sind ja abstruse Gehälter bezahlt worden. Also wirklich, die haben auch vor Jahren schon Leute gehabt, habe ich mal gesagt, die fahren durch irgendwelche Kneipen, gehen rein und fragen, kann jemand SAP und dann bist du Experte. Jetzt ist es dann aber so, da wird der Kunde sagen, Moment jetzt kommt hier jemand, der kann das gar nicht. Der hat gar keine Erfahrung damit. Merkt er sofort. Und dann wird die Luft dünn für die ganzen vielen, die einfach auf diesen schönen Zug aufgesprungen sind.“

Zwar ist diese Vorgehensweise bei der Rekrutierung von Beratern überzeichnet, das Expertenwissen der Softwareberater allerdings treffend problematisiert. Dieses wurde in der Vergangenheit von den Kunden nicht infrage gestellt. Mittlerweile fordern Kunden vor Projektbeginn Beraterprofile an, die darüber Auskunft geben, in welchen Branchen und Unternehmen der Berater die Software bereits implementiert und welche Projektrolle er dabei übernommen hat. Die Bedeutung

D IE

INDIVIDUALISIERTE

S OFTWARE

| 171

der Profildaten des Beraters für den Kunden erklärt ein Projektmitglied auf der Organisations- bzw. Kundenseite folgendermaßen: INTERVIEWPARTNER P: „Wir wollen keine Berater, denen wir erst erklären müssen, wie es im Unternehmen läuft. Sondern wir gehen davon aus, dass da Leute kommen, die genau wissen, wie das in anderen Unternehmen und auch in anderen Branchen funktioniert. Wir wollen schon ganz genau wissen, mit wem wir es eigentlich zu tun haben. Dafür gibt es Beraterprofile, die wir auch fordern. Das steht drin: Wie lange sind die schon im Geschäft, welche Themen haben die in anderen Projekten, in anderen Unternehmen schon realisiert.“

In der Interaktion zwischen Berater und Organisationsmitgliedern werden zwei verschiedene Wissensarten miteinander in Beziehung gesetzt. Es geht um Softwarewissen von Beratern und Organisationswissen von Organisationsmitgliedern. INTERVIEWPARTNER A: „Unsere Berater kommen mehr von der Modulseite. Die kennen sich in ihrem Modul super aus. Sagen, okay, kann man so und so lösen. Die und die Konzepte machen wir so und so und so und dann muss man das da und da so einstellen. Der Kunde kommt mehr von der Geschäftsprozessseite. Der weiß ja am besten, wie sein Laden funktioniert. Die kommen aus dem Geschäftsleben während unsere Berater mehr von der Technik kommen. Und beide müssen jetzt aufeinander zugehen. Das funktioniert mehr oder weniger gut.“

Das Softwarewissen („Modulseite“) und das Organisationswissen („Geschäftsprozessseite“) wird von diesem Projektleiter auf Beraterseite als gleichrangig beschrieben. Die Wissensarten können nicht aufeinander reduziert werden. Ein anderer Berater bringt hingegen zum Ausdruck, dass er sein fehlendes Organisationswissen durch Softwarewissen kompensiert. INTERVIEWPARTNER C: „Als SAP-Berater musst du das System einigermaßen verstehen. Na ja, wir sind Experten halt im Rahmen des SAP-Systems, aber es gibt auch noch eine reale Welt. Ich weiß von Fertigung nicht so viel, aber ich guck dann, was das System da hergibt.“

Der Vergleich zwischen den Programmabläufen im System der standardisierten Software und den Arbeitsabläufen der „reale[n] Welt“ (ebd.) ist ein zentraler Bestandteil der Softwareberatung. Berater verwenden bei ihrer Vergleichsarbeit ei-

172 | D AS P ROJEKT SAP

ne besondere Methode: das Prototyping.4 Es ist eine Methode aus der Softwareentwicklung, die in den Interviews mit Softwareberatern oft als „ganz normale Projektarbeit“ beschrieben wird. Die Anfertigung verschiedener Prototypen der Software erfolgt in der Realisierungsphase. Der Modulberater erstellt den Prototyp für ein einzelnes Softwaremodul oder für einen bestimmten Programmabschnitt innerhalb eines Moduls, indem er bestimmte Einstellungen im System der Standardsoftware vornimmt. Der Key-User, der bereits beim Aufbau des Prototyps beteiligt war und die Software auch in Zukunft in seinem Arbeitsalltag verwenden soll, stellt diesen Prototyp normalerweise einem organisationsinternen Publikum vor. Solche Interaktionssituationen werden häufig zum Schauplatz für Diskussionen über die zukünftige Verwendung der Software und zum Austragungsort für eine Reihe organisationsinterner Konflikte. Die Teilnahme der Geschäftsführung an der Prototypen-Vorstellung und die damit zum Ausdruck gebrachte organisatorische Rahmung des Beratungsprojektes, ist von wesentlicher Bedeutung für den sozialen Prozess der Implementierung. INTERVIEWPARTNER K: „Wir möchten gerne, dass die Geschäftsleitung dabei sitzt. Das funktioniert, das funktioniert aber auch teilweise nicht. Dann sitzen dort Abteilungsleiter und teilweise auch Mitarbeiter aus den Abteilungen. Das sind dann auch wirklich die, die mit dem Ding arbeiten sollen. Jeder hat so seine eigene Sicht, jeder hat seine eigene Anforderung. Der eine sieht nur seinen eigenen kleinen Bereich, in dem er arbeitet. Abteilungsleiter und Geschäftsführer sehen das gesamte Unternehmen. [...] Es gibt teilweise die wildesten Diskussionen. Es gibt teilweise richtig Zoff, weil auch dort sehr prekäre, sehr emotional geladene Dinge in diesen Runden präsentiert werden. Wo auf einmal jemand merkt, wenn das so und so abläuft, dann sieht mein Arbeitsplatz und mein Umfeld ganz anders aus. Da gibt es auch teilweise Ängste. Wenn die das so und so machen, dann bin ich auf einmal nicht mehr notwendig. [...] Das merkt man in diesen Diskussionen dann schon, dass so was auch eine Rolle spielt, dass diese nicht-fachlichen Sachen eine große Rolle spielen, wo es dann wirklich um Kämpfe geht, wo man Aufgaben hin und her schiebt.“

Für den Berater spielen die Teilnehmer der Interaktion, die „dann auch wirklich [...] mit dem Ding [der Software: H. M.] arbeiten sollen“ (ebd.), eine eher untergeordnete bzw. Komparsenrolle. Die Mitglieder der Geschäftsleitung hingegen besetzen eine zentrale Rolle und dies in verschiedener Hinsicht: Die Anwesen-

4

Vergleiche hierzu die Ausführungen in KAPITEL 7.4 „Prototyping und andere Strategien der Angleichung“.

D IE

INDIVIDUALISIERTE

S OFTWARE

| 173

heit (bzw. Abwesenheit) der Geschäftsleitung signalisiert dem organisationsinternen Publikum die strategische Bedeutung der Softwareimplementierung für das Unternehmen (interne Signalfunktion). Außerdem werden die Key-User, die den Prototyp für die Programmabläufe in ihrem Fachbereich vorstellen, angespornt, die Benutzung der Software ausreichend einzuüben. Niemand will sich schließlich vor einem Publikum und schon gar nicht vor der Geschäftsführung blamieren (Funktion der Teilnehmermotivation). In seiner Beschreibung weist Berater K überdies auf ein grundlegendes Problem bei der Einführung einer abteilungs- und bereichsübergreifenden Standardsoftware wie SAP hin: „Jeder hat so seine eigene Sicht, jeder hat seine eigene Anforderung“. Um dieses generelle Organisationsproblem zu lösen, schlägt er vor, die Entscheidungen über das Customizing der Standardsoftware den Abteilungsleitern und Geschäftsführern in der Organisation zu überlassen. Aufgrund ihres Überblickswissens seien sie in der Lage organisatorisch rationale Entscheidungen zu treffen. Der Berater bringt damit eine Vorstellung von Organisationen als zerlegbare Entscheidungssysteme zum Ausdruck, die in den Ingenieurwissenschaften verbreitet ist. Hiernach ist das Management der Organisation (d.h. Geschäftsführer und Abteilungsleiter) prinzipiell in der Lage, die Organisation als Gesamtsystem zu gestalten.5 Als Rechtfertigung für die Entscheidung der Implementierung von SAP gelten rationale Gestaltungsmöglichkeiten. Ausnahmslos alle interviewten Softwarenutzer und -nutzerinnen haben in diesem Zusammenhang das Adjektiv vernünftig verwendet. Inwieweit diese Möglichkeiten tatsächlich ausgenutzt werden, wird von vielen Interviewpartnern und Interviewpartnerinnen allerdings eher skeptisch betrachtet. So auch vom Berater K, der die Präsentation der Software als Ort beschrieb, wo Konflikte schwelen. In Organisationen werden Konflikte dann offen ausgetragen, wenn es sich die Konfliktteilnehmer aufgrund ihrer leitenden Position in der Organisation leisten können, sie sich zuvor bei ihrem Vorgesetzten abgesichert oder zumindest mit mehreren Kollegen abgestimmt haben. Luhmann beschreibt die organisatorische Rahmung konfliktträchtiger Interaktionen so: „Die formale Organisation bestimmt in mannigfacher Weise die Topographie der Landschaft, in der sich die Manöver bewegen. Man begegnet sich überhaupt nur als Mitglied einer formalen Organisation. Die Erhaltung der Mitgliedschaft und damit die Anerkennung der formalen Organisation ist die Basis auch für alle Konflikte.“ (Luhmann 1964a: 245)

5

Vergleiche hierzu „Die Systemperspektive“ von Simon in KAPITEL 4.3.3.

174 | D AS P ROJEKT SAP

Sich selbst sieht Berater K in der beschriebenen Interaktionssituation eher als Zaungast. Es sind „die Leute“ und ihre Kämpfe und Ängste, die er aus der Distanz beobachtet. Im weiteren Verlauf des Interviews führt derselbe Berater den Projekterfolg allerdings primär auf die „persönliche Beziehung“ zwischen Softwareberater und Kunden zurück. INTERVIEWPARTNER K: „Die persönlichen Beziehungen sind das ganz Entscheidende. In dem Projekt ist sehr stark der Nasenfaktor entscheidend. Die Chemie muss stimmen. Es ist nicht nur so, dass man das Gefühl haben muss, der kann das fachlich abbilden. Das Fachliche ist sicher auch ein wichtiger Grund, aber ganz wichtig ist eben auch, dass die Chemie zwischen dem Berater und dem Kunden stimmt.“

Die Beziehung zwischen Berater und der beratenen Organisation („der Kunde“) wird hier in doppelter Hinsicht personalisiert. Einerseits handelt es sich um eine semantische Vereinfachung, denn es gibt im Beratungsprojekt nicht den Kunden. Es sind verschiedene Organisationsmitglieder, die dem Berater in der Beratungsinteraktion als Key-User gegenübertreten. Ein Key-User vertritt nicht unbedingt die Organisation, sondern meistens einen bestimmten Fachbereich in der Organisation: „Jeder hat so seine eigene Sicht, jeder hat seine eigene Anforderung“. Diese verschiedenen Anforderungen können im Widerspruch zueinander stehen. Andererseits kommt es nicht nur auf die Qualifikation und die Berufserfahrung des Beraters („der kann das fachlich abbilden“) an. Bei der Beurteilung der Beratungsleistung spielt die Persönlichkeit des Beraters („Nasenfaktor“; „Chemie muss stimmen“) eine zentrale Rolle. Gleichwohl bleibt die Beziehung zwischen Berater und Key-User eine professionelle Rollenbeziehung. Persönliche Beziehungen (z. B. Freundschaften) zeichnen sich dadurch aus, dass sie funktional diffus sind. Sie lassen keinen Personalwechsel zu, denn sie sind an die Person gebunden (vgl. Lenz & Nestmann 2009: 10). In Softwareberatungsprojekten ist letztlich sowohl der Berater als auch der Key-User austauschbar, auch wenn Berater ihre Austauschbarkeit bestreiten. INTERVIEWPARTNER M: „Dem Kunden ist es egal, welches Unternehmen hinter dem Berater steht und an wen er letztendlich die Rechnung bezahlt. Hauptsache ist, dass er wieder den Berater bekommt, mit dem er schon einmal erfolgreich zusammengearbeitet hat, den er kennt und dem er vertraut.“

Nicht das Vertrauen in die Person des Beraters, sondern das Vertrauen in die Rolle des Beraters und seine Kompetenz als Berater ist für die beratene Organisation letztlich entscheidend. Deshalb kann auch die Beschreibung der Rollenbe-

D IE

INDIVIDUALISIERTE

S OFTWARE

| 175

ziehung von Berater und Kunde als „persönliche Beziehung“ nicht darüber hinwegtäuschen, dass es zunächst und vor allem ein formales Verhältnis zwischen Auftragnehmer (Beratungsunternehmen) und Auftraggeber (beratene Organisation) ist, das die Interaktion strukturiert. Dass der Berater mitunter von seinem Arbeitgeber, dem Beratungsunternehmen, an dieses formale Verhältnis erinnert werden muss, kommt vor. INTERVIEWPARTNER J: „Wir haben zum Beispiel das Problem, was nicht in unserem Vertrag liegt, das ist auch nicht unsere Aufgabe. Das müssen wir ganz klar an den Kunden kommunizieren. Klar, auf gesetzlicher Ebene sind wir auf der richtigen Seite, aber du bist als Berater immer auch in der Rolle, weil du das schon ein paar Mal gemacht hast, dem Kunden auch zu helfen.“

Das formale Auftragsverhältnis birgt für den Berater ein gewisses Konfliktpotenzial. So wie der Arzt den Patienten im Notfall behandelt, ohne nach der für die Bezahlung zuständigen Krankenkasse zu fragen, fühlt sich anscheinend auch ein Softwareberater dazu verpflichtet, seinem Kunden zu helfen. Ein gegensätzliches Bild dazu zeichnet Berater D. Er beschreibt die Softwareimplementierung als Belehrung und rein technisches Vorgehen. INTERVIEWPARTNER D: „Das heißt, wir zeigen euch, was drin ist und ihr zeigt, wie eure jetzigen Prozesse aussehen und wir überdecken das dann. Da wo wir Abweichungen haben, überlegen wir, ob wir die Abweichungen noch in den Standard reinbringen können oder ob wir sagen, das ist halt so. Arbeitet mit Legacy-Systemen [Altsysteme: H. M.] oder mit der Hand weiter, aber das ist das, was ihr bekommt.“

Im nächsten Kapitel wird gezeigt, wie der Zeitfaktor die Projektarbeit und die Entscheidungen der Organisation über die Individualisierung der Standardsoftware strukturiert.

7.3 Z EITKNAPPHEIT ALS KONSTITUTIVES M ERKMAL VON S OFTWAREPROJEKTEN Termine und Fristen spielen für die Implementierung der Standardsoftware und ihre Individualisierung eine zentrale Rolle. Auf diesen Zusammenhang soll auf den nächsten Seiten anhand weiterer Interviewpassagen eingegangen werden. Zeit wird in diesen Beschreibungen vor allem als Zeitknappheit thematisiert. Die zeitliche Befristung von Softwareprojekten stellt ein konstitutives Merkmal dar,

176 | D AS P ROJEKT SAP

denn die Projektorganisation löst sich auf, sobald das Projektvorhaben abgeschlossen bzw. das Projektziel erreicht ist. Für Berater allerdings folgt ein Projekt auf das nächste. Softwareberater sind darauf angewiesen, darüber informiert zu werden, wann sie mit den Beiträgen von Beraterkollegen und Mitarbeitern der beratenen Organisation rechnen können. Mit den Kollegen, die für das Customizing anderer Softwaremodule zuständig sind, müssen beispielsweise technische Schnittstellen aufeinander abgestimmt werden. Key-User in den verschiedenen Fachabteilungen müssen Datensätze in einer bestimmten Form aufbereiten und bis zu einem festen Termin zur Verfügung stellen. Dass Projektmitglieder auf der Kundenseite neben ihrer Projekttätigkeit normalerweise weiterhin in das Tagesgeschäft des Unternehmens eingespannt und nur selten, meist nur phasenweise davon freigestellt sind, erschwert die Terminkoordination zusätzlich. Dasselbe gilt auch für die Projektmitglieder auf der Beraterseite, die ihre Termine für Projektsitzungen mit den Terminen in anderen Beratungsprojekten abstimmen müssen. Für das Unternehmen, das im folgenden Interviewausschnitt beschrieben wird, ist nicht das kalendarische Jahresende für die Datierung des Projektendes entscheidend, sondern das Ende des Geschäftsjahres, das allerdings in vielen Unternehmen mit dem des kalendarischen Jahres zusammenfällt.6 INTERVIEWPARTNER K: „Das Projekt läuft jetzt seit dem 1. Mai und wird produktiv gesetzt zum 1.1. Der Berater sitzt pro Woche ein bis zwei Tage beim Kunden. Der sitzt also Vorort mit dem entsprechenden Key-User und bespricht sich. Er zieht sich dann auch schon mal teilweise zurück und versucht Lösungen für die Anforderungen zu finden. Im Normalfall sind es ein bis zwei Tage pro Woche. Der Kunde muss dann entsprechend auch anwesend sein und die Meetings vorbereiten und nachbereiten.“

Der Stichtag für den Abschluss der Projektarbeiten ist eine Vorgabe durch die beratene Organisation. Mitunter sind diese Vorgaben an gesetzliche Vorschriften gekoppelt. In jedem Fall sind Projekttermine an Organisationstermine geknüpft. Es ist die Organisation, die über Termine und Laufzeiten des Softwareprojektes entscheidet und so auch Beginn und Ende von Beratungsinteraktionen festlegt. Im geschilderten Fall handelt es sich um den Termin für die Bilanzeröffnung der

6

Das Geschäftsjahr eines Unternehmens kann auch vom Kalenderjahr abweichen. In vielen landwirtschaftlichen Unternehmen beginnt das Geschäftsjahr beispielsweise erst am 1. Mai. Um die Bilanzkontinuität als einen Grundsatz ordnungsgemäßer Buchführung zu erfüllen, müssen die einmal gewählten Stichtage für die Bilanzeröffnung und den Bilanzabschluss 12 Monate danach beibehalten werden (vgl. Coenenberg et al. 2012: 4).

D IE

INDIVIDUALISIERTE

S OFTWARE

| 177

Organisation, die mithilfe der SAP-Software und ihrer Module für das Finanzund Rechnungswesen erfolgen soll. Die generelle Zeitknappheit im Projekt wirkt sich auf die Anwesenheit des Softwareberaters beim Kunden vor Ort und damit auf die Gelegenheit zur Interaktion zwischen Key-User und Berater aus. Sobald über die konkrete Modellierung von Arbeitsabläufen im System der Software entschieden werden soll, sind Abstimmungen zwischen den verschiedenen Arbeitsbereichen in der Organisation und zwischen Modulberatern notwendig. Abstimmungen kosten jedoch Zeit. Mitunter wird die begrenzte Zeit im Projekt als eine Ausflucht benutzt, schwierige und umstrittene Themen auf einen späteren Zeitpunkt zu verschieben. Aufgrund des vorgegebenen Zeitplans ist thematisch nicht mehr alles möglich, was zur Anpassung der Software an die organisationsspezifischen Gegebenheiten möglich und sachlich sinnvoll wäre. Zeitknappheit kann darüber hinaus zu suboptimalen Entscheidungen zwingen. Ein Interviewpartner erzählt von einzelnen Modulen, deren Zusammenspiel nicht ausreichend getestet werden konnte, weil Projekte zu knapp kalkuliert worden waren. Um den angekündigten Termin trotzdem einzuhalten, seien sogar fehlerhafte Datenverknüpfungen riskiert worden. Normalerweise wechseln Softwareberater ihre Projekte häufig. Sie springen kurzfristig ein, ohne dass sie die konkrete Umsetzung der Softwareimplementierung und den Abschluss von Projekten miterleben oder verfolgen können. Das typische Projektgeschäft eines Beraters sieht so aus: INTERVIEWPARTNER L: „Die Leute werden laufend, werden on-the-fly aus dem Projekt rausgezogen, wenn sie irgendwo Freiräume haben. Andere Projekte kommen hinzu, das kann natürlich auch passieren. Es läuft irgendwie so weiter, man zieht Leute schon raus und fährt da runter, fährt da wieder rauf. Sobald ich aus einem Projekt raus bin, habe ich ja schon wieder eine andere Aufgabe. Da bin ich eigentlich schon wieder ganz weit weg.“

Mit dem Ausdruck „on-the-fly“ (ebd.) wird in der Computertechnik ein Vorgang bezeichnet, bei dem auf das dauerhafte Speichern von Daten im permanenten Datenspeicher verzichtet wird. Tatsächlich ist die Dokumentation der Beratungsleistung auf der Beraterseite ein vieldiskutiertes Thema in der Praxis (vgl. Mormann 2006: 80ff.). Die beratene Organisation wünscht sich eine möglichst umfangreiche Dokumentation zum Customizing der Standardsoftware. Man will sich so von einzelnen Beratern bzw. einem einzelnen Beratungsunternehmen unabhängig machen, um bei der nächsten Vergabe von Beratungsaufträgen in einer besseren Verhandlungsposition zu sein. Tatsächlich werden, so lautet eine allgemeine Klage von Mitgliedern der beratenen Organisationen, wenn überhaupt, die Einstellungen der Software nur lückenhaft und oberflächlich dokumentiert

178 | D AS P ROJEKT SAP

(ebd.). Berater werden oft bereits vor Projektabschluss abgezogen und können deshalb auch nicht für das endgültige Ergebnis der Projektarbeiten verantwortlich gemacht werden. Aufschlussreich ist die folgende Beschreibung eines Beraters, weil hier der Unterschied zwischen Ergebnisverantwortung und Prozessverantwortung (vgl. Schroer 2010: 30) illustriert wird. INTERVIEWPARTNER D: „Dann war das große Projekt bei H., wo ich dann sogar drei Jahre war, beim globalen Roll Out. Das war wirklich, da war ich wirklich von A bis Z dabei. Also quasi vor der Phase, wo du das Template baust, also dieses globale Template bis hin, wo es ausgerollt wurde. Also das Projekt hat, glaube ich, vier Jahre gedauert und ich war drei davon dabei. Ich war wirklich bis zum Schluss (--) also ich bin halt nicht geblieben bis das letzte Land live war. Aber ich bin, habe von daher wirklich alles gesehen, wie so was funktioniert und vor allem, es war auch spannend, weil die haben, die hatten wirklich nichts.“

Für D ist das Projekt im Unternehmen H. außergewöhnlich, weil er dort über einen längeren Zeitraum beteiligt gewesen ist. Mehrmals spricht er die lange Dauer seiner Beteiligung an. In seinen Erzählungen wird jedoch deutlich, dass sich das Ende seines Einsatzes vom Projektende („[...] bis das letzte Land live war.”) unterscheidet. Trotz dieser Inkongruenz ist D davon überzeugt, dass er „wirklich von A bis Z dabei“ (ebd.) gewesen ist. Zeit wird aus einer systemtheoretischen Perspektive als Medium der Kontingenzbewältigung betrachtet. Das für die Systemtheorie grundlegende Problem der Komplexität wird in einem frühen Aufsatz von Luhmann (1971) besonders anschaulich erläutert.7 Er verwendet die Unterscheidung zwischen sachlicher, sozialer und zeitlicher Sinndimension und schildert die Interdependenzen der Dimensionen folgendermaßen: „Die Sachstrukturen der Welt, nämlich die Eigenart unendlich vieler Dinge und Ereignisse, in bestimmter Weise und nicht anders zu sein, wäre unproblematisch, wenn zu ihrer Erforschung unbegrenzt Zeit zur Verfügung stünde oder Konsens garantiert wäre, so daß alles erfragt werden könnte. Konsensprobleme würden nicht auftreten, wenn die Zeit für kommunikative Verständigung unendlich wäre und die sachliche Struktur der Welt einfach.“ (Luhmann 1971: 145)

7

In KAPITEL 5.1 wurde dieses generelle Problem sozialer Systeme aus einer organisationstheoretischen Perspektive als Problem der Unsicherheitsreduktion expliziert.

D IE

INDIVIDUALISIERTE

S OFTWARE

| 179

Interdependenzen zwischen sozialen Faktoren (Projektteilnehmer) und zeitlichen Faktoren (Termine und Fristen) strukturieren Softwareberatungsprojekte inhaltlich und sorgen für die Anpassung der Organisation an die Technik. Wie sich die Verknappung der Zeit auf die Projektinhalte auswirkt, schildert Berater K so: „Wir experimentieren weniger. Das Fenster ist eng. Die Projekte werden generell sehr knapp und mit sehr dünnem Bleistift kalkuliert, so dass auch gar nicht viel Spielraum da ist.“ Welche Methode bei der Softwareimplementierung gewählt wird, um die Technik in einer Organisation einzupassen, schildere ich im nächsten Abschnitt.

7.4 P ROTOTYPING UND ANDERE S TRATEGIEN DER A NGLEICHUNG VON O RGANISATION UND T ECHNIK In den folgenden Interviewausschnitten wird die Vorgehensweise bei der Softwareimplementierung aus der Perspektive von Beratern geschildert: INTERVIEWPARTNER I: „Du fängst immer mit einem Workshop an, du fängst immer mit einem Blueprint an, wo halt gesagt wird, was will der Kunde überhaupt drin haben. Dann gehst Du rein in die Realisierungsphase, dann Prototypvorstellung, könnte dazu passen ja oder nein. Dann machst du so eine Schleife und dann gehst du wieder in die Feinumsetzungsphase rein. Dann gehst du in die Testphase mit dem Kunden rein und dann irgendwie in die Produktivstartvorbereitung, wo du dann Datenübernahme und dergleichen noch mit drin hast. Das sind so die klassischen Projektphasen, die immer mit drin sind. Was wir jetzt in einigen Bereichen ansetzen ist, dass wir diese Blueprint-Phase weglassen und dass wir sagen, wir gehen mit vordefinierten Lösungen einfach rein, mit Standards und der Kunde hat diese Standards einfach auch zu akzeptieren und zu nehmen.“

Die aufgeführten Phasen des klassischen Projektverlaufs sind mit jeweils unterschiedlichen Interaktionsformaten für Berater und Organisationsmitglieder verknüpft.8 Auf das Prototypingverfahren während der Realisierungs- und Feinumsetzungsphase soll im Folgenden genauer eingegangen werden. Der Begriff Prototyping bezeichnet ein Vorgehen in der Softwareentwicklung, bei dem nicht sofort ein endgültiges Softwareprodukt hergestellt wird, sondern zunächst ein oder mehrere Prototypen gebaut werden, an denen sukzessive Veränderungen oder Verbesserungen vorgenommen werden können. Was in der Softwareentwicklung

8

Vergleiche hierzu KAPITEL 7.1 „Entscheidungen über Interaktionsformate“.

180 | D AS P ROJEKT SAP

generell üblich ist, ist auch für die Implementierung einer Standardsoftware wie SAP typisch. INTERVIEWPARTNER L: „Prototyping in der Form, dass wir sagen, jetzt machen wir etwas mal fertig, dass es so ein Jugend forscht ist, das stellen wir jetzt mal fertig und das könnte es sein und wir stellen drei, vier Varianten vor, das ist es mit Sicherheit nicht. Also was man macht, ist in der Regel Prototyping in der Form, dass man das Meilenstein oder wirklich Prototyp eins, zwei, drei, vier nennt. Gerade im Automotive-Bereich sind es die Firmen gewöhnt, in Phasen zu arbeiten, weil wenn die ein Neuprodukt entwickeln, dann gibt es im Automotive immer so Qualitätsschritte oder Türchen. Quality Gates im Neuhochdeutsch. Und das kennen die. Dann wissen die, das ist eine Prüfung, da ist eine Abnahme und dann machen wir erst weiter. So bauen wir bei uns die Projekte auf.“

Die in der Softwareberatung verwendete Prototyping-Methode grenzt der Berater von etwas ab, das er etwas abschätzig als „Jugend forscht“ charakterisiert. Er meint damit eine Form des Prototypings, die einen explorativen Charakter hat. Das explorative Prototyping dient der Feststellung von Anforderungen und wünschenswerten Merkmalen eines Softwaresystems. Falls der Prototyp nicht über die gewünschten Merkmale verfügt, wird er verworfen und ein neuer Prototyp aufgebaut. Beim evolutionären Prototyping hingegen werden Folgeversionen erstellt, die von den potenziellen Nutzern bestätigt werden müssen. Softwarefunktionen werden nach und nach erweitert und im Austausch mit den Softwarenutzern weiterentwickelt (vgl. Schrage 2004).9 Vor allem in der Produktentwicklung der Automobilindustrie ist ein solches Vorgehen beliebt. Es geht nicht um die Partizipation des Kunden, sondern die Qualitätssicherung des Produktes steht im Vordergrund. Mit der Bezeichnung „Quality Gates“ passt sich der Berater den sprachlichen Gepflogenheiten dieser Branche an. Mittlerweile wird der Begriff auch in vielen Handbüchern über Projektmanagementmethoden verwendet (z.B. Prefi 2007; Sondermann 2007). Eingeführt haben ihn Automobilhersteller zur Bezeichnung von Produktionsabschnitten der Qualitätssicherung und -überprüfung. Das Projekt der Softwareimplementierung wird in verschiedene Phasen eingeteilt, an deren Ende der Projektfortschritt bzw. der Reifegrad der individualisierten Software festgestellt wird. Dafür werden vorab verschiedene Kriterien definiert, anhand derer der Grad der Fertigstellung des Prototyps gemessen werden soll. Für den Prototyp 1 werden beispielsweise Unternehmensdaten nur ausschnitthaft aufbereitet, damit

9

Christina Floyd und Reinhard Keil (1984: 4) unterscheiden zudem noch das experimentelle Prototyping, das für Forschungszwecke eingesetzt wird.

D IE

INDIVIDUALISIERTE

S OFTWARE

| 181

die Key-User ihre Daten im System der Software wiedererkennen und die Verarbeitung der Daten zumindest ansatzweise nachvollziehen können. Dafür werden u. a. Artikelnummern und echte Kundennamen verwendet. Die Überprüfung von Datenverknüpfungen im System der Software wird für den Prototyp 2 anhand von Materialstammdaten und Stücklisten des Unternehmens durchgeführt. Um vollständige Warenbewegungen im System der Software darstellen und testen zu können, werden im Prototyp 3 beispielsweise Kreditoren und Debitoren angelegt. Für den einen Berater ist die Vorstellung der einzelnen Prototypen besonders wichtig, weil auf diese Weise die Abnahme seiner bisherige Dienstleistung durch den Kunden erfolgt.10 Ein anderer Berater betrachtet die verschiedenen Prototypen eher als Test, inwieweit die Abstimmung zwischen verschiedenen Teilprojekten und ihren jeweiligen Mitgliedern funktioniert hat. INTERVIEWPARTNER M: „Aus mehreren Modulen muss das ja immer permanent zusammengeführt werden. Es gibt ja viele Teilbereiche, die zusammengeführt werden müssen und dann gibt es einen sogenannten Prototypentest. Das ist ein fixer Zeitpunkt, wo der Gesamtbestand, der momentan vorhanden ist, getestet wird. […] alle Elemente müssen irgendwie zusammengeführt werden, damit auch das Zusammenspiel zwischen den einzelnen Modulen klappt. Dafür hat man vorher ja auch Schnittstellen abgestimmt und hat Verfahren abgestimmt, wie die einzelnen Module sich zum Beispiel untereinander unterhalten, wie die Kommunikation ausschaut.“

Die organisationsspezifischen Einstellungen der Softwaremodule für einen Anwendungsbereich im Unternehmen werden von jeweils spezialisierten Modulberatern vorgenommen. Diese Anpassungen müssen nicht nur mit dem Key-User aus dem Fachbereich besprochen, sondern v. a. auch mit Beratern für andere Module abgestimmt werden. Dafür wird der Aufbau von Prototypen ebenfalls genutzt. Über sie lassen sich die Einstellungen der Programmabläufe in den unterschiedlichen Modulen überprüfen und falsche oder überflüssige Datenverknüpfungen im Gesamtsystem vermeiden. INTERVIEWPARTNER I: „Du hast 20 verschiedene Punkte, die abgearbeitet werden müssen. Für diese 20 Punkte musst du nachher einen kleinen Prototyp haben. Prototyp bedeutet für

10 Die Abnahme ist in § 640 Abs. 2 BGB gesetzlich geregelt und wird vertraglich zwischen der beratenen Organisation (Auftraggeber) und dem Beratungsunternehmen (Auftragnehmer) vereinbart. Nach einer Abnahme liegt die Beweislast für das Vorhandensein eines Mangels nicht mehr beim Auftragnehmer sondern beim Auftraggeber.

182 | D AS P ROJEKT SAP uns nicht, dass wir für alles ein eigenes System haben oder ein eigenes Modell, es ist einfach nur ein Prozess, der abgebildet werden muss. Für jeden Prozess hast du eigentlich einen eigenen Prototypen. Im Prinzip ist es ganz normale Projektarbeit, es hat einfach nur einen eigenen Namen bekommen.“

Die „20 verschiedene[n] Punkte“ (ebd.) sind das Ergebnis der Vergleichsarbeit von Beratern und Key-Usern. Es wird in der Interaktion zwischen Berater und Organisationsmitgliedern kommunikativ hergestellt. Mit Unterstützung der Berater fertigen die Organisationsmitglieder Beschreibungen von Arbeitsabläufen an, die mit den Programmabläufen der standardisierten Software verglichen werden. Ein Zielobjekt ist in einem Vergleich das, worüber etwas ausgesagt werden soll. Die Aussage wird anhand des Referenzobjekts getroffen. Obwohl die Projektteilnehmer die Software als Zielobjekt und die Organisation als Referenzobjekt vorstellen, erscheint der Zusammenhang zwischen Technik und Organisation in der Beratungsinteraktion genau umgekehrt: die Programmabläufe der Standardsoftware werden zum Referenzobjekt und die konkreten Arbeitsabläufe in der Organisation zum Zielobjekt gemacht. INTERVIEWPARTNER K: „Oftmals ist es so und das ist wirklich der Großteil, dass also wirklich die Leute in die Sitzungen reinkommen und wir erzählen lassen. Der Berater fragt, was kaufen sie denn alles ein – um jetzt bei dem Beispiel Einkauf zu bleiben. Dann erzählt der Key-User, die und die Materialien kaufe ich ein. Und dann läuft das wie in so einem Interview. Der Berater fragt weiter, dann machen Sie dies und dann machen sie das und dann zeigt er ihm schon im System oder einfach als Vorgabe, um ihn zu führen, so wird das im System abgebildet. Der Berater zeigt das dann also und dann ergibt sich so ein Wechselspiel, so nach dem Motto: Ich zeige Dir, wie wir das machen können und der Kunde sagt dann, da komme ich aber nicht ganz mit klar oder okay, das können wir so machen.“

Die Interaktion zwischen Berater und Key-User charakterisiert K zunächst als exploratives Interview („erzählen lassen“). In den folgenden Erläuterungen entsteht jedoch der Eindruck, dass es sich vielmehr um eine standardisierte Befragung durch den Berater handelt. Der Key-User informiert den Berater nicht über konkrete Arbeitsabläufe. Seine Aufgabe in der Prototypingsitzung besteht vielmehr darin, die vom Berater gemachten Vorschläge zur Abbildung seiner Tätigkeiten („dann machen sie dies und dann machen sie das“) lediglich zu bestätigen oder abzulehnen. Die Anforderungen der Organisation ordnen sich dem System der Standardsoftware bei der Beschreibung von Arbeitsabläufen unter. Der Spielraum für Entscheidungen über das Customizing der Standardsoftware und

D IE

INDIVIDUALISIERTE

S OFTWARE

| 183

die Anpassung der Software an organisationsspezifische Bedingungen werden dadurch eingeschränkt. Der Kunde entscheidet bloß noch darüber, ob der Programmablauf zum Arbeitsablauf passt (ja/nein), nicht aber darüber, inwiefern Anpassungen der Technik vorgenommen werden. Die Laufzeit des Projektes, so das Argument des Softwareberaters I, der zu Beginn des Kapitels ausführlich zitiert wurde, könne insgesamt verkürzt werden, wenn die Blueprint-Phase („was [...] der Kunde überhaupt drin haben [will]“) gestrichen wird. Die beratene Organisation spare so Projektkosten ein. Er schlägt vor, die Implementierung möglichst ohne die Mitwirkung der Organisation und ihrer Mitglieder umzusetzen. Er rechtfertigt dieses alternative Vorgehen mit der knappen Entscheidungszeit im Projekt und dem Kostendruck. Nicht die individuellen Anforderungen eines Unternehmens sollen beim Customizing der Standardsoftware berücksichtigt werden, sondern die für eine Branche typischen Anforderungen. Aus systemtheoretischer Perspektive kann dieses Vorgehen so beschrieben werden: „Aus der knappen Entscheidungszeit ergibt sich zum Beispiel eine Bevorzugung des schon Bekannten, der eingefahrenen Denkbahnen der Informationen, die man hat, vor denen, die man erst suchen muß, eine Bevorzugung der Kommunikationspartner, mit denen man sich rasch verständigen kann, vor solchen, mit denen zeitraubende Verhandlungen erforderlich wären [...].“ (Luhmann [1971] 2013: 28)

Vom Berater wird eine Zeitstrategie vorgeschlagen, die auch in anderen organisatorischen Kontexten angewendet wird. Mit „vordefinierten Lösungen“ greift der Berater auf Erfahrungen aus vergangenen Implementierungsprojekten in anderen Organisationen zurück. Faktisch ist die Bandbreite für die Möglichkeiten organisationsspezifischer Anpassungen der Software also bereits durch die zeitliche Befristung des Implementierungsprojektes beschränkt. Außerdem reduziert die knappe Entscheidungszeit die Möglichkeiten zur Beteiligung von Organisationsmitgliedern, die über ein bloßes Abnicken der Softwarelösung hinaus geht. Letztlich entscheidet jedoch die beratene Organisation über die Implementierung der Software, die Projektdauer und damit auch über die Höhe der Projektausgaben. Es gibt unzählige Formen der Softwareanpassung: Beispielsweise werden für Softwarenutzer (bzw. Nutzergruppen) Bildschirmmasken für die Dateneingabe und Datenausgabe definiert; Reportingfunktionen der Software, die Grundlage für Datenbankabfragen und SAP-Berichte sind, werden erweitert oder eingeschränkt; zusätzliche Anwendungsprogramme werden mit ERPProgrammier-ungen hergestellt; Schnittstellen werden entwickelt, damit auch (Alt-)Systeme von Drittanbietern benutzt werden können; komplett neue Module

184 | D AS P ROJEKT SAP

mit zusätzlichen Funktionen werden entwickelt, die in den Modulen der Standardsoftware nicht enthalten sind. All diese Anpassungen können den Begriffen Parametrisierung, Konfiguration und Modifikation zugeordnet werden. In der Fachliteratur gelten Parametrisierung und Konfiguration von Standardsoftware als Customizing im engeren Sinne. Die Modifikation dagegen fällt unter das Customizing im weiteren Sinne (vgl. Abts & Mülder 2010: 79ff.).11 Zwei Interviewpassagen von Beratern sollen ausführlicher vorgestellt werden, weil sie zwei typische Strategien bei der Implementierung von SAP repräsentieren. Berater I charakterisiert seinen Kunden weniger als Entscheider, sondern eher als passiven Empfänger von Leistungspaketen. Er interpretiert seinen

11 Parametrisierung bedeutet das Setzen von Parametern. Dadurch wird zugleich der Funktionsumfang der Standardsoftware für eine Organisation definiert, indem einzelne Programmabläufe im Softwaresystem aktiviert bzw. deaktiviert werden. Die konkrete Ausprägung des Organisationsmodells der Software wird bei einer Parametrisierung im top-down-Verfahren bestimmt (vgl. Wedekind & Günzel 1999: 450). Die Konfiguration der Standardsoftware wird dann als Modularisierung bezeichnet, wenn zunächst einzelne Module aus dem System der Standardsoftware ausgewählt und anschließend über Schnittstellen wieder verknüpft werden. Die Module, die im Softwareprodukt bereits enthalten sind, werden mitunter durch Spezialmodule anderer Softwarehersteller ergänzt. Dieses Vorgehen bezeichnet man auch als bottom-upVerfahren, weil nur diejenigen Module der Standardsoftware implementiert werden, für die sich eine Organisation explizit entscheidet (vgl. Wedekind & Günzel 1999: 450). Die Modifikation zählt zum Customizing im weiteren Sinne. Es handelt sich um Erweiterungsprogrammierungen. Für deren Funktionsweise übernimmt der Softwarehersteller SAP keine Gewährleistung und auch keine Wartung. Die Erweiterungsprogramme sind oft – genauso wie die SAP-Module selbst – in den Programmiersprachen ABAP oder Java geschrieben. Viele kleinere Softwareunternehmen bieten ihre Produkte als optionale Module (add-on) an, um Lücken im Funktionsumfang der Standardsoftware abzudecken. Diese Programme können ausschließlich über standardisierte Schnittstellen (user-exits) mit den SAP-Programmen verknüpft werden. Die Schnittstellen werden von den SAP-Entwicklern vordefiniert und bleiben auch bei einem Releasewechsel erhalten (vgl. Horváth et al. 1986: 123). Bei einem Releasewechsel werden Änderungen in der Konfiguration und in den Funktionalitäten der standardisierten Software vorgenommen. Schnittstellen, die nicht von den Entwicklern von SAP eingeplant worden sind, verfügen über keine Releasefähigkeit. Bei jedem neuen Release der Software müssen die vorgenommenen Veränderungen und Anpassungen in den Programmabläufen überprüft und erneuert werden.

D IE

INDIVIDUALISIERTE

S OFTWARE

| 185

Beratungsauftrag als Betreuung. Hingegen tritt Berater vor seinem Kunden als Belehrender auf.12 INTERVIEWPARTNER I: „Für den Bereich CRM [Softwaremodul für das „Customer Relationsship Management“; H. M.] definiere ich gerade Leistungspakete, die genau beschreiben, was sie machen. Da ist auch alles drin. Da gibt es keinen Workshop mehr, sondern da gibt es eine technische Umsetzung. Es gibt da einen Workshop mit den Kunden nachher, der aber gleichzeitig Testen ist und das war es dann. (--) Das bringt den Vorteil, dass man einfach schneller bei der Umsetzung ist, weil wenn du mit dem Kunden zusammensitzt, findet häufig so etwas wie Wunschdenken, so ein Wunschkonzert statt (-) und das hätte ich gerne noch und hier hätte ich gerne noch ein Schleifchen dran und dieses Feld, da möchte ich aber nicht, dass das dunkelblau, sondern dass das hellblau erscheint. [...] Und dann kommst halt dahin und der Kunde sagt dir ein Wunschkonzert und bläst einfach ein Projekt riesig groß auf, weil du so viel Freiräume und Spielplätze lässt. Du diskutierst mit dem Kunden nachher über Feldbezeichnungen und nicht, ob der Prozess nun richtig ist und gut funktioniert.“ INTERVIEWPARTNER J: „Und wenn du dann ein Festpreisprojekt hast, dann kannst du das alles überhaupt nicht realisieren. Du hast dann die Problematik, dass der Leistungsumfang gar nicht richtig abgestimmt ist. Deshalb gehe ich halt hin. Lieber Kunde, du hast zwei Möglichkeiten. Entweder du nimmst diese Standardlösung, die wir dir empfehlen und die halt vorkonfiguriert ist in gewisser Art und Weise und dir ein genaues Leistungsspektrum gibt. Die bekommst du für 50.000 Euro. Und die andere Lösung: Wir können mit dir auch in eine Workshopphase reingehen und deine Leute können noch mal genau sagen, was sie haben wollen und wie es aussehen soll und was sich alles ändern soll und dann zahlst du für das identische Projekt 150.000 Euro. Ist dem Kunden die Workshopphase so viel Wert, dass er die Differenz zahlt oder sagt er, du fängst mit einer Standardlösung an, wo Standardsoftware ja auch eigentlich für ausgerichtet ist. Wir sagen halt, das ist der Standard und da gewöhnen wir uns dran.“

I kommentiert Kundenwünsche sarkastisch als Wunschdenken bzw. Wunschkonzert. Damit die Organisationsmitglieder der beratenen Organisation keine Gelegenheit haben, über Nichtigkeiten (z. B. Farben und Bezeichnungen) zu diskutieren, schlägt er vor, bestimmte Interaktionsformate (z.B. Workshops) zu vermeiden. Die Organisationsmitglieder sollen die vorgenommenen Anpassungen lediglich testen. Seinen Beratungsauftrag versteht I eher als Betreuungsauf-

12 Vergleiche zur Unterscheidung von Beratung, Belehrung und Betreuung KAPITEL 5.3 „Die kommunikative Bearbeitung von Entscheidungsproblemen“.

186 | D AS P ROJEKT SAP

trag, denn die Selektions- und Entscheidungsmöglichkeiten bei der Individualisierung der Standardsoftware sollen massiv beschnitten werden. J hingegen weist zunächst auf die vertragliche Regelung des Beratungsauftrags hin. Zwei Vertragstypen werden in der Praxis unterschieden: Fixed-PriceVerträge und Time-Material-Verträge. Das Beratungsunternehmen ist im ersten Fall an einen zuvor vereinbarten Preis gebunden, auch wenn der tatsächliche Aufwand bei der Implementierung der Software im Kundenunternehmen höher ist, als der zuvor geschätzte zeitliche Aufwand. Dagegen trägt im zweiten Fall das Kundenunternehmen das Kostenrisiko, denn die Dienstleistungen des Beratungsunternehmens werden nach dem tatsächlichen Aufwand (Beratertage) abgerechnet. In seiner Beschreibung nimmt J primär auf den ersten Vertragstyp (Festpreisprojekt) Bezug, der in der Praxis häufiger vorkommt. Aufgrund der Vertragssituation versucht der Berater die Beteiligung der Organisationsmitglieder an Entscheidungen über die Individualisierung der Standardsoftware möglichst gering zu halten. Sich über Anpassungen zu verständigen, koste Zeit und treibe die Projektkosten in die Höhe. Dass auch das Organisationswissen des Personals für die Softwareimplementierung notwendig ist und die Akzeptanz für das System der Software im Organisationsalltag erhöht, blendet J in seiner Darstellung vollkommen aus. Er beschreibt seine Rolle im Softwareprojekt als Belehrender: „Wir sagen halt, das ist der Standard und da gewöhnen wir uns dran“. In Selbstbeschreibungen überschätzen Berater sowohl ihre Rolle als auch die Rolle der Standardsoftware für die Organisationsgestaltung. Im dritten Teil des Buches wird die Diskrepanz zwischen der standardisierten bzw. individualisierten Software und der operativen Software zum Thema gemacht. TEIL C ist der Beantwortung der Frage gewidmet, wie Organisationsmitglieder die Technik in ihren Arbeitsalltag integrieren.

C. Die operative Software: Die Integration der Technik II

8. Beschreibungen der Softwareverwendung

Als zentrale sozialtheoretische Referenz für die Organisationsforschung, die sich mit der Verwendung moderner Informations- und Kommunikationstechniken (IKT) beschäftigt, gilt der strukturationstheoretische Ansatz von Anthony Giddens.1 Der Vorschlag von Wanda Orlikowski (z.B. 1992; 2000; Orlikowski & Scott 2008) für eine strukturationstheoretische Konzeptualisierung von IKT in organisatorischen Kontexten stieß auf besonders große Resonanz. Eine ihrer bekanntesten Arbeiten trägt den Titel The Duality of Technology. Rethinking the Concept of Technology in Organizations (1992). Dieser Beitrag steht im Mittelpunkt für die folgende theoretische Auseinandersetzung mit der Softwareverwendung von Organisationsmitgliedern. Vorgestellt werden zunächst deterministische Modelle und danach Orlikowskis alternatives Modell zum Zusammenspiel von Organisation und Technik. Anschließend schlage ich eine systemtheoretische Sicht auf die Softwareverwendung in Organisationen vor. In TEIL B bot der systemtheoretische Ansatz das Instrumentarium zur Untersuchung der Softwareimplementierung. In diesem Teil des Buches soll gezeigt werden, dass Luhmanns kommunikationstheoretische Überlegungen, die er in seinem Werk nur kursorisch auf den Computer angewendet hat, ebenso fruchtbar für die Analyse der Softwareverwendung sind.

1

Einen Überblick über die Forschungsliteratur im Rahmen der Strukturationstheorie mit besonderem Bezug auf organisationsinterne Informations- und Kommunikationstechniken geben Roberts & Grabowski (1996), Rose (1998), Orlikowski & Scott (2008), Poole & DeSanctis (2004) und Jones & Karsten (2008).

190 | D AS P ROJEKT SAP

8.1 D ETERMINISTISCHE M ODELLE Wanda Orlikowski kritisiert in The Duality of Technology (1992) die Sozialwissenschaften für eine dichotomische Perspektive auf die Verbindung von Technik und Sozialem. In bisherigen Arbeiten sei entweder technikdeterministisch argumentiert worden oder Technik ausschließlich als soziale Konstruktion betrachtet worden: „The duality of technology identifies prior views of technology – as either objective force or a socially constructed product – as a false dichotomy“ (ebd.: 406). Die bisherige Forschung ließe sich anhand zweier grundverschiedener Modelle des Zusammenspiels von Technik und Organisation zusammenfassen. Differenziert werden müsse zwischen technik- und sozialdeterministischen Ansätzen. Die für verschiedene Erklärungen des Zusammenspiels von Organisation und Technik grundlegenden Modelle, sollen im Folgenden expliziert werden. Im ersten Modell wird die Beziehung von Organisation und Technik technikdeterministisch erklärt. Abbildung 14: Das technikdeterministische Modell

Quelle: Darstellung nach Orlikowski (1992: 400)

Der einseitige Richtungspfeil in der Abbildung spiegelt die zentrale Grundannahme des Modells wider: Technik bedingt sozialen bzw. organisatorischen Wandel. Diese technikdeterministische Sichtweise auf die Verwendung von SAP-Software in Organisationen wird mitunter im Interviewmaterial bestätigt. Hasso Plattner meint zum Beispiel: „Wir hatten also technisch ein einwandfreies

D IE

OPERATIVE

S OFTWARE

| 191

System, das die Leute zwang, ihre Vorgehensweise zu verändern“.2 Der von Plattner beschriebene Determinismus wird vom Anthropologen Bryan Pfaffenberger (vgl. 1992: 493) als Masternarrativ des 20. Jahrhunderts bezeichnet. „By now, most people in modernized societies have become habituated to the seeming power of advancing technology (and its products) to change the way they live. For them, indeed, the steady growth of that power is just another self-evident feature of modern life, an obvious fact that calls for no more comment than the human penchant for breathing. As an explicit idea „technological determinism“ may mean nothing to them, but the phenomenon it ostensibly represents is an omnipresent aspect of their awareness.“ (Marx & Smith 1994: ix)

Die Entwicklung einer Technik wird meistens als Fortschrittspfad interpretiert. Technikdeterministische Vorstellungen zur Gestaltung des (Arbeits-)Lebens sind tief in der westlichen Kultur verankert.3 Für die Untersuchung der Softwareverbreitung (TEIL A) und der Softwareimplementierung (TEIL B) bedeutete eine Abkehr vom Technikdeterminismus, sich von einfachen kausalen Modellen zum Zusammenspiel von Organisation und Technik zu verabschieden. Die Verwendung moderner Informationstechniken wie SAP soll auch in diesem Teil des Buches nicht vorschnell als Begründung für organisatorischen Wandel angeführt werden. Das zweite von Orlikowski kritisierte Modell steht für das Gros von Ansätzen in der sozialwissenschaftlichen Technikforschung. Im Vergleich zum technikdeterministischen Modell vereinseitigt das sozialdeterministische Modell die Relation zwischen Sozialität und Technik in umgekehrter Richtung. Technik wird nicht als ein gegebenes und unveränderliches Objekt betrachtet. Sie ist in diesem Modell vielmehr eine abhängige Variable, die durch andere Variablen in einer Organisation, z. B. einflussreiche Mitarbeitergruppen und Organisationsregeln, erklärt wird.

2

Diese technikdeterministische Beschreibung von Plattner wird ausführlich in KAPITEL 1.2 „Die Anwendungsebene“ zitiert.

3

Günther Ropohl (1991: 193f.) unterscheidet zwei Varianten des Technikdeterminismus: Der genetische Determinismus nimmt die Selbstläufigkeit von Techniken an; der konsequenzielle Determinismus behauptet die Prägekraft von Techniken auf soziales Handeln.

192 | D AS P ROJEKT SAP

Abbildung 15: Das sozialdeterministische Modell

Quelle: Darstellung nach Orlikowski (1992: 400)

Die gemeinsame Grundannahme von Vertretern sozialdeterministischer Ansätze lautet, dass Techniken durch ihre sozialen Kontexte geprägt und durch Strategien von Nutzern beeinflusst werden. Für Orlikowski (1992) repräsentiert das sozialdeterministische Modell drei verschiedene Strömungen in der zeitgenössischen Forschung, nämlich 1) sozio-technische, 2) marxistisch geprägte und 3) sozialkonstruktivistische Erklärungsansätze. 1) In sozio-technischen Ansätzen wird angenommen, dass die Gestaltungsmacht einer Technik bei ihren Nutzern liegt (z. B. Trist et al. 1963; Davis & Taylor 1986; Mumford 1981). Sie entscheiden darüber, wie sie eine Technik in der Organisation einsetzen.4 Die Entwicklung und Verwendung von Technik ist an unterschiedliche Intentionen geknüpft, hat dementsprechend verschiedene Auswirkungen auf Mitarbeiter und Mitarbeitergruppen in einer Organisation. Zielt der Einsatz beispielsweise auf die Automatisierung von Arbeitsabläufen ab, geht damit die Dequalifizierung bestimmter Mitarbeitergruppen und ihrer Tätigkeiten einher. Wird hingegen primär das Ziel der Informatisierung verfolgt, führt der Einsatz von Technik zum Empowerment der Belegschaft (vgl. Zuboff 1988).

4

Die Organisation wird in diesem Ansatz als sozio-technisches System betrachtet. Geprägt wurde dieser Begriff in den 1950er Jahren von Mitgliedern des Tavistock Institute of Human Relations. Dazu zählte u. a. Eric Trist, der versuchte, das Zusammenspiel menschlicher und technischer Aspekte von Arbeit zu umschreiben. Das 1947 gegründete sozialwissenschaftliche Forschungsinstitut beschäftigt sich noch heute mit Fragen der Organisationsentwicklung und des sozialen Wandels.

D IE

OPERATIVE

S OFTWARE

| 193

2) Harry Braverman zählt mit Labor and Monopoly Capital. The Degradation of Work in the Twentieth Century (1974) zu den bekanntesten marxistisch argumentierenden Autoren. Eine Prämisse ist, dass Unternehmen die Fragmentierung der Arbeit vorangetrieben haben. Technik erfüllt eine Managementfunktion. Es geht primär darum, Arbeit zu kontrollieren und zu verbilligen. Arbeiter haben kaum noch Einsicht in den Arbeitsprozess, wie es für handwerkliche Arbeit noch charakteristisch gewesen war. Braverman und andere Autoren (z. B. Edwards 1979; Noble 1984) kritisieren den Einsatz von Techniken, die primär den ökonomischen Interessen der Unternehmensführung dienen. Techniken für wirtschaftliche Interessen zu nutzen, so argumentieren sie, steht allein der Gruppe der Manager offen. Andere Organisationsteilnehmer hingegen stehen der Technik relativ machtlos gegenüber; sie sind ihr weitgehend ausgeliefert. 3) Wiebe Bijker, Trevor Pinch, Donald MacKenzie, Steven Woolgar, Bruno Latour5 und andere haben in den 1980er Jahren mit ihren Beiträgen das Fundament für das inzwischen weit verzweigte Forschungsfeld der Science and Technology Studies (SST) gelegt.6 Ein Verdienst sozialkonstruktivistischer Ansätze besteht darin, so argumentiert Orlikowski, in dichten Beschreibungen deutlich gemacht zu haben, dass Technik durch und durch sozial vermittelt ist und dass sich in der Entwicklung und Verwendung einer Technik gesellschaftliche Vorstellungen und Gewohnheiten materialisieren. In den Kapiteln zur Entstehungsgeschichte von SAP (TEIL A) und zur Softwareimplementierung (TEIL B) konnte gezeigt werden, dass die soziale Konstruktion bzw. Formung einer Technik nicht als unidirektionale und bewusste Beeinflussung durch den menschlichen Willen zu verstehen ist. Es gibt keine einzelne dominierende formende Kraft. Es handelt sich eher um ein komplexes Zusammenspiel von technischen und sozialen Aspekten. Orlikowskis Gegenüberstellung des technikdeterministischen Modells und des sozialdeterministischen Modells wird von Ingo Schulz-Schaeffer (1999; 2000) kritisiert. Er wirft ihr vor, Pappkameraden aufzustellen und Scheingefech-

5

Bruno Latour gilt zusammen mit Michel Callon und John Law als Begründer der Akteur-Netzwerk-Theorie (ANT) (Belliger & Krieger 2006). ANT-Vertreter selbst würden ihren Ansatz nicht notwendigerweise als sozialkonstruktivistisch bezeichnen (Law & Singleton 2000: 767). Die Frage nach der sozialen Bedeutung gegenständlicher Technik sei obsolet, weil sie auf einer unzulässigen Ausgangsunterscheidung basiere. ANT lehnt die Unterscheidung zwischen Technischem und Sozialem als Beobachtungskategorie vollständig ab (Callon & Latour 1992: 348).

6

Siehe hierzu die Ausführungen in der EINLEITUNG.

194 | D AS P ROJEKT SAP

te zu führen. Der scharfe Gegensatz zwischen technikdeterministischen und sozialdeterministischen Ansätzen in der Forschung bestehe gar nicht mehr. „In der Tat ist in der Frühzeit der neueren Techniksoziologie verschiedentlich argumentiert worden, es bestehe eine zentrale wissenschaftliche Kontroverse zwischen Technikdeterminismus und Sozialkonstruktivismus. Allerdings muss dieses Argument im Wesentlichen als rhetorischer Versuch sozialkonstruktivistischer Autoren gewertet werden, den kaum bezweifelbaren Aussagen, dass Techniken menschliche und damit zugleich auch soziale Konstruktionsleistungen sind, das Flair des Kontraintuitiven zu verleihen.“ (SchulzSchaeffer 1999: 413)

Für Schulz-Schaeffer (vgl. 2000: 48ff.) geht es stattdessen um unterschiedliche soziologische Zugänge zu gegenständlicher Technik. Diese Unterschiede kennzeichnen das Fach Soziologie schlechthin, weil sie sich als eine multiparadigmatische Wissenschaft auszeichnet.7 Orlikowski plädiert, Techniken und ihre soziale Bedeutung in einem umfassenden Sinne zu betrachten: Die Entstehung („technology design“) und die Verwendung („technology use“) von Technik sollen in ihrem Erklärungsmodell gleichermaßen berücksichtigt werden. Orlikowskis alternativer Vorschlag zur Konzeptualisierung des Zusammenspiels von Organisation und Technik wird im nächsten Kapitel vorgestellt.

7

Die multiparadigmatische Struktur gilt natürlich auch für die Organisationswissenschaften. Vergleiche hierzu die Ausführungen im SCHLUSS zur komplementären Verwendung der neoinstitutionalistischen Organisationstheorie und des systemtheoretischen Ansatzes in der Organisationsforschung.

D IE

8.2 D IE D UALITÄT

DER

OPERATIVE

S OFTWARE

| 195

T ECHNIK

Das Modell von Wanda Orlikowski basiert auf den drei Komponenten Technik, Akteur und institutionelle Merkmale einer Organisation. Abbildung 16: Das Modell zur Dualität der Technik

Quelle: Orlikowski (1992: 410)

In der Abbildung symbolisieren Richtungspfeile (a-d) die angenommene Wirkungsbeziehung zwischen den drei Komponenten. Pfeil a gibt an, dass Technik ein Produkt menschlicher Handlungen ist: „Technology is an outcome of such human action as design, development, appropriation, and modification“ (ebd.: 410). Mit Pfeil b ist zum Ausdruck gebracht, dass dieselbe Technik nicht nur ein Produkt, sondern auch ein Medium für menschliche Handlungen darstellt: „Technology facilitates and constrains human action through the provision of interpretive schemes, facilities, and norms“ (ebd.). Technik beschränkt einerseits, andererseits ermöglicht Technik erst bestimmte Handlungen für Akteure. Pfeil c gibt an, dass institutionelle Merkmale (einer Organisation) Akteure und ihre Handlungen beeinflussen, indem sie ihnen eine (organisatorische) Rahmung geben. Diese spielt sowohl bei der Entstehung als auch bei der Verwendung von Technik eine zentrale Rolle. Orlikowski geht davon aus, dass Technik einen Abdruck der sozialen Bedingungen in sich trägt, die sowohl bei der Entstehung als auch der Verwendung bedeutsam sind: „[...] for example, intentions, professional norms, state of the art in materials and knowledge, design standards, and available resources (time, money, skills)“ (ebd.). Der Einfluss der verwendeten Technik auf institutionelle Merkmale wird durch Pfeil d symbolisiert. Die Beziehung zwischen Technik und den institutio-

196 | D AS P ROJEKT SAP

nellen Merkmalen einer Organisation ist nicht (technik-)deterministisch gedacht. Techniken haben zwar bestimmte Merkmale und Funktionen, diese können jedoch in verschiedenen organisatorischen Kontexten variieren und sich im Laufe der Zeit verändern. Stephen R. Barley (1986) zeigt am Beispiel der Verwendung von Scannern im medizinischen Bereich nicht intendierte, unerwartete Effekte für eine vergleichsweise unflexible Technik auf. Orlikowski (1992: 402) bezieht sich ausführlich auf Barleys mittlerweile klassische empirische Studie zur Einführung von Computer-Tomographie-Technik in zwei Krankenhäusern und charakterisiert seinen strukturationstheoretischen Ansatz als „Model of Technology as Trigger of Structural Change“ (ebd.). Bei hochflexiblen, modular aufgebauten Informations- und Kommunikationstechniken, argumentiert Orlikowski (2000) in einer später veröffentlichten Arbeit, würde sich dieser Effekt noch verstärken. Diese Techniken verändern sich im Zeitverlauf in vielfältiger Weise, etwa durch die Implementierung zusätzlicher Module oder Änderungen der Konfigurationen. Das Customizing von SAP-Software ist dafür ein Beispiel par excellence. Kritiker haben Orlikowski vorgeworfen, dass sie Technik und Struktur in ihrem Modell gleichsetzt und Technik als Struktur behandelt. Hierauf reagiert sie, indem sie auf die sozialkonstruktivistischen Grundlagen des von ihr vorgeschlagenen Modells verweist: „The development of a structurational perspective on technology has benefited considerably from social constructivist ideas, particularly in the absence of any explicit treatment of technology in Giddens’ (1984) theory of structuration. However, the adoption of social constructivist conceptions has also created some difficulties, primarily with respect to two propositions: that technologies become „stabilized“ after development; and that they „embody“ structures which (re)present various social rules and political interests.“ (Orlikowski 2000: 405)

Eine grundlegende Idee der Theorie der Strukturation von Giddens ist, dass Strukturen erst in ihrem konkreten Vollzug wirklich werden (vgl. Giddens 1984: 17, 34). Eine Technik an sich ist deshalb noch keine Struktur. Orlikowski nimmt ausführlich Stellung zu dieser Problematik und entwickelt in Using Technology and Constituting Structures: A Practice Lens for Studying Technology in Organizations (2000) ihr Modell der Dualität von Technik weiter. Der Technology-inPractice-Ansatz (Orlikowski 2000) gilt bisher als überzeugendste Umsetzung von Giddens’ Strukturationstheorie in der Forschung zur Verwendung von Informationstechniken (vgl. Hauptmann 2011: 68).

D IE

OPERATIVE

S OFTWARE

| 197

„Thus rather than starting with the technology and examining how actors appropriate its embodied structures, this view starts with human action and examines how it enacts emergent structures through recurrent interaction with the technology at hand [...]. [Technology structures] are not »out there«, embodied in technologies simply waiting to be appropriated. Rather they are virtual, emerging from people’s repeated and situated interaction with particular technologies. These enacted structures of technology use, which I term technologies-in-practice, are the sets of rules and resources that are (re)constituted in people’s recurrent engagement with the technologies at hand.“ (Orlikowski 2000: 207) [Hervorh., H.M.]

Stark beeinflusst wird die Verwendung von Technik durch das Verständnis ihrer Nutzer für die Eigenschaften und Funktionalitäten der Technik. Dieses Verständnis ist wiederum durch Organisationsbilder und Beschreibungen von Herstellern und Designern geprägt. Orlikowski formuliert dies so: „When people use a technology, they draw on the properties comprising the technological artifact – those provided by its constituent materiality, those inscribed by the designers, and those added on by users through previous interactions (e. g., specific data content, customized features, or expanded software/hardware accessories). People also draw on their skills, power, knowledge, assumptions, and expectations about the technology and its use, influenced typically by training, communication, and previous experiences.“ (Ebd.: 210) [Hervorh., H. M.]

Die Nutzer und Nutzerinnen einer Technik („people“) interpretieren eine Technik bewusst oder unbewusst vor dem Hintergrund ihrer persönlichen Erfahrungen und dem institutionellen Verwendungskontext. Sie setzen die Technik für ihre speziellen Zwecke ein, wobei sie den Intentionen der Designer folgen, diese aber auch umgehen können und (re-) interpretieren. Im Unterschied zur früheren Version des Modells der Dualität von Technik sind es nun dezidiert die Praktiken im Umgang mit der Technik, welche Strukturen in Organisationen fortschreiben oder verändern. Orlikowski beschreibt im Anschluss an Giddens’ Strukturbegriff Organisationsstrukturen als Regeln und Ressourcen, die interaktive Beziehungen über Raum und Zeit stabilisieren. „[C]onstruction and use [of technology] is conditioned by an organization’s structures of signification, domination and legitimation. The appropriation and use of technology implies the change or reinforcement of these three institutional structures.“ (Ebd. 411)

198 | D AS P ROJEKT SAP

Einerseits werden Regeln als Interpretationsschemata herangezogen, um Sinn aus dem herauszulesen, was Akteure sagen oder tun („signification“). Andererseits formulieren Regeln Rechte und Verpflichtungen („legitimation“). Regeln sind an Ressourcen geknüpft („domination“).8 Im Technology-as-PracticeAnsatz wird zwar der Einfluss von Organisationen („institutional properties“) berücksichtigt, es wird jedoch auf einen soziologisch elaborierten Organisationsbegriff verzichtet. Orlikowski vergibt meines Erachtens so die Chance, mithilfe der Untersuchung von Techniken und ihrer Verwendung mehr über Organisationen und ihre Funktionsweise zu erfahren. Wenn eine Technik wie SAP in Organisationen verwendet wird, sind die Softwarenutzer in erster Linie Organisationsmitglieder und nicht bloß „people“. Diese Feststellung mutet zunächst trivial an, für die Untersuchung der Verwendung der SAP-Technik hat sie allerdings weitreichende theoretische und praktische Konsequenzen. Eine Organisationsmitgliedschaft geht einher mit bestimmten Verhaltenserwartungen, die eine Organisation nicht nur als Bedingungen für den Eintritt, sondern auch für den Verbleib in der Organisation formuliert. Diese Erwartungen betreffen auch die Softwareverwendung. Das Konzept der Mitgliedschaft ist für ein systemtheoretisches Organisationsverständnis grundlegend. Im nächsten Kapitel kombiniere ich dieses Organisationskonzept mit Luhmanns kommunikationstheoretischen Überlegungen.

8.3 D IE S OFTWAREVERWENDUNG ALS SOFTWAREVERMITTELTE K OMMUNIKATION Organisationen sind soziale Systeme, weil „jeweils entschieden werden muss, ob man den im System selbst produzierten Erwartungen folgt – oder nicht; und ob man sie dann ändert oder sie schlicht unbeachtet lässt und vergisst“ (Luhmann 2000: 229). Das gilt auch für eine Software, die von Organisationsmitgliedern verwendet und als Teil der formalen Organisationsstruktur wahrgenommen

8

Zwei Arten von Ressourcen sind zu unterscheiden (vgl. Giddens 1984: 45): Allokative Ressourcen beziehen sich auf Fähigkeiten zur Kontrolle über materielle Produkte oder bestimmte Aspekte der materiellen Welt. Es geht sehr allgemein gesprochen um die Herrschaft des Menschen über die Natur. Autoritative Ressourcen umfassen die Fähigkeit zur Koordination des Handelns von Menschen.

D IE

OPERATIVE

S OFTWARE

| 199

wird.9 Nach der aufwendigen Einführung der Software bleibt die Technik in einer Organisation nicht unbeachtet. Bei vielen Entscheidungen im Organisationsalltag wird auf die betriebswirtschaftlichen Anwendungsprogramme Bezug genommen werden. Die Software ist Teil der Programmstruktur der Organisation. Trotzdem sind Entscheidungen, die im Organisationsalltag getroffen werden, nicht vollständig im Voraus festgelegt. Aus einer systemtheoretischen Perspektive besteht nämlich ein Unterschied zwischen formalen Strukturen und dem sozialen System Organisation. Organisationen reproduzieren sich wie alle sozialen Systemen über ihre eigenen Operationen, nämlich über Kommunikation.10 Genauso wie die Softwareimplementierung ist auch die Softwareverwendung in Organisationen Gegenstand von Entscheidungen. „Nur wenn auch über die Koordination von Entscheidungen noch entschieden werden kann und hier Alternativen sichtbar werden, greift Selbstorganisation und differenziert das System aus. Und nur dann kommt es auch in dem Sinne zu Entscheidungen, das jeweils entschieden werden muss, ob man den im System selbst produzierten Erwartungen folgt – oder nicht; ob man sie dann ändert oder sie schlicht ungeachtet lässt und vergisst.“ (Luhmann 2000: 229).

Ob und wie die Software verwendet wird, wird von formalen und informalen Mitgliedschaftserwartungen beeinflusst. Softwarenutzer in Organisationen sind nämlich in erster Linie Organisationsmitglieder. Der Begriff der Mitgliedschaft hat in Luhmanns Organisationstheorie einen zentralen Stellenwert. Der Mitgliedschaftsbegriff lässt sich mit dem kommunikationstheoretischen Überlegungen von Luhmanns allgemeiner Theorie sozialer Systeme verbinden. In Organisationen ereignet sich Kommunikation wie gesagt systemtypisch als Entscheidungen. Der Zusammenhang von Entscheidungen und Mitgliedschaft ist deshalb folgendermaßen zu erklären: „[N]ur Kommunikationen, die die Mitglieder der Organisation in ihrer Rolle als Mitglieder tätigen, werden der Organisation zugerechnet. Alles andere, Gebäude, Maschinen,

9

In KAPITEL 5.2 wurden Entscheidungsprogramme, Kommunikationswege und Personal als formale Organisationsstrukturen (bzw. Entscheidungsprämissen) vorgestellt. Die Software ließe sich in die Kategorie der Entscheidungsprogramme einordnen.

10 Der Begriff Entscheidung tritt in Luhmanns Organisationstheorie an die Stelle, die in seiner allgemeinen Systemtheorie mit dem Begriff der Kommunikation besetzt ist (vgl. Luhmann 2000: 63).

200 | D AS P ROJEKT SAP aber auch Menschen selbst und all das, was Nichtmitglieder untereinander aushandeln, gehört zur Umwelt des Systems.“ „Außerdem ist klar, daß die Mitgliedschaft durch Entscheidungen übernommen und durch Entscheidungen beendet wird. Es sind also Entscheidungen, mit denen die Organisation sich selbst erzeugt und in der laufenden Kommunikation gegen ihre Umwelt abgrenzt.“ (Ebd.: 400)

Seine Kommunikationstheorie wendet Luhmann kursorisch auf den Computer an. In Die Gesellschaft der Gesellschaft (1998) beschreibt er die durch Computer vermittelte Kommunikation folgendermaßen: „Sie ermöglicht es, die Eingabe von Daten in den Computer und das Abrufen von Informationen so weit zu trennen, daß keinerlei Identität mehr besteht. Im Zusammenhang mit Kommunikation heißt dies, daß die Einheit von Mitteilung und Verstehen aufgegeben wird. Wer etwas eingibt, weiß nicht (und wenn er es wüßte, brauchte er den Computer nicht), was auf der anderen Seite entnommen wird. Die Daten sind inzwischen »verarbeitet« worden.“ (Luhmann 1998: 309)

Diese Überlegungen sollen nun auf das Beispiel softwarevermittelter Kommunikation in Organisationen angewendet werden. Dafür sind allerdings noch einige Begriffsklärungen notwendig. Zunächst soll der Unterschied zwischen Daten und Informationen erläutert werden (a). Danach soll Kommunikation als Verknüpfung von Information, Mitteilung und Verstehen definiert werden (b). a) Daten sind im systemtheoretischen Sinne dann eine Information, wenn sie für den Softwarenutzer neu oder überraschend sind. Illustriert werden soll dies am Beispiel von zwei Datenbankabfragen, die in den Anwendungsprogrammen von SAP konfiguriert sind. Sie lauten: „Welche Werbekampagnen helfen Unterlasten in den Produktionskapazitäten abzubauen?“ Und: „Welche Verkaufsprioritäten bestehen aus Sicht der Kapitalbindung?“ Um die erste Frage zu beantworten, werden Daten aus dem Marketing und der Produktion miteinander verknüpft. Um die zweite Frage zu beantworten, werden Daten aus den Bereichen Marketing und Lagerhaltung miteinander kombiniert. Auf der Grundlage der beschriebenen Datenverknüpfungen werden dem Marketingleiter die Verkaufszahlen des Produktes in einzelnen Verkaufsgebieten sowie die entsprechenden Anzeigenkampagnen der letzten Monate angezeigt (Antwort auf die erste Frage). Dem Verkäufer wird nach der Eingabe einer Produktbestellung angezeigt, dass durch unerwartet hohes Bestellaufkommen und die daraus resultierende Materi-

D IE

OPERATIVE

S OFTWARE

| 201

alknappheit ein bestimmtes Produkt erst nach vier statt nach zwei Werktagen am Verkaufsort eintrifft (Antwort auf die zweite Frage). Die Fragen illustrieren, wie die Wirklichkeit der Organisation im System der Software auf Daten, d.h. Entitäten, Attribute und Beziehungstypen, reduziert wird. Es handelt sich keineswegs um eine neutrale Übersetzung. Stattdessen ist sie abduktiv, da sie es ermöglicht, Aspekte des formalisierten Bereichs zu entdecken und sichtbar zu machen, die ohne diese formale Darstellung sehr viel schwieriger oder vielleicht gar nicht expliziert werden könnten. Wie die Daten in den Anwendungsprogrammen genau verknüpft werden, d. h. welche mathematischen Relationen in einer Datenbank oder verschiedenen Datenbanken hergestellt werden, ist sowohl für die Marketingleiterin als auch den Verkäufer sowie für die meisten anderen Softwarenutzer und -nutzerinnen wahrscheinlich nicht nachvollziehbar. Die Datenbankabfragen sind in sogenannten Reportfunktionen der Software voreingestellt und deshalb noch nicht einmal als Fragen erkennbar. Für die Marketingleiter stellt die Werbewirksamkeit einer Kampagne eine Information dar, die ihre nachfolgenden Entscheidungen beeinflusst. Für den Verkäufer stellen die veränderten Lieferzeiten eines Produktes eine Information dar, an die seine folgenden Entscheidungen anknüpfen können. b) Systemtheoretisch ist Kommunikation definiert als Verknüpfung von Information, Mitteilung und Verstehen. Verstehen ist hiernach kein psychischer Vorgang, sondern ein kommunikativer Prozess. Verstehen ist nicht der gelungene oder gescheiterte Versuch der Nachbildung der Mitteilungsabsicht eines Autors. Verstehen hat eine eigenständige und produktive Rolle für den Aufbau von Kommunikation und ihrer Anschlusskommunikation. Das charakteristische Merkmal von Kommunikation ist ihre Unwahrscheinlichkeit.11 Das gilt auch für die softwarevermittelte Kommunikation, die in Organisationen stattfindet. Kommunikation liegt dann vor, wenn eine Information, eine Mitteilungsweise und eine Verstehensmöglichkeit ausgewählt worden sind. Luhmann identifiziert „eine Mehrzahl von Problemen, eine Mehrzahl von Hindernissen, die die Kommunikation überwinden muß, damit sie überhaupt möglich ist“ (2005a: 30). Kommunikation ist demnach mit drei Problemarten konfrontiert: 1) Verstehensprobleme, 2) Aufmerksamkeits- bzw. Distributionsprobleme und 3) Akzeptanzprobleme. Diese Problemarten werden im Folgenden skizziert, um sie anschließend auf den konkreten Fall der Verwendung von SAP-Software in Organisationen zu beziehen.

11 Vergleiche zum systemtheoretischen Begriff der Kommunikation die Ausführungen in KAPITEL 5.3 „Die kommunikative Bearbeitung von Entscheidungsproblemen“.

202 | D AS P ROJEKT SAP

1) „Sinn kann nur kontextgebunden verstanden werden“, so Luhmann in seinem programmatischen Beitrag Die Unwahrscheinlichkeit der Kommunikation (2005b: 30). „[U]nd als Kontext fungiert für jeden zunächst einmal das“, fügt er hinzu, „was sein eigenes Gedächtnis bereitstellt“ (ebd.). Aus diesem Grund ist es unwahrscheinlich, dass eine mitgeteilte Information überhaupt als Information verstanden wird. In der mündlichen Kommunikation ist es weniger problematisch, wenn ein Fall von Nicht-Verstehen auftritt. Die Mitteilung kann auf Nachfrage ganz einfach wiederholt oder kann anders formuliert werden, bis sie als Information verstanden worden ist. Sprache ist ein Medium, das die Wahrscheinlichkeit von Kommunikation erhöht. Die mündliche Mitteilung ist meistens verständlich, weil implizit vorausgesetzt werden kann, dass eine Person sie mit einer Mitteilungsabsicht äußert. Im Fall softwarevermittelter Kommunikation kann die Mitteilung einer Information nicht auf eine konkrete Person bezogen werden. Es kann nicht direkt nachgefragt werden, wie die Mitteilung einer Information genau gemeint war. Mitteilung (bzw. Mitteilungsabsicht) und Information sind getrennt. Das Medium per se schränkt ein, wie und was als Information mitgeteilt werden kann. Im Fall der Standardsoftware ist damit die Darstellungsebene der Technik gemeint. 2) In der mündlichen Kommunikation ist die Zahl der Empfänger begrenzt. Dafür ist die Aufmerksamkeit für die Mitteilung einer Information jedoch meistens hoch. „Das Interaktionssystem der jeweils Anwesenden garantiert in praktisch ausreichendem Maße Aufmerksamkeit für Kommunikation, und es zerbricht, wenn man erkennbar kommuniziert, daß man nicht kommunizieren will. Über die Grenzen dieses Interaktionssystems hinaus können die hier geltenden Regeln jedoch nicht erzwungen werden. Selbst wenn die Kommunikation bewegliche und zeitbeständige Träger findet, wird es daher unwahrscheinlich, daß sie Aufmerksamkeit voraussetzen kann.“ (Ebd.: 31)

Ähnlich wie in der schriftlichen Kommunikation oder der Kommunikation über Radio, Fernsehen oder Internet löst sich die softwarevermittelte Kommunikation vom direkten zeitlichen und räumlichen Zusammenhang zwischen demjenigen, der eine Information mitteilt, und demjenigen, der eine Information versteht. Klassische Verbreitungsmedien wie Radio, Fernsehen und Internet erweitern den Kreis der Empfänger. Sie tragen so zwar zur Lösung des Distributionsproblems von Kommunikation bei. Allerdings wird es so zunehmend unwahrscheinlicher, dass eine mitgeteilte Information ihre Empfänger auch tatsächlich erreicht und nicht bloß als Rauschen wahrgenommen wird. Weil sie innerhalb einer Organisation verwendet wird, handelt es sich bei SAP-Software um ein besonderes

D IE

OPERATIVE

S OFTWARE

| 203

Verbreitungsmedium. An die Stelle des reziproken Verhältnisses von Interaktion und mündlicher Kommunikation tritt in der Organisation die Generalisierung der Annahmebereitschaft durch formale Strukturen. Die Formalisierung von Mitgliedschaft macht die Annahme von vorab strukturierten Kommunikationsangeboten relativ wahrscheinlich (vgl. Drepper 2003: 111). 3) Kommunikativer Erfolg bedeutet, dass der selektive Inhalt einer Kommunikation als Prämisse für das eigene Verhalten akzeptiert wird. „Annehmen als Prämisse eigenen Verhaltens kann dabei bedeuten: Handeln nach entsprechenden Direktiven, aber auch Erleben, Denken und weitere Kognitionen Verarbeiten unter der Voraussetzung, daß eine bestimmte Information zutrifft“ (Luhmann 2005a: 31). Akzeptanzprobleme in Organisationen sind vermutlich eher gering. Die erfolgreiche softwarevermittelte Kommunikation birgt hingegen andere Risiken für die Organisation. „Verdatung von Information und Formalisierung von Informationsprozessen mittels Informatisierung […] führt zur riskanten Erblindung von Organisationen, wenn Organisationen die so angefertigte Selbst- und Fremdbeschreibung für die tatsächliche Umwelt nehmen und auf deren Grundlage selbstsicher entscheiden. Die Wahrscheinlichkeit, daß sie das tun ist nicht ganz gering, denn die Informatisierung legt als Rationalisierungsstrategie für Organisationen nahe, daß man besser informiert ist.“ (Tacke & Borchers 1993: 142)

Das Organisationsmodell der Software suggeriert, dass alle Arbeits- und Kommunikationsabläufe kontrollierbar, Ressourcen planbar, Fehler erkennbar und zurechenbar sind. Die softwarevermittelte Kommunikation in Organisationen setzt voraus, dass alle Abläufe in einer Organisation auf ein formalisiertes, idealisiertes Modell der Organisation hin entworfen wurden, auf ein Modell also, in dem alle relevanten Zustände und Veränderungen nur genau so vorkommen, wie es im Vorhinein definiert wurde. Wie mit der zu erwartenden Diskrepanz zwischen Modell und Wirklichkeit umgegangen wird, wird im folgenden Kapitel untersucht.

9. Über unvollständige, verteilte und anderweitig „defekte“ Datenverarbeitung

Die vor einigen Jahren getroffene Entscheidung zur standortübergreifenden Einführung und Verwendung von SAP kommentiert IT-Leiterin W besonders drastisch: INTERVIEWPARTNERIN W: „Das ist eigentlich schade, dass man die Dinger dafür installiert hat, aber gut, das ist natürlich auch mit einer großen SAP-Kampagne meines Vorgängers gekommen. Der wollte mit allen Aufklebern an die Presse. Jetzt hat man diese teuren Molochs hier, mit einer schönen Unternehmenslizenz, damit es nicht so auffällt, wie viel das alles im Einzelnen kostet.“

Die verschiedenen Aufkleber stehen für unterschiedliche Module und AnalyseTools an den Standorten des Unternehmens. Organisationen entscheiden nicht nur darüber, ob eine bestimmte Software verwendet wird. Sie entscheiden auch darüber, wie die Software verwendet wird. „[D]as ist sozusagen die Musik“, so Interviewpartnerin W, „wie ich einen Prozess neu gestalten kann“. Inwieweit die Softwareverwendung zur Gestaltung der Organisation und ihrer Kommunikation faktisch beiträgt, illustrieren die Beschreibungen von Softwarenutzern und Softwarenutzerinnen auf den folgenden Seiten. Im vorliegenden Kapitel greife ich die im zweiten Teil untersuchte Forschungsfrage erneut auf: Wie integriert eine Organisation die Technik?

206 | D AS P ROJEKT SAP

Die folgenden zentralen Motive1 in den Interviews mit Softwarenutzern und Softwarenutzerinnen strukturieren die Darstellung des empirischen Materials: 1) Unsicherheitsreduktion mithilfe der Software, 2) Anpassung von Organisation und Technik, 3) informationstechnische Vernetzung und 4) Abbildung von Organisationsstrukturen.

9.1 D IE S OFTWARE

ALS

E NTSCHEIDUNGSPROGRAMM

Interviewpartner D beschreibt die Einführung von SAP als Maßnahme, das Problem einer unsicheren Auftragslage organisatorisch zu bearbeiten. INTERVIEWPARTNER D: „Du musst dir vorstellen, jetzt kommt eine Bestellung rein irgendwo in, sagen wir mal, in Italien kommt eine Großbestellung, der Kunde bestellt jetzt, weiß ich, wie viel Tonnen davon. Da merken sie, hier im Werk haben sie das nicht am Lager. Dann mussten die wirklich quasi per Telefon mussten die dann rumtelefonieren irgendwie in die verschiedenen Werke und mal fragen ja, bei wem, wer hat eventuell noch das und wenn es dann nicht in einem Ort war, mussten die in mehrere Orte und die mussten dann irgendwie schauen, wie sie, wo sie eventuell günstig dann zu den, wie soll ich sagen, zu den einzelnen Rohstoffen kamen und so weiter. Also es war alles sehr unprofessionell eigentlich. (--) Und dadurch natürlich auch die Lagerbestände waren oft auch viel zu hoch. Oder dann hatten sie gar keine, weil sie es auch nicht planen konnten.“

In der Vergangenheit wurden die Arbeitsabläufe an den verschiedenen Standorten des Unternehmen weitgehend unabhängig voneinander organisiert. Jedes Werk verfügte beispielswiese über ein eigenes Warenlager. Um auch größere Bestellmengen, die vor Ort nicht vorrätig waren, fristgerecht an einen Kunden ausliefern zu können, war es allerdings üblich, auf die Lagervorräte anderer Standorte zurückzugreifen. Telefonische Abstimmungen mit anderen Standorten waren notwendig. Rückblickend bezeichnet D dieses Vorgehen als unprofessionell und als ineffizient. Die Softwareverwendung wird von D als Gewährleistung geregelter und konstanter Arbeitsabläufe beschrieben. Die Standardsoftware wurde an mehreren europäischen Standorten eingeführt, um Bestellungen standortübergreifend abzuwickeln. Zwischen- und Zentrallager im Unternehmen wurden eingerichtet und die Darstellung von Produktions- und Lagerdaten verein-

1

Der Motivbegriff wird in einem fotografischen und nicht in einem psychologischen Sinne verwendet. Siehe hierzu die Erläuterungen zur Auswertung des Datenmaterials in der EINLEITUNG.

D IE

OPERATIVE

S OFTWARE

| 207

heitlicht und Prozesse über Werke und Buchungskreise hinweg im System der Software modelliert. Auf der Grundlage zentraler Datenbanken sollen Entscheidungen (z. B. über spezielle Preise und Sonderangebote für Regionen) getroffen, die Koordination zwischen den Standorten erleichtert und Schwankungen in der externen Nachfrage an unterschiedlichen Standorten ausgeglichen werden. In der Organisationstheorie wird die von D und anderen Interviewpartnern beschriebene Softwareverwendung als Pufferung (buffering) bezeichnet.2 Die Softwareimplementierung im Unternehmen steht für den Versuch, möglichst viele bisher nicht formalisierte Abläufe formal zu definieren. Der Umgang mit Kundenreklamationen ist dafür ein typisches Beispiel. INTERVIEWPARTNER O: „Also wenn wir zum Beispiel, unser Kunde reklamiert etwas und wir sagen der Kunde hat aber nicht Recht, dann will unser Außendienst ganz gerne manchmal so eine Kulanzlösung herführen. Früher konnte man das irgendwie so hindeichseln, dass das auf seine Provision jetzt keinen Einfluss hatte. Heutzutage muss er sagen, ich möchte das ganz gerne und das kommt auf seine Kostenstelle oder es werden eben irgendwelche Gutschriften gemacht, die nicht irgendwo verschwinden ins Nirvana, sondern ganz deutlich zu erkennen sind auf den Konten, wo sie hingehören. Das geht heutzutage nicht mehr. Ich kann halt nicht hinten rum irgendwas machen. Irgendwo landet es. Auf irgendeiner Kostenstelle im Endeffekt, irgendwer hat den Hut auf und muss sagen ja, das haben wir des- und deswegen gemacht. Früher also mhm wollen wir mal gucken, wie wir das abhandeln. Ich glaube, dass dadurch auch nicht so viel Geld verloren geht.“

Die Kulanz bezeichnet ein Entgegenkommen zwischen Vertragspartnern nach Vertragsabschluss. Kulanzlösungen stehen für das Gewähren von Reparatur- und Serviceleistungen nach Ablauf der gesetzlichen oder individualvertraglichen Gewährleistungsverpflichtung durch die Mitarbeiter im Außendienst eines Unternehmens. Sie gelten allgemein als organisatorische Maßnahme zur Kundenbindung. In der Vergangenheit handhabten es die Außendienstmitarbeiter in der beschriebenen Organisation als informelles Vorgehen. Kulanzlösungen wurden „irgendwie so hin[ge]deichsel[t]”. Das persönliche Interesse des Aussendienstmitarbeiters war ausschlaggebend für das Entgegenkommen der Organisation

2

Das folgende Zitat stammt aus dem Buch Organization in Action (1967) von James Thompson: „Buffering [...] usually takes the form of maintaining warehouse inventories and items in transit or in distributor inventories, which permits the technical core to produce at a constant rate, but distribution to fluctuate with market conditions.“ (Thompson 2003: 20)

208 | D AS P ROJEKT SAP

gegenüber dem Kunden und hatte den Zweck, die Provision des Mitarbeiters nicht zu gefährden. Das informelle und eigenmächtige Vorgehen des Außendienstmitarbeiters, so O in seiner Beschreibung, habe in der Vergangenheit zu finanziellen Verlusten für die Organisation geführt. Heutzutage wird die Information „Reklamation eines Kunden“ in ein bestimmtes Format im System der Software übertragen. Auf eine Reklamation eines Kunden kann der Außendienstmitarbeiter nicht mehr länger nach Gutdünken reagieren. Die Reklamation wird zu einem betriebswirtschaftlichen Ereignis, das ein vordefiniertes Verfahren (Prozesskette) auslöst.3 Sobald der Außendienstmitarbeiter Reparatur- und Serviceleistungen gewährt, wird diese Entscheidung im System der Software dokumentiert. Es fallen Kosten an, die nicht mehr „ins Nirvana [verschwinden]“. Die anfallenden Kosten lösen sich nicht in Luft auf, sondern werden im System der Software auf die Kostenstelle des Außendienstmitarbeiters gebucht. Dieser muss nun gegenüber seinem Vorgesetzten („Kostenstellenverantwortlicher“) die Entscheidung rechtfertigen („das haben wir [...] deswegen gemacht“). Dass die zunehmende informationstechnische Formalisierung und Verregelung von Arbeitsabläufen zu neuen Problemen führt, wird von den Interviewpartnern und Interviewpartnerinnen weniger ausführlich und eher anekdotisch beschrieben: •

•

•

3

In einem Unternehmen konnte beispielsweise bei einer Lieferung von Schüttgütern, die die voreingestellten Grenzwerte überschritt, kein Wareneingang gebucht werden, weil der für die Freigabe zuständige Einkäufer nicht erreichbar war. In einem anderen Fall standen fertige, dringend auszuliefernde Fahrzeuge tagelang bei einem Automobilunternehmen im Versandlager, weil noch Rückmeldungen aus der Fertigung ausstanden. Das System von SAP verweigerte den Ausdruck von Lieferscheinen und Faktura. Die Auftragsabrechnung in einem Unternehmen stimmte nicht, denn die Lagerarbeiter wussten nur, dass man als Bewegungsart immer „irgendetwas mit einer Zwei am Anfang“ eingeben muss, „damit das System die Buchung annimmt“.

Betriebswirtschaftliche Ereignisse verändern im System der Software die wert- und mengenmäßigen Beschreibung der Organisation. Vergleiche hierzu KAPITEL 1.2 „Die Anwendungsebene“.

D IE

OPERATIVE

S OFTWARE

| 209

Interviewpartnerin Q berichtet aus dem Arbeitsalltag im Innendienst eines Unternehmens. Sie beschreibt geregelte Arbeitsabläufe, die durch die Verwendung der Standardsoftware unterstützt werden. INTERVIEWPARTNERIN Q: „Über einen Workflow im SAP werden dann halt Arbeitsvorräte generiert, die wir dann täglich abarbeiten. Früher hat man die Mailbox vollgehabt mit 30, 40 Mails und konnte da ja im Endeffekt gar nicht sehen, was ist das jetzt alles. Was ist eine Terminanfrage, was ist eine Preisanfrage, was ist jetzt eine Reklamation? Man konnte gar nicht sehen, wie priorisiere ich jetzt meinen Alltag und wir haben durch SAP natürlich die Möglichkeit da wirklich auch Prioritäten festzulegen. Dass wir sagen, wir haben einen automatischen Bestelllauf zum Beispiel, das hatten wir vorher auch nicht. Wir mussten vorher einen Zettel nehmen und beschaffen, sozusagen die Anforderung aus dem Verkauf mussten wir auf Beschaffung setzen. Heute haben wir gewisse Regelwerke im SAP hinterlegt, sodass wir sagen, unter den und den Bedingungen können wir automatisch bestellen zum Lieferanten hin. Das brauchen wir uns gar nicht mehr angucken. Und ja, das sind so Dinge, die wir halt so tagtäglich dann machen. Oder das wir ja, vormittags kümmern wir uns um die Bestellläufe oder zu gewissen Zeitpunkten. Im automatischen Bestelllauf beispielsweise müssen teilweise schon Nacharbeiten gemacht werden. Wenn zum Beispiel ein Preis nicht da ist, bleibt das hängen in einem bestimmten Monitor, wo man noch mal drüber gucken muss.“

Entscheidungen und Arbeitsabläufe im Arbeitsalltag eines Sachbearbeiters werden durch die Software und ihre Datendarstellung stark vorstrukturiert. Die Softwareverwendung wird im beschriebenen Fall vor allem als Entlastung für Organisationsmitglieder empfunden. Kundenanfragen (z.B. Termin- und Preisanfragen oder Reklamationen) wurden in der Vergangenheit, d. h. vor der Softwareimplementierung, per E-Mail an Mitarbeiter im Vertrieb oder dem Verkauf geschickt. Diese Anfragen landeten danach unsortiert in der Mailbox der Innendienstmitarbeiter. Für den Mitarbeiter im Innendienst bedeutete diese Form der Mitteilung, dass er selbst entscheidet, welche Anfragen er zuerst bearbeitet. Die Auflistung von Kundenanfragen, die als Daten im System der Software dargestellt werden, folgt hingegen eindeutigen Regeln. Mithilfe der in den Anwendungsprogrammen definierten Regeln kategorisiert und priorisiert der Innendienst Kundenanfragen und die damit verbundenen Aufgaben. Sogenannte Arbeitsvorräte werden automatisch erzeugt und dem Mitarbeiter am Bildschirm angezeigt; sie müssen dann in einer bestimmten Reihenfolge bearbeitet werden. Eine Bestellung ist im System der Software Teil einer ereignisgesteuerten Prozesskette. Mitarbeiter im Innendienst müssen nicht mehr länger die Bestelldaten des Kunden von einem lokalen Datenverarbeitungssystem (z.B. im Verkauf) in

210 | D AS P ROJEKT SAP

ein anderes (z.B. im Einkauf) übertragen, um so das erforderliche Material beim Lieferanten ordern zu können. Das übernimmt der „automatische [...] Bestelllauf“ (ebd.). Der Bestellvorgang beim Lieferanten für Materialien ist Teil derselben Prozesskette. Er wird durch die Bestellung eines Kunden ausgelöst. „Das brauchen wir uns gar nicht mehr angucken“, so Q in ihrer Beschreibung der Arbeitsabläufe, die durch die Software unterstützt werden. Sollten die Daten doch einmal von den zuvor definierten Regeln für die automatische Abwicklung einer Bestellung abweichen, wird dies in den Anwendungsprogrammen der Software erkannt: „[das] bleibt [...] hängen in einem bestimmten Monitor“. Eine solche Abweichung betrifft beispielsweise unvollständige Preisangaben für Materialien, wenn sie nicht in der zugrunde liegenden Datenbank eingetragen sind. Damit der Bestelllauf fortgesetzt werden kann, müssen dann zunächst die fehlenden Daten von einem Mitarbeiter im Innendienst nachgefragt und nachgetragen werden. Die Software erfordert von ihren Benutzern also kompensatorische Leistungen.

9.2 D AS

UNVOLLENDETE

S OFTWAREPROJEKT

Dass die Dateneingabe durch den Softwarenutzer möglichst einzuschränken ist, weil dadurch das Fehlerpotenzial steigt, erklärt Interviewpartner N im folgenden Zitat: INTERVIEWPARTNER N: „Also die Leute sind immer noch in der Lage, mutwillig was Falsches einzugeben. Das ist gar kein Problem. An vielen Stellen fangen wir das ab und da, wo wir irgendwann mal feststellen, dass dann wirklich Prozesse falsch laufen, weil ein Werker was Falsches eingegeben hat, dann versuchen wir das natürlich zu optimieren, um dem Werker gar nicht mehr die Möglichkeit zu geben. Solche Prozesse haben wir auch viele gehabt und ich muss also sagen, die merken wir natürlich so im Laufe der Zeit. Das ist dann so diese klassische Optimierung, diese Optimierungsphase.“

In Organisationen werden von Prozessingenieuren wie N formalisierte und standardisierte Verfahren (z. B. Bestellvorgänge oder Buchungen im Lager) auf eine idealisierte Wirklichkeit hin entworfen, auf eine Wirklichkeit, in der alle relevanten Zustände und Zustandsveränderungen nur genauso vorkommen, wie es das formale Modell der Organisation im System der Software beschreibt bzw. vorschreibt. Die operative Software befindet sich aus dieser Perspektive ständig in einer Optimierungsphase.

D IE

OPERATIVE

S OFTWARE

| 211

INTERVIEWPARTNER X: „Man kann halt in so einem Implementierungsprojekt nicht von vorneherein sagen, wir fangen jetzt jeden Fehler von vorneherein ab. Die Kollegen in dem Projektgeschäft, wenn man so ein Implementierungsprojekt hat, kann man gar nicht von vorneherein jede mögliche Konstellation berücksichtigen und vor allen Dingen, man kann auch die, sollte die Kreativität der Mitarbeiter nicht unterschätzen. Ne, also wir haben teilweise dann Prozesse, die halt nicht so sauber laufen und dann muss man auch erst mal analysieren im Detail, an welcher Stelle läuft das eigentlich schief und warum. Und dann stellt man irgendwann fest, dass die Kollegen da an der Stelle gar nicht so arbeiten, wie wir das damals vorgesehen haben, weil es zum Beispiel für die unkomfortabel ist oder manchmal geht’s anders schneller oder die Leute machen Schritt zwei vor Schritt eins.“

Die Möglichkeit, dass Mitarbeiter „mutwillig was Falsches eingeben“ (N), wird unterschiedlich bewertet. X spricht beispielsweise nicht von Mutwilligkeit, sondern von einer nicht zu unterschätzenden „Kreativität der Mitarbeiter“, die sich nicht so verhalten, „wie wir das damals vorgesehen haben“. „Prozesse, die halt nicht so sauber laufen“, werden von ihm und anderen internen Beratern analysiert und verändert. Ein anderer Interviewpartner nennt verschiedene Möglichkeiten, Mitarbeiter dazu zu bringen, sich so zu verhalten, wie es im Organisationsmodell der Software vorgesehen ist. INTERVIEWPARTNER N: „Also der Werker wird zum Beispiel an vielen Stellen einfach dazu gezwungen, wenn er etwas bestätigen will, muss er zum Beispiel einen Barcode einscannen. So, und dafür muss er halt vor dem Fach stehen. Er muss halt vor dem Regal stehen, an dem dieser Aufkleber mit dem Barcode angebracht ist. Er muss diesen Barcode anscannen und einlesen. So, wenn er das jetzt meint irgendwie im Büro zu machen, dann kann er das gar nicht, weil er halt diese ganzen Barcodes nicht zur Verfügung hat. Aber dementsprechend versuchen wir natürlich über solche Technologien den Werker schon dazu zu zwingen, an der richtigen Stelle zu sein und die Arbeit dann auch zu machen. Das funktioniert eigentlich auch sehr, sehr gut. Muss man dazu sagen.“

Mehrmals werden in diesem Ausschnitt die Verben „zwingen“ und „müssen“ verwendet, um auf die determinierende Wirkung der Software hinzuweisen. Das Entscheidungsverhalten von Mitarbeitern (Werker) soll über die Programmabläufe der Software gesteuert werden. Um das Organisationsmodell der Software und die Organisationspraxis annähernd zur Deckung zu bringen, versucht man einerseits, Mitarbeiter an die ‚elektronische Leine’ zu nehmen, ihre Gewohnheiten zu verändern und damit die Organisation der Technik anzupassen. Dass die Anpassung auch umgekehrt erfolgt, beschreibt O im folgenden Interviewausschnitt.

212 | D AS P ROJEKT SAP INTERVIEWPARTNER O: „Also ich muss zurzeit noch sagen, sie [die Software] wächst eigentlich viel zu viel mit. Also ich finde, wir sind, wir haben es vor, wir haben es Anfang 2008 hier eingeführt in B., Mitte 2007 in W. Genau. Und seitdem sind wir eigentlich jedes Jahr immer noch am Ändern. Also jedes Jahr gibt irgendwas Neues, hier noch ein IPünktchen drauf und da noch. Und ich finde irgendwann muss man auch mal sagen so, jetzt wird erst mal damit als Standard S. [Name des Unternehmens; H. M.] gearbeitet, um auch mal zu sehen, ohne das ständig irgendwelche Neuerungen, irgendwelche neue Sachen einlaufen, was man gar nicht mehr sieht, welche Sachen eigentlich alle benutzt werden und welche nicht. Es ist so viel programmiert worden, wo ich glaube, das gibt es, wird aber nie benutzt. So ungefähr und da müsste man eigentlich mal so irgendwo was sagen, jetzt ist mal Schluss. Man kann nicht immer alles weiterentwickeln.“

Auch nach dem Projekt der Softwareimplementierung ist das Customizing von SAP nicht abgeschlossen. Interviewpartner N beschreibt die operative Software, die vor über 15 Jahren im Unternehmen eingeführt wurde, folgendermaßen: „Es gibt SAP bei S. schon seit 2000 glaube ich. Allerdings dann auch mehr so nach dem Motto, hier ist das SAP-System, wenn ihr davon irgendwas nutzen wollt, bitte schön, macht das alleine. Das heißt also, das heißt einige Teilbereiche haben dann so eine Eigendynamik entwickelt und haben dann halt sich selber SAP Berater gesucht und haben dann angefangen, irgendwelche Prozesse da abzubilden. Das tut uns heute natürlich manchmal noch ein bisschen weh. [...] Wir schmeißen das wiederum alles weg, was die damals so alleine gebaut haben und machen, nehmen das dann auf in unsere Kernlösung. [...] Und na ja, das Schlimme ist eigentlich an dem Host, das er halt so schlecht erweiterbar ist. Dann entwickeln sich parallel zum Host natürlich wieder andere eigene Programme und Datenbanken nebenbei und das versuchen wir natürlich auch alles einzudämmen und wieder einzufangen und wieder alles mit dem SAP, in unsere SAP-Lösung aufzunehmen.“

Obwohl sich das Unternehmen für die Einführung von SAP als Standardsoftware entschieden hat, hat dies bislang nicht zu einer umfassenden informationstechnischen Standardisierung und Verzahnung von Arbeitsabläufen geführt. Zwar ist die Implementierung der Software in den verschiedenen Unternehmensbereichen abgeschlossen, die Einführung der Module ist jedoch nicht aufeinander abgestimmt. Selbst die Beauftragung von SAP-Beratern, so der Interviewpartner, ist nicht bereichsübergreifend koordiniert worden. Noch Jahre nach der Einführung von SAP wird versucht, die Unternehmensbereiche, deren Eigendynamik sich in den Programmabläufen der Software widerspiegelt, zentral zu steuern und die Individualisierung der Standardsoftware „einzudämmen und wieder einzufan-

D IE

OPERATIVE

S OFTWARE

| 213

gen“ (ebd.). Die Ablösung der verschiedenen (Alt-)Systeme wird als aufwendiger und noch andauernder Prozess beschrieben. INTERVIEWPARTNER N: „Und gut, jetzt kann man meinen, wenn die plötzlich mit SAP arbeiten und vorher vielleicht mit einer anderen Software gearbeitet haben, die müssen ja immer noch das Gleiche machen wie vorher. Vom Prinzip her ist das natürlich auch so. Es ist allerdings auch so, dass SAP natürlich seine eigenen Begrifflichkeiten hat und die muss man erst mal lernen. Also geht auch darum Vokabeln zu lernen, also den Leuten dann beizubringen, es geht hier um eine Anmeldung an einer SAP GUI [„Graphical User Interface“ bzw. die Darstellungsebene von SAP: H. M.] oder man muss einen Transaktionscode eingeben und da gibt es solche Dinge wie die organisatorischen Begriffe wie, es gibt dann halt Verkaufsorganisationen und es gibt Materialstämme und es gibt Debitoren- und Kreditorenstammdaten und alles, was so ein SAP-System halt gerne hätte als Konfiguration und als Information, gibt’s da entsprechend Vokabeln für, das müssen die Leute auch erst mal lernen.“

Dass sich die Organisation der Technik SAP und ihrer Systematik nicht automatisch anpasst, machen N und andere Organisationsmitglieder in ihren Beschreibungen deutlich. Die technische Leistungsfähigkeit der Software kann durch das Hinzufügen von Rechnern bzw. Knoten in einem Netzwerk verschiedener Rechner nahezu unbegrenzt gesteigert werden.4 Das System der Standardsoftware kann mehr oder weniger rücksichtlos erweitert werden, d. h. die Software kann für Nutzer an verschiedenen Standorten ausgebaut werden. Im folgenden Interviewausschnitt wird deutlich, dass die Organisation keineswegs automatisch nachzieht. Auch Jahre nach der SAP-Einführung gibt es in Unternehmen neben einem zentralen System wie SAP parallele Datenverarbeitungssysteme an den verschiedenen Standorten. INTERVIEWPARTNER W: „Der Konzern kaufte in den vergangenen 10 Jahren Standorte in Osteuropa auf. Die wurden nach und nach, ich sage ketzerisch in Mund-zu-MundBeatmung, einzeln auf unser System genommen. Ich behaupte heute noch, Mensch, in Polen läuft noch ein anderes System parallel. Und ihr sagt es nicht, oder ihr wisst es nicht, oder ihr merkt es nicht.“

Interviewpartner O arbeitet im Qualitätsmanagement der deutschen Konzernzentrale eines Handelsunternehmens und schildert die Verwendung der Software in der Organisation so:

4

Vergleiche KAPITEL 1.1.4 „Die Softwarearchitektur“.

214 | D AS P ROJEKT SAP „Also wir haben bei S. [Name des Unternehmens; H. M.] so, ja die Prozesse in allen Niederlassungen sollten eigentlich gleich sein. Also seit wir SAP einführen und ausrollen an die verschiedenen Niederlassungen ist das so, dass wir sagen, die Prozesse sind überall gleich. B. [Standort der deutschen Zentrale; H. M.] ist der Kopf und gibt vor wie gearbeitet wird. Und W. [Niederlassung in Deutschland; H. M.] arbeitet genauso wie B. England arbeitet genauso wie B., also vom SAP her und Spanien wird ja dieses Jahr ausgerollt, genau das Gleiche. Also alle sollen gleich arbeiten. Das hat klare Vorteile. Man redet in jedem, also in jeder Firma von, weil man muss ja von einzelnen Firmen reden, von dem Gleichen.“

Die Angleichung der Standortunternehmen an die Unternehmenszentrale ist der Soll-Zustand. Es handelt sich um das vermeintliche Projektziel der Softwareimplementierung, das noch zu verwirklichen ist. Das Vorgehen bei der Implementierung der Software bezeichnet er mit dem Wort „ausrollen“ (ebd.) – eine direkte Übersetzung des englischen roll out. Dieser Begriff hat verschiedene Bedeutungen. Softwareentwickler bezeichnen so die Verteilung von Softwarekomponenten auf verschiedene Rechner. Berater hingegen meinen damit die mit der Softwareeinführung verknüpften organisatorischen Aufgaben wie Projektmarketing, Softwaretrainings, Monitoring und Reporting der Projektfortschritte. O hingegen charakterisiert die Softwareimplementierung damit als zentral gesteuerten und reibungslosen Prozess. „Wie gearbeitet wird“, werde von der Unternehmenszentrale vorgegeben. Die einzelnen Standorte sind Zielobjekte, die Konzernzentrale das bestimmende Zentrum der Standardisierung („B. ist der Kopf“). INTERVIEWPARTNER O: „Also wenn ich hier von einem Lagertyp rede, wo es um Beanstandungen geht, also der heißt bei uns 917 zum Beispiel oder 927. Es gibt zwei Stück. Dann ist das in den anderen Standorten genau das Gleiche. Und wenn ich von bestimmten Lagerorten rede, die nur QM [Qualitätsmanagement: H. M.] angeht, rede ich eben auch von dem Gleichen und nicht von zehn verschiedenen, die da anders heißen und so weiter. Also hier gibt’s ganz klare Prozessvorgaben. [...] So läuft das.“

Die Verwendung derselben Kategorien vereinfacht die Kommunikation zwischen verschiedenen Standorten. Ob O mit der Formulierung „[H]ier gibt’s ganz klare Prozessvorgaben“ bloß das Modul der Software oder seine Abteilung in der Unternehmenszentrale gemeint hat, kann im Nachhinein nicht geklärt werden. Tatsächlich vermischen sich in den Beschreibungen softwareinduzierte Vorgaben und Direktiven der Unternehmenszentrale. Der nachgeschobene Satz „So läuft das“ (ebd.) verleiht der Aussage besonderen Nachdruck, kann aber gleichzeitig als Appell verstanden werden, der eigentlich an die einzelnen Standorte

D IE

OPERATIVE

S OFTWARE

| 215

gerichtet ist, den Vorgaben der Zentrale zu folgen. Die Beschreibungen der Softwareverwendung machen deutlich, das die Einführung einer Standardsoftware wie SAP ein lang andauernder Prozess ist, der keinen Endpunkt hat.

9.3 L OKALE D ATENSAMMLUNGEN (N ICHT -)I NFORMATIONEN

UND

Der Informationswert von Unternehmensdaten hängt davon ab, welche Daten in den Datenbanken gesammelt und welche Datenverknüpfungen mithilfe der Software hergestellt werden können. Welche Datenverknüpfungen überhaupt realisiert werden können, führen ausnahmslos alle Interviewpartner und Interviewpartnerinnen auf die Individualisierung des Organisationsmodells und die Modifikation der Software während der Softwareimplementierung zurück.5 INTERVIEWPARTNERIN W: „Das heißt nicht ganz die Hälfte, aber auch mehr als ein Drittel des täglichen, des operativen Systems ist handgestrickt. Handgestrickt, deshalb nennen wir das System Neuschwanstein. Noch ein Türmchen und noch ein Fensterle, Extraziegel und hier ein Erker. Handgestrickt. Daher kommt das Bild. SAP ist nur der Rumpf. Man zieht sich die Daten nur raus und verarbeitet die dann irgendwie weiter. Man bringt Effekte rein, die mehr als das Übliche sind, als die eines Controlling. Doch die Daten, die ein SAP bietet, sind auch nur so gut, wie man es strukturiert, gefüttert und auch, ja, individualisiert hat. SAP nutzt man hier als bessere Schreibmaschine. Ein anderer Spruch, den ich hier auch habe. Ich gebe die Daten zwar ein, aber ich verarbeite sie nicht wirklich weiter. Das ist auch ein Resultat der Eigenentwicklungen, die praktisch, ja weil sie Weiterverarbeitung verhindern. So kommt das, was ich Nebelkerzen im System nenne, also eigentlich in den Prozessen.“

Während der Softwareimplementierung sind die Konditionen für die Softwareverwendung weitreichend festgelegt worden. Mit dem Ausdruck „handgestrickt“ (ebd.) weist W auf ein unprofessionelles Vorgehen beim Customizing der Standardsoftware hin, das dazu beigetragen habe, dass die Verarbeitung von Daten weiterhin außerhalb des Systems der Software erfolge: „Man [...] verarbeitet die [Daten] dann irgendwie weiter“ (ebd.). Die Interviewpartnerin verwendet verschiedene Metaphern, die darauf hinweisen, dass die operative Software im Un-

5

Siehe hierzu KAPITEL 6 „Die Beratungsinteraktion“ und KAPITEL 7 „Die Projektorganisation“.

216 | D AS P ROJEKT SAP

ternehmen bloß als Datensammlung fungiert.6 Zentrale Datenbanken bzw. ein zentrales Datenbanksystem sind in einer Organisation, die über mehrere Standorte verteilt sind, keinesfalls selbstverständlich. Interviewpartnerin W berichtet, wie sich ein Standort der konzernweiten Softwareeinführung entzogen hat, indem die Mitarbeiter ihre Daten erst gar nicht in das SAP-System eingaben. INTERVIEWPARTNERIN W: „Die zogen aus dem HR [Human Resources ist die Bezeichnung für das Modul für die Personalwirtschaft: H. M.] aus. Wie macht man das denn als Land? Die geben einfach keine Daten mehr ein. Die zogen aus. Die schrieben eine Mail: Wir machen jetzt auch keine Abrechnung mehr aus dem SAP. Wir lassen das vom Steuerberater machen. Wir liefen natürlich Sturm, aber letztendlich konnten wir es nicht verhindern. Weil es dann Machtworte braucht, von der Unternehmensspitze, von der Landesspitze. Und die sagten, nee, das wollen wir nicht, das machen wir jetzt eben anders. Und das habe ich auch noch nie erlebt, dass die aus dem System davon geschlichen sind. Für sie mit wirklich guten Argumenten. Also lokal kann ich die Argumente sogar verstehen. Zentral darf ich sie nicht und kann sie auch nicht verstehen.“

W ist selbst darüber erstaunt, dass sich ein Standort gegen die Softwareverwendung entscheidet, obwohl die konzernweite Softwareimplementierung von der Unternehmensspitze bereits beschlossen worden ist. Die Konzernzentrale ist bei der Entscheidung gegen die Softwareverwendung nicht involviert, sondern lediglich im Nachhinein in Kenntnis gesetzt worden. W weist in diesem Zusammenhang auf die fehlenden „Machtworte“ (ebd.) des Konzernmanagements und des Standortmanagements hin. Erst die Untätigkeit des Managements habe dazu geführt, dass sich der ungarische Standort „aus dem System davon[schleichen]“ (ebd.) konnte. Aus Sicht der Unternehmenszentrale verurteilt W diese Entscheidung des Standortes. Die Interviewpartnerin räumt jedoch ein, dass es aus der Sicht des Standortes nachvollziehbar sei, aus Kosten- und Kapazitätsgründen bestimmte Aufgaben nicht über das System der Standardsoftware abzuwickeln und Daten weiterhin lokal zu verarbeiten. Die Produktionswerke, so erklärt W im weiteren Verlauf des Interviews, sind an diesem Standort vor einigen Monaten

6

„Neuschwanstein“ steht für die idealisierte und romantisierte Vorstellung einer mittelalterlichen Ritterburg mit vielen Türmen und Erkern. Das Schloss Neuschwanstein wurde nie vollständig fertiggestellt und vom Auftraggeber nicht bewohnt. Der „Rumpf“ bezeichnet einen Körper ohne Kopf und Gliedmaßen. Die „Schreibmaschine“ gilt im Hinblick auf die Textverarbeitung als ein historischer Vorläufer des modernen Computers. Eine Datenverarbeitung, bei der Daten miteinander in Beziehung gesetzt werden, findet noch nicht statt.

D IE

OPERATIVE

S OFTWARE

| 217

geschlossen worden. Der Vertrieb und die Verwaltung beschäftigt nur noch einige wenige Mitarbeiter am ungarischen Standort, die mit der Dateneingabe in das zentrale SAP-System schlicht überlastet gewesen wären. Welche Daten in der Organisation wie aufbereitet und ausgewertet werden, ist weiterhin an die Datenverarbeitungskapazität und das Wissen der beteiligten Personen geknüpft. Lokale und verteilte Datenverarbeitungssysteme in der Organisation sind keineswegs bloß eine Ausnahme. Dies unterstreichen auch andere Interviewpartner und Interviewpartnerinnen in ihren Ausführungen. INTERVIEWPARTNER D: „Man bekommt mit der Einführung der SAP schon ein integriertes System. Das heißt aber nicht, dass die Leute nicht doch versuchen ihre Altsysteme zu halten und das beste Beispiel dafür ist Excel. [...] Das liegt einfach da dran, weil die das Gefühl haben, das ist auf meinem PC, ich kann es manipulieren. Die SAP-Datenbank ist halt weit weg. Das ist aber nicht ein Unternehmensproblem von uns, sondern das ist generell ein Problem, das sich viele Kollegen beschweren, wie kriege ich eigentlich Leute dazu, von Excel wegzukommen. Weil, die haben sehr viel Geld investiert, um SAP-Standard zu haben. Ist normal, also da gibt’s die wildesten Geschichten, wo man sagt, wofür haben wir eigentlich die Millionen in die Hand genommen und SAP eingeführt.“

Obwohl die Altsysteme mit der Einführung von SAP abgelöst und in ein integriertes System wie SAP überführt werden sollten, verwenden viele Organisationsmitglieder weiterhin Programme wie Excel. D stellt heraus, dass die Verwendung von Excel nicht typisch für sein Unternehmen ist, sondern dass es sich hierbei um ein generelles Problem in Organisationen handelt: „Ist normal, also da gibt’s die wildesten Geschichten“ (ebd.). Ein allgemeines Organisationsproblem würde deshalb lauten: „[W]ie kriege ich eigentlich Leute dazu, von Excel wegzukommen“ (ebd.). Das Rechnungswesen und das Controlling eines Unternehmens gelten als klassische Anwendungsdomänen für SAP-Software. Von mehreren Interviewpartnern wird das Controlling allerdings als ein Beispiel dafür genannt, dass auch weiterhin lokale Datenverarbeitungssysteme in Organisationen im Einsatz sind. Diese lokalen Systeme stehen einer zentralen Steuerung und Kontrolle im Unternehmen entgegen. INTERVIEWPARTNER X: „Also das Rechnungswesen ganz bestimmt. Personal, wenn es um die Verwaltung geht, um die Stammdaten, ja, die Urlaubsplanung, ja, die Abrechnung auch. Ja. Finanzen, ja. Controlling, behaupte ich mal, weniger als das ich es erwarten würde. Hängt aber eben mit diesen Strukturen hier zusammen. Noch große Teile werden dann doch auf Excel weiter prozessiert.“

218 | D AS P ROJEKT SAP

X beantwortet die Frage, inwieweit die Software in den einzelnen Unternehmensbereichen verwendet wird, um Arbeitsabläufe abzubilden und zu strukturieren. In dem Interviewausschnitt hakt er eine imaginäre Checkliste ab. Die Kommunikation über Zahlen spielt in den von ihm genannten Bereichen eine herausragende Rolle. Er bejaht die Frage zur Softwareverwendung für fast alle genannten Unternehmensbereiche im Organisationsalltag. Er räumt ein, dass die Software im Controlling vergleichsweise wenig verwendet wird. Die im Organisationsmodell von SAP beschriebenen ereignisgesteuerten Prozessketten werden unterbrochen. Daten werden außerhalb des Systems der Software „weiter prozessier[t]“ (ebd.). INTERVIEWPARTNERIN Q: „Also ich arbeite auch noch viel, wenn es um Auswertungen geht mit Excel, weil mir Excel einfach mehr Freiheiten bietet. SAP hat die Möglichkeit, also alle haben einen Button für weitergehende Reports eingerichtet, wo ich in Excel exportieren kann. Wo ich dann wieder hin und her sortieren kann und spielen kann, weil SAP ist ja ein Informationssystem, wo ich mir Daten rausziehe. Mit Excel, klar arbeite ich dann immer noch, oder Access, wenn man halt irgendwelche Daten aneinander fahren möchte.“

Q erklärt, warum sie selbst auf zusätzliche Werkzeuge bei der Datenverarbeitung zurückgreift. Anwendungsprogramme wie Excel oder Access ermöglichen ihr bei der Auswertung von Daten „mehr Freiheiten“ (ebd.). Teilweise ist die Datenverarbeitung außerhalb des Systems im Konzept von SAP vorgesehen. Es gibt einen „Button für weitergehende Reports“ (ebd.). Inwiefern Softwarenutzer auf diese Möglichkeit zurückgreifen können, ist allerdings an das Berechtigungskonzept der Software geknüpft. INTERVIEWPARTNER N: „Unserer Geschäftsführung, denen ist das eigentlich völlig egal, die kriegen den Bericht und da drin sehen die ihre Zahlen. Im Hintergrund kann das natürlich gut sein, dass diese Zahlen zum einen aus dem Microsoft-System gekommen sind, die sind aus unserem SAP-System gekommen, aus unserem Kernsystem, und die sind vielleicht auch noch aus dem alten Host gekommen. Der Großteil der Geschäftsführer haben gar keinen direkten Kontakt zum System. Sondern es werden natürlich, es gibt andere Leute, die bereiten dann diese Berichte auf und übermitteln die dann über ganz normale Standard-Office-Lösungen wie Excel.“

Die Entwickler der SAP-Standardsoftware wollten mit ihrer Technik zwar die Datenverarbeitung in Unternehmen vereinheitlichen und unterschiedliche Datenverarbeitungssysteme in einem System zusammenführen. Faktisch werden

D IE

OPERATIVE

S OFTWARE

| 219

Daten auch weiterhin aus unterschiedlichen Datensammlungen kombiniert, um daraus Informationen zu ziehen. Leitbild für den Entwurf des relationalen Datenbankmodells war der casual user (Codd 1970). Gemeint ist damit ein Nutzer, der ohne spezielles Programmierwissen Datenbanksysteme für flexible und spontane Abfragen verwenden kann. Interviewpartner S beschreibt jedoch ein vollkommen anderes Nutzerkonzept für die Software, die auf der relationalen Datenbanktechnik basiert. „Es muss ja wirklich Know-how angefordert werden. Im Grunde, die da wissen, welche Tabellen denn wo, wie miteinander zusammenhängen. Darum redet man hier bei uns im Einkauf immer von der M.-IT [M. ist der Name eines Mitarbeiters in der IT-Abteilung des Unternehmens; H. M.], also es gibt jemanden, der für den Einkauf ganz viel mit Access und sonst was für Geschichten macht. Also eigentlich ganz gruselig, aber damit auf, wenn ein Einkauf eine Information braucht in einer gewissen Konstellation, das damit eben schnell und einfach und kostengünstig lösbar ist. Bei dem SAP muss ein Antrag gestellt werden, dann müssen irgendwelche Programmierer schauen, was ist da machbar, was ist da nicht machbar und ja, dann haben wir schon unser Geschäft versäumt.“

Im System der Software sind die Möglichkeiten der Datenbankabfrage und Datenverknüpfungen an ein Berechtigungskonzept geknüpft. Dieses Konzept sieht vor, dass andere (z. B. Softwareentwickler, Beraterin und Key-User) festlegen, welche Daten vom Softwarenutzer benötigt werden. Diese Festlegung erweist sich in der Organisationspraxis als Nachteil für die Organisation. Datenbankabfragen können nicht mehr flexibel realisiert werden: „[W]as ist da machbar, was ist da nicht machbar“ (ebd.). Die Mitarbeiter sind auf Spezialisten angewiesen, um auch nicht-standardisierte Datenbankabfragen durchführen zu können. Derjenige, der Daten verwenden will, muss zunächst einen Antrag stellen bzw. die Erlaubnis für die Softwareverwendung bei jemandem einholen. In der Folge dieser Einschränkungen fehlen Informationen, die beispielsweise die Position eines Mitarbeiters im Einkauf in Verhandlungen mit einem Lieferanten stärken würde. In der Organisationspraxis sind Abweichungen vom Konzept der Standardsoftware, das ein einheitliches System der Datenverarbeitung im Unternehmen vorsieht, auf ein generelles Problem beim Umgang mit einer neuen Technik zurückzuführen. Das erforderliche Know-how muss von den meisten Organisationsmitgliedern erst erlernt werden. Was dies im Fall der Software bedeutet, erläutern mehrere Interviewpartner am Beispiel von Transaktionscodes, die für ei-

220 | D AS P ROJEKT SAP

ne direkte Instruktion der Anwendungsprogramme sorgen.7 Die Eingabe des Transaktionscodes ermöglicht im Gegensatz zur Navigation an der Bildschirmoberfläche einen schnelleren und flexibleren Zugriff auf SAP-Anwendungen und die ihnen zugrunde liegenden Datenbanken. Der Code kann nicht aus der natürlichen Sprache abgeleitet werden. Ähnlich wie der Maschinencode besteht der Transaktionscode lediglich aus einer Folge von Zahlen und Buchstaben, d.h. der Code für eine bestimmte Datenbanktransaktion muss dem Nutzer bekannt sein. INTERVIEWPARTNER S: „Wenn ich im SAP, wenn ich nicht vorher weiß, wie diese Transaktion, so heißt das ja da, heißt, dann bin ich schon mal aufgeschmissen. Und das SAP ist so mächtig von dem was es an Daten und so weiter bieten könnte, aber ich komme ja gar nicht ran. Das ist, also das ist schon mal das erste Problem. Ich komme ja gar nicht, ich kriege gar nicht das, was ich brauche. Ne, also ich kann gar nicht das rausziehen, was da drinnen steckt. [...] [D]as ist schon problematisch an diesem Ding da.“

Software als „Ding“ (ebd.) zu bezeichnen, weist darauf hin, dass die Technik in der Organisation als eine Art Fremdkörper wahrgenommen wird. Damit Organisationsmitglieder aus Datensammlungen Informationen für sich ziehen können, müssen Daten überhaupt als Information verstanden werden. Ein NichtVerstehen führt Interviewpartner N nicht nur auf den umständlichen Datenzugriff, sondern auch auf das verwendete Vokabular im System der Software zurück. Außerdem legt die Software eine bestimmte Systematik (z. B. Materialstämme, Kreditorenstammdaten) zur Beschreibung der Organisation und ihrer Arbeitsabläufe fest, die von den Organisationsmitgliedern erst einmal verstanden werden muss.8

9.4 D IE OPERATIVE S OFTWARE : D AS P RODUKT E NTSCHEIDUNGSNETZWERKES

EINES

Von Interviewpartnerin W wird das Bild der Nebelkerzen mehrfach aufgegriffen, um die operative Software zu beschreiben. Üblicherweise wird mit der Redewendung „Nebelkerzen zünden bzw. werfen“ eine rhetorische Taktik der Verschleierung oder Ablenkung bezeichnet. Im folgenden Interviewausschnitt wer-

7

Der Transaktionscode wird in der Befehlszeile am rechten oberen Rand des Bildschirms eingegeben. Siehe ABBILDUNG 3 in KAPITEL 1 „Das 3-Ebenen-Modell“.

8

In KAPITEL 1.2 „Die Anwendungsebene“ wurde die Systematik von SAP zur Modellierung von Organisationen erläutert.

D IE

OPERATIVE

S OFTWARE

| 221

den die Modifikationen der Standardsoftware und des Organisationsmodells der Software beschrieben, die dazu führen, dass Daten aus verschiedenen Organisationseinheiten nicht miteinander verglichen werden können. INTERVIEWPARTNERIN W: „Transparenz ist für mich ein schneller, verfügbarer Vergleich von Daten. Der Zugriff auf vergleichbare Daten. Das ist genau das Spannende. Das ist bei uns nicht möglich. Durch die mühevolle Kleinarbeit, in diesem Fall eines speziellen KeyUsers, der im Betriebsrat sitzt. Auch so was bildet sich ab. Und ein Mitarbeiter, zum Glück für die IT, bald in Frührente ging. Nachdem ich angekommen war, hat man also erst einmal ein paar Nebelkerzen ins System eingebaut, die Dinge so weit verarbeitet, dass es nicht mehr transparent war, ob das nun meine Maintenance-Kosten vom Werk U, oder vom Werk N oder vom Werk XY sind. Das ist ja genau das, was man im Unternehmen vergleichen will. Das können wir nicht.“

Die operative Software verdeckt bzw. vernebelt im wortwörtlichen Sinne organisatorische Beziehungen und Zusammenhänge, die mit einer Standardssoftware wie SAP eigentlich aufgedeckt werden sollen. Von allen Softwarenutzern wird in ihren Beschreibungen das Potenzial der Technik thematisiert, Arbeitsabläufe im Unternehmen transparenter zu gestalten. Transparenz bezieht sich dabei nicht nur auf Datenbankinformationen, sondern wird mit Kostentransparenz im Unternehmen gleichgesetzt, die es ermöglicht, Ausgaben im Unternehmen eindeutig zuzuordnen und entsprechend Verantwortlichkeiten zu bestimmen. Stereotype wie das Betriebsratsmitglied, der Finanzvorstandskollege, der IT-Mitarbeiter etc. spielen in den Interviews eine zentrale Rolle, um auf konkurrierende Interessen zwischen organisatorischen Gruppen bei der Softwareimplementierung und der Softwareverwendung hinzuweisen. Dass die technischen Möglichkeiten der Software nicht ausgeschöpft werden, führt Interviewpartnerin W beispielsweise auf die Anstrengungen eines einzelnen Mitarbeiters zurück. Das Verhalten ihres Kollegen versucht sie nicht zu erklären, sondern belässt es bei dem Hinweis, dass es sich bei diesem Mitarbeiter um ein Mitglied des Betriebsrats handelt. Sich selbst charakterisiert sie als Neuling in der Organisation, der mit einem bereits installierten Softwaresystem konfrontiert wurde. Die IT-Leiterin W schildert den Versuch, die IT-Abteilung aus der bestehenden politischen Ordnung der Organisation auszuklammern. Doch auch die IT-Abteilung und ihre Mitglieder sind eingebettet in die hierarchischen Strukturen der Organisation. Von den Kollegen werden die IT-Mitarbeiter deshalb keineswegs als überparteiliche oder neutrale Instanz betrachtet.

222 | D AS P ROJEKT SAP INTERVIEWPARTNERIN W: „Ich habe vorher immer gedacht, es spielt überhaupt keine Rolle, ob ich an einem A, B oder C hänge. Es spielt eine Rolle. Es spielt vielleicht für mich in der IT keine Rolle, als zentraler Servicebereich. Aber es spielt für die Vorstände sehr wohl eine Rolle. Natürlich zieht ein Vorstand nach außen immer an einem Strang. Man nimmt von außen wahr, das ist die oberste Ebene und die wollen alle dasselbe. Aber nein, da gibt es auch vertikale Schneidungen im Unternehmen, die man von außen gar nicht so wahrnimmt.“

Nicht nur die im Softwareprojekt direkt involvierten Key-User entscheiden über die zukünftige Softwareverwendung. Es sind Mitglieder des Vorstands, die W in diesem Zitat dafür verantwortlich macht, dass die Software in der Organisation nur ansatzweise verwendet wird, weil sie „gar kein Interesse daran [haben], Transparenz zu zeigen“. In der von W beschriebenen Organisation werden die technischen Möglichkeiten der Software nur ansatzweise genutzt. Die operative Software charakterisiert die Interviewpartnerin wiederholt als „NeuschwansteinRudiment“. INTERVIEWPARTNERIN W: „Auch wenn wir SAP nur als Rudiment, NeuschwansteinRudiment sozusagen im Einsatz haben, erkennt man doch, was mal die Motivation gewesen sein könnte. Klare Zahlen. Ich will mich verlassen können auf Zahlen. Und dann fange ich an, gleichartige Informationen zu prozessieren. Es ging glaube ich wirklich um diese Gleichschaltung von Prozessen, vordergründig war bestimmt genannt Geschwindigkeit. Transparenz ist für mich ein schneller, verfügbarer Vergleich von Daten. Von vergleichbaren Daten. Das ist genau das Spannende. Das ist ja genau das, was man im Unternehmen vergleichen will. Das können wir nicht. Und es gibt viele Menschen und das geht auch bis in die Unternehmensspitze, die haben gar kein Interesse daran.“

Bei ihrer Beschreibung der Softwareverwendung unterscheidet W im Goffmanschen Sinne zwischen Vorder- und Hinterbühne (Goffman 1969). Auf der Vorderbühne sei die Aufgaben- und Entscheidungsunterstützung für alle Organisationsmitglieder thematisiert worden. Auf der Hinterbühne würde es primär um die Kontrolle und Steuerung durch die Unternehmenszentrale gehen. Die Verwendung der Software im Organisationsalltag sollte zu „klaren Zahlen“ (ebd.) führen. Damit man sich auf Zahlen verlassen kann, fügt die Interviewpartnerin hinzu, ist es notwendig „gleichartige Informationen zu prozessieren“ (ebd.). Die Einführung von SAP bedeute die Gleichschaltung von Prozessen, um Zahlen zur Beschreibung unterschiedliche Unternehmensstandorte zu erzeugen und miteinander vergleichbar zu machen.

D IE

OPERATIVE

S OFTWARE

| 223

INTERVIEWPARTNERIN W: „Der offizielle Motor war immer der, jetzt haben wir noch ein Land, jetzt haben wir noch was dazu gekauft, wir expandieren nach X und jetzt sehen wir zu, dass wir das alles mal vereinheitlichen. Das andere, dass man eine Vergleichbarkeit wollte. Dass es wirklich darum geht, dass ich sagen kann, in den unruhiger gewordenen Gewässern der globalen Wirtschaft, dass ich sag: Lohnt es sich denn noch, Ungarn zu halten? Was bringt uns die Slowakei? Bringt uns die Slowakei noch was? Oder kosten die Polen uns nur was?“

„[V]ereinheitlichen“ und „Vergleichbarkeit“ (ebd.) werden als zwei Aspekte der Softwareimplementierung und -verwendung genannt. Mit dem Ideal der Vereinheitlichung habe die Unternehmensführung ihre Entscheidung zur Einführung einer Standardsoftware im Unternehmen gerechtfertigt.9 Die Implementierung derselben Software an verschiedenen Standorten ist demnach Teil der Unternehmensstrategie eines globalen Konzerns, um Arbeitsabläufe aufeinander abzustimmen und miteinander zu verzahnen. Von W wird diese Form der Vereinheitlichung als „offizieller Motor“ des Softwareprojektes bezeichnet. Die Standorte beispielsweise hinsichtlich ihrer Kosten miteinander in Beziehung zu setzen, bezeichnet eine andere Strategie: die Vergleichbarkeit und Bewertung von Organisationseinheiten. Dieser Vorgang läuft als hidden agenda im Hintergrund mit. Die Möglichkeiten einer Standardsoftware für Vergleiche zwischen Standorten und anderen Organisationseinheiten, so räumt W ein, werden in der operativen Software allerdings nur ansatzweise genutzt. INTERVIEWPARTNERIN W: „Und natürlich ist es für denjenigen, der gemessen wird, kein Vergnügen, sich messen zu lassen. Und er wird immer versucht sein zu schönen. Wenn er das Gefühl hat, der Empfänger der Information trifft eine Entscheidung, die einen persönlich nicht lieb sein kann. Und da geht es gar nicht, um Zentrale und Peripherie oder Dezentrale, sondern das haben sie hier im Haus auch, das haben sie überall im Management, auch in den ganz verschiedenen Branchen in denen ich war. Und auch hier in der Soft-

9

Die konzernweite Einführung einer Software wie SAP ist für Ives und Jarvenpaa (1991) ein paradigmatisches Beispiel für eine globale Koordination der Standortunternehmen durch die Unternehmenszentrale. Sie vergleichen den Aufbau der ITInfrastruktur von Konzernen und unterscheiden in Anlehnung an die Organisationstypologie von Bartlett und Goshal (1989) die multinationale Organisation, die internationale Organisation, die globale Organisation und die transnationale Organisation. Die Strukturen globaler Organisationen sind, ungeachtet der vielfältigen und widersprüchlichen Umwelteinbettung einzelner Standortunternehmen, vereinheitlicht und eng miteinander verknüpft.

224 | D AS P ROJEKT SAP ware, hier in unserem SAP können sie das erkennen, dass das, was ich jetzt mal von einer Extremposition her, auch hier Vernebelungspositionen eingebaut wurden. Also Prozesse eher vernebelt werden, denn zu Klarheit führen. Dinge kompliziert und überkompliziert werden. Meines Erachtens, um letztendlich die Messbarkeit zu vermeiden. [...] Und das sehen sie unserem System an. Finde ich.“

Während andere Interviewpartner und Interviewpartnerinnen den Begriff „[M]anipulieren von Daten“ (ebd.) in einem technischen Sinne verwenden, weist W explizit darauf hin, dass Daten „[ge]schön[t]“ (ebd.) werden könnten. Manager seien zumindest versucht, den von ihnen verantworteten Bereich in einem möglichst guten Licht darzustellen. Modifikationen der Software sorgten dafür, dass „Dinge kompliziert und überkompliziert“ (ebd.) gemacht werden würden. Die operative Software ist nicht auf die Entscheidungen einzelner Personen zurückzuführen, sondern das Produkt eines komplexen Entscheidungsnetzwerkes in der Organisation.

Schluss

Arbeitsabläufe werden in Abteilungen und an verschiedenen Standorten aufeinander abgestimmt und als ereignisgesteuerte Prozessketten modelliert. Sachliche Unsicherheiten (Was?) und zeitliche Unsicherheiten (Wann?) sind in den Anwendungsprogrammen von SAP verschwunden. Die verbliebene soziale Unsicherheit (Wer?), die aus der Unübersichtlichkeit von Zuständigkeiten und Verantwortlichkeiten resultieren kann, wird durch die Definition von Benutzerrollen vollständig absorbiert. Das ist die Idee der Unsicherheitsreduktion einer betriebswirtschaftlichen Standardsoftware wie SAP. Entwickelt wurde dieses Ideenkonstrukt von Ingenieuren. Methoden, die zur Systematisierung und Standardisierung technischer Systeme entwickelt worden waren, haben Managementingenieure wie Frederick W. Taylor Anfang des 20. Jahrhunderts auf die Gestaltung organisatorischer Zusammenhänge übertragen. Ingenieure sorgten mit ihren Überlegungen zur Systematisierung und Standardisierung für den Aufstieg ihrer Profession in das Management von Unternehmen. Die Idee der Unsicherheitsreduktion wurde sowohl in der Managementpraxis aufgegriffen als auch in der modernen Organisationstheorie adaptiert. Unsicherheitsreduktion ist ein allgemeines Konzept, mit dem unterschiedliche Formen der Systematisierung in Organisationen aus einer organisationstheoretischen Perspektive beschrieben werden. Die meisten Organisationsforscher und Organisationsforscherinnen sind sich der ingenieurtechnischen Wurzeln des vermeintlich universellen Begriffs der Unsicherheitsreduktion allerdings gar nicht bewusst. Shenhav spricht sogar von einer Kolonisierung des Denkens (vgl. Shenhav 1999: 71ff.). „The concept of uncertainty assumed almost mythical and magical characteristics for organization theorists. For an organizational narrative constructed around the notion of rationality, uncertainty represented darkness and undesirability. It became a Pandora’s box of threats: opportunism, labor unrest, short-sightedness, competition, and other enemies of the organizational order. The engineer, the manager, and the planner were set to the task

226 | D AS P ROJEKT SAP of slaying the dragon of uncertainty. Their authority derived from their ability to cope with and reduce uncertainty.“ (Ebd.: 202)

Als Wegbereiter für eine moderne Organisationstheorie wurde Herbert A. Simon in diesem Buch vorgestellt. Seine Arbeiten über Entscheidungsprozesse in Organisationen gelten bis heute auch als Grundlage für eine Soziologie der Organisation. Für Simons entscheidungstheoretisches Forschungsprogramm ist die Idee der Unsicherheitsreduktion zentral. Er schlägt ein umfassendes Begriffsrepertoire vor und unterscheidet verschiedene, durch Ziel- und Mittelkategorien definierte Rationalitäten. Er behandelt die begrenzte Rationalität des Entscheidungsverhaltens von Individuen und zeigt Möglichkeiten für die Gestaltung rationaler Entscheidungsprozesse in Organisationen auf. Grundlegend für sein Organisationsverständnis ist die Dekomponierbarkeit von Entscheidungssystemen: Die Gesamtziele einer Organisation können in Teilziele zerlegt und sollten so aufeinander abgestimmt werden, dass sie zum Erreichen der Gesamtziele einer Organisation beitragen. Das Management sollte Simon zufolge die Aufgaben eines Designers wahrnehmen und das Instrumentarium der verhaltenswissenschaftlichen Entscheidungstheorie für die Analyse von Entscheidungsprozessen praktisch nutzen. Analysen des Entscheidungssystems und seines Datenbedarfs sollten dabei helfen, Differenzen zwischen Ist- und Soll-Zuständen in der Organisation zu überbrücken und Arbeitsabläufe auf diese Weise effizienter zu gestalten. Nichts anderes versuchen Softwareberater mit der Einführung von SAP. Arbeitsabläufe sollen mithilfe der betriebswirtschaftlichen Anwendungsprogramme effizienter gestaltet werden. Zumindest wurde so der Beratungsauftrag in Interviews mit Softwarenutzern und Softwareberatern beschrieben.1 Das Software-

1

In Computer und Macht in Organisationen stellen Günter Ortmann et al. (1990) fest, dass Informatisierungsprojekte zwar immer mit der Erwartung von Effizienzsteigerungen verbunden sind, in ihrem konkreten Verlauf aber ganz wesentlich von den Strategien und Machtspielen der beteiligten Akteure abhängen. Ortmann und seine Kollegen beschäftigen sich aus einer mikropolitischen Forschungsperspektive mit „d[er] Logik, d[er] Unübersichtlichkeit, de[m] schleppende[n] Verlauf, d[en] Irrtümer[n], Schwachstellen und Risiken, d[en] Pannen, Abbrüche[n] und Neuanfängen der Einführung computergestützter Informations- und Planungssysteme“ (ebd.: 393). IT-Projekte in Organisationen, so resümieren sie, sind hochgradig kontingent. Die beteiligten Akteure (Managementmitglieder, IT-Mitarbeiter, Abteilungsleiter, Sachbearbeiter etc.) verfügen über Handlungsspielräume, doch gleichzeitig sorgen Strukturen dafür, dass diese Spielräume organisatorisch abgesteckt sind. Das Autorenkollektiv setzt sich, über den mikropolitischen Ansatz von Crozier und Friedberg (1979) hinaus,

S CHLUSS

| 227

projekt wurde in diesem Buch als ein paradigmatisches Beispiel für einen informationstechnischen Rationalisierungsversuch in Organisationen vorgestellt. Um das Projekt SAP aus einer organisationssoziologischen Perspektive zu analysieren, habe ich auf zwei komplementäre Theorieansätze zurückgegriffen: 1) die neoinstitutionalistische Organisationstheorie und 2) der systemtheoretische Ansatz von Niklas Luhmann. Die Soziologie zeichnet sich als multiparadigmatische Wissenschaft aus. Dies gilt auch für die Subdisziplin der Organisationssoziologie. In diesem Buch habe ich vor allem auf die Komplementarität der neoinstitutionalistischen Organisationstheorie und des systemtheoretischen Ansatzes hingewiesen. Veronika Tacke fasst den Vorteil der systemtheoretischen Organisationssoziologie folgendermaßen zusammen. „Es liegt [...] eine allgemeine Theorie der Organisation vor, die als thematisch in hohem Maße inklusiv gelten kann, weil sie eine Vielzahl heterogener organisationaler Phänomene in einem konsistenten Rahmen zu erfassen vermag, die damit zugleich – und trotz ihrer starken theoretischen Selektivität – Anschlussstellen zu zahlreichen anderen Theorien der Organisationssoziologie eröffnet.“ (Tacke 2010: 342).

Die „Anschlussstellen“ (ebd.) verdankt der systemtheoretische Ansatz vor allem dem zugrunde liegenden Kommunikationskonzept. Kommunikation kommt aus einer systemtheoretischen Perspektive dann zustande, wenn eine Information, eine Mitteilungsweise und eine Verstehensmöglichkeit ausgewählt worden sind. In der Organisationsforschung wurde die Verbreitung von Organisationsmodellen und Managementkonzepten bisher vor allem als Diffusionsthema untersucht (vgl. Rogers 2003).2 Kommunikation hat in der Diffusionsforschung bislang allerdings keinen systematischen Stellenwert. Bettina Heintz (2010) schlägt vor, Diffusionsprozesse als Kommunikationsprozesse zu analysieren. Was sich mit der Standardsoftware SAP weltweit verbreitet, ist demnach keine exakte Kopie.

umfassend mit der rationalitätskritischen Organisationstheorie von March und Simon (1958) und der Theorie der Strukturierung von Anthony Giddens (1984) auseinander. 2

Diese Beschreibung wird jedoch zunehmend kritisiert, weil es unrealistisch ist, Innovationen als invariante Größen zu behandeln, ihre Implementierung als reibungslose Übertragung zu beobachten und dabei eine vollständige Passivität der Adaptoren zu unterstellen. Der Diffusionsforschung soll diesbezüglich weder theoretische noch empirische Blindheit vorgeworfen werden. Es handelt sich wohl eher um einen methodologisch bedingten Kompromiss zugunsten quantitativer Datenanalysen, für die diese Form der Operationalisierung von Variablen notwendig ist.

228 | D AS P ROJEKT SAP

Die Technik und das Organisationsmodell der Software werden vielmehr als Informationen interpretiert, die auf unterschiedliche Weise mitgeteilt werden können und in Organisationen kommunikativ weiterverarbeitet werden. Sowohl für die neoinstitutionalistische Forschung als auch für Luhmanns Organisationstheorie stellt Simons entscheidungstheoretischer Ansatz einen zentralen Bezugspunkt dar. Darauf möchte ich kurz eingehen: 1) Neoinstitutionalistische Organisationsanalysen beschäftigen sich primär mit dem Verhältnis von Organisation und Gesellschaft. Im Untertitel ihres berühmt gewordenen Aufsatzes machen John W. Meyer und Brian Rowan (1977) deutlich, wie sie den neoinstitutionalistischen Organisationsbegriff verstanden wissen wollen: Formal structures as myth and ceremony. Die formalen Strukturen einer Organisation sind hiernach „prefabricated formulae“ (ebd.: 344), die eine Übereinstimmung mit gesamtgesellschaftlich institutionalisierten Organisationsbildern signalisieren. Der Zusammenhang von Organisationen und (wissenschaftlichen) Theorien über Organisationen wird aus einer neoinstitutionalistischen Perspektive betont. David Strang und John W. Meyer (1993) verweisen im folgenden Zitat sogar explizit auf Simons Organisationskonzept, um die Wirkmacht sozialer Konstrukte und Kategorien in der Gesellschaft zu illustrieren: „A tradition of research and professional practice (in accounting and managerial science) conceptualizes organizations as information processing systems. Many proposals for organizational structure and practice are inspired by this theoretization. Strategic planning schemes, information gathering and processing technologies, budgeting and goal-setting routines, and organizational structures to combat rationality flow rapidly.“ (Ebd.: 498)3

Die Modellierung ereignisgesteuerter Prozessketten und die Echtzeitverarbeitung betriebswirtschaftlicher Ereignisse in den Anwendungsprogrammen von SAP würde hervorragend in diese Aufzählung von Meyer und Rowan passen. SAP und das zugrunde liegende Modell der Prozessorganisation sind aus einer neoinstitutionalistischen Perspektive Teil eines (welt-)gesellschaftlichen Kulturapparates. An diese sozialkonstruktivistische Argumentationslinie knüpfen auch Nils Brunsson und Kerstin Sahlin-Andersson (2000) an, wenn sie Reformprojekte in Behörden, Schulen und Krankenhäusern als Organisationswerdung untersuchen. Sie thematisieren in dem Beitrag Constructing Organizations. The Example of

3

In der Fußnote machen sie die folgenden Angaben: „Distinguished contributions to this perspective include Herbert A. Simon, Administrative Behavior (New York: Macmillian, 1957); James G. March and Herbert A. Simon, Organization (New York: Wiley, 1958).“ (Strang & Meyer 1993: 509)

S CHLUSS

| 229

Public Sector Reform ebenfalls das in den Organisationswissenschaften bis heute einflussreiche entscheidungstheoretische Paradigma von Simon und illustrieren die soziale Wirkmacht des Modells formaler Organisationen in der Praxis. Für das empirische Forschungsprogramm der neoinstitutionalistischen Organisationstheorie sind die von Paul DiMaggio und Walter Powell (1983) formulierten Thesen zur Strukturangleichung von Organisationen wegweisend. Um Strukturangleichungen von Organisationen zu erklären, beziehen sich die Autoren ebenfalls explizit auf die von Simon und anderen Autoren ausgearbeitete verhaltenswissenschaftliche Entscheidungstheorie. „Uncertainty is also a powerful force that encourages imitation“ (ebd.: 151). Die von DiMaggio und Powell formulierten Strukturangleichungsmechanismen – Zwang, normativer Druck und Mimesis – und das vorgeschlagene Organisationsfeldkonzept wurden von mir verwendet, um die Beziehungen und sozialen Dynamiken zwischen Organisationen zu beschreiben, die für die Softwareverbreitung eine wichtige Rolle gespielt haben. Im ersten Teil des Buches erwies sich die Bezugnahme auf die Kernkonzepte der neoinstitutionalistischen Organisationstheorie als instruktiv, weil so das Organisationsmodell der Software expliziert und die Verbreitung von SAP aus einer organisationssoziologischen Perspektive erklärt werden konnte. Um die Innenwelt von Organisationen in den Blick zu bekommen und das Zusammenspiel von Organisation und Technik detailliert zu untersuchen, habe ich im zweiten Teil des Buches eine systemtheoretische Rahmung vorgeschlagen. Auf diesen Ansatz und die (kritische) Bezugnahme Luhmanns auf die Arbeiten Simons gehe ich im Folgenden ein: 2) Im systemtheoretischen Ansatz werden auch Strukturen jenseits formaler Organisationsstrukturen in die Analyse einbezogen. Es wird sowohl zwischen formalen und informalen Organisationsstrukturen als auch zwischen verschiedenen Systemtypen bzw. -ebenen differenziert. Die Interaktion zwischen Organisationsmitgliedern und externen Beratern, die im Zentrum der empirischen Untersuchung zur Integration der Technik in Organisationen stand, konnte innerhalb derselben Theorie behandelt werden.4 Softwareberatungsprojekte, so habe ich

4

Der Stellenwert von Informalität für die späteren organisationssoziologischen Arbeiten von Luhmann sorgt zwischen Vertretern und Vertreterinnen des systemtheoretischen Ansatzes weiterhin für Diskussion (vgl. Tacke 2015: 63ff.). Luhmann selbst begnügt sich in seinem zweiten organisationstheoretischen Hauptwerk Organisation und Entscheidung mit einem Hinweis auf die Arbeit von André Kieserling (Kieserling 1999): „Inzwischen mehren sich die Anzeichen dafür, dass der Begriff der informalen Organisation [...] durch eine Theorie der Interaktionssysteme ersetzt wird. Sie greift

230 | D AS P ROJEKT SAP

auf der Grundlage empirischen Datenmaterials zeigen können, müssen durch das „Nadelöhr einer Interaktion unter Anwesenden“ (Luhmann 1972: 148). Luhmann bezieht sich in seinen organisationstheoretischen Beiträgen maßgeblich auf die Arbeiten von Simon. Im Unterschied zu Simon löst er sich jedoch vollständig von den ingenieurtechnischen Grundlagen der Organisationstheorie. Ein wichtiges Indiz dafür ist, dass die Zweck- bzw. Zielkategorie in der systemtheoretischen Forschung keine übergeordnete Rolle mehr spielt. Stattdessen werden mit Entscheidungsprogrammen, Kommunikationswegen und Personal drei gleichrangige formale Strukturmerkmale in die Organisationsanalyse eingeführt, mit denen die Eigenlogik des sozialen Systems Organisation und die sozialen Dynamiken von Standardisierungsprojekten wie das der Softwareimplementierung erfasst werden können. Mithilfe der neoinstitutionalistischen Organisationstheorie und des organisationstheoretischen Ansatzes der Systemtheorie konnten unterschiedliche Aspekte der Software und des Zusammenspiels von Organisation und Technik ausgeleuchtet werden. Die Ergebnisse der Fallstudie sollen nun zusammengefasst werden. Wie modelliert die Technik eine Organisation? Erklärtes Ziel der Entwickler der Standardsoftware SAP war die Darstellung möglichst vieler Arbeitsabläufe unterschiedlicher Organisationen in einer allgemeinen Form. Kundendaten, Materialdaten und Produktionsdaten sowie Personaldaten und Finanzdaten sollten auf Basis relationaler Datenbanken bereichsübergreifend und auf vielfältige Weise miteinander in Beziehung gesetzt und kombiniert werden. Einerseits wurden das relationale Datenbankmodell, die Echtzeitverarbeitung betriebswirtschaftlicher Ereignisse und die Mehrsprachigkeit als drei charakteristische Merkmale der standardisierten Software vorgestellt, die grundlegend für das Organisationsmodell der Software sind. Andererseits wurde am Beispiel des 3-Ebenen-Modells (Datenbankebene, Anwendungsebene und Darstellungsebene) die Entstehung von SAP als soziale Formung einer komplexen Technik rekonstruiert. Ende der 1970er Jahre war ein Streit entfacht, der um die Dominanz des Programmierers und die Freiheit des Nutzers von Datenbanken kreiste. Das logisch-mathematische Paradigma löste das inge-

auf Anregungen zurück, die Erving Goffman gegeben hatte, und reformuliert sie mit Rückgriffen auf die allgemeine Theorie sozialer Systeme“ (Luhmann 2000: 25).

S CHLUSS

| 231

nieurtechnische Paradigma in der Datenbankentwicklung ab. Die praktischen Vorteile des relationalen Ansatzes nutzten die Entwickler von Unternehmenssoftware wie SAP für eine vergleichsweise einfache Datenbeschaffung für die Programmierung komplexer betriebswirtschaftlicher Anwendungen. Das Organisationsmodell von SAP basiert nicht primär auf einem betriebswirtschaftlichen Ansatz. Am Beispiel der Echtzeit-Datenverarbeitung im Rechnungswesen konnte gezeigt werden, dass vielmehr die Denkweise von Ingenieuren das Organisationsmodell der Software entscheidend prägte. Die SAP-Systemingenieure griffen bei der Entwicklung ihrer Anwendungsprogramme auf Sozialmetaphern und Alltagsvorstellungen des Sozialen zurück, um Probleme auf dem Gebiet der Technik zu lösen. Sie stützten sich beispielsweise bei der Umstellung von einer zentralistischen auf eine verteilte Rechner- und Softwarearchitektur auf die Idee des Netzwerks, die im universitären Kontext entwickelt worden war. Die Internationalisierung der Software, die durch die Verwendung des Zeichensatzes Unicode in den Programmen der Software begünstigt wurde, folgte einem bestimmten Globalisierungsmuster. Es waren existierende Beziehungen der SAP-Gründer mit Unternehmen, die die Softwareentwicklung stark beeinflussten. Es konnte gezeigt werden, dass das Organisationsmodell der Software und seine Entstehungsgeschichte eng mit der Softwareverbreitung verzahnt sind. Um die Softwareverbreitung in den 1990er Jahren aus einer organisationssoziologischen Perspektive zu erklären, wurden inter-organisationale Beziehungen in den Fokus der Untersuchung gerückt. Es konnten drei verschiedene Beziehungstypen identifiziert werden: Abhängigkeitsbeziehungen, Netzwerkbeziehungen und Beobachtungs- bzw. Vergleichsbeziehungen. Das Referenzmarketing von SAP wurde in diesem Zusammenhang als ein Beispiel dafür angeführt, wie der Softwarehersteller Beziehungen zwischen Organisationen konstruiert und aktiv zur Konstitution eines Organisationsfeldes beiträgt. Die Software basiert auf abstrakten Beschreibungen verschiedener Organisationen, die Gemeinsamkeiten zwischen Organisationseinheiten und zwischen verschiedenen Organisationen hervorheben. Das Organisationsmodell von SAP wurde als eine erfolgreiche Theoretisierung („theorization“, Strang & Meyer 1994) interpretiert. Das der betriebswirtschaftlichen Standardsoftware zugrundeliegende Modell der Prozessorganisation entspricht nicht nur formalen Selbstbeschreibungen von Unternehmen. Organisationen im Gesundheitswesen und in der öffentlichen Verwaltung sowie Hochschul- und Forschungseinrichtungen

232 | D AS P ROJEKT SAP

scheinen ebenfalls diese Organisationsbeschreibung zu übernehmen.5 Der Kunde wird dabei zur zentralen Autorität des Organisationsgeschehens gemacht. In den Beschreibungen von Softwarenutzern und Softwarenutzerinnen tauchte die Idee der Kundenorientierung als ein wiederkehrendes zentrales Motiv auf. Inwiefern diese und andere Leitsätze populärer Managementliteratur im Organisationsmodell betriebswirtschaftlicher Software fixiert sind, konnte am Beispiel von SAP gezeigt werden. Die Diskrepanz des Organisationsmodells der Software mit der alltäglichen Praxis von Organisationen wurde von Beratern und Techniknutzern in ihren Beschreibungen der Softwareimplementierung und Softwareverwendung zum Ausdruck gebracht. Auf der Grundlage empirischen Datenmaterials wurde die zweite Leitfrage beantwortet: Wie integriert eine Organisation die Technik? Die Organisation selbst entscheidet darüber, ob und inwiefern betriebswirtschaftlichen Anwendungsprogramme der Software zu Entscheidungsprogrammen der Organisation werden. Entscheidungen über die Individualisierung der Software wurden als outputs der Beratungsinteraktion analysiert; Entscheidungen über die Teilnehmer und die Laufzeit des Projektes sowie über die Projektthemen und methoden wurden hingegen als inputs für die Softwareberatung interpretiert. Obgleich das Customizing der Standardsoftware seinem Anspruch nach als kundenorientierte Dienstleistung beschrieben wurde, zeigte sich in der Kommunikation zwischen Softwareberatern und Organisationsmitgliedern, dass in der Interaktion vor allem Informationen mitgeteilt wurden, die primär den formallogischen Ansprüchen des Softwareexperten gerecht wurden. Softwareberater haben es mit vagen und wechselnden Anforderungen der Kundenorganisation zu tun. Sie arbeiten deshalb primär mit Unterstellungen und technikinduzierten Zuschreibungen als mit konkreten Anforderungen und Erwartungen auf der Organisationsseite. In einigen beschriebenen Fällen stellte sich heraus, das Softwareberater versuchten, die Projektzeit zu verknappen und Projektphasen zu streichen, um mit sachlichen und sozialen Komplexitäten der Softwareimplementierung umzugehen. Die zeitliche Befristung des Softwareprojekts wurde mitunter dazu genutzt, um Selektionsmöglichkeiten für die beratene Organisation bei der An-

5

Der Softwarehersteller listet auf seiner Internetseite insgesamt 28 verschiedene Branchen auf, in denen die Standardsoftware verwendet wird. Quelle: http://www.sap.com/ germany/solution.html; Stand: 26.06.2015

S CHLUSS

| 233

passung der Standardsoftware an die Organisation einzuschränken. Nicht selten wurde die Beratung einer Organisation als Betreuung oder Belehrung umgedeutet. Die Einführung einer Standardsoftware wie SAP in Organisationen steht für den Versuch, Kommunikation stärker zu formalisieren. Durch die softwaregestützte Verarbeitung von Daten in Organisationen sollen Unsicherheiten reduziert und Komplexität auf entscheidungsfähige Problemgrößen reduziert werden. Es konnte gezeigt werden, dass die organisationsweite Einführung von Standardsoftware ein lang andauernder Prozess ist, der keinen Endpunkt hat. Es wurde beispielhaft gezeigt, dass einzelne Module der Standardsoftware mitunter so modifiziert wurden, dass ihre Verknüpfung zu einem integrierten System der Datenverarbeitung technisch gar nicht mehr möglich war. In Organisationen, so eines der zentralen Untersuchungsergebnisse zur Integration der Technik, wird auch weiterhin mit lokalen, spezialisierten und unvollständigen Datensammlungen gearbeitet. Auch innerhalb von Organisationen bleibt die informationstechnische Vernetzung besonders voraussetzungsvoll. Trotzdem funktionieren Organisationen oft besser als es die Diskrepanz der Organisationswirklichkeit und ihrer formalen Modelle wie SAP vermuten ließen. Den wesentlichen Beitrag dazu leistet Informalität, die widersprüchliche Anforderungen in der Organisationswirklichkeit abfedert und Unvollkommenheiten eines informationstechnisch komplexen Regelwerks ausgleicht. Informalität zeichnet nicht nur den Großteil der Interaktion zwischen den Mitgliedern einer Organisation aus. Informalität kennzeichnet auch den Umgang mit der Software im Organisationsalltag. Jede Organisation ist auf kompensatorische Leistungen ihrer Mitglieder angewiesen. Darin liegt kein Mangel an Perfektion der Organisation und ihrer Formalisierungswerkzeuge wie SAP. Eine vollständige Formalisierung würde das Ende jeder funktionierenden Organisation bedeuten. Das wusste auch Simon, der sich für das Urteilsvermögen, die Intuition und die Kreativität von Individuen interessierte. Die Begriffe Standard und Standardisierung werden oft synonym verwendet, obwohl sie zwei unterschiedliche Assoziationen wecken. Während Standards Vergleichbarkeit und Transparenz versprechen und als erstrebenswert gelten, ist der Begriff Standardisierung eher negativ konnotiert. Mit ihm verbindet man Bilder der Eintönigkeit und Unterdrückung von Individualität. In A World of Standards but not a Standard World diskutieren Stefan Timmermans und Stephen Epstein (2010) das breite Spektrum sozialwissenschaftlicher Forschung zum Thema Standards. Sie listen eine Reihe von Antonymen für Standardisierung auf: Flexibilität, Entscheidungsfreiheit, Interpretation, Vielfalt, Individualismus, Einzigartigkeit, Willkür, Anomie oder Chaos. Im Zuge der Einführung

234 | D AS P ROJEKT SAP

der Standardsoftware in Organisationen, so konnte in diesem Buch gezeigt werden, kommt es zu einer wechselseitigen Anpassung von Organisation und Technik. Die Individualisierung erwies sich als ein zentraler Aspekt bei der Standardisierung von Organisationen mittels Software. Sie ist für das Funktionieren der Technik in der Organisation überhaupt verantwortlich. Standardisierung und Individualisierung sind in diesem Sinne keine widersprechenden Begriffe, sondern ergeben ein komplementäres Begriffspaar für das Projekt SAP.

Literatur

Abts, Dietmar; Mülder, Wilhelm (2010): Wirtschaftsinformatik. 7. Auflage. Wiesbaden: Vieweg & Teubner. Aldrich, Howard (1979): Organizations and Environments. Englewood Cliffs. N.J: Prentice-Hall. Alves, Carina; Finkelstein, Anthony (2003): Investigating Conflicts in COTS Decisionmaking. In: International Journal of Software Engineering and Knowledge Engineering 13 (5). 473–495. Anderson, Deborah (2005): Global Linguistic Diversity for the Internet. In: Communications of the ACM 48 (1). 17–18. Aschenbrenner, Michael (2010): Informationsverarbeitung – Überblick. In: Aschenbrenner, Michael; Dicke, Ralph; Kamarski, Bertel; Schweigert, Franz (Hg.): Informationsverarbeitung in Versicherungsunternehmen. Berlin, Heidelberg: Springer. 15–25. Astrahan, Morton M.; Chamberlin, Donald D. (1975): Implementation of a Structured English Query Language. In: Communications of the ACM 18. 580–588. Augier, Mie; March, James G. (2004): Herbert A. Simon, Scientist. In: Augier, Mie; March, James G. (Hg.): Models of a Man. Essays in Memory of Herbert A. Simon. Cambridge, Mass.: MIT Press. 3-32. Bachman, Charles W. (1973): The Programmer as Navigator. 1973 Turing Award Lecture. 269–285. URL: http://awards.acm.org/images/140/articles/ 1896680.pdf. Stand: 18.12.2011. Bachman, Charles W. (1974): The Data-Structure-Set Model. In: Rustin, Randall (Hg.): Proceedings of 1974 ACM-SIGMOD Workshop on Data Description, Access and Control. 2 Bände. Ann Arbor, Michigan. 1–10. Barley, Stephen. R. (1986): Technology as an Occasion for Structuring: Evidence from Observations of CT Scanners and the Social Order of Radiology Departments. Administrative Science Quarterly 31. 78-108.

236 | D AS P ROJEKT SAP

Bartlett, Christopher A.; Ghoshal, Sumantra (1989): Managing across Borders. The Transnational Solution. Boston, Mass.: Harvard Business School Press. Becker, Joseph D. (1988): Unicode 88. Commemorating Years of the Unicode Standard 1988 to 1998. Xerox Corporation. Palo Alto. URL: http://www.unicode.org/history/unicode88.pdf. Stand: 24.06.2015. Belliger, Andrea; Krieger, David J. (Hg.) (2006): ANThology. Ein einführendes Handbuch zur Akteurs-Netzwerk-Theorie. Bielefeld: Transkript. Bijker, Wiebe E.; Hughes, Thomas P.; Pinch, Trevor J. (Hg.) (1987): The Social Construction of Technological Systems: New Directions in the Sociology and History Technology. Cambridge, Mass.: MIT Press. Bloomfield, Brian P; Best, Ardha (1992): Management Consultants, Systems Development, Power and the Translation of Problems. In: Sociological Review 40. 533–560. Bloor, David (1976): Knowledge and Social Imagery. London: Routledge & Kegan Paul. Blumer, Herbert (1954): What is Wrong with Social Theory? In: American Sociological Review 19 (1). 3-10. Boeker, Warren (1997): Executive Migration and Strategic Change: The Effect of Top Manager Movement on Product Entry. In: Administrative Science Quarterly 42. 213–236. Bogner, Alexander; Menz, Wolfgang (2005): Das theoriegenerierende Experteninterview. Erkenntnis, Wissensformen, Interaktion. In: Bogner, Alexander; Littig, Beate; Menz, Wolfgang (Hg.): Das Experteninterview: Theorie, Methode, Anwendung. Wiesbaden: VS-Verlag. 33–70. Borch, Christian; Stäheli, Urs (2009): Einleitung – Tardes Soziologie der Nachahmung und des Begehrens. Materialien zu Gabriel Tarde. In: Borch, Christian; Stäheli, Urs (Hg.): Soziologie der Nachahmung und des Begehrens. Materialien zu Gabriel Tarde. Frankfurt am Main: Suhrkamp. 7–38. Bowker, Geoffrey C.; Star, Susan Leigh (2000): Sorting Things Out. Classification and its Consequences. Cambridge, Mass.: MIT Press. Boxenbaum, Eva; Jonsson, Stefan (2008): Isomorphism, Diffusion and Decoupling. In: Greenwood, Royston; Oliver, Christine; Sahlin, Kerstin; Suddaby, Roy (Hg.): The SAGE Handbook of Organizational Institutionalism. Los Angeles, London: SAGE. 79–98. Braverman, Harry (1974): Labor and Monopoly Capital: The Degradation of Work in the Twentieth Century. New York: Monthly Review Press. Briers, Michael; Chua, Wai Fong (2001): The Role of Actor-Networks and Boundary Objects in Management Accounting Change: A Field Study of an

L ITERATUR

| 237

Implementation of Activity-Based Costing. Accounting, Organizations and Society 26 (3). 237–269. Brooks, Frederick Phillips (2011): The Mythical Man-month. Essays on Software Engineering. 37. Auflage. Boston, Mass.: Addison-Wesley. (Orig. 1975) Brunner, Franz J. (2011): Japanische Erfolgskonzepte: KAIZEN, KVP, Lean Production Management, Total Productive Maintenance Shopfloor Management, Toyota Production Management, GD³ - Lean Development. München: Hanser. Brunsson, Nils; Jacobsson, Bengt (Hg.) (2000): A World of Standards. Oxford: Oxford University Press. Brunsson, Nils; Rasche, Andreas; Seidl, David (2012): The Dynamics of Standardization: Three Perspectives on Standards in Organization Studies. In: Organization Studies 33. 613–632. Brunsson, Nils; Sahlin-Andersson, Kerstin (2000): Constructing Organizations. The Example of Public Sector Reform. In: Organization Studies 21. 721-746. Bunz, Mercedes (2009): Vom Speicher zum Verteiler. Die Geschichte des Internet. Berlin: Kultur-Verl. Kadmos. Burt, Ronald S. (1992): Structural Holes: The Social Structure of Competition. Cambridge, Mass.: Harvard University Press. Caldwell, Bruce (1996): Trends In Big Six Consulting. Split Personality. In: CMP The Technology Source. April 22. Callon, Michel; Latour, Bruno (1992): Don't Throw the Baby Out with the Bath School! A Reply to Collins and Yearley. In: Pickering, Andrew (Hg.): Science as Practice and Culture. Chicago: Chicago University Press. 343–368. Campbell-Kelly, Martin (2003): From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry. Cambridge, Mass.: The MIT Press. Campbell-Kelly, Martin (2012): The Rdbms Industry. A Northern California Perspective. In: IEEE Annals of the History of Computing 34 (4). 18–29. Carlson, Sune (1978): The Prize in Economics 1978. Presentation Speech. URL: http//www.nobelprize.or/nobel_prizes/economics/laureates/1978/presentionspeech.html. Stand: 15.05.2013. Ceruzzi, Paul E. (2012): Computing. A Concise History. Cambridge, Mass.: MIT Press. Chamberlin, Donald D. (2012): Early History of SQL. In: IEEE Annals of the History of Computing 34 (4). 78–82. Chamberlin, Donald D.; Astrahan, Morton M.; Blasgen, Michael W.; Gray, James N.; King, W. Frank; Lindsay, Bruce G., Lorie, Raymond; Mehl, James W.; Price, Thomas G., Putzolu, Franco; Griffiths Selinger, Patricia; Schkol-

238 | D AS P ROJEKT SAP

nick, Mario; Slutz, Donald R.; Traiger, Irving L.; Wade, Bradford W.; Yost, Robert A. (1981): A History and Evaluation of System R. In: Communications of the ACM 24. 633–646. Chandler, Alfred D. (1977): The Visible Hand: The Managerial Revolution in American Business. Cambridge, Mass.: Harvard University Press. Chandler, Alfred D. (1984): The Emergence of Managerial Capitalism. In: The Business History Review. 58. 4. 473–503. Ciborra, Claudio U. et al. (Hg.) (2001): From Control to Drift: The Dynamics of Corporate Information Infrastructures. Oxford: Oxford University Press. Codd, Edgar F. (1970): A Relational Model of Data for Large Shared Data Banks. In: Communications of the ACM 13. 377–387. Codd, Edgar F. (1981): Relational Database: A Practical Foundation for Productivity. In: Communications of the ACM 25 (2). 109–117. Codd, Edgar F.; Date, Chris J. (1974): Interactive Support For NonProgrammers: The Relational and Network Approaches. In: Rustin, Randall (Hg.): Proceedings of 1974 ACM-SIGMOD Workshop on Data Description, Access and Control. 2 Bände. Ann Arbor, Michigan. 11–41. Coenenberg, Adolf G.; Haller, Axel; Matter, Gerhard; Schulze, Wolfgang (2012): Einführung in das Rechnungswesen. Grundzüge der Buchführung und Bilanzierung. Stuttgart: Schäffer-Poeschel Verlag. Crozier, Michel; Friedberg, Erhard (1979): Macht und Organisation. Die Zwänge kollektiven Handelns. Königstein: Athenäum Verlag. Cyert, Richard M.; March, James G. (1992): A Behavioral Theory of the Firm. 2. Auflage. Cambridge, Mass.: Blackwell Business. (Org. 1963) Czarniawska, Barbara (2009): Gabriel Tarde und die Verwaltung von Grossstädten. In: Borch, Christian; Stäheli, Urs (Hg.): Soziologie der Nachahmung und des Begehrens. Materialien zu Gabriel Tarde. Frankfurt am Main: Suhrkamp. 372–396. D’Adderio, Luciana (2004): Inside the Virtual Product: How Organizations Create Knowledge through Software. Cheltenham: Edward Elgar Pub. Darwen, Hugh (2012): The Relational Model. Beginning of an Era. In: IEEE Annals of the History of Computing 34 (4). 30–37. Davis, Gerald (1991): Agents Without Principles? The Spread of the Poison Pill Through the Intercorporate Network. In: Administrative Science Quarterly 36. 583–613. Davis, L. E. and J. C. Taylor (1986): Technology, Organization and Job Structure. In: Dubin, R. (Hg.): Handbook of Work, Organization, and Society. Chicago, IL: Rand McNally. 379–419.

L ITERATUR

| 239

Deppermann, Arnulf (1999): Gespräche analysieren. Ein praktischer Leitfaden für Sozialwissenschaftler. Opladen: Westdeutscher Verlag. Diekmann, Thomas; Hagenhoff, Svenja (2003): Verteilte Systeme: State of the Art. In: Institut für Wirtschaftsinformatik Arbeitsberichte 1. Georg-AugustUniversität Göttingen. Göttingen. Dierkes, Julian; Zorn, Dirk (2005): Soziologischer Neoinstitutionalismus. In: Kaesler, Dirk (Hg.): Aktuelle Theorien der Soziologie. München: C.H. Beck. 313–331. DiMaggio, Paul (1995): Comments on What Theory is Not. In: Administrative Science Quarterly 40. 391–397. DiMaggio, Paul; Powell, Walter W. (1983): The Iron Cage Revisited. Institutional Isomorphism and Collective Rationality. In: American Sociological Review 48. 147–160. DiMaggio, Paul (1991): Constructing an Organizational Field as a Professional Project: U.S. Art Museums, 1920-1940. In: DiMaggio, Paul; Powell, Walter W. (Hg.): The New Institutionalism in Organizational Analysis. Chicago: University of Chicago Press. 267–292. Dobbin, Frank; Sutton, John R. (1998): The Strenght of a Weak State. The Rights Revolution and the Rise of Human Resources Management Divisions. In: American Journal of Sociology 104. 441–476. Drepper, Thomas (2003): Organisationen der Gesellschaft. Wiesbaden: Westdeutscher Verlag. Durkheim, Émile (1984): Die Regeln der soziologischen Methode. Herausgegeben und eingeleitet von Rene König. Frankfurt am Main: Suhrkamp. (Orig. 1895). Edelman, Lauren (1992): Legal Ambiguity and Symbolic Structures. Organizational Mediation of Civil Rights Law. In: American Journal of Sociology 97. 1531–1576. Edge, David (1988): The Social Shaping of Technology. Edinburgh PICT Working Paper. No. 1. Edinburgh University. Edwards, Paul N. (1998): Y2K: Millennial Reflections on Computers as Infrastructure. In: History & Technology 15. 7–29. Edwards, R. (1979): Contested Terrain: The Transformation of the Workplace in the Twentieth Century. New York: Basic Books. Ensmenger, Nathan (2010): The Computer Boys Take Over. Computers, Programmers, and the Politics of Technical Expertise. Cambridge, Mass.: MIT Press. Ericsson, Karl A.; Simon, Herbert A. (1980): Verbal Reports as Data. In: Psychological Review 87. 215–251.

240 | D AS P ROJEKT SAP

Esders, Michael (2012): Echtzeit. Zur Konjunktur eines Begriffs. In: Merkur. Deutsche Zeitschrift für europäisches Denken 66 (755). 351–356. Fleck, James; Webster, Juliet; Williams, Robin (1990): The Dynamics of IT Implementation: A Reassessment of Paradigms and Trajectories of Development. In: Futures 22. 618–664. Floyd, Christiane; Keil, Reinhard (1984): Integrative Systementwicklung: Ein Ansatz zur Orientierung der Softwaretechnik auf die benutzergerechte Entwicklung rechnergestützter Systeme. Karlsruhe. Funken, Christiane (2001): Die Modellierung der Welt. Wissenssoziologische Studien zur Software-Entwicklung. Opladen: Leske + Budrich. Geyer, Christian (2013): Niklas Luhmann. Die Knappheit der Zeit und die Vordringlichkeit des Befristeten. Berlin: Kulturverlag Kadmos. Giddens, Anthony (1984): The Constitution of Society: Outline of the Theory of Structuration. Cambridge: Polity. Glaser, Barney G.; Strauss, Anselm L. (1998) : Grounded Theory. Strategien qualitativer Forschung. Göttingen: H. Huber. (Orig. 1967). Glückler, Johannes; Armbrüster, Thomas (2003): Bridging Uncertainty in Management Consulting. The Mechanisms of Trust and Networked Reputation. In: Organization Studies 24 (2). 269–297. Goffman, Erving (1969): Wir alle spielen Theater. Die Selbstdarstellung im Alltag. München: Piper. Goll, Michaela (2008): Arbeitsbeziehungen und Beziehungsarbeit: Zur Gestaltung arbeitsbezogener und informeller Nachrichten in Unternehmen. In: Schulz-Schaeffer, I./Funken, C. (Hg.): Digitalisierung der Arbeitswelt. Wiesbaden. 143–164. Granovetter, Mark S. (1973): The Strenghts of Weak Ties. In: American Journal of Sociology 78. 1360–1380. Greenwood, Royston; Oliver, Christine; Sahlin, Kerstin; Suddaby, Roy (Hg.) (2008): The SAGE Handbook of Organizational Institutionalism. Los Angeles, London: SAGE. Grimm, Christiane (2009): Inside a Secret Software Laboratory. An Ethnographic Study of a Global Software Package Producer. Gabler Verlag: Wiesbaden. Gugerli, David (2007): Die Welt als Datenbank. Zur Relation von Softwareentwicklung, Abfragetechnik und Deutungsautonomie. In: Gugerli, David; Hagner, Michael; Hampe, Michael; Orland, Barbara; Sarasin, Philipp; Tanner, Jakob (Hg.): Daten. Berlin: Diaphanes. 11–36. Gugerli, David (2009): Suchmaschinen. Die Welt als Datenbank. Frankfurt am Main: Suhrkamp.

L ITERATUR

| 241

Gulick, Luther; Urwick, Lyndall (1937): Papers on Science of Administration. Institute of Public Administration: Columbia University. Hadeler, Thorsten; Winter, Eggert; Arentzen, Ute (Hg.) (2001): Gabler Wirtschaftslexikon. Betriebswirtschaftlicher Verlag Dr. Th. Gabler Gmbh: Wiesbaden. Haigh, Thomas (2007): A Veritable Bucket of Facts. Ursprünge des Datenbankmanagementsystems. In: Gugerli, David; Hagner, Michael; Hampe, Michael; Orland, Barbara; Sarasin, Philipp; Tanner, Jakob (Hg.): Daten. Berlin: Diaphanes. 57–98. Hammer, Michael; Champy, James (1993): Re-engineering the Corporation. A Manifesto for Business Revolution. London: Brealey Pub. Hammer, Michael (2004): The Process Revolution and ERP. In: SAP AG (Hg.): Real Time. A Tribute to Hasso Plattner. Indianapolis: Wiley Pub. 81–92. Hannan, Michael T.; Freeman, John H. (1977): The Population Ecology of Organizations. In: American Journal of Sociology 82. 929–964. Hanseth, Ole; Aanestad, Margunn (2004): Guest Editors' Introduction: Actornetwork Theory and Information Systems: What’s so Special? In: Information Technology & People 17 (2). 116–123. Hasse, Raimund; Krücken, Georg (2005): Neo-Institutionalismus. 2. Auflage. Bielefeld: Transcript. Hauptmann, Stefan (2011): Social Media in Organisationen. Strukturation und Computervermittelte Kommunikation. Springer Gabler. Hebeisen, Walter (1999): F.W. Taylor und der Taylorismus. Über das Wirken und die Lehre Taylors und die Kritik am Taylorismus. Zürich: vdf, Hochschulverlag an der ETH Zürich. Heintel, Peter; Krainz, Ewald E. (2001): Projektmanagement. Eine Antwort auf die Hierarchiekrise? Wiesbaden: Gabler. Heintz, Bettina (1993): Die Herrschaft der Regel. Frankfurt am Main: Campus Verlag. Heintz, Bettina (1995): Die Gesellschaft in der Machine. Überlegungen zum Verhältnis von Informatik und Soziologie. In: Kreowski, Hans-Jörg u.a. (Hg.): Realität und Utopien der Informatik. Münster: Agenda. 12-31. Heintz, Bettina (2008): Governance by Numbers. Zum Zusammenhang von Quantifizierung und Globalisierung am Beispiel der Hochschulpolitik. In: Folke Schuppert, Gunnar; Voßkuhl, Andreas (Hg.): Governance von und durch Wissen. Baden-Baden: Nomos. 110–128. Heintz, Bettina (2010): Numerische Differenz. Überlegungen zu einer Soziologie des (quantitativen) Vergleichs. In: Zeitschrift für Soziologie 39 (3). 162– 181.

242 | D AS P ROJEKT SAP

Helfferich, Cornelia (2005): Die Qualität qualitativer Daten. Manual zur Durchführung qualitativer Einzelinterviews. Wiesbaden: VS-Verlag. Hill, Mark D. (1990): What is Scalability? In: ACM SIGARCH Computer Architecture News. 18 (4). 18–21. Hoffman, Andrew J. (1999): Institutional Evolution and Change. Environmentalism and the U.S. Chemical Industry. In: Academy of Management Journal 42. 351–371. Hoffman, Andrew J.; Ocasio, William (2001): Not All Events are Attended Equally: Toward a Middle-Range Theory of Industry Attention to External Events. In: Organization Science 12. 414–434. Hoffmann-Riem, Christel (1980): Die Sozialforschung einer interpretativen Soziologie. In: Kölner Zeitschrift für Soziologie und Sozialpsychologie 32. 339–372. Hohlmann, Brita (2007): Organisation SAP – soziale Auswirkungen technischer Systeme. Aachen: Shaker. Horváth, Péter; Petsch, Manfred; Weihe, Michael (1986): StandardAnwendungssoftware für das Rechnungswesen. 2. Auflage. München: Vahlen. Hyman, Herbert H. (1942): The Psychology of Status. In: Archives of Psychology 269. 5–91. Ives, Black; Jarvenpaa, Sirkka, L. (1991): Applications of Global Information Technology: Key Issues for Management. Management Information Systems Quarterly 15. 33-49. Joas, Hans; Knöbl, Wolfgang (2004): Sozialtheorie: zwanzig einführende Vorlesungen. Frankfurt am Main: Suhrkamp. Joerges, Bernward (1989): Technische Normen – Soziale Normen? In: Soziale Welt 40 (1/2). 242–258. Joerges, Bernward (1999): Die Brücken des Robert Moses. Stille Post in der Stadt- und Techniksoziologie. In: Leviathan 1. 43–63. Joerges, Bernward; Shinn, Terry (2001): Instrumentation. Between Science, State, and Industry. Dordrecht, Boston: Kluwer Academic Publishers. Jones, M. R.; Karsten, H. (2008): Giddens’s Structuration Theory and Information Systems Research. In: MIS Quarterly 32 (1). 127–157. Keller, Gerhard; Nüttgens, Markus; Scheer, August-Wilhelm (1992): Semantische Prozessmodellierung auf der Grundlage Ereignisgesteuerter Prozessketten (EPK). Universität des Saarlandes. Saarbrücken. Veröffentlichungen des Instituts für Wirtschaftsinformatik (IWi).

L ITERATUR

| 243

Kelly, Erin; Dobbin, Frank (1999): Civil Rights Law at Work. Sex Discrimination and the Rise of Maternity Leave Policies. In: American Journal of Sociology 105. 455–492. Kette, Sven (2012): Das Unternehmen als Organisation. Typische Strukturen und Probleme. In: Apelt, Maja; Tacke, Veronika (Hg.): Handbuch Organisationstypen. Wiesbaden: VS Verlag. 21–42. Kette, Sven; Mormann, Hannah (2015): Cyert, Richard M.; March, James G. (1963): A Behavorial Theory of the Firm. Englewood Cliffs: Prentice-Hall. In: Kühl, Stefan (Hg.): Schlüsselwerke der Organisationsforschung. Wiesbaden: Springer VS. 210-214 Kieser, Alfred (2014): Managementlehren – von Regeln guter Praxis über den Taylorismus zur Human Relations-Bewegung. In: Kieser, Alfred; Eber, Mark (Hg.): Organisationstheorien. 7. aktualisierte und überarbeitete Auflage. Stuttgart: Kohlhammer. 73–117. Kieserling, André (1994): Interaktion in Organisationen. In: Dammann, Klaus; Grunow, Dieter; Japp, Klaus P. (Hg.): Die Verwaltung des politischen Systems: Neuere systemtheoretische Zugriffe auf ein altes Thema. Opladen: Westdeutscher Verlag. 168–183. Kieserling, André (1999): Kommunikation unter Anwesenden. Studien über Interaktionssysteme. Frankfurt am Main: Suhrkamp. Knorr Cetina, Karin (1984): Die Fabrikation von Erkenntnis. Zur Anthropologie der Naturwissenschaft. Frankfurt am Main: Suhrkamp. Koch, Christoph (2000): The Ventriloquist’s Dummy? The Role of Technology in Political Process. In: Technology Analysis and Strategic Management 12 (1). 119–138. Kruse, Jan (2008): Reader Einführung in die Qualitative Interviewforschung. Freiburg. Kühl (2008): Dyaden, Gruppen und Teams: Die Rahmungen von Coachings und Supervisionen. In: Gruppendynamik & Organisationsberatung 39 (4). 477– 498. Kühl, Stefan (2011): Organisationen. Eine sehr kurze Einführung. Wiesbaden: VS Verlag für Sozialwissenschaften. Kumar, Vinod; Maheshwari, Bharat; Kumar, Uma (2003): An Investigation of Critical Management Issues in ERP Implementation: Empirical Evidence from Canadian Organizations. In: Technovation 23. 793–807. Lassmann, Wolfgang (2006): Wirtschaftsinformatik. Nachschlagewerk für Studium und Praxis. Wiesbaden: Gabler. Latour, Bruno (1987): Science in Action: How to Follow Scientists and Engineers through Society. Cambridge, Mass.: Harvard University Press.

244 | D AS P ROJEKT SAP

Latour, Bruno (1999): Pandora's Hope. Essays on the Reality of Science Studies. Cambridge, Mass.: Harvard University Press. Latour, Bruno; Woolgar, Steve (1979): Laboratory Life: The Social Construction of Scientific Facts. Princeton: Princeton University Press. Laumann, Edward O.; Galaskiewicz, Joseph; Marsden, Peter (1978): Community Structure as Interorganizational Linkage. In: Annual Review of Sociology 4. 455–484. Law, John; Singleton, Vicky (2000): Performing technology’s stories: On Social Constructivism, Performance, and Performativity. In: Technology and Culture 41 (4). 765–775. Leimbach, Timo (2007): Vom Programmierbüro zum globalen Softwareproduzenten. Die Erfolgsfaktoren der SAP von der Gründung bis zum R/3-Boom, 1972 bis 1996. In: Zeitschrift für Unternehmensgeschichte 52 (1). 33–56. Leimbach, Timo (2008): The SAP Story. Evolution of SAP within the German Software Industry. In: IEE Annals of the History of Computing. 60–76. Leimbach, Timo (2010): Die Geschichte der Softwarebranche in Deutschland. Entwicklung und Anwendung von Informations- und Kommunikationstechnologie zwischen den 1950ern und heute. Dissertation. München: Universitätsbibliothek München. Lenz, Karl; Nestmann, Frank (2009): Persönliche Beziehungen. Eine Einleitung. In: Lenz, Karl; Nestmann, Frank (Hg.): Handbuch Persönliche Beziehungen. Weinheim, München: Juventa. 9–28. Liedloff, Thilo; Bromberger, Heiko (2009): Informationen für morgen aus Systemen von gestern? Der IBM Mainframe im Mittelpunkt zentraler Datenhaltung im Jahr 2020. In: Keuper, Frank (Hg.): Wissens- und Informationsmanagement. Strategien, Organisation und Prozesse. Wiesbaden: Gabler. 569– 596. Linde, Hans (1972): Sachdominanz in Sozialstrukturen. Tübingen: Mohr. Littig, Beate (2005): Interviews mit Experten und Expertinnen. Überlegungen aus geschlechtertheoretischer Sicht. In: Bogner, Alexander; Littig, Beate; Menz, Wolfgang (Hg.): Das Experteninterview: Theorie, Methode, Anwendung. Wiesbaden: VS Verlag. 191–206. Lucius-Hoene, Gabriele; Deppermann, Arnulf (2002): Rekonstruktion narrativer Identität. Ein Arbeitsbuch zur Analyse narrativer Identität. Opladen: Leske und Budrich. Lucking, John R. (1974): Comments on Advantages of the Data-Structure-Set Model. In: Rustin, Randall (Hg.): Proceedings of 1974 ACM-SIGMOD Workshop on Data Description, Access and Control. 2 Bände. Ann Arbor, Michigan. 115–119.

L ITERATUR

| 245

Luckmann, Thomas (1986): Grundformen der gesellschaftlichen Vermittlung des Wissens. Kommunikative Gattungen. In: Kölner Zeitschrift für Soziologie und Sozialpsychologie. Sonderheft 27. 191–211. Luhmann, Niklas (1964a): Funktionen und Folgen formaler Organisation. Berlin: Duncker & Humblot. Luhmann, Niklas (1964b): Funktionale Methode und Systemtheorie. In: Soziale Welt 15. 1–25. Luhmann, Niklas (1967): Soziologie als Theorie sozialer Systeme. In: Kölner Zeitschrift für Soziologie und Sozialpsychologie 19. 615–644. Luhmann, Niklas (1971): Die Knappheit der Zeit und die Vordringlichkeit des Befristeten. In: Luhmann, Niklas: Politische Planung. Aufsätze zur Soziologie von Politik und Verwaltung. Opladen: Westdeutscher Verlag. 143–164. Luhmann, Niklas (1972): Überlegungen zum Verhältnis von Gesellschaftssystemen und Organisationssystemen. In: Bund Deutscher Werbeberater (Hg.): Kommunikation und Gesellschaft. Möglichkeiten und Grenzen von Kommunikation und Marketing in einer sich wandelnden Gesellschaft. Karlsruhe: Verlag Nadolski. 144–149. Luhmann, Niklas (1977): Zweckbegriff und Systemrationalität. Über die Funktion von Zwecken in sozialen Systemen. 2. Auflage. Frankfurt am Main: Suhrkamp. Luhmann, Niklas (1984): Soziale Systeme. Grundriß einer allgemeinen Theorie. Frankfurt am Main: Suhrkamp. Luhmann, Niklas (1988): Wie ist Bewußtsein an Kommunikation beteiligt? In: Gumbrecht, H. U.; Pfeiffer, K. L. (Hg.): Materialität der Kommunikation. Frankfurt am Main. 884–905. Luhmann, Niklas (1993): Die Paradoxie des Entscheidens. In: VerwaltungsArchiv 84 (3). 287–310. Luhmann, Niklas (1998): Die Gesellschaft der Gesellschaft. Erster Teilband. Frankfurt am Main: Suhrkamp. Luhmann, Niklas (2000): Organisation und Entscheidung. Opladen: Westdeutscher Verlag. Luhmann, Niklas (2005a): Funktionale Methode und Systemtheorie. In: Soziologische Aufklärung 1. Aufsätze zur Theorie sozialer Systeme. 7. Auflage. Wiesbaden: VS Verlag. 39–67. Luhmann, Niklas (2005b): Soziologische Aufklärung. In: Soziologische Aufklärung 1. Aufsätze zur Theorie sozialer Systeme. 7. Auflage. Wiesbaden: VS Verlag. 83-115.

246 | D AS P ROJEKT SAP

Luhmann, Niklas (2005c): Was ist Kommunikation? In: Soziologische Aufklärung 6. Die Soziologie und der Mensch. 2. Auflage. Wiesbaden: VS Verlag. 109-120. Luhmann, Niklas (2005d): Die Unwahrscheinlichkeit der Kommunikation. In: Niklas Luhmann (Hg.): Soziologische Aufklärung 3. Soziales System, Gesellschaft, Organisation. 4. Auflage. Wiesbaden: VS Verlag für Sozialwissenschaften. 29–40. Luhmann, Niklas (2005e): Interaktion, Organisation, Gesellschaft. In: Niklas Luhmann (Hg.): Soziologische Aufklärung 2. Aufsätze zur Theorie der Gesellschaft. 5. Auflage. Wiesbaden: VS Verlag für Sozialwissenschaften. 9-24. Luhmann, Niklas (2011): Einführung in die Systemtheorie. Herausgegeben von Dirk Baecker. 6. Auflage. Heidelberg: Carl-Auer-Verlag. MacKenzie, Donald A.; Wajcman, Judy (Hg.) (1985): The Social Shaping of Technology. Philadelphia: Open University Press. Mannheim, Karl (1985): Ideologie und Utopie. Frankfurt am Main: Klostermann. (Orig. 1929). March, James G.; Simon, Herbert A. (1958): Organizations. New York: Wiley. March, James G.; Olsen, Johan P. (1976): Ambiguity and Choice in Organizations. Bergen, Norway: Universitetsforlaget. March, James G. (1999): Organizational Consultants and Organizational Research. In: ders.: The Pursuit of Organizational Intelligence. Oxford: Blackwell Publisher. 325–337. March, James G. (2001): Wenn Organisationen wirklich intelligent werden wollen, müssen sie lernen, sich Torheiten zu leisten! In: Bardmann, Theodor M., Torsten Groth (Hg.) (2001): Zirkuläre Positionen 3. Organisation, Management und Beratung. Opladen: Westdeutscher Verlag. 21–33. Marienthal, Louis B. (1975): A Vicious Circle. In: Datamation 21 (11). 117. Marquard, Odo (1974): Inkompetenzkompensationskompetenz. In: Philosophisches Jahrbuch 81. 341–349. Martens, Wil; Ortmann, Günther (2014): Organisationen in Luhmanns Systemtheorie. In: Kieser, Alfred; Eber, Mark (Hg.): Organisationstheorien. 7. Auflage. Stuttgart: Kohlhammer. 407-440. Marx, Leo; Smith, Merritt Roe (1994): Introduction. In: Smith, Merritt Roe; Marx, Leo (Hg.): Does Technology Drive History. The Dilemma of Technological Determinism. Cambridge, Mass.: The MIT Press. ix-xv. Massie, John L. (1966): Management Theory. In: March, James (Hg.): Handbook of Organisations. Chicago: Rand McNally. 387–422.

L ITERATUR

| 247

McLaughlin, Janice, Rosen, Paul, Skinner, David; Webster, Andrew (1999): Valuing Technology – Organisations, Culture and Change. Routledge: London. Meier, Hermann; Hopp, Dietmar; Plattner, Hasso (1972): Auftragsabwicklung, Disposition und Versandsteuerung integriert im Realzeitbetrieb. IBMBeiträge zur Datenverarbeitung. Stuttgart: IBM-Deutschland. Meissner, Gerd (1997): SAP, die heimliche Software-Macht. Wie ein mittelständisches Unternehmen den Weltmarkt eroberte. Hamburg: Hoffmann und Campe (Reihe Standort). Mendel, Peter (2006): The Making and Expansion of International Management Standards. The Global Diffusion of ISO 9000 Quality Management Certificates. In: Drori, Gili S.; Meyer, John W.; Hwang, Hokyu (Hg.): Globalization and Organization. World Society and Organizational Change. Oxford, New York: Oxford University Press. 137–166. Mennicken, Andrea; Vollmer, Hendrik (2007) (Hg.): Zahlenwerk. Kalkulation, Organisation und Gesellschaft. Wiesbaden: VS Verlag für Sozialwissenschaften. Merton, Robert K. (1968): Social Theory and Social Structure. New York: Free Press. Meyer, John W. (1996): Otherhood. The Promulgation and Transmission of Ideas in the Modern Organizational Environment. In: Czarniawska-Joerges, Barbara; Sevón, Guje (Hg.): Translating Organizational Change. Berlin, New York: Walter de Gruyter. 241–252. Meyer, John W.; Rowan, Brian (1977): Institutionalized Organizations. Formal Structure as Myth and Ceremony. In: American Journal of Sociology 83 (2). 340–363. Miller, Peter (1994): Accounting as Social and Institutional Practice: An Introduction. In: Hopwood, Anthony G.; Miller, Peter (Hg.), Accounting as Social and Institutional Practice. Cambridge: Cambridge University Press. 1–39. Miller, Peter (1999): Governing the Enterprise: The Hidden Face of Accounting. In: Porter, Theodore M.; Ross, Dorothy (Hg.): The Cambridge History of Science 7. Cambridge: Cambridge University Press. Mizruchi, Mark S.; Fein, Lisa C. (1999): The Social Construction of Organizational Knowledge. A Study of the Uses of Coercive, Mimetic, and Normative Isomorphism. In: Administrative Science Quarterly (44). 653–683. Mooney, James D.; Reiley, Alan C. (1939): Principles of Organization. New York, London, Harper & Brothers.

248 | D AS P ROJEKT SAP

Mormann, Hannah (2006): Wissensorganisation und Projektarbeit in einem ITDienstleistungsunternehmen. Diplom-Arbeit. Fakultät für Soziologie. Universität Bielefeld. Mormann, Hannah; Willjes, Kristin (2013): Organisationsprojekt und Projektorganisation. Softwareeinführungsprojekte in der Hochschule aus organisationssoziologischer Perspektive. In: HIS: Forum Hochschule. 4/2013. 23–41. Mormann, Hannah (2015): Herbert A. Simon. The Proverbs of Administration. In: Kühl, Stefan (Hg.): Schlüsselwerke der Organisationsforschung. Wiesbaden: Springer VS. 640-643. Moscove, Stephen; Simkin, Mark; Bagranoff, Nancy (2003): Accounting and Enterprise Software Core Concepts of Accounting Information Systems. Hoboken, NJ: John Wiley and Sons. Müller, Heinrich (2001): Plaut, Hans-Georg. URL: http://www.deutschebiographie.de/pnd118988409.html. Stand: 03.04.2012. Mumford, E. (1981): Participative Systems Design: Structure and Method. Systems, Objectives, Solutions 1. 5–19. Murphy, Craig; Yates, JoAnne (2009): The International Organization for Standardization (ISO). Global Governance through Voluntary Consensus. London, New York: Routledge. Neugebauer, Klaus (1969): Um die Entbündelung der Computerpreise, in: Bürotechnik + Automation 8. 448-452. Newell, Allan; Simon, Herbert A. (1956): The Logic Theory Machine. In: IRE Transactions on Information Theory 3. 61–79. Newell, Allan; Simon, Herbert A. (1995): GPS, a Program that Simulates Human Thought. In: Feigenbaum, Edward; Feldman, Julian (Hg.): Computers and Thought. Menlo Park: AAAI Press. 279-296. (Org. 1961) Noak, Wilhelm (2009): SQL. Grundlagen der Datenverarbeitung. Hannover: Regionales Rechenzentrum Niedersachsen. Noble, David F. (1984): Forces of Production: A Social History of Industrial Automation. New York: Oxford University Press. Orlikowski, Wanda J. (1992): The Duality of Technology: Rethinking the Concept of Technology in Organizations. In: Organization Science 3 (3). 398– 427. Orlikowski, Wanda J.; Barley, Stephen (2001): Technology and Institutions: What can Research on Information Technology and Research on Organizations Learn from Each Other? In: MIS Quarterly 25 (2): 145–165. Orlikowski, Wanda J.; Scott, Susan V. (2008): Sociomateriality: Challenging the Separation of Technology, Work and Organization. In: The Academy of Management Annals 2 (1). 433–474.

L ITERATUR

| 249

Ortmann, Günther; Windeler, Arnold; Becker, Albrecht; Schulz, Hans-Joachim (1990): Computer und Macht in Organisationen. Mikropolitische Analysen. Wiesbaden: Springer Fachmedien Wiesbaden GmbH. Ottmann, Thomas; Widmayer, Peter (2011): Algorithmen und Datenstrukturen. 5. Auflage. Heidelberg, Berlin: Spektrum Akad. Verlag. Pargman, Daniel; Palme, Jacob (2009): ASCII Imperialism. In: Lampland, Martha; Star, Susan Leigh (Hg.): Standards and Their Stories. How Quantifying, Classifying, and Formalizing Practices Shape Everyday Life. Ithaca, NY: Cornell University Press. 177–199. Parsons, Talcott (1951): The Social System. London: Routledge and Kegan Paul. Pfaffenberger, Bryan (1992): Social Anthropology of Technology. In: Annual Review of Anthropology 21. 491–516. Pfeffer, Jeffrey; Salancik, Gerald R. (1978): The External Control of Organizations. A Resource Dependence Perspective. New York: Stanford Business Books. Pinch, Trevor J.; Bijker, Wiebe E. (1987): The Social Construction of Facts and Artifacts: Or How the Sociology of Technology Might Benefit of Each Other. In: Bijker, Wiebe E.; Hughes, Thomas P.; Pinch, Trevor J. (Hg.): The Social Construction of Technological Systems: New Directions in the Sociology and History Technology. Cambridge, Mass.: MIT Press. 17–50. Plattner, Hasso; Kagermann, Henning (1988): Einbettung eines Systems der Plankostenrechnung in ein EDV-Gesamtkonzept. In: Scheer, AugustWilhelm (Hg.): Grenzplankostenrechnung – Stand und aktuelle Probleme. Wiesbaden: Gabler Verlag. 137-178. Plattner, Hasso (1997): Der Knoten ist geplatzt. In: Der Spiegel 13 (1997). 109– 112. Plattner, Hasso; Morrow, Daniel; Scheer, August-Wilhelm; Wendt, Siegfried (2000): Dem Wandel voraus. Hasso Plattner im Gespräch. Galileo Press: Bonn. Pollock, Neil; Williams, Robin (2009): Software and Organisations. The Biography of the Enterprise-Wide System or How SAP Conquered the World. London, New York: Routledge. Pollock, Neil; Williams, Robin; D`Adderio, Luciana (2007): Global Software and its Provenance: Generification Work in the Production of Organizational Software Packages. In: Social Studies of Science 37 (2). 254–280. Poole, Marshall Scott; DeSanctis, Geraldine (2004): Structuration Theory in Information Systems Research. In: Whitman, M.E.; Woszczynski, A.B. (Hg.): The Handbook of Information Systems Research. London: Idea Group Publishing. 206–248.

250 | D AS P ROJEKT SAP

Prefi, Thomas (2007): Qualitätsmanagement in der Produktentwicklung. In: Pfeifer, Tilo; Schmitt, Robert (Hg.): Masing Handbuch Qualitätsmanagement. München: Hanser. 405-440. Prewo, Rainer; Ritsert, Jürgen; Stracke, Elmar (1973): Systemtheoretische Ansätze in der Soziologie. Eine kritische Analyse. Reinbek: VS Verlag für Sozialwissenschaften. Quattrone, Paulo; Hopper, Trevor (2005): A Time-Space Odyssey. Management Control Systems in Two Multinational Organisations. In: Accounting, Organizations and Society 30. 735–764. Quattrone, Paulo; Hopper, Trevor (2006): SAP, Accounting, and Visibility in a Multinational Organisation. In: Information and Organization 16. 212–250. Quintas, Paul (1994): A Product-process Model of Innovation in Software Development. Journal of Information Technology 9. 3–17. Rammert, Werner (1989): Techniksoziologie. In: Endruweit, Günter; Trommsdorf, Gisela (Hg.): Lexikon der Soziologie. Band 3: Sanktion – Zweistufenthese. Stuttgart. 724-735. Rammert, Werner (1993): Technik aus soziologischer Perspektive. Forschungsstand, Theorieansätze, Fallbeispiele, ein Überblick. Opladen: Westdt. Verlag. Ridley, Charles E.; Simon, Herbert A. (1938): Measuring Municipal Activities. International City Manager’s Association. Ritchie, Dennis (1984): Reflections on Software Research. 1983 Turing Award Lecture. In: Communications of the ACM 27 (8). 758–760. Ritchie, Dennis; Thompson, Ken (1974): The Unix Time-Sharing System. In: Communications of the ACM 17 (7). 365–375. Roberts, Karlene; Grabowski, Martha (1996): Organizations, Technology and Structuring. In: Clegg, Stewart; Hardy, Cynthia; Nord, Walter R. (Hg.): Handbook of Organization Studies. London: Sage Publications. 409–423. Rogers, Everett M. (2003): Diffusion of Innovations. 5. Auflage. New York: Free Press. (Org. 1962) Rolf, Arno (1998): Grundlagen der Organisations- und Wirtschaftsinformatik. Berlin, New York: Springer. Ropohl, Günter (1991): Technologische Aufklärung. Beiträge zur Technikphilosophie. Frankfurt am Main: Suhrkamp. Rose, Jeremy (1998): Evaluating the Contribution of Structuration Theory to the Information Systems Discipline. In: 6th European Conference on Information Systems. Aix-en-Provence: Management School. 910–924. Rösner, Andreas (1978): Die Wettbewerbsverhältnisse auf dem Markt für elektronische Datenverarbeitungsanlagen in der Bundesrepublik Deutschland. Berlin: Duncker & Humblot.

L ITERATUR

| 251

Røvik, Kjell Arne (2002): The Secrets of the Winners. Management Ideas that Flow. In: Sahlin-Andersson, Kerstin; Engwall, Lars (Hg.): The Expansion of Management Knowledge. Carriers, Flows, and Sources. Stanford, Calif: Stanford Business Books. 113–144. Rowe, Lawrence A. (2012): History of Ingres Corporation. In: IEEE Annals of the History of Computing 34 (4). 58–70. Sahlin-Andersson, Kerstin (1996): Imitating by Editing Success. The Construction of Organizationals Fields. In: Czarniawska-Joerges, Barbara; Sevón, Guje (Hg.): Translating Organizational Change. Berlin, New York: Walter de Gruyter. 69–92. SAP AG (Hg.) (2004): Real Time. A Tribute to Hasso Plattner. Indianapolis: Wiley Pub. Sawyer, Steve (2000): Packaged Software. Implications of the Differences from Custom Approaches to Software Development. In: European Journal of Information Systems 9. 47–58. Sawyer, Steve (2001): A Market-Based Perspective on Information Systems Development. In: Communications of the ACM 44 (11). 97–101. Scheer, August-Wilhelm (2004): Power on the Desktop. In: Hasso Plattner (Hg.): Real Time. A Tribute to Hasso Plattner. Indianapolis: Wiley Pub. 25– 36. Schein, Edgar H. (2003): DEC is Dead, Long Live DEC. The Lasting Legacy of Digital Equipment Corporation. San Fransisco: Berret-Koehler. Schlageter, Gunter; Stucky, Wolffried (1983): Datenbanksysteme. Konzepte und Modelle. 2. Auflage. Stuttgart: Teubner. Schneider, Hans-J. (1997): Lexikon der Informatik und Datenverarbeitung. München: Oldenburg Verlag. Schrage, Michael (2004): Never Go to the Client Meeting without a Prototype. In: IEEE Software 21 (2). 42–45. Schroer, Jutta Anna (2010): Der Berater. In: Moebius, Stephan; Schroer, Markus (Hg.): Diven, Hacker, Spekulanten. Sozialtypen der Gegenwart. Frankfurt am Main: Suhrkamp. 26–37. Schulz-Schaeffer, Ingo; Funken, Christiane (2008): Das Verhältnis von Formalisierung und Informalität betrieblicher Arbeits- und Kommunikationsprozesse und die Rolle der Informationstechnik. In: Funken, Christiane; SchulzSchaeffer, Ingo (Hg.): Digitalisierung der Arbeitswelt. Zur Neuordnung formaler und informeller Prozesse in Unternehmen. Wiesbaden: VS Verlag für Sozialwissenschaften. 11–39. Schulz-Schaeffer, Ingo (1999): Technik und die Dualität von Ressourcen und Routinen. In: Zeitschrift für Soziologie 28 (6). 409–428.

252 | D AS P ROJEKT SAP

Schulz-Schaeffer, Ingo (2000): Sozialtheorie der Technik. Frankfurt am Main: Campus. Schützeichel, Rainer (2004): Skizzen zu einer Soziologie der Beratung. In: Schützeichel, Rainer; Brüsemeister, Thomas (Hg.): Die beratene Gesellschaft. Zur gesellschaftlichen Bedeutung von Beratung. Wiesbaden: VS Verlag für Sozialwissenschaften. 273–285. Schwuchow, Karlheinz (2007): Der Business-Revolutionär: James Champy. In: Manager Seminare 113. 24–27. Scott, W. Richard (1987): Organizations. Rational, Natural and Open Systems. Englewood Cliffs, NJ: Prentice Hall. Scott, W. Richard (1994): Conceptualizing Organizational Fields. Linking Organizations and Societal Systems. In: Derlien, Hans-Ulrich; Gerhardt, Ute; Scharpf, Fritz (Hg.): Systemrationalität und Partialinteresse. Festschrift für Renate Mayntz. Baden-Baden: Nomos. 203–222. Scott, W. Richard; Meyer, John W. (1991): The Organization of Societal Sectors: Propositions and Early Evidence. In: DiMaggio, Paul; Powell, Walter W. (Hg.): The New Institutionalism in Organizational Analysis. Chicago: University of Chicago Press. 108–140. Seidl, David (2005): Organization and Interaction. In: Seidl, David; Becker, Kai Helge (Hg.): Niklas Luhmann and Organization Studies. Malmö, Herndon, VA: Liber. 145–170. Seidl, David; Mormann, Hannah (2014): Niklas Luhmann as Organization Theorist. In: Adler, Paul; du Gay, Paul; Morgan, Glenn; Reed, Mike (2014): Oxford Handbook of Sociology, Social Theory, & Organization Studies. Contemporary Currents. Oxford: Oxford University Press. 125–157. Shenhav, Yehouda A. (1999): Manufacturing Rationality. The Engineering Foundations of the Managerial Revolution. Oxford, New York: Oxford University Press. Shenhav, Yehouda; Weitz, Ely (2000): The Roots of Uncertainty in Organization Theory. A Historical Constructivist Analysis. In: Organization 7. 373–401. Sibley, Edgar H. (1974): On the Equivalence of Data Based Systems. In: Rustin, Randall (Hg.): Proceedings of 1974 ACM-SIGMOD Workshop on Data Description, Access and Control. 2 Bände. Ann Arbor, Michigan. 43–76. Siegele, Ludwig; Zepelin, Joachim (2009): Matrix der Welt. SAP und der neue globale Kapitalismus. Frankfurt am Main, New York: Campus-Verlag. Simon, Herbert A. (1943): The Incidence of a Tax on Urban Real Property. In: Quarterly Journal of Economics 57. 398–420. Simon, Herbert A. (1946): The Proverbs of Administration. In: Public Administration Review 6 (1). 53–67.

L ITERATUR

| 253

Simon, Herbert A. (1947): Administrative Behavior. New York: Macmillian. Simon, Herbert A. (1960): The New Science of Management Decision. Englewood Cliffs, NJ: Prentice Hall. Simon, Herbert A. (1969): The Sciences of the Artificial. Cambridge, Mass.: MIT Press. Simon, Herbert A. (1977): Models of Discovery. Reidel. Simon, Herbert A. (1981): Entscheidungsverhalten in Organisationen. Eine Untersuchung von Entscheidungsprozessen in Management und Verwaltung. Landsberg am Lech: Verlag Moderne Industrie. Simon, Herbert A. (1991): Models of My Life. New York: Basic Books. Simon, Herbert A. (1997): Administrative Behaviour. A Study of Decisionmaking Process in Administrative Organizations. 4. Auflage. New York: Free Press; Simon & Schuster. Smith, Merritt Roe; Marx, Leo (Hg.) (1994): Does Technology Drive History? The Dilemma of Technological Determinism. Cambridge, Mass.: MIT Press. Sondermann, Jochen Peter (2007): Interne Qualitätsanforderungen und Anforderungsbewertung. In: Pfeifer, Tilo; Schmitt, Robert (Hg.): Masing Handbuch Qualitätsmanagement. München: Carl Hanser Verlag. 387–404. Sprott, David (2000): Enterprise Resource Planning: Componentizing the Enterprise Application Packages. Tomorrow’s Customers Demand the Ability to Buy, Reuse, and Build Their Competitive-edge Solutions. Can the Package Vendors Adapt in Time? In: Communications of the ACM 43 (4). 63–69. Stach, Heike (2001): Zwischen Organismus und Notation. Zur kulturellen Konstruktion des Computer-Programms. Wiesbaden: Dt. Univ.-Verlag. Stichweh, Rudolf (2011): Niklas Luhmann. In: Ritzer, George; Stepnisky, Jeffrey (Hg.): The Wiley-Blackwell Companion to Major Social Theorists. Vol. II. Contemporary Social Theorists. Chichester: Wiley-Blackwell. 287–309. Still, Mary C.; Strang David (2009): Who Does an Elite Organization Emulate? In: Administrative Science Quarterly 54. 58–89. Stokes, Stewart L. (2000): Attracting and Keeping IT Talents. In: Information System Management 3. 1–9. Strang, David (2010): Learning by Example. Imitation and Innovation at a Global Bank. Princeton: Princeton University Press. Strang, David; Meyer, John W. (1993): Institutional Conditions for Diffusion. In: Theory and Society 22. 487–512. Strang, David; Sine, Wesley D. (2001): Inter-Organizational Institutions. In: Baum, Joel A.C (Hg.): Blackwell Companion to Organizations. Malden, Mass.: Blackwell. 497–519.

254 | D AS P ROJEKT SAP

Strübing, Jörg (2008): Grounded Theory. Zur sozialtheoretischen und epistemologischen Fundierung des Verfahrens der empirisch begründeten Theoribildung. Wiesbaden: Verlag für Sozialwissenschaften. Summerfield, Brian (2009): Bachman, Codd and Stonebraker. The Fathers of Modern Database. In: Certification Magazine. URL: http://certmag.com/bachman-codd-and-stonebraker-the-fathers-of-modern-databases/. Stand: 24. 06.2015 Tacke, Veronika; Borchers, Uwe (1993): Organisation, Informatisierung und Risiko. In: Weissbach, Hans-Jürgen; Poy, Andrea (Hg.): Risiken informatisierter Produktion. Wiesbaden: Westdeutscher Verlag. 125–151. Tacke, Veronika (2010): Organisationssoziologie. In: Kneer, Georg; Schroer, Markus (Hg.): Handbuch Spezielle Soziologien. Wiesbaden: VS Verlag für Sozialwissenschaften. 341–359. Tacke, Veronika (2015): Formalität und Informalität. Zu einer klassischen Unterscheidung in der Organisationssoziologie. In: v. Groddeck, Victoria; Wilz, Sylvia, Marlene (Hg.): Formalität und Informalität in Organisationen. Wiesbaden: Springer VS. 37-92. Tarde, Gabriel (2003): Die Gesetze der Nachahmung. Frankfurt am Main: Suhrkamp. (Org. 1890) Tasch, Dieter (1997): 50 Jahre Zukunft. Messen in Hannover 1947 – 1997. Hannover: Verlag Grütter. Taylor, Frederick Winslow (2006): The Principles of Scientific Management. New York: Cosimo. (Orig. 1911). Taylor, Frederick Winslow (1895): A Piece-Rate System: Being a Step Toward Partial solution of the Labor Problem. In: American Society of Mechanical Engineers (Hg.): Transactions of the American Society of Mechanical Engineers. New York City: The Society XXIV. 856–903. Timmermans, Stefan; Epstein, Steven (2010): A World of Standards but not a Standard World. Toward a Sociology of Standards and Standardization. In: Annual Review of Sociology 36. 69–89. Thompson, James D. (2003): Organizations in Action: Social Science Bases of Administrative Theory. New Brunswick, New Jersey: Transaction Publishers. (Orig. 1967). Trinczek, Rainer (2005): „Wie befrage ich Manager? Methodische und methodologische Aspekte des Experteninterviews als qualitative Methode empirischer Sozialforschung“. In: Bogner, Alexander ; Littig, Beate; Menz, Wolfgang (Hg.): Das Experteninterview. Theorie, Methode, Anwendung. Wiesbaden. 209–222.

L ITERATUR

| 255

Trist, Eric L.; Higgin, Garth, W.; Murray, Hugh; Pollock, Alexander B. (1963): Organizational Choice. London, UK: Tavistock. Tukey, John W. (1958): The Teaching of Concrete Mathematics. In: The American Mathematical Monthly 65. 1–9. Unicode (2000): Unicode Standard Extends to All World Languages. Seamless Data Interchange Across Borders Breaks e-Business Barriers. (Pressemeldung vom 29.02.2000). URL: http://www.unicode.org/announcements/ pr-3.0.html. Stand: 24.06.2015 Vollmer, Hendrik (2004): Folgen und Funktionen organisierten Rechnens. In: Zeitschrift für Soziologie 33 (6). 450–470. v. Groddeck, Victoria; Wilz, Sylvia Marlene (2015): Auf dem Papier und zwischen den Zeilen. Formalität und Informalität in Organisationen. In: v. Groddeck, Victoria; Wilz, Sylvia Marlene (Hg.): Formalität und Informalität in Organisationen. Wiesbaden: Springer VS. 7–37. Voswinkel, Stephan (2013): Kundenorientierung. In: Bröckling, Ulrich; Krasmann, Susanne; Lemke, Thomas (Hg.): Glossar der Gegenwart. 5. Auflage. Frankfurt am Main: Suhrkamp. 145–151. Wade, Bradford W.; Chamberlin, Donald D. (2012): IBM Relational Database Systems. The Early Years. In: IEEE Annals of the History of Computing 34 (4). 38–48. Walgenbach, Peter (2000): Die normgerechte Organisation. Eine Studie über die Entstehung, Verbreitung und Nutzung der DIN EN ISO 9000er Normenreihe. Stuttgart: Schäffer-Poeschel. Walgenbach, Peter; Meyer, Renate E. (2008): Neoinstitutionalistische Organisationstheorie. Stuttgart: Kohlhammer. Wang, Mei (2007): Cultivating the Generic Solution: The Shaping of Organizational Software Packages. Doctoral Dissertation. Edinburgh: University of Edinburgh. Warren, Ronald L. (1967): The Interorganizational Field as a Focus for Investigation. In: Administrative Science Quarterly 12. 396–419. Watts, Duncan J. (1999): Networks, Dynamics, and the Small-World Phenomenon. In: American Journal of Sociology 105. 493–527. Weber, Max (1972): Wirtschaft und Gesellschaft. Grundriß der verstehenden Soziologie. 5. Auflage. Tübingen: Mohr Siebeck. (Orig. 1922). Wedekind, Hartmut; Günzel, Holger (1999): „Top-Down“- versus „Bottom-up“Adaption von betriebswirtschaftlicher Standardsoftware. In: Buchmann, Alejandro P. (Hg.): Datenbanksysteme in Büro, Technik und Wissenschaft (BTW). GI-Fachtagung. Freiburg: Springer. 449–455.

256 | D AS P ROJEKT SAP

Westrup, Christopher; Knight, Frank (2000): Consultants and Enterprise Resource Planning (ERP) Systems. In: Proceedings of the European Conference on Information Systems. 637–644. Whitehead, Alfred North; Russell, Bertrand (1910-1913): Principia Mathematica. Cambridge: Cambridge University Press. (Vol. I 1910; Vol. II 1912; Vol. III 1913) Williams, Robin; Edge, David (1996): The Social Shaping of Technology. In: Research Policy 25. 856–899. Williamson, Oliver E. (1975): Markets and Hierarchies. Analysis and Antitrust Implications. New York: Free Press. Winner, Langdon (1999): Do Artifacts Have Politics? In: MacKenzie, Donald; Wajcman, Judy (Hg.): The Social Shaping of Technology. London: Open University Press: 28–40. (Orig. 1980). Wooten, Melissa; Hoffman, Andrew J. (2008): Organizational Fields. Past, Present and Future. In: Greenwood, Royston; Oliver, Christine; Sahlin, Kerstin; Suddaby, Roy (Hg.): The SAGE Handbook of Organizational Institutionalism. Los Angeles, London: SAGE. 130–147. Zuboff, Shoshana (1988): In the Age of the Smart Machine. New York: Basic Books.

Anhang

Umsatz- und Mitarbeiterentwicklung des Softwareherstellers In der folgenden Abbildung sind die Umsätze und Mitarbeiter nach Angaben aus Geschäftsberichten und Pressemeldungen der SAP AG für den Zeitraum 1972 bis 2011 aufgelistet. Indirekt lässt sich die Verbreitung von SAP-Software in den vergangenen vier Jahrzehnten an der Umsatzentwicklung und der Mitarbeiterzahl des Softwareherstellers SAP ablesen. 1980 waren 77 Mitarbeiter und Mitarbeiterinnen beim Softwarehersteller beschäftigt, 1990 waren es bereits über 2.000. Im Jahr 2000 arbeiteten über 24.000 Mitarbeiter und Mitarbeiterinnen bei SAP, 2010 waren es über 55.000. Lediglich im Jahr 2009 sank die Mitarbeiterzahl um 7,7 Prozentpunkte im Vergleich zum Vorjahr. Der Umsatz stieg ebenfalls in den vergangenen Jahrzehnten. Einzige Ausnahmen sind die Jahre 2003, in dem der Umsatz im Vergleich zum Vorjahr um 5,2 Prozentpunkte sank, und 2009, in dem der Umsatz um 7,8 Prozentpunkte sank. Besonders hohe Umsatzsteigerungen, das heißt um mehr als die Hälfte im Vergleich zum Vorjahr, gab es 1983 (67,4 Prozent) und 1986 (73,2 Prozent). 1989 verdoppelte sich der Umsatz im Vergleich zum Vorjahr (104,8 Prozent). Im Zeitraum 1994 bis 1998 gab es ebenfalls hohe Umsatzsteigerungen.

258 | D AS P ROJEKT SAP

Abbildung 17: Umsatz- und Mitarbeiterentwicklung

Quelle: Eigene Darstellung; aus Geschäftsberichten der SAP AG

A NHANG

| 259

Interviewmaterial und anderes Datenmaterial Der folgenden Übersicht ist zu entnehmen, welches Interview- bzw. Datenmaterial den einzelnen Teilen des Buches zugrunde liegt. Datenmaterial Interviewtranskript

Interviewtranskript

Experte/Expertin Berater für die Modellierung von Geschäftsprozessen in einem IT-Dienstleistungsunternehmen ehemaliger Berater beim Softwarehersteller SAP, FHProfessur Wirtschaftsinformatik, aktives Mitglied der Deutschsprachigen SAP-Anwendergemeinschaft (DSAG) Berater für das Modul HR in einem ITDienstleistungsunternehmen, Physiker Berater in einem IT-Dienstleistungsunternehmen, Schwerpunkt Chemiebranche, Betriebswirt Bereichsleiter der Informatikabteilung eines Automobilherstellers Bereichsleiter der Informatikabteilung eines Handelsunternehmens Entwickler beim Softwarehersteller SAP, fachlicher Hintergrund: KI-Forschung und Linguistik Berater in einem IT-Dienstleistungsunternehmen, Schwerpunkt Automobilbranche, (Elektro-) Ingenieur Berater in einem IT-Dienstleistungsunternehmen, verantwortlich für das Qualitätsmanagement von Softwareprojekten, promovierter Mathematiker Berater in einem IT-Dienstleistungsunternehmen

Interviewtranskript

Berater in einem IT-Dienstleistungsunternehmen

L

7

Interviewtranskript

Berater in einem IT-Dienstleistungsunternehmen

M

2, 7

Interviewtranskript

Interner Berater in einem Handelsunternehmen, ehemaliger Berater in einem IT-Dienstleistungsunternehmen, Schwerpunkt Logistik SAP-Anwender in der Abteilung Qualitätsmanagement in einem Handelsunternehmen Bereichsleiter der Informatikabteilung eines Handelsunternehmens Entwickler beim Softwarehersteller SAP, fachlicher Hintergrund: KI-Forschung und Linguistik Interner Berater in einem Handelsunternehmen in der Nahrungsmittelindustrie

N

4, 9

O

2

P

1, 4

Q

1

S

9

Leiterin der Informatikabteilung eines Nahrungsmittelherstellers, Informatikerin und Sozialwissenschaftlerin Bereichsleiter IT-Systeme bei einem Nahrungsmittelhersteller Charles W. Bachman, Turing-Preisträger, Entwickler des Netzwerk-Datenbankmodells; Quelle: http://archive.computerhistory.org Stand: 28.06.2015

W

4, 7, 9

X

7, 9

CB

1

Interviewtranskript

Interviewtranskript Interviewtranskript Interviewtranskript Interviewtranskript Interviewtranskript Interviewtranskript Interviewtranskript

Interviewtranskript Interviewtranskript Interviewtranskript Interviewtranskript

Interviewtranskript Interviewtranskript Oral HistoryTranskript

Kürzel

Kapitel

A

2, 7

B

1

C

1, 9

D

1, 7, 9

E

1

F

4

G

1

I

7

J

1, 7

K

7

260 | D AS P ROJEKT SAP Oral HistoryTranskript

Oral HistoryTranskript Oral HistoryTranskript

Transkript Beratungssituation

Donald Chamberlin, IBM-Forschungsmitarbeiter, Projektleiter von System R zur relationalen Datenbankabfragesprache; Quelle: http://archive.computerhistory.org Stand: 28.06.2015 Ken Thompson, Entwickler des Betriebssystems Unix; Quelle: http://archive.computerhistory.org Stand: 28.06.2015 Hasso Plattner, Mitgründer des Unternehmens SAP; Quelle: http://www.cwhonors.org/archives/histories/Plattner.pdf Stand: 28.06.2015; teilw. deutsche Übersetzung in Plattner et al. (2000) Projektmitglieder einer Softwareimplementierung bei einem Hersteller von Busfahrzeugen und ein Berater eines IT-Dienstleistungsunternehmens

DC

2, 7

KT

1

HP

1, 2, 4

6

A NHANG

| 261

Leitfaden Softwarenutzer: „SAP im Organisationsalltag“ 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

11. 12. 13. 14.

15. 16.

17.

Schildern Sie Ihren typischen Arbeitsalltag? Welche Rolle spielt dabei SAP? Kommt die Nutzung von SAP in Ihrer Stellenbeschreibung vor? Wie hat sich Ihr Arbeitsalltag durch die Einführung der Software verändert? Ein Arbeitsleben ohne SAP? Wie hat sich die Zusammenarbeit mit anderen Abteilungen/Niederlassungen verändert? Wie haben sich die Handlungsabläufe seit der Einführung von SAP verändert? Haben Sie Zugriff auf die Daten in anderen Niederlassungen (anderen Ländern)? Wird die SAP-Software national modifiziert? Können Sie hierfür Beispiele aus Ihrem Arbeitsbereich angeben? Gibt es regional/lokal spezifische Anwendungsformen? Wie werden die Vernetzungen von Niederlassungen/Tochterfirmen/Abteilungen durch SAP-Software dargestellt? (Stichwort: Buchungskreise) Wie gehen Sie mit Arbeitsabläufen/Entscheidungen um, die von der Software nicht repräsentiert werden können? Inwieweit – denken Sie – werden die Möglichkeiten der Software ausgeschöpft? Projektbeispiele? Welche Rolle spielt die Software für die Zusammenarbeit mit anderen Unternehmen? Hat sich die Kooperation und Koordination in Ihrem Unternehmen (Filialen)/mit anderen Unternehmen (Zulieferern etc.) nach Einführung der Software verändert? Wie sähe sie ohne SAP aus? Was bedeutet Realtime für Sie? Was bedeutet Datenintegration für Sie? Wie wirkt sich dies auf die tatsächliche Zusammenarbeit zwischen Kollegen, Abteilungen und Niederlassungen aus? Rückkopplungen/Feedback: Wird das Programm stetig verändert/verbessert? Reagiert das Unternehmen darauf mit Schulung von Mitarbeitern?

262 | D AS P ROJEKT SAP

Leitfaden Softwareentwickler: „Geschichte der SAPProgrammiersprache ABAP“ 1. 2. 3. 4. 5.

6.

7.

8.

9. 10. 11. 12. 13.

Was sind aus Ihrer Sicht die Meilensteine in der Entwicklung von ABAP seit den 1980er Jahren? Was hat der Allgemeine Berichts- und Auswerteprozessor noch mit der Programmiersprache ABAP gemeinsam? Was sind die Hauptmerkmale von ABAP? Was kennzeichnet ABAP als prozedurale Programmiersprache? Inwieweit wurde das Prinzip der strukturierten Programmierung in ABAP umgesetzt? Inwieweit sind Konzepte der Computerlinguistik in die Entwicklung von ABAP in den 1980er Jahren eingeflossen? Sie selbst haben ja auch im Bereich der Computerlinguistik studiert und geforscht. Wie schätzen Sie den Einfluss der Diskussionen in der wissenschaftlichen Disziplin der Informatik damals und heute ein? (Stichwort: Softwarekrise Ende der 1960er Jahre) Was für einen Anteil am späteren Erfolg von SAP-Software hatte die Entwicklung bzw. der Umstieg auf die relationale Datenbanktechnik Ende der 1980er Jahre? War die Umstellung auf Client-Server-Architektur der bedeutendere Schritt? Welche Konsequenzen hatte dies für die Entwicklung der Programmiersprache? Welche Vorteile und Probleme ergeben sich aus der Abwärtskompatibilität von ABAP? Können Sie das Prinzip der Bibliotheken erläutern? Wo genau steckt die betriebswirtschaftliche Logik von SAP-Software? Inwieweit ist mit der Programmiersprache ABAP auch die Einführungsmethode der Software in Unternehmen vorgegeben? Wie habe ich mir die Weiterentwicklung von ABAP vorzustellen? Welche Trends lassen sich erkennen? (Stichwort: objektorientierte Programmierung; Software als Service bedeutet Anwendungsentwicklung ohne Programmierer)

Danksagung

Bei den Menschen, die mich bei der Entstehung dieses Buches inspiriert, unterstützt und begleitet haben, möchte ich mich an dieser Stelle bedanken. Herbert Vogel eröffnete mir Einblicke in die IT- und Beraterwelt und traute mir dabei viel zu. Katrin Schlegel und Silvia Dicke förderten und forderten mich und mein praktisches Organisationswissen, was mein Interesse für organisationssoziologische Fragen und Themen weckte. Dieses Buch konnte nur entstehen, weil Entwickler, Berater und Anwender bereit waren, mir ihre Erfahrungen im Umgang mit SAP-Software mitzuteilen und sie alle geduldig meine Fragen zur Technik und zu ihrem Organisationsalltag beantworteten. Dafür möchte ich mich bei allen Interviewpartnerinnen und Gesprächspartnern bedanken. Besonders danken möchte ich Uwe Kalmer für sein ausdauerndes Interesse für meine Arbeit und seine tatkräftige Unterstützung bei der Datenerhebung. Ermöglicht wurde meine Forschung durch ein Promotionsstipendium der Deutschen Forschungsgemeinschaft. Bettina Heintz und Veronika Tacke danke ich für die Begutachtung meiner Arbeit im Rahmen des Promotionsverfahrens an der Universität Bielefeld. Mit ihren kritischen Hinweisen zum Text haben sie zur Fokussierung und zu entscheidenden Präzisierungen beigetragen. Darüber hinaus möchte ich den Kollegen und Kolleginnen des Graduiertenkollegs „Weltgesellschaft“ und des Arbeitsbereiches Organisationssoziologie der Universität Bielefeld für viele wertvolle und interessante Diskussionen danken. Vor allem möchte ich mich bei meinen Kollegen und Kolleginnen bedanken, die Teile der Arbeit bei unterschiedlichen Gelegenheiten mit mir diskutiert, wertvolle Anregungen gegeben und/oder durch ihre kritische Lektüre zur Verbesserung des Manuskripts beigetragen haben: Anna Beise, Hannah Bennani, Thomas Hoebel, Kjell Hoffmann, Sven Kette, Susann Kunadt, Britta Leisering, Martin Petzke, David Seidl, Miriam Tag und Hendrik Vollmer. Besonderer Dank gilt auch Raimund Hasse, der mir an der Universität Luzern großzügige Freiräume zur Fertigstellung des Manuskripts geschaffen hat. Katrin Herbon übernahm das Lektorat und

264 | D AS P ROJEKT SAP

half mir mit ihren Anmerkungen, die Argumentation zu schärfen. Erwin Hoffmann hat mir mit viel Geduld bei der Erstellung der Abbildungen in diesem Buch geholfen. Meiner Familie und meiner Freundin Sandra Rudolph danke ich für die motivierenden Gespräche. Thomas Mormann hat mich stets daran erinnert, dass man auch dann weiterlaufen sollte, wenn man gestolpert ist. Kjell Hoffmann danke ich für seine Liebe und sein Lachen.

Sozialtheorie Henning Laux (Hg.) Bruno Latours Soziologie der »Existenzweisen« Einführung und Diskussion September 2016, ca. 280 Seiten, kart., ca. 29,99 €, ISBN 978-3-8376-3125-8

Joachim Renn Selbstentfaltung – Das Formen der Person und die Ausdifferenzierung des Subjektiven Soziologische Übersetzungen II Juli 2016, ca. 300 Seiten, kart., ca. 39,99 €, ISBN 978-3-8376-3359-7

Kolja Möller, Jasmin Siri (Hg.) Systemtheorie und Gesellschaftskritik Perspektiven der Kritischen Systemtheorie Juli 2016, ca. 300 Seiten, kart., ca. 34,99 €, ISBN 978-3-8376-3323-8

Leseproben, weitere Informationen und Bestellmöglichkeiten finden Sie unter www.transcript-verlag.de

Sozialtheorie Hilmar Schäfer (Hg.) Praxistheorie Ein soziologisches Forschungsprogramm Mai 2016, ca. 300 Seiten, kart., ca. 29,99 €, ISBN 978-3-8376-2404-5

Andreas Reckwitz Kreativität und soziale Praxis Studien zur Sozial- und Gesellschaftstheorie Mai 2016, ca. 350 Seiten, kart., ca. 29,99 €, ISBN 978-3-8376-3345-0

Silke Helfrich, David Bollier, Heinrich-Böll-Stiftung (Hg.) Die Welt der Commons Muster gemeinsamen Handelns 2015, 384 Seiten, kart., zahlr. Abb., 19,99 €, ISBN 978-3-8376-3245-3

Leseproben, weitere Informationen und Bestellmöglichkeiten finden Sie unter www.transcript-verlag.de