Make-or-Buy bei Anwendungssystemen (eBook)

Björn Brandt promovierte bei Prof. Dr. Peter Buxmann am Fachgebiet Information Systems/Wirtschaftsinformatik der Technischen Universität Darmstadt. Er ist als Produktentwickler bei einem mittelständischen IT-Beratungsunternehmen tätig.

Geleitwort 5
Vorwort 7
Inhaltsverzeichnis 9
Abbildungsverzeichnis 13
Tabellenverzeichnis 16
Abk¨urzungsverzeichnis 18
1 Einleitung 20
1.1 Historische Einordnung 20
1.2 Problemstellung 23
1.3 Ziele der Arbeit 25
1.4 Forschungsmethodik und Gang der Untersuchung 26
2Ausgewahlte¨ ok¨ onomische Ansatze¨ zur Erklarung¨ und Unterstutzung¨ von Make-or-Buy-Entscheidungen – Ein konzeptioneller Bezu 28
2.1 Zur Auswahl der Theorien 28
2.2 Neo-institutionalistischer Theoriebereich 30
2.2.1 Transaktionskostentheorie 32
2.2.1.1 Hintergrund 33
2.2.1.2 Wesentliche Erklarungsfaktor¨ en 36
2.2.1.3 Erkla¨rungsund Gestaltungsbeitrage¨ der Transaktionskostentheorie fur¨ Make-or-Buy-Entscheidungen 38
2.2.2 Principal-Agent-Theorie 41
2.2.2.1 Hintergrund 42
2.2.2.2 Wesentliche Bestandteile der Principal-Agent-Theorie 43
2.2.2.3 Logik der Principal-Agent-Theorie bei der Anwendung auf Make-or-Buy-Entscheidungen 48
2.3 Strategischer Theoriebereich 50
2.3.1 Resource-based view 50
2.3.1.1 Hintergrund 51
2.3.1.2 Wesentliche Bestandteile des Resource-based view 52
2.3.1.3 Logik des Resource-based view bei der Anwendung auf Make-or-Buy-Entscheidungen 55
2.4 Soziologischer Theoriebereich 56
2.4.1 Theory of Planned Behavior 57
2.4.1.1 Hintergrund 57
2.4.1.2 Wesentliche Elemente 59
2.4.1.3 Logik der Theory of Planned Behavior bei der Anwendung auf Make-or-Buy-Entscheidungen 62
2.4.2 Social Exchange Theorie 64
2.4.2.1 Hintergrund 66
2.4.2.2 Wesentliche Komponenten einer sozialen Austauschbeziehung 68
2.4.2.3 Logik der Social Exchange Theory bei der Anwendung auf Make-or-Buy-Entscheidungen 70
2.5 Tabellarische Ubersicht¨ 72
3 Grundlagen zur Eigenund Fremdleistung bei Anwendungssystemen 74
3.1 Uberblick¨ 74
3.2 Begrif.iche Grundlagen zum Untersuchungsgegenstand 76
3.2.1 Informationssysteme und Anwendungssoftware 76
3.2.1.1 Abgrenzung von Anwendungssystemen 79
3.2.1.2 Neuund Weiterentwicklung sowie Wartung von Anwendungssystemen 81
3.2.1.3 Unterscheidung von Anwendungstypen 82
3.2.2 Eigenerstellung und Fremdbezug – De.nition und State-of-the-Art 82
3.2.2.1 Begrif.iche Abgrenzung 83
3.2.2.2 State-of-the-Art und Kernfragestellungen 84
3.2.3 Onshoring und Offshoring der Anwendungsentwicklung 92
3.2.3.1 Begrif.iche Abgrenzung und Systematisierung 92
3.2.3.2 Spezi.ka des Offshoring der Anwendungsentwicklung und -wartung 94
3.3 Make-or-Buy-Entscheidungen entlang des Standardisierungsgrades von Anwendungssystemen 96
3.3.1 Uberbl¨ ick 96
3.3.2 Neuentwicklung von Individualsoftware 98
3.3.2.1 De.nition und Eigenschaften 98
3.3.2.2 Betrachteter Untersuchungsgegenstand 99
3.3.3 Auswahl, Einsatz und Anpassung von Standardsoftware 106
3.3.3.1 De.nition und Eigenschaften 107
3.3.3.2 Betrachteter Untersuchungsgegenstand 108
3.3.4 Software as a Service als Spezialform von Standardsoftware 117
3.3.4.1 De.nition und Eigenschaften 118
3.3.4.2 Software as a Service versus klassische Standardsoftware 120
3.3.4.3 Untersuchungsgegenstand: Potenziale, Risiken und Triebkrafte¨ des Einsatzes von Software as a Service 124
4 Empirische Studien – Design, Durchfuhrung¨ und Ergebnisse 128
4.1 Dreistu.ges Vorgehensmodell im Uberblick,¨ Ablauf, Ziele der Einzelschritte 129
4.2 Eigenerstellung oder Fremdbezug bei Anwendungssystemen – Explorative Experteninterviews 132
4.2.1 Das Experteninterview als Forschungsmethode 132
4.2.2 Untersuchungsdesign 134
4.2.3 Qualitative Auswertung der Interviews 136
4.2.3.1 Spezi.ka kleiner und mittlerer Unternehmen 137
4.2.3.2 Allgemeine Aussagen zu Eigenund Fremdleistung in der IT kleiner und mittlerer Unternehmen 139
4.2.3.3 Eigenund Fremdleistung im Rahmen der Anwendungsentwicklung 140
4.2.3.4 Aussagen und Einstellungen zu Software as a Service 146
Strategische Aspekte 146
Operative Aspekte 147
Technische Aspekte 148
4.2.4 Einschra¨nkungen 149
4.3 Eigenoder Fremdleistung in Anwendungsentwicklung und -wartung – Eine quantitativ-deskriptive empirische Untersuchung 150
4.3.1 Uberbl¨ ick 150
4.3.2 Forschungsfragen 150
4.3.2.1 Individuelle Forschungsfragen 151
4.3.2.2 Komparative Forschungsfragen 155
4.3.3 Untersuchungsdesign 159
4.3.4 Datenerhebung 160
4.3.5 Stichprobencharakteristika 163
4.3.6 Deskriptive und induktive Analyse der primarstatistischen¨ Daten 166
4.3.6.1 Auswertungsstrategie und U¨ berblick 166
4.3.6.2 Uber¨ greifende Analysen zu Eigenoder Fremdleistung in Anwendungsentwicklung und -wartung 168
4.3.6.3 Individuelle Auswertungen 174
4.3.6.4 Komparative Auswertungen 200
4.3.7 Einschra¨nkungen 231
4.4 Software as a Service – Eine quantitativ-kon.rmatorische empirische Untersuchung des Adoptionsverhaltens deutscher KMUs 232
4.4.1 Uberblick 232
4.4.2 Forschungsmodell und Hypothesenentwicklung 233
4.4.2.1 Hypothesen auf Basis der Theory of Planned Behavior 234
4.4.2.2 Hypothesen auf Basis der Transaktionskostentheorie 238
4.4.2.3 Hypothesen auf Basis der Principal-Agent-Theorie 241
4.4.2.4 Hypothesen auf Basis des Resource-based view 245
4.4.2.5 Hypothesen auf Basis der Social Exchange Theory 248
4.4.2.6 Hypothesen basierend auf der Logik von Pfadabhangigk¨ eiten 250
4.4.3 Operationalisierung der Forschungskonstrukte 254
4.4.4 Datenerhebung 255
4.4.5 Stichprobencharakteristika 257
4.4.6 Datenanalyse 260
4.4.6.1 Strukturgleichungsmodelle 260
4.4.6.2 Analyse von Strukturgleichungsmodellen mit PLS 263
4.4.7 Evaluierung des Forschungsmodells 265
4.4.7.1 Validierung der Messmodelle 266
4.4.7.2 Analytische Auswertung des Strukturmodells 269
4.4.8 Diskussion der Ergebnisse 272
4.4.8.1 Implikationen fur¨ Wissenschaft und Forschung 272
4.4.8.2 Implikationen fur¨ die Praxis 274
4.4.9 Einschra¨nkungen 276
5 Schlussbetrachtung 278
5.1 Zusammenfassung 278
5.2 Handlungsempfehlungen fur¨ Anwenderunternehmen sowie Softwareund Serviceanbieter 281
5.3 Ausblick auf kunftige¨ Forschungsfragen 285
Literaturverzeichnis 287
A State-of-the-Art – Ein aktueller Literatur ¨uberblick 314
A.1 Durchsuchte Zeitschriften und IS-Konferenzen 315
A.2 U¨ berblick gefundener Studien 316
A.3 Verwendete ¨okonomische Ans¨atze 320
B Beschreibung der Anwendungstypen 325
C Leitfaden der Experteninterviews 328
D Fragebogen zur Eigen- oder Fremdleistung in Anwendungsentwicklung und -wartung 333
E Operationalisierung 340
E.1 Grad des SaaS-basierten Outsourcings 340
E.2 Konstrukte aus der Theory of Planned Behavior 340
E.3 Konstrukte aus der Transaktionskostentheorie 342
E.4 Konstrukte aus der Principal-Agent-Theorie 343
E.5 Konstrukte aus dem Resource-based view 345
E.6 Konstrukte aus der Social Exchange Theory 346
E.7 Konstrukte, die aus der der Logik der Pfadabh¨angigkeiten abgeleitet werden 346
F Fragebogen zur SaaS-Studie 348
G Cross-Loadings zur SaaS-Studie 354

1 Einleitung (S. 1)

1.1 Historische Einordnung

Die Entwicklung und Bereitstellung von Software (in Deutschland) kann auf eine fast 50-jährige Geschichte zurückblicken. Seit etwa 1960 wird Software verstärkt verwendet, um in Unternehmen Geschäftsprozesse zu unterstützen.

Durch ein sprunghaft verbessertes Preis-Leistungs- Verhältnis der Hardware wurde der Einsatz von Computern zunächst für große Unternehmen unter Kosten-Nutzen-Gesichtspunkten ermöglicht. Es entwickelte sich ein Spezialgebiet der Programmierung, die ”kommerzielle Anwendungsentwicklung“

. Das Potenzial für die Rationalisierung der Abwicklung von Geschäftsprozessen und für die Aufbereitung von Entscheidungsunterlagen war enorm. Es gab große Unternehmen, die frühzeitig Wettbewerbsvorteile sowie neue Geschäftsmodelle durch IT-Programmunterstützung realisieren wollten. Sie betrachteten den Einsatz von IT als strategische Entscheidung, bauten eigene IT-Abteilungen auf und realisierten auf ihr Unternehmen zugeschnittene Individualprogramme.

IT wurde damit zu einem unmittelbaren Wettbewerbsfaktor. Andere Großunternehmen warteten ab. Sie waren der Ansicht, dass grundlegende Geschäftsprozesse in nahezu allen Unternehmen ähnlich sind und dass gesetzliche Anforderungen an die Rechnungslegung sowie anerkannte Grundsätze der Kostenrechnung für alle Unternehmen gelten. Sie setzten darauf, dass man in absehbarer Zeit ”fertige“ Software kaufen kann.

Häufig waren das Unternehmen, die aufgrund ihrer einzigartigen Produkte der Ansicht waren, dass IT ”Commodity“ ist und deren Einsatz keine Wettbewerbsvorteile mit sich bringt. Es gab aber bis Mitte der 70er Jahre keine leistungsfähige Softwareindustrie, die für die zersplitterte Hardwarelandschaft mit unterschiedlichen Betriebssystemen das jeweils passende Produkt anbieten konnte.

Wegen der unbestreitbaren Vorteile des IT-Einsatzes entschieden sich viele zunächst zögerliche Unternehmen dann doch, eigene IT-Abteilungen aufzubauen und Software selbst zu entwickeln. Es entstand großer Bedarf nach Spezialisten für Systemanalyse und Programmentwicklung, der zum Entstehen der IT-Dienstleistungsbranche in den 60er und 70er Jahren führte.

Das Leistungsangebot der IT-Dienstleister bestand darin, im Auftrag von Unternehmen Individualsoftware zu entwickeln, den Unternehmen bei der Anpassung der Anwendungen auf die sich st¨andig ¨andernden Hardware- und Systemsoftwarekomponenten zu helfen sowie Kapazitäten bereit zu stellen für die Realisierung neuer Anwenderanforderungen.

Es war eine verbreitete Strategie in den Anwenderunternehmen, IT-Dienstleister zu beauftragen, um einen Knowhow- Transfer für die eigenen Mitarbeiter zu erreichen und Kapazitätsbedarfsspitzen abzudecken. Das verursachte hohe Kosten. Vor jeder Entscheidung, ein Programmsystem zu entwickeln, suchte man deshalb nach Standardsoftware, die die benötigte Funktionalität abdeckte.

Mit zunehmendem Funktionsumfang der Standard-IT-Produkte ergeben Wirtschaftlichkeitsüberlegungen, dass ein Fremdbezug tendenziell vorteilhafter als die Eigenerstellung ist. Ab diesem Zeitpunkt standen Großunternehmen verstärkt vor der Make-or-Buy-Entscheidung, Software selbst zu entwickeln oder zu kaufen. Für Prozesse, die gesetzlich geregelt und deshalb für alle Unternehmen verbindlich waren, wurden zuerst Standardprodukte am Markt angeboten.

Derartige Software konnte weitestgehend unverändert im Unternehmen eingesetzt werden, wobei individuelle Schnittstellen für die Integration in die IT-Landschaft des Unternehmens programmiert wurden. Bei Standardprodukten, die beispielsweise die Auftragsabwicklung, den Einkauf oder die Lagerhaltung etc. unterstützten, gab es zwar Unternehmen, die diese unverändert einsetzten, der Regelfall war aber, dass ein Standardprodukt als Grundlage diente, in das individuelle Funktionen einprogrammiert wurden.