E-Book, Deutsch, 356 Seiten, eBook
Brandt Make-or-Buy bei Anwendungssystemen
2010
ISBN: 978-3-8349-8603-0
Verlag: Betriebswirtschaftlicher Verlag Gabler
Format: PDF
Kopierschutz: 1 - PDF Watermark
Eine empirische Untersuchung der Entwicklung und Wartung betrieblicher Anwendungssoftware
E-Book, Deutsch, 356 Seiten, eBook
ISBN: 978-3-8349-8603-0
Verlag: Betriebswirtschaftlicher Verlag Gabler
Format: PDF
Kopierschutz: 1 - PDF Watermark
Unternehmen können notwendige Entwicklungsarbeiten an Anwendungssystemen durch eigene Mitarbeiter erbringen oder externe Dienstleister beauftragen (Make or Buy). Björn Brandt entwickelt eine Systematik von Make-or-Buy-Entscheidungen und stellt dar, welche Kriterien bei der Partnerwahl zugrunde liegen.
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.
Zielgruppe
Research
Weitere Infos & Material
1;Geleitwort;5
2;Vorwort;7
3;Inhaltsverzeichnis;9
4;Abbildungsverzeichnis;13
5;Tabellenverzeichnis;16
6;Abk¨urzungsverzeichnis;18
7;1 Einleitung;20
7.1;1.1 Historische Einordnung;20
7.2;1.2 Problemstellung;23
7.3;1.3 Ziele der Arbeit;25
7.4;1.4 Forschungsmethodik und Gang der Untersuchung;26
8;2Ausgewahlte¨ ok¨ onomische Ansatze¨ zur Erklarung¨ und Unterstutzung¨ von Make-or-Buy-Entscheidungen – Ein konzeptioneller Bezu;28
8.1;2.1 Zur Auswahl der Theorien;28
8.2;2.2 Neo-institutionalistischer Theoriebereich;30
8.2.1;2.2.1 Transaktionskostentheorie;32
8.2.1.1;2.2.1.1 Hintergrund;33
8.2.1.2;2.2.1.2 Wesentliche Erklarungsfaktor¨ en;36
8.2.1.3;2.2.1.3 Erkla¨rungsund Gestaltungsbeitrage¨ der Transaktionskostentheorie fur¨ Make-or-Buy-Entscheidungen;38
8.2.2;2.2.2 Principal-Agent-Theorie;41
8.2.2.1;2.2.2.1 Hintergrund;42
8.2.2.2;2.2.2.2 Wesentliche Bestandteile der Principal-Agent-Theorie;43
8.2.2.3;2.2.2.3 Logik der Principal-Agent-Theorie bei der Anwendung auf Make-or-Buy-Entscheidungen;48
8.3;2.3 Strategischer Theoriebereich;50
8.3.1;2.3.1 Resource-based view;50
8.3.1.1;2.3.1.1 Hintergrund;51
8.3.1.2;2.3.1.2 Wesentliche Bestandteile des Resource-based view;52
8.3.1.3;2.3.1.3 Logik des Resource-based view bei der Anwendung auf Make-or-Buy-Entscheidungen;55
8.4;2.4 Soziologischer Theoriebereich;56
8.4.1;2.4.1 Theory of Planned Behavior;57
8.4.1.1;2.4.1.1 Hintergrund;57
8.4.1.2;2.4.1.2 Wesentliche Elemente;59
8.4.1.3;2.4.1.3 Logik der Theory of Planned Behavior bei der Anwendung auf Make-or-Buy-Entscheidungen;62
8.4.2;2.4.2 Social Exchange Theorie;64
8.4.2.1;2.4.2.1 Hintergrund;66
8.4.2.2;2.4.2.2 Wesentliche Komponenten einer sozialen Austauschbeziehung;68
8.4.2.3;2.4.2.3 Logik der Social Exchange Theory bei der Anwendung auf Make-or-Buy-Entscheidungen;70
8.5;2.5 Tabellarische Ubersicht¨;72
9;3 Grundlagen zur Eigenund Fremdleistung bei Anwendungssystemen;74
9.1;3.1 Uberblick¨;74
9.2;3.2 Begrif.iche Grundlagen zum Untersuchungsgegenstand;76
9.2.1;3.2.1 Informationssysteme und Anwendungssoftware;76
9.2.1.1;3.2.1.1 Abgrenzung von Anwendungssystemen;79
9.2.1.2;3.2.1.2 Neuund Weiterentwicklung sowie Wartung von Anwendungssystemen;81
9.2.1.3;3.2.1.3 Unterscheidung von Anwendungstypen;82
9.2.2;3.2.2 Eigenerstellung und Fremdbezug – De.nition und State-of-the-Art;82
9.2.2.1;3.2.2.1 Begrif.iche Abgrenzung;83
9.2.2.2;3.2.2.2 State-of-the-Art und Kernfragestellungen;84
9.2.3;3.2.3 Onshoring und Offshoring der Anwendungsentwicklung;92
9.2.4;3.2.3.1 Begrif.iche Abgrenzung und Systematisierung;92
9.2.5;3.2.3.2 Spezi.ka des Offshoring der Anwendungsentwicklung und -wartung;94
9.3;3.3 Make-or-Buy-Entscheidungen entlang des Standardisierungsgrades von Anwendungssystemen;96
9.3.1;3.3.1 Uberbl¨ ick;96
9.3.2;3.3.2 Neuentwicklung von Individualsoftware;98
9.3.2.1;3.3.2.1 De.nition und Eigenschaften;98
9.3.2.2;3.3.2.2 Betrachteter Untersuchungsgegenstand;99
9.3.3;3.3.3 Auswahl, Einsatz und Anpassung von Standardsoftware;106
9.3.3.1;3.3.3.1 De.nition und Eigenschaften;107
9.3.3.2;3.3.3.2 Betrachteter Untersuchungsgegenstand;108
9.3.4;3.3.4 Software as a Service als Spezialform von Standardsoftware;117
9.3.4.1;3.3.4.1 De.nition und Eigenschaften;118
9.3.4.2;3.3.4.2 Software as a Service versus klassische Standardsoftware;120
9.3.4.3;3.3.4.3 Untersuchungsgegenstand: Potenziale, Risiken und Triebkrafte¨ des Einsatzes von Software as a Service;124
10;4 Empirische Studien – Design, Durchfuhrung¨ und Ergebnisse;128
10.1;4.1 Dreistu.ges Vorgehensmodell im Uberblick,¨ Ablauf, Ziele der Einzelschritte;129
10.2;4.2 Eigenerstellung oder Fremdbezug bei Anwendungssystemen – Explorative Experteninterviews;132
10.2.1;4.2.1 Das Experteninterview als Forschungsmethode;132
10.2.2;4.2.2 Untersuchungsdesign;134
10.2.3;4.2.3 Qualitative Auswertung der Interviews;136
10.2.3.1;4.2.3.1 Spezi.ka kleiner und mittlerer Unternehmen;137
10.2.3.2;4.2.3.2 Allgemeine Aussagen zu Eigenund Fremdleistung in der IT kleiner und mittlerer Unternehmen;139
10.2.3.3;4.2.3.3 Eigenund Fremdleistung im Rahmen der Anwendungsentwicklung;140
10.2.3.4;4.2.3.4 Aussagen und Einstellungen zu Software as a Service;146
10.2.3.4.1;Strategische Aspekte;146
10.2.3.4.2;Operative Aspekte;147
10.2.3.4.3;Technische Aspekte;148
10.2.4;4.2.4 Einschra¨nkungen;149
10.3;4.3 Eigenoder Fremdleistung in Anwendungsentwicklung und -wartung – Eine quantitativ-deskriptive empirische Untersuchung;150
10.3.1;4.3.1 Uberbl¨ ick;150
10.3.2;4.3.2 Forschungsfragen;150
10.3.2.1;4.3.2.1 Individuelle Forschungsfragen;151
10.3.2.2;4.3.2.2 Komparative Forschungsfragen;155
10.3.3;4.3.3 Untersuchungsdesign;159
10.3.4;4.3.4 Datenerhebung;160
10.3.5;4.3.5 Stichprobencharakteristika;163
10.3.6;4.3.6 Deskriptive und induktive Analyse der primarstatistischen¨ Daten;166
10.3.6.1;4.3.6.1 Auswertungsstrategie und U¨ berblick;166
10.3.6.2;4.3.6.2 Uber¨ greifende Analysen zu Eigenoder Fremdleistung in Anwendungsentwicklung und -wartung;168
10.3.6.3;4.3.6.3 Individuelle Auswertungen;174
10.3.6.4;4.3.6.4 Komparative Auswertungen;200
10.3.7;4.3.7 Einschra¨nkungen;231
10.4;4.4 Software as a Service – Eine quantitativ-kon.rmatorische empirische Untersuchung des Adoptionsverhaltens deutscher KMUs;232
10.4.1;4.4.1 Uberblick;232
10.4.2;4.4.2 Forschungsmodell und Hypothesenentwicklung;233
10.4.2.1;4.4.2.1 Hypothesen auf Basis der Theory of Planned Behavior;234
10.4.2.2;4.4.2.2 Hypothesen auf Basis der Transaktionskostentheorie;238
10.4.2.3;4.4.2.3 Hypothesen auf Basis der Principal-Agent-Theorie;241
10.4.2.4;4.4.2.4 Hypothesen auf Basis des Resource-based view;245
10.4.2.5;4.4.2.5 Hypothesen auf Basis der Social Exchange Theory;248
10.4.2.6;4.4.2.6 Hypothesen basierend auf der Logik von Pfadabhangigk¨ eiten;250
10.4.3;4.4.3 Operationalisierung der Forschungskonstrukte;254
10.4.4;4.4.4 Datenerhebung;255
10.4.5;4.4.5 Stichprobencharakteristika;257
10.4.6;4.4.6 Datenanalyse;260
10.4.6.1;4.4.6.1 Strukturgleichungsmodelle;260
10.4.6.2;4.4.6.2 Analyse von Strukturgleichungsmodellen mit PLS;263
10.4.7;4.4.7 Evaluierung des Forschungsmodells;265
10.4.7.1;4.4.7.1 Validierung der Messmodelle;266
10.4.7.2;4.4.7.2 Analytische Auswertung des Strukturmodells;269
10.4.8;4.4.8 Diskussion der Ergebnisse;272
10.4.8.1;4.4.8.1 Implikationen fur¨ Wissenschaft und Forschung;272
10.4.8.2;4.4.8.2 Implikationen fur¨ die Praxis;274
10.4.9;4.4.9 Einschra¨nkungen;276
11;5 Schlussbetrachtung;278
11.1;5.1 Zusammenfassung;278
11.2;5.2 Handlungsempfehlungen fur¨ Anwenderunternehmen sowie Softwareund Serviceanbieter;281
11.3;5.3 Ausblick auf kunftige¨ Forschungsfragen;285
12;Literaturverzeichnis;287
13;A State-of-the-Art – Ein aktueller Literatur ¨uberblick;314
13.1;A.1 Durchsuchte Zeitschriften und IS-Konferenzen;315
13.2;A.2 U¨ berblick gefundener Studien;316
13.3;A.3 Verwendete ¨okonomische Ans¨atze;320
14;B Beschreibung der Anwendungstypen;325
15;C Leitfaden der Experteninterviews;328
16;D Fragebogen zur Eigen- oder Fremdleistung in Anwendungsentwicklung und -wartung;333
17;E Operationalisierung;340
17.1;E.1 Grad des SaaS-basierten Outsourcings;340
17.2;E.2 Konstrukte aus der Theory of Planned Behavior;340
17.3;E.3 Konstrukte aus der Transaktionskostentheorie;342
17.4;E.4 Konstrukte aus der Principal-Agent-Theorie;343
17.5;E.5 Konstrukte aus dem Resource-based view;345
17.6;E.6 Konstrukte aus der Social Exchange Theory;346
17.7;E.7 Konstrukte, die aus der der Logik der Pfadabh¨angigkeiten abgeleitet werden;346
18;F Fragebogen zur SaaS-Studie;348
19;G Cross-Loadings zur SaaS-Studie;354
Ausgewählte ökonomische Ansätze zur Erklärung und Unterstützung von Make-or-Buy-Entscheidungen – Ein konzeptioneller Bezugsrahmen.- Grundlagen zur Eigen- und Fremdleistung bei Anwendungssystemen.- Empirische Studien – Design, Durchführung und Ergebnisse.- Schlussbetrachtung.
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.
