Entwicklung eines netzwerkbasier ten „Lieferanten Performance Management und Measurement“-Modells am Beispiel der Embedded-Software-Beschaffung in der Automobilindustrie PDF Free Download
1 / 204
/204
100%
-Modelles am Beispiel der Embedded-Software-
Beschaffung in der Automobilindustrie
Maria Meißner
Vollständiger Abdruck der von der Fakultät für Wirtschafts- und Organisationswissen-
schaften der Universität der Bundeswehr München zur Erlangung des akademischen
Grades eines
Doktors der Wirtschafts- und Sozialwissenschaften (Dr. rer. pol.)
angenommenen Dissertation.
Gutachter/Gutachterin:
1. Univ.-Prof. Dr. Michael Eßig
2. Jun.-Prof. Dr. Christian von Deimling
Die Dissertation wurde am 12.11.2024 bei der Universität der Bundeswehr München
eingereicht und durch die Fakultät für Wirtschafts- und Organisationswissenschaften
am 10.03.2025 angenommen. Die mündliche Prüfung fand am 01.10.2025 statt.
Vorwort II
Vorwort
Die vorliegende Dissertation ist im Rahmen einer Industrie-Promotion zwischen der
Universität der Bundeswehr München und einem Automobilkonzern im Zeitraum von
2019 bis 2024 entstanden. An dieser Stelle möchte ich allen beteiligten Personen mei-
nen großen Dank aussprechen, die mich bei der Anfertigung meiner Dissertation un-
terstützt haben.
Besonders danken möchte ich Herrn Univ.-Prof. Dr. Michael Eßig und Herrn Jun.-Prof.
Dr. Christian von Deimling für die ausgezeichnete Betreuung und die enorme Unter-
stützung bei der Umsetzung der gesamten Arbeit. Durch den stets intensiven Aus-
tausch konnte ich viele wertvolle Impulse und Anregungen gewinnen, ohne die meine
Arbeit nicht den jetzigen Reifegrad erreicht hätte.
Außerdem möchte ich mich bei meinen fachlichen Betreuern seitens meines Arbeitge-
bers Sandra Karsch und Dr. Alexander Kinski für den fachlichen Austausch und die
Unterstützung bei der Umsetzung der Fallstudie herzlich bedanken. Mein Dank gilt
außerdem meinen Vorgesetzten Frederic Wehling und Yuvina Vosshoff für ihre Ermu-
tigungen sowie die entgegengebrachte Geduld und Rücksichtnahme bezüglich meiner
Doppelbelastung über 1,5 Jahre.
Nicht zuletzt möchte ich mich bei meinem Mann Paul bedanken, der mich in allen Le-
benssituationen jederzeit unterstützt und ermutigt hat und mir den Rückhalt und Frei-
raum gegeben hat, den ich brauchte. Nur mit seiner Unterstützung konnte ich den
Kampfgeist und das Durchhaltevermögen entwickeln, um dieses Projekt erfolgreich zu
beenden.
Schließlich möchte ich mich noch bei meinen lieben Eltern, meiner Schwiegermutti,
meinem Bruder und meinen Freunden für ihre ständigen Ermutigungen, Zusprüche
und das entgegengebrachte Verständnis meiner eingeschränkten zeitlichen Verfüg-
barkeit bedanken. Besonders hervorheben möchte ich an dieser Stelle die wertvolle
Unterstützung durch Marius, Jens und Krissi, die mir in stressigen Zeiten wirklich ge-
holfen hat.
III Kurzfassung
Kurzfassung
Die fortschreitende Digitalisierung und die steigende Softwarekomplexität in Fahrzeu-
gen erschweren die Beschaffung und Integration kundenspezifischer Software erheb-
lich, da Abhängigkeiten geografisch verteilter Komponenten zu unerwarteten Wech-
selwirkungen führen. Die daraus resultierenden netzwerkartigen Lieferantenbeziehun-
gen stellen neue Anforderungen an das Lieferanten Performance Management
(LPMM). Eine systematische Literaturrecherche zeigt, dass bestehende LPMM-Mo-
delle überwiegend dyadische Lieferanten-OEM-Beziehungen adressieren und hori-
zontale Interaktionen im Lieferantennetzwerk weitgehend unberücksichtigt bleiben.
Das Ziel dieser Dissertation besteht folglich in der Entwicklung eines netzwerkbasier-
ten LPMM-Modells, das die spezifischen Anforderungen der Embedded-Software-Be-
schaffung integriert. Basierend auf einer systematischen Literaturrecherche im Netz-
werk Performance Management werden Anforderungen an das LPMM im Netzwerk-
kontext abgeleitet und anschließend im Rahmen einer eingebetteten Fallstudie im
Kontext der Automobilindustrie empirisch validiert. Die Datenerhebung erfolgt mittels
leitfadengestützter Interviews unter Zugrundelegung einer Netzwerkperspektive.
Die Untersuchung identifiziert die Phänomene Aufgaben-Interdependenz, Forced
Coopetition und kollaborative Leistungen als zentrale Einflussfaktoren der Netzwerk-
Performance. Forced Coopetition kann bei geeigneter Governance innovationsför-
dernd wirken, während Aufgaben-Interdependenz und kollaborative Leistungen primär
als leistungshemmend wahrgenommen werden. Aus der Analyse resultieren sechs
Kernanforderungen an ein effektives LPMM im Netzwerkkontext: klar abgegrenzte
Verantwortlichkeiten, Berücksichtigung von Abhängigkeiten, Transparenz, Multi-Di-
mensionalität, Kollektivität sowie Flexibilität. Diese bilden die Grundlage des entwickel-
ten LPMM-Modells, das eine systematische Steuerung der Lieferanten-Performance
auf Netzwerkebene ermöglicht.
Die Dissertation erweitert den wissenschaftlichen Diskurs in den Forschungsfeldern
Software-Multi-Sourcing und Lieferanten Performance Management, indem die Rele-
vanz netzwerkbezogener Phänomene für den Beschaffungskontext empirisch belegt
und auf dieser Grundlage ein netzwerkbasiertes LPMM-Modell entwickelt wird. Für die
Praxis liefert das Modell konkrete Handlungs- und Gestaltungsempfehlungen zur Ver-
besserung der Kommunikation und Leistungssteuerung in softwaregeprägten Liefe-
rantennetzwerken.
Abstract IV
Abstract
Advancing digitalization and increasing software complexity in vehicles render the pro-
curement and integration of customer-specific software considerably more difficult, as
dependencies between geographically distributed components lead to unexpected in-
teractions. The resulting network-like supplier relationships place new demands on
supplier performance management (SPM). A systematic literature review shows that
existing SPM models predominantly address dyadic supplier-OEM relationships and
widely disregard horizontal interactions in the supplier network.
This dissertation therefore aims to develop a network-based SPM model that integra-
tes the specific requirements of embedded software procurement. Based on a syste-
matic literature review in the field of network performance management, requirements
for SPM in a network context are deductively derived and empirically validated in an
embedded case study in the context of the automotive industry. The data collection is
carried out using semi-structured interviews on the basis of an underlying network per-
spective.
The study identifies the phenomena of Task Interdependence, Forced Coopetition, and
Collaborative Efforts as key influencing factors on the network performance. With ap-
propriate governance mechanisms, Forced Coopetition can promote innovation, while
Task Interdependence and Collaborative Efforts are primarily perceived as perfor-
mance-impeding factors. The analysis results in six core requirements for effective
SPM in a network context: clearly defined responsibilities, consideration of dependen-
cies, transparency, multidimensionality, collectivity, and flexibility. These requirements
serve as the basis for the developed SPM model, which enables systematic manage-
ment of supplier performance at the network level. The dissertation expands the sci-
entific discourse in the research fields of software multi-sourcing and supplier perfor-
mance management by empirically proving the relevance of network-related pheno-
mena for the procurement context and developing a network-based SPM model on this
basis. For practitioners, the model provides specific guidelines and recommendations
for improving communication and performance management in software-driven supp-
lier networks.
V Inhaltsverzeichnis
Inhaltsverzeichnis
Vorwort ....................................................................................................................... II
Kurzfassung .............................................................................................................. III
Abstract .................................................................................................................... IV
Inhaltsverzeichnis .................................................................................................... V
Abbildungsverzeichnis ......................................................................................... VIII
Tabellenverzeichnis ................................................................................................ IX
Abkürzungsverzeichnis ........................................................................................... X
1
-Modelles für die Embedded-Software-Beschaffung ..................... 1
1.1 Relevanz und Problemstellung ..................................................................... 1
1.2 Zielstellung und Forschungsfragen ............................................................... 7
1.3 Methodik und wissenschaftliche Gütekriterien .............................................. 9
1.4 Aufbau der Dissertation ............................................................................... 13
2 Theoretischer Hintergrund für die angestrebte Modellentwicklung ............ 14
2.1 Strukturierung des Forschungsstandes anhand eines konzeptionellen
Bezugsrahmens ..................................................................................................... 14
2.1.1 Zielstellung und Methodik .................................................................... 14
2.1.2 Systematische Literaturrecherche ........................................................ 18
2.1.3 Analyse bestehender Bezugsrahmen .................................................. 21
2.1.4 Diskussion der Anknüpfungspunkte zur Entwicklung des konzeptionellen
Bezugsrahmens ................................................................................................. 24
2.1.5 Zentrale Erkenntnisse und Forschungsbedarf ..................................... 34
2.2 Wissenschaftstheoretische Grundlagen ...................................................... 35
2.2.1 Systemtheorie ...................................................................................... 36
2.2.2 Modelltheorie ....................................................................................... 37
2.2.3 Prinzipal-Agenten-Theorie ................................................................... 39
Inhaltsverzeichnis VI
2.3 Zentrale Konzepte und Definitionen ............................................................ 40
2.3.1 Beschaffungstheoretische Grundlagen ................................................ 40
2.3.2 Grundlagen Lieferanten Performance Management & Measurement .. 41
2.3.3 Performance Management & Measurement im Netzwerk-Kontext ...... 46
2.3.4 Spezifika des Beschaffungskontextes .................................................. 51
3
-Modelles ........................................................... 65
3.1 Methodik zur Modellentwicklung ................................................................. 65
3.2
-Modell .......................................... 66
3.3 Diskussion der Erkenntnisse aus der systematischen Literaturrecherche .. 72
3.4 Validierung der Anforderungen und Modellentwicklung anhand einer
Fallstudienuntersuchung ........................................................................................ 77
3.4.1 Einordnung und Zielstellung ................................................................ 77
3.4.2 Fallauswahl .......................................................................................... 79
3.4.3 Datensammlung und -aufbereitung mittels Experteninterviews ........... 81
3.4.4 Qualitative Inhaltsanalyse .................................................................... 86
3.5 Einzelfallanalyse ......................................................................................... 91
3.6 Ergebnisse aus fallübergreifender Analyse ............................................... 107
3.6.1 Erkenntnisse zu Kontextfaktoren ....................................................... 107
3.6.2 Erkenntnisse zu netzwerkspezifischen Phänomenen ........................ 108
3.6.3 Erkenntnisse zur Lieferanten- und Netzwerk-Performance ................ 111
3.6.4 Erkenntnisse zur erfolgreichen Integration ......................................... 114
3.6.5 Erkenntnisse zum LPMM im Multi-Sourcing-Kontext ......................... 116
3.6.6 Impulse aus theoretischen Erklärungsansätzen ................................ 136
4 Diskussion und Beitrag zur Forschung ....................................................... 141
4.1 Diskussion der Ergebnisse ........................................................................ 141
4.2 Zusammenfassung der Erkenntnisse ........................................................ 147
4.3 Beiträge für Wissenschaft und Praxis ....................................................... 150
VII Inhaltsverzeichnis
5 Fazit und Limitationen ................................................................................... 154
5.1 Kritische Würdigung .................................................................................. 154
5.2 Ausblick ..................................................................................................... 155
Anhang ................................................................................................................... 158
Literaturverzeichnis .............................................................................................. 174
Abbildungsverzeichnis VIII
Abbildungsverzeichnis
Abbildung 1: Zielstellung der Dissertation ................................................................... 8
Abbildung 2: Forschungsdesign .................................................................................. 9
Abbildung 3: Vorgehensweise bei der Bezugsrahmenentwicklung ........................... 15
Abbildung 4: Eingrenzung des Forschungsfeldes anhand eines vorläufigen
Bezugsrahmens ........................................................................................................ 16
Abbildung 5: Vorgehensweise bei der systematischen Literaturrecherche ............... 19
Abbildung 6: Konzeptioneller Bezugsrahmen LPMM bei Embedded Software aus
Abnehmersicht .......................................................................................................... 24
Abbildung 7: Schnittstellen zwischen Beschaffungsmanagement und Performance
Management ............................................................................................................. 41
Abbildung 8: Vorgehensweise bei der konsekutiven Literaturrecherche ................... 48
Abbildung 9: Das Phänomen Forced Coopetition ...................................................... 54
Abbildung 10: Arten der Integrations-Interdependenz ............................................... 58
Abbildung 11: Kollaborative Leistungen in Multi-Agenten-Netzwerken ..................... 61
Abbildung 12: Methodik bei der LPMM-Modellentwicklung ....................................... 65
Abbildung 13: Anforderungen an ein netzwerkspezifisches LPMM-Modell ............... 68
Abbildung 14: LPMM-Modellentwurf .......................................................................... 73
Abbildung 15: Entwurf der Balanced Scorecard ........................................................ 75
-Multi--Kontext .. 78
Abbildung 17: Vorgehensweise bei der qualitativen Inhaltsanalyse .......................... 87
Abbildung 18: Einflussfaktoren auf die Lieferanten- und Netzwerk-Performance .... 112
Abbildung 19: Matrix der Performance-Einflussfaktoren ......................................... 113
Abbildung 20: LPMM-Modellelemente aus OEM- und Lieferantensicht .................. 126
Abbildung 21: Netzwerkbasiertes LPMM-Modell .................................................... 127
Abbildung 22: Balanced Scorecard ......................................................................... 130
IX Tabellenverzeichnis
Tabellenverzeichnis
Tabelle 1: Gütekriterien für qualitative Forschungsdesigns ....................................... 11
Tabelle 2: Angewandte Gütekriterien bei der Bezugsrahmen-Entwicklung ............... 17
Tabelle 3: Analyse der Bezugsrahmen aus der Kernliteratur .................................... 22
Tabelle 4: Empirische Unterstützung der Bezugsrahmen-Beziehungen ................... 30
Tabelle 5: Überblick über empirische Studien in der Kernliteratur ............................. 32
Tabelle 6: Empirische Unterstützung der Bezugsrahmen-Elemente ......................... 33
Tabelle 7: Definitionen Lieferanten Performance Measurement................................ 43
Tabelle 8: Definitionen Lieferanten Performance Management................................. 44
Tabelle 9: Charakteristika der zu untersuchenden Phänomene ................................ 52
Tabelle 10: Klassifikationsschema für IT-Multi-Sourcing-Modelle ............................. 55
Tabelle 11: Deduktiv ermittelte LPMM-Modellelemente ............................................ 69
Tabelle 12: Deduktiv ermittelte LPMM-Modellanforderungen .................................... 72
Tabelle 13: Methodische Übersicht der untersuchten Fälle ....................................... 84
Tabelle 14: Suchbegriffe für die lexikalische Suche .................................................. 88
Tabelle 15: Deskriptive Übersicht der untersuchten Fälle ......................................... 92
Tabelle 16: Netzwerkkonstellationen und Wortwolken der untersuchten Projekte .... 96
Tabelle 17: Phänomen-Wahrnehmung und Anforderungen nach Projekten ........... 101
Tabelle 18: Fallspezifische Wahrnehmung von Problemen ..................................... 102
Tabelle 19: Probleme aus OEM- und Lieferantenperspektive ................................. 108
Tabelle 20: Faktoren für eine erfolgreiche Integration ............................................. 115
Tabelle 21: Validierung der LPMM-Modellanforderungen ....................................... 117
Tabelle 22: Validierung der LPMM-Modellelemente ................................................ 121
Tabelle 23: Validierung des LPMM-Modelles .......................................................... 132
Tabelle 24: Handlungsempfehlungen zur praktischen Umsetzung der LPMM-
Modellanforderungen .............................................................................................. 133
Tabelle 25: Handlungsempfehlungen zur Gestaltung der LPMM-Modellelemente .. 135
Abkürzungsverzeichnis X
Abkürzungsverzeichnis
AHP Analytic Hierarchy Process
ECU Electronic Control Unit
FF Forschungsfrage
GSD Global Software Development
ICT Informations- und Kommunikationstechnologie
IT Informationstechnologie
KPI Key Performance Indicator
LPMM Lieferanten Performance Management und Measurement
MAN Lieferanten Performance Management
MES Lieferanten Performance Measurement
OEM Original Equipment Manufacturer
SDO Software Development Outsourcing
1 Relevanz und Problemstellung
1 Bedarf eines netzwerkbasierten Lieferanten Performance Management
und Measurement-Modelles für die Embedded-Software-Beschaffung
1.1 Relevanz und Problemstellung
Angesichts der fortschreitenden Globalisierung des stark wachsenden Softwaremark-
tes stellt die geografische Verteilung der einzelnen Software-Komponenten bei der
Software-Beschaffung eine wachsende Herausforderung dar, vor allem aufgrund der
zunehmenden Softwarekomplexität.
1
Dieser Aspekt spielt speziell bei der Integration
von kundenspezifischer (Individual)-Software, welche von einer Vielzahl von Lieferan-
ten bereitgestellt wurde, in bestehende IT-Infrastrukturen eine Rolle, da die Varianz
der Kundenanforderungen mit technischen Abhängigkeiten und unerwarteten Wech-
selwirkungen einhergeht.
2
In der IT-Literatur wird das Phänomen der Multi-Lieferanten-Integration im Rahmen
des Forschungsfeldes IT-Multi-Sourcing diskutiert.
3
Diese stellt ein Teilgebiet des IT-
Outsourcing dar. Cohen/Young
lined provisioning and blending of business and IT services from the optimal set of
4
Laut Erkenntnissen
von Könning et al. (2018) findet sowohl in der praktischen als auch in der akademi-
schen Literatur ein kontinuierliches Umdenken bei der Nutzung von Sourcing-Strate-
gien von Single-Sourcing in Richtung Multi-Sourcing statt.
5
Die Forschungsschwerpunkte im IT-Multi-Sourcing lagen bisher besonders auf der Lie-
ferantenauswahl, Management-Praktiken, Gründen für die Entscheidung für Multi-
Sourcing und dem Wissenstransfer zwischen Lieferanten.
6
Ebenso wurde der Aspekt
der Steuerung (Governance) von IT-Multi-Sourcing-Modellen bereits mehrfach in der
Literatur adressiert, wobei der Fokus dabei meist auf Koordinationsansätzen lag.
7
Laut
1
Vgl. Ojala et al. (2017), S. 15.
2
Vgl. Ojala et al. (2017), S. 15f.
3
Vgl. Bapna et al. (2010); Vgl. Goldberg/Satzger (2015); Vgl. Levina/Su (2008); Vgl. Lin (2015).
4
Cohen/Young (2006), S. 1.
5
Vgl. Könning et al. (2018), S. 1815.
6
Vgl. Lin (2015), S. 191.
7
Vgl. Lin (2015), S. 191; Bapna et al. (2010); Plugge/Janssen (2014); Rajamaki/Vuorinen (2013).
-Modelles für die Embedded-Software-Beschaffung 2
Lin (2016) fehlt es derzeit noch an einem tiefgreifenden Verständnis von Multi-Sour-
cing in Forschung und Praxis, da der Fokus der theoretischen Einblicke bislang auf
dyadischen Lieferanten-Abnehmer-Beziehungen liegt und das Management von hori-
zontalen Lieferanten-Beziehungen in diesem Kontext kaum untersucht werden.
8
Einen weiteren Aspekt der IT-Multi-Sourcing-Forschung stellt die Service Integration
dar. Diese kann laut Goldberg/Satzger (2016) definiert werden als das Management
und die Koordination von internen und externen Anbietern sowie deren voneinander
abhängigen Dienstleistungen zu einem kohärenten, kooperativen System.
9
Insbeson-
dere hinsichtlich der Integration von stark voneinander abhängigen Dienstleistungen
besteht in der IT-Multi-Sourcing-Literatur noch Forschungsbedarf, da bestehende An-
sätze aus verwandten Bereichen aufgrund der Besonderheit der Interdependenzen
nicht uneingeschränkt übertragbar sind.
10
In der IT Multi-Sourcing-Literatur wird betont, dass ein erfolgreiches Management von
Multi-Sourcing-Projekten aufgrund der Komplexität, die durch stark voneinander ab-
hängigen Dienstleistungen und die Beteiligung einer großen Anzahl von Akteuren ent-
steht, von entscheidender Bedeutung ist.
11
Der Aspekt des erhöhten Koordinationsbe-
darfs aufgrund von Aufgaben-Interdependenzen in Lieferanten-Netzwerken wird von
Bapna et al. (2010) in ihrem konzeptionellen Bezugsrahmen adressiert.
12
Dabei stellen
die Publizierenden fest, dass eine lineare Erweiterung der dyadischen Perspektive auf-
grund von Abhängigkeiten in der Leistungserstellung bei der Analyse solcher Umge-
bungen nicht mehr ausreichend sei.
13
Sie argumentieren, dass der Bedarf an Koope-
ration und Koordination sowie die Auswahl der Steuerungsmechanismen stark vom
Grad der Aufgaben-Interdependenz sowie von der Beobachtbarkeit und Prüfbarkeit
des Outputs abhängig seien.
14
Außerdem stelle die Bereitschaft von Lieferanten neben
8
Vgl. Lin (2016), S. 34.
9
Vgl. Goldberg/Satzger (2016), S. 2.
10
Vgl. Goldberg/Satzger (2016), S. 3; Vgl. Bapna et al. (2010), S. 788f.
11
Vgl. Könning et al. (2018), S. 1815; Vgl. Lin (2016), S. 34; Vgl. Goldberg/Satzger (2016), S. 3.
12
Vgl. Bapna et al. (2010), S. 790.
13
Vgl. Bapna et al. (2010), S. 794.
14
Vgl. Bapna et al. (2010), S. 789.
3 Relevanz und Problemstellung
den primären Einzelleistungen auch kollaborative bzw. unterstützende Leistungen zu
erbringen, eine Schlüsselrolle im IT-Multi-Sourcing-Kontext dar.
15
Die Herausforderung eines erhöhten Maßes an erforderlicher Zusammenarbeit wird in
der IT-Multi-Sourcing-Literaturströmung bereits adressiert.
16
Dabei sind insbesondere
zwei Aspekte relevant: Zum einen die geografische Verteilung der in den Entwick-
lungsprozess involvierten Lieferanten, zum anderen die erzwungene synergetische
Zusammenarbeit zwischen konkurrierenden Zulieferern.
17
Wiener/Saunders (2014)
bezeichnen letztgenanntes Phänomen erstmals als Forced Coopetition.
18
Zusammenfassend besteht im IT-Multi-Sourcing aktuell weiterer Forschungsbedarf im
Bereich der Multi-Lieferanten-Integration, insbesondere hinsichtlich der Service In-
tegration bei voneinander abhängigen Leistungen und der Steuerung von horizontalen
Lieferanten-Beziehungen. Bisherige Ansätze fokussierten oft auf dyadische Lieferan-
ten-Abnehmer-Beziehungen und vernachlässigten horizontale Lieferanten-Beziehun-
gen. Des Weiteren mangelt es derzeit an Untersuchungen zum erfolgreichen Manage-
ment der im Kontext von IT-Multi-Sourcing auftretenden Phänomene Aufgaben-Inter-
dependenz, Forced Coopetition und kollaborative Leistungen. Folglich soll die vorlie-
gende Dissertation einen Beitrag zur Schließung dieser Forschungslücken leisten. An-
hand einer eingebetteten Fallstudie sollen die letztgenannten Phänomene im Kontext
der Automobilbranche tiefgreifend untersucht werden, um darauf basierend einen ge-
eigneten Lösungsansatz für das erfolgreiche Lieferanten Management zu entwickeln.
Wie viele andere vormals hardwaregetriebene Branchen befindet sich auch die Auto-
mobilindustrie in einer digitalen Transformation und nähert sich damit zunehmend dem
Sektor der Informationstechnologie (IT) an.
19
Im Folgenden wird genauer auf die wach-
sende Bedeutung von Software im Automobilsektor eingegangen. Der Software-Anteil
im Fahrzeug unterliegt seit einigen Jahren einem exponentiellen Wachstum.
20
Die Soft-
ware fungiert dabei nicht nur als Enabler (engl. für Wegbereiter) und Beschleuniger für
15
Vgl. Bapna et al. (2010), S. 794.
16
Bapna et al. (2010); Lin (2016); Wiener/Saunders (2014).
17
Vgl. Lin (2015), S. 188.
18
Vgl. Wiener/Saunders (2014), S. 212.
19
Vgl. Llopis-Albert et al. (2021), S. 1.
20
Vgl. Broy (2006), S. 33.
-Modelles für die Embedded-Software-Beschaffung 4
zahlreiche Innovationen im Fahrzeugsektor, sondern auch als Schlüsseldifferenzie-
rungsmerkmal für Kunden, da der Kundenwert eines Fahrzeugs mittlerweile maßgeb-
lich über digitale Funktionen bestimmt wird.
21
In den vergangenen Jahrzehnten konn-
ten durch den Einsatz von Software zahlreiche wesentliche Innovationen im Automo-
bilbau realisiert werden, wie beispielsweise der Notbrems- oder der Einparkassistent.
22
Aktuell und auch zukünftig wird die Automobilindustrie durch softwaregetriebene
Trends wie dem autonomen Fahren, der Elektrifizierung und Konnektivität maßgeblich
beeinflusst.
23
Neben der Virtualisierung vormals mechanischer bzw. elektrischer Lö-
sungen können mittels Software auch völlig neue Funktionen realisiert werden, welche
den Kundennutzen in den Bereichen Komfort, Effizienz, Fahrerassistenz, Sicherheit
und Nachhaltigkeit steigern.
24
Die im Forschungsfeld des IT-Multi-Sourcing diskutierten Herausforderungen führen
auch in der Automobilindustrie zu gravierenden Problemen, welche in den folgenden
Abschnitten erläutert werden. Ein Großteil der Software im Fahrzeug ist auf Steuerge-
räten verortet, welche über Bus- und Protokollsysteme miteinander vernetzt sind.
25
Diese sogenannte eingebettete Software (engl. Embedded Software)
26
wird derzeit
noch zu großen Teilen in Form von individuellen, nicht veränderbaren Softwarekom-
ponenten eingekauft.
27
Dieser hohe Anteil sogenannter proprietärer Lösungen trägt
auch im Automobilsektor zu einer Komplexitätssteigerung und einem erhöhten Integ-
rations- und Testaufwand, bedingt durch ungewollte Wechselwirkungen, bei.
28
Zudem hat sich in den letzten zehn Jahren ein Wandel in der Fahrzeug-Elektronik-
Architektur hin zur Zentralisierung vollzogen, wodurch Steuergeräte, die vormals un-
abhängig voneinander gearbeitet haben, viel stärker miteinander vernetzt sind.
29
Die-
21
Vgl. Broy (2006), S. 34; Vgl. Berret et al. (2017), S. 34.
22
Vgl. Bernard et al. (2011), S. 18.
23
Vgl. Corent et al. (2019), S. 15; Vgl. Berret et al. (2017), S. 51.
24
Vgl. Bernard et al. (2011), S. 20.
25
Vgl. Bernard et al. (2011), S. 21.
26
Vgl. Bernard et al. (2011), S. 96.
27
Vgl. Broy (2006), S. 34; Vgl. Grimm (2003), S. 499.
28
Vgl. Bernard et al. (2011), S. 2123.
29
Vgl. Hedge et al. (2011), S. 99; Burkacky et al. (2019), S. 10.
5 Relevanz und Problemstellung
ser rasante technologische Wandel bringt neben Innovation und technischem Fort-
schritt zahlreiche Probleme mit sich.
30
Beispielsweise beliefen sich laut einer Schät-
zung von McKinsey die Gewährleistungskosten für softwarebedingte Fehler in der Au-
tomobilindustrie im Jahr 2008 auf 15 bis 20 Prozent des Gewinnes vor Steuern und
Zinsen.
31
Neben der wachsenden funktionalen und technischen Komplexität stellt vor
allem die Integration der zahlreichen miteinander vernetzten Softwarekomponenten,
welche mitunter von einer Vielzahl von Lieferanten entwickelt werden, eine Schlüssel-
Herausforderung dar.
32
Im Allgemeinen zählt die Integration zu den kritischsten Pha-
sen von Software-Entwicklungsprojekten, da hierbei häufig zuvor versteckte Fehler im
Zusammenspiel mit anderen Komponenten zum Vorschein treten.
33
Das hohe Prob-
lem- und Fehleraufkommen in dieser fortgeschrittenen Projektphase resultiert häufig
in einer starken Überschreitung von geplanten Entwicklungsaufwendungen, einem
deutlichen Zeitverzug bis hin zu einem Scheitern von derartigen Projekten, wie nach-
folgende Beispiele aus der Automobil- und Luftfahrtbranche belegen.
34
Durch ein hohes Fehleraufkommen in der späten Phase des Entwicklungsprozess sa-
hen sich Kunden des Elektro-mit verzögerten
Auslieferungen sowie reduzierten Funktionsangeboten zum Zeitpunkt der Auslieferung
konfrontiert.
35
Ebenso kommt es bedingt durch softwarebasierte Probleme vermehrt zu
Funktionsausfällen, Fehlermeldungen oder gar Rückrufaktionen, wie Presseartikeln zu
den Tesla-
entnehmen ist.
36
Dass software-bedingte Probleme sogar tödliche Folgen haben kann,
urden.
37
Weiterhin findet aufgrund des technologischen Wandels und der damit einhergehen-
den steigenden Komplexität eine zunehmende Spezialisierung der Lieferanten sowie
30
Vgl. Grimm (2003), S. 498.
31
Vgl. Bernard et al. (2011), S. 19.
32
Vgl. Ebert (2017), S. 86; Broy (2006), S. 37; Grimm (2003), S. 501.
33
Vgl. Larsson (2007), S. 2.
34
Vgl. Hedge et al. (2011), S. 101; Larsson (2007), S. 3.
35
Vgl. Hammerschmidt (2020); Jenkins (2020), Vgl.
36
Vgl. Axel Springer SE (2020); Vgl. Merkur tz Redaktions GmbH & Co. KG (2020).
37
Vgl. WELT (2020).
-Modelles für die Embedded-Software-Beschaffung 6
eine Öffnung des Marktes für 2nd Tier-Zulieferer
38
und branchenfremde Softwareun-
ternehmen statt.
39
Anstelle des bisher üblichen Einkaufes von integrierten Hardware-
Software-Paketen bei einem 1st Tier-Lieferanten
40
, gehen die Originalausrüstungsher-
steller (engl. Original Equipment Manufacturer, kurz OEM) mittlerweile dazu über,
Hardware und Software getrennt zu beschaffen
41
, was letztlich in der Entstehung he-
terogener, von Wettbewerb geprägter Lieferantennetzwerke mündet.
42
Eine generische Eigenschaft von Software besteht in der grundlegend schweren
Messbarkeit der Qualität aufgrund des immateriellen Charakters.
43
Demzufolge muss
die Qualitätsprüfung stets systematisch und anhand vorab definierter Kriterien erfol-
gen.
44
Bei Individualsoftware kann im Gegensatz zu Standardsoftware die Qualität
nicht vor dem Kauf, sondern entweder während des Entwicklungsprozesses oder an-
hand des Endproduktes geprüft werden.
45
Eine hundertprozentige Qualitätsabsiche-
rung kann dabei nicht erreicht werden.
46
Folglich handelt es sich dabei aus informa-
tionsökonomischer Sicht um Vertrauenseigenschaften und somit kann es helfen, die
Problemstellung aus der Perspektive der Prinzipal-Agenten-Theorie zu betrachten.
47
Hinzu kommt, dass im hier betrachteten Fall von Embedded Software, welche als fes-
ter Bestandteil technischer Geräte nur im Zusammenspiel funktioniert, die Funktiona-
lität nur im Verbund getestet werden kann und damit die späte Integrationsphase von
einem hohen Risiko und Testaufwand begleitet wird.
48
Das Vorliegen der Informationsasymmetrie, bedingt durch die generischen Eigen-
schaften des Beschaffungsobjektes automobiler Embedded Software zeigt die Not-
wendigkeit für Informations-, Motivations- und Kontrollmechanismen auf. Das legt den
38
Unter 2nd Tier-Lieferanten sind Unterlieferanten zu verstehen, welche die Direktlieferanten mit Unter-
Komponenten beliefern. Vgl. van Weele/Eßig (2017), S. 372.
39
Vgl. Burkacky et al. (2019), S. 30.
40
1st Tier-Lieferanten sind Lieferanten erster Ordnung, welche den Abnehmer direkt beliefern. Vgl. van
Weele/Eßig (2017), S. 373.
41
Vgl. Burkacky et al. (2019), S. 31; Broy (2006), S. 38.
42
Vgl. Burkacky et al. (2019), S. 8.
43
Vgl. Abts/Mülder (2017), S. 56.
44
Vgl. Abts/Mülder (2017), S. 56.
45
Vgl. Abts/Mülder (2017), S. 56.
46
Vgl. Abts/Mülder (2017), S. 76; Vgl. Herzig et al. (2017), S. 4.
47
Vgl. Backhaus/Voeth (2010), S. 192.
48
Vgl. Abts/Mülder (2017), S. 64; Vgl. Bernard et al. (2011), S. 23.
7 Zielstellung und Forschungsfragen
Anfangsverdacht nahe, dass ein dediziertes Modell für das Lieferanten Performance
Management und Measurement (LPMM) zur Problemlösung beitragen kann, da Per-
formance Management und Measurement-Systeme im Allgemeinen zur Reduktion
von Informationsasymmetrien bei einem angemessenen Kosten-Nutzen-Verhältnis
dienen können.
49
Die netzwerkartige Lieferanten-Struktur, welche von Aufgaben-Inter-
dependenz, kollaborativen Leistungen und Forced Coopetition geprägt ist, legt zudem
nahe, dass ein solches LPMM-Modell eine Netzwerk-Dimension aufweisen und die
netzwerkspezifischen Phänomene adäquat adressieren sollte. Dabei wird angenom-
men, dass keine vollständige Neugestaltung eines solchen kontextspezifischen
LPMM-Modelles erforderlich ist, sondern bereits bestehende Ansätze aus der LPMM-
Literatur in Teilen übernommen und angepasst werden können.
1.2 Zielstellung und Forschungsfragen
Vor dem Hintergrund der aufgezeigten Problemstellung sowie der dargelegten For-
schungslücke besteht das theoretische Ziel dieses Forschungsvorhabens in der Ent-
wicklung eines dedizierten LPMM-Modelles für das Beschaffungsobjekt Embedded
Software. Dieses Modell soll insbesondere die Phänomene Forced Coopetition, Auf-
gaben-Interdependenz und kollaborative Leistungen auf Netzwerk- und Akteursebene
adressieren. Neben dem genannten Erklärungsziel besteht das Gestaltungsziel dieser
Dissertation in der Ableitung von konkreten Handlungsempfehlungen für die Steuerung
der Zusammenarbeit mit Software-Lieferanten in Embedded-Software-Entwicklungs-
projekten aus Abnehmersicht.
50
Die Zielstellung dieser Arbeit ist auf Abbildung 1 sche-
matisch dargestellt.
49
Vgl. Kleindienst (2017), S. 32.
50
Vgl. Neus (2018), S. 13ff.
-Modelles für die Embedded-Software-Beschaffung 8
Abbildung 1: Zielstellung der Dissertation
51
Die Erreichung des Forschungsziels soll über die Beantwortung der folgenden For-
schungsfragen (FF) gewährleistet sein:
1. Status Quo: Woraus ergibt sich bei Embedded-Software-Entwicklungsprojek-
ten die Notwendigkeit einer dedizierten Lieferanten-Steuerung in Form eines
netzwerkbasierten LPMM-Modelles?
a. Welche Probleme treten in diesem Zusammenhang auf?
b. Welche Spezifika und Phänomene sind in diesem Kontext von Rele-
vanz?
c. Welchen Einfluss können diese auf die Performance von Software-Lie-
feranten im Rahmen von Embedded-Software-Entwicklungsprojekten
ausüben?
2. Modellentwicklung: Wie kann ein netzwerkbasiertes LPMM-Modell für Em-
bedded Software gestaltet sein?
a. Welchen Beitrag liefern bestehende Ansätze aus dem LPMM und dem
Netzwerk Performance Management?
b. Welche Anforderungen und Implikationen ergeben sich aus den Spezi-
fika des Beschaffungskontextes für das LPMM?
c. Welche Dimensionen und konstituierende Merkmale kann ein solches
Modell aufweisen?
51
Eigene Darstellung.
9 Methodik und wissenschaftliche Gütekriterien
d. Wie kann ein solches Modell zu einer erfolgreichen Integration beitra-
gen?
3. Modellevaluation:
a. Ist das entwickelte LPMM-Modell auf Netzwerk- und Akteursebene ge-
eignet, die Netzwerk-Performance sowie die erfolgreiche Integration po-
sitiv zu beeinflussen?
b. Welche Handlungs- und Gestaltungsempfehlungen können für die er-
folgreiche Implementierung eines LPMM-Modelles für Embedded Soft-
ware abgeleitet werden?
1.3 Methodik und wissenschaftliche Gütekriterien
Nachfolgend wird das zur Beantwortung der Forschungsfragen gewählte Forschungs-
design, welches auf Abbildung 2 dargestellt ist, vorgestellt.
Abbildung 2: Forschungsdesign
52
Zunächst erfolgt basierend auf einer systematischen Literaturrecherche im Bereich
die Strukturierung des aktuellen
Forschungsstandes und mündet in der deduktiven Entwicklung eines konzeptionellen
Bezugsrahmens. Dabei wird das Ziel verfolgt, die Forschungslücke zu schärfen und
Anknüpfungspunkte für die vorliegende Dissertation zu identifizieren. Dieser Bezugs-
rahmen soll außerdem im weiteren Verlauf der Arbeit als Strukturierungshilfe für die
ermittelten Ergebnisse genutzt werden.
52
Eigene Darstellung.
-Modelles für die Embedded-Software-Beschaffung 10
Basierend auf der mit Hilfe des Bezugsrahmens identifizierten Forschungslücke wird
nach der Klärung aller modell- und verständnisrelevanten Begrifflichkeiten und Kon-
zepte eine konsekutive Literaturrecherche durchgeführt. Da der Bezugsrahmen die
Notwendigkeit eines dedizierten LPMM-Modelles auf Netzwerk- und Akteurs-Ebene
offenbart, wird eine systematische fachdisziplinübergreifende Literaturrecherche im
mit dem Ziel der deduktiven Herleitung
von kontextspezifischen Modellanforderungen und -elementen durchgeführt. Dabei
-An-
sätze hinsichtlich Ihrer Eignung und Übertragbarkeit auf den vorliegenden Untersu-
chungskontext geprüft und es werden mögliche Einschränkungen der Übertragbarkeit
aufgezeigt.
Schließlich wird die Forschungsstrategie der empirischen Fallstudie angewendet.
53
Diese Methodik eignet sich besonders für komplexe und wenig erforschte Forschungs-
felder und ermöglicht Antworten auf deskriptive, explorative und explanative For-
schungsfragen.
54
Die Durchführung von Fallstudien ermöglicht die Erlangung eines
tiefgreifendes Verständnis eines komplexen Sachverhalts und den inhärenten Prozes-
sen und kann sowohl quantitative als auch qualitative Daten inkludieren.
55
Demzufolge
eignet sich diese Methodik, um die komplexen Problemstellungen des vorliegenden
Beschaffungskontextes zu durchdringen und tiefergehendes Wissen über die auftre-
tenden Phänomene sowie deren Erscheinungskontext aufzubauen. Ein eingebettetes
Fallstudiendesign liegt vor, wenn mehrere Untereinheiten eines übergeordneten Falles
individuell untersucht und anschließend zu einer ganzheitlichen Perspektive zusam-
mengeführt werden.
56
Das eingebettete Fallstudiendesign wird gewählt, um die analy-
tische Generalisierbarkeit der Ergebnisse durch den Vergleich ähnlicher Fälle inner-
halb eines übergreifenden Untersuchungskontextes zu erhöhen.
57
Ähnlich wie bei mul-
tiplen Fallstudien können durch die fallspezifische und fallübergreifende Analyse mul-
tipler, ähnlich gelagerter Fälle robustere Ergebnisse erzielt werden.
58
53
Vgl. Borchardt/Göthlich (2007), S. 35.
54
Vgl. Borchardt/Göthlich (2007), S. 35.
55
56
Vgl. Rowley (2002), S. 22; Vgl. Eisenhardt (1989), S. 534.
57
Vgl. Gibbert/Ruigrok (2010), S. 714.
58
Vgl. Oza (2006), S. 60.
11 Methodik und wissenschaftliche Gütekriterien
Im Kontext der Automobilindustrie werden acht Embedded-Software-Entwicklungspro-
jekte unter Zugrundelegung einer Netzwerkperspektive untersucht. Dabei werden für
jedes Entwicklungsprojekt Kontaktpersonen von OEMs und kollaborierenden Lieferan-
ten im Rahmen von Experteninterviews befragt. Durch die gewählte Netzwerkperspek-
tive wird gleichermaßen die Analyse von dyadischen Lieferanten-Abnehmer-Bezie-
hungen sowie von horizontalen Beziehungen zwischen Lieferanten ermöglicht. Außer-
dem bietet die Netzwerk-Analyseebene die Möglichkeit, netzwerkspezifische Phäno-
mene sowie deren Zusammenspiel im komplexen Akteurs-Beziehungs-Gefüge näher
zu beleuchten. Das Ziel der empirischen Fallstudie besteht einerseits in der Validie-
rung der zuvor deduktiv ermittelten Modellanforderungen und -elemente und anderer-
seits in der induktiven Ermittlung weiterer LPMM-Modellanforderungen sowie -Gestal-
tungs- und Handlungsempfehlungen.
Wie bei quantitativen Studien, können auch qualitative Studien hinsichtlich der Qualität
des wissenschaftlichen Erkenntnisgewinns beurteilt werden.
59
Hierzu werden zwar
ähnliche Begriffe für die Gütekriterien genutzt, jedoch sind diese mit einer anderen
inhaltlichen Bedeutung besetzt.
60
Obwohl in der Literatur bislang noch keine Einigkeit
über die Anwendung bestimmter Gütekriterien zur Beurteilung qualitativer For-
schungsvorhaben existiert, gehören die Konstruktvalidität, die interne und externe Va-
lidität und Reliabilität zu den etablierteren Gütekriterien.
61
In der nachfolgenden Tabelle
werden die Empfehlungen aus der Literatur bezüglich der Einhaltung jener Gütekrite-
rien dargestellt. Eine Prüfung der wissenschaftlichen Güte gemäß der u. g. Kriterien
wird im Rahmen der kritischen Würdigung in Kapitel 5.1 erfolgen.
Tabelle 1: Gütekriterien für qualitative Forschungsdesigns
62
Gütekriterium
Beschreibung und Empfehlungen aus der Literatur
Konstruktvalidität
• Verwendung mehrerer Erhebungsmethoden (Methodentriangula-
tion) zur Kompensation von Verzerrungen einzelner Methoden63,
• Beteiligung mehrerer Forschenden64,
• A priori Spezifikation der Konstrukte basierend auf relevanter Lite-
ratur zur Ermöglichung einer zielgerichteten Datenerhebung65,
59
Vgl. Borchardt/Göthlich (2007), S. 44.
60
Vgl. Borchardt/Göthlich (2007), S. 44.
61
Vgl. Borchardt/Göthlich (2007), S. 44; Vgl. Flick (2014), S. 411.
62
Eigene Darstellung.
63
Vgl. Borchardt/Göthlich (2009), S. 44f.
64
Vgl. Borchardt/Göthlich (2009), S. 44f.
65
Vgl. Borchardt/Göthlich (2009), S. 44f.
-Modelles für die Embedded-Software-Beschaffung 12
Gütekriterium
Beschreibung und Empfehlungen aus der Literatur
• Prüfung der Fallstudienreporte durch Probanden66,
• Dokumentation und Wahrung der Beweiskette67
Interne Validität
• Bezeichnung der Gültigkeit, Glaubwürdigkeit, Regelgeleitetheit, in-
tersubjektiven Überprüfbarkeit und Zuverlässigkeit68,
• Erhöhung der internen Validität durch steigende Anzahl bestätigen-
der Fälle und argumentative Validierung (Erläuterung von Über-
einstimmungen und Widersprüchlichkeiten; Darlegung der Argu-
mentationskette)69,
• Triangulation von Methoden und Datenquellen70,
• Logischer Vergleich empirischer Muster mit vorhergesagtem Mus-
ter71,
• Kontrolle der Kontextbedingungen durch weitgehende Standardisie-
rung der Erhebungs- und Auswertungsmethoden72
Externe Validität
• Bezeichnung der Übertragbarkeit und Verallgemeinerbarkeit73,
• Gilt aufgrund geringer Fall-Zahlen als Schwachpunkt qualitativer
Studien74,
• Bei qualitativen Studien Bezug auf analytische anstelle der statisti-
schen Generalisierbarkeit75,
• Verallgemeinerbarkeit der Ergebnisse auf theoretische Aussagen,
jedoch nicht auf Populationen76
Reliabilität
• Bezeichnung des Nachweises des Erzielens gleicher Ergebnisse
durch Wiederholung des Datenerhebungsverfahrens77,
• Einschränkung aufgrund der Einzigartigkeit und einer kontextab-
hängigen Bedeutung bei qualitativen Studien78,
• Beitrag zur Standardisierung durch die Erstellung eines Fallstudien-
protokolles79,
• Umfassende Dokumentation stellt Grundvoraussetzung dar80
66
Vgl. Borchardt/Göthlich (2009), S. 44f.
67
68
Vgl. Kuckartz (2016), S. 203; Vgl. Borchardt/Göthlich (2009), S. 45f.
69
Vgl. Borchardt/Göthlich (2009), S. 45.
70
71
72
Vgl. Flick (2020), S. 250.
73
Vgl. Kuckartz (2016), S. 203.
74
Vgl. Borchardt/Göthlich (2009), S. 45.
75
Vgl. Borchardt/Göthlich (2009), S. 45.
76
77
78
Vgl. Borchardt/Göthlich (2009), S. 46.
79
80
Vgl. Borchardt/Göthlich (2009), S. 46.
13 Aufbau der Dissertation
1.4 Aufbau der Dissertation
Der weitere Aufbau der Dissertation gestaltet sich wie folgt: Im konzeptionellen Kapitel
2 findet zunächst in eine Strukturierung des aktuellen Forschungsstandes statt, was in
der Entwicklung eines Bezugsrahmens sowie in der Konkretisierung des Forschungs-
bedarfes mündet. Weiterhin werden die für die Modellentwicklung notwendigen wis-
senschaftstheoretischen Grundlagen sowie zentrale Konzepte erläutert.
Kapitel 3 ist der Entwicklung des netzwerkbasierten LPMM-Modelles gewidmet. Nach
der Erläuterung der angewandten Methodik schließt sich die deduktive Ermittlung der
Modellanforderungen und -elemente sowie eine Diskussion der wesentlichen Erkennt-
nisse aus der konsekutiven Literaturrecherche an.
Kapitel 3.4 beinhaltet die Durchführung und Analyse der eingebetteten Fallstudie.
Nach einer kurzen Einordnung der Methodik wird anschließend die Vorgehensweise
bei der Fallauswahl, Datensammlung und der qualitativen Inhaltsanalyse erläutert. In
den Kapiteln 3.5 und 3.6 werden die Ergebnisse aus der fallspezifischen und fallüber-
greifenden Analyse vorgestellt und diskutiert. Dabei findet eine Clusterung der Er-
kenntnisse gemäß dem vorgestellten konzeptionellen Bezugsrahmen statt. Neben der
Beantwortung der Forschungsfragen erfolgt die Darstellung der ermittelten Modellan-
forderungen, des LPMM-Modelles sowie der Handlungs- und Gestaltungsempfehlun-
gen.
Die Diskussion und Zusammenfassung der Ergebnisse sowie die Darstellung des Bei-
trags für Wissenschaft und Praxis erfolgen in Kapitel 4. Abschließend findet in Kapitel
5 eine kritische Würdigung der Arbeit und der vorliegenden Limitationen statt und es
wird ein Ausblick auf weiteren Forschungsbedarf gegeben.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 14
2 Theoretischer Hintergrund für die angestrebte Modellentwicklung
2.1 Strukturierung des Forschungsstandes anhand eines konzeptionellen Bezugs-
rahmens
In den folgenden Unterkapiteln wird die Zielstellung und Vorgehensweise bei der Ent-
wicklung des konzeptionellen Bezugsrahmens erläutert. Anschließend wird im Detail
auf die systematische Literaturrecherche eingegangen und abschließend folgt die Vor-
stellung und Diskussion der zentralen Erkenntnisse.
2.1.1 Zielstellung und Methodik
Die Entwicklung eines Bezugsrahmens dient dem Verständnis und der Strukturierung
des vorhandenen Forschungswissens.
81
Dieser bildet alle für den Untersuchungskon-
text relevanten Elemente und vermutete Beziehungen ab und kann als Grundlage zur
Entwicklung des Forschungsdesigns genutzt werden.
82
Laut Eisenhart (1991) wird zwi-
schen theoretischen, praxisorientierten und konzeptionellen Bezugsrahmen unter-
schieden.
83
Praxisorientierte Bezugsrahmen stellen eine Strukturierung von Schlüs-
selelementen oder Praktiken dar, welche sich von Anwendern in einem Praxiskontext
als performant herausgestellt haben und nicht Theorie-geleitet sind, sondern auf prak-
tischem Erfahrungswissen beruhen.
84
Während der theoretische Bezugsrahmen de-
duktiv von einer oder mehreren etablierten Theorien abgeleitet wird
85
, ist der konzepti-
onelle Bezugsrahmen eher als eine Auswahl bzw. Synthese verschiedener Ideen und
Konzepte zu verstehen.
86
Diese können aus Forschungsergebnissen wissenschaftli-
cher Studien, Praxiswissen
87
sowie von theoretischen Überlegungen entstammen und
81
Vgl. Grant/Osanloo (2014), S. 17.
82
Vgl. Lester (2005), S. 458.
83
Vgl. Eisenhart (1991), S. 204.
84
Vgl. Eisenhart (1991), S. 207f.
85
Vgl. Grant/Osanloo (2014), S. 16.
86
Vgl. Eisenhart (1991), S. 209.
87
Vgl. Lester (2005), S. 460.
15 Strukturierung des Forschungsstandes anhand eines konzeptionellen
Bezugsrahmens
sollen einen Erklärungsansatz für das Forschungsproblem liefern sowie als Rechtfer-
tigung
88
für die Auseinandersetzung mit desselbigen dienen.
89
Wenngleich ein konzep-
tioneller Bezugsrahmen nicht mit einem kausalen Erklärungsmodell gleichzusetzen ist,
kann dieser vermutete Beziehungen zwischen den systematisch ausgewählten Kon-
zepten darstellen und folglich als Interpretation der sozialen Realität verstanden wer-
den.
90
Konzeptionelle Bezugsrahmen werden primär induktiv entwickelt und stellen so-
wohl für quantitativ als auch für qualitativ ausgelegte Untersuchungsdesigns eine ge-
eignete Grundlage dar.
91
Im Gegensatz zu theoretischen Bezugsrahmen dienen diese
der Konzeptionalisierung des Untersuchungskontextes unter Einbeziehung unter-
schiedlicher Informationsquellen und Perspektiven.
92
Durch diesen integrativen Cha-
rakter fördern sie die Bildung neuer Blickwinkel und Denkweisen.
93
Im Kontext dieser
Dissertation dient die Entwicklung des konzeptionellen Bezugsrahmens der Systema-
tisierung des Forschungsproblems für das LPMM von Embedded-Software-Lieferan-
ten sowie der Strukturierung des vorhandenen Wissens mit dem Ziel, Anknüpfungs-
punkte für diese und weitere Forschungsarbeiten aufzuzeigen und die Forschungslü-
cke zu schärfen.
Bei der Bezugsrahmen-Entwicklung wird auf den acht-stufigen Prozess von Jabareen
(2009) zurückgegriffen.
94
Die Vorgehensweise ist auf Abbildung 3 dargestellt und wird
im Folgenden erläutert.
Abbildung 3: Vorgehensweise bei der Bezugsrahmenentwicklung
95
Im ersten Schritt finden die Auswahl und Darstellung der relevanten Forschungsdis-
ziplinen statt. Basierend auf dem Anfangsverdacht, welcher sich aus der praktischen
88
Vgl. Lester (2005), S. 458.
89
Vgl. Imenda (2014), S. 189.
90
Vgl. Jabareen (2009), S. 51.
91
Vgl. Imenda (2014), S. 193.
92
Vgl. Eisenhart (1991), S. 211.
93
Vgl. Shapira (2011), S. 1315; gesamter Absatz in Anlehnung an Deimling (2019), S. 109118.
94
Vgl. Jabareen (2009), S. 53ff.
95
in Anlehnung an Jabareen (2009), S. 53ff.
Auswahl
Forschungs-
disziplinen
Systematische
Literatur-
recherche
Konzeptanalyse
& -zerlegung Integration &
Synthese Validierung
Theoretischer Hintergrund für die angestrebte Modellentwicklung 16
Relevanz ergibt, wird eine initiale Recherche innerhalb verschiedener Fachdisziplinen
durchgeführt. Die zuvor beschriebenen Herausforderungen in der Praxis treten grund-
legend beim Einkauf von kundenspezifischen Softwareentwicklungs-Dienstleistungen
auf. Standardsoftware hingegen wird als fertiges Produkt von einem Anbieter am Markt
bezogen.
96
Folglich besteht keine Informationsasymmetrie und es ist keine Steuerung
eines komplexen Lieferantennetzwerkes erforderlich. Dementsprechend werden die
97
cherche ausgewählt. Der erste Anfangsverdacht legt nahe, dass die hier vorliegende
Problematik unter Verwendung eines dedizierten LPMM-Modelles beherrscht werden
kann. Folglich soll in der Forschungsdisziplin und Measu-
rement nach bestehenden Lösungsansätzen gesucht werden. Aus den genannten
Teildisziplinen ergibt sich der vorläufige Bezugsrahmen, welcher in Form eines Venn-
Diagrammes auf Abbildung 4 dargestellt ist.
Abbildung 4: Eingrenzung des Forschungsfeldes anhand eines vorläufigen Bezugsrahmens
98
Die zweite Phase beinhaltet das detaillierte Einlesen in die ausgewählten Teildiszipli-
nen. Hierzu wird im Überschneidungsbereich aller drei Forschungsdisziplinen eine
systematische Literaturrecherche durchgeführt, welche in Kapitel 2.1.2 näher erläutert
wird. In diesem Zuge findet eine erste Kategorisierung statt, welche in iterativen Schrit-
96
Vgl. Abts/Mülder (2017), S. 59.
97
-Software, da in diesem Fall be-
reits ein fertiges Produkt vorliegt und keine Entwicklungs-Dienstleistung mehr erforderlich ist.
98
in Anlehnung an Hannewald et al. (2021), S. 6.
17 Strukturierung des Forschungsstandes anhand eines konzeptionellen
Bezugsrahmens
ten angepasst wird. Das auf diesem Wege entwickelte Analyseraster enthält Katego-
rien, welche neben der Entwicklung des konzeptionellen Bezugsrahmens zur deskrip-
tiven Analyse und Identifikation von Forschungslücken dienen.
Im dritten Schritt werden aus den ausgewählten Quellen die Konzepte extrahiert, ana-
lysiert und in ihre Hauptkomponenten zerlegt. Im Zuge der Analyse werden alle iden-
tifizierten Konzepte und Elemente hinsichtlich ihrer potenziellen Relevanz für die vor-
liegende Problemstellung geprüft. Im folgenden Schritt wird eine Synthese der Kon-
zepte und Elemente vorgenommen. Basierend auf Gemeinsamkeiten wurden Cluster
gebildet und nicht benötigte Konzepte schrittweise eliminiert. Die verbleibenden Kon-
zepte werden im nächsten Schritt, der Synthese, iterativ in verschiedenen Varianten
zusammengesetzt, bis eine geeignete und konsistente Konfiguration gefunden wird.
Anschließend erfolgen eine Validierung anhand von wissenschaftlichen Gütekriterien
sowie die kontinuierliche Überarbeitung des Bezugsrahmens.
Zur Überprüfung der wissenschaftlichen Güte wurden schließlich ausgewählte Prüfkri-
terien herangezogen. In Tabelle 2 sind die Kriterien sowie die angewandten Maßnah-
men zur Überprüfung dargestellt. Zur Gewährleistung des Neuheitswertes wurde eine
Analyse bestehender Bezugsrahmen durchgeführt. Die Generalisierbarkeit ist teil-
weise gegeben, da eine Übertragbarkeit auf andere Technologie- und Software-domi-
nierte Branchen grundsätzlich möglich ist. Um die interne Konsistenz zu gewährleisten,
fand ein Diskurs mit anderen Wissenschaftlern statt. Außerdem wird ein Abgleich mit
den Ergebnissen der empirischen Studie vorgenommen. Die Dokumentation der sys-
tematischen Vorgehensweise bei der Bezugsrahmenentwicklung sowie die Diskussion
der Ergebnisse in Forschungskolloquien tragen zur Reliabilität bei.
Tabelle 2: Angewandte Gütekriterien bei der Bezugsrahmen-Entwicklung
99
Gütekriterium
Beschreibung
Anwendung
Neuheitswert100
• Vergleich mit bestehen-
den Bezugsrahmen und
Überprüfung hinsicht-
lich Überschneidungen
und Unterschieden
• Analyse bestehender Bezugsrahmen
• Teilweise Übernahme von Elementen
(z. B. Strategie-Entwicklung, Aufgaben-
Interdependenz
Bezugsrahmen
99
Eigene Darstellung in Anlehnung an Deimling (2019), S. 118.
100
Vgl. Soni/Kodali (2013), S. 270.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 18
Gütekriterium
Beschreibung
Anwendung
• Neu: Trennung der Lieferanten Perfor-
mance in Akteurs- und Netzwerkebene
& erfolgreiche Integration als Zielgröße
Generalisierbar-
keit101
• Anwendbarkeit des Be-
zugsrahmens auf vari-
ierende (industrielle)
Kontexte
• Übertragbarkeit auf andere Branchen
aus dem Technologie-Bereich, welche
sich im digitalen Wandel befinden, oder
den Einkauf anderer komplexer Integra-
tionsgüter mit netzwerkartigen Lieferan-
ten-Strukturen wird angenommen sofern
vergleichbare Kontextfaktoren (Multi-
Sourcing, Individualität, Forced Coopeti-
tion, Aufgaben-Interdependenz, kollabo-
rative Leistungen) vorliegen
Interne Konsis-
tenz102
• Identifikation aller rele-
vanten Variablen und
Beziehungen
• Keine logischen Wider-
sprüchlichkeiten
• Überprüfung der internen Konsistenz
basierend auf den Ergebnissen empiri-
scher Studien
• Prüfung der internen Konsistenz im Aus-
tausch mit Praktizierenden und anderen
Forschenden
Reliabilität103
• Transparenz in der Vor-
gehensweise zur Be-
zugsrahmenentwick-
lung
• Verlässlichkeit, inso-
fern, dass andere For-
scher zu ähnlichen Er-
gebnissen kommen
• Anwendung und Dokumentation der
systematischen Vorgehensweise nach
Jabareen (2009)
• Diskussion der Ergebnisse in diversen
Forschungskolloquien
• Vornehmen von Anpassungen basie-
rend auf Feedback
2.1.2 Systematische Literaturrecherche
Bei der systematischen Literaturrecherche wurde ein dreistufiger Ansatz in Anlehnung
an Tranfield et al. (2003) angewandt, dessen Ablauf auf Abbildung 5 dargestellt ist.
104
Die erste Stufe beinhaltet die Planung des Reviews, was u. a. die Feststellung der
Notwendigkeit sowie die Vorbereitung eines Protokolls umfasst. Dies erfolgte durch
Gespräche mit Praktikern sowie einer groben Überblicksrecherche. Der erste Schritt
Durchführung), die Identification of Research
bereits erläuterte Auswahl der relevanten Themenfelder (siehe Abbildung 4) sowie die
Definition der Suchstrategie inklusive geeigneter Suchwörter. Die Recherche erfolgte
in fünf ausgewählten Datenbanken. Um eine möglichst hohe Trefferquote zu erzielen,
101
Vgl. Wacker (2004), S. 644.
102
Vgl. Wacker (2004), S. 644.
103
Vgl. Saunders et al. (2009), S. 600.
104
Vgl. Tranfield et al. (2003), S. 214219.
19 Strukturierung des Forschungsstandes anhand eines konzeptionellen
Bezugsrahmens
wurde die Suche auf Titel, Schlagwörter und Abstract begrenzt. Somit ergab sich eine
Anzahl von insgesamt 167 Quellen. Besonderheiten ergaben sich bei der Datenbank
Google Scholar. Hier fand eine weitere Eingrenzung des Such-
(distributed software" OR cyber-based OR multi-party software" OR software deve-
lopment outsourcing"), um eine überschaubare Ergebnisanzahl zu erhalten.
Abbildung 5: Vorgehensweise bei der systematischen Literaturrecherche
105
Für den zweiten Schritt, der Selection of Studies
terien gefiltert. Anschließend wurden Titel, Abstract und Schlagwörter nach inhaltlichen
Kriterien geprüft. Ausgeschlossen wurden dabei Studien, in denen Software nicht das
Beschaffungsobjekt darstellte oder es sich um den Einkauf von Standardsoftware han-
delte. Ein weiteres Ausschlusskriterium bestand im mangelnden Bezug zum Perfor-
mance Management. Dahingehend wurde geprüft, ob Performance Management As-
pekte wie z. B. kritische Barrieren, Erfolgsfaktoren, Performance-Einflüsse oder Per-
formance Management Modelle den Fokus der identifizierten Quellen darstellte. Eine
inhaltliche Eingrenzung auf die Automobilindustrie wurde nicht vorgenommen, um die
105
Eigene Darstellung in Anlehnung an Tranfield et al. (2003), S. 214219.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 20
Generalisierbarkeit der Ergebnisse gewährleisten zu können. Nach einer anschließen-
den Backward-Suche
106
wurden die verbleibenden Quellen schließlich einer inhaltli-
chen und qualitativen Volltext-Prüfung unterzogen Study quality assessment, wobei
sich die Anzahl der Ergebnisse auf 17 Quellen reduzierte. Die Datenextraktion und -
synthese stellen die letzten Schritte der Durchführung dar und wurden im Rahmen der
Bezugsrahmenentwicklung durchgeführt (siehe Kapitel 2.1.3 - 2.1.5).
Die 17 identifizierten Studien aus den Jahren 2003 bis 2018 setzen sich aus acht Kon-
ferenzbeiträgen, fünf Zeitschriftenaufsätzen, zwei Dissertationen sowie zwei weiteren
Hochschulschriften zusammen. Da die Journals und Konferenzen größtenteils im IT-
Bereich angesiedelt oder multidisziplinär aufgestellt sind, konnten folglich im Rahmen
der systematischen Literaturrecherche keine Beiträge identifiziert werden, die der Be-
schaffungsmanagement- oder Performance Management Literaturströmung direkt zu-
zuordnen sind.
Im Software Development Outsourcing
107
wird das Thema LPMM in vier verschiede-
nen Forschungsströmen aufgegriffen: Software Subcontracting, Global Software
Engineering & DevelopmentSoftware Development Outsourcing
IT-Multi-Sourcing. Nachfolgend wird auf die jeweiligen LPMM-Aspekte der identifi-
zierten Kernliteratur eingegangen. Im Bereich des Software Subcontracting befassen
sich die Publizierenden mit der Entwicklung einer Lieferanten-Bewertungsmethode so-
wie mit erfolgskritischen Management-Praktiken auf Einzellieferantenebene.
108
Im
GSE-Literaturstrom werden vor allem kritische Risiken und Einflussfaktoren auf die
Partnerschaftsqualität sowie den Projekterfolg untersucht.
109
In der Literaturströmung
SDO sind die Entwicklung eines Prozessmodelles zur Lieferantenauswahl sowie die
Ermittlung von Erfolgsfaktoren für den Aufbau und das Management von (partner-
schaftlichen) Beziehungen Untersuchungsgegenstand der Publizierenden.
110
Dazu
zählt eine Reihe von Studien, die sich mit dem Aufbau und Erhalt von Partnerschaften
106
Bei der Backward-Suche (Rückwärtssuche) werden die zitierten Quelleneines identifizierten Artikels
geprüft, um weitere passende Literatur zu identifizieren. Vgl. Brell (2020).
107
108
Assmann/Punter (2004); Calvo-Manzano et al. (2010).
109
Kumar/Thangavelu (2013); Ebert (2017); Ebert (2007).
110
Oza (2006); Fekete/Hancu (2010); Ali et al. (2017); Ali et al. (2018).
21 Strukturierung des Forschungsstandes anhand eines konzeptionellen
Bezugsrahmens
aus Lieferantensicht befassen.
111
Aus der Abnehmerperspektive ist das Thema part-
nerschaftliche Beziehungen in der Beschaffung von Softwareentwicklungs-Dienstleis-
tungen bisher nicht untersucht worden. Im SDO und GSE stehen sowohl dyadische
Beziehungen als auch einzelne Lieferanten im Fokus. Die Veröffentlichungen im Be-
reich IT-Multi-Sourcing befassen sich mit Erfolgsfaktoren und dem Einsatz von Anrei-
zen und Steuerungsmechanismen in einem Netzwerkkontext.
112
Spezifische Perfor-
mance Metriken sind in vier Beiträgen enthalten, wobei keine dieser Studien das
LPMM auf Netzwerkebene adressiert.
113
2.1.3 Analyse bestehender Bezugsrahmen
Wie in Kapitel 2.1.1 beschrieben, umfasst der dritte Schritt der Bezugsrahmenentwick-
lung die Analyse bestehender Bezugsrahmen mit dem Ziel der anschließenden Ex-
traktion der Kernelemente. Aus der Summe aller Beiträge, welche zwar im gleichen
Forschungsfeld angesiedelt sind, jedoch unterschiedliche Zielstellungen verfolgen,
sollen sich im Rahmen der Synthese Anknüpfungspunkte für den zu entwickelnden
Bezugsrahmen ergeben. Eine erste grobe Analyse der Kernliteratur ergab, dass 11
von 17 Publikationen praxisorientierte oder konzeptionelle Bezugsrahmen enthalten.
Theoretische Bezugsrahmen konnten im Rahmen der systematischen Literaturrecher-
che nicht identifiziert werden.
Tabelle 3 gibt Aufschluss über die Art, Perspektive, die enthaltenen Kernelemente so-
wie den Beitrag jener Bezugsrahmen für den hier vorliegenden Untersuchungskontext.
Fünf der identifizierten Bezugsrahmen sind als Prozessmodell für das Lieferanten Ma-
nagement oder den Lieferantenauswahl-Prozess zu verstehen. Eine systematische
Wiederverwendung der Bezugsrahmen kann nicht beobachtet werden, jedoch existie-
ren mitunter mehrfach aufgegriffene Elemente, wie z. B. die Sourcing-Strategie
114
so-
wie die Evaluation vergangener Erfahrungen.
115
Erkennbar ist außerdem, dass ein
Großteil der ermittelten Bezugsrahmen ausschließlich eine Abnehmerperspektive ein-
nimmt. Die Gleichzeitige Berücksichtigung von Lieferanten- und Abnehmersicht erfolgt
111
Ali et al. (2018); Ali et al. (2017); Ali/Khan (2014).
112
Bapna et al. (2010); Buttschardt (2017).
113
Assmann/Punter (2004); Assmann/Punter (2003); Ebert et al. (2008); Fekete/Hancu (2010).
114
Vgl. Assmann/Punter (2004), S. 143; Vgl. Ebert (2017), S. 95.
115
Vgl. Ebert (2017), S. 95; Vgl. Bapna et al. (2010), S. 789f.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 22
lediglich in der Dissertation von Oza (2006). Weiterhin wurde festgestellt, dass die
identifizierten Bezugsrahmen jeweils nur vereinzelte für diesen Untersuchungskontext
relevante Konzepte abbilden.
Tabelle 3: Analyse der Bezugsrahmen aus der Kernliteratur
116
Quelle
Bezugs-
rahmen Art
Perspek-
tive
Elemente
Beitrag
Assmann/P
unter (2003)
& (2004)
Praxisorien-
tiert
Abnehmer
Kontext-Bestimmung,
Strategie-Entwicklung,
Hauptprozessschritte,
benötigte Dokumente
MASS = Methode zur
Bewertung von Soft-
ware-Zulieferern, Dar-
stellung der notwendi-
gen Prozess-Schritte
Bapna et al.
(2010)
Konzeptio-
nell
Abnehmer
Aufgaben-Charakteristik,
Abnehmer-Entscheidun-
gen, langfristiges Lernen,
Performance Outcomes,
Kooperations- und Koor-
dinations-Anforderungen,
Lieferanten-Pool
Notwendigkeit der
Netzwerkperspektive
für das Performance
Management von
Software-Lieferanten,
Aufgaben-Interdepen-
denz, kollaborative
Leistungen
Buttschardt
(2017)
Konzeptio-
nell
Abnehmer
Forced-Coopetition-Be-
ziehung zwischen Liefe-
rant und Abnehmer,
Supplier Management,
Management Commit-
ment, etc. als Einfluss-
faktoren
Einflussfaktoren auf
Erfolg von Forced-
Coopetition-Beziehun-
gen im IT-Multi-Sour-
cing-Kontext
Calvo-
Manzano et
al. (2010)
Praxisorien-
tiert
Abnehmer
Ziele, Praktiken und
Probleme
Generische Probleme
im Software Sub-
contracting
Ebert
(2007)
Praxisorien-
tiert
Abnehmer
Lieferanten-Strategie,
Lieferantenauswahl, Ver-
trags-Management, Eva-
luation und Beziehungs-
Management
Wesentliche Supplier
Management-Pro-
zess-Schritte im Be-
reich GSE während
des gesamten Sour-
cing Zyklus
Ebert et al.
(2008)
Praxisorien-
tiert
Abnehmer
Flexibilität, Effizienz, Ta-
lent, Präsenz
Treiber und Risiken in
Bezug auf GSE
Ebert
(2017)
Praxisorien-
tiert
Abnehmer
Sourcing-Strategie, Initi-
alisierung und Anlauf,
Projekt-Durchführung,
Evaluation und Bezie-
hungs-Management
Wesentliche Supplier
Management-Pro-
zess-Schritte im Be-
reich GSE während
des gesamten Sour-
cing Zyklus
116
Eigene Darstellung.
23 Strukturierung des Forschungsstandes anhand eines konzeptionellen
Bezugsrahmens
Quelle
Bezugs-
rahmen Art
Perspek-
tive
Elemente
Beitrag
Fekete/Han
cu (2010)
Konzeptio-
nell
Abnehmer
Zielsetzung, Bestimmung
der Auswahl-Kriterien,
Gewichtung, Nutzwert-
Bestimmung
Prozessmodell für Lie-
ferantenauswahl im
SDO
Kumar/Tha
ngavelu
(2013)
Konzeptio-
nell
Lieferant
Partnerschafts-Qualität,
Vertrauen, Commitment,
soziale Interaktion, ge-
meinsames Verständnis,
etc.
Einfluss der Partner-
schafts-Qualität und
anderer Einfluss-Fak-
toren auf den Projekt-
erfolg im GSE
Oza (2006)
Konzeptio-
nell
Lieferant
und Ab-
nehmer
Kommunikation, Commit-
ment, Vertrauen, Pro-
zess, Transparenz
Einflussfaktoren auf
das erfolgreiche Ma-
nagement von Soft-
ware Outsourcing Be-
ziehungen
Aus diesem Grund wurde im Rahmen dieses Forschungsvorhabens ein neuer konzep-
tioneller Bezugsrahmen entwickelt, welcher alle für die Problemstellung relevanten
Konzepte umfasst. Dieser ist auf Abbildung 6 dargestellt und bildet das Ergebnis des
Synthese-Prozesses ab. Hierbei wurden die im Rahmen der Literaturanalyse identifi-
zierten Elemente geclustert und in iterativen Schritten zu neuen Konfigurationen zu-
sammengesetzt.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 24
Abbildung 6: Konzeptioneller Bezugsrahmen LPMM bei Embedded Software aus Abnehmer-
sicht
117
2.1.4 Diskussion der Anknüpfungspunkte zur Entwicklung des konzeptionellen Be-
zugsrahmens
In den folgenden Kapiteln wird zunächst der entwickelte konzeptionelle Bezugsrahmen
(siehe Abbildung 6) zusammen mit dessen Herleitung aus den Ergebnissen der Lite-
raturrecherche vorgestellt und auf die Bedeutung der einzelnen enthaltenen Elemente
für das Forschungsproblem eingegangen. Abschließend folgt eine Analyse der empi-
rischen Studien in der Kernliteratur mit dem Ziel, die bisherige empirische Fundierung
des Bezugsrahmens sowie Anknüpfungspunkte für zukünftige Forschung aufzuzeigen.
2.1.4.1 Kontext-Faktoren
Vier
118
der bestehenden Bezugsrahmen beinhalten das Element Strategie-Entwick-
lung, welche grundsätzlich den ersten Schritt im Lieferantenmanagement von globa-
len Software-Entwicklungsprojekten darstellen sollte.
119
Auch im Kontext von Software
Subcontracting stellt diese einen elementaren Bestandteil dar, da sie den Trade-off
117
Der hier dargestellte Bezugsrahmen bildet einen überarbeiteten Stand des im Rahmen von Hanne-
wald et al. (2021), S. 8 Vorgestellten Bezugsrahmens ab.
118
Vgl. Assmann/Punter (2003), S. 610; Vgl. Assmann/Punter (2004), S. 143; Vgl. Ebert (2017), S. 95;
Vgl. Ebert (2007), S. 4.
119
Vgl. Ebert (2017), S. 94.
25 Strukturierung des Forschungsstandes anhand eines konzeptionellen
Bezugsrahmens
zwischen vorhandenen Ressourcen und Zielen unterstützt.
120
Dieses Element wird in
der identifizierten Kernliteratur auf der Akteurs- bzw. dyadischen Ebene adressiert.
In der Praxis hat sich gezeigt, dass Embedded-Software-Entwicklungsprojekte von ei-
ner enormen Komplexität, bedingt durch die hochgradig vernetzte Softwarearchitek-
tur und ungewollte Interdependenzen, geprägt sind.
121
Diese Komplexität manifestiert
sich u. a. in der mangelnden Verifizierbarkeit und Prüfbarkeit von Entwicklungs-Dienst-
leistungen, welche Bapna et al. (2010) in ihrem Bezugsrahmen auf einer Netzwerk-
ebene adressieren.
122
Verschiedene Publizierende untersuchen kritische Faktoren und Risiken im Kontext
von GSE und SDO auf Akteursebene.
123
Im Kontext von IT-Multi-Sourcing identifiziert
Buttschardt (2017) kritische Erfolgsfaktoren für Forced Coopetition-Beziehungen, wie
Vertrauen, Wissenstransfer, kollaborative Software und langfristige Commitments.
124
Einen weiteren Kontext-Faktor, welcher in mehreren Bezugsrahmen Berücksichtigung
findet, stellt die Evaluation vergangener Erfahrungen mit Lieferanten dar.
125
Dazu
zählen die Analyse der Projektergebnisse, der Abgleich mit vorab definierten Service
Level Agreements sowie die Erarbeitung von Verbesserungsmaßnahmen für Lieferan-
ten und eigene Prozesse.
126
Bapna et al. (2010) berücksichtigen dabei ebenso konti-
nuierliche Anpassungen während laufender Projekte.
127
Da die Strategie-Entwicklung
und Evaluation vergangener Erfahrungen mit Lieferanten
128
als Kernelemente des
LPMM identifiziert wurden, werden diese auch im hier entwickelten Bezugsrahmen in-
kludiert.
120
Vgl. Assmann/Punter (2004), S. 141.
121
Vgl. Grimm (2003), S. 500; Vgl. Broy (2006), S. 36.
122
Vgl. Bapna et al. (2010), S. 790.
123
Ebert (2017); Oza (2006); Kumar/Thangavelu (2013).
124
Vgl. Buttschardt (2017), S. 167.
125
Vgl. Ebert (2007), S. 4; Vgl. Ebert (2017), S. 95; Vgl. Bapna et al. (2010), S. 790.
126
Vgl. Ebert (2007), S. 4.
127
Vgl. Bapna et al. (2010), S. 789.
128
Theoretischer Hintergrund für die angestrebte Modellentwicklung 26
2.1.4.2 Netzwerk-Performance ex-post Vertrag
Sundtoft Hald/Ellegaard (2011) nehmen bei ihrer Klassifikation der Performance Ma-
nagement-Literatur eine Unterscheidung in drei Analyseebenen vor: Lieferant (Ak-
teur), Lieferanten-Abnehmer-Beziehung (Dyade) und Lieferkette.
129
Ritter et al. (2004)
unterscheiden im Management von Beziehungen und Netzwerken hingegen zwischen
den fünf Analyseebenen Akteur, Dyade, Portfolio, verbundene Beziehung und Netz-
werk.
130
Für die vorliegende Arbeit werden zwei Analyseebenen zugrunde gelegt: die
Akteurs- bzw. dyadische Analyseebene sowie die Netzwerk-Analyseebene. Verschie-
dene Publizierende haben sich im Kontext der Software-Beschaffung bereits mit dem
LPMM auf der Akteurs- oder dyadischen Ebene befasst und in diesem Zusammen-
hang Prozesse, Modelle oder Metriken entwickelt.
131
Während zahlreiche Publizie-
rende dabei eine Einzellieferantenperspektive einnehmen
132
, weisen lediglich zwei der
identifizierten Publikationen einen Netzwerkbezug auf.
133
Ein LPMM-Ansatz mit Prüf-
Kriterien auf Netzwerkebene wird jedoch in keiner der beiden Veröffentlichungen vor-
gestellt.
Im hier vorliegenden Multi-Sourcing-Beschaffungskontext sind die Phänomene Auf-
gaben-Interdependenz
134
und Forced Coopetition
135
von Relevanz. Auch im unter-
suchten Spezialfall von automobilen Embedded-Software-Entwicklungsprojekten stel-
len diese Phänomene eine Herausforderung für das Management von Software-Liefe-
ranten dar.
136
Aufgaben-Interdependenz bezeichnet das Vorhandensein von Abhän-
gigkeiten zwischen Input- und Output-Faktoren in der Leistungserstellung mehrerer
Lieferanten.
137
Die Tatsache, dass Lieferanten bei Vorliegen von Aufgaben-Interdepen-
129
Vgl. Sundtoft Hald/Ellegaard (2011), S. 889.
130
Vgl. Ritter et al. (2004), S. 179.
131
Oza (2006); Fekete/Hancu (2010); Assmann/Punter (2004).
132
Calvo-Manzano et al. (2010); Assmann/Punter (2004); Assmann/Punter (2003); Fekete/Hancu
(2010); Ebert et al. (2008).
133
Buttschardt (2017); Bapna et al. (2010).
134
Bapna et al. (2010), S. 790.
135
Buttschardt (2017), S. 43.
136
Vgl. Buttschardt (2017), S. 1; Vgl. Bapna et al. (2010), S. 786.
137
Vgl. Bapna et al. (2010), S. 790.
27 Strukturierung des Forschungsstandes anhand eines konzeptionellen
Bezugsrahmens
denzen nicht unabhängig voneinander arbeiten können, berge Risiken für die Anreiz-
setzung und Lieferanten-Steuerung.
138
Bapna et al. (2010) konstatieren in diesem Zu-
sammenhang, dass der Erfolg der individuellen Leistung der Lieferanten wesentlich
von der Ausprägung der Aufgaben-Interdependenz beeinflusst werde, insbesondere
wenn eine Vielzahl von Software-Lieferanten zusammenwirkt, um ein integriertes, soft-
warebasiertes Produkt zu entwickeln.
139
Da in verschiedenen Studien ein Zusammen-
hang zwischen der Lieferanten-Performance und dem Coopetition-Phänomen festge-
stellt wurde
140
, besteht die Vermutung, dass sich auch der Spezialfall der Forced Coo-
petition auf die Lieferanten-Performance auswirken kann. Des Weiteren ist es in die-
sem Kontext erforderlich, dass Lieferanten neben den primären Leistungen auch kol-
laborative Leistungen in Form von Ressourcen, Informationen, etc. erbringen, um
eine nahtlose Integration aller Teilleistungen beim Abnehmer zu ermöglichen.
141
Ge-
mäß der Erkenntnisse von Alnatour/Gibson (2011) könne das Auftreten von multi-
agency
142
in Beschaffungs-Netzwerken einen negativen Einfluss auf die Netzwerk-Per-
formance haben und bedürfe eines dedizierten Management-Ansatzes.
143
Da die sys-
tematische Literaturrecherche ergeben hat, dass die Phänomene Forced Coopetition,
Aufgaben-Interdependenz und kollaborative Leistungen zu den wesentlichen Heraus-
forderungen bei der Beschaffung von Embedded Software zählen und ein vermuteter
Zusammenhang sowohl mit der Lieferanten-Performance als auch mit der Netzwerk-
Performance besteht, werden diese in den konzeptionellen Bezugsrahmen integriert.
Hinsichtlich des Zeitpunkts der Leistungsmessung kann grundsätzlich zwischen der
Ausschreibungsphase und dem Projektlebenszyklus unterschieden werden.
144
Die
identifizierten Publikationen fokussieren sich primär auf das LPMM während des Pro-
jektlebenszyklus als auf die Phase der Lieferantenauswahl.
145
In einigen Fällen wird
138
Vgl. Bapna et al. (2010), S. 786.
139
Vgl. Bapna et al. (2010), S. 785.
140
Vgl. Bouncken/Fredrich (2012), S. 20; Vgl. Mariani (2007), S. 120.
141
Vgl. Bapna et al. (2010), S. 786.
142
Multi-Agency ist ein Spezialfall des Agency Problems: Delegation von Entscheidungsgewalt und Kon-
trolle von einem Prinzipal an mehrere Agents, welche unterschiedliche Ziele und Risikoneigungen auf-
weisen und sich opportunistisch verhalten. Vgl. Alnatour/Gibson (2011), 2f.
143
Vgl. Alnatour/Gibson (2011), S. 3.
144
Vgl. Emmanuel-Ebikake et al. (2014), S. 969.
145
Vgl. Hannewald et al. (2021), S. 10.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 28
auch der gesamte Sourcing-Zyklus (Lieferantenauswahl und Projektlebenszyklus) be-
trachtet oder es wird keine Spezifizierung durch die Autorenschaft vorgenommen.
146
Da sich in der Praxis gezeigt hat, dass Probleme in diesem Zusammenhang vor allem
während der Entwicklung, dem Testen und insbesondere der Integration auftreten,
wird der Fokus dieses Forschungsprojekts auf das LPMM während des Projektlebens-
zyklus (ex-post Vertrag) gelegt.
2.1.4.3 Lieferanten-Management (Abnehmer)
Im dargestellten Bezugsrahmen (siehe Abbildung 6) ist erkennbar, dass das Lieferan-
ten Performance Management und Measurement als zentrales Werkzeug im Rah-
men des Lieferanten-Managements des Abnehmers fungiert. Den Erkenntnissen von
Bapna et al. (2010) zufolge, sei eine dyadische Steuerung der Lieferanten-Beziehun-
gen bei der Beschaffung von hoch integrativen softwarebasierten Produkten nicht
mehr ausreichend.
147
Für das erfolgreiche Management von Spannungen in komple-
xen Lieferanten-Netzwerken sei es laut Wilhelm (2011) notwendig, nicht nur die verti-
kalen Lieferanten-Abnehmer-Beziehungen, sondern auch die horizontalen Forced-
Coopetition
148
-Beziehungen zwischen den Lieferanten gezielt zu steuern
149
. Im hier vor-
liegenden Fall einer gewählten Multi-Sourcing-Strategie ist folglich ein dediziertes
LPMM-Modell, welches eine Akteurs- und Netzwerkebene aufweist und die netz-
werkspezifischen Phänomene adressiert, erforderlich.
2.1.4.4 Erfolgreiche Integration von Embedded Software
Chittister/Haimes (1996) verstehen unter dem Begriff System-Integration die Zusam-
menführung von Komponenten sowie die Koordination aller Kopplungen und Interak-
tionen zwischen den Komponenten, sodass das System die vorgesehene Funktionali-
tät erbringen kann.
150
Die nahtlose Integration von Softwarekomponenten stellt eine
der kritischsten Barrieren im GSE dar.
151
Bisher mangelt es jedoch trotz der enormen
146
Ebert (2007); Ebert (2017); Calvo-Manzano et al. (2010).
147
Vgl. Bapna et al. (2010), S. 794.
148
Manche Publizierenden
von Wiener und Saunders (2014) eingeführten Begriff der Forced Coopetition zu verwenden. Im Rah-
men dieser Arbeit wird stets der Begriff Forced Coopetition verwendet, insofern sich die Beschreibung
des Publizierenden mit der Definition nach Wiender und Saunders (2014) deckt.
149
Vgl. Wilhelm (2011), S. 664.
150
Vgl. Chittister/Haimes (1996), S. 522.
151
Vgl. Ilyas/Khan (2015), S. 1.
29 Strukturierung des Forschungsstandes anhand eines konzeptionellen
Bezugsrahmens
Relevanz der Integrationsphase für den Erfolg
152
von Software-Entwicklungsprojekten
an empirischer Forschung in diesem Bereich.
153
Ilyas/Khan untersuchen im Rahmen
diverser Studien die Integrations-Problematik aus Lieferantensicht und ermitteln in die-
sem Zusammenhang kritische Erfolgsfaktoren für GSE-Lieferanten.
154
Zafar et al.
(2011) identifizieren basierend auf einer Literaturanalyse und einer Delphi-Studie so-
wohl Integrations-Probleme als auch kritische Erfolgsfaktoren im Kontext von GSE-
Projekten.
155
Ilyas/Khan (2012a) stellen fest, dass die Literatur zur Integrations-Proble-
matik bislang eher problem- als lösungsorientiert ausgerichtet sei und es in diesem
Zusammenhang an konkreten Integrationslösungen und -praktiken mangele.
156
Ge-
mäß Larsson et al. (2009) könne der Einsatz dedizierter Metriken zur Verbesserung
des Integrations-Prozesses beitragen.
157
Aus technischer Sicht wurden Software-In-
tegrations-Metriken bereits mehrfach in der Literatur adressiert.
158
Nicht-technische
Lieferanten Performance-Metriken zur Unterstützung des Integrations-Prozesses
konnten im Rahmen der Literaturrecherche jedoch nicht ermittelt werden. Die erfolg-
reiche Integration von Embedded Software wurde als Zielgröße für diesen Bezugs-
rahmen ausgewählt, da dieser problembehaftete Aspekt den Projekterfolg maßgeblich
beeinflussen kann
159
und insbesondere in GSE-Umgebungen aufgrund von erhöhtem
Koordinations- sowie Kommunikationsbedarf eine große Herausforderung darstellt.
160
Da die erfolgreiche Integration von Embedded Software nur über die Zusammenarbeit
aller beteiligter Akteure im Netzwerk erreicht werden kann, ist diese als Dimension der
Netzwerk-Performance zu verstehen.
152
Vgl. Zafar et al. (2011), S. 291.
153
Vgl. Ilyas/Khan (2015), S. 1; Vgl. Ilyas/Khan (2017), S. 256.
154
Vgl. Ilyas/Khan (2015), S. 5; Vgl. Ilyas/Khan (2016), S. 244ff; Vgl. Ilyas/Khan (2012b), S. 454.
155
Vgl. Zafar et al. (2011), S. 294.
156
Vgl. Ilyas/Khan (2012a), S. 31.
157
Vgl. Larsson et al. (2009), S. 1068.
158
Kharb/Singh (2008); Narasimhan et al. (2009); Narasimhan/Hendradjaya (2007).
159
Vgl. Ilyas/Khan (2012b), S. 453.
160
Vgl. Ilyas/Khan (2012b), S. 2.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 30
2.1.4.5 Empirische Unterstützung des Bezugsrahmens
Mit Ausnahme der erfolgreichen Integration extern entwickelter Software, welche auf-
grund der praktischen Relevanz inkludiert wurde, entstammen alle Elemente des Be-
zugsrahmens der mittels systematischer Literaturrecherche identifizierten Quellen. Die
vermuteten Beziehungen zwischen den Elementen ergaben sich im ersten Schritt ba-
sierend auf Erkenntnissen und Aussagen aus der Kernliteratur, logischen Verknüpfun-
gen sowie gesammeltem Praxiswissen. Im zweiten Schritt wurde nach empirischen
Studien aus verwandten Fachdisziplinen oder Anwendungskontexten gesucht, welche
Belege oder Indikatoren für die aufgestellten Kausalitäten liefern. Die jeweiligen Kern-
aussagen der identifizierten Quellen sind in Tabelle 4 dargestellt.
Tabelle 4: Empirische Unterstützung der Bezugsrahmen-Beziehungen
161
Verbin-
dung
Kernaussage / Untersuchungsgegenstand
Quelle
[a]
Untersuchung des Zusammenhangs zwischen
Sourcing-Strategie und Lieferanten-Performance
Richardson/Roumasset
(1995)
[b]
Untersuchung des Einflusses von Service-Komple-
xität auf Lieferanten-Performance;
Untersuchung des Zusammenhangs von Projekt-
Komplexität, Grad der Abhängigkeit, Lieferanten-
Performance
Zou et al. (2019);
Mahapatra et al. (2010)
[c]
Einfluss kritischer Erfolgsfaktoren auf Qualität von
Forced-Coopetition-Beziehungen;
Einfluss von Risiken auf Outsourcing-Performance
Buttschardt (2017);
Wiengarten et al. (2013)
[d]
Identifikation von Project completion experience als
kritischer Erfolgsfaktor für Lieferantenentwicklung
Routroy/Kumar Pradhan
(2014)
[e]
Aufgaben- und Belohnungs-Interdependenz beein-
flussen Gruppen-Performance
Wageman/Baker (1997)
[f]
Coopetition kann sich bei hohem Vertrauen und Ab-
hängigkeiten positiv auf Performance auswirken;
Bei Flexibilität des Managements kann Forced Coo-
petition die Performance steigern
Bouncken/Fredrich
(2012);
Mariani (2007)
[g]
Kooperation bei gleichzeitig hoher Aufgaben-Inter-
dependenz steigert die Firmen-Leistung
Wageman/Baker (1997)
[h]
Untersuchung des Einflusses eines MAN-Systems
auf die Lieferanten-Performance
Maestrini et al. (2018b)
[i]
Grad der Lieferanten-Integration wird positiv beein-
flusst durch den Einsatz Innovations-bezogener
Lieferanten Performance-Metriken;
Militaru (2009);
Ilyas/Khan (2015)
161
Eigene Darstellung.
31 Strukturierung des Forschungsstandes anhand eines konzeptionellen
Bezugsrahmens
Verbin-
dung
Kernaussage / Untersuchungsgegenstand
Quelle
Identifikation von
folgsfaktor für Software-Integration
[j]
Reviews und regelmäßiges Feedback sind im
LPMM notwendig, um nachhaltige Performance-
Verbesserungen zu erzielen
[k]
Ein Performance Measurement-System kann das
Lernen innerhalb von Organisationen fördern;
Performance-Metriken sollten in regelmäßigen Ab-
ständen rekalibriert werden
Amaratunga/Baldry
(2002);
Parkash/Kaushik (2011a)
Weiterhin wurde eine Analyse aller empirischer Studien aus der Kernliteratur durchge-
führt. Es wurden alle Artikel untersucht, welche ausschließlich oder teilweise empiri-
sche Studien enthalten, um daraus mögliche Ansatzpunkte für weitere empirische For-
schung zu identifizieren. Dabei wurden Forschungsdesign, Art der Datenerhebung und
Datenanalyse den wesentlichen empirischen Ergebnissen gegenübergestellt. Von den
17 identifizierten Kernstudien weisen lediglich sieben Publikationen einen empirischen
Teil auf. Zwei der Publikationen geben einen spezifischen Branchenfokus an, darunter
eine Studie mit Bezug zur Automobilindustrie.
162
Die knappe Mehrheit der Studien ba-
siert auf der Verwendung von quantitativen Daten, welche zum Teil durch Fragebögen
erhoben oder als Sekundärdaten aus Industrieprojekten bezogen wurden. Qualitative
Daten wurden in allen drei Fällen im Rahmen von Interviews erhoben. Auffällig ist,
dass teilweise wenige oder keine Angaben zum empirischen Vorgehen gemacht wer-
den, sodass die Validität der Ergebnisse nicht vollständig beurteilt werden kann.
163
In-
haltlich ist eine starke Fokussierung auf die Entwicklung kritischer Erfolgs- und Ein-
flussfaktoren sowie Risiken zu beobachten. Mit Ausnahme von Bapna et al. (2010) und
Ebert et al. (2008) wird stets eine dyadische Perspektive eingenommen. Ein Netzwerk-
kontext liegt in zwei Publikationen vor, welche dem Forschungsstrom IT-Multi-Sourcing
zuzuordnen sind.
164
Folglich kann ein Bedarf an weiterer empirischer Forschung zum
LPMM auf Netzwerkebene bei der Beschaffung von Embedded Software konstatiert
werden. Die Ergebnisse sind in Tabelle 5 dargestellt.
162
Ebert (2017).
163
Bapna et al. (2010); Ebert (2007); Ebert et al. (2008).
164
Buttschardt (2017); Bapna et al. (2010).
Theoretischer Hintergrund für die angestrebte Modellentwicklung 32
Tabelle 5: Überblick über empirische Studien in der Kernliteratur
165
Quelle [Bran-
chenfokus]
Forschungs-
design [Da-
tensamm-
lung]
Datenana-
lyse
Beschreibung der empirischen Ergeb-
nisse
Buttschardt
(2017) [nicht
spezifiziert]
Mixed Me-
thod [6 Inter-
views, 64
Fragebögen]
Hypothe-
sen-Tests,
ANOVA,
deskriptive
statistische
Analyse
Untersuchung des Einflusses von Erfolgs-
faktoren auf die Qualität von Forced-Coope-
tition-Beziehungen in IT-Multi-Sourcing-Pro-
jekten; Ermittlung von kritischen Erfolgsfak-
toren
Ebert (2017)
[Automobil-
industrie]
Multiple Fall-
studie [2
Fälle, Archiv-
Projektdaten]
Fehler-Ur-
sachen-
Analyse,
quantitative
Datenana-
lyse
Erstellung und Validierung einer Checkliste
der Top 10 Risiken im Software und Service
Sourcing; Checkliste für effektives Lieferan-
ten-Beziehungs-Management entlang der
Phasen des Sourcing Zyklus
Ebert (2007)
[nicht spezifi-
ziert]
Nicht spezifi-
ziert
Nicht spezi-
fiziert
Erfolgsfaktoren für das Management von
Lieferanten-Beziehungen in GSE; Entwick-
lung von Checklisten für Supplier und
Contract Monitoring zur Vermeidung von Ri-
siken und zur Verbesserung der Lieferan-
ten-Management-Aktivitäten
Ebert et al.
(2008) [ICT]
Feldstudie
[Archiv-Pro-
jektdaten]
Nicht spezi-
fiziert
Ermittlung von Faktoren, die die Projekt-
Performance bei GSE-Projekten beeinflus-
sen; Identifikation der Top 10 Risiken, deren
Einfluss und Milderungs-Maßnahmen
Kumar/Than
gavelu
(2013) [nicht
spezifiziert]
Umfrage [338
Fragebögen]
Statistische
Datenana-
lyse
Ermittlung von Schlüsselfaktoren, die die
Partnerschafts-Qualität und den Erfolg von
GSE-Projekten beeinflussen; Wissenstrans-
fer als Schlüsselfaktor mit signifikanten Ein-
fluss; Entwicklung eines Software Outsour-
cing Service Provider Relationship-Model-
les
Oza (2006)
[nicht spezifi-
ziert]
Multiple Fall-
studie [24
Unterneh-
men, Inter-
views]
Qualitative
Datenana-
lyse, Fall-
übergrei-
fende Ana-
lyse
Ermittlung von Motivatoren und kritischen
Faktoren im Management von Software-
Outsourcing-Beziehungen und zur Vertrau-
ensbildung; Entwicklung eines Relationship
Management-Modelles und praktischer
Guidelines für das Management von Soft-
ware-Outsourcing-Beziehungen
Bapna et al.
(2010) [nicht
spezifiziert]
Nicht spezifi-
ziert [Inter-
views, Ar-
chivdaten]
Qualitative
Datenana-
lyse
Die Wahl der Anreiz- und Steuerungsme-
chanismen hängt vom Grad der Aufgaben-
Interdependenz und der Beobachtbarkeit
des Outputs ab; Entwicklung eines konzep-
tionellen Bezugsrahmens als Forschungsa-
genda; der "helfende Einsatz" des Lieferan-
165
Vgl. Hannewald et al. (2021), S. 11f.
33 Strukturierung des Forschungsstandes anhand eines konzeptionellen
Bezugsrahmens
Quelle [Bran-
chenfokus]
Forschungs-
design [Da-
tensamm-
lung]
Datenana-
lyse
Beschreibung der empirischen Ergeb-
nisse
ten ist ein Schlüsselfaktor; dyadische Per-
spektive bei Multi-Sourcing nicht ausrei-
chend
Es folgt eine Bewertung hinsichtlich der empirischen Fundierung der einzelnen Be-
zugsrahmen-Elemente. In Tabelle 6 ist erkennbar, welche Elemente durch die empiri-
schen Studien der Kernliteratur adressiert werden.
Tabelle 6: Empirische Unterstützung der Bezugsrahmen-Elemente
166
Quelle
Strategie [1]
Komplexität [2]
Krit. Faktoren [3]
Verg. Erfahrungen [4]
Forced Coop.[5]
Aufgaben-Interdep. [6]
Lieferanten-Perf. [7]
Netzwerk-Perf. [8]
LPMM Akteur [9]
LPMM Netzwerk [10]
Erfolgr. Integration [11]
Koll. Leistungen [12]
Multi-Sourcing [13]
Buttschardt
(2017)
○
○
●
○
●
○
○
○
○
○
○
○
●
Ebert (2017)
●
○
●
●
○
○
●
○
●
○
○
○
○
Ebert (2007)
◐
○
◐
◐
○
○
○
○
○
○
○
○
○
Ebert et al.
(2008)
○
○
◐
○
○
○
○
○
○
○
○
○
○
Kumar/Than
gavelu
(2013)
○
○
●
○
○
○
○
○
●
○
○
○
○
Oza (2006)
○
○
●
○
○
○
●
○
●
○
○
○
○
Bapna et al.
(2010)
○
◐
○
◐
○
◐
◐
○
○
◐
○
◐
◐
(● = empirisch belegt, ◐ = nicht ausreichend empirisch belegt, ○ = nicht empirisch belegt)
Hieraus geht hervor, dass die Empirie in der Kernliteratur noch signifikante Lücken
aufweist, insbesondere hinsichtlich der Netzwerk-Performance [8] und der erfolgrei-
chen Integration extern entwickelter Software [11]. Keine der identifizierten Studien
166
Vgl. Hannewald et al. (2021), S. 12.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 34
kann diese Konzepte mit empirischen Ergebnissen anreichern. In manchen Studien
mangelt es an einer ausreichenden Dokumentation der empirischen Vorgehensweise.
Folglich besteht auch ein Bedarf an weiteren empirischen Untersuchungen zur Kom-
plexität von Softwareentwicklungsprojekten [2], Aufgaben-Interdependenz [6], Supp-
lier Performance Management & Measurement auf Netzwerkebene [10] und zu kolla-
borativen Leistungen [12].
2.1.5 Zentrale Erkenntnisse und Forschungsbedarf
Im Rahmen der durchgeführten Literaturanalyse konnte gezeigt werden, dass die er-
mittelten Spezifika und Phänomene des vorliegenden Beschaffungskontextes in der
identifizierten Kernliteratur bisher nur unzureichend Berücksichtigung finden. Es konn-
ten zwar zwei Publikationen mit einem Netzwerkkontext ermittelt werden, jedoch liegt
in diesen Studien keine Netzwerk-Analyseebene zugrunde. Weiterhin hat die syste-
matische Literaturrecherche gezeigt, dass in Publikationen mit dyadischer Analyse-
ebene bisher keine Beziehungen zwischen Lieferanten untersucht werden. Hinsicht-
lich der gewählten Perspektive liegt in der identifizierten Kernliteratur der Fokus ten-
denziell auf der Abnehmersicht, wohingegen Studien mit Bezug auf die Lieferanten-
perspektive unterrepräsentiert sind. Lediglich vier der identifizierten Studien enthalten
konkrete Performance Metriken für Software-Lieferanten. Darunter befinden sich we-
der Metriken für das Lieferanten Performance Measurement (MES) von Software-Lie-
feranten auf Netzwerkebene noch Metriken zur Unterstützung des Integrations-Pro-
zesses. Bapna et al. (2010) stellen fest, dass es im Kontext von komplexen IT-Multi-
Sourcing-Projekten an operativen Performance-Metriken zur Unterstützung der Koor-
dination mangelt.
167
Zusammenfassend kann in der identifizierten Kernliteratur zum
LPMM bei der Beschaffung von Embedded Software der folgende Forschungsbedarf
aufgezeigt werden:
1. Mangelnde Zugrundelegung einer Netzwerk-Analyseebene,
2. Unzureichende Berücksichtigung von horizontalen Lieferanten-Beziehungen,
3. Mangelnde Perfomance-Metriken auf Netzwerkebene,
4. Unzureichende Berücksichtigung der Lieferanten-Perspektive,
167
Vgl. Bapna et al. (2010), S. 793.
35 Wissenschaftstheoretische Grundlagen
5. Fehlende Identifikation eines LPMM-Modelles, welcher die Phänomene Aufga-
ben-Interdependenz, Forced Coopetition und kollaborative Leistungen adres-
siert.
An diesen Forschungslücken wird durch das gewählte Forschungsdesign einer einge-
betteten Fallstudie im Kontext der Automobilindustrie mit zugrunde gelegter Netzwerk-
Perspektive im Rahmen dieser Dissertation angeknüpft. Diese Methodik ermöglicht
tiefgreifende Einblicke in die Lieferantensicht sowie die Untersuchung von horizontalen
Lieferanten-Beziehungen und soll in der Entwicklung eines dedizierten LPMM-Model-
les münden, welcher die o. g. Phänomene adressiert.
2.2 Wissenschaftstheoretische Grundlagen
In diesem Kapitel werden die für diese Arbeit relevanten wissenschaftstheoretischen
Grundlagen kurz vorgestellt. Die ausgewählten Theorien bilden die Grundlage für das
zu entwickelnde LPMM-Modell und liefern einen Erklärungsansatz für die bestehenden
Wirkungszusammenhänge.
Der konzeptionelle Bezugsrahmen (siehe Abbildung 6) gibt Aufschluss darüber, dass
das Lieferanten Performance Management und Measurement auf Netzwerk- und Ak-
teurs-Ebene zur Steigerung der Lieferanten-Performance eingesetzt und damit zur er-
folgreichen Integration von Embedded Software beitragen kann. Bei der Erstellung von
Performance Management-Systemen stellt die Systemabgrenzung einen wesentli-
chen Bestandteil dar.
168
Demzufolge wird bei der Entwicklung des LPMM-Modelles im
Kontext dieser Dissertation ein systemtheoretischer Ansatz zugrunde gelegt. Systeme
bestehen grundsätzlich aus Elementen, die miteinander in Beziehung stehen, was
ebenso die Basis für LPMM-Modelle darstellt.
169
Es wird dabei zwischen einer wir-
kungsorientierten, umfeldorientierten und strukturorientierten Betrachtung unterschie-
den, wobei letztgenannte essenziell für die Unternehmenssteuerung ist und die Ana-
lyse der Wirkungszusammenhänge zwischen Elementen beinhaltet.
170
Da das Hauptziel dieser Arbeit in der Entwicklung eines Modelles besteht, stellt die
Modelltheorie eine weitere wesentliche Grundlage dar. Mit Hilfe von Modellen können
168
Vgl. Kleindienst (2017), S. 31.
169
Vgl. Grochla (1978), S. 203; Vgl. Kleindienst (2017), S. 31.
170
Vgl. Kleindienst (2017), S. 31f.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 36
komplexe Systeme und Zusammenhänge vereinfacht abgebildet werden. Dadurch ge-
lingt es, die Komplexität zu verringern, die Kommunikation zu erleichtern und Zusam-
menhänge zu visualisieren.
171
Gemäß der Geschäftstypologie nach Backhaus (2014) kann die Beschaffung von Em-
bedded Software in der Automobilindustrie als Integrationsgeschäft verstanden wer-
den, da es sich um ein abnehmerspezifisches, individualisiertes Produkt handelt, wel-
ches für die Dauer des Produktlebenszyklus eines fertigen Produktes und somit in ei-
nem zeitlichen Kaufverbund, abnehmerspezifisch angeboten wird.
172
Das Integrations-
geschäft zeichnet sich insbesondere durch Individualität aus, weshalb eine vollstän-
dige Beurteilung der Leistung der Lieferanten im Voraus nicht möglich ist. Zudem er-
höht sich die Komplexität der Interaktionen, wodurch die aktive Beteiligung des Ab-
nehmers bei der Definition der Leistung unerlässlich wird.
173174
Die daraus hervorgehende Informationsasymmetrie zwischen einem Auftraggeber
(Prinzipal, hier OEM) und einem Auftragnehmer (Agent, hier Lieferant) wird durch die
Prinzipal-Agenten-Theorie beschrieben.
175
Performance Management-Systeme kön-
nen dabei helfen, Transparenz zu schaffen, die Interessen von Prinzipal und Agenten
anzugleichen und die mit Informationsasymmetrie verbundenen Ineffizienzen zu ver-
ringern.
176
Die Theorie findet nicht nur Anwendung im Performance Management-
Prozess innerhalb von Unternehmen, sondern auch im LPMM auf dyadischer sowie
auf Netzwerkebene.
177
2.2.1 Systemtheorie
Die Systemtheorie ist eine der bedeutendsten Theorien der Wissenschaft, da sie in
zahlreichen Disziplinen Anwendung findet.
178
In der Literatur existiert bislang kein ein-
heitliches Verständnis über den zentralen Begriff des Systems.
179
Wilke (2000) versteht
171
Vgl. Kleindienst (2017), S. 32.
172
Vgl. Backhaus (2014), S. 521ff.
173
Vgl. Backhaus (2014), S. 522ff.
174
Abbildung 1
175
Vgl. Kleindienst (2017), S. 32.
176
Vgl. Kleindienst (2017), S. 32.
177
Vgl. Natour et al. (2011), S. 8.
178
Vgl. Wolf (2020), S. 158.
179
Vgl. Wolf (2020), S. 159.
37 Wissenschaftstheoretische Grundlagen
-dazuge-
180
Zu den grundlegenden Bestandteilen von
Systemen gehören Elemente, welche typische Eigenschaften aufweisen, die eine Ab-
grenzung von anderen Systemen ermöglichen.
181
Außerdem sind Systeme durch eine
Vielzahl an Beziehungen zwischen Elementen, Subsystemen etc. gekennzeichnet und
weisen eine Systemstruktur auf, wodurch eine nicht vollständig zeitstabile Ordnung
existiert.
182
Dies impliziert, dass Systeme zwar ganzheitlich zu betrachten sind, jedoch
aufgrund der Veränderlichkeit von Elementen und Beziehungen unterschiedliche Sys-
temzustände annehmen können.
183
Die Festlegung der Grenze zwischen einem Sys-
tem und dessen Umfeld wird unter Berücksichtigung des Untersuchungszwecks und
Forschungsfortschritts vorgenommen.
184
Außerhalb der definierten Systemgrenzen lie-
gen andere Systeme oder Elemente, welche auch als Umfeldelemente bezeichnet
werden.
185
In Abhängigkeit davon, ob es sich um offene oder geschlossene Systeme
handelt, existieren Wechselwirkungen zwischen System und Umfeld oder nicht.
186
Sys-
temforschende halten es für wenig hilfreich, einzelne Elemente, Eigenschaften oder
Phänomene isoliert zu betrachten, sondern plädieren für eine Untersuchung des Ge-
samtgefüges an Ursachen und Bedingungen.
187
Dies wird damit begründet, dass ein-
zelne Teile des Systems ausschließlich in ihrer Funktion für das Ganze verstanden
werden können.
188
Aufgrund einer angenommenen Komplexität werden Linearität und
Widerspruchslosigkeit als fragwürdig erachtet, da es nicht möglich sei, systemimma-
nente Wirkungsbeziehungen auf einfache Gesetzmäßigkeiten zu reduzieren.
189
2.2.2 Modelltheorie
Modelle dienen im Allgemeinen der Reduktion der zu untersuchenden Realität auf die
relevanten Erklärungsvariablen und werden in der Betriebswirtschaftslehre häufig als
180
Wilke (2000), S. 51.
181
Vgl. Wolf (2020), S. 159.
182
Vgl. Wolf (2020), S. 160.
183
Vgl. Wolf (2020), S. 160.
184
Vgl. Grochla (1978), S. 204.
185
Vgl. Kleindienst (2017), S. 19.
186
Vgl. Kleindienst (2017), S. 19.
187
Vgl. Wolf (2020), S. 167.
188
Vgl. Wolf (2020), S. 167.
189
Vgl. Wolf (2020), S. 167.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 38
Instrument zur Gewinnung und Überprüfung von Erkenntnissen eingesetzt.
190
Sie wei-
sen unabhängig von deren Zielsetzung stets drei grundlegende Merkmale auf:
• Abbildungsmerkmal (Abbildung von Repräsentationen von Originalen),
• Verkürzungsmerkmal (Ausschließlich Darstellung zweckrelevanter Attribute
des Originals),
• Pragmatisches Merkmal (Zweckgebundene Verbindung zwischen Modell und
Original).
191
In der Betriebswirtschaftslehre werden Modelle häufig nach deren Anwendungszweck
in drei Modellklassen unterschieden: Beschreibungsmodelle, Erklärungsmodelle so-
wie Entscheidungsmodelle bzw. Gestaltungsmodelle.
192
Im Gegensatz zu den rein de-
skriptiven Beschreibungsmodellen, enthalten Erklärungsmodelle Hypothesen über
Wirkungszusammenhänge zwischen Variablen und können mitunter auch für Progno-
sen verwendet werden.
193
Entscheidungsmodelle beinhalten beschreibende sowie er-
klärende Elemente und ermöglichen die Bewertung von Handlungsalternativen im Hin-
blick auf eine zugrundeliegende Zielsetzung.
194
Bei dem zu entwickelnden LPMM-Mo-
dell handelt es sich um ein Entscheidungsmodell, da es von Praktizierenden zur Steu-
erung von Software-Lieferanten mit dem Ziel der Performancesteigerung genutzt wer-
den soll.
Die Modellentwicklung erfolgt im Allgemeinen über einen mehrstufigen Prozess, des-
sen genaue Ausgestaltung kontextabhängig ist: Nach der Problemidentifikation und -
eingrenzung folgt eine detaillierte Beschreibung der relevanten Systemelemente, At-
tribute und Beziehungen des ausgewählten Realitätsausschnittes. Anschließend findet
über die Definition von Modellprämissen, Elementen und Beziehungen die eigentliche
Konstruktion des Modelles statt. Dabei werden auch Entscheidungsvariablen sowie
eine Zielsetzung definiert. Im nächsten Schritt der Modellanalyse erfolgt die Auswahl
und Entwicklung der Lösungsmethode und abschließend wird das Modell validiert.
195
190
Vgl. Bardmann (2019), S. 149; Vgl. Kleindienst (2017), S. 21.
191
Vgl. Kleindienst (2017), S. 22f.
192
Vgl. Bardmann (2019), S. 149f; Vgl. Kleindienst (2017), S. 24.
193
Vgl. Kleindienst (2017), S. 24f.
194
Vgl. Kleindienst (2017), S. 25.
195
Vgl. Kleindienst (2017), S. 2527.
39 Wissenschaftstheoretische Grundlagen
2.2.3 Prinzipal-Agenten-Theorie
Die Prinzipal-Agenten-Theorie entstammt der Neuen Institutionenökonomik und hat
sich seit den 1970er Jahren zu einer eigenständigen Forschungsrichtung entwickelt.
196
Die Theorie befasst sich mit der Untersuchung und Lösung von Informationsasymmet-
rien, die in den Wirtschaftsbeziehungen zwischen einer auftraggebenden (Prinzipal)
und einer Auftrag annehmenden Partei (Agent) auftreten können.
197
Beide verfolgen
unterschiedliche Ziele und streben nach der Maximierung ihres eigenen Nutzens,
wodurch es zu opportunistischem Verhalten und Ineffizienzen kommen kann.
198
Hinsichtlich der Informationsasymmetrien wird zwischen versteckten Eigenschaften
(engl. Hidden Characteristics), versteckten Handlungen (engl. Hidden Action) und ver-
steckten Informationen (engl. Hidden Information) unterschieden.
199
Im Fall von Hidden
Characteristics liegen dem Prinzipal vor Vertragsabschluss nicht alle Informationen
über die wahren Eigenschaften des Agenten vor, weshalb es zur adversen Selektion
kommen kann.
200
Bei Hidden Action handelt es sich um Handlungsmöglichkeiten des
Agenten, die der Auftraggeber nach Vertragsabschluss nicht beobachten kann.
201
Im
Fall von Hidden Information kann der Auftraggeber die Handlungen des Agenten zwar
beobachten, jedoch nicht beurteilen, wodurch nach Vertragsabschluss ein moralisches
Risiko (engl. Moral Hazard) entstehen kann.
202
Das moralische Risiko bezeichnet die
Gefahr, dass der Agent die vorhandenen Informationsasymmetrien zu seinem Vorteil
ausnutzt.
203
Um das Risiko für opportunistisches Verhalten zu reduzieren, stehen dem
Prinzipal Informations- Kontroll- und Anreizmechanismen als Steuerungsmechanis-
men (governance mechanisms) zur Verfügung.
204
196
Vgl. Kleindienst (2017), S. 27.
197
Vgl. Kleindienst (2017), S. 28.
198
Vgl. Kleindienst (2017), S. 32.
199
Vgl. Wolf (2020), S. 365.
200
Vgl. Wolf (2020), S. 365.
201
Vgl. Kleindienst (2017), S. 29.
202
Vgl. Kleindienst (2017), S. 29.
203
Vgl. Kleindienst (2017), S. 29.
204
Vgl. Wolf (2020), S. 368.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 40
2.3 Zentrale Konzepte und Definitionen
In den folgenden Unterkapiteln werden die für das Verständnis und die angestrebte
Modellentwicklung notwendigen zentralen Konzepte und Definitionen vorgestellt.
2.3.1 Beschaffungstheoretische Grundlagen
Zunächst erfolgt eine Abgrenzung der für das Verständnis notwendigen beschaffungs-
relevanten Begrifflichkeiten. Die Beschaffung stellt das erste Glied in der Wertschöp-
fungskette dar und umfasst folglich Prozesse, die der Produktion und dem Vertrieb
vorgelagert sind.
205
Im Allgemeinen kann unter dem Begriff der Beschaffung die Ver-
sorgung eines Betriebes mit den erforderlichen Gütern, Ressourcen und Dienstleistun-
gen verstanden werden, wobei dies gemäß vorab definierter Mengen, Art, Zeit und
Qualität erfolgen soll.
206
Während bei der Beschaffung der Wertschöpfungsfluss im Fo-
kus der Betrachtung steht, beinhaltet der objektorientierte Begriff der Materialwirtschaft
alle betriebswirtschaftlichen Tätigkeiten, welche die Art der zu beschaffenden Güter
und Materialien betreffen und berücksichtigt zudem Lagerhaltungs- und Entsorgungs-
prozesse.
207
Der Einkauf beschränkt sich als Teilprozess der Beschaffung lediglich auf
die rein operative Bestellabwicklung, wohingegen die Beschaffung auch eine strategi-
sche Komponente umfasst.
208
Bei dem Beschaffungsmanagement oder auch Supply Management sind neben der
Optimierung unternehmensinterner Beschaffungsprozesse auch Tätigkeiten relevant,
die zur Verbesserung der Lieferantenbeziehungen erforderlich sind.
209
Dies wird häufig
in Form einer aktiven, mit der Unternehmensstrategie in Einklang gebrachten Liefe-
rantensteuerung umgesetzt.
210
Zu den strategischen Zielen der Beschaffung zählen
neben Wirtschaftlichkeit, Sicherheit, Flexibilität und Liquidität auch die Produktqualität,
welche durch Qualitätsvorgaben und -kontrollen sichergestellt werden kann.
211
Auch
205
Vgl. Weber et al. (2018), S. 165; Vgl. Bea et al. (1994), S. 10.
206
Vgl. Wannenwetsch (2021), S. 111.
207
Vgl. Weber et al. (2018), S. 166; Vgl. Bea et al. (1994), S. 14.
208
Vgl. van Weele/Eßig (2017), S. 20.
209
Vgl. van Weele/Eßig (2017), S. 20.
210
Vgl. van Weele/Eßig (2017), S. 20.
211
Vgl. Weber et al. (2018), S. 175,168.
41 Zentrale Konzepte und Definitionen
der Einsatz von LPMM-Modellen kann zur Umsetzung dieser strategischen Beschaf-
fungsziele beitragen (siehe Kapitel 2.3.2).
Gemäß der Klassifikation von van Weele/Eßig (2017)
212
lassen sich verschiedene Ar-
ten von Beschaffungsobjekten unterscheiden, z. B. Rohstoffe, Bauteile, Fertigerzeug-
nisse, Investitionsgüter oder Dienstleistungen. Dienstleistungen werden in einer Inter-
aktion zwischen zwei Unternehmen erbracht und unterscheiden sich im Wesentlichen
hinsichtlich ihrer Intangibilität, Heterogenität, Gleichzeitigkeit und Vergänglichkeit von
Sachleistungen.
213
Auch der Einkauf von Softwareentwicklungsleistungen wie bei-
spielsweise für das hier betrachtete Beschaffungsobjekt Embedded Software, kann als
Dienstleistung verstanden werden.
214
Besonderheiten ergeben sich u. a. bei der Beur-
teilung der Qualität von Dienstleistungen, da diese nicht vor Vertragsabschluss erfol-
gen kann.
215
Aus diesem Grund besteht die Notwendigkeit, bei Vertragsabschluss eine
Einigung bezüglich geeigneter Kriterien, anhand deren die Qualität angemessen beur-
teilt werden kann, zu erzielen.
216
2.3.2 Grundlagen Lieferanten Performance Management & Measurement
Einen elementaren Bestandteil des auf Abbildung 7 dargestellten Beschaffungs-
prozesses stellt die Lieferantenbewertung dar.
Abbildung 7: Schnittstellen zwischen Beschaffungsmanagement und Performance Manage-
ment
217
212
Vgl. van Weele/Eßig (2017), S. 31f.
213
Vgl. van Weele/Eßig (2017), S. 120f.
214
Vgl. van Weele/Eßig (2017), S. 123.
215
Vgl. van Weele/Eßig (2017), S. 129.
216
Vgl. van Weele/Eßig (2017), S. 129.
217
in Anlehnung an van Weele/Eßig (2017), S. 50.
Festlegung der
Spezifikationen Lieferanten-
auswahl Vertragsab-
schluss Bestellung Terminüber-
wachung Evaluierung
Funktionale
Spezifikation
Technische
Verände-
rungen
Qualifi-
zierung
potenzieller
Lieferanten
Einholen von
Angeboten
Vertrags-
rechtliche
Kenntnisse
Ver-
handlungs-
geschick
Bestell-
verfahren
entwickeln
Bestell-
abwicklung
Terminüber-
wachung
Problem-
behandlung
Lieferanten-
bewertung
Lieferanten-
einstufung
Theoretischer Hintergrund für die angestrebte Modellentwicklung 42
Da dieser Prozess sowohl ex-ante als auch ex-post Vertragsabschluss greift und
ebenso Monitoring-Elemente aufweist, werden die farbig markierten Prozessschritte
hier als Schnittstellenbereiche zwischen dem Beschaffungsmanagement und dem
LPMM betrachtet.
218
Bei dem Performance-Begriff handelt es sich um ein multidimensionales Konzept,
welches die Beurteilung von Organisationseinheiten ermöglicht und dabei nicht nur
das Ergebnis als solches, sondern auch die dafür erforderlichen Abläufe und Prozesse
umfasst.
219
Der Begriff unterlag im Laufe der Jahrzehnte einer stetigen Erweiterung und
schließt neben Effizienz und Effektivität mittlerweile weitere Leistungsmerkmale wie
Flexibilität oder Nachhaltigkeit ein.
220
In der Literatur wird eine große Anzahl von Leis-
tungsindikatoren diskutiert, die in der Regel unterschiedlicher Natur sind (qualitative
vs. quantitative Indikatoren) und sich auf verschiedene Kategorien von Kennzahlen
(z. B. finanzielle und operative Kennzahlen) und unterschiedliche Messebenen (z. B.
Prozess, Unternehmen, Lieferkette) beziehen.
221
Prahinski/Benton (2004) definieren Lieferanten-Performance als ein quantifizierbares
Maß für die wichtigsten Erfolgsfaktoren im Wettbewerb, wie beispielsweise Produkt-
qualität, Liefertreue und Preis.
222
Um die Begriffe MAN und MES tiefgründiger verste-
hen und abgrenzen zu können, ist eine Analyse bestehender Definitionen durchgeführt
worden.
223
-
Suche nach dem Such-
D (definition OR defined OR taxonomy)) durchgeführt.
Aus insgesamt elf identifizierten Studien wurden Definitionen für MAN und MES extra-
hiert, in ihre Bestandteile zerlegt und anschließend zu Kernelementen bzw. -funktionen
zusammengefasst.
In Tabelle 7 sind die drei identifizierten MES-Definitionen dargestellt. Bei Betrachtung
der Definitionen fällt auf, dass das MES grundlegend als ein Messinstrument für die
218
Vgl. Ebert (2007), S. 180.
219
Vgl. Kleindienst (2017), S. 34f.
220
Vgl. Tangen (2004), S. 45.
221
Vgl. Lefebre et al. (2010), S. 3.
222
Vgl. Prahinski/Benton (2004), S. 43.
223
Die Erkenntnisse der Definitions-Analyse werden im Wesentlichen aus Hannewald et al. (2021), S.
35 entnommen.
43 Zentrale Konzepte und Definitionen
Lieferanten-Performance zu verstehen ist, welches durch die Definition von Zielgrößen
die Funktion der Erfolgsbeitragsorientierung erfüllt. Außerdem wird das Konzept als
Feedback- und Entscheidungsunterstützungsinstrument eingesetzt.
Tabelle 7: Definitionen Lieferanten Performance Measurement
224
Quelle
Definition
MES-Elemente
Connor et al.
(2020), 3
toring are important formal control mechanisms in
B2B relationships, which customers use to guide
supplier evaluations and give feedback as well as to
make purchase order allocation and ongoing
Messung, Evalua-
tion, Feedback,
Entscheidungs-un-
terstützung
Maestrini et
al. (2018a),
S. 2042
the implementation of strategy at various levels, the
goal of an SPMS is to support the purchasing stra-
tegy and align buyer-supplier relationships towards
Zielsetzung, Krite-
rien, Messung
Parkash/Kau
shik (2011a),
S. 12
choosing desired performance measures and gene-
lier performance measurement (SPM) is a mecha-
nism to track supplier progress towards meeting or-
ganizational goals, & gives feedback to the supplier
Zielsetzung, Krite-
rien, Messung
Bezüglich MAN wurden insgesamt acht Definitionen
225
identifiziert, welche hinsichtlich
der enthaltenen Bestandteile eine hohe Heterogenität aufweisen. Exemplarisch wur-
den daraus drei Definitionen ausgewählt, welche sich stark voneinander unterscheiden
und somit den gesamten Umfang der identifizierten Kernelemente repräsentieren
(siehe Tabelle 8).
Die Analyse aller identifizierten Definitionen gibt Aufschluss darüber, dass die Publi-
zierenden unter MAN eine umfassende Methode zur Messung und Steigerung der Lie-
feranten-Performance verstehen. Neben den zuvor genannten MES-Elementen um-
fasst das MAN zahlreiche weitere Funktionen. Eine Erfolgsbeitragsorientierung
226
kann
224
in Anlehnung an Hannewald et al. (2021), S. 4.
225
Jiang/Bai (2010), S. 1409; Hawkins (2016), S. 1; Nsowah et al. (2017), S. 3; Parkash/Kaushik (2011b),
S. 12; Qian Li et al. (2017), S. 118; Sanei et al. (2011), S. 11; Adesanya et al. (2020), S. 416; Day (2014),
S. 33.
226
Vgl. Hawkins (2016), S. 7.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 44
hier vor allem aufgrund des Anspruches zur Steigerung der Lieferantenleistung und
der kontinuierlichen Verbesserung festgestellt werden. Als MAN-spezifische Funktio-
nen wurden zudem Problemverständnis
227
, Kontrolle und Überwachung
228
, Steuerung
und Rekalibrierung
229
, Beziehungsentwicklung
230
sowie Risikominderung
231
ermittelt.
Tabelle 8: Definitionen Lieferanten Performance Management
232
Quelle
Definition
MAN-Elemente
Adesanya et
al. (2020), S.
416
measure, analyse and report supplier performance
nuous improvement. An important part of this pro-
cess is to provide suppliers with evaluation feedback
Messung, Analyse,
Feedback, Korrek-
turmaßnahmen,
Performancestei-
gerung
Nsowah et al.
(2017), S. 3
of procurement concerned with streamlining the
supplier base and selecting, coordinating, appraising
the performance of suppliers and building long term
as an important part of supplier performance ma-
nagement. [11] also assert that the main aim of the
supplier performance assessment is to lessen the
risk related to purchase and maximize the overall va-
lue o
Messung, Evalua-
tion, Analyse, Mo-
nitoring, Zusam-
menarbeit, Risi-
kominderung, Per-
formancesteige-
rung
Parkash/Kau
shik (2011a),
S. 12
widely adopted as a method to understand and im-
mary areas: Factor & Criteria, Weighting, Rating
Scale, Ease of Use and Effectiveness in providing
data for decision-making, Share results with supp-
liers and stakeholders, Review and recalibrate per-
Analyse, Perfor-
mancesteigerung,
Kriterien, Review &
Rekalibrierung,
Feedback, Ent-
scheidungsunter-
stützung
Die Definitionsanalyse hat gezeigt, dass eine der wesentlichen Funktionen von LPMM
in der Erfolgsbeitragsorientierung liegt, was über die Definition von kontextspezifischen,
227
Vgl. Adesanya et al. (2020), S. 416.
228
Vgl. Nsowah et al. (2017), S. 3.
229
Vgl. Parkash/Kaushik (2011a), S. 12.
230
Vgl. Jiang/Bai (2010), S. 1409.
231
Vgl. Hawkins (2016), S. 7.
232
in Anlehnung an Hannewald et al. (2021), S. 4.
45 Zentrale Konzepte und Definitionen
strategischen Zielgrößen, und operativen Messgrößen erreicht wird.
233
Ebenso sind
dabei Prozesse zur Sicherstellung einer kontinuierlichen Leistungsverbesserung von
Relevanz.
234
In Summe wurden daraus die folgenden Kernelemente für das LPMM ab-
geleitet:
• Übergeordnete Strategie & Zielsetzung
235
• Kriterien & Messung
236
,
• Monitoring
237
,
• Analyse & Evaluation
238
,
• Feedback
239
,
• Korrekturmaßnahmen
240
,
• Review & Rekalibrierung
241
,
• Entscheidungsunterstützung
242
.
Trotz des umfangreichen Literaturbestandes hat sich bislang keine allgemeingültige
bzw. allumfassende Definition für das Konzept des LPMM etabliert. Die Publizierenden
stützen sich in ihren zugrunde gelegten Definitionen stets auf verschiedene Primär-
quellen und es scheint hinsichtlich der Relevanz der einzelnen Funktionen und Ele-
mente eine starke Kontextabhängigkeit vorzuliegen.
243
Weiterhin kann festgestellt wer-
den, dass analog zur Performance Management-Literatur, das MAN ein dem MES
übergeordnetes Konzept darstellt.
244
Auch hier kann das Performance Measurement
als elementarer Bestandteil im Performance Management-Prozess und damit als Mit-
tel zur Zielerreichung verstanden werden.
245
233
Vgl. Hawkins (2016), S. 1; Vgl. Maestrini et al. (2018c), S. 298; Vgl. Qian Li et al. (2017), S. 118.
234
Vgl. Qian Li et al. (2017), S. 118; Vgl. Hawkins (2016), S. 1.
235
Vgl. Parkash/Kaushik (2011a), S. 12; Vgl. Maestrini et al. (2018c), S. 298.
236
Vgl. Hawkins (2016), S. 1; Vgl. Nsowah et al. (2017), S. 3.
237
Vgl. Nsowah et al. (2017), S. 3; Vgl. Connor et al. (2020), 3.
238
Vgl. Jiang/Bai (2010), S. 1409; Vgl. Hawkins (2016), S. 1.
239
Vgl. Parkash/Kaushik (2011a), S. 11; Vgl. Parkash/Kaushik (2011b), S. 2.
240
Vgl. Jiang/Bai (2010), S. 1409; Vgl. Adesanya et al. (2020), S. 416.
241
Vgl. Parkash/Kaushik (2011a), S. 13.
242
Vgl. Connor et al. (2020), 3; Vgl. Jiang/Bai (2010), S. 1409.
243
Vgl. Hannewald et al. (2021), S. 5.
244
Vgl. Hannewald et al. (2021), S. 5.
245
Vgl. Amaratunga/Baldry (2002), S. 218; Vgl. Smith/Goddard (2002), S. 248.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 46
In der Wissenschaft wird LPMM seit den 1990er Jahren umfassend diskutiert und da-
bei innerhalb verschiedener Literaturströmungen aufgegriffen.
246
Ein Großteil der Lite-
ratur befasst sich mit der Performance-Messung und der Lieferantenbeurteilung als
solche.
247
Dabei werden im Wesentlichen die Definition und Bewertung von Lieferan-
tenauswahl- und Evaluations-Kriterien und -methoden sowie die Entwicklung von
LPMM-Modellen und -Systemen adressiert.
248
Einen weiteren Aspekt des LPMM stellt
die Forschungsströmung Lieferantenentwicklung (engl. Supplier Development) dar,
wobei der Fokus auf Lieferantenentwicklungs- sowie Qualitäts- und Leistungsverbes-
serungsmaßnahmen und -methoden liegt.
249
Als Analyseobjekte können sowohl ein-
zelne Lieferanten als auch Lieferanten-Abnehmer-Beziehungen sowie ganze Liefer-
ketten fungieren.
250
Im Rahmen der Supply Chain Performance Management-Litera-
tur fokussieren sich die Publizierenden auf die Entwicklung ganzheitlicher Bezugsrah-
men, Methoden, Modelle und Metriken
251
sowie auf ausgewählte Aspekte wie das Ri-
sikomanagement oder Nachhaltigkeit.
252
2.3.3 Performance Management & Measurement im Netzwerk-Kontext
Unter einem Netzwerk ist im Allgemeinen eine Ansammlung von Knoten und Verbin-
dungen zu verstehen, wobei die Knoten Akteure und die Verbindungen Beziehungen
zwischen Akteuren repräsentieren.
253
Kenis/Provan (2009) definieren ein Netzwerk wie
folgt:
three or more organizations that consciously agree to coordinate and colla-
borate with one another, are used to deliver services, address problems and op-
portunities, transmit information, innovate, and acquire needed resources".
254
246
Vgl. Maestrini et al. (2018c), S. 299; Vgl. Bourne et al. (2018), S. 2010; Vgl. Sundtoft Hald/Ellegaard
(2011), S. 889.
247
Vgl. Maestrini et al. (2018a), S. 2041.
248
Ho et al. (2010); Imeri (2013); Keshavarz Ghorabaee et al. (2017); Patil/Gogte (2016); Patil (2014);
Simpson et al. (2002); Thanaraksakul/Phruksaphanrat (2009); Maestrini et al. (2018c).
249
AlMaian (2014); Noshad/Awasthi (2015); Shokri et al. (2010); Tungjitjarurn et al. (2012);
Lukhoba/Muturi (2015); Modi/Mabert (2007); Jiang/Bai (2010).
250
Vgl. Sundtoft Hald/Ellegaard (2011), S. 889.
251
Ramaa et al. (2009); Cuthbertson/Piotrowicz (2011); Chan et al. (2003); Sanei et al. (2011).
252
Shaw et al. (2010); Ritchie/Brindley (2007); Ritchie et al. (2008).
253
Vgl. Brass et al. (2004), S. 795.
254
Kenis/Provan (2009), S. 440.
47 Zentrale Konzepte und Definitionen
Solche Netzwerke können im öffentlichen, gemeinnützigen und geschäftlichen Sektor
vorkommen.
255
Die Zielvariable Performance kann im Kontext von Netzwerken auf
vier verschiedenen Ebenen gemessen werden: auf der individuellen Ebene, der Grup-
pen-, Unternehmens- oder Netzwerkebene.
256
Die Netzwerk-Performance kann laut
Straub et al. (2004) als die Leistung einer Gruppe vernetzter Firmen oder eines Fir-
mensystems betrachtet werden.
257
Dabei findet eine Aggregation des Outputs auf Un-
ternehmensebene zu einer Netzwerkkonfiguration statt.
258
Im Kontext dieser Dissertation wird der Begriff Software-Lieferanten-Netzwerk wie
folgt definiert: Die Gesamtheit aller Software-Lieferanten sowie Hardware-Lieferanten
mit Integrationsverantwortung, welche im Rahmen von Embedded-Software-Entwick-
lungsprojekten zusammenarbeiten und eine direkte Beziehung
259
mit dem Abnehmer
(OEM) haben. Aufgrund des zu untersuchenden Netzwerkkontextes werden Sub-Lie-
feranten von 1st Tier-Lieferanten, zu denen kein direkter Kontakt seitens OEM besteht,
im Rahmen dieser Arbeit nicht berücksichtigt. Um die zuvor beschriebene netzwerkar-
tige Lieferantenstruktur abbilden zu können, wird im Rahmen dieses Forschungsvor-
habens eine Netzwerk-Analyseebene zugrunde gelegt. Es wird folglich nicht nur die
individuelle Firmen-Leistung
260
der Lieferanten, sondern auch die aggregierte Netz-
werk-Performance aller Zulieferer betrachtet.
Gemäß der Definition von Kenis/Provan (2009) basieren Netzwerke auf Freiwilligkeit
und stellen bewusste Zusammenschlüsse von Unternehmen dar, was auf den vorlie-
genden Beschaffungskontext nicht zutrifft.
261
Der hier betrachtete Untersuchungskon-
text ist durch netzwerkartige Strukturen gekennzeichnet, welche jedoch nicht als frei-
willige, auf Dauer angelegte Zusammenschlüsse von Firmen zu verstehen, sondern
von transaktionalen Beziehungen und Wettbewerb geprägt sind. Dennoch ist davon
255
Vgl. Kenis/Provan (2009), S. 440.
256
Vgl. Straub et al. (2004), S. 87.
257
Vgl. Straub et al. (2004), S. 87.
258
Vgl. Straub et al. (2004), S. 87.
259
Direkte Beziehung kann folgendes bedeuten: Direktes Vertragsverhältnis zwischen Lieferant und
OEM oder Nominierung bzw. Vorgabe der Zusammenarbeit durch OEM oder direkte Kommunikation
zwischen Lieferant und OEM.
260
Diese wird im Folgenden als Lieferanten-Performance auf Akteurs-Ebene bezeichnet.
261
Vgl. Kenis/Provan (2009), S. 440.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 48
auszugehen, dass die Literaturströmung Netzwerk Performance Management wert-
volle Impulse für das zu entwickelnde LPMM-Modell liefern kann.
Folglich wurde eine systematische Literaturrecherche im Bereich Netzwerk Perfor-
mance Management in Anlehnung an Tranfield et al. (2003) in sechs ausgewählten
Datenbanken durchgeführt (siehe Abbildung 8).
262
Im Zuge der Literaturrecherche
konnten insgesamt 18 englischsprachige frei zugängliche Quellen aus den Jahren
2004 bis 2018 identifiziert werden. Diese wurden umfassend hinsichtlich der folgenden
Aspekte untersucht, welche dabei als Analyseraster fungierten:
• Netzwerkspezifische Anforderungen in Bezug auf die Gestaltung und Umset-
zung eines LPMM-Modelles,
• Netzwerkspezifische LPMM-Modellelemente,
• Netzwerkspezifische LPMM-Kriterien und -Dimensionen für das MES,
• Impulse bezüglich der LPMM-Modellgestaltung und der Prozessabläufe.
Abbildung 8: Vorgehensweise bei der konsekutiven Literaturrecherche
263
262
Vgl. Tranfield et al. (2003), S. 214219.
263
Eigene Darstellung.
49 Zentrale Konzepte und Definitionen
Innerhalb der Netzwerk Performance Management-Literatur werden hauptsächlich
öffentliche Netzwerke
264
sowie kollaborative Netzwerke
265
bzw. Versorgungsnetz-
werke
266
im Unternehmenssektor adressiert.
Außerdem stellen strategische Netzwerke
267
sowie Tourismusnetzwerke
268
den Unter-
suchungsgegenstand zweier Veröffentlichungen dar. Untersucht werden u. a. Zusam-
menhänge verschiedener Faktoren mit dem Konstrukt der Netzwerk-Performance
269
,
sowie Erfolgsgrößen von kollaborativen Netzwerken und deren Bewertung.
270
Analog
zur LPMM-Literatur befassen sich die Publizierenden ebenso mit der Entwicklung von
Methoden
271
, Modellen
272
, Prozessen
273
und Bezugsrahmen
274
im Zusammenhang mit
dem Netzwerk Performance Management und Measurement. Ein Bezug zum Beschaf-
fungsobjekt Software kann lediglich bei Bonatto et al. (2017) festgestellt werden: Die
Autorenschaft entwickelt ein Modell zur Bewertung der Effektivität der Performance-
Messung in horizontalen Netzwerken auf individueller und kollektiver Ebene und im-
plementieren dies in einem Netzwerk innerhalb der Branche für Informations- und
Kommunikationstechnologie (ICT).
275
In Anhang A sind alle identifizierten Quellen in-
klusive Netzwerkart, der angewandten Methodik und einem Auszug des Beitrags, den
sie im Rahmen dieser Dissertation liefern, aufgelistet.
Bei dem multidimensionalen Konstrukt der Netzwerk-Performance findet in der Litera-
tur eine kontroverse Diskussion hinsichtlich der Eignung verschiedener Ansätze und
Herangehensweisen zur Performance-Messung auf Netzwerkebene statt.
276
Das lässt
sich u. a. auf die derzeitige Unkenntnis über die treibenden Faktoren zurückführen,
264
Agostino/Arnaboldi (2018); Herranz (2010); Heranz (2010); Kenis/Provan (2009).
265
Sena Ferreira et al. (2012); Ferreira et al. (2011); Klijn/Koppenjan (2014); Mandell/Keast (2007);
Parung/Bititci (2008); Pekkola/Ukko (2016); Verdecho et al. (2011).
266
Bonatto et al. (2017); Straub et al. (2004); José Alfaro Saiz et al. (2007); Bayne et al. (2017);
Alnatour/Gibson (2011); Vesalainen et al. (2017).
267
Bayne et al. (2017).
268
Pyo (2010).
269
Herranz (2010); Heranz (2010); Alnatour/Gibson (2011).
270
Mandell/Keast (2007); Parung/Bititci (2008); Straub et al. (2004).
271
Ferreira et al. (2011); Verdecho et al. (2011).
272
Bonatto et al. (2017); Pyo (2010); José Alfaro Saiz et al. (2007).
273
Mandell/Keast (2007).
274
Agostino/Arnaboldi (2018); Heranz (2010); Vesalainen et al. (2017); Bayne et al. (2017).
275
Vgl. Bonatto et al. (2017), S. 10.
276
Vgl. Bayne et al. (2017), S. 134; Vgl. Kenis/Provan (2009), S. 443f; Vgl. Straub et al. (2004), S. 92.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 50
welche die Netzwerk-Performance und deren Messung bestimmen.
277
Bonatto et al.
(2017) stoßen im Rahmen ihrer Studie auf die beiden folgenden Lücken in der Netz-
werk Performance Management-Forschung: Es fehle einerseits an einem flexiblen
Modell zur Performance-Analyse horizontaler Business-Netzwerke und andererseits
an einem Modell, welches die Bewertung auf Unternehmens- und Netzwerkebene ge-
währleistet.
278
Straub et al. (2004) definieren die networked organizational performance
als die Leistung einer Reihe vernetzter Organisationen oder eines Systems von Unter-
nehmen, die sowohl als Aggregation der Einzelfirmen-Outputs als auch direkt über
netzwerkspezifische Ergebnisgrößen erhoben werden kann.
279
Kenis/Provan (2009)
kritisieren eine unzureichende Definition und Operationalisierung des Konzeptes der
Netzwerk-Performance.
280
Die Autorenschaft stellt fest, dass jede Entscheidung über
Kriterien, die bei der Bewertung der Netzwerk Performance verwendet werden, einen
normativen Charakter hat. Sie vertreten außerdem die Ansicht, dass grundsätzlich je-
des Kriterium, wie beispielsweise Wachstum, Gewinnstabilität und Resilienz, zur Mes-
sung herangezogen werden könne.
281
Zu den in der Literatur am häufigsten genannten
Netzwerk-Performance-Kriterien zählen Effizienz, Effektivität und Zielerreichung.
282
Kenis/Provan (2009) argumentieren außerdem, dass nicht jedes Kriterium gleicherma-
ßen für die Performance-Messung eines Netzwerkes geeignet sei und ermitteln drei
exogene Faktoren, welche zwar entscheidend für die Eignungs-Prüfung von Kriterien
sind, jedoch nicht der Kontrolle der Netzwerkmitglieder unterliegen. Dabei geht es um
die Art der Gründung (freiwillig vs. verpflichtend), die Form der Steuerung sowie das
Entwicklungsstadium eines Netzwerkes.
283
Folglich können Netzwerke selbst unter
277
Vgl. Bonatto et al. (2017), S. 2.
278
Vgl. Bonatto et al. (2017), S. 2.
279
Vgl. Straub et al. (2004), S. 87.
280
Vgl. Kenis/Provan (2009), S. 441.
281
Vgl. Kenis/Provan (2009), S. 443.
282
Vgl. Kenis/Provan (2009), S. 443.
283
Vgl. Kenis/Provan (2009), S. 444446.
51 Zentrale Konzepte und Definitionen
den besten endogenen Bedingungen schlechte Leistungen erbringen, wenn diese an-
hand ungeeigneter Kriterien bewertet werden.
284
Trotz der genannten Herausforderun-
gen ist das Verständnis der Netzwerk-Performance für das Management von großem
Nutzen in Hinblick auf die erfolgreiche Zielerreichung von Netzwerken.
285
2.3.4 Spezifika des Beschaffungskontextes
Der entwickelte konzeptionelle Bezugsrahen gibt Aufschluss darüber, dass im hier vor-
liegenden Beschaffungskontext die Phänomene Aufgaben-Interdependenz
286
und
Forced Coopetition
287
sowie kollaborative Leistungen
288
von Relevanz sind und speziell
für den untersuchten Anwendungsfall automobiler Embedded Software eine Heraus-
forderung für das Management von Software-Lieferanten darstellen.
289
Eine Besonder-
heit bei der Beschaffung von Embedded Software in der Automobilindustrie liegt im
derzeit hohen Anteil der Softwareentwicklung durch externe Lieferanten.
290
Bedingt
durch die beschriebene hoch komplexe Softwarearchitektur im Fahrzeug sowie den
damit einhergehenden technischen und funktionalen Abhängigkeiten weist der hier
vorliegende Beschaffungskontext netzwerkartige Strukturen auf, wobei ein hohes Maß
an Zusammenarbeit zwischen den an der Softwareentwicklung beteiligten Akteuren
erforderlich ist. Hinzu kommt der zunehmende Einsatz von Multi-Sourcing-Modellen
Blackbox-Einkaufs integrierter Hardware-Software-
Bündel bei einem 1st Tier-Lieferanten. Die netzwerkartige Struktur führt zu neuen An-
forderungen an das Lieferanten Performance Management (MAN), insbesondere
durch das Auftreten der Phänomene Aufgaben-Interdependenz und Forced Coopeti-
tion und kollaborativen Leistungen.
In den folgenden Kapiteln wird eine Definition und Einordnung dieser Phänomene in
den Untersuchungskontext vorgenommen. Eine Zusammenfassung der wesentlichen
Charakteristiken kann Tabelle 9 entnommen werden.
284
Vgl. Kenis/Provan (2009), S. 444.
285
Vgl. Bayne et al. (2017), S. 134.
286
Vgl. Bapna et al. (2010), S. 790.
287
Vgl. Buttschardt (2017), S. 43.
288
Vgl. Bapna et al. (2010), S. 786.
289
Vgl. Buttschardt (2017), S. 1; Vgl. Bapna et al. (2010), S. 786.
290
Vgl. Staron (2017), S. 5.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 52
Tabelle 9: Charakteristika der zu untersuchenden Phänomene
291
Forced Coopetition
Aufgaben-Interdependenz
Kollaborative Leistungen
• Ambivalenz zwischen
Wettbewerb und
erzwungener Zusam-
menarbeit zwischen
Lieferanten,
• Wettbewerbsinduzierte
Spannungen zwischen
Lieferanten.
• Abhängigkeiten
zwischen Input- und
Output-Faktoren,
• Geteilte Ressourcen
und Aktivitäten,
• Wechselwirkungen bei
der Leistungserstellung,
• Koordinationsbedarf.
• Unterstützung anderer
Lieferanten bei der Leis-
tungserstellung
(Hilfsleistungen),
• Unbezahlter Zusat-
zaufwand in Form von
Informationen, Kommu-
nikation, Know-How,
Ressourcen und Ser-
viceleistungen.
2.3.4.1 Forced Coopetition
Forced Coopetition stellt als bislang wenig erforschtes Paradigm einen Spezialfall von
Coopetition dar, was seit den späten 1990er Jahren auf inner- und zwischenbetriebli-
cher sowie auf Netzwerkebene erforscht wird.
292
Im Unterschied zu Forced Coopetition
wird darunter die simultane Existenz von Kooperation und Wettbewerb zwischen min-
destens zwei Akteuren auf freiwilliger Basis verstanden.
293
Im Rahmen einer systema-
tischen Literaturrecherche identifizieren Dorn et al. (2016) die folgenden fünf For-
schungsbereiche im Forschungsfeld Coopetition Management: Art und Output der Be-
ziehungen, Steuerungsmechanismen und Management, Akteurs-Charakteristiken so-
wie Umwelt-Aspekte.
294
Wilhelm (2011) unterscheidet hier lediglich zwischen zwei Li-
teraturströmungen: Coopetition im engeren Sinne, wobei es im Wesentlichen um die
Art und Weise der Zusammenarbeit zwischen Wettbewerbern geht, sowie Coopetition
im weiteren Sinne, wobei die dabei auftretenden Spannungen den Untersuchungsge-
genstand darstellen.
295
Im Rahmen einer vergleichenden Fallstudie zu coopetitiven Business-Netzwerken un-
tersucht Tidström (2014) die Arten von Spannungen, die im Rahmen von coopetitiven
Beziehungen auftreten können, sowie geeignete Strategien für das Management die-
ser Spannungen in Abhängigkeit von der Art der vorliegenden Coopetition (freiwillig
oder induziert). Der Publizierende klassifiziert die bislang untersuchten Spannungen
291
Eigene Darstellung.
292
Wiener/Saunders (2014); Vgl. Dorn et al. (2016), S. 3.
293
Vgl. Wiener/Saunders (2014), S. 213; Vgl. Dorn et al. (2016), S. 2.
294
Vgl. Dorn et al. (2016), S. 2.
295
Vgl. Wilhelm (2011), S. 665.
53 Zentrale Konzepte und Definitionen
wie folgt: Spannungen in Bezug auf unklare Rollen oder Zielkonflikte, Wissenstransfer,
Macht und Abhängigkeit sowie Opportunismus.
296
Die Studie hat gezeigt, dass Wett-
bewerb und Vermeidung zu den am häufigsten genutzten Strategien im Umgang mit
Spannungen zählen und dass sich die gewählten Management-Strategien in coopeti-
tiven Beziehungen von denen in rein kooperativen Verhältnissen unterscheiden kön-
nen.
297
Tidström (2014) weist außerdem auf das Potenzial von Vertrauen hin, Span-
nungen zu reduzieren und Konflikte zu bewältigen und konstatiert dahingehend weite-
ren Forschungsbedarf.
298
Die auftretenden Spannungen können je nach Stärke der
Coopetition ebenso in ihrem Ausmaß variieren und die Performance beeinflussen.
299
Salvetat/Géraudel (2012) untersuchen anhand der Social Network-Theorie die ver-
mittelnde Rolle von dritten Akteuren in coopetitiven Beziehungen.
300
Pathak et al. (2014)
nehmen eine Klassifikation von vier Versorgungsnetzwerk-Archetypen im Kontext von
coopetitiven Dynamiken vor: Gemeinschaft, Verband, Konsortium und Hierarchie.
301
Die Publizierenden charakterisieren diese hinsichtlich der inhärenten Beziehungen,
Kooperations- und Wettbewerbsaktivitäten, Zielen auf Netzwerkebene und einer ge-
eigneten Steuerung.
302
Im hier vorliegenden Untersuchungskontext handelt es sich um
eine Hierarchie, wobei das übergeordnete Ziel in der Erfüllung von Aufträgen des End-
kunden liegt. Die bei der Leistungserstellung kooperierenden Unternehmen konkurrie-
ren gleichzeitig um die Vormachtstellung in der Lieferkette oder den Zugang zu ge-
meinsam genutzten Ressourcen.
303
Die Steuerung erfolgt durch einen führenden Kun-
den oder Lieferanten hauptsächlich anhand von vertraglichen Regelungen.
304
Wu et al. (2010) untersuchen die Bedeutung des aktiven Managements coopetitver
Lieferanten-Lieferanten-Beziehungen für die Lieferanten-Performance aus Abnehmer-
sicht und legen dabei eine triadische Perspektive zugrunde.
305
Auch Wilhelm (2011)
296
Vgl. Tidström (2014), S. 262.
297
Vgl. Tidström (2014), S. 270.
298
Vgl. Tidström (2014), S. 263.
299
Vgl. Bengtsson et al. (2016), S. 3.
300
Salvetat/Géraudel (2012).
301
Vgl. Pathak et al. (2014), S. 256.
302
Vgl. Pathak et al. (2014), S. 257.
303
Vgl. Pathak et al. (2014), S. 257.
304
Vgl. Pathak et al. (2014), S. 257.
305
Vgl. Wu et al. (2010), S. 115.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 54
weist auf die Notwendigkeit hin, im Fall von Coopetition-Netzwerken neben vertikalen
Lieferanten-Abnehmer-Beziehungen auch horizontale Lieferanten-Beziehungen ge-
zielt zu analysieren und zu steuern und stellt damit eine Verbindung zwischen der dya-
dischen und der Netzwerk-Analyseebene her.
306
Dies gelingt durch die Analyse der In-
teraktionen innerhalb von Triaden und der gleichzeitigen Betrachtung von Ausbrin-
gungs-Größen auf Netzwerkebene.
307
Der Spezialfall der Forced Coopetition wird von Wiener/Saunders (2014) wie folgt de-
finiert:
a situation where an external actor (the multi-sourcing client firm) creates and
orchestrates a market-like environment, in which a set of interdependent actors
308
Zu diesem Konzept, welches auf Abbildung 9 grafisch dargestellt ist, existieren bislang
nur wenige Studien, die ausschließlich eine dyadische Perspektive einnehmen.
309
Abbildung 9: Das Phänomen Forced Coopetition
310
306
Vgl. Wilhelm (2011), S. 665.
307
Vgl. Wilhelm (2011), S. 672.
308
Wiener/Saunders (2014), S. 212f.
309
Wiener/Saunders (2014); Buttschardt (2017); Tidström/Rajala (2016).
310
Eigene Darstellung.
Kunde
LieferantLieferant
Wettbewerb durch
Kompetenz-Überlappung
Spannungen
Auftrag-basierte Kooperation
durch Abhängigkeiten
55 Zentrale Konzepte und Definitionen
Wiener/Saunders (2014) identifizieren im Rahmen einer Fallstudie Erfolgsfaktoren für
das Management der kritischen Balance zwischen dem Kooperations- und Wettbe-
werbs-Paradigma aus Sicht eines Abnehmers.
311
Die Autorenschaft entwickelt ein
Klassifikationsschema, wobei bestehende IT-Multi-Sourcing-Modelle anhand der Ka-
Forced CoopetitionVendor competitionVendor cooperation
fiziert werden (siehe Tabelle 10) und schlagen die Anwendung dieses Frameworks im
Rahmen von zukünftigen Fallstudien im IT-Multi-Sourcing-Kontext vor.
312
Erkennbar ist,
dass das Ausmaß von Forced Coopetition im Fall von überlappenden Aufgabenberei-
chen der Lieferanten am stärksten ist.
Tabelle 10: Klassifikationsschema für IT-Multi-Sourcing-Modelle
313
Modell
Vermittelt (mediated)
Direkt
Direkt-überlappend
Grafische Dar-
stellung
Forced Coope-
tition
Niedrig bis moderat
Niedrig bis moderat
hoch
Lieferanten
Wettbewerb
Niedrig (vermittelte
Kunden-Lieferanten-
Beziehungen und ge-
trennte Lieferanten-Be-
reiche)
Moderat (direkte Kun-
den-Lieferanten-Be-
ziehungen, aber ge-
trennte Lieferanten-
Bereiche)
Hoch (direkte Liefe-
ranten-Kunden-Bezie-
hungen und überlap-
pende Lieferanten-
Bereiche)
Lieferanten
Kooperation
Moderat (Kooperation
mit guardian vendor
(V1) und Kooperation
mit anderen Lieferanten
in Bereichs-Schnittstel-
len)
Niedrig (Kooperation
mit anderen Lieferan-
ten nur in Bereichs-
Schnittstellen)
Hoch (Kooperation
mit anderen Lieferan-
ten in Bereichs-
Schnittstellen, inner-
halb der Bereiche und
bei denselben Aufga-
ben)
311
Vgl. Wiener/Saunders (2014), S. 219ff.
312
Vgl. Wiener/Saunders (2014), S. 223.
313
in Anlehnung an Wiener/Saunders (2014), S. 223.
C
V1
V1 V2 V3
C
V1 V2 V3
C
V1
V2 V3
Theoretischer Hintergrund für die angestrebte Modellentwicklung 56
Buttschardt (2017) greift das Phänomen im Rahmen seiner Dissertation auf und ermit-
telt kritische Erfolgsfaktoren für das Management von Forced-Coopetition-Beziehun-
gen in IT-Multi-Sourcing-Projekten aus der Abnehmerperspektive.
314
Dabei zielt er ins-
besondere auf das Management der Spannungen zwischen den Akteuren ab, welche
u. a. aufgrund der simultanen Existenz der widersprüchlichen Paradigmen Koopera-
tion und Wettbewerb entstehen.
315
Auf einen möglichen Zusammenhang zwischen
Forced Coopetition und der Lieferanten-Performance weist eine Fallstudie von Mariani
(2007) hin, wobei das Auftreten von Coopetition als ungewollte Strategie von einer
externen Institution dargestellt wird. Es kann gezeigt werden, dass durch diese indu-
zierte Coopetition
316
die Performance bei gleichzeitig ausreichender Flexibilität des Ma-
nagements gesteigert werden kann.
317
2.3.4.2 Aufgaben-Interdependenz
Aufgaben-Interdependenz bezeichnet das Vorhandensein von Abhängigkeiten zwi-
schen Input- und Output-Faktoren in den Handlungen mehrerer organisatorischer Ein-
heiten.
318
Diese Abhängigkeiten bedingen ein verstärktes Maß an Interaktion sowie den
Austausch von Wissen, Informationen, Produkten und Ressourcen in Hinblick auf die
Zielerreichung.
319
Kumar et al. (2009) definieren Aufgaben-Interdependenz als das
Ausmaß, inwieweit die Leistung und das Ergebnis einer Aufgabe durch die Leistung
und das Ergebnis anderer Aufgaben beeinflusst wird oder eine Interaktion mit ihnen
erfordert.
320
Das Phänomen findet seinen Ursprung in der Coordination Theory, wobei
Koordination als das Management voneinander abhängiger Aufgaben verstanden
wird.
321
Aufgaben-Interdependenz fungiert in diesem Zusammenhang folglich als Cha-
314
Vgl. Buttschardt (2017), S. 21ff.
315
Vgl. Buttschardt (2017), S. 18.
316
Die Autorenschaft verwendet
Saunders (2010) eingeführten Phänomens der Forced Coopetition vergleichbar ist.
317
Vgl. Mariani (2007), S. 120.
318
Vgl. Bapna et al. (2010), S. 790; Vgl. Andres/Zmud (2002), S. 44.
319
Vgl. Kuthyola et al. (2017), S. 136; Vgl. Andres/Zmud (2002), S. 44.
320
Vgl. Kumar et al. (2009), S. 644.
321
Vgl. Crowston (1997), S. 159; Vgl. Malone/Crowston (1990), S. 5.
57 Zentrale Konzepte und Definitionen
rakteristik, welche die Notwendigkeit für Koordinationsmechanismen maßgeblich be-
dingt.
322
Dabei hängt das Ausmaß des eingesetzten Kommunikations- und Koordinati-
onsaufwands von dem Grad der Aufgaben-Interdependenz ab.
323
Um Aufgaben-Interdependenzen durch geeignete Koordinationsmechanismen steu-
ern zu können, ist es zunächst notwendig, diese zu identifizieren.
324
Malone/Crowston
(1990) entwickeln zur Analyse von Interdependenzen ein Klassifikationsschema an-
hand von gemeinsam genutzten Objekten und unterscheiden bei den generischen In-
terdependenzen zwischen Vorbedingung, geteilter Ressource und Gleichzeitigkeit.
325
Darauf aufbauend verfeinert Crowston (1997) diese Typologie und differenziert zwi-
schen drei Arten von Abhängigkeiten: Jenen zwischen Aufgaben (geteilter Input, ge-
teilter Output oder sequenziell genutzt), zwischen Aufgaben und Ressourcen sowie
Abhängigkeiten zwischen Ressourcen.
326
Traditionelle Konzepte der Aufgaben-Inter-
dependenz entstanden im Kontext der routinemäßigen Fabrik- oder Büroarbeit, wobei
der Fluss des Arbeitsobjektes beobachtbar war.
327
Bei abstrakten, wissensbasierten Interaktionen, wie etwa bei der Entwicklung von Em-
bedded Software, stellt die mangelnde Beobachtbarkeit eine Herausforderung für die
Koordination voneinander abhängiger Aufgaben dar.
328
Insbesondere bei hoch kom-
plexen Artefakten bestehend aus Hardware- und Softwarekomponenten führt die ge-
meinsame Produktentwicklung zu Interdependenzen über produktbezogene, geogra-
fische und organisatorische Grenzen hinweg.
329
Kumar et al. (2009) stellen in diesem
Zusammenhang fest, dass die traditionelle Typologie nach van de Ven et al. (1997)
330
im Kontext von globalisierten Märkten und komplexer werdenden Produkten nicht
mehr ausreicht und entwickeln eine robustere Typologie für Aufgaben-Interdependenz
322
Vgl. Malone/Crowston (1990), S. 363.
323
Vgl. Kumar et al. (2009), S. 644.
324
Vgl. Malone/Crowston (1990), S. 364.
325
Vgl. Malone/Crowston (1990), S. 363f.
326
Vgl. Crowston (1997), S. 160.
327
Vgl. Kumar et al. (2009), S. 645.
328
Vgl. Kumar et al. (2009), S. 645.
329
Vgl. Kumar et al. (2009), S. 645f.
330
siehe dazu van de Ven et al. (1976), S. 325.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 58
zur Analyse und Gestaltung global verteilter, komplexer und wissensintensiver Ar-
beit.
331
Dabei nehmen die Publizierenden auf das Konzept der Informationspermanenz
(engl. information stickiness) sowie die Integrations-Interdependenz Bezug. Informati-
onspermanenz bezeichnet den erforderlichen Zusatzaufwand zur Übertragung einer
Informationseinheit in einer für den Informationssuchenden nutzbaren Form an einen
bestimmten Ort.
332
Mehrdeutige, unsichere oder komplexe Informationen weisen eine
erhöhte Informationspermanenz und haben erhöhte Transferkosten in Form von Kom-
munikations- und Koordinationsaufwand zur Folge.
333
Gemäß der Definition von Kumar
et al. (2009) liegt Integrations-Interdependenz vor, wenn folgende Aspekte erfüllt sind:
1. Eine Gesamtaufgabe ist in Teilaufgaben untergliedert, welche unterschiedli-
che Komponenten des Gesamtergebnisses darstellen, von getrennt und pa-
rallel arbeitenden Akteuren ausgeführt werden, und jeweils verschiedene Pro-
zesse und Fertigkeiten erfordern.
2. Die Ergebnisse des Aufgabensegmente erhalten ihren Wert erst als Teil des
integrierten Ganzen.
3. Die Integration der Aufgabensegmente erfordert einen Anpassungs- oder In-
tegrationsprozess.
4. Die Akteure müssen den Status anderer parallellaufender Arbeitsaktivitäten
kennen, da diese ihre eigenen Arbeiten oder den Zeitplan beeinflussen kön-
nen.
334
Ein Ausschnitt der Typologie von Kumar et al. (2009) ist auf Abbildung 10 dargestellt.
Abbildung 10: Arten der Integrations-Interdependenz
335
331
Vgl. Kumar et al. (2009), S. 644646.
332
Vgl. Hippel (1994), S. 430.
333
Vgl. Kumar et al. (2009), S. 654f.
334
Vgl. Kumar et al. (2009), S. 652.
335
in Anlehnung an Kumar et al. (2009), S. 657.
Arbeit kommt in die
Einheiten rein
Arbeit verlässt die
Einheiten
Arbeit kommt in die
Einheiten rein
Arbeit verlässt die
Einheiten
Arbeit kommt in die
Einheiten rein
Arbeit verlässt die
Einheiten
Normale Form: Teilweise permanent: Vollständig permanent:
59 Zentrale Konzepte und Definitionen
Hierbei werden die Arbeitsorte durch Rechtecke und die Agierenden durch Kreise sym-
bolisiert. Der Einfluss der Informationspermanenz ist anhand der zirkulierenden Pfeile
erkennbar. Dieser Typologie folgend, liegt für den hier vorliegenden Beschaffungskon-
text teilweise (engl. partially sticky) oder vollständig permanente (engl. fully sticky) In-
tegrations-Interdependenz vor, woraus ein hoher Kommunikations- und Koordinations-
aufwand resultieren.
Es existiert eine Reihe von Studien, welche den Zusammenhang zwischen Aufgaben-
Interdependenz, Performance-Größen sowie anderen Faktoren innerhalb von Organi-
sationen, beleuchten.
336
Auch im Bereich des Software-Projektmanagements wird das
Phänomen im Zusammenhang mit Projekt-Performance bereits mehrfach adressiert.
337
Andres/Zmud (2002) ermitteln beispielsweise einen negativen Zusammenhang zwi-
schen dem Ausmaß von Aufgaben-Interdependenz und dem Projekterfolg.
338
Zunächst
wurde das Phänomen hauptsächlich im intra-organisationalen Kontext untersucht.
339
Dass eine Übertragbarkeit auf den inter-organisationalen Kontext gegeben ist, belegen
Studien aus den Bereichen Multi-Sourcing und global verteiltes Arbeiten, welche das
Phänomen Aufgaben-Interdependenz zwischen Lieferanten im Zusammenhang mit
Steuerungsmechanismen sowie Performance-Größen untersuchen.
340
Plugge/Jans-
sen (2014) argumentieren, dass Interdependenzen sowohl zwischen Lieferanten und
Kunden als auch zwischen Lieferanten vertraglich geregelt werden sollten.
341
Solche
Multi-Lieferanten-Verträge sollten konkrete Steuerungsvereinbarungen zu Rollen, Ver-
antwortlichkeiten und Meeting-Strukturen enthalten, um Widerstände zu verringern
und Beziehungen zu stärken.
342
2.3.4.3 Kollaborative Leistungen
Eine weitere Besonderheit des vorliegenden Beschaffungskontextes besteht in dem
hohen Maß an erforderlicher Zusammenarbeit zwischen Lieferanten, was maßgeblich
durch die vorherrschenden Abhängigkeiten bedingt ist. Natour et al. (2011) verstehen
336
Bachrach et al. (2006); Katz-Navon/Erez (2005); Langfred (2005); Lee et al. (2015); Wageman/Baker
(1997); Hsu (2018).
337
Vgl. Kuthyola et al. (2017); Vgl. Andres/Zmud (2002); Vgl. Marsicano et al. (2018).
338
Vgl. Andres/Zmud (2002), S. 41.
339
van de Ven et al. (1976); Victor/Blackburn (1987); Wageman/Baker (1997).
340
Bapna et al. (2010); Oshri et al. (2019); Plugge/Janssen (2014); Kumar/Thangavelu (2013).
341
Vgl. Plugge/Janssen (2014), S. 93.
342
Vgl. Plugge/Janssen (2014), S. 93.
Theoretischer Hintergrund für die angestrebte Modellentwicklung 60
unter der Zusammenarbeit im Versorgungsnetzwerk (supply network collaboration) die
verhaltensbezogenen und weichen Aspekte, die den Güter-, Dienstleistungs-, Infor-
mations- und finanziellen Fluss erleichtern, ausführen und kontrollieren.
343
Das Kon-
zept der Zusammenarbeit wird vor allem in der Supply Chain Management-Literatur
umfassend diskutiert, wobei sich seit Beginn des 21. Jahrhunderts der Fokus von einer
intra-organisationalen hin zu einer inter-organisationalen Betrachtungsweise verlagert
hat.
344
Laut der Erkenntnisse von Bapna et al. (2010) besteht in einem von Aufgaben-Inter-
dependenz geprägten Multi-Sourcing-Umfeld die Notwendigkeit, dass Lieferanten zu-
sätzlich zur vertraglich vereinbarten Primärleistung kollaborative Leistungen
(engl. collaborative efforts) gegenüber anderen Lieferanten erbringen. Folglich sei die
Fähigkeit eines Lieferanten zur Auftragserfüllung nicht mehr nur von dessen eigenen
Primärl in Form von
Ressourcen, Informationen, etc. abhängig.
345
Dieser Aspekt bringe folglich enorme
Herausforderungen für die Anreiz-Setzung und die Lieferanten-Steuerung mit sich.
346
Bapna et al. (2010) zeigen auf, dass Anreize in solchen Multi-Lieferanten-Umgebun-
gen nicht nur an die eigene, sondern auch an die relative Leistung eines Lieferanten
oder an die aggregierte Performance aller Lieferanten geknüpft sein sollten.
347
Natour et al. (2011) stellen in ihrem Bezugsrahmen den Zusammenhang zwischen
Supply Chain Integration, Kollaboration und Performance dar und nehmen eine
Agency Theory-Perspektive ein (siehe Abbildung 11).
348
Die Autorenschaft vertritt die
Ansicht, dass die auftretenden Macht-Dynamiken in Lieferanten-Netzwerken nicht in
ausreichendem Maß über eine klassische dyadische Prinzipal-Agenten-Perspektive
analysiert werden könne und legen daher eine multi-agency-analytische Linse zu-
grunde.
349
Sie argumentieren, dass eine Performancesteigerung in Multi-Agenten-Ver-
sorgungsnetzwerken nur durch das Erbringen kollaborativer Leistungen zwischen den
Akteuren erreicht werden könne. Diese würden jedoch durch Kontext-Faktoren wie
343
Vgl. Natour et al. (2011), S. 2.
344
Vgl. Kache/Seuring (2014), S. 668.
345
Vgl. Bapna et al. (2010), S. 786794.
346
Vgl. Bapna et al. (2010), S. 786.
347
Vgl. Bapna et al. (2010), S. 791.
348
Vgl. Natour et al. (2011), S. 9.
349
Vgl. Natour et al. (2011), S. 8.
61 Zentrale Konzepte und Definitionen
Transparenz, Kontrolle und Sichtbarkeit beeinflusst und es bestünde bei fehlendem
Management die Gefahr einer Umwandlung der Lieferanten-Beziehungen in Agency-
Beziehungen.
350
Eine Möglichkeit, dem entgegenzuwirken und folglich die Perfor-
mance zu steigern bestünde in vertrauensbildenden und risikomindernden Maßnah-
men sowie in Maßnahmen zur Ziel-Angleichung zwischen den beteiligten Akteuren.
Natour et al. (2011) weisen schließlich auf die Notwendigkeit der Validierung ihres Be-
zugsrahmens im Rahmen von branchenspezifischen Fallstudien hin.
351
Abbildung 11: Kollaborative Leistungen in Multi-Agenten-Netzwerken
352
2.3.4.4 Besonderheiten des Beschaffungsobjektes Embedded Software
Unter Software im Allgemeinen ist ein immaterielles, digitales Produkt zu verstehen,
welches in einer Programmiersprache geschrieben ist und Vorschriften zur Datenver-
arbeitung mittels eines technischen Geräts enthält.
353
Hinsichtlich der Art der Bereit-
stellung kann zwischen Standard- und Individualsoftware differenziert werden.
354
Wäh-
rend Standardsoftware als vorgefertigtes Programmpaket am Markt erworben werden
kann, wird Individualsoftware für die spezifischen Anforderungen eines Auftraggebers
350
Vgl. Natour et al. (2011), S. 11.
351
Vgl. Natour et al. (2011), S. 11.
352
in Anlehnung an Natour et al. (2011), S. 9.
353
Vgl. Abts/Mülder (2017), S. 57; Vgl. Blohm (2013), S. 11.
354
Vgl. Blohm (2013), S. 12.
Prinzipal
AgentAgent Agency-Beziehung
Multi-Agenten Versorgungsnetzwerk
Sichtbarkeit
Steuerung
Angleichung von
Zielen und
Präferenzen
Risiko-Minderung
Vertrauensbildende
Maßnahmen
Transparenz
Kooperative
Leistungen
Steigerung
Performance
Theoretischer Hintergrund für die angestrebte Modellentwicklung 62
entwickelt.
355
Das Produkt Software ist durch eine Reihe spezifischer Eigenschaften
gekennzeichnet, welche es von physischen Produkten unterscheiden:
• Immaterialität,
• Leichte Kopierbarkeit,
• Kein Verschleiß,
• Keine Ersatzteile erforderlich,
• Unterliegt Alterungsprozess aufgrund sich ändernder Anforderungen,
• Leichte Änderbarkeit,
• Schwer messbare Qualität.
356
Software-Qualität bezeichnet die Fähigkeit, vorab definierte Anforderungen zu erfüllen
und kann sowohl während des Entwicklungsprozesses als auch anhand der Beschaf-
fenheit des Endprodukts festgestellt werden.
357
Eine Beurteilung der Qualitätskriterien
vor Vertragsabschluss ist ausschließlich beim Kauf von Standardsoftware möglich.
358
Die Qualitätsprüfung muss stets systematisch und anhand dedizierter Kriterien erfol-
gen.
359
Aufgrund der enormen Produkt-Komplexität kann eine hundertprozentige Qua-
litätsabsicherung dabei im Regelfall nicht erreicht werden.
360
Um eine möglichst hohe
Absicherung zu erreichen, werden Testverfahren an Risikoszenarien ausgerichtet,
welche bereits in der frühen Konzeptionsphase entworfen werden müssen.
361
Bei der so genannten eingebetteten (engl. Embedded) Software wird diese im Gegen-
satz zur eigenständigen Software als fester Bestandteil eines technischen Gerätes ein-
gesetzt, wobei sich die Funktionalität erst aus dem einwandfreien Zusammenspiel von
Hardware und Software ergibt.
362
Embedded Software wird häufig in Form von Steue-
rungsprogrammen in Fahrzeugen oder Maschinen verwendet, z. B. in der Robotik, A-
vionik, Telekommunikation oder der Fahrzeugelektronik.
363
355
Vgl. Blohm (2013), S. 12.
356
Vgl. Abts/Mülder (2017), S. 55f.
357
Vgl. Abts/Mülder (2017), S. 76.
358
Vgl. Abts/Mülder (2017), S. 76.
359
Vgl. Abts/Mülder (2017), S. 56.
360
Vgl. Herzig et al. (2017), S. 5.
361
Vgl. Herzig et al. (2017), S. 5.
362
Vgl. Abts/Mülder (2017), S. 64; Vgl. Blohm (2013), S. 12.
363
Vgl. Abts/Mülder (2017), S. 64; Marwedel (2021), S. 4f.
63 Zentrale Konzepte und Definitionen
Ein Großteil der Software in modernen Fahrzeugen befindet sich auf miteinander ver-
netzten elektronischen Steuergeräten (engl. Electronic Control Unit, kurz ECU).
364
Da-
bei dient die Software vorwiegend der Umsetzung der vom Kunden wahrnehmbaren
und als Ausstattungsmerkmal erwerblichen funktionalen Anforderungen.
365
Darüber
hinaus wird Fahrzeug-Software eingesetzt, um Schwächen der Elektronik und Hard-
ware zu kompensieren, wenn eine Behebung der Ursache zu teuer, zu langsam oder
physikalisch unmöglich ist.
366
Der Einsatz von Embedded Software in der Automobilin-
dustrie geht mit einigen Besonderheiten einher: Neben einer hohen Heterogenität und
Varianten-Vielfalt ist diese durch eine besonders hohe Komplexität gekennzeichnet,
welche maßgeblich auf die Verteilung der Software auf eine Vielzahl vernetzter Steu-
ergeräte zurückzuführen ist.
367
Eingekauft wird Embedded Software in der Automobilindustrie derzeit noch größten-
teils in Form von einzelnen, nicht veränderbaren Softwarekomponenten.
368
Bei dem
Einkauf solcher sogenannter proprietärer Komponenten, erwirbt der Abnehmer zwar
die Nutzungsrechte, erhält jedoch keinen Einblick in den Quellcode.
369
Dieser hohe An-
teil proprietärer Lösungen trägt neben der mangelnden Standardisierung und der his-
torisch gewachsenen Fahrzeug-Elektronik-Architektur dazu bei, dass die tatsächliche
Komplexität die technisch notwendige Komplexität übersteigt und es immer häufiger
zu ungewollten Wechselwirkungen (Interdependenzen) zwischen Funktionen
kommt.
370
Eine weitere Besonderheit bei der Beschaffung von Embedded Software in der Auto-
mobilindustrie besteht in dem hohen Anteil von Zulieferern im Design- und Entwick-
lungsprozess.
371372
Der technologische Wandel und die damit verbundene steigende
Komplexität führen dazu, dass einzelne Lieferanten nicht mehr in der Lage sind, den
364
Vgl. Bernard et al. (2011), S. 21.
365
Vgl. Wolf (2018), S. 41.
366
Vgl. Wolf (2018), S. 41.
367
Vgl. Staron (2017), S. 5.
368
Vgl. Broy (2006), S. 34; Vgl. Grimm (2003), S. 499.
369
Vgl. Abts/Mülder (2017), S. 60.
370
Vgl. Bernard et al. (2011), S. 21.
371
Vgl. Staron (2017), S. 5.
372
bezeichnet. Siehe Abbildung 1
Theoretischer Hintergrund für die angestrebte Modellentwicklung 64
Anforderungen von OEMs best of breed-Funktionalitäten innerhalb eines Ge-
samt-Systems gerecht zu werden.
373
Folglich findet eine zunehmende Spezialisierung
der Anbieter sowie eine Öffnung des Marktes für 2nd Tier-Zulieferer sowie branchen-
fremde Softwareunternehmen statt.
374
Blackbox-Einkau-
fes von integrierten Hardware-Software-Bündeln bei einem 1st Tier-Lieferanten, gehen
OEMs zu einer getrennten Beschaffung von Hardware und Software über.
375
Diese
Entwicklung hat weiterhin zur Folge, dass sich die klassische Wertschöpfungskette
zunehmend zu heterogenen Wertschöpfungsnetzwerken entwickelt, wobei Akteure
aus vormals getrennten Industriezweigen, welche teilweise in Konkurrenz zueinander
stehen, im Rahmen von Software-Entwicklungsprojekten zur Zusammenarbeit ge-
zwungen sind.
376
373
Vgl. Burkacky et al. (2019), S. 30.
374
Vgl. Burkacky et al. (2019), S. 30.
375
Vgl. Burkacky et al. (2019), S. 31; Broy (2006), S. 38.
376
Vgl. Bernard et al. (2011), S. 91.
65 Methodik zur Modellentwicklung
3 Entwicklung eines netzwerkbasierten Lieferanten Performance Manage-
ment und Measurement-Modelles
3.1 Methodik zur Modellentwicklung
Im Folgenden wird der methodische Ansatz zur Entwicklung eines netzwerkbasierten
LPMM-Modelles beschrieben. Bei der Erstellung eines Managementkonzeptes kann
zwischen zwei grundlegenden Vorgehensweisen unterschieden werden. Bei dem de-
duktiven Ansatz werden etablierte Modellansätze aus der Literatur hinsichtlich der An-
wendbarkeit auf den vorliegenden Kontext untersucht, wohingegen bei der induktiven
Vorgehensweise eine ungebundene Ableitung von Gestaltungsempfehlungen er-
folgt.
377
Da beide Ansätze sowohl Vor- als auch Nachteile
378
aufweisen wird für den vor-
liegenden Untersuchungskontext ein deduktiv-induktiver Mischansatz gewählt, wel-
cher nachfolgend detailliert vorgestellt wird und auf Abbildung 12 dargestellt ist.
Abbildung 12: Methodik bei der LPMM-Modellentwicklung
379
Über die initiale systematische Literaturrecherche wird zunächst eine Eingrenzung des
Problems vorgenommen und anhand des konzeptionellen Bezugsrahmens der Bedarf
für ein netzwerkbasiertes LPMM-Modell identifiziert, welches die Phänomene Aufga-
ben-Interdependenz, Forced Coopetition und kollaborative Leistungen adressiert
(siehe Kapitel 2.1). Um die Basis für die Modellentwicklung zu schaffen, werden über
377
Vgl. Deimling (2019), S. 777.
378
Zu den Vor- und Nachteilen siehe Deimling (2019), S. 777.
379
Eigene Darstellung.
-Modelles 66
formance Management übertragbare Ansätze ermittelt. Die dabei identifizierten Quel-
len werden anhand eines vorab definierten Analyserasters systematisch auf netzwerk-
spezifische Modellanforderungen, -elemente und Gestaltungsimpulse untersucht. Da-
bei werden bestehende Grenzen in der Übertragbarkeit auf den vorliegenden Unter-
suchungskontext identifiziert und berücksichtigt. Basierend auf den deduktiv ermittel-
ten Anforderungen und Gestaltungsimpulsen, werden die Modellelemente in unter-
schiedlichen Konfigurationen derart zusammengesetzt, sodass schließlich ein erster
Modellentwurf entsteht, welcher die zuvor ermittelten Inhalte in geeigneter Form visuell
darstellt. Dieser deduktiv entwickelte Modellentwurf soll im Rahmen der Experteninter-
views dazu dienen, den komplexen Sachverhalt für die Teilnehmenden anschaulich
und verständlich zu gestalten und damit die Generierung von neuen Ideen und Gestal-
tungsempfehlungen anzuregen. Um eine freie Ideenbildung zu ermöglichen, ist der
Modellentwurf daher bewusst generisch gehalten und weist keinen Anspruch auf Voll-
ständigkeit auf.
Bei der anschließenden empirischen Fallstudie werden mittels der durchgeführten Ex-
perteninterviews weitere Modellanforderungen und -elemente sowie generelle Gestal-
tungsempfehlungen induktiv ermittelt. Durch den deduktiv-induktiven Mischansatz
können die deduktiv ermittelten Anforderungen und Elemente einerseits validiert wer-
den. Andererseits sollen über die induktive Vorgehensweise neue Modellanforderun-
gen und -elemente sowie generelle Gestaltungsempfehlungen ermittelt werden. Da-
rauf basierend wird schließlich das LPMM-Modell entwickelt. Abschließend erfolgt eine
Überprüfung des Modelles in Bezug auf die Erfüllung der allgemeinen Management-
Modellanforderungen sowie der kontextspezifischen Anforderungen.
3.2 Deduktiv ermittelte Anforderungen an ein netzwerkbasiertes Lieferanten Per-
formance Management und Measurement-Modell
Das im Rahmen dieser Arbeit zu entwickelnde netzwerkspezifische LPMM-Modell
kann grundlegend als kontexspezifische Umsetzung eines Managementkonzeptes
verstanden werden. Unter einem Konzept wird in diesem Zusammenhang eine
systematische Interpretation von Erfahrungen verstanden.
380
Der Begriff Management
380
Vgl. Hofmann (2002), S. 6.
67
-Modell
beschreibt einerseits Prozesse und Funktionen, die in Organisationen angewandt
werden und andererseits die Personen, die diese Aufgaben wahrnehmen.
381
Managementkonzepte weisen unter anderem die folgenden Chrakterisika auf:
• Große Anwendungsnähe,
• Pragmatischer Ansatz: Legitimation größtenteils basierend auf empirischer
Relevanz,
• Induktive Entwicklung basierend auf Erfahrungswissen,
• Strategische Grundausrichtgung,
• Ständige Weiterentwicklung aufgrund sich ändernder Anforderungen,
• Bereitstellung von Methoden und Instrumenten zur Umsetzung.
382
Folglich sollte das zu entwickelnde LPMM-Modell zunächst die allgemeinen Anforde-
rungen an ein Managementkonzept erfüllen. Dabei kann gemäß Deimling (2019)
zwischen formalen (z. B. Integrationsfähigkeit, Ganzheitlichkeit, Praktikabilität) und
inhaltlichen Kriterien (z. B. Kontext-, Prozess- und Rollenorientierung) unterschieden
werden.
383
Aufgrund des Anfangsverdachtes, dass für den hier vorliegenden
Beschaffungskontext keine vollständige Neugestaltung des klassischen LPMM-
Modelles erforderlich ist, sollten ebenso die kontextunabhängigen Anforderungen an
ein LPMM-Modell berücksichtigt werden.
Auf Abbildung 13 sind sowohl die allgemeinen als auch die kontextspezifischen Mo-
dellanforderungen pyramidenartig dargestellt. Die Spitze der Anforderungs-Pyramide
bilden die kontextspezifischen LPMM-Modellanforderungen, die im Rahmen der in
Kapitel 2.3.3 durchgeführten systematischen Literaturrecherche ermittelt wurden.
Darunter schließen sich die kontexunabhängigen sowie die allgemeinen LPMM-
Modellanforderungen an ein Managementkonzept an.
381
Vgl. Hofmann (2002), S. 6.
382
Vgl. Hofmann (2002), S. 7.
383
Vgl. Deimling (2019), S. 774f.
-Modelles 68
Abbildung 13: Anforderungen an ein netzwerkspezifisches LPMM-Modell
384
Die auf Abbildung 13 dargestellten allgemeinen LPMM-Modellanforderungen entstam-
men der LPMM-Literatur werden im Folgenden näher erläutert. Ein LPMM-Modell
sollte über den Einsatz geeigneter Messgrößen und Mechanismen als Bewertungs-
und Messinstrument zur Ermittlung der Lieferanten-Performance dienen.
385
Die Steue-
rungs- und Überwachungsfunktion von LPMM-Modellen erfolgt über den Einsatz von
Monitoring-Aktivitäten.
386
Mit Hilfe eines Feedback-Mechanismus sollten Lieferanten
einerseits über die Erwartungen des Abnehmers sowie über die erzielten Leistungen
informiert werden, um Verbesserungen anzustoßen.
387
Über die Messung, Evaluation
und Analyse der Leistungskennzahlen fungieren LPMM-Modelle außerdem als Ent-
scheidungsunterstützungsinstrument, um strategische Entscheidungen im Hinblick auf
die Zusammensetzung des Lieferantenstammes treffen zu können.
388
Weiterhin ist ein
kontinuierlicher Review- und Rekalibrierungsprozess der gewählten Metriken und Me-
chanismen zielführend.
389
Die Beziehungsentwicklung kann über den Einsatz von Kor-
rekturmaßnahmen wie Anreizen, Bestrafungen und Belohnungen sowie dem Aufbau
384
Eigene Darstellung.
385
Vgl. Qian Li et al. (2017), S. 118; Vgl. Hawkins (2016), S. 1; Vgl. Parkash/Kaushik (2011a), S. 12.
386
Vgl. Parkash/Kaushik (2011a), S. 13; Vgl. Nsowah et al. (2017), S. 3; Vgl. Hawkins (2016), S. 1.
387
Vgl. Adesanya et al. (2020), S. 416; Vgl. Connor et al. (2020), 3.
388
Vgl. Jiang/Bai (2010), S. 1409; Vgl. Connor et al. (2020), 3; Vgl. Parkash/Kaushik (2011a), S. 13.
389
Vgl. Parkash/Kaushik (2011a), S. 13; Vgl. Bourne et al. (2018), S. 2016.
Kollektivität Berücksichtigung von Abhängigkeiten
Komplexitäts-Reduktion Multi-Dimensionalität Flexible
Strukturen & Prozesse Transparenz durch
Informationsaustausch vertrauensbildende Maßnahmen
Messung auf individueller und aggregierter Ebene
Bewertungs- und Messinstrument Steuerungs- und
Überwachungsinstrument Feedbackinstrument
Entscheidungsunterstützungsinstrument
Beziehungsentwicklungsinstrument Risikominderung
Review & Rekalibrierung Inklusion aller relevanten
Stakeholder
Kontextorientierung Objektorientierung Ursachen-
Wirkungsorientierung Erfolgsbeitragsorientierung
Prozess- und Rollenorientierung Instrumentenorientierung
Regel- und Normorientierung Allgemeine
Managementkonzept
Anforderungen
kontextunabhängige
LPMM Modell
Anforderungen
netzwerkspezifische
LPMM Modell
Anforderungen
Integrationsfähigkeit Ganzheitlichkeit Praktikabilität
Methodische Fundierung Theoretische Fundierung
Empirische Fundierung
Inhaltlich
Formal
69
-Modell
langfristiger kollaborativer Beziehungen erfolgen und stellt einen kritischen Erfolgsfak-
tor im LPMM dar.
390
Einen wesentlichen Aspekt des LPMM stellt außerdem die Mini-
mierung einkaufsbezogener Risiken dar.
391
Außerdem ist bei dem Design und der Ent-
wicklung eines LPMM-Modelles auf die Inklusion aller relevanter Stakeholder zu ach-
ten.
392
Im Folgenden werden die über die Literaturrecherche aus Kapitel 2.3.3 ermittelten
netzwerkspezifischen LPMM-Modellelemente und -anforderungen vorgestellt. In Ta-
belle 11 sind die kontextspezifischen LPMM-Elemente inklusive der von der Autorin
vermuteten Grenzen in der Übertragbarkeit für den hier betrachteten Kontext darge-
stellt. Für alle vorab identifizierten LPMM-Kernelemente konnten Besonderheiten für
den vorliegenden Netzwerkkontext ermittelt werden. Zusätzlich wurden drei netzwerk-
spezifische LPMM-Elemente identifiziert. Da in der Netzwerk Performance Manage-
ment-Literatur keine Bezugspunkte zu den Phänomenen Forced Coopetition, Aufga-
ben-Interdependenz und kollaborative Leistungen identifiziert werden konnten, wurden
im Rahmen der Backward-Suche weitere thematisch relevante Publikationen inkludi-
ert.
393
Tabelle 11: Deduktiv ermittelte LPMM-Modellelemente
394
LPMM-Element
Besonderheit im Netzwerk
Grenzen der Übertrag-
barkeit
Strategie & Ziel-
setzung
Kollektive Ziele; gemeinsame Ab-
stimmung; einheitliches Verständnis
aller Akteure395
Ziel-Divergenz aufgrund von
Wettbewerb und mangelnder
Freiwilligkeit; Einbindung von
Lieferanten in Ziel-Defini-
tions-Prozess nur begrenzt
möglich
Kriterien & Messung
Komplexität; Multi-Dimensionalität;
keine hierarchischen Metriken
aufgrund von Interdependenzen;
Messung auf individueller &
Netzwerkebene; Relevanz in-
formeller Kriterien; Infor-
mationsaustausch und Abhäng-
igkeiten messbar machen396
Messung sozialer & in-
formeller Faktoren bei
Gewährleistung von Objek-
tivität herausfordernd;
Zustimmung aller Netzwerk
Akteure bei Messung auf
Netzwerk-ebene erforderlich
Monitoring
Joint Performance Assessment397
Datenschutz-Bedenken
(Zusammenarbeit von
Wettbewerbern)
Analyse & Evalua-
tion
Ziel-Verflechtung als Bewertung-
smaßstab für Performance heran-
ziehen398
Unzureichende Kenntnis des
Abnehmers über individuelle
Ziele der Lieferanten
-Modelles 70
390
Vgl. Wiener/Saunders (2014), S. 218; Vgl. Buttschardt (2017), S. 167; Vgl. Jiang/Bai (2010), S. 1409;
Vgl. Hawkins (2016), S. 1.
391
Vgl. Hawkins (2016), S. 1; Vgl. Nsowah et al. (2017), S. 3.
392
Vgl. Maestrini et al. (2018a), S. 2045.
393
Wiener/Saunders (2014); Buttschardt (2017); Bapna et al. (2010); Malone/Crowston (1990); Crows-
ton (1997).
394
Eigene Darstellung.
395
Vgl. Ferreira et al. (2011), S. 1413; Vgl. Koppenjan (2008), S. 700; Vgl. Pekkola/Ukko (2016), S.
1429; Vgl. Mandell/Keast (2007), S. 583.
396
Vgl. Straub et al. (2004), S. 84; Vgl. Agostino/Arnaboldi (2018), S. 112; Vgl. Ferreira et al. (2011), S.
1414.
397
Vgl. Bapna et al. (2010), S. 792.
398
Vgl. Koppenjan (2008), S. 701.
399
Vgl. Wiener/Saunders (2014), S. 217.
400
Vgl. Koppenjan (2008), S. 706; Vgl. Natour et al. (2011), S. 8; Vgl. Alnatour/Gibson (2011), S. 4.
401
Vgl. Koppenjan (2008), S. 706; Vgl. Pekkola/Ukko (2016), S. 1419.
402
Vgl. Pekkola/Ukko (2016), S. 1418; Vgl. Ferreira et al. (2011), S. 1414; Vgl. Natour et al. (2011), S.
10.
403
Vgl. Buttschardt (2017), S. 43; Vgl. Wiener/Saunders (2014), S. 218220; Vgl. Natour et al. (2011),
S. 7.
LPMM-Element
Besonderheit im Netzwerk
Grenzen der Übertrag-
barkeit
Feedback
Regelmäßige Feedback-Schleifen;
direkte Kommunikation kann Motiva-
tion steigern399
Bilaterale vs. multilaterale
Kommunikation?
Korrekturmaßnah-
men
Gemeinsames Verständnis; loose
couplings (Spielraum für organisa-
tionales Lernen); vertrauens-
bildende Maßnahmen400
-
Review & Rekalibri-
erung
Aufgrund hoher Dynamik: flexibel
anpassbare Commitments bei Kon-
text-Veränderungen; regelmäßige
Überprüfung & Anpassung der
Metriken401
Netzwerk-Dauer aufgrund
von Projektlaufzeit nur be-
grenzt: Wie hoch ist Dynamik
tatsächlich?
Kommunikations-In-
frastruktur (netwerk-
spezifisch)
Informationsaustausch erleichtern
zur Schaffung von Vertrauen und
Transparenz; Informationsasymme-
trien verringern; Zusammenarbeit
fördern402
Austausch von sensiblen
Daten problematisch,
Datenschutz muss gewähr-
leistet sein
Anreizsystem
(netzwerkspezifisch)
Ziel- und Interessensangleichung al-
ler Netzwerkakteure; Förderung der
Zusammenarbeit; Wachstums- und
Entwicklungsmöglichkeiten403
-
71
-Modell
Tabelle 12 zeigt die deduktiv ermittelten netzwerkspezifischen LPMM-Anforderungen
sowie die vermuteten Grenzen in der Übertragbarkeit auf den vorliegenden Beschaf-
fungskontext. Diese werden im Folgenden kurz erläutert. Die Anforderung der
Kollektivität bezieht sich auf alle Prozess-Schritte entlang des gesamten LPMM-
Prozesses. Dabei sollen z. B. Prüfkriterien von kollektiven Zielen abgeleitet werden
sowie eine stärkere Abstimmung zwischen Lieferanten und Abnehmer in Bezug auf
den gelebten LPMM-Prozess und ein Übergang von bilateralen hin zu multilateralen
Meetings, Reportings und Abstimmungen mit allen relevanten Netzwerkakteuren
stattfinden. Dadurch kann die Transparenz erhöht und ein Konsens geschaffen werden,
was gleichzeitig eine Voraussetzung für die Entstehung von Vertrauen darstellt. Ein
transparenter Informationsaustausch zwischen allen Akteuren sowie ein transparenter
LPMM-Prozess werden außerdem zur Vermeidung bzw. Verringerung von
Informationsasymmetrien benötigt. Bei Auftreten von Abhängigkeiten zwischen den
Lieferumfängen mehrerer Lieferanten, sollten hierarchische Performance-Metriken
vermieden werden. Des Weiteren sollten die vorliegenden Abhängigkeiten zunächst
klassifiziert und mit geeigneten Koordinationsmechanismen versehen werden. Die
ausgewählten Performance-Metriken sollten im Netzwerk-Kontext nicht nur multilateral
abgestimtm und transparent kommuniziert werden, sondern auch die Komplexität und
Multi-Dimensionalität der Entwicklungsleistungen widerspiegeln. Darüber hinaus sollte
ein LPMM-Modell im Netzwerkkontext flexible Strukturen und Prozesse aufweisen, um
den Ein- und Austritt von Akteuren zu vereinfachen und der vorherrschenden Dynamik
gerecht zu werden.
404
Vgl. Crowston (1997), S. 160; Vgl. Malone/Crowston (1990), S. 364f.
LPMM-Element
Besonderheit im Netzwerk
Grenzen der Übertrag-
barkeit
Koordinations-
mechanismen
(netzwerkspezifisch)
Gezielte Steuerung von Interde-
pendenzen404
Identifikation aller Interde-
pendenzen ist aufgrund der
Komplexität schwierig
-Modelles 72
Tabelle 12: Deduktiv ermittelte LPMM-Modellanforderungen
405
Anforderungen
Grenzen der Übertragbarkeit
Kollektivität406
gemeinsame Abstimmung mit Lieferanten bezüglich der Gestaltung
und Umsetzung des LPMM: Mitspracherecht der Lieferanten nur zu
Auftraggeber liegen, da kein freiwilliger Netzwerk-Zusam-
menschluss
Berücksichtigung
von Abhäng-
igkeiten407
Durch Aufgaben-Interdependenz sind Lieferanten nicht unabhängig
ler Abhängigkeiten; hierarchische Performance-Messung im
Netzwerk nicht effektiv
Komplexitäts-Reduk-
tion408
Herausforderung: Ausgewogenheit gewährleisten und gleichzeitig
Informationsüberfluss und Widersprüchlichkeiten vermeiden
Multi-Dimensional-
ität409
-
Flexible Strukturen &
Prozesse410
agile Prozesse aus der Softwareentwicklung kollidieren mit lang-
samen und starren Hardware-Entwicklungsprozessen; 1-zu-1-
Übertragung auf die hardwarelastige Entwicklung nicht problemlos
lungsprozess
Transparenz durch
Infor-
mationsaustausch411
Vorbehalte einzelner Firmen gegenüber offenen Datenaustausch
im Netzwerk führen zu Informationsasymmetrie; Ängste bezüglich
Datenmissbrauchs aufgrund von Wettbewerbs-Situation können
hinderlich sein
Vertrauensbildende
Maßnahmen412
Messung auf indi-
vidueller & aggre-
gierter Ebene413
Herausforderung: Wie erfolgt Aggregation der individuellen Perfor-
mance-Ergebnisse auf Netzwerkebene
3.3 Diskussion der Erkenntnisse aus der systematischen Literaturrecherche
Anhand der deduktiv ermittelten netzwerkspezifischen LPMM-Modellanforderungen
(siehe Tabelle 12) sowie den netzwerkspezifischen LPMM-Modellelementen (siehe
Tabelle 11) wurde ein erster Entwurfsstand für das LPMM-Modell erstellt, welcher im
405
Eigene Darstellung.
406
Vgl. Ferreira et al. (2011), S. 1413; Vgl. Pekkola/Ukko (2016), S. 1419.
407
Vgl. Koppenjan (2008), S. 705f; Vgl. Crowston (1997), S. 160.
408
Vgl. Koppenjan (2008), S. 705; Vgl. Sena Ferreira et al. (2012), S. 687.
409
Vgl. Pekkola/Ukko (2016), S. 1417; Vgl. Koppenjan (2008), S. 705.
410
Vgl. Koppenjan (2008), S. 706; Vgl. Pekkola/Ukko (2016), S. 1419.
411
Vgl. Natour et al. (2011), S. 8f; Vgl. Pekkola/Ukko (2016), S. 1417.
412
Vgl. Bouncken/Fredrich (2012), S. 1; Vgl. Bapna et al. (2010), S. 789; Vgl. Buttschardt (2017), S. 43.
413
Vgl. Pekkola/Ukko (2016), S. 1419.
73 Diskussion der Erkenntnisse aus der systematischen Literaturrecherche
Rahmen der Experteninterviews als Anschauungsmaterial dienen und dabei die Ide-
engenerierung der Experten unterstützen sollte. Der entwickelte Modellentwurf setzt
sich aus zwei Teilen zusammen: einem Prozessmodell, welches die Abläufe und Be-
ziehungen beschreibt, sowie einer Balanced Scorecard, die als Instrument zur Mes-
sung verstanden werden kann und damit in den LPMM-Prozess integriert ist. Die Ba-
lanced Scorecard wurde 1992 von Kaplan und Norton entwickelt und erlaubt es dem
Nutzer, einen umfassenden, übersichtlichen und funktionsübergreifenden Überblick
über die Leistung eines Unternehmens zu erhalten und dabei die strategische mit der
operativen Ebene zu verknüpfen.
414
Auf Abbildung 14 ist das Prozessmodell dargestellt. Erkennbar ist eine Unterteilung in
zwei Systeme: dem LPMM-Prozess als solchen, der innerhalb der Systemgrenzen des
Abnehmers angewandt wird, sowie dem Lieferanten-Netzwerk.
Abbildung 14: LPMM-Modellentwurf
415
dient es der Abstimmung bezüglich der LPMM-Prozessgestaltung zwischen Lieferan-
ten und Kunden. Andererseits steht es für eine Kommunikationsinfrastruktur, die eine
bilaterale sowie eine multilaterale Kommunikation unterstützt. Kommuniziert werden
414
Vgl. Kleindienst (2017), S. 58; Vgl. Kaplan/Norton (1996b), S. 75.
415
Eigene Darstellung.
-Modelles 74
neben fachlichen Themen auch Feedback, Anreize sowie notwendige Korrekturmaß-
fasst ist. Somit sind den Anforderungen der Transparenz und Kollektivität Rechnung
getragen. An erster Stelle des LPMM--
Strategien zur Umsetzung abgeleitet werden. Da besonders im Rahmen von Netzwer-
ken das LPMM einer starken Kontextabhängigkeit unterliegt, wurde eine Reihe von
möglichen Einflussfaktoren, die bei der Ziel-Definition berücksichtigt werden sollten,
im Modell inkludiert.
416
Das LPMM-Modell kann folglich als offenes System, welches
von Umfeldelementen beeinflusst wird, verstanden werden.
Die messbaren Indikatoren (KPIs, engl: Key Performance Indicator) werden für alle
relevanten Geschäftsprozesse von der übergeordneten Zielsetzung abgeleitet und in
einer Balanced Scorecard zusammengetragen.
417
Dabei soll zwischen der Unterneh-
mens- und der Netzwerkebene unterschieden werden. Ebenso wurde das Element
dem Modell hinzugefügt. Hierbei handelt
es sich um einen nachgelagerten, unternehmensinternen Prozess, wobei die generier-
ten Messergebnisse durch das Management verarbeitet und als Entscheidungsgrund-
lage verwendet werden. Zusammenfassend kann festgestellt werden, dass der erste
Modellentwurf zunächst nur einen Teil der netzwerkspezifischen Anforderungen erfül-
len kann. Beispielsweise ist anhand des Modellentwurfes bislang nicht erkennbar, in-
wiefern Abhängigkeiten berücksichtigt werden oder vertrauensbildende Maßnahmen
durchgeführt werden. Außerdem konnte das Element der Koordination noch nicht
integriert werden. Für den generisch gehaltenen Modellentwurf besteht zunächst kein
Anspruch auf Vollständigkeit, jedoch soll das finale LPMM-Modell schließlich hinsicht-
lich der Erfüllung aller Anforderungen aus Abbildung 13 überprüft werden.
Abbildung 15 zeigt den Entwurf der Balanced Scorecard, der den Teilnehmenden im
Rahmen der Interviews vorgestellt wurde. Diese besteht aus insgesamt sechs Leis-
-Interdepen-
blick auf die Eignung für den vorliegenden spezifischen Beschaffungskontext. So wird
416
Vgl. Pekkola/Ukko (2016), S. 1416.
417
Vgl. José Alfaro Saiz et al. (2007), S. 316f.
75 Diskussion der Erkenntnisse aus der systematischen Literaturrecherche
beispielsweise die Bewertung der Prozess-Güte aufgrund der Immaterialität und
schweren Qualitätsprüfbarkeit von Software als wesentliches Performance-Kriterium
in einem sehr dynamischen Umfeld von Relevanz ist, da dies auch die Fähigkeit, fle-
-Qualität zwischen den
Unternehmen durch die Netzwerkakteure und ist folglich speziell in einem Netzwerk-
kontext relevant.
418
Abbildung 15: Entwurf der Balanced Scorecard
419
Die Dimensionen enthalten eine exemplarische Auswahl an Kriterien, für die im nächs-
ten Schritt jeweils Ziele, Strategien, Erfolgsfaktoren und schließlich messbare Indika-
toren abzuleiten sind. Zu den ursprünglichen Perspektiven nach Kaplan und Norton
zählen die Finanz- und Kundenperspektive, Wachstum und Lernen sowie Prozesse.
420
Kaplan und Norton betonen, dass die von ihnen getroffene Auswahl an Perspektiven
418
Vgl. Bonatto et al. (2017), S. 7.
419
Eigene Darstellung.
420
Vgl. Kaplan/Norton (1996a), S. 31.
Performance
Measurement
Netzwerk-
Ebene
-Modelles 76
Gegenstand von Änderungen bzw. Erweiterung sein dürfen und als Grundlage für Ma-
nager dienen sollen, sich auf die wesentlichen Kennzahlen zu fokussieren.
421
Bei der
Kriterienauswahl wurde auch Literatur aus dem Bereich GSD herangezogen, um die
Spezifika des Beschaffungskontextes adäquat abbilden zu können. Die identifizierten
Kriterien wurden einer inhaltlichen Clusterung unterzogen und anschließend in Anleh-
nung an bestehende Scorecards passenden Dimensionen zugewiesen. Das Phäno-
men Aufgaben-Interdependenz wurde im Zuge der Clusterbildung als übergeordnete
Dimension eingestuft, da sich hierzu mehrere zugehörige Kriterien identifizieren ließen.
Im Gegensatz dazu wurden die Phänomene Forced Coopetition und kollaborative
Leistungen als Kriterien innerhalb der Zusammenarbeit eingeordnet und
bedürfen einer weiteren Operationalisierung.
Da es sich um einen Entwurfsstand handelt, besteht auch hier kein Anspruch auf Voll-
ständigkeit. Die Scorecard sowie das Prozessmodell sollen den Interview-Teilnehmen-
den als Anschauungsmaterial dienen und außerdem zur eigenen Ideengenerierung
anregen. Gleichzeitig soll die getroffene Auswahl an Kriterien und Dimensionen von
den Teilnehmenden bewertet werden. Anhang B kann eine Auflistung aller deduktiv
ermittelten Kriterien und Dimensionen entnommen werden.
Um die Messung auf Netzwerk- sowie auf Akteursebene zu gewährleisten, sollen zwei
separate Scorecards genutzt werden. Eine Prüfung aller Kriterien hinsichtlich der
Messebene ist für diesen Scorecard-Entwurf nicht erfolgt und soll Bestandteil der Ex-
perteninterviews sein. Aus diesem Grund unterscheiden sich die Scorecards für die
Messung auf Akteurs- und Netzwerkebene zunächst lediglich anhand der Dimension
kontext Relevanz aufweist und da-
mit für die Messung auf Akteursebene nicht benötigt wird.
422
Parung/Bititci (2008) ar-
gumentieren, dass durch die Messung der Gesundheit einer Beziehung (engl. health
of collaborationder mögliche Erfolg eines Netzwerkes vorausgesagt werden kann
und schlagen die Messung anhand der Attribute Commitment, Koordination, Ver-
trauen, Kommunikationsqualität sowie Konfliktlösungstechnik vor.
423
421
Vgl. Kaplan/Norton (1996a), S. 34f.
422
Vgl. Vesalainen et al. (2017), S. 8.
423
Vgl. Parung/Bititci (2008), S. 663f.
77 Validierung der Anforderungen und Modellentwicklung anhand einer
Fallstudienuntersuchung
3.4 Validierung der Anforderungen und Modellentwicklung anhand einer Fallstudie-
nuntersuchung
3.4.1 Einordnung und Zielstellung
Um ein tiefgreifenderes Verständnis des Geschäftstyps Integrationsgeschäft mit der
Besonderheit von Forced Coopetition, Aufgaben-Interdependenz und kollaborativen
Leistungen zu erlangen und darauf basierend ein adäquates LPMM-Modell entwickeln
zu können, wird eine eingebettete Einzelfallstudie durchgeführt. Bei einer Fallstudie
findet grundlegend die Untersuchung eines Phänomens in dessen realen Umfeld an-
hand verschiedener Datenquellen statt.
424
Sie bietet den Vorteil einer ganzheitlichen
Betrachtung, wonach das Ganze nicht als Summe seiner Teile verstanden werden
kann und nur als zentraler Untersuchungsgegenstand begriffen werden kann.
425
Folg-
lich trägt diese Forschungsmethode zum Tiefenverständnis über komplexe individuelle,
soziale, organisatorische und politische Phänomene bei und ermöglicht die ganzheit-
liche Untersuchung von damit in Zusammenhang stehenden Merkmalen und Ereignis-
sen.
426
In Hinblick auf die Datensammlung bietet sie dem Forschenden die Möglichkeit,
eine Vielzahl von Techniken zu verwenden, welche auch in Kombination eingesetzt
werden können.
427
Das Ziel besteht im Unterschied zu quantitativen Untersuchungsde-
signs nicht in der statistischen Verallgemeinerung, sondern vielmehr der Ermittlung
von Häufigkeiten in Hinblick auf die zu analysierenden Phänomene.
428
Aus Vorgesprächen mit Praktizierenden ging der Anfangsverdacht hervor, dass die zu
untersuchenden Phänomene auch in der Automobilindustrie von Relevanz sind. Folg-
lich wird diese Branche als konkreter Anwendungsfall für diese Studie herangezogen.
Als übergeordneter Fall wird die Embedded-Software-Beschaffung eines Automobil-
Konzerns definiert. Die zu untersuchenden Unter-Einheiten bilden ausgewählte Ent-
wicklungsprojekte, welche im Software Multi-Sourcing-Kontext angesiedelt sind. Auf
Abbildung 16 ist die Einbettung der zu untersuchenden Entwicklungsprojekte (P1 - P14)
in den Gesamtkontext des Software Multi-Sourcings dargestellt. Untersucht werden
424
Vgl. Dücker (2020), S. 112.
425
Vgl. Patton/Appelbaum (2003), S. 63.
426
Vgl. Patton/Appelbaum (2003), S. 63; Vgl. Dücker (2020), S. 112.
427
Vgl. Saunders et al. (2009), S. 146.
428
Vgl. Borchardt/Göthlich (2007), S. 36.
-Modelles 78
insgesamt acht Embedded-Software-Entwicklungsprojekte von drei verschiedenen
Marken (OEM1 - OEM3). Vergleichbare Fallstudien ([1] - [9]) im Kontext von Software
Multi-Sourcing sind bislang mit Ausnahme von Ebert (2017) auf andere Branchen (vor-
ranging IT-Dienstleistungen
429
) fokussiert und lediglich zwei der vergleichbaren Fallstu-
dien im Kontext des Software Multi-Sourcing (Nr. [9]) untersuchen dabei die Phäno-
mene Forced Coopetition bzw. Aufgaben-Interdependenz.
430
Abbildung 16: Einbettung der Fallstudie in den Software-Multi-Sourcing-Kontext
431
([1]: Lin (2015), [2]: Lin (2016), [3]: Plugge/Janssen (2014), [4]: Plugge (2018), [5]: Gold-
berg/Satzger (2016), [6]: Levina/Su (2008), [7]: Ebert (2017), [8]: Oza (2006), [9]: Wie-
ner/Saunders (2014))
Hauptsächlich handelt es sich bei den vergleichbaren Studien um Einzelfallstudien, in
denen ein oder zwei Fälle untersucht werden. Eine Netzwerkperspektive wird lediglich
in zwei Fallstudien aus der IT-Dienstleistungsbranche zugrunde gelegt.
432
Im Rahmen
der Fallstudie wird zur Beantwortung der Forschungsfragen FF 1a 1b eine deskrip-
tive Beschreibung der vorherrschenden Probleme und Phänomene erfolgen. Zur Be-
antwortung von FF 1c werden basierend auf der qualitativen Inhaltsanalyse Hypothe-
sen über vermutete Wirkungsbeziehungen im Zusammenhang mit der Lieferanten-
429
Lin (2015); Lin (2016); Plugge/Janssen (2014); Plugge (2018); Goldberg/Satzger (2016).
430
Wiener/Saunders (2014); Vgl. Plugge/Janssen (2014).
431
Eigene Darstellung.
432
Lin (2015); Lin (2016).
79 Validierung der Anforderungen und Modellentwicklung anhand einer
Fallstudienuntersuchung
und Netzwerk-Performance aufgestellt. Weiterhin besteht das Ziel in der Validierung
der deduktiv ermittelten Anforderungen sowie in der induktiven Generierung weiterer
Modellanforderungen und Gestaltungsempfehlungen, welche anschließend zur Erar-
beitung des LPMM-Modelles sowie der Beantwortung der Forschungsfragen FF2a
2d sowie 3b genutzt werden.
3.4.2 Fallauswahl
In qualitativen Fallstudiendesigns sollte die Auswahl der zu untersuchenden Fälle be-
gründet, d. h. anhand vorab definierter Kriterien, erfolgen und in einem Zusammen-
hang mit dem übergeordneten Forschungsziel stehen.
433
Im Gegensatz zur quantitati-
ven Forschung darf die Fallauswahl also keinem Zufallsprinzip unterliegen.
434
Bei Stu-
dien mit mehreren Fällen sollten diese derart ausgewählt werden, dass sie entweder
voraussichtlich bisherige Erkenntnisse bestätigen (engl. literal replication) oder sich
daraus gegensätzliche Ergebnisse erwarten lassen (engl. theoretical replication), die
theorieseitig prognostizierbar sind.
435
Wenn mehrere Fälle zu widersprüchlichen Er-
gebnissen führen, sollte die vorläufige Theorie überarbeitet und mit einer weiteren
Reihe von Fällen getestet werden.
436
Beim theoretischen Sampling können Fälle mit
dem Ziel ausgewählt werden, eine bestehende Theorie zu erweitern, Theorie-abgelei-
tete Kategorien zu bedienen oder frühere Fälle zu replizieren.
437
Eisenhardt (1989)
empfiehlt eine Fallanzahl von vier bis maximal zehn Fällen, da dies einen Kompromiss
aus einer ausreichenden Datenmenge und gleichzeitiger Handhabbarkeit der hohen
Komplexität darstelle.
438
Bei der Auswahl geeigneter Entwicklungsprojekte unterstützten verschiedene Embed-
ded-Software-Beschafferinnen und -Beschaffer eines renommierten Automobil-Kon-
zernes. Die Fallauswahl erfolgte gemäß der folgenden vorab definierten aus der Lite-
ratur abgeleiteten Kriterien:
433
Vgl. Borchardt/Göthlich (2009), S. 37.
434
Vgl. Borchardt/Göthlich (2009), S. 37.
435
436
437
Vgl. Eisenhardt (1989), S. 537.
438
Vgl. Eisenhardt (1989), S. 545.
-Modelles 80
• Getrenntes Sourcing von Hardware und Software,
439
• Vorliegen von technischen und funktionalen Abhängigkeiten zwischen den Lie-
ferumfängen mehrerer Lieferanten,
440
• Zusammenarbeit zwischen Lieferanten auf horizontaler und vertikaler Ebene
erforderlich
441
,
• Bestehender Verdacht auf Vorliegen von Forced Coopetition,
442
• Fortgeschrittenes Projekt-Stadium.
443
Dabei wurde außerdem darauf geachtet, möglichst repräsentative und kritische Pro-
jekte auszuwählen, um ein breites Spektrum an Problemen und Phänomenen abbilden
zu können.
444
Die Distanz der ausgewählten Fälle ist gering, da alle Entwicklungspro-
jekte die o. g. Kriterien erfüllen mit Ausnahme des fortgeschrittenen Projekt-Stadiums.
Lediglich das Projekt P14 befand sich im Gegensatz zu den anderen Projekten noch
in einer vergleichsweise frühen Projektphase. Sobald ein geeignetes Entwicklungspro-
jekt identifiziert wurde, erfolgte die Auswahl der zu befragenden Lieferanten, mit dem
Ziel, möglichst repräsentative Ausschnitte der komplexen Lieferanten-Netzwerke ab-
bilden zu können. Aufgrund der zugrunde gelegten Netzwerkperspektive wurden für
jedes Entwicklungsprojekt neben dem beauftragenden OEM Lieferanten ausgewählt,
welche im besonders hohen Maße miteinander interagieren müssen und viele Abhän-
gigkeiten untereinander aufweisen. Hundertprozentige Tochterunternehmen von O-
EMs wurden im Rahmen der Fallstudie als OEMs gewertet.
439
Dies impliziert die Beteiligung von mindestens zwei Software- oder Systemlieferanten mit direkter
Beziehung zum OEM an der Entwicklung des Steuergerätes.
440
Dieses Kriterium wurde gewählt, da es einen Indiz für das Auftreten von Aufgaben-Interdependenz
darstellt.
441
Dieses Kriterium wurde gewählt, da es einen Indiz für das Vorliegen von kollaborativen Leistungen
darstellt.
442
Die Erfüllung dieses Kriteriums war nicht zwingend erforderlich, sondern wünschenswert. Der Ver-
dacht auf Forced Coopetition ist gegeben, wenn im Rahmen des Projektes die Zusammenarbeit zwi-
schen Wettbewerbern mit überlappenden Kompetenzbereichen erforderlich ist.
443
Dieses Kriterium wurde gewählt, da die zu untersuchenden Phänomene vorrangig in der fortgeschrit-
tenen Projektphase auftreten und somit besser bewertet werden können.
444
81 Validierung der Anforderungen und Modellentwicklung anhand einer
Fallstudienuntersuchung
3.4.3 Datensammlung und -aufbereitung mittels Experteninterviews
Als Datenerhebungsmethode wurde die mündliche Befragung gewählt, da sich diese
besonders für explorative Fragestellungen und zum Generieren von tiefgründigen Er-
kenntnissen über komplexe und wenig ergründete Phänomene eignet.
445
In Abhängig-
keit vom Strukturierungsgrad kann hier zwischen dem narrativen, problemzentrierten,
fokussierten, dem halbstandardisierten Interview sowie dem Experteninterview unter-
schieden werden.
446
Letztgenanntes stellt hinsichtlich Offenheit und Strukturierung
eine gemäßigte Variante dar und eignet sich zur Beantwortung der vorliegenden For-
schungsfragen, da hierbei nicht die teilnehmende Person selbst, sondern primär deren
Erfahrungen und Interpretationen in Bezug auf das Forschungsthema im Vordergrund
stehen.
447
Die Auswahl der Interview-Teilnehmenden innerhalb der zu befragenden Unterneh-
men erfolgte im Rahmen der Vorgespräche gezielt, basierend auf deren Expertenwis-
sen in Bezug auf die Forschungsfragen. Gemäß Bogner et al. (2014) wurden Vorge-
spräche mit den Erst-Kontakten zur Identifikation derjenigen Person mit dem höchsten
Expertenwissen durchgeführt.
448
Das Ziel der Vorgespräche bestand darin, die Kon-
taktperson über die Zielstellung und Rahmenbedingungen der Studie zu informieren
und darauf basierend möglichst aussagefähige Interview-Teilnehmende innerhalb der
Unternehmen zu identifizieren. Weiterhin wurde den Interview-Teilnehmenden der In-
terview-Leitfaden in einer reduzierten Form inklusive relevanter Begriffs-Definitionen
im Vorfeld zur Verfügung gestellt, um eine Vorbereitung und damit gezieltere Beant-
wortung zu ermöglichen.
449
Zur Rekonstruktion des Expertenwissens wird die Datengewinnung mittels eines in-
haltlich vorstrukturierten Leitfadens empfohlen.
450
Dieser dient dem Interviewenden als
445
Vgl. Dücker (2020), S. 118ff.
446
Vgl. Borchardt/Göthlich (2009), S. 38.
447
Vgl. Borchardt/Göthlich (2009), S. 38.
448
Vgl. Bogner et al. (2014), S. 35.
449
Vgl. Bogner et al. (2014), S. 30.
450
Vgl. Dücker (2020), S. 119.
-Modelles 82
Orientierung, um keine inhaltlich relevanten Themen auszulassen und damit die Ver-
gleichbarkeit sicherzustellen.
451
Für diese Fallstudie wird ein semi-strukturierter Leitfa-
den erstellt, welcher fast ausschließlich offene Fragen enthält, um ein gewisses Maß
an Flexibilität zu gewährleisten. Diese Flexibilität erlaubt es u. a., die Reihenfolge und
die inhaltliche Tiefe der beantworteten Fragen dem natürlichen Gesprächsverlauf an-
zupassen.
452
Eine hundertprozentige Standardisierung ist im Gegensatz zur quantitati-
ven Sozialforschung nicht erforderlich, um eine hohe Vergleichbarkeit und Generali-
sierbarkeit erreichen zu können.
453
Die Vergleichbarkeit zwischen den untersuchten
Fällen kann im Rahmen der qualitativen Inhaltsanalyse über den Vergleich und die
Analyse der Codierungen gewährleistet werden.
Bei der Leitfaden-Erstellung fand zunächst basierend auf den gestellten Forschungs-
fragen und den zu untersuchenden Phänomenen eine Unterteilung in Themenblöcke
und Kategorien statt. Im zweiten Schritt wurde in der Literatur für jede Kategorie nach
thematisch passenden Fragen recherchiert. Die auf diesem Wege identifizierten Fra-
gen wurden anschließend hinsichtlich deren Eignung für den vorliegenden For-
schungszweck geprüft, aussortiert und in einigen Fällen in der Formulierung angepasst.
Für die verbleibenden Kategorien wurden schließlich neue Interview-Fragen formuliert.
Der Interview-Leitfaden ist in die folgenden Abschnitte untergliedert:
1. Gesprächseinstieg mit Vorstellung und allgemeinen Hinweisen,
2. Status Quo Probleme & Phänomene,
3. Bewertung LPMM-Modell,
4. Dank, Abmoderation & offene Punkte.
Da der Beginn des Interviews einen großen Einfluss auf den weiteren Verlauf hat, wird
bei dem Gesprächseinstieg darauf geachtet, mit einer offenen und erzählgenerieren-
den Frage eine entspannte Atmosphäre zu schaffen.
454
Nach einer gegenseitigen Vor-
stellung folgen weitere erzählgenerierende Fragen, welche die Probleme und Phäno-
mene im Kontext von Software Multi-Sourcing adressieren. Die Fragen dienen dazu,
ein tiefgreifendes Verständnis der Spezifika des Beschaffungskontextes zu erlangen,
um daraus mögliche Anforderungen an ein LPMM-Modell ableiten zu können. Im drit-
ten Teil des Interviews werden die Teilnehmenden nach konkreten Einschätzungen
451
Vgl. Borchardt/Göthlich (2009), S. 39.
452
Vgl. Bogner et al. (2014), S. 29; Vgl. Dücker (2020), S. 118.
453
Vgl. Bogner et al. (2014), S. 28.
454
Vgl. Borchardt/Göthlich (2009), S. 39.
83 Validierung der Anforderungen und Modellentwicklung anhand einer
Fallstudienuntersuchung
und Lösungsansätzen bezüglich des LPMMs befragt. Weiterhin soll der im Rahmen
dieser Arbeit entwickelte LPMM-Modellentwurf von den Interview-Teilnehmenden be-
wertet werden. Dabei kommen im Wesentlichen Bewertungsfragen und erzählgene-
rierende Fragen zum Einsatz.
455
Bei Unklarheiten oder wenig detaillierten Ausführun-
gen, wird mit Hilfe von Ergänzungsfragen und Sondierungen zu weiteren Detaillierun-
gen angeregt.
456
Auf der Grundlage des erstellten Basisleitfadens wurden mit Hilfe ge-
ringfügiger Anpassungen rollenbezogene Leitfäden für Lieferanten- und OEM-Kontakt-
personen abgeleitet.
457
Außerdem wurde der Leitfaden im Laufe des Untersuchungs-
zeitraumes iterativ angepasst, wenn sich beispielsweise herausgestellt hat, dass be-
stimmte Formulierungen zu Fehlinterpretationen oder Missverständnissen führen oder
nicht die erwarteten Antworten liefern. Alle Änderungen wurden entsprechend begrün-
det und dokumentiert. Als zusätzliche Datenquellen fungierten die Vorgespräche mit
den zuständigen Software-Beschafferinnen und -Beschaffern sowie die vorab erstellen
und von letztgenannten ausgefüllten Projekt-Steckbriefe. Hieraus konnten bereits
erste Erkenntnisse bezüglich Netzwerkkonstellationen und -Charakteristika gewonnen
werden. Im Anhang C ist eine Tabelle mit den Interview-Fragen in ihrer ursprünglichen
Form dargestellt, wobei auf die zu beantwortenden Forschungsfragen und die erwar-
teten Beiträge Bezug genommen wird. Außerdem kann dem Anhang D der finale In-
terview-Leitfaden entnommen werden.
Die Interviews waren auf ca. eine Stunde ausgelegt und fanden via Video-Konferenz
statt. In Tabelle 13 ist eine Übersicht mit deskriptiven Daten zu den durchgeführten
Interviews dargestellt. Die Projekt-IDs entsprechen den Codes, die im Rahmen der
Anonymisierung vergeben wurden. Erkennbar ist, dass in den einzelnen Projekten so-
wohl die Anzahl durchgeführter Interviews als auch die Anzahl der Teilnehmenden je
Interview variiert. Insgesamt wurden im Rahmen der acht untersuchten Fälle 24 Inter-
views mit 32 Teilnehmenden durchgeführt, was eine Gesamtdauer der Interviews von
ca. 26 Stunden ergab. Sieben Interviews wurden mit mehr als einer teilnehmenden
Person durchgeführt, weil im Zuge der Vorgespräche festgestellt wurde, dass eine ein-
zelne Person nicht ausreichend aussagefähig sein würde. In einigen Fällen wurden die
Interview-Teilnehmenden innerhalb eines Interviews zu unterschiedlichen Projekten
455
Vgl. Bogner et al. (2014), S. 6264.
456
Vgl. Bogner et al. (2014), S. 66.
457
Vgl. Bogner et al. (2014), S. 30.
-Modelles 84
befragt, weshalb diese mehrfach in der Liste auftauchen. Hierbei wurden die Teilneh-
menden darauf hingewiesen, in ihren Antworten eine klare Abgrenzung zwischen den
betreffenden Projekten vorzunehmen, wodurch im Nachgang eine projektspezifische
Auswertung gewährleistet ist. Bei den Projekten P10 und P11 war eine Befragung der
OEM-Ansprechpersonen aus organisatorischen Gründen nicht möglich, was das vor-
handene Ungleichgewicht hinsichtlich der Anzahl der befragten Lieferanten- und OEM-
Kontaktpersonen verstärkt.
Tabelle 13: Methodische Übersicht der untersuchten Fälle
458
Projekt-ID
Anzahl Inter-
views
Anzahl Codie-
rende
Position der
Teilnehmen-
den
Anzahl Teilneh-
mende je Inter-
view
Lieferant
OEM
Dauer Interview
[min]
Länge Tran-
skript [A4-Sei-
ten]
P1
5
1
Account Manager
1
X
64
8
Supplier Manager
1
X
X
55
8
Technischer Projektleiter
1
X
58
10
Account Manager
1
X
79
6
Account Manager
1
X
57
11
P3
3
1
Account Manager
1
X
64
8
Projektleiter
1
X
53
7
Program Manager
2
X
56
8
P4
3
1
Account Manager
1
X
64
8
Projektleiter
1
X
53
7
Program Manager
2
X
56
8
P5
4
1
Software Projektleiter
1
X
96
12
unbekannt
1
X
73
12
Abteilungsleiter Elektronik-Archi-
tektur, Teamleiter Entwicklung
2
X
76
11
Supplier Manager (3x), Program
Manager
4
X
102
15
P10
3
1
Technischer Projektleiter
1
X
64
11
Technischer Projektleiter
1
X
84
11
Projektleiter
1
X
43
8
P11
3
1
Technischer Projektleiter
1
X
84
11
Projektleiter
1
X
43
8
Projektleiter
1
X
58
8
P12
5
1
Product Owner Datenbanken
1
X
72
10
Leiter Vertrieb
1
X
76
10
Leiter Vertrieb
1
X
52
14
Leiter Program Management
2
X
73
11
458
Eigene Darstellung.
85 Validierung der Anforderungen und Modellentwicklung anhand einer
Fallstudienuntersuchung
Projekt-ID
Anzahl Inter-
views
Anzahl Codie-
rende
Position der
Teilnehmen-
den
Anzahl Teilneh-
mende je Inter-
view
Lieferant
OEM
Dauer Interview
[min]
Länge Tran-
skript [A4-Sei-
ten]
Customer Solution Manager
2
X
81
15
P14
4
1
Sourcing Manager
2
X
53
9
Program Manager
1
X
51
10
Business Development
1
X
53
8
Account Manager
1
X
57
6
Um eine präzise Auswertung zu ermöglichen, wurden alle Interviews nach vorheriger
Einwilligung der Befragten aufgenommen und anschließend mit Hilfe der Software
MaxQDA transkribiert.
459
Zu diesem Zweck wurden in Anlehnung an Baur/Blasius
(2014) folgende Transkriptionsregeln aufgestellt:
• Verschriftlichung von Standardorthografie, folglich keine Kennzeichnung von
paraverbalen Äußerungen oder Geräuschen,
•
• Kennzeichnung von unverständlichen Passagen mit (unverständlich),
• Generell wörtliche Widergabe des Gesagten,
• Zulässigkeit der Auslassung von Füllwörtern, Wiederholungen, inhaltlich nicht
relevanter Ausschmückungen zur Reduktion des zeitlichen Aufwandes,
• Kennzeichnung eines Sprecherwechsels durch Absatz.
460
Um den Aufwand möglichst gering zu halten, wurde zunächst eine automatisierte Tran-
skription mittels verschiedenster Spracherkennungssoftware getestet. Da die Qualität
der Transkripte nicht den Anforderungen der Autorin entsprach, wurde schließlich eine
manuelle Transkription aller Interviews vorgenommen, woraus sich eine gesamte
Transkript-Länge von 239 A4-Seiten ergab.
Nach der vollständigen Transkription wurde eine Anonymisierung all jener Namen und
Bezeichnungen durchgeführt, die Rückschlüsse auf bestimmte Personen oder Firmen
zulassen: Personennamen, Firmennamen, Projektbezeichnungen, Ortsbezeichnun-
gen, Lieferumfänge, Fahrzeugmodelle. Diese wurden mit Pseudonymen und fortlau-
fender Nummerierung belegt und anschließend in den Transkripten ersetzt, da eine
459
Vgl. Borchardt/Göthlich (2009), S. 40.
460
Vgl. Kuckartz/Rädiker (2014), S. 391.
-Modelles 86
Unterscheidung hinsichtlich bestimmter Merkmale wie Firmen- oder Projekt-Zugehö-
rigkeit für die Auswertung notwendig ist. Über eine Zuordnungsvorschrift, die aus-
schließlich der Autorenschaft dieser Arbeit zugänglich ist, kann eine Rücktransforma-
tion erfolgen.
461
3.4.4 Qualitative Inhaltsanalyse
Die qualitative Inhaltsanalyse stellt ein streng regelgeleitetes Verfahren zur Textinter-
pretation und -analyse dar, welches häufig zum Zweck der Informationsgewinnung bei
der Auswertung von Experteninterviews eingesetzt wird.
462
Mayring (2020) schlägt drei
grundlegende Techniken vor, die im Rahmen von qualitativen Inhaltsanalysen Anwen-
dung finden:
• Zusammenfassungen durch induktive Kategorienbildung,
• Explikationen unklarer Textstellen,
• Strukturierung und Systematisierung durch deduktiv gebildete Kategorien.
463
Die Textanalyse erfolgt stets anhand vorab formulierter Regeln, wie z. B. Ablaufmo-
delle, die an die jeweilige Fragestellung angepasst werden.
464
Zu diesem Zweck kann
eine der o. g. Grundtechniken oder eine Kombination verschiedener Grundformen ge-
nutzt werden.
465
Im Mittelpunkt des Analyseprozesses steht das Kategoriensystem,
welches in der Regel die definierten Kategorien sowie deren Beziehungen zueinander
enthält.
466
Unter einer Kategorie wird das Resultat der Klassifizierung von Einheiten
verstanden.
467
Kuckartz (2016) unterscheidet zwischen den folgenden Kategorie-Arten:
• Fakten-Kategorien (für objektive Gegebenheiten wie z. B. Berufszugehörig-
keit),
• Thematische Kategorien (bezeichnet ein Thema, Argument oder eine Denk-
figur),
• Evaluative Kategorien (bezogen auf externe Bewertungsmaßstäbe, bei-
spielsweise bei Ausprägungen von Kategorien mit ordinalem Skalenniveau),
461
Vgl. Meyermann/Porzelt (2014), S. 6f.
462
Vgl. Mayring/Fenzl (2014), S. 546; Vgl. Bogner et al. (2014), S. 72.
463
Vgl. Mayring (2020), S. 497.
464
Vgl. Mayring (2020), S. 498.
465
Vgl. Mayring (2020), S. 498.
466
Vgl. Bogner et al. (2014), S. 74; Vgl. Mayring (2020), S. 498.
467
Vgl. Kuckartz (2016), S. 31.
87 Validierung der Anforderungen und Modellentwicklung anhand einer
Fallstudienuntersuchung
• Analytische Kategorien (resultiert aus der intensiven Auseinandersetzung
der Codierenden mit den Daten; kann auch in Verbindung mit einer Theorie
stehen).
468
Das Kategoriensystem kann als einfache Liste, als Hierarchie oder auch als Netzwerk
aufgebaut sein.
469
Die Zuordnung von Textstellen zu einer Kategorie erfolgt dabei im
Unterschied zur quantitativen Inhaltsanalyse nie automatisch, sondern in einem regel-
geleiteten Interpretationsprozess.
470
Im Rahmen dieser Dissertation wurde für die Inhaltsanalyse ein deduktiv-induktiver
Mischansatz in Anlehnung an Baur/Blasius (2014) gewählt und mittels der Software
MaxQDA durchgeführt.
471
Die gewählte Vorgehensweise ist auf Abbildung 17 grafisch
dargestellt.
Abbildung 17: Vorgehensweise bei der qualitativen Inhaltsanalyse
472
468
Vgl. Kuckartz (2016), S. 34.
469
Vgl. Kuckartz (2016), S. 38.
470
Vgl. Mayring (2020), S. 498.
471
Vgl. Mayring/Fenzl (2014), S. 552.
472
Eigene Darstellung.
-Modelles 88
Zunächst wurden basierend auf den Forschungsfragen und dem Leitfaden deduktiv
die Hauptkategorien abgeleitet. Dies geschieht in der Regel a-priori und losgelöst von
den empirischen Daten.
473
Die initiale induktive Kategorien-Bildung erfolgte anhand ei-
nes Testlaufes von sechs Dokumenten unterschiedlicher Projekte. Dabei wurde das
bestehende Kategoriensystem durch die Bildung von Unter-Kategorien stetig verfei-
nert. Um die große Datenmenge von 24 Dokumenten und insgesamt 239 A4-Seiten
Transkript möglichst effizient zu codieren, wurde mit zwei Testdurchläufen sowie einer
lexikalischen Suche gearbeitet. Die lexikalische Suche dient dazu, über eine automa-
tisierte Code-Zuweisung anhand festgelegter Suchbegriffe den Codier-Prozess zu be-
schleunigen und die Codierenden bei der Identifikation relevanter Textstellen zu un-
terstützen. Hierzu wurden im Rahmen des zweiten Testdurchlaufes anhand sechs wei-
terer Dokumente die vorab definierten Suchwörter erprobt. Die Herausforderung be-
steht dabei in der Identifikation derjenigen Signalwörter, welche möglichst nur inner-
halb der zugewiesenen Kategorie auftreten, um die Anzahl falsch codierter Textstellen
gering zu halten. Dies gelang lediglich bei sieben Kategorien, wie Tabelle 14 zu ent-
nehmen ist.
Tabelle 14: Suchbegriffe für die lexikalische Suche
474
Kategorie
Suchbegriffe für lexikalische Suche
Anreize
Motiviert, Motivation, Anreiz, motivated, motivation, incentive
Aufgaben-Interdependenz
abhängig*, Wechselwirkung, Interdependen*, verzahnt, ver-
woben, Schnittstell*, interface, wirkkette, angewiesen, depen-
den*
Forced Coopetition
Gezwungen, Wettbewerb, Konkurren*, konkurrierend, forced,
coopetition, competing, competitor, competition
Kollaborative Leistungen
Zusatz*, zusätzlich, unterstütz, unentgeltlich, helping, sup-
port, additional
Persönlicher Hintergrund
Ausbildung, studiert, Studium, Diplom, promoviert, Elektro-
technik, Betriebswirt, Ingenieur, Informatik, education, study,
profession
Position im Projekt
Position, (tätig)>, (zuständig)>, responsible
Rolle im Netzwerk
Verhältnis, Beziehung, "set up", relationship, <(tier), role,
(Aufgabe)>
473
Vgl. Kuckartz (2016), S. 64f.
474
Eigene Darstellung.
89 Validierung der Anforderungen und Modellentwicklung anhand einer
Fallstudienuntersuchung
Nach dem zweiten Testdurchlauf wurde der Codier-Leitfaden, dessen Erstellung pa-
rallel zu den eben beschriebenen Prozessschritten erfolgt ist, finalisiert. Vor dem voll-
ständigen Codier-Durchlauf aller Dokumente wurde das Kategoriensystem mittels des
Creative Coding Tools von MaxQDA als Mind Map visualisiert, umstrukturiert und an-
gepasst. Außerdem wurde in diesem Zuge geprüft, ob das Kategoriensystem disjunkt
und erschöpfend ist.
475
Im anschließenden Codier-Durchlauf aller Dokumente wurden
die automatisch codierten Textstellen geprüft und ggf. gelöscht oder angepasst und
die kontinuierliche Anpassung des Kategoriensystems wurde fortgesetzt. Dabei wurde
darauf geachtet, dass jegliche Änderungen des Kategoriensystems in allen Dokumen-
ten Berücksichtigung finden und sauber dokumentiert werden.
Die im Rahmen der Testläufe codierten Dokumente wurden bei dem gesamten Durch-
lauf ebenso einer erneuten Codierung unterzogen. Der Codier-Leitfaden, auch Kate-
gorienleitfaden genannt, beinhaltet für jede definierte Kategorie Vorschriften und Hilfen
zur Kategorie-Zuweisung.
476
In der Software MaxQDA wurde dies über die Erstellung
von kategoriebezogenen Memos umgesetzt, welche die folgenden Elemente enthalten:
Kategorie-Art, Codier-Regeln, Abgrenzung zu anderen Kategorien, Ausprägungen und
Suchwörter. Zusätzlich wurden die folgenden allgemeinen Codierregeln formuliert:
1. Die Codierung erfolgt in der Regel in Sinneinheiten, mindestens jedoch in
Form eines vollständigen Satzes. Die Länge der Textstelle kann dabei stark
variieren und sollte derart gewählt werden, dass sie ohne den umgebenden
Text verständlich ist.
2. Sofern die (Zwischen-)Frage des Interviewers für das Verständnis notwendig
ist, wird sie ebenfalls codiert.
3. Irrelevante Textstellen werden nicht codiert.
4. Widersprüchliche Aussagen werden beiden zugehörigen Kategorien zugeord-
net.
5. Textpassagen, die nicht eindeutig zugeordnet werden können, werden zu-
tegorie zugewiesen.
6. Grundsätzlich werden alle Textstellen, welche den zu einer Kategorie passen-
den Inhalt aufweisen, als solche codiert → eine Mehrfach-Zuweisung von Ka-
tegorien je Dokument ist folglich erlaubt.
7. Ausnahmen bilden dabei die Unter-
,
475
Vgl. Kuckartz (2016), S. 67.
476
Vgl. Kuckartz (2016), S. 40; Vgl. Mayring/Fenzl (2014), S. 549.
-Modelles 90
Coopetition → Für diese Kategorien darf jeweils nur eine Textstelle je Doku-
ment codiert werden.
8. Mehrfach-Codierungen von Textstellen sind nur für bestimmte Kategorien zu-
lässig, anderenfalls darf eine Textstelle nur einem Code zugewiesen werden
→ Dies ist im Codierleitfaden entsprechend hinterlegt.
9. Textstellen, die als wörtliche Zitate in Frage kommen, werden farblich markiert
(blau).
477
Nach dem vollständigen Codier-Durchlauf wurde eine Plausibilitätsprüfung in den fol-
genden Schritten vorgenommen:
• Prüfung aller Mehrfach-Codierungen auf Zulässigkeit,
• Prüfung, ob zu den folgenden Kategorien Codierungen in allen Dokumenten
gaben-
• Prüfung und ggf. nachträgliche Kategorie-Zuweisung aller Textstellen, die un-
S
• Quercheck hinsichtlich der inhaltlich korrekten Code-Zuweisung, ohne zuvor
auf die zugewiesene Kategorie zu schauen (Intra-Codereliabilität
478
).
Neben der Intra-Codereliabilität stellt die Inter-Codereliabilität ein wesentliches Güte-
kriterium der qualitativen Inhaltsanalyse dar.
479
Dabei wird ein Ausschnitt des Textma-
terials einer weiteren codierenden Person, die zuvor in das bestehende Regelwerk
eingeführt wurde, zur Codierung vorgelegt. Eine Nicht-Übereinstimmung liegt vor,
wenn die zweite der ersten codierenden Person Fehlcodierungen nachweisen kann.
480
Der Einsatz einer zweiten codierenden Person war im Rahmen dieser Dissertation aus
kapazitativen Gründen nicht möglich. Als Ergebnis der qualitativen Inhaltsanalyse lie-
gen das vollständige Kategoriensystem (siehe Anhang E) sowie die zugehörigen Häu-
figkeiten aller Einzelkategorien vor.
481
477
in Anlehnung an Kuckartz (2016), S. 104 und um weitere eigene Regeln ergänzt .
478
Vgl. Mayring (2020), S. 499.
479
Vgl. Mayring (2020), S. 499.
480
Vgl. Mayring (2020), S. 499.
481
Vgl. Mayring/Fenzl (2014), S. 554.
91 Einzelfallanalyse
3.5 Einzelfallanalyse
Im Zuge der fallspezifischen Analyse wird für jedes der untersuchten Projekte eine
Beschreibung der individuellen Projektkonstellation sowie der bestehenden Besonder-
heiten vorgenommen. Die untersuchten Fälle werden in Tabelle 15 hinsichtlich der
Netzwerkkonstellation, der Netzwerkgröße, des Unternehmenssitzes sowie der Rolle
der Akteure innerhalb des Netzwerks vorgestellt. Informationen über die geschätzte
Gesamtgröße des Netzwerks sowie Details über den Vernetzungsgrad und die Anzahl
der Abhängigkeiten zu anderen Steuergeräten wurden den Projektsteckbriefen ent-
nommen, die vorab von den zuständigen Software-Beschafferinnen und -Beschaffern
ausgefüllt wurden. Der Vernetzungsgrad wurde von den Einkäufern auf einer Skala
von 0 (keine Vernetzung) bis 10 (sehr starke Vernetzung) geschätzt.
-Modelles 92
Tabelle 15: Deskriptive Übersicht der untersuchten Fälle
482
Projekt-ID
Besonderheiten
Geschätzte Netz-
werk-Größe
Firmen-ID
Hauptsitz (Land)
Position Inter-
view-Teilneh-
mende
OEM
HW-Lieferant
SW-Lieferant
System-Lieferant
Integrationsver-
antwortung
Dienstleister
Setzlieferant
P1
• 4 Lieferanten aus 4 unter-
schiedlichen Nationen
• Darunter 3 Setz-Lieferan-
ten
• Doppel-Rolle von L2 als
OEM und Lieferant
• 2 Lieferanten mit Integra-
tionsverantwortung
10 -
50
L1
Südkorea
Account Mana-
ger
X
X
X
L2
Deutschland
Supplier Mana-
ger
X
X
X
X
L5
Luxemburg
Account Mana-
ger
X
X
X
L4
USA
Account Mana-
ger
X
X
X
L3
Deutschland
Technischer
Projektleiter
X
P3
• Sehr hoher Vernetzungs-
grad (10)
• Direktes Vertragsverhält-
nis des OEM mit 2 Wett-
bewerbern
• Rolle von L10 als Sys-
tem-Lieferant
• L1 und L10 teilen sich In-
tegrations- und System-
verantwortung
10 -
50
L1
Südkorea
Account Mana-
ger
X
X
X
X
L10
China
Program Ma-
nager (2x)
X
X
X
X
L3
Deutschland
Projektleiter
X
482
Eigene Darstellung.
93 Einzelfallanalyse
Projekt-ID
Besonderheiten
Geschätzte Netz-
werk-Größe
Firmen-ID
Hauptsitz (Land)
Position Inter-
view-Teilneh-
mende
OEM
HW-Lieferant
SW-Lieferant
System-Lieferant
Integrationsver-
antwortung
Dienstleister
Setzlieferant
P4
• Gleiche Konstellation wie
P3, aber Rolle von L10
hier als Software-Tier2
10 -
50
L1
Südkorea
Account Mana-
ger
X
X
X
X
L10
China
Program Ma-
nager (2x)
X
X
L3
Deutschland
Projektleiter
X
P5
• Sehr hoher Vernetzungs-
grad (10) und Komplexität
• Hohe Anzahl beteiligter
3rd Party Software-Liefe-
ranten
• Setz-Lieferant L13 belie-
fert System-Lieferant L6
indirekt über OEM1 / L3
• Größtes Netzwerk
>
100
L13
Deutschland
Abteilungsleiter
Elektronik-Ar-
chitektur,
Teamleiter Ent-
wicklung
X
X
L6
Deutschland
Supplier Mana-
ger (3x), Pro-
gram Manager
X
X
X
X
L3
Deutschland
Software-Pro-
jektleiter
X
OEM1
Deutschland
unbekannt
X
P10
• hohe Anzahl involvierter
Software-Lieferanten,
sehr hoher Vernetzungs-
grad (10), viele Abhängig-
keiten (30)
• 2 Lieferanten mit System-
verantwortung
• L6 liefert sowohl an L17
als auch direkt an OEM2
10 -
50
L19
Irland
Technischer
Projektleiter
X
X
X
L17
Österreich
Technischer
Projektleiter
X
X
X
L6
Deutschland
Projektleiter
X
X
X
-Modelles 94
Projekt-ID
Besonderheiten
Geschätzte Netz-
werk-Größe
Firmen-ID
Hauptsitz (Land)
Position Inter-
view-Teilneh-
mende
OEM
HW-Lieferant
SW-Lieferant
System-Lieferant
Integrationsver-
antwortung
Dienstleister
Setzlieferant
P11
• Nachfolge-Projekt von
P10
• hohe Anzahl involvierter
Software-Lieferanten,
sehr hoher Vernetzungs-
grad (9)
• L17 liefert sowohl direkt
an OEM2 als auch an L6
• Viele Abhängigkeiten
(>10)
10 -
50
L18
Deutschland
Projektleiter
X
X
X
L17
Österreich
Technischer
Projektleiter
X
X
L6
Deutschland
Projektleiter
X
X
X
X
P12
• Ausschließlich Software-
Lieferanten und Dienst-
leister befragt
• Alle befragten Lieferanten
sind Setz-Lieferanten und
beliefern OEM2 nicht di-
rekt
• L26 als neutrale dritte In-
stanz zwischen den direk-
ten Konkurrenten L11
und L25
?
L26
China
Leiter Vertrieb
X
X
X
L11
Niederlande
Leiter Vertrieb
X
X
L25
Niederlande
Leiter Program
Management,
Customer So-
lution Manager
X
X
X
L3
Deutschland
Product Owner
Datenbanken
X
P14
• Hoher Vernetzungsgrad
(8)
0 -
10
L22
Deutschland
Program Ma-
nager
X
X
X
L28
USA
Business De-
velopment
X
X
X
95 Einzelfallanalyse
Projekt-ID
Besonderheiten
Geschätzte Netz-
werk-Größe
Firmen-ID
Hauptsitz (Land)
Position Inter-
view-Teilneh-
mende
OEM
HW-Lieferant
SW-Lieferant
System-Lieferant
Integrationsver-
antwortung
Dienstleister
Setzlieferant
• Geringe Anzahl involvier-
ter Software-Lieferanten
und mittelmäßig viele Ab-
hängigkeiten (5)
• Wettbewerb vorrangig
zwischen L28 und L29,
L28 mit Systemverant-
wortung und L29 mit In-
tegrationsverantwortung
• direkte Lieferbeziehung
von OEM3 nur mit L28,
L22 beliefert L28 und L29
indirekt über OEM3
L29
Schweiz
Account Mana-
ger
X
X
OEM3
Schweden
Sourcing Ma-
nager (2x)
X
-Modelles 96
Die Rollen der Unternehmen innerhalb der Netzwerke wurden von der Autorin der Dis-
sertation nach Auswertung der Interviews bestimmt, da die Informationen in den Pro-
jektsteckbriefen teilweise unvollständig oder widersprüchlich waren. Dabei kann es
vorkommen, dass Unternehmen mehrere Rollen einnehmen, wie z. B. als Software-
und Systemlieferant. Ebenso ist eine Doppelfunktion als OEM und Lieferant möglich.
Es fällt auf, dass in dieser Studie ausschließlich Entwicklungsprojekte mit Setzlieferan-
ten, welche Teilkomponenten an einen anderen Lieferanten liefern und direkt vom
OEM nominiert werden, untersucht werden. Dies legt den Verdacht nahe, dass solche
Lieferantenkonstellationen besonders problembehaftet sein können und daher von
den Beschafferinnen und Beschaffern bevorzugt ausgewählt wurden. Außerdem be-
steht der Verdacht, dass die Doppelbesetzung der System- und Integrationsverant-
wortung durch mehrere Lieferanten sowie das Begleiten verschiedener Rollen durch
einen Lieferanten zu Problemen in der Zusammenarbeit führen kann.
Tabelle 16: Netzwerkkonstellationen und Wortwolken der untersuchten Projekte
483
Pro-
jekt
ID
Grafische Darstellung des Netzwerk-
ausschnittes
Wortwolke
P1
P3
483
Eigene Darstellung.
L1
L2
L5
L4
OEM1 / L3
Lieferbeziehung
Vertragsverhältnis
System-Verantwortung
Software-Lieferant
Hardware-Lieferant
L10 L1
OEM1 / L3
Lieferbeziehung
Vertragsverhältnis
System-Verantwortung
Software-Lieferant
Hardware-Lieferant
97 Einzelfallanalyse
Pro-
jekt
ID
Grafische Darstellung des Netzwerk-
ausschnittes
Wortwolke
P4
P5
P10
L10 L1
OEM1 / L3
Lieferbeziehung
Vertragsverhältnis
System-Verantwortung
Software-Lieferant
Hardware-Lieferant
L13 L6
OEM1 / L3
3rd party
Lieferanten
Lieferbeziehung
Vertragsverhältnis
System-Verantwortung
Software-Lieferant
Hardware-Lieferant
L6
OEM2
L17
L19
Lieferbeziehung
Vertragsverhältnis
System-Verantwortung
Software-Lieferant
Hardware-Lieferant
-Modelles 98
Pro-
jekt
ID
Grafische Darstellung des Netzwerk-
ausschnittes
Wortwolke
P11
P12
P14
In Tabelle 16 sind die Netzwerkkonstellationen der untersuchten Projekte sowie die
mittels MaxQDA erzeugten Wortwolken grafisch dargestellt. Grau umrandete Firmen
stellen relevante Netzwerkakteure dar, die im Rahmen der Studie nicht befragt werden
konnten. Die abgebildeten Wortwolken visualisieren die am häufigsten genannten
Wörter der innerhalb eines Projektes durchgeführten Interviews und können somit ei-
nen ersten Eindruck über die inhaltlichen Schwerpunkte der Gespräche vermitteln. In-
haltlich nicht relevante Füllwörter wurden dabei ausgeschlossen.
Im Folgenden wird eine kurze Darstellung der Projekte hinsichtlich der Gemeinsam-
keiten und projektspezifischen Besonderheiten vorgenommen. Grundsätzlich wurden
L17
OEM2
L6
L18
Lieferbeziehung
Vertragsverhältnis
System-Verantwortung
Software-Lieferant
Hardware-Lieferant
L11
OEM2 / L3
L26
L25 L8
Lieferbeziehung
Vertragsverhältnis
System-Verantwortung
Software-Lieferant
Hardware-Lieferant
OEM3
L28 L29
L22
Lieferbeziehung
Vertragsverhältnis
System-Verantwortung
Software-Lieferant
Hardware-Lieferant
99 Einzelfallanalyse
alle untersuchten Projekte gemäß der in Kapitel 3.4.2 dargestellten Kriterien hinsicht-
lich des Verdachtes auf das Vorliegen der drei Phänomene sowie der Kritikalität aus-
gewählt. In allen Projekten wurden jeweils stark reduzierte Ausschnitte der Lieferan-
tennetzwerke untersucht, welche aus OEM und zwei bis vier Lieferanten bestehen. Mit
Ausnahme von Projekt P12 gibt es in allen Projekten Lieferanten, welche sowohl Hard-
ware als auch Software beliefern. Eine weitere Gemeinsamkeit besteht in der Beteili-
gung von mindestens einem Setzlieferanten bei allen Projekten. Weiterhin fällt auf,
dass bei fünf von acht Projekten bidirektionale Lieferbeziehungen vorliegen und der
Vernetzungsgrad stets als hoch (acht oder mehr) bewertet oder keine Angabe ge-
macht wurde. Dies lässt auf das Vorliegen einer gewissen Komplexität schließen. Die
geringe Distanz der Fälle schlägt sich auch in der hohen Übereinstimmung der erzeug-
ten Wortwolken nieder, wie Tabelle 16 zu entnehmen ist. Insbesondere die Wörter
hohen Häufigkeit auf.
Die Besonderheiten von Projekt P1 bestehen in der hohen Beteiligung von Setzliefe-
ranten, der geteilten Integrationsverantwortung sowie der Doppelrolle von L2 als OEM
und Lieferant, was eine besonders hohe Komplexität der Liefer- und Vertragsbezie-
hungen zur Folge hat. Zu den häufig genannten Wörtern zählen u.
durch das direkte Vertragsverhältnis des OEM mit zwei Wettbewerbern aus. Bei P3
liegt eine geteilte System- und Integrationsverantwortung vor, wohingegen diese Ver-
antwortung bei P4 in der Hand eines Lieferanten liegt, bei einer ansonsten gleichblei-
benden
um das größte der untersuchten Lieferantennetzwerke mit einer besonders großen
Anzahl an Software-Lieferanten, die den OEM jedoch nicht direkt beliefern. Eine wei-
tere Besonderheit besteht in der indirekten Belieferung von L13 an L6 über den OEM
, was auf eine hohe technische Komple-
xität schließen lässt. Im Rahmen der Projekte P10 und P11 war es nicht möglich, den
beauftragenden OEM zu befragen. Die Projektkonstellation beider Projekte unter-
scheidet sich lediglich hinsichtlich der Systemverantwortung, welche bei P10 geteilt ist
und bei dem Folgeprojekt P11 in der Hand eines Lieferanten liegt.
-Modelles 100
bei dem Projekt P1 wurden im Rahmen von Projekt P12 die meisten Setzlieferanten
befragt (drei), welche alle ein direktes Vertragsverhältnis mit dem OEM haben, diesen
jedoch nicht direkt beliefern. Die Lieferbeziehung gleicht hier eher einer Lieferkette als
einem Netzwerk. Dabei fungiert der Lieferant L26 als neutrale Instanz zwischen zwei
direkten Konkurrenten. Besonders häufig wurden in diesem Projekt Per-
Das Projekt
P14 stellt schließlich das kleinste untersuchte Netzwerk mit den wenigsten Abhängig-
keiten dar. Das Besondere an dieser Projekt-Konstellation ist der starke Wettbewerb
zwischen den Firmen L28, welche die Systemverantwortung innehat, und L29, welcher
die Integrationsverantwortung übertragen wurde. L22 liefert Software direkt an den
OEM und hat wenig Berührungspunkte mit den anderen Lieferanten. Zu den am häu-
Nachfolgend wird im Rahmen der Einzelfallanalyse eine ausführliche Charakterisie-
rung der einzelnen untersuchten Projekte vorgenommen. Dabei wird auf die fallspezi-
fische Wahrnehmung der Phänomene sowie weitere ermittelte Probleme und LPMM-
Modellanforderungen Bezug genommen.
484
Als Datenbasis für die Fallzusammenfas-
sungen dienen Tabelle 17 und Tabelle 18. Tabelle 17 bildet die Wahrnehmungsstärke
der Phänomene anhand eines berechneten Scores
485
sowie die ermittelten Anforde-
rungen ab, während Tabelle 18 die fallspezifischen Häufigkeiten der Nennung einzel-
ner Probleme darstellt. Die Häufigkeiten der genannten Anforderungen und Probleme
sind jeweils in eckigen Klammern angegeben und können aufgrund von Mehrfachnen-
nungen die Anzahl der Interviews übersteigen.
484
Für die fallübergreifende Betrachtung der Probleme und Anforderungen sei auf Kapitel 3.6.1 und
3.6.5.1 verwiesen.
485
teilnehmende Person in Bezug auf
die Wahrnehmung der Phänomene unschlüssig sein oder keine Aussage dazu getätigt haben, wurde
dies zur Berechnung des Scores außer Acht gelassen. Der Score kann den Maximalwert der Anzahl
durchgeführter Interviews nicht übersteigen, da Mehrfachnennungen ausgeschlossen waren.
101 Einzelfallanalyse
Tabelle 17: Phänomen-Wahrnehmung und Anforderungen nach Projekten
486
Projekt-ID
Anzahl Inter-
views
Aufgaben-Inter-
dependenz
Forced
Coopetition
Kollaborative
Leistungen
Anforderungen
P1
5
5
3
2
Multi-Dimensionalität [4]; Berücksichtigung von Sub-
Lieferanten [2], klar abgegrenzte Verantwortlichkeiten
& Schnittstellen [2], Flexibilität [1], Transparenz [1],
Kollektivität [1], Abhängigkeiten abbilden [1], Messung
auf ind. & agg. Ebene [1]
P3 /
P4
3
3
3
3
Synchronisation von Anforderungen [1], Multi-Dimen-
sionalität [1], Flexibilität [1], Transparenz [1], Eigen-
verantwortung [1], klar abgegrenzte Verantwortlich-
keiten & Schnittstellen [1], Messung auf ind. & agg.
Ebene [1]
P5
4
3
3
3
Multi-Dimensionalität [9], Kollektivität [3], Flexibilität
[3], Berücksichtigung von Abhängigkeiten [3],
paritätische Besetzung der Verantwortlichkeiten [2],
klar abgegrenzte Verantwortlichkeiten & Schnittstellen
[2], Messung auf ind. & agg. Ebene [1], Transparenz
[1], kürzere Iterationen [1], mit gleichem Maßstab
messen [1], Definition der Frequenz [1]
P10
3
2
2
3
klar abgegrenzte Verantwortlichkeiten & Schnittstellen
[4], Multi-Dimensionalität [2], Abhängigkeiten abbilden
[1], kürzere Iterationen [1], Messung auf ind. & agg.
Ebene [1]
P11
3
2
2
3
Kollektivität [3], Transparenz [2], Abhängigkeiten ab-
bilden [2], klar abgegrenzte Verantwortlichkeiten &
Schnittstellen [1],
P12
5
5
4
5
Abhängigkeiten abbilden [4], klar abgegrenzte Verant-
wortlichkeiten & Schnittstellen [4], Kollektivität [3],
Transparenz [3], Multi-Dimensionalität [2], mit glei-
chem Maßstab messen [1], Kontinuität [1]
P14
4
0
2
4
Kollektivität [4], Multi-Dimensionalität [4], Messung auf
ind. & agg. Ebene [3], Abhängigkeiten abbilden [1],
klar abgegrenzte Verantwortlichkeiten & Schnittstellen
[1], Vertrauen [1], Transparenz [1]
Bei dem besonders komplexen Projekt P1 wurde das Phänomen Aufgaben-Interde-
pendenz uneingeschränkt von allen Interview-Teilnehmenden wahrgenommen und er-
486
Eigene Darstellung.
-Modelles 102
zielt damit den höchsten Wert unter den zu untersuchenden Phänomenen. Das fol-
gende Zitat der Firma L1 unterstreicht die hohe Relevanz von Aufgaben-Interde-
pendenz innerhalb dieses Projektes:
Die größte Herausforderung bei der Fahrzeugentwicklung ist heutzutage die In-
terdependenz zwischen verschiedenen Komponenten, Sensoren, Aktuatoren,
Kameras, Steuergeräten und die Sicherstellung, dass alle Zulieferer zusam-
menarbeiten, um den Stand der Entwicklung anzugleichen.
Tabelle 18: Fallspezifische Wahrnehmung von Problemen
487
Sonstige Probleme
P14
P12
P11
P5
P3 /
P4
P1
P10
Total
Prozess-Inkompatibilität
0
0
1
3
0
0
1
5
Komplexität
0
1
0
1
1
3
0
6
Integration & Schnittstellen
0
1
2
4
0
1
1
9
Spezifikation
2
3
2
1
0
0
2
10
Rollenverständnis und -
wahrnehmung
2
0
1
5
1
4
1
14
Verantwortlichkeiten
1
2
2
5
0
9
2
21
fehlende Weisungsbefugnis /
indirekte Beziehung
0
0
0
0
2
3
1
6
Kommunikationsprobleme
3
4
2
3
0
5
3
20
Software Know-How
1
1
1
2
1
0
1
7
sich ändernde Anforderun-
gen
0
0
1
1
1
1
1
5
unrealistische Projektpla-
nung
1
0
1
2
0
0
0
4
Vision / Gesamtüberblick
fehlt
0
0
2
0
0
2
2
6
Sonstige
0
2
0
4
3
5
0
14
SUMME
10
14
15
31
9
33
15
127
N = Dokumente
4
5
3
4
3
5
3
27
Wie dieses beispielhafte Zitat zeigt, wurden Im Rahmen der Interviews zu P1 insbe-
sondere viele Abhängigkeiten als auch daraus resultierender Koordinationsbedarf im
Zusammenhang mit dem Phänomen Aufgaben-Interdependenz beschrieben. Es wer-
den außerdem die meisten Spannungen im Zusammenhang mit Forced Coopetition
wahrgenommen, vor allem Interessenskonflikte, kontraproduktives Verhalten und ein-
geschränkter Informationsaustausch, wobei dies vorwiegend als ungewollter Neben-
effekt eingeschätzt wird. Unter kollaborativen Leistungen verstehen die Befragten
487
Eigene Darstellung.
103 Einzelfallanalyse
mehrheitlich den zu leistenden Koordinations- und Steuerungsaufwand. Des Weiteren
wurde im Rahmen der Interviews eine Vielzahl weiterer Probleme adressiert, darunter
mit Abstand am häufigsten Probleme durch unklare Verantwortlichkeiten, aber auch
Kommunikationsprobleme und ein unklares Rollenverständnis. Hinsichtlich der ge-
nannten Anforderungen liegt der Fokus klar auf der Multi-Dimensionalität des LPMM-
Modelles. Die Befragten halten u. a. eine Unterscheidung hinsichtlich unterschiedli-
cher Vertragsarten sowie eine Messung auf mehreren Ebenen für notwendig. Außer-
dem sei die Berücksichtigung von Unter-Lieferanten in der Performance Messung so-
wie eine klare Abgrenzung von Verantwortlichkeiten und Schnittstellen erforderlich.
Die Projekte P3 und P4 werden zusammengefasst betrachtet, da alle Interview-Teil-
nehmenden jeweils gleichzeitig zu beiden Projekten befragt wurden und eine scharfe
Abgrenzung aufgrund der ähnlichen Projekt-Konstellation schwer möglich ist. Die Pro-
jekte zeichnen sich durch die höchste Wahrnehmungsstärke aller drei Phänomene aus.
Neben den zahlreichen beschriebenen Abhängigkeiten scheint insbesondere die Kon-
kurrenzsituation zu Problemen zu führen, wie das folgende Zitat der Firma L10 belegt:
-Rolle
gegenüber OEM1 auftreten, ist es einfacher, weil weniger Stakeholder in die Kom-
munikation eingebunden sind. Weil dort das Auftragsverhältnis klar ist oder das
Abhängigkeits- und Transparenz-Gebaren ein anderes ist als in der Abhängigkeit
Die Wettbewerbs-Situation gepaart mit einer fehlenden Weisungsbefugnis gegenüber
des jeweils anderen Lieferanten wird von den Interview-Teilnehmenden als problem-
behaftet wahrgenommen. Das Phänomen Forced Coopetition wird hier überwiegend
als ungewollter Nebeneffekt beobachtet, jedoch werden zahlreiche daraus resultie-
rende Spannungen erläutert, allen voran ein eingeschränkter Informationsaustausch.
Anforderungen an das LPMM wurden innerhalb der beiden Fälle kaum angesprochen.
Hervorzuheben ist die klare Abgrenzung von Verantwortlichkeiten und Schnittstellen,
was im Fall von geteilter Verantwortung, Aufgaben-Interdependenz sowie Forced Coo-
petition Abhilfe schaffen kann.
Bei dem Projekt P5 gab es insgesamt wenig Äußerungen im Zusammenhang mit den
Phänomenen Aufgaben-Interdependenz, Forced Coopetition und kollaborative Leis-
tungen, welche gemäß der Einschätzung der Teilnehmenden gleichermaßen relevant
zu sein scheinen. In den Interviews wurden jedoch besonders viele weitere Probleme
-Modelles 104
thematisiert, vor allem solche, die durch ein falsches Rollenverständnis und unklare
Verantwortlichkeiten sowie Schnittstellen- und Integrationsprobleme bedingt sind, was
anhand des nachfolgenden Zitats von Firma L13 verdeutlicht wird:
Zu den am häufigsten genannten Anforderungen im Rahmen des Projektes P5 zählen
Kollektivität, Flexibilität und Multi-Dimensionalität. Insbesondere eine Unterscheidung
hinsichtlich Funktions-Clustern wurde von den Teilnehmenden mehrfach vorgeschla-
gen. Entgegen den Erwartungen wurden in diesem Projekt die wenigsten Spannungen
durch Forced Coopetition wahrgenommen. Denkbar wäre es, dass aufgrund der hohen
Komplexität und der enormen Netzwerk-Größe andere Probleme vordergründig wahr-
genommen werden und somit die Zusammenarbeit mit Wettbewerbern in den Hinter-
grund rückt.
Im Projekt P10 stehen kollaborative Leistungen im Fokus, welche aufgrund eines ho-
hen Vernetzungsgrades, vielen Abhängigkeiten und einer hohen Anzahl involvierter
Software-Lieferanten besonders relevant zu sein scheinen. Diese wurden vor allem in
Form von zusätzlichem Entwicklungs- und Kommunikationsaufwand wahrgenommen.
Ein hohes Maß an Kollaboration wird durch zahlreiche vertikale sowie horizontale Lie-
ferbeziehungen zwischen den befragten Lieferanten erforderlich. Außerdem liegt eine
geteilte Systemverantwortung zwischen den Lieferanten L17 und L19 vor. Diese Kons-
tellation scheint insbesondere Probleme bei der Kommunikation und der Zuweisung
von Verantwortlichkeiten zu Problemen zu führen, wie das folgende Zitat der Firma L6
belegt:
den Lieferanten nicht klar genug definiert hat und dann gab es bedingt immer Miss-
.
Folglich wurde auch hier die klare Abgrenzung von Verantwortlichkeiten und Schnitt-
stellen besonders häufig als Anforderung vorgeschlagen.
Bei dem Projekt P11 handelt es sich um das Nachfolger-Projekt von P10. Diese Infor-
mation ist insofern relevant, als dass hier bewusst eine von P10 abweichende Liefe-
rantenkonstellation gewählt wurde, um die Probleme aus dem Vorgänger-Projekt maß-
105 Einzelfallanalyse
geblich zu verhindern. Auch hier liegen ein hoher Vernetzungsgrad (9), viele Abhän-
gigkeiten (>10) und eine große Anzahl involvierter Software-Lieferanten vor, jedoch
wurde mit L6 nur einem Lieferanten die gesamte Systemverantwortung übertragen. Im
Gegensatz zum P10 Projekt sind hier mehr Setz-Lieferanten involviert, was die er-
wähnten Kommunikationsprobleme und Probleme durch unklare Verantwortlichkeiten
und Schnittstellen verursacht haben könnte. Diese Problematik wird im Rahmen des
Interviews mit L17 wie folgt beschrieben:
ich eine gewisse Schwierigkeit darin, dass auch hier in einem sehr komplexen Pro-
jekt der Setup nicht sehr gut funktioniert mit einem Setz-Teil einerseits, weil diese
Dreiecks-Kommunikation einfach natürliche Konflikte schafft, das heißt der OEM2
.
Ebenso wie im Fall P10 werden hinsichtlich der untersuchten Phänomene kollabora-
tive Leistungen am stärksten wahrgenommen. In Bezug auf den besseren Umgang mit
Forced Coopetition wünschen sich die Teilnehmenden beispielsweise mehr Modera-
tion und Mediation seitens OEM. Im Zusammenhang mit Aufgaben-Interdependenz
werden von den Teilnehmenden zahlreiche Abhängigkeiten beschrieben, welche auf-
grund der komplexen Lieferbeziehungen entstehen. Im Vergleich zu P10, werden hier
vorrangig kollektive Prozesse in Form von gemeinsamen Abstimmungen, Meetings
und Reportings sowie transparente Prozesse und Strukturen als wesentliche Anforde-
rungen für das LPMM angeführt.
Bei dem Projekt P12 haben alle drei Phänomene eine starke Wahrnehmung erfahren,
wobei Forced Coopetition nicht von allen Teilnehmenden wahrgenommen wurde.
Spannungen im Zusammenhang mit diesem Phänomen werden mittelmäßig viele
wahrgenommen, was dafürsprechen kann, dass die Konstellation mit einer neutralen
dritten Instanz den Effekt von Forced Coopetition abmildern kann. Zu den am häufigs-
ten genannten Problemen zählen Kommunikationsprobleme, eine unvollständige Spe-
zifikation sowie unklare Verantwortlichkeiten. Kollaborative Leistungen wurden am
häufigsten in Form von zusätzlichem Entwicklungsaufwand wahrgenommen, was teil-
weise auf eine unvollständige Spezifikation zurückzuführen sein könnte. In Bezug auf
das Phänomen Aufgaben-Interdependenz gab es zahlreiche Beschreibungen von Ab-
hängigkeiten und Kommunikationsproblemen, was durch das folgende Zitat der Firma
L25 verdeutlicht wird:
-Modelles 106
, wenn jetzt alle beteiligten Unternehmen ähnliche Interessen haben und
mit positiven Ansätzen reingehen, werden Sie immer die Schwierigkeit haben,
dass Abhängigkeiten da sind. Dass z. B. Unternehmen zwei eine Zulieferung von
Unternehmen eins braucht und, dass Unternehmen zwei möglicherweise
schlechte KPIs hat, weil das Unternehmen eins
Dementsprechend werden das Abbilden von Abhängigkeiten sowie klar abgegrenzte
Verantwortlichkeiten und Schnittstellen am häufigsten als Anforderungen vorgeschla-
gen. Außerdem wurden Kollektivität und Transparenz mehrfach genannt, womit sich
möglicherweise die auftretenden Kommunikationsprobleme reduzieren ließen.
Bei dem Projekt P14 wird das Phänomen Forced Coopetition erwartungsgemäß mit
Ausnahme von L22 von allen übrigen Teilnehmenden wahrgenommen. Der Vernet-
zungsgrad fällt in diesem Projekt etwas geringer aus, jedoch sind auch hier horizontale
wie vertikale bidirektionale Lieferbeziehungen zu verzeichnen. Hinsichtlich der Exis-
tenz von Aufgaben-Interdependenz herrscht unter den Befragten eine geteilte Meinung,
wohingegen Forced Coopetition mehrheitlich und kollaborative Leistungen von allen
Interview-Teilnehmenden einstimmig wahrgenommen werden. Während Abhängigkei-
ten kaum geschildert werden, beschreiben die Teilnehmenden zahlreiche Spannun-
gen im Zusammenhang mit Forced Coopetition, insbesondere eine generelle Anspan-
nung und Zurückhaltung der Projektpartner sowie einen eingeschränkten Informati-
onsaustausch. Dem entgegenwirken könne man mit kollektiven Prozessen und ver-
trauensbildenden Maßnahmen, wie dieses Zitat von L22 verdeutlicht:
Wobei man dann wirklich ein gemeinsames Steering-Meeting braucht wo man
auch offen darüber sprechen kann. Gerade wenn man ein Netzwerk misst, ist es
wichtig, dass man ein vertrauensvolles Verhältnis mit allen Parteien hat, damit
keine Schuldzuweisungen entstehen. Ich glaube, dann ist gerade diese gemein-
same Zusammenarbeit, das gemeinsame Ziel ist sehr wichtig .
Außerdem werden von den Teilnehmenden Multi-Dimensionalität und dahingehen ins-
besondere die Performance Messung auf mehreren Ebenen als wesentliche Anforde-
rungen für das LPMM genannt.
Bezugnehmend auf das Klassifikationsschema von Wiener/Saunders (2014) (siehe
Tabelle 10) kann festgestellt werden, dass jedes der untersuchten Projekte dem Typ
direct-overlapping kann. Diese Zuordnung kann aufgrund der
107 Ergebnisse aus fallübergreifender Analyse
mittelstarken bis starken Wahrnehmung von Forced Coopetition, der überlappenden
Kompetenzbereiche der Lieferanten sowie der bestehenden Vertragsverhältnisse des
OEM mit mehreren Lieferanten vorgenommen werden.
3.6 Ergebnisse aus fallübergreifender Analyse
In den folgenden Kapiteln werden die Ergebnisse der fallübergreifende Analyse prä-
sentiert. Dem Aufbau des eingangs entwickelten Bezugsrahmen folgend, wird dabei
zunächst auf die ermittelten Probleme eingegangen, welche sich bei den kritischen
Faktoren und Risiken [3] und damit den allgemeinen Kontext-Faktoren einordnen las-
sen. Anschließend wird der Erkenntnisgewinn zu den untersuchten Phänomenen
Forced Coopetition [5], Aufgaben-Interdependenz [6] und kollaborative Leistungen [12]
erläutert. Dabei wird der Versuch unternommen, Zusammenhänge zwischen den er-
mittelten Anforderungen und den Phänomenen herzustellen. Darauffolgend werden
die Erkenntnisse zur Lieferanten-Performance [7] und Netzwerk-Performance [8] so-
wie der erfolgreichen Integration von Embedded Software [11] vorgestellt. Schließlich
werden in Kapitel 0 die ermittelten Anforderungen für das Lieferanten Performance
Management und Measurement auf Netzwerk-Ebene [10] und Akteurs-Ebene [9] so-
wie das darauf basierende LPMM-Modell und die induktiv ermittelten Handlungs- und
Gestaltungsempfehlungen präsentiert. Abschließend werden Impulse aus theoreti-
schen Erklärungsansätzen dargelegt.
3.6.1 Erkenntnisse zu Kontextfaktoren
Zur Beantwortung von FF 1a wurde eine Analyse der von den Interview-Teilnehmen-
den genannten Probleme vorgenommen. Mit Blick auf Tabelle 18 kann festgestellt
werden, dass Kommunikationsprobleme und unklare Verantwortlichkeiten zu den am
häufigsten wahrgenommenen Problemen zählen. Grundsätzlich lässt sich ein Teil der
Probleme durch Maßnahmen im Rahmen des Software-Projektmanagements lösen.
Ein anderer Teil, wie z. B. Rollenverständnis und -wahrnehmung, unklare Verantwort-
lichkeiten oder Kommunikationsprobleme können im Rahmen eines LPMMs adressiert
werden.
Tabelle 19 kann die Wahrnehmung der Probleme aus Lieferanten- und Abnehmersicht
entnommen werden. Aus Lieferantensicht überwiegen Probleme durch eine unvoll-
ständige Spezifikation, unklare Verantwortlichkeiten sowie beim Rollenverständnis,
wohingegen bei OEM-Kontaktpersonen Integrations- und Schnittstellenprobleme,
-Modelles 108
mangelndes Software-Know-How und Komplexitätsprobleme dominieren. Eine Über-
einstimmung besteht bei dem Kommunikationsaspekt, da Kommunikationsprobleme
sowohl aus Lieferanten- als auch aus OEM-Sicht häufig genannt wurden. Auffällig ist,
dass eine unvollständige Spezifikation und sich ändernde Anforderungen ausschließ-
lich aus Lieferantensicht als problematisch wahrgenommen werden, obwohl diese
Themenfelder klar im Verantwortungsbereich des OEM liegen.
Tabelle 19: Probleme aus OEM- und Lieferantenperspektive
488
Lieferant
OEM
Probleme
Anzahl
%
Anzahl
%
Total
Prozess-Inkompatibilität
1
1,7%
1
4,3%
2
Komplexität
2
3,4%
3
13,0%
5
Integration & Schnittstellen
4
6,8%
4
17,4%
8
Spezifikation
8
13,6%
0
0
8
Rollenverständnis und -wahrnehmung
6
10,2%
2
8,7%
8
Verantwortlichkeiten
9
15,3%
1
4,3%
10
fehlende Weisungsbefugnis / indirekte
Beziehung
3
5,1%
2
8,7%
5
Kommunikationsprobleme
10
16,9%
3
13,0%
13
Software-Know-How
2
3,4%
4
17,4%
6
sich ändernde Anforderungen
4
6,8%
0
0
4
unrealistische Projektplanung
3
5,1%
1
4,3%
4
Vision / Gesamtüberblick fehlt
2
3,4%
0
0
2
Sonstige
5
8,5%
2
8,7%
7
SUMME
59
23
82
N = Dokumente
18
6
24
3.6.2 Erkenntnisse zu netzwerkspezifischen Phänomenen
Bei einer fallübergreifenden Betrachtung fällt auf, dass grundsätzlich alle zu untersu-
chenden Phänomene in den untersuchten Projekten bei einer variierenden Wahrneh-
mungsstärke Relevanz aufweisen. Die einzige Ausnahme bildet dabei das Phänomen
der Aufgaben-Interdependenz, welches im Projekt P14 aufgrund einer zweigeteilten
Experteneinschätzung einen Score von 0 erreicht. Dies lässt sich vermutlich darauf
zurückführen, dass es sich bei diesem Projekt um das kleinste der untersuchten Lie-
feranten-Netzwerke mit vergleichsweise wenig Abhängigkeiten zwischen den Liefe-
488
Eigene Darstellung.
109 Ergebnisse aus fallübergreifender Analyse
ranten handelt. Somit kann die generelle Relevanz der Phänomene Forced Coopeti-
tion, Aufgaben-Interdependenz und kollaborative Leistungen für den vorliegenden Un-
tersuchungskontext bestätigt werden.
Es kann weiterhin festgestellt werden, dass Forced Coopetition in keinem der Projekte
das dominierende Phänomen mit der stärksten Wahrnehmung darstellt. Der maximale
Score wird lediglich in den Projekten P3 und P4 erreicht, wobei jeweils alle drei unter-
suchten Phänomene eine äquivalente Wahrnehmungsstärke erfahren haben. Unter
den in Zusammenhang mit Forced Coopetition beobachteten Spannungen wurde ein
eingeschränkter Informationsaustausch aufgrund von Datenschutz-Bedenken mit Ab-
stand am häufigsten genannt (18 Nennungen) und sowohl aus Lieferanten- als auch
aus OEM-Sicht wahrgenommen. Außerdem waren Spannungen durch Interessens-
konflikte (8 Nennungen), eine generelle Zurückhaltung & Anspannung (8 Nennungen)
sowie ein ablehnendes, kontraproduktives Verhalten (5 Nennungen) mehrfach zu ver-
zeichnen, wobei letztgenanntes ausschließlich von Lieferanten wahrgenommen wurde.
Zu den am häufigsten genannten Maßnahmen zählen in diesem Zusammenhang Ver-
träge und Zusatzvereinbarungen (7 Nennungen), Moderation und Mediation durch den
OEM (5 Nennungen) und eine starke Führung seitens OEM (4 Nennungen). Das Phä-
nomen ist mehrheitlich als unbewusst herbeigeführt bewertet worden. Bei einem Ver-
gleich der OEM- und Lieferantenperspektive zeigt sich hierbei jedoch ein entscheiden-
der Unterschied: Die Mehrheit der Lieferanten nimmt Forced Coopetition als bewusst
eingesetztes Mittel wahr, wohingegen alle OEM-Ansprechpersonen dies als einen un-
bewusst auftretenden Nebeneffekt verstehen.
489
Insgesamt wird das Phänomen von
Lieferanten-Kontaktpersonen prozentual häufiger wahrgenommen als von OEM-Kon-
taktpersonen. Hinsichtlich der Lieferanten-Rollen können bei der Wahrnehmung von
Forced Coopetition kaum Unterschiede festgestellt werden: Mit Ausnahme der Dienst-
leister (67 %) liegt die Wahrnehmung bei allen Lieferanten-Rollen bei über 80 %.
Aufgaben-Interdependenz dominierte in den Projekten P1 und P12 und die kollabora-
tiven Leistungen stellten in insgesamt vier Projekten (P10, P11, P12, P14) das domi-
nierende Phänomen dar. Beide Phänomene werden aus Lieferanten- und OEM-Sicht
gleichermaßen stark wahrgenommen. Lieferanten verstehen unter kollaborativen Leis-
tungen primär zusätzliche Entwicklungsaufwände, Kommunikationsaufwand sowie
489
Die entsprechende Frage wurde dem Interview-Leitfaden erst im Laufe des Untersuchungszeitrau-
mes hinzugefügt. Folglich gab es in einigen Interviews keine Stellungnahme dazu.
-Modelles 110
Unterstützungsleistungen bei der Fehlersuche, wohingegen aus OEM-Sicht darunter
hauptsächlich ein zusätzlicher Ressourceneinsatz zu verstehen ist. Bei der Unter-
scheidung hinsichtlich Lieferanten-Rollen zeichnet sich ein differenzierteres Bild ab.
Aufgaben-Interdependenz wird besonders stark von Software-Lieferanten und Integra-
toren wahrgenommen (80 100 %). Im Gegensatz dazu liegt die Wahrnehmung bei
Dienstleistern, System- und Hardware-Lieferanten lediglich bei 57 67 %. Kollabora-
tive Leistungen werden im Gegensatz dazu am stärksten von Dienstleistern (100 %)
und am geringsten von Integratoren (67 %) wahrgenommen. Einzig die Gruppe der
Software-Lieferanten scheint von allen drei Phänomenen gleichermaßen stark betrof-
fen zu sein, da die Wahrnehmungsstärke jeweils bei 81 % liegt.
Da die drei Phänomene in nahezu allen Projekten in unterschiedlicher Intensität wahr-
genommen wurden, war eine isolierte Betrachtung einzelner Phänomene und damit
eine eindeutige Zuordnung der ermittelten Anforderungen nicht möglich. Vielmehr kön-
nen auf diesem Weg Vermutungen über Zusammenhänge zwischen Phänomenen und
Anforderungen aufgestellt werden. Aus diesem Grund wurde basierend auf den ermit-
telten Merkmalen aus Tabelle 9 im Rahmen der Inhaltsanalyse der Versuch einer An-
forderungs-Phänomen-Zuordnung vorgenommen. Über die erneute Analyse der als
Anforderungen und Elemente codierten Textstellen konnte schließlich bei der knappen
Hälfte der ermittelten Anforderungen und Elementen eine Verknüpfung zu mindestens
einem der Phänomene hergestellt werden. Eine eindeutige Zuordnung konnte zwi-
schen der Berücksichtigung von Abhängigkeiten und dem Phänomen Aufgaben-Inter-
dependenz bei 10 von 12 Nennungen hergestellt werden. Außerdem wurde die For-
derung nach Transparenz in diesem Zusammenhang im Rahmen von zwei Projekten
genannt. Lediglich die Anforderungen der Multi-Dimensionalität sowie die klare Ab-
grenzung von Verantwortlichkeiten konnten allen drei Phänomenen zugeordnet wer-
den. Die Notwendigkeit eines Anreizsystems wurde in zwei Fällen in direkten Zusam-
menhang mit kollaborativen Leistungen gebracht.
Hinsichtlich der ermittelten Probleme und Anforderungen gibt es starke Überschnei-
dungen zwischen Aufgaben-Interdependenz und kollaborativen Leistungen. Insbeson-
dere unklare Verantwortlichkeiten und Kommunikationsprobleme wurden in diesem
Zusammenhang häufig erwähnt. Klar abgegrenzte Verantwortlichkeiten und Schnitt-
stellen, die Berücksichtigung von Abhängigkeiten, Transparenz, Multi-Dimensionalität
111 Ergebnisse aus fallübergreifender Analyse
und Kollektivität gehören zu den Anforderungen, welche in von Aufgaben-Interdepen-
denz und kollaborativen Leistungen dominierten Projekten am häufigsten angespro-
chen wurden. Die Berücksichtigung von Unter-Lieferanten im Rahmen des LPMM fand
ausschließlich in Projekt P1 Erwähnung und kann damit primär mit Aufgaben-Interde-
pendenz in Verbindung gebracht werden, wohingegen vertrauensbildende Maßnah-
men lediglich im von kollaborativen Leistungen dominierten Projekt P14 vorgeschlagen
wurden.
Im Projekt P5, welches durch eine enorme Netzwerk-Größe und hohe Komplexität ge-
kennzeichnet ist, wurden die drei untersuchten Phänomene gleichermaßen stark wahr-
genommen. Im Rahmen dieses Projektes wurden insbesondere die Anforderungen
Multi-Dimensionalität, Flexibilität und die Berücksichtigung von Abhängigkeiten häufig
genannt und scheinen folglich im Kontext von allen drei Phänomenen von Bedeutung
zu sein. Eine klare Abgrenzung bzw. eindeutige Zuordnung zu einem der Phänomene
kann basierend auf den erhobenen Daten nicht vorgenommen werden. In Projektkons-
tellationen mit einer hohen Beteiligung von Setz-Lieferanten (P1, P11, P12), scheint
es hinsichtlich der Wahrnehmung der Phänomene keine eindeutige Tendenz zu geben.
Es kann jedoch festgestellt werden, dass es in diesen drei Projekten besonders häufig
zu unklaren Verantwortlichkeiten und Kommunikationsproblemen gekommen ist. Hier
wurden Kollektivität, Transparenz und die Berücksichtigung von Abhängigkeiten von
den Teilnehmenden als wesentliche Anforderungen für das LPMM eingeschätzt.
3.6.3 Erkenntnisse zur Lieferanten- und Netzwerk-Performance
Im Rahmen der Inhaltsanalyse wurden auch Aussagen der Teilnehmenden hinsichtlich
der individuellen sowie der Netzwerk-Performance codiert. In Hinblick auf die Beant-
wortung von FF 1c wurden darauf basierend die wesentlichen Einflussfaktoren auf die
Lieferanten- und Netzwerkperformance abgeleitet. Auf Abbildung 18 ist ein Balkendi-
agramm dargestellt, welches die Häufigkeiten der Nennung aller identifizierten Ein-
flussfaktoren gruppiert nach OEM- und Lieferantensicht abbildet. Neben den Faktoren
Kommunikation und Komplexität befinden sich auch die drei untersuchten Phänomene
unter den Haupteinflussfaktoren mit mehr als fünf Nennungen, wobei Aufgaben-Inter-
dependenz am häufigsten genannt wurde. Damit kann die Relevanz der Phänomene
und damit der gewählte Fokus der Untersuchung erneut bestätigt werden. Bei der Un-
terscheidung zwischen der Lieferanten- und Abnehmerperspektive ist das ungleiche
Verhältnis von Lieferanten- zu OEM-Ansprechpersonen von 3:1 zu berücksichtigen.
-Modelles 112
Dabei fällt auf, dass die Phänomene Forced Coopetition und Aufgaben-Interdepen-
denz hauptsächlich aus Lieferantensicht und eine fehlende Weisungsbefugnis, Pro-
zess-Inkompatibilität sowie eine unvollständige Spezifikation hauptsächlich aus OEM-
Sicht als Einflussfaktoren auf die Performance wahrgenommen werden.
Abbildung 18: Einflussfaktoren auf die Lieferanten- und Netzwerk-Performance
490
Bei den genannten Einflussfaktoren kann weiterhin zwischen positiven und negativen
Einflüssen sowie zwischen der individuellen und der Netzwerkebene unterschieden
werden. Auf Abbildung 19 sind die ermittelten Einflussfaktoren auf einer 3x2-Perfor-
mance-Matrix dargestellt, wobei auf der X-Achse zwischen der Art des Einflusses und
auf der Y-Achse zwischen der Aggregationsebene differenziert wird. In Fällen, in de-
nen die Aussagen, keiner Aggregationsebene eindeutig zugeordnet werden können,
lisiert, deren Größe mit der Anzahl der Nennungen einhergeht. Hier kann es vorkom-
men, dass Einflussfaktoren mehreren Matrix-Feldern zugeordnet werden, da sich die
Wahrnehmung in Abhängigkeit vom Projekt oder der Unternehmens-Rolle unterschei-
den kann. Erkennbar ist, dass die Interview-Teilnehmenden vorwiegend Aussagen zu
negativen Performance-Einflüssen treffen. Dies lässt sich vermutlich auf die Auswahl
besonders problembehafteter Projekte zurückführen und kann zu einer Ergebnisver-
zerrung führen. Der Haupteinflussfaktor Aufgaben-Interdependenz wird am häufigsten
490
Eigene Darstellung.
113 Ergebnisse aus fallübergreifender Analyse
im Zusammenhang mit der Netzwerk-Performance erwähnt, was größtenteils mit einer
hoch komplexen, verteilten Architektur und daraus resultierenden Abhängigkeiten ein-
her geht, wie nachfolgendes Zitat von L13 zeigt:
-Lieferanten wieder etwas ändern muss, das
ist viel komplexer und langwieriger, als wenn man das über ein Bauteil lösen kann.
Mit den Anlaufschwierigkeiten bei K8, das hat nicht nur uns betroffen, sondern die
anderen auch. Das hat definitiv zu Ineffizienzen geführt, aber wir wissen nicht,
Außerdem scheinen sich die inhärente Komplexität, eine fehlende Weisungsbefugnis
sowie Probleme bei der Integration und Schnittstellen insbesondere auf die Netzwerk-
Performance auszuwirken.
Abbildung 19: Matrix der Performance-Einflussfaktoren
491
Bei der individuellen Lieferanten-Performance kann keine eindeutige Tendenz festge-
stellt werden. Hier überwiegt mit knapper Mehrheit ein negativer Einfluss bedingt durch
Kommunikationsprobleme, was durch das nachfolgende Zitat von L25 verdeutlicht wird:
491
Eigene Darstellung.
Netzwerk individuell unklar
positiv negativ
1
23
11
5
6
9
10
4
8
2
6
8
2
57
2
5
9
1
Einflussfaktoren [Häufigkeit]
1: Aufgaben-Interdependenz [13]
2: Kommunikation [12]
3: Integration & Schnittstellen [3]
4: Spezifikation [1]
5: Forced Coopetition [6]
6: Komplexität [6]
7: Vision / Gesamtüberblick fehlt [1]
8: Unrealistische Projektplanung [3]
9: Software Know-How [2]
10: Prozess-Inkompatibilität [2]
11: Fehlende Weisungsbefugnis [3]
12: Verantwortlichkeiten bei Fehlern [2]
13: Kollaborative Leistungen [6]
12
12
Art des Einflusses
Aggregations-Ebene
6
1
1
13
13
13
5
13
-Modelles 114
Kommunikationsstrecken, wo man über eine Woche gebraucht hat, um herauszu-
Auffallend ist, dass einzig beim Phänomen Forced Coopetition ein positiver Einfluss
gegenüber dem negativen Einfluss sowohl auf Netzwerk- als auch auf individueller
Ebene überwiegt. Dabei wird die erzwungene Zusammenarbeit von den Teilnehmen-
den als Anreiz und Treiber für Innovationen und Entwicklungsleistungen verstanden,
was durch das folgende Zitat von L13 veranschaulicht wird:
sehe das mit dem Wettbewerb positiv, weil ich die Erfahrung gemacht habe, dass
überall, wo wir monopolartig unterwegs waren, sich mit der Zeit so gewisse Effekte
einschleichen, wo man zum Teil nicht mehr weiß, was man aneinander hat. Ich bin
3.6.4 Erkenntnisse zur erfolgreichen Integration
Zur Beantwortung von FF 2d wurden die Aussagen der Interview-Teilnehmenden in
Hinblick auf mögliche Faktoren für eine erfolgreiche Integration untersucht. Dabei
konnten insgesamt 16 Erfolgsfaktoren identifiziert werden, welche in Tabelle 20 auf-
gelistet sind. Für jeden Faktor wird ein Bezug zur vorhandenen Literatur hergestellt
sowie eine Einschätzung zur Relevanz und Implementationsmöglichkeit im Rahmen
des LPMM abgegeben. Auch hier ist eine hohe Relevanz des Kommunikationsaspek-
tes erkennbar -
e es auf klare Kommunika-
tionsstrukturen an, die vor allen Dingen eine direkte, multilaterale Kommunikation zwi-
schen den Entwicklungs-Teams aller Netzwerkakteure fördert. Das folgende Zitat von
L25 belegt die Relevanz von Kommunikation während der Integrationsphase:
da effektiv das zu realisieren und nicht zu viele Fehler am Anfang zu haben. Es
sind keine unkomplexen Systeme. Vor allem wenn man nur Komponenten liefert
und nicht das Komplettsy
Auch physische Vor-Ort-Treffen sollten insbesondere bei der gemeinsamen Integra-
tion und Fehlersuche nicht vernachlässigt werden. Die identifizierten Erfolgsfaktoren
115 Ergebnisse aus fallübergreifender Analyse
entsprechen weitgehend dem aktuellen Stand der Forschung, jedoch konnten auch
neue Faktoren ermittelt werden, wie z.
ons-
zierten Erfolgsfaktoren nur ein Mal genannt wurde, liegt jedoch eine geringe Reprä-
sentativität vor. Erkennbar ist außerdem, dass manche der identifizierten Faktoren le-
diglich für das Software-Projektmanagement relevant sind und sich mutmaßlich nicht
in den LPMM-Prozess integrieren lassen. Die meistens Erfolgsfaktoren wie beispiels-
weise Continuous Integration & Delivery sollten nicht nur vom Lieferanten eingefordert
werden, sondern müssen in erster Linie vom OEM vorgelebt werden, um Prozessin-
kompatibilitäten zu vermeiden.
Tabelle 20: Faktoren für eine erfolgreiche Integration
492
Faktoren für eine erfolgrei-
che Integration
Häufigkeit
Vergleichbare Erfolgs-
faktoren in der Litera-
tur
Relevanz für
das LPMM
Kommunikation & Kollaboration
zwischen Entwicklungs-Teams
fördern
8
Ja, z. B. Ilyas/Khan
(2015), S. 3
Ja (Handlungs-
empfehlung)
Gemeinsame Integration &
Trouble Shooting (auch phy-
sisch vor Ort)
5
Nein
Ja (Handlungs-
empfehlung)
Strukturierte & sukzessive In-
tegrations-Planung
3
Ja, z. B. Ilyas/Khan
(2017), S. 255
Ja (Scorecard)
Continuous Integration & De-
livery
3
Ja, z. B. Ilyas/Khan
(2016), S. 244
Ja (Scorecard)
Standardisierte Arbeitsmetho-
den und -prozesse
2
Ja, z. B. Zafar et al.
(2011), S. 294
Ja (Scorecard)
Klar definierte Verantwortlich-
keiten
2
Nein
Ja (Modell)
klar definierte Kommunikations-
struktur
2
Ja, z. B. Zafar et al.
(2011), S. 294
Ja (Modell)
Mehr Fokus auf Vorintegration
2
Ja, z. B. Ilyas/Khan
(2015), S. 3
Nein
Strukturierte Schnittstellen-Ab-
stimmung
2
Ja, z. B. Ilyas/Khan
(2016), S. 244
Ja (Scorecard &
Modell)
Best of Breed Vergabe an Viel-
zahl von Lieferanten
1
Nein
Ja (Sourcing-
Strategie)
Flexible Prozesse
1
Nein
Ja (Scorecard)
Definition von gemeinsamen In-
tegrations-Zielen
1
Nein
Ja (Modell)
Tool-Einbindung
1
Nein
Nein
492
Eigene Darstellung.
-Modelles 116
Dezentrale Teams mit mehr
Entscheidungsspielraum
1
Nein
Nein
Zentrale, starke Koordination
seitens 1st Tier oder OEM
1
Nein
Ja (Modell)
Saubere Dokumentation und
Versionsmanagement
1
Ja, z. B. Ilyas/Khan
(2016), S. 244
Ja (Scorecard)
3.6.5 Erkenntnisse zum LPMM im Multi-Sourcing-Kontext
In den folgenden Unterkapiteln werden die Kern-Ergebnisse dieser Dissertation vor-
(Netzwerk-Ebene [10] & Akteurs- des konzeptionellen Bezugsrahmens zu-
zuordnen sind. Zunächst findet ein Vergleich der deduktiv abgeleiteten mit den induktiv
ermittelten Anforderungen statt. Anschließend wird das LPMM-Modell, welches basie-
rend auf den ermittelten Anforderungen und Gestaltungsempfehlungen entwickelt
wurde, vorgestellt. Daran schließen sich die konkreten Handlungs- und Gestaltungs-
empfehlungen für das LPMM im Multi-Sourcing-Kontext an.
3.6.5.1 Anforderungen an ein netzwerkbasiertes
-Modell
Im Rahmen der konsekutiven Literaturrecherche im Forschungsfeld des Netzwerk Per-
formance Managements wurde eine Reihe von LPMM-Modellanforderungen deduktiv
ermittelt (siehe Kapitel 3.2). Diese werden in Tabelle 21 den induktiv ermittelten Anfor-
derungen gegenübergestellt und somit einer Validierung unterzogen. Die Zahlen in
eckigen Klammern entsprechen der fallübergreifenden Häufigkeit des Auftretens. Dar-
über hinaus werden konkrete Implikationen für die Entwicklung eines LPMM-Modells,
die aus der Literatur und der empirischen Fallstudie abgeleitet wurden, dargestellt.
Erkennbar ist, dass mit Ausnahme der Komplexitätsreduktion alle Anforderungen aus
der Literatur im Rahmen der empirischen Fallstudie bestätigt werden konnten. Darüber
hinaus konnten acht weitere Anforderungen identifiziert werden, von denen die meis-
ten jedoch nur ein- oder zweimal genannt wurden und somit von geringer Relevanz
sind. Einige der Anforderungen wurden lediglich implizit über die Nennung von Teilas-
pekten bestätigt (z. B. gemeinsame Planung für Kollektivität). Die folgenden identifi-
zierten Kernanforderungen mit mindestens fünf Nennungen werden nachfolgend nä-
her erläutert (**: Literatur & empirische Studie; *: empirische Studie):
117 Ergebnisse aus fallübergreifender Analyse
• Multi-Dimensionalität**,
• Kollektivität**,
• Berücksichtigung von Abhängigkeiten**,
• Transparenz**,
• Flexibilität**,
• Klar abgegrenzte Verantwortlichkeiten und Schnittstellen*.
Tabelle 21: Validierung der LPMM-Modellanforderungen
493
Anforderungen aus
der Literatur
Anforderungen aus
der Fallstudie
[Häufigkeit]
Implikationen für das LPMM-Modell
Kollektivität
Multilaterale Meetings
[5], Gemeinsame Ziele
[3], Gemeinsames Re-
porting [2], ge-
meinsame Abstim-
mung [2], andere [3]
Prozessschritt zur gemeinsamen Ab-
stimmung des LPMM hinzufügen;
Festlegung der Netzwerk-Grenzen; In-
volvieren der Lieferanten in alle
Prozessschritte; gemeinsames
Verständnis aller Stakeholder sicherstel-
len
Berücksichtigung von
Abhängigkeiten
Berücksichtigung von
Abhängigkeiten [12]
Interdependenzen müssen klar definiert
und berücksichtigt werden.
Komplexitätsreduktion
-
Vermeidung von Mehrdeutigkeit und In-
formationsüberflutung; bewusste Aus-
wahl einer repräsentativen Reihe von
Kriterien494
Multi-Dimensionalität
Vorgeschlagene Di-
mensionen:
Messebene [7], Zeit
[6], Funktionscluster
[5], andere [4]
Nutzung von Priorisierungen und
Gewichtung, um ein differenziertes Bild
zu erzeugen; Einsatz multipler Indi-
katoren und Methoden; Hinzufügen von
netzwerkrelevanten Dimensionen495
Flexible Strukturen &
Prozesse
Flexibilität [5]
Flexibel anpassbare Commitments496;
Neugestaltung von Verträgen; re-
gelmäßige gemeinsame Review-Meet-
ings; einfachen Ein- und Austritt für
Netzwerkakteure ermöglichen497; kurze
Entscheidungswege ermöglichen
Transparenz durch In-
formationsaustausch
Transparenz [9]
Schaffung eines Gesamtüberblicks; Ein-
richtung einer zentralen Kommu-
nikationsplattform; Sicherstellung des
Datenschutzes durch Geheimhaltung-
svereinbarungen; transparente Rege-
493
Eigene Darstellung.
494
Vgl. Koppenjan (2008), S. 705.
495
Vgl. Pekkola/Ukko (2016), S. 1429.
496
Vgl. Koppenjan (2008), S. 706.
497
Vgl. Pekkola/Ukko (2016), S. 1419.
-Modelles 118
Anforderungen aus
der Literatur
Anforderungen aus
der Fallstudie
[Häufigkeit]
Implikationen für das LPMM-Modell
lung des Informationsaustausches; Er-
möglichung der gegenseitigen Bewer-
tung von Zulieferern
Vertrauensbildende
Maßnahmen
Vertrauen [1]
Offene Fehlerkultur leben, Schul-
dzuweisungen vermeiden, partner-
schaftliche Beziehungen pflegen
Messung auf individu-
eller und agregierter
Ebene
Messung auf individu-
eller und agregierter
Ebene [7]
Einbettung des individuellen LPMM in
ein Netzwerk-LPMM; Festlegung von
Netzwerkgrenzen für aggregierte
Messungen auf Netzwerkebene.
-
Kontinuität [1]
Zu häufiges Ändern von Prozessen und
Messgrößen vermeiden, um die Ver-
gleichbarkeit der Daten zu gewährleis-
ten.
-
Eigenverantwortung
[1]
Mehr Entscheidungsspielraum für
Lieferanten ermöglichen.
-
Berücksichtigung von
Unter-Lieferanten [2]
Nicht nur direkte Lieferanten in das
LPMM inkludieren; Status Unter-
Lieferanten in Reporting der direkten
Lieferanten aufnehmen, Drei-Parteien-
Gespräche durchführen
-
Klar abgegrenzte
Verantwortlichkeiten
und Schnittstellen [15]
Klare Definition von Rollen und Verant-
wortlichkeiten auf übergeordneter
Ebene zu Beginn des Projekts; Um-
setzung mittels RASI-Chart.
-
Paritätische Besetzung
der Verantwortlich-
keiten bei OEM und
Lieferanten [2]
Bereitstellung von Pendants auf Arbeits-
und Managementebene, um die Ver-
netzung aller Beteiligten zu gewährleis-
ten.
-
Kürzere Iterationen [2]
Iterative Prozessschritte, kürzere
Schleifen
-
Mit gleichem Maßstab
messen [2]
Ungleichbehandlung führt zu Unmut und
Vertrauensverlust; KPIs, Belohnungen
und Bestrafungen müssen für alle Be-
teiligten transparent und nachvollziehbar
sein.
-
Festlegung der Fre-
quenz [1]
Prozessdauer und Abläufe müssen im
Voraus festgelegt werden und ange-
messen sein.
119 Ergebnisse aus fallübergreifender Analyse
Gemäß Koppenjan (2008) sollte die vorhandene Multi-Dimensionalität der Outputs im
Netzwerkkontext auch im Rahmen von LPMM-Modellen berücksichtigt werden.
498
Dies
kann durch die Verwendung eines umfassenden, ausgewogenen Kriterien-Satzes
oder durch eine Differenzierung in Bezug auf kontextrelevante Faktoren erreicht wer-
den. So wurde eine Differenzierung der Performance-Messung in Bezug auf den Zeit-
punkt oder die Ebene der Messung von den Teilnehmenden am häufigsten vorge-
schlagen, wie das folgende Zitat von L29 veranschaulicht:
Again, one thing that comes to my mind is that you need to have an individual
measurement of suppliers: Main supplier, system integrator,... but that also needs
to be some joint evaluations
Eine Unterscheidung hinsichtlich Funktionsclustern und der Vertragsart wurde dabei
ausschließlich aus OEM-Perspektive vorgeschlagen.
Unter Kollektivität wird die verstärkte Einbindung aller Beteiligten in die einzelnen Pro-
zessschritte des LPMM verstanden. Dazu gehört u. a. die Ableitung von Leistungsin-
dikatoren von kollektiven Zielen und die gemeinsame Erstellung eines kontextspezifi-
schen LPMM-Modells auf der Grundlage eines Referenzmodelles.
499
Laut der Aussage
von mehreren Befragten können regelmäßige multilaterale Treffen mit den teilnehmen-
den Lieferanten zu Leistungsverbesserungen im Lieferantennetzwerk beitragen. Auch
die Definition und Kommunikation gemeinsamer Ziele kann einen wesentlichen Beitrag
zum Erfolg leisten.
Die Identifikation und Berücksichtigung von Abhängigkeiten zwischen den Leistungs-
umfängen mehrerer Lieferanten wird in fast allen Projekten als wesentliche Vorausset-
zung für das LPMM angesehen. Insbesondere in den Projekten P5 und P12, die durch
eine starke Wahrnehmung aller Phänomene sowie unklare Verantwortlichkeiten ge-
kennzeichnet sind, scheint diese Anforderung besonders relevant zu sein. Wie das in
der Praxis umgesetzt werden kann, zeigt das nachfolgende Zitat von L25:
Sie müssten im Prinzip ein Abhängigkeitsdiagramm haben. Das heißt: Wel-
ches Unternehmen hängt von welcher Zulieferung ab? Also, dass eine Art Domi-
noeffekt in den KPIs oder zumindest in der Beschreibung um die KPIs eingebaut
[ist]. Ein KPI muss dann so strukturiert sein, dass er ein Unternehmen unabhängig
498
Vgl. Koppenjan (2008), S. 705.
499
Vgl. Ferreira et al. (2011), S. 1413.
-Modelles 120
von dieser Lieferkette bewertet. Das wird eine Herkules-Aufgabe, diese KPIs so
zu definieren, dass sie aussagekräftig sind und gleichzeitig nicht ein Unternehmen
dadurch benachteiligen, , dass es in der Lieferkette eines der letzten Glieder
ist.
Transparenz kann durch die Förderung der Kommunikation und des Informationsaus-
tauschs zwischen allen Akteuren erreicht werden. Diese Anforderung wurde von den
Teilnehmenden der Projekte P11 und P12, die stark von kollaborativen Leistungen und
Kommunikationsproblemen betroffen waren, mehrfach genannt. Transparenz kann
außerdem durch die Durchführung von kollektiven Prozessen geschaffen werden, wie
das folgende Zitat von L26 veranschaulicht:
Eine gewisse Transparenz ist da schon erforderlich. Es gibt da auch bilateral zwi-
schen L25 und OEM2 weitere Detail-Sessions, da kriegen wir nicht alles mit.
Einmal im Monat kriegt man auf dem high level das Gefühl, wo steht das Gesamt-
projekt und wo steht jeder der involvierten Supplier
Dieses Zitat verdeutlicht auch die Notwendigkeit eines LPMM auf mehreren Ebenen,
die z. B. durch multilaterale Treffen und gemeinsame Berichterstattung umgesetzt wer-
den kann.
Flexibel anpassbare Prozesse, Strukturen und Ziele sind für das LPMM in einem Netz-
werkkontext erforderlich, um der vorherrschenden Dynamik gerecht zu werden.
500
Dies
erfordert jedoch die Neugestaltung von Lieferantenverträgen und, im Fall von Embed-
ded Software, eine verstärkte Synchronisierung des Software- und Hardware-Entwick-
lungsprozesses. Regelmäßige gemeinsame Review-Meetings können helfen, verän-
derte Rahmenbedingungen oder Prozessinsuffizienzen frühzeitig zu erkennen und
entsprechende Maßnahmen einzuleiten.
Die Forderung nach einer klaren Abgrenzung von Verantwortlichkeiten und Schnitt-
stellen wurde ausschließlich empirisch ermittelt und sticht im Vergleich zu anderen
empirisch ermittelten Anforderungen aufgrund der Vielzahl an Nennungen hervor. Das
folgende Zitat von L6 unterstreicht die Relevanz dieser Anforderung:
500
Vgl. Koppenjan (2008), S. 706.
121 Ergebnisse aus fallübergreifender Analyse
Aus meiner Sicht wichtig ist diese ganze Abhängigkeit zwischen den Liefe-
ranten. Weil einem Lieferanten kann man natürlich sehr leicht seine Aufgaben de-
finieren und verhandeln. Aber wenn es mehrere Lieferanten sind, kommt man im-
mer in dieses "War es klar definiert oder ist es sein Job oder sein Job?"-Thema.
Das sollte man mehr in den Fokus rücken mit klaren Integrations-Meilensteinen
damit sich die einzelnen Leute auch vorbereiten. Mit sehr frühen gemeinsa-
men Abstimmungen. Dieses Netzwerk-Tracking, was Sie erwähnt haben und dann
nicht zuletzt auch eine klare Lieferanten-Struktur
Neben den Anforderungen wurden auch die deduktiv ermittelten LPMM-Elemente auf
der Grundlage der empirischen Untersuchung validiert. In Tabelle 22 werden diese
den empirisch ermittelten gegenübergestellt und die möglichen Implikationen für das
LPMM-Modell aufgezeigt. Die Relevanz aller deduktiv abgeleiteten Elemente kann für
den vorliegenden Beschaffungskontext empirisch bestätigt werden, einschließlich der
netzwerkspezifischen LPMM-Elemente.
Tabelle 22: Validierung der LPMM-Modellelemente
501
LPMM-Element
Literatur
LPMM-Element
Empirie
[Häufigkeit]
Implikationen für das LPMM-Modell
Kriterien &
Messung
Kriterien [5];
Messung [4]
Gemeinsame Abstimmung der Kriterien mit
Lieferanten; Einsatz multipler & multi-dimen-
sionaler Indikatoren; Vornehmen von Gewich-
tungen und Priorisierungen zur Sicherstellung der
Ausgewogenheit; Entwicklung eines Referenz-
Modelles zur Projekt- und kontextspezifischen
Anpassung; gemeinsames Reporting der Lieferan-
ten; Eigenverantwortung gewährleisten; kollabora-
tive Fähigkeit messbar machen
Strategie & Ziel-
setzung
Ziel-Definition [8]
kollektive Ziele & Visionen müssen vom Abnehmer
geschaffen und transparent kommuniziert werden
tung des LPMM einbeziehen, aber Entschei-
dungsgewalt muss bei Abnehmer verbleiben;
anpassbare Zielgrößen; starke Synchronisation
von Anforderungen mit Lieferanten
Anreizsystem
(netzwerk-
spezifisch)
Anreizsystem [7]
Belohnungen für überdurchschnittliche
Lieferergebnisse oder gute Zusammenarbeit;
Berücksichtigung von Abhängigkeiten für mehr
Fairness; Ranking-System; Aussicht auf Folgepro-
jekt-Nominierung oder langfristige Zusammenarbeit
501
Eigene Darstellung.
-Modelles 122
LPMM-Element
Literatur
LPMM-Element
Empirie
[Häufigkeit]
Implikationen für das LPMM-Modell
Kommunikations-
infrastruktur
(netzwerk-
spezifisch)
Kommunikations-
infrastruktur [4]
Stärkere Förderung der horizontalen Kommu-
nikation zwischen Lieferanten; zentrale Kommu-
nikations-Plattform, die zentrale & dezentrale sowie
direkte & indirekte Kommunikation ermöglicht, ist
Grundvoraussetzung für Messung auf
Netzwerkebene
Feedback
Feedback [4]
Gemeinsame Feedback-Runden können als
Ge-
heimhaltungsvereinbarungen zwischen allen Ak-
teuren; Performance-Vergleich mit Wettbewerbern
kann zu höherer Leistung motivieren
Korrektur-
maßnahmen
Korrektur-
maßnahmen [3]
Korrekturmaßnahmen bei schlechter Leistung
müssen vor Vertragsbeginn bekannt und akzeptiert
sein
genaue Zuordnung der Verantwortlichkeit bei Feh-
lern muss gewährleistet sein
Analyse & Evalu-
ation
Analyse [3]
Analyse dient der Bewertung einzelner Lieferanten
sowie der Bestimmung derer Position im Netzwerk;
Identifikation von Schwachstellen, Risiken und
Entwicklungs-Lieferanten
Monitoring
Monitoring [2]
Joint Performance Assessment kann bei Zustim-
mung aller Lieferanten durchgeführt werden und zu
Performancesteigerung führen
Koordinations-
mechanismen
(netzwerk-
spezifisch)
Zentrale Koordi-
nation [2]
Identifikation von Abhängigkeiten und Implementa-
tion gezielter Koordinationsmechanismen; zentrale
Anlaufstelle für alle Akteure, welche gesamte Ak-
tivitäten steuert
Review & Rekali-
brierung
Review & Rekali-
brierung [2]
Review und Rekalibrierung sollte kontinuierlich und
in kurzen Iterationen erfolgen; Anpassung von
Zielgrößen aufgrund von geänderten Rahmenbed-
ingungen sollte gemeinsam mit Lieferanten abges-
timmt werden und transparent und nachvollziehbar
erfolgen502
Die Kernelemente mit mehr als fünf Nennungen, zu denen Kriterien und Messung,
Strategie und Zielsetzung sowie das Anreizsystem zählen, werden im Folgenden er-
läutert. Im vorliegenden Netzwerkkontext sollten die für die Performance Messung an-
gewandten Bewertungskriterien mit den Lieferanten abgestimmt und transparent kom-
muniziert werden. Darüber hinaus sollte aufgrund der vorliegenden Komplexität ein
502
Vgl. Koppenjan (2008), S. 706; Vgl. Pekkola/Ukko (2016), S. 1419.
123 Ergebnisse aus fallübergreifender Analyse
ausgewogenes, mehrdimensionales Kriterien-Set mit einer zugrundeliegenden Ge-
wichtung angewandt werden. Hinsichtlich der Messung kann eine stärkere Eigenver-
antwortung der Lieferanten und eine gemeinsame Berichterstattung mit anderen An-
bietern zusätzliche Anreize zur Kollaboration schaffen.
Aufgrund der vorherrschenden Zieldivergenz zwischen den Netzwerkakteuren ist die
Definition und transparente Kommunikation gemeinsamer Ziele besonders wichtig und
kann auch als Anreiz zur Zusammenarbeit dienen.
Zusätzlich zu den bestehenden reaktiven Kennzahlen scheint die Einführung eines
proaktiven Anreizsystems im Netzwerkkontext eine hohe Relevanz aufzuweisen. Dies
erfordert positive Anreize, die gezielt gesetzt und transparent kommuniziert werden
sollten. Folglich wurden die Aussagen der Interview-Teilnehmenden hinsichtlich der
Art und Gestaltung von Anreizen analysiert und in die folgenden sechs Anreiz-Arten
geclustert:
• Wertschätzung (nicht-monetär),
• Monetäre Anreize,
• Reputation & Aussicht auf Folgebeauftragung und Partnerschaft,
• Vision & Bezug zum Endprodukt,
• Offene, vertrauensvolle Unternehmens- und Fehlerkultur,
• Agiles, innovatives Arbeitsumfeld im Netzwerk.
Unter nicht-monetärer Wertschätzung stellen sich die Befragten z. B. Auszeichnungen,
Awards oder auch positives Feedback in Form einer freundlichen E-Mail vor. Ein mo-
netärer Anreiz kann durch Zurückhaltung der Bezahlung bis zur vollständigen Leis-
tungserbringung oder durch eine Honorierung bei besonders schneller Lösung be-
stimmter Probleme erfolgen. Der dritte Punkt umfasst einerseits den Wunsch nach
Kundenzufriedenheit, welche sich in einer positiven Reputation am Markt nieder-
schlägt. Andererseits werden Lieferanten durch die Aussicht auf Wiederbeauftragung
bei Folgeprojekten sowie die Chance auf den Aufbau partnerschaftlicher Beziehungen
zu guten Leistungen motiviert. Bei den drei eben beschriebenen Punkten handelt es
sich um allgemeingültige Anreize, und es kann keine spezielle Relevanz für den vor-
liegenden Untersuchungskontext festgestellt werden.
Ein weiterer Anreiz besteht darin, den Lieferanten mehr Einblicke in das Endprodukt
zu ermöglichen und Probleme aus der Kundenperspektive aufzuzeigen. Dadurch kann
-Modelles 124
für den einzelnen Lieferanten, der lediglich eine kleine Komponente zuliefert, der Ge-
samtüberblick geschafft und die Bindung zum Endprodukt erhöht werden, wie das fol-
gende Zitat von L17 zeigt:
Selbstverständnis auch sehr stark daraus, dass wir auf der einen Seite nicht alles
selbst machen können, aber auf der anderen Seite wollen wir auch gerne den
kompletten Überblick über Systeme haben. Wir wollen über den Tellerrand raus-
schauen und wir wollen irgendwo mitwirken, dass am Schluss eine gute Lösung,
- Lieferanten-
Dieser Anreiz ist speziell bei Vorliegen von Aufgaben-Interdependenz von Bedeutung,
da dieses Phänomen primär bei einer starken Partitionierung und Verteilung des Ent-
wicklungsumfangs auf mehrere Lieferanten auftritt. Durch die entstehenden Abhängig-
keiten besteht das Risiko, dass sich jeder Lieferant nur noch auf seinen kleinen Liefer-
umfang fokussiert und dabei den Gesamtüberblick verliert.
Bei der offenen, vertrauensvollen Unternehmens- und Fehlerkultur geht es vor allem
darum, ein respektvolles Klima zu schaffen, in dem Probleme von allen Parteien offen
angesprochen werden können und Finger-Pointing vermieden wird. Dass ein solches
offenes Unternehmensklima motivierend wirken kann, zeigt das nachfolgende Zitat
von L18:
Jeder zieht mit, jeder bringt die gleiche Motivation und Bereitschaft mit rein und
jeder hat auch die Offenheit, auch die schwierigen Themen anzusprechen, ohne
gleich eins auf
Anknüpfend an die Erkenntnisse von Tidström (2014) besteht auch hier die Vermutung,
dass eine vertrauensvolle Unternehmenskultur bei der Reduktion von Spannungen
helfen und außerdem zur Erbringung von kollaborativen Leistungen anregen kann.
Schließlich kann auch ein agiles, innovatives Arbeitsumfeld im Lieferanten-Netzwerk,
welches einen elementaren Bestandteil des vorliegenden Untersuchungskontextes
darstellt, als Motivation per se fungieren, da es den Lieferanten ermöglicht, an die ei-
125 Ergebnisse aus fallübergreifender Analyse
gene Leistungsgrenze zu gehen und gleichzeitig gemeinsam mit anderen Firmen in-
novative Lösungen hervorzubringen. Dieser Aspekt wird durch das nachfolgende Zitat
von L13 veranschaulicht:
abstimmen muss. Gleichzeitig ist es ja auch diese Komplexität, die dann versichert,
dass wir nicht nur eine totale Standard-Leistung erbringen, sondern wir bewegen
uns in e
Hinsichtlich der Lieferanten- und OEM-Sicht sind deutliche Unterschiede bei den er-
mittelten Anforderungen zu verzeichnen. Die Berücksichtigung von Abhängigkeiten
und die klare Abgrenzung von Verantwortlichkeiten und Schnittstellen sind fast aus-
schließlich von Kontaktpersonen der Zulieferer genannt worden. Dies könnte zum Teil
daran liegen, dass die Zulieferer die Probleme, die durch unklare Zuständigkeiten ent-
stehen, wesentlich stärker wahrnehmen als die OEMs (Zulieferer: 15 %, OEMs: 4 %)
oder eher davon betroffen sind. Die damit verbundenen Integrations- und Schnittstel-
lenprobleme sowie eine hohe Komplexität werden jedoch deutlich stärker von den
OEM-Kontaktpersonen wahrgenommen. Dies deutet darauf hin, dass den Abnehmern
die Bedeutung einer klaren Abgrenzung von Verantwortlichkeiten zu Beginn eines Pro-
jektes als notwendige Voraussetzung für ein LPMM-Modell möglicherweise nicht be-
wusst ist. Die Kernanforderungen Transparenz und Flexibilität werden prozentual be-
trachtet sowohl aus Lieferanten- als auch aus Abnehmersicht als gleichermaßen rele-
vant erachtet.
In Bezug auf die LPMM-Elemente ist die Ziel-Definition sowohl von Lieferanten- als
auch von OEM-Ansprechpersonen am häufigsten genannt worden, wie Abbildung 20
entnommen werden kann. Außerdem fällt auf, dass Koordinationsmechanismen,
Feedback, Analyse sowie Review- und Rekalibrierung ausschließlich von Lieferanten-
Kontaktpersonen genannt worden. Aus Lieferantensicht ist Feedback in Form einer
Bewertung oder eines Punkte-Systems wünschenswert, um Probleme und Verbesse-
rungspotenziale identifizieren zu können. Bei der Zusammenarbeit mit Wettbewerbern
sind vor allem das direkte Feedback des OEM, aber auch eine gegenseitige Bewer-
tung zwischen Lieferanten relevant. Außerdem kann eine relative Bewertung im Ver-
gleich zur Konkurrenz hilfreich sein, um die eigene Position im Netzwerk identifizieren
und stärken zu können. Dieses Potenzial scheint im Rahmen dieser Untersuchung bei
OEM-Kontaktpersonen noch nicht realisiert worden sein.
-Modelles 126
Abbildung 20: LPMM-Modellelemente aus OEM- und Lieferantensicht
503
3.6.5.2 Netzwerkbasiertes LPMM-Modell
Im Rahmen der durchgeführten Interviews wurde der entwickelte LPMM-Modellentwurf
aus Abbildung 14 inklusive der zugehörigen Scorecard den Teilnehmenden zur Be-
wertung und Anregung eigener Ideen vorgestellt. Das auf Abbildung 21 dargestellte
netzwerkbasierte LPMM-Modell wurde schließlich basierend auf den ermittelten Anfor-
derungen und den von den Teilnehmenden geäußerten Gestaltungsempfehlungen
entwickelt. Dabei wurden alle Empfehlungen tabellarisch erfasst, hinsichtlich der Re-
levanz für Modell und Scorecard geprüft und im Falle der Eignung implementiert (siehe
Anhang F und Anhang G). Widersprüchliche Aussagen wurden dabei nicht identifiziert.
Bezogen auf das Modell wurden am häufigsten kürzere Iterationen, direkte Kommu-
nikationswege zwischen Lieferanten sowie doppelseitige Kommunikationspfeile zwi-
schen Lieferanten-Netzwerk und dem LPMM-Prozess des Abnehmers vorgeschlagen.
Ein Großteil der Gestaltungsempfehlungen steht im Einklang mit den identifizierten
Anforderungen wie Kollektivität, Flexibilität oder Multi-Dimensionalität und kann damit
problemlos in das LPMM-Modell integriert werden. Nicht umgesetzt wurden Vor-
schläge mit einer mangelnden Relevanz, unklaren Bedeutung oder mangels Ideen zur
konkreten Visualisierung.
503
Eigene Darstellung.
127 Ergebnisse aus fallübergreifender Analyse
Abbildung 21: Netzwerkbasiertes LPMM-Modell (eigene Darstellung)
Vision & Zieldefinition
-Zielen
Definition Kriterien-Set (→Balanced Scorecard)
ausgewogen & multi-dimensional
Performance Messung & Monitoring
Netzwerk- & Akteurs-Ebene; gemeinsame Review Meetings & Reportings
Analyse
Identifikation von Schwachstellen, Risiken & Entwicklungs-Lieferanten
Review
&
Rekali-
brierung
Netzwerk-Bezogen:
Organisationsstruktur / Governance
Machtverhältnisse / Wettbewerb
Branche, Netzwerk-Größe
Grad der Verbundenheit / Verpflichtung
Allgemein:
Evaluierungsebene & -zeitrahmen
Datenzugang
Interne Stakeholder (Fachbereiche)
Zeitpunkt und Häufigkeit der
Datenerfassung
LPMM-Prozess Abnehmer
Anreize & Awards
Feedback & Messergebnisse
Kommunikationsinfrastruktur
Zentral & dezentral; bilateral & multilateral
Korrekturmaßnahmen
Netzwerkkonfiguration
Kick-Off: Abgrenzung; Abhängigkeiten;
Verantwortlichkeiten; Schnittstellen,
Messintervall
Koordination
Paritätische Besetzung d. Verantwortlichkeiten
Netzwerksteuerung
Unternehmenskultur
Struktur
Gesetzeslage
Kundenanforderungen
Komplexität & Vernetzungsgrad
Zielkonflikte
Informations-Asymmetrie
Technologie-Reifegrad
Kontextfaktoren
Performance
Integrator / System-
Lieferant
Performance
Software-Lieferant Performance
Dienstleister
Netzwerk-Performance
Performance
Sub-Lieferanten
Forced
Coopetition
Aufgaben-
Interdependenz
Kollaborative
Leistungen
++
+
+
-
--
-
-
-
-
-Modelles 128
Erkennbar ist, dass das Modell im Vergleich zum Entwurfsstand nun aus drei anstelle
von zwei Systemen zusammengesetzt ist. Bei den Kontextfaktoren und dem LPMM-
Prozess des Abnehmers wurden lediglich minimale Anpassungen vorgenommen, die
Anhang F zu entnehmen sind. Durch das Hinzufügen von Feedback- und Korrektur-
schleifen nach den einzelnen Prozessschritten wird eine höhere Dynamik und Flexibi-
lität gewährleistet. Die Doppelpfeile symbolisieren eine kollektive Prozessgestaltung
und einen intensiven mu
verse Funktionen erfüllt: Es dient der Netzwerkkonfiguration zu Beginn des Projektes,
der Schaffung und Pflege einer geeigneten Kommunikationsinfrastruktur sowie der Ko-
ordination aller Netzwerkakteure. Außerdem werden die aus der Analyse resultieren-
den Messergebnisse sowie Anreize und Korrekturmaßnahmen in Hinblick auf eine zu
erzielende Performancesteigerung in das Lieferanten-Netzwerk eingesteuert. Im Rah-
men der Kommunikationsinfrastruktur müssen Kommunikationswege definiert und die
Rahmenbedingungen für einen sicheren Datenaustausch geschaffen werden, z. B.
über Geheimhaltungsvereinbarungen, um die negativen Auswirkungen von Forced
Coopetition abmildern zu können. Dem Phänomen Aufgaben-Interdependenz wird
durch die Einführung von Koordinationsmechanismen und einer Netzwerkkonfigura-
tion Rechnung getragen. Das Erbringen von kollaborativen Leistungen soll mit Hilfe
von positiven Anreizen und Awards gefördert werden.
Die drei Phänomene sind im System der Netzwerk-Performance als dunkelblaue Ellip-
sen dargestellt, wobei die Pfeile den Einfluss auf die Lieferanten- und Netzwerk-Per-
formance symbolisieren. Da die Phänomene im Rahmen der Studie zwar als Einfluss-
faktoren auf die Performance identifiziert wurden, jedoch die Stärke und Richtung des
Einflusses nicht genau bestimmt werden konnten, laufen die Pfeile ins Leere. Die Phä-
nomene sollten folglich im Zuge der Performance-Messung und der Netzwerksteue-
rung dediziert berücksichtigt werden.
Zur Überarbeitung des Entwurfsstandes der Balanced Scorecard (siehe Abbildung 15)
fand ebenso eine Analyse der Aussagen der Teilnehmenden statt. Im Anhang G wer-
den die von der Autorin vorgeschlagenen Kriterien hinsichtlich der Relevanz überprüft.
Mit Ausnahme von Entwicklungskosten, Initiativen zur Leistungsverbesserung und
Unternehmensbeitrag zum Netzwerk wurden alle Kriterien von den Teilnehmenden
129 Ergebnisse aus fallübergreifender Analyse
für diesen Untersuchungskontext als relevant erachtet. Außerdem wurden insgesamt
neun weitere Kriterien von den Interview-Teilnehmenden vorgeschlagen. Insgesamt
wurden alle ausgewählten Dimensionen und ein Großteil der Kriterien von den Teil-
nehmenden für sinnvoll befunden, wobei es vereinzelt Vorbehalte hinsichtlich der
Messbarkeit gab, vor allen Dingen in Bezug auf das Sozialkapital. Dies äußert sich
auch dahingehend, dass lediglich für zehn Kriterien Beispiele für messbare Indikatoren
vorgeschlagen wurden, welche ebenso in dieser Tabelle abgebildet sind. Für die An-
wendung im industriellen Kontext ist es jedoch notwendig, dass messbare Indikatoren
von den jeweiligen Zielen und Strategien des Unternehmens für alle Kriterien abgelei-
tet werden.
504
Aufgaben-
Interdependenzvon der Autorin wieder entfernt und deren untergeordnete Kriterien
Forced
CoopetitionSomit finden sich alle messbaren Kriterien
der Phänomene Aufgaben-Interdependenz, Forced Coopetition und kollaborative Leis-
tungen unter der übergeordneten Dimension Zusammenarbeit wieder. Die übrigen
Gestaltungsempfehlungen für die Balanced Scorecard ließen sich größtenteils nicht
umsetzen und können dem Anhang H entnommen werden.
Auf Abbildung 22 ist die zum netzwerkbasierten LPMM-Modell zugehörige Balanced
Scorecard dargestellt. Erkennbar ist, dass für jedes Kriterium neben einem Soll-Wert
und einer Priorisierung
505
auch eine Messebene festzulegen ist. Bei der Messebene
kann zwischen der Akteursebene (Lieferant), der Netzwerkebene (Netzwerk) sowie
einer Messung auf beiden Ebenen (N & L) ausgewählt werden. Die Auswahl wurde
teilweise basierend auf den Gestaltungsempfehlungen der Teilnehmenden und teil-
weise vom Publizierenden selbst vorgenommen.
504
Vgl. José Alfaro Saiz et al. (2007), S. 317.
505
Soll-Wert und Priorisierung sind aber der Abbildung nicht dargestellt, stellen jedoch relevante Be-
standteile dar (siehe Handlungsempfehlungen).
-Modelles 130
Abbildung 22: Balanced Scorecard
506
506
Eigene Darstellung.
Zusammenarbeit
Mess-EbeneKPIsKriterien
Netzwerk
Lieferant
Lieferant
Netzwerk
Netzwerk
N & L
N & L
Netzwerk
Tbd
Tbd
Tbd
Tbd
Tbd
Tbd
Tbd
Tbd
Tbd
Informationsaustausch
Stakeholder Management
Kollaborative Fähigkeit
Spannungen
Health of Collaboration
Abhängigkeiten &
Wechselwirkungen
Schnittstellenkompatibilität
Definierte Verantwortlichkeiten
Andere
Wachstum und Lernen
Mess-EbeneKPIsKriterien
Lieferant
N & L
Netzwerk
N & L
Lieferant
Lieferant
Tbd
Tbd
Tbd
Tbd
Tbd
Tbd
Tbd
Trainings & Kurse
Lernfähigkeit
Interorganisationales Lernen
Innovationskompetenz
System-Kompetenz
Program Management Capab.
Andere
Prozesse
Mess-EbeneKPIsKriterien
Lieferant (L)
Lieferant
N & L
Lieferant
Lieferant
Lieferant
N & L
Tbd
Tbd
Tbd
Tbd
Tbd
Tbd
Tbd
Tbd
Qualitätssicherung
Stand. Prozessmodelle
Flexibilität / Skalierbarkeit
Integrationsplanung u.
strategie
Continuous Integration
Anforderungsmanagement
Saubere Dokumentation
Andere
Sozialkapital
Mess-EbeneKPIsKriterien
Netzwerk (N)
Netzwerk
Netzwerk
Tbd
Tbd
Tbd
Tbd
Geteilte Ansichten & Normen
Vertrauen
Gemeinsames Verständnis
Andere
Entwicklungs-Projekt
Mess-EbeneKPIsKriterien
N & L
N & L
N & L
N & L
Lieferant
Tbd
Tbd
Tbd
Tbd
Tbd
Tbd
Termintreue
Featureimplementierung
Lieferqualität / Funktionalität
Fehlerbehebung
Unit Testing
Andere
Kriterien →Ziele →Strategien →Erfolgsfaktoren →KPIs
Balanced
Scorecard
131 Ergebnisse aus fallübergreifender Analyse
Grundsätzlich lassen sich alle Kriterien, die auf Lieferantenebene gemessen werden,
aggregieren (bottom-up), um eine Netzwerksicht zu generieren und daraus gut oder
schlecht agierende Lieferanten identifizieren zu können. Umgekehrt lässt sich jedoch
nur ein Teil der Kriterien mit einer angegebenen Netzwerk-Messebene auch auf der
Lieferantenebene messen. Teilweise ist die Messung dieser Kriterien ausschließlich
auf einer übergeordneten Ebene für das gesamte Netzwerk (top-down) möglich (z. B.
bei dem Auftreten von bilateralen oder multilateralen Spannungen). Denkbar wäre es,
in Anlehnung an Straub et al. (2004) die Messwerte sowohl bottom-up als auch top-
down zu ermitteln und miteinander abzugleichen. -
den Abnehmer durchgeführt werden. Die beiden dunkelblau markierten Dimensionen
weisen eine explizite Netzwerk-Relevanz auf
und könnten durch eine Eigenbewertung sowie eine gegenseitige Bewertung der Lie-
feranten ergänzt werden. Wie bei dem Entwurfsstand, besteht auch hier kein Anspruch
Dimensionen-Blocks dargestellt wird. Die hier vorgestellte Scorecard zeigt, welche Di-
mensionen und Kriterien im Kontext der Embedded-Software-Beschaffung relevant
sein können, jedoch nicht müssen. Sie sollte folglich als Referenz-Scorecard genutzt
werden und projekt- und kontextabhängig angepasst werden. Die praktische Umset-
zung kann beliebig im Form eines Excel-Tools oder eines programmierten Dashboards
erfolgen.
Schließlich wurde zur Beantwortung von FF 3a das entwickelte LPMM-Modell hinsicht-
lich der Erfüllung der ermittelten Anforderungen geprüft. Dabei wurde zunächst fest-
gestellt, dass alle erforderlichen Modellelemente enthalten sind. In der nachfolgenden
Tabelle wird der Erfüllungsgrad der Anforderungen ermittelt und auf die Implementa-
tion im Modell Bezug genommen. Erkennbar ist, dass ein Großteil der Anforderungen
erfüllt werden konnte, was für einen hohen Reifegrad des Modelles spricht. Anforde-
rungen, die sich im Zuge der Modellentwicklung nicht direkt implementieren ließen,
werden Rahmen der Handlungsempfehlungen aufgegriffen. Schließlich wurde das Mo-
dell auch hinsichtlich der Erfüllung der allgemeinen LPMM-Modellanforderungen sowie
der Managementkonzeptanforderungen geprüft (siehe dazu Anhang I).
-Modelles 132
Tabelle 23: Validierung des LPMM-Modelles
507
Anforderung
Erfüllungsgrad
Implementation
Kollektivität
erfüllt
Bidirektionale Pfeile symbolisieren ge-
meinsame Abstimmung aller Prozess-
schritte
Berücksichtigung von Ab-
hängigkeiten
erfüllt
Identifikation von Abhängigkeiten Be-
standteil der Netzwerkkonfiguration
Komplexitäts-Reduktion
Teilweise erfüllt
So allgemein gehalten wie möglich, so
detailliert wie nötig; es wurde versucht,
die wesentlichen netzwerkspezifischen
Aspekte des LPMM anschaulich und an-
wenderfreundlich hervorzuheben
Multi-Dimensionalität
erfüllt
Unterscheidung hinsichtlich Lieferanten-
Rollen, multidimensionale Scorecard,
Messung auf mehreren Ebenen
Flexible Strukturen & Pro-
zesse
erfüllt
Review & Rekalibrierung nach allen Pro-
zess-Schritten, ständige Prüfung hinsicht-
lich sich ändernder Kontextfaktoren
Transparenz durch Informa-
tionsaustausch
erfüllt
Kommunikationsinfrastruktur; transpa-
rente Kommunikation von Feedback &
Messergebnissen
Vertrauensbildende Maß-
nahmen
Nicht erfüllt
Nicht implementiert; siehe Handlungs-
empfehlungen
Messung auf individueller
und aggregierter Ebene
erfüllt
Messebene wird für alle Kriterien der
Scorecard festgelegt
Kontinuität
Nicht erfüllt
Nicht implementiert; siehe Handlungs-
empfehlungen
Eigenverantwortung
Nicht erfüllt
Nicht implementiert; siehe Handlungs-
empfehlungen
Berücksichtigung von Unter-
Lieferanten
Teilweise erfüllt
Unter-Lieferanten sind dem Lieferanten-
Netzwerk hinzugefügt; prozessuale Um-
setzung zu klären
Klar abgegrenzte Verant-
wortlichkeiten und Schnitt-
stellen
erfüllt
k
ten
Paritätische Besetzung der
Verantwortlichkeiten
erfüllt
Kürzere Iterationen
erfüllt
Review & Rekalibrierung nach allen Pro-
zess-Schritten
Mit gleichem Maßstab mes-
sen
Nicht erfüllt
Nicht implementiert; siehe Handlungs-
empfehlungen
Festlegung der Frequenz
erfüllt
k
Festlegung Messintervall enthalten
507
Eigene Darstellung.
133 Ergebnisse aus fallübergreifender Analyse
3.6.5.3 Handlungs- und Gestaltungsempfehlungen
Im Rahmen der Inhaltsanalyse sind zahlreiche konkrete Handlungsempfehlungen an-
hand der Aussagen der Interview-Teilnehmenden identifiziert worden, welche zu-
nächst hinsichtlich der Sinnhaftigkeit geprüft wurden und in den nachfolgenden Tabel-
len aufgelistet sind. Diese Handlungsempfehlungen können als konkrete Umsetzungs-
vorschläge in Bezug auf die ermittelten LPMM-Modellanforderungen und die Gestal-
tung der LPMM-Modellelemente verstanden werden. Folglich wurde eine Clusterung
aller identifizierten Handlungsempfehlungen nach Anforderungen bzw. Modellelemen-
ten vorgenommen und es wurde eine Einschätzung von der Autorin hinsichtlich der
Relevanz bezüglich der Phänomene Aufgaben-Interdependenz (AI), Forced Coopeti-
tion (FC) sowie kollaborativen Leistungen (KL) vorgenommen. Zu beachten ist hierbei,
dass es sich bei fast allen Empfehlungen um die persönliche Meinung einzelner Per-
sonen handelt. Folglich liegt eine eingeschränkte Repräsentativität vor. Tabelle 24
zeigt die Handlungsempfehlungen, welche den Modellanforderungen zugeordnet wer-
den konnten und in Tabelle 25 sind die Handlungsempfehlungen zur Gestaltung der
LPMM-Modellelemente dargestellt. -
--
ziert werden. Es wurden für alle Modelle
lungsempfehlungen zur konkreten Ausgestaltung ermittelt.
Tabelle 24: Handlungsempfehlungen zur praktischen Umsetzung der LPMM-Modellanforde-
rungen
508
Anforderung
Handlungsempfehlungen (Bezug zu Phänomenen)
Kollektivität
• Gemeinsame Meetings zur Integration und Fehlerbehebung mit allen
beteiligten Akteuren auf Arbeits- & Managementebene (AI, KL, FC)
• Regelmäßige multilaterale Management Review-Meetings, um Risiken
und Probleme zu analysieren und Gesamtüberblick zu schaffen (AI)
• Zu Projektstart regelmäßige Kick-Off-Meetings ("verlängerter Kick Off")
mit allen Stakeholdern auf Arbeitsebene, um Verantwortlichkeiten und
Schnittstellen zu schärfen und Risiken zu minimieren (AI)
• Gemeinsame Vergabe von Folgeprojekten für Lieferantenkonstellatio-
nen, welche gut zusammengearbeitet haben (KL)
• Veranstaltung von Lieferantentagen mit allen Unterlieferanten vor Ort,
um bilateralen Austausch von Lieferant, Auftraggeber und Integrator zu
fördern (AI, KL, FC)
508
Eigene Darstellung.
-Modelles 134
Anforderung
Handlungsempfehlungen (Bezug zu Phänomenen)
Flexible Struk-
turen & Pro-
zesse
• Mehr Vernetzung und Entscheidungskompetenz auf Arbeitsebene
• Flexibles Reagieren auf Änderungen darf keine negativen Konsequen-
zen fü
lich
Transparenz
• Grundvoraussetzung: Geheimhaltungsvereinbarungen für uneinge-
schränkten Informationsaustausch (FC)
• Den Lieferanten Einblicke in die gesamte Systemsicht & Architektur ge-
währen (AI)
• Joint Assessment bei technischen KPIs → schafft Transparenz, wo je-
des einzelne Unternehmen und das Gesamtprojekt stehen (KL)
• Gemeinsame Pflege von Schnittstellen erforderlich (AI)
• Einheitliche von allen Akteuren genutzte Tool-Kette oder funktionie-
rende Synchronisierung zwischen den Tools aller Akteure & stärkere
Digitalisierung der Systemlandschaft (AI)
• Bootcamps mit Openings und Closings für mehr Transparenz im Re-
porting (als multilaterale Vor-Ort-Meetings) (AI, KL, FC)
Vertrauensbil-
dende Maß-
nahmen
• Informelle Meetings & Events zwischen Lieferanten und OEM (FC, KL)
• Gewissen Angebotsrahmen für Entwicklungsdienstleistungen schaffen
und dadurch Overhead reduzieren
• Vertrauensvolle Grundattitüde muss etabliert werden, damit Transpa-
renz und Ehrlichkeit generiert werden (FC, KL)
• Offene Fehlerkultur, kein Finger-Pointing, gemeinsames Problem-Lö-
sen (FC, KL)
Messung auf
individueller &
aggregierter
Ebene
• Unterschiedliche Gewichtung der Kriterien für Netzwerk- und Lieferan-
tenebene anwenden
• Messung auf Akteursebene von Lieferanten durchführen lassen, Mes-
sung auf Netzwerkebene durch OEM Abgleich der Ergebnisse im
gemeinsamen Review-Termin
• Zunächst Top-down-Messung auf Netzwerkebene durchführen, dann
für Details die individuelle Lieferantenebene prüfen
Kontinuität
• Mehr Konstanz bei der Performance-Messung, um Vergleichbarkeit der
Daten zu gewährleisten
Eigenverant-
wortung
• Den Lieferanten mehr Entscheidungsspielraum und Eigenverantwor-
tung zugestehen maximale Kontrolle ist nicht immer zielführend (KL)
Klar abge-
grenzte Ver-
antwortlichkei-
ten & Schnitt-
stellen
• RASI Chart / Schnittstellenvereinbarung zu Beginn des Projektes er-
stellen (AI)
• Zu Projektstart Abstimmung aller Beteiligten: Prüfung, ob einheitliches
Verständnis bezüglich der Abgrenzung von Rollen und Verantwortlich-
(AI)
• Abhängigkeiten müssen klar definiert sein, um im Falle von schlechter
Performance, die Verantwortung zu kaskadieren (AI)
Paritätische
Besetzung der
Verantwortlich-
keiten
• Gesamtsystemverantwortung muss seitens Lieferanten und OEM je-
weils bei einer Person liegen
Mit gleichem
Maßstab mes-
sen
• Ungleiche Behandlung führt zu Unmut und Vertrauensverlust Kenn-
zahlen, Belohnung und Bestrafung müssen für alle Beteiligten transpa-
rent und nachvollziehbar sein; keine Sonderbehandlung für einzelne
Lieferanten (KL)
135 Ergebnisse aus fallübergreifender Analyse
Anforderung
Handlungsempfehlungen (Bezug zu Phänomenen)
Festlegung der
Frequenz
• Für die Definition der Häufigkeit der Messung, sollte geprüft werden, ab
wann Veränderungen ersichtlich sind
• Aufgrund des hohen Aufwands darf die Messung nicht zu häufig erfol-
gen, ggf. vierteljährlich
Tabelle 25: Handlungsempfehlungen zur Gestaltung der LPMM-Modellelemente
509
LPMM-Ele-
ment
Handlungsempfehlung (Bezug zu Phänomenen)
Strategie &
Zielsetzung
• Frühzeitiges Einbinden der Lieferanten bei der Ziel-Definition und dem
Aufsetzen des LPMM-Prozesses
• Vermeidung von "Micro-Management": individuelle Akteure dürfen nicht
nur ihre eigene Performance optimieren, sondern müssen stets das
Gesamtbild / die Vision im Blick behalten (KL)
Kriterien &
Messung
• Festlegung von Soll-Werten und einer Priorisierung sind erforderlich
• Entscheidungen nicht rein zahlenbasiert treffen, sondern Messergeb-
nisse als richtungsweisende Tendenz nutzen
• Metriken müssen zielführend und erprobt sein
• Angemessene Detailtiefe für die Messung erforderlich
• Klassifikation und Priorisierung von Fehlern vornehmen: nur für wich-
tige Fehler die Fehlerrate bestimmen
Anreizsystem
• Fachbereichsübergreifende Abstimmung bezüglich zu setzender An-
reize notwendig
• Um Anreize schaffen zu können, müssen direkte Vertragsverhältnisse
mit allen Lieferanten bestehen
Kommunika-
tionsinfrastruk-
tur
• Rahmen schaffen für informelle, persönliche und offene Kommunika-
tion auf Arbeitsebene (FC, KL)
• Entwicklung einer virtuellen Plattform, welche die Kommunikation und
den Informationsaustausch sowie das gemeinsame Arbeiten an Lösun-
gen ermöglicht (AI, KL, FC)
• Kommunikation über dedizierte Systeme mit Audit-Trails und Time
Stamps, denn Kommunikation über E-Mail bietet kaum Transparenz
(AI)
• Klar definierte und abgestimmte Kommunikationskanäle unter Einbe-
zug aller Stakeholder schaffen (AI, KL)
Korrekturmaß-
nahmen
• Strafzahlungen bei Nicht-Einhaltung von Prozess-Standards
Analyse
• Mit geeigneten Systemen Dashboards erstellen und Messergebnisse
zusammenführen, z. B. mit Microsoft Power BI
Monitoring
• Regelmäßige multilaterale Status-Meetings durchführen (AI, KL)
• Reporting auf Managementebene reduzieren, da sonst zu viele Kapazi-
täten gebunden (KL)
Koordinations-
mechanismen
• Zentrale Koordination seitens OEM erforderlich: alle Stakeholder zu-
sammen bringen & Gesamtüberblick behalten (AI)
Review & Re-
kalibrierung
• Bei Einführung einer neuen Technologie müssen Prozesse, Methoden
und Tools geprüft und angepasst werden
509
Eigene Darstellung.
-Modelles 136
Nicht für alle Handlungsempfehlungen konnte eine Relevanz bezüglich eines oder
mehrerer Phänomene festgestellt werden. Für Forced Coopetition werden z. B. Ge-
heimhaltungsvereinbarungen oder vertrauensbildende Maßnahmen als relevant er-
achtet, da diese zum Abbau von Spannungen und Vorbehalten führen können. Im Zu-
sammenhang mit Aufgaben-Interdependenz wurden u. a. eine zentrale Koordination,
Maßnahmen zur multilateralen Abstimmung und Kommunikation sowie zur gemeinsa-
men Abstimmung von Verantwortlichkeiten und Schnittstellen für sinnvoll erachtet. Zur
Förderung von Kollaborativen Leistungen wurden insbesondere Maßnahmen zur Ver-
meidung von Ungleichbehandlung, zur Erreichung eines Zusammengehörigkeitsge-
fühls sowie zur Schaffung eines Gesamtüberblicks über den Projektstatus sowie über
die eigene Performance im Vergleich zu anderen Lieferanten identifiziert, da diese
3.6.6 Impulse aus theoretischen Erklärungsansätzen
Wacker (1998) fasst die divergierenden Verfahren zur Theoriebildung in der wissen-
schaftlichen Literatur in allgemeingültige Richtlinien zur guten Theoriebildung zusam-
men.
510
Demnach sollten Theorien im Allgemeinen die folgenden vier Merkmale auf-
weisen:
• Definition der zugrundeliegenden Variablen (Wer oder was ist eingeschlossen
bzw. ausgeschlossen?),
• Eingrenzung des Anwendungsbereiches (Wann und wo werden die Ereignisse
eintreten?),
• Aufstellen von Beziehungen (Logische Begründung von Zusammenhängen),
• Vorhersagen und empirische Unterstützung.
511
Nachfolgend soll anhand der o. g. Anforderungen geprüft werden, ob im Rahmen der
Dissertation gemäß dieser Definition eine Theoriebildung stattgefunden hat. In der vor-
liegenden Dissertation werden drei präexistente Phänomene, welche jeweils Bestand-
teil eigenständiger Theorien sind, unter Zugrundelegung einer Netzwerkperspektive in
Zusammenhang mit Performance-Größen untersucht. Die Phänomene Aufgaben-In-
terdependenz, Forced Coopetition und kollaborative Leistungen sowie das Konstrukt
der Performance können gemäß des Theorie-Verständnisses nach Wacker (2004) als
Theorie-definierende Variablen verstanden werden. In den Kapiteln 2.3.2 und 2.3.4
510
Vgl. Wacker (1998), S. 368.
511
Vgl. Wacker (1998), S. 368.
137 Ergebnisse aus fallübergreifender Analyse
fand eine eindeutige und präzise Definition dieser Variablen unter Berücksichtigung
der Regeln von Wacker (2004) statt.
512
Eine Eingrenzung des Anwendungsbereiches wurde in Kapitel 1.1 vorgenommen.
Während die Embedded-Software-Beschaffung eines OEMs den praktischen Anwen-
dungsfall der Fallstudie darstellt, kann der allgemeingültige Wirkungsbereich als ein
Beschaffungskontext unter Vorliegen von Integrationsgeschäften und Multi-Sourcing
beschrieben werden. Die Besonderheit liegt dabei in der Individualität und der Kom-
plexität des Produktes, was bei der Entwicklung die Zusammenarbeit einer Vielzahl an
Lieferanten erfordert. Ausgeschlossen ist dabei der Einkauf standardisierter Produkte,
die von einzelnen Lieferanten direkt bezogen werden können. Es wird von einer ge-
währleisteten Übertragbarkeit der ermittelten Ergebnisse und Zusammenhänge auf
den Einkauf von Integrationsgütern anderer Branchen ausgegangen, solange diese
innerhalb eines Netzwerkkontextes entwickelt werden, z. B. im Maschinen- und Anla-
genbau oder in der Luft- und Raumfahrt.
Im Rahmen des konzeptionellen Bezugsrahmens (siehe Abbildung 6), welcher die
Grundlage für das vorliegende Untersuchungsdesign bildet, wurde ein Anfangsver-
dacht über vermutete Zusammenhänge zwischen den drei Phänomenen und der Lie-
feranten- sowie der Netzwerk-Performance aufgestellt. Im Zuge der qualitativen In-
haltsanalyse wurde dieser Anfangsverdacht nicht widerlegt, sondern mit empirischen
Daten angereichert. Wie auf Abbildung 18 erkennbar ist, konnten basierend auf den
Aussagen der Interview-Teilnehmenden insgesamt 13 verschiedene Faktoren ermittelt
werden, welche die Lieferanten-Performance auf individueller und Netzwerkebene
mutmaßlich positiv oder negativ beeinflussen. Unter den Haupteinflussfaktoren befin-
den sich neben Kommunikation und Komplexität auch die zu untersuchenden Phäno-
mene Aufgaben-Interdependenz, Forced Coopetition und kollaborative Leistungen.
Aufgrund des qualitativen Untersuchungsdesigns liegt den Ergebnissen jedoch keine
statistische Signifikanz zugrunde. Vielmehr können die Ergebnisse als richtungswei-
sende Tendenzen verstanden werden und zur Generierung der folgenden drei Hypo-
thesen genutzt werden:
1. Aufgaben-Interdependenz hat einen überwiegend negativen Einfluss auf die in-
dividuelle Lieferanten-Performance als auch auf die Netzwerk-Performance.
512
Vgl. Wacker (2004), S. 638.
-Modelles 138
2. Das Erbringen Kollaborativer Leistungen hat einen überwiegend negativen Ein-
fluss auf die individuelle Lieferanten-Performance als auch auf die Netzwerk-
Performance.
3. Forced Coopetition hat überwiegend einen positiven Einfluss auf die individuelle
Lieferanten-Performance als auch auf die Netzwerk-Performance.
Diese drei Hypothesen sollten im Rahmen von zukünftigen quantitativen Studien über-
prüft werden.
Hinsichtlich der Forschungszielrichtung unterscheidet Wacker (1998) grundlegend
zwischen theoriebildender und faktenorientierter Forschung.
513
Im Gegensatz zur the-
oriebildenden Forschung wird bei der faktenorientierten Forschung der Beweis vor der
Vorhersage der Beziehungen empirisch ermittelt.
514
Die faktenorientierte Forschung ist
folglich nicht durch bestehende theoriegestützte Beziehungen eingeschränkt und kann
daher leichter neue Beziehungen untersuchen, die im Nachgang in eine Theorie inte-
griert werden können.
515
Um jedoch den Anforderungen einer Theorie-Bildung
gerecht zu werden, muss auch eine gute faktenorientierte Forschung die ersten bei-
den Bedingungen erfüllen, da Fakten ohne präzise Definitionen und klar abgegrenzte
Anwendungsbereiche für eine spätere Verwendung nicht nutzbar sind.
516
Da die Hypo-
thesen über Kausal-Zusammenhänge in der vorliegenden Dissertation nicht prognos-
tiziert, sondern empirisch ermittelt wurden, ist das Forschungsvorhaben eher als fak-
tenorientierte Forschung einzuordnen. Demzufolge findet im Rahmen dieser Disserta-
tion durch den Erkenntnisgewinn zu den Phänomenen und Zusammenhängen ein
Theorie-bildender Prozess im weiteren Sinne statt.
Fisher/Aguinis (2017) definierten den Begriff der Theorie-Elaboration wie folgt:
Theory elaboration is the process of conceptualizing and executing empirical re-
search using preexisting conceptual ideas or a preliminary model as a basis for
513
Vgl. Wacker (1998), S. 371.
514
Vgl. Wacker (1998), S. 371.
515
Vgl. Wacker (1998), S. 371.
516
Vgl. Wacker (1998), S. 371.
139 Ergebnisse aus fallübergreifender Analyse
developing new theoretical insights by contrasting, specifying, or structuring theo-
retical constructs and relations to account for and explain empirical observati-
ons.
517
Im Rahmen der Gegenüberstellung (engl. contrasting) werden Beobachtungen entwe-
der auf einen anderen Kontext (horizontal contrasting) oder auf eine andere Analyse-
ebene (vertical contrasting) übertragen.
518
Bei der Spezifizierung (engl. specification)
kann entweder ein neues Konstrukt identifiziert (new specification) oder ein vorhande-
nes Konstrukt in Teil-Aspekte aufgeteilt (construct splitting) werden.
519
Bei der Struktu-
rierung (engl. structuring) werden Beziehungen zwischen zwei Konstrukten (specific
relation) oder eine Abfolge von Beziehungen oder Ereignissen (sequence relations)
(neu) definiert.
520
Außerdem können dabei rekursive Beziehungen zwischen zwei oder
mehreren Einheiten aufgestellt werden (recursive relations).
521
Im Rahmen dieser Ar-
beit wurden die vermuteten Beziehungen zwischen den einzelnen Phänomenen und
der Lieferanten-Performance basierend auf Studien aus anderen Untersuchungskon-
texten aufgestellt. Das Konstrukt der Netzwerk-Performance war dabei größtenteils
nicht Bestandteil bisheriger Studien.
522
Folglich wurde durch die Übertragung auf den
Kontext der Embedded-Software-Beschaffung und die Anwendung einer Netzwerk-
Analyseebene sowohl horizontales als auch vertikales contrasting vorgenommen.
Bezugnehmend auf den konzeptionellen Bezugsrahmen von Natour et al. (2011) auf
Abbildung 11 kann eine teilweise Übereinstimmung mit den Ergebnissen der qualitati-
ven Inhaltsanalyse und folglich die Anwendbarkeit für diesen Kontext als gewährleistet
festgestellt werden. Zwar wurde ein primär negativer Zusammenhang zwischen Kolla-
borativen Leistungen und der Performance ermittelt, jedoch wurden als Ergebnis der
Studie u. a. vertrauensbildende Maßnahmen, kollektive Ziele und Prozesse, Trans-
parenz durch erhöhten Informationsaustausch als Anforderungen an das LPMM im
Netzwerk identifiziert, wodurch sich bei Erfüllung jener potenziell eine Performance-
517
Fisher/Aguinis (2017), S. 4.
518
Vgl. Fisher/Aguinis (2017), S. 8.
519
Vgl. Fisher/Aguinis (2017), S. 8.
520
Vgl. Fisher/Aguinis (2017), S. 8.
521
Vgl. Fisher/Aguinis (2017), S. 8.
522
-
-Modelles 140
steigerung erzielen ließe. Über risikomindernde Maßnahmen sowie die Machtverhält-
nisse im Netzwerk wurden im Rahmen der Experteninterviews keine Aussagen getätigt.
Unter Risiken im Multi-Agenten-Lieferantennetzwerk verstehen Natour et al. (2011)
z. B. moralische Risiken oder Informationsasymmetrien sowie die Unfähigkeit zur Leis-
tungsüberwachung.
523
Diese Risiken können durch einen verstärkten Informationsaus-
tausch und die damit verbundene Erhöhung der Sichtbarkeit abgemildert werden, da
aus Sicht der Agenten somit die Wahrscheinlichkeit für das Auftreten unerwarteter ne-
gativer Ereignisse verringert werde.
524
Dies deckt sich mit dem Wunsch der Studien-
Teilnehmenden nach mehr Transparenz sowie nach einer dedizierten Kommunikati-
onsinfrastruktur. Kritisiert werden könnte das Fehlen von direkten kollaborationsför-
dernden Anreizen im Bezugsrahmen von Natour et al. (2011). Die Ergebnisse der Fall-
studie haben gezeigt, dass das Setzen gezielter positiver Anreize, wie z. B. Wertschät-
zung, Visionen oder die Aussicht auf Partnerschaften oder Folgebeauftragungen, die
Bereitschaft für das Erbringen kollaborativer Leistungen erhöhen kann. Das Element
- auf der rechten Seite, welcher die Maß-
nahmen zur Förderung kollaborativer Leistungen enthält, ergänzt werden.
523
Vgl. Natour et al. (2011), S. 10.
524
Vgl. Natour et al. (2011), S. 10.
141 Diskussion der Ergebnisse
4 Diskussion und Beitrag zur Forschung
4.1 Diskussion der Ergebnisse
Nachfolgend werden die Ergebnisse diskutiert und mit Bezug auf die zu beantworten-
den Forschungsfragen eingeordnet. In Hinblick auf FF 1a wurden im vorliegenden Un-
tersuchungskontext insgesamt zwölf Probleme identifiziert (siehe Tabelle 18. Am häu-
figsten wurden Kommunikationsprobleme sowie Probleme durch unklare Verantwort-
lichkeiten genannt, welche insbesondere in von Aufgaben-Interdependenz und kolla-
borativen Leistungen dominierten Projekten auftreten. Da diese beiden Aspekte auch
im Rahmen der Anforderungen wieder aufgegriffen werden, sollte hierauf ein beson-
derer Fokus gerichtet werden. Nicht alle ermittelten Probleme lassen sich im Rahmen
eines LPMM, sondern vielmehr durch ein ausgereifteres Software-Projektmanage-
ment seitens OEM adressieren, wie z. B. sich ändernde Anforderungen, eine unvoll-
ständige Spezifikation oder Prozess-Inkompatibilität. Während Kommunikationsprob-
leme sowohl aus Lieferanten- als auch aus OEM-Sicht relevant sind, werden Probleme
durch eine unvollständige Spezifikation, sich ändernde Anforderungen und unklare
Verantwortlichkeiten fast ausschließlich von Lieferanten wahrgenommen, obwohl
diese Themen im Verantwortungsbereich des OEMs liegen. Da es sich hierbei um
Performance-hemmende Faktoren handelt, sollten LPMM-Prozessverantwortliche auf
Seiten der OEMs für diese Probleme sensibilisiert werden und entsprechende Maß-
nahmen einleiten, um damit die Grundvoraussetzungen für ein erfolgreiches LPMM zu
schaffen. Im Rahmen der Analyse haben sich bestimmte Netzwerkkonstellationen als
besonders kritisch herausgestellt. Zum einen hat sich gezeigt, dass Projekte mit meh-
reren Setzlieferanten oder mit geteilter System- bzw. Integrationsverantwortung zwi-
schen mehreren Lieferanten besonders häufig von Kommunikationsproblemen, unkla-
ren Verantwortlichkeiten betroffen sind. Solche Projektkonstellationen sollten folglich
möglichst vermieden werden.
Mit Bezugnahme auf FF 1b wurde eine hohe Wahrnehmungsstärke der Phänomene
Aufgaben-Interdependenz, Forced Coopetition und kollaborative Leistungen mit Aus-
nahme von P14 in allen Projekten festgestellt. Folglich konnte der Anfangsverdacht,
dass diese Phänomene für das LPMM von Lieferantennetzwerken im Allgemeinen und
für den speziellen Fall der Beschaffung von Embedded Software von Bedeutung sind,
bestätigt werden. Die Tatsache, dass die drei Phänomene in fast allen untersuchten
Projekten in unterschiedlicher Stärke wahrgenommen wurden, deutet darauf hin, dass
Diskussion und Beitrag zur Forschung 142
diese möglicherweise in Zusammenhang miteinander stehen und daher im Rahmen
eines LPMM adäquat adressiert werden sollten.
Unterschiede hinsichtlich der OEM- und Lieferantensicht wurden bei der Wahrneh-
mung der Phänomene kaum festgestellt. Auffällig war, dass Forced Coopetition von
den Lieferanten im Gegensatz zu den OEM-Kontaktpersonen überwiegend als gezielt
herbeigeführt wahrgenommen wurde, was auf ein fehlendes Bewusstsein für die Exis-
tenz und Auswirkungen dieses Phänomens auf Seiten der OEMs hindeutet. Während
kollaborative Leistungen am stärksten von Dienstleistern wahrgenommen wurden,
scheint Aufgaben-Interdependenz am stärksten für Software-Lieferanten und Integra-
toren von Relevanz zu sein. Letzteres ist insofern naheliegend, als dass Integratoren
für die Zusammenführung aller Software- und Hardwarekomponenten verantwortlich
sind und damit am ehesten mit Abhängigkeiten und Interdependenzen in Berührung
kommen.
In Hinblick auf die Beantwortung der FF 1c konnten insgesamt 13 Faktoren ermittelt
werden, die nach Einschätzung der Interview-Teilnehmenden einen Einfluss auf die
Lieferanten- oder Netzwerkperformance haben (siehe Tabelle 20). Neben den Fakto-
ren Kommunikation und Komplexität befinden sich auch die drei untersuchten Phäno-
mene unter den Haupteinflussfaktoren, wobei Aufgaben-Interdependenz insgesamt
am häufigsten genannt wurde. Aus OEM-Sicht werden dabei vorrangig eine unvoll-
ständige Spezifikation, Prozess-Inkompatibilität und eine fehlende Weisungsbefugnis
genannt, wohingegen aus Lieferantensicht, insbesondere die Phänomene Aufgaben-
Interdependenz und Forced Coopetition sowie ein fehlender Gesamtüberblick als
Haupteinflussfaktoren angesehen werden. Kommunikation und kollaborative Leistun-
gen werden von Lieferanten- und OEM-Ansprechpersonen prozentual betrachtet als
gleichermaßen relevant erachtet. Basierend auf der Erkenntnis, dass sich die gene-
relle Wahrnehmung der Phänomene aus OEM- und Lieferantenperspektive kaum un-
terscheidet, kann daraus die Schlussfolgerung gezogen werden, dass seitens OEMs
möglicherweise ein mangelndes Bewusstsein für die Performance-Auswirkungen von
Aufgaben-Interdependenz und Forced Coopetition vorliegt.
Basierend auf den Aussagen der Interview-Teilnehmenden konnte außerdem eine
Klassifizierung der Einflussfaktoren bezüglich positiver und negativer Einflüsse sowie
der Aggregationsebene vorgenommen werden. Erkennbar ist, dass Aufgaben-Interde-
pendenz am häufigsten mit der Netzwerk-Performance in Zusammenhang gebracht
143 Diskussion der Ergebnisse
wird, was mit einer hoch komplexen Architektur und daraus resultierenden Abhängig-
keiten sowie Integrationsproblemen einher gehen kann. Um die negativen Effekte von
Aufgaben-Interdependenz zu vermeiden, sollten die Abhängigkeiten in erster Linie
identifiziert und im zweiten Schritt entsprechend gesteuert werden, z. B. durch Wis-
senstransfer oder kommunikationsfördernde Maßnahmen.
525
Seitens der individuellen
Lieferanten-Performance hat sich keine richtungsweisende Tendenz gezeigt.
Trotz der zahlreichen damit in Zusammenhang stehenden Spannungen überwiegen
bei Forced Coopetition die positiven Performance-Einflüsse auf Netzwerk- und indivi-
dueller Ebene, was vorwiegend auf zusätzliche Anreize durch ein wettbewerbsintensi-
ves, innovationsförderndes Umfeld zurückzuführen ist. Das deckt sich mit den Erkennt-
nissen von Bouncken/Fredrich (2012) und Mariani (2007), welche ebenfalls einen po-
sitiven Performance-Effekt des Phänomens ermitteln konnten. Um die vorrangig von
Lieferanten wahrgenommenen Spannungen abzumildern sollte Forced Coopetition
folglich von OEMs zunehmend als bewusst eingesetztes und durch gezielte Manage-
ment-Mechanismen gesteuertes Konzept eingesetzt werden. Gleichzeitig deuten die
Ergebnisse der Fallstudie daraufhin, dass dies in der Praxis aktuell unzureichend sei-
tens OEMs umgesetzt wird, da die OEM-Vertreter dieses Phänomen lediglich als un-
gewollten Nebeneffekt verstehen.
Entgegen den Erwartungen überwiegt gemäß der Einschätzung der Befragten bei kol-
laborativen Leistungen ein negativer Performance-Einfluss sowohl auf individueller als
auch auf Netzwerkebene. Das könnte darauf zurückzuführen sein, dass Lieferanten
dieses Phänomen primär als zusätzlichen Entwicklungsaufwand wahrnehmen, der in
Zusammenhang mit Integrationsproblemen anfällt und die eigenen verfügbaren Kapa-
zitäten verringert. Hier ist ein Umdenken erforderlich, da gemäß der Erkenntnisse von
Natour et al. (2011) eine Förderung der kooperativen Leistungen im Multi-Agenten-
Netzwerk eine Steigerung der Performance im Versorgungsnetzwerk bewirken solle.
Zu erwarten wäre folglich ein negativer Performance-Effekt auf der Lieferantenebene,
jedoch ein positiver Effekt auf der Netzwerkebene. Bei stark voneinander abhängigen
Aufgaben ist das Erbringen kollaborativer Leistungen nicht vermeidbar und sollte da-
her durch gezielte Anreize oder Belohnungen durch den OEM stärker gefördert werden.
525
Vgl. Malone/Crowston (1990), S. 365.
Diskussion und Beitrag zur Forschung 144
Im Rahmen einer systematischen Literaturrecherche im Bereich des Netzwerk Perfor-
mance Managements wurden insgesamt 18 Quellen identifiziert, welche geeignete Im-
pulse für die Ermittlung der netzwerkspezifischen LPMM-Modellanforderungen liefern
können. Trotz eines abweichenden Netzwerk-Verständnisses konnten einige auf den
vorliegenden Kontext übertragbare Aspekte identifiziert werden. Zur Beantwortung von
FF 2a sei auf die Tabelle in Anhang A verwiesen, welche neben den Quellen, der
Netzwerk-Art und der angewandten Methodik auch die jeweiligen Beiträge für den ent-
wickelten LPMM-Modellentwurf enthält.
Die deduktiv ermittelten Anforderungen wurden im Zuge der empirischen Fallstudie
anschließend validiert. Zur Beantwortung von FF 2b werden die Ergebnisse nachfol-
gend zusammengefasst und diskutiert. Insgesamt ist eine sehr hohe Übereinstimmung
zwischen der Literatur und den empirischen Daten zu beobachten, da sieben der acht
deduktiv ermittelten Anforderungen im Rahmen der empirischen Untersuchung bestä-
tigt werden konnten. Darüber hinaus wurden acht weitere Anforderungen ausschließ-
lich empirisch ermittelt. Zu den sechs Kernanforderungen mit mehr als fünf Nennungen
zählen Multi-Dimensionalität, Kollektivität, die Berücksichtigung von Abhängigkeiten,
Transparenz, Flexibilität sowie die klare Abgrenzung von Verantwortlichkeiten und
Schnittstellen, wobei letztgenannte ausschließlich empirisch ermittelt wurde. Hinsicht-
lich der OEM- und Lieferantensicht waren bei den Anforderungen starke Unterschiede
zu verzeichnen. So wurden beispielsweise die Berücksichtigung von Abhängigkeiten
und die klare Definition von Verantwortlichkeiten und Schnittstellen fast ausschließlich
von Kontaktpersonen der Zulieferer genannt. Dies deckt sich mit der Erkenntnis, dass
das Problem unklarer Verantwortlichkeiten aus der Lieferantenperspektive wesentlich
häufiger wahrgenommen wurde als aus der OEM-Perspektive, was auf einen dringen-
den Handlungsbedarf auf Seiten des Abnehmers schließen lässt. Die damit verbunde-
nen Integrations- und Schnittstellenprobleme sowie eine hohe Komplexität werden hin-
gegen von den OEM-Ansprechpersonen deutlich stärker wahrgenommen. Die Kern-
anforderungen Transparenz und Flexibilität werden sowohl aus Lieferanten- als auch
aus Abnehmersicht als gleichermaßen relevant erachtet.
Basierend auf der Wahrnehmungsstärke der Phänomene wurden Tendenzen hinsicht-
lich der Kausalität zwischen Phänomenen und den identifizierten Anforderungen her-
geleitet. Aufgrund des gemeinsamen Auftretens der Phänomene war eine vollständig
isolierte Betrachtung jedoch nicht möglich. Darüber hinaus ließen sich im Rahmen der
Inhaltsanalyse zumindest für einen Teil der Anforderungen direkte Verknüpfungen zu
145 Diskussion der Ergebnisse
den Phänomenen herstellen. Bei der aggregierten Betrachtung beider Verknüpfungs-
mechanismen lassen sich schließlich alle Kernanforderungen mit Ausnahme von
Transparenz allen drei Phänomenen zuordnen. Daraus lässt sich eine generelle Rele-
vanz dieser Kernanforderungen für das LPMM im Netzwerkkontext ableiten. Die Be-
rücksichtigung von Abhängigkeiten scheint insbesondere bei Vorliegen von Aufgaben-
Interdependenz relevant zu sein. Die Forderung nach Transparenz ist vor allem im
Zusammenhang mit Aufgaben-Interdependenz und kollaborativen Leistungen relevant.
Die im Zusammenhang mit Forced Coopetition festgestellten Spannungen, wie Zu-
rückhaltung und eingeschränkter Informationsaustausch, deuten auf einen wettbe-
werbsbedingten Vertrauensverlust hin. Entgegen den Erwartungen wurden vertrau-
ensbildende Maßnahmen in den Interviews lediglich einmal genannt und folglich von
den Praktizierenden nicht als LPMM-relevante Anforderung bewertet. Ein möglicher
Grund dafür könnte in der schwierigen Implementation dieses weichen Faktors liegen.
Zur Beantwortung von FF 2c wird nachfolgend auf die ermittelten LPMM-Modellele-
mente und Dimensionen Bezug genommen. Alle zehn deduktiv abgeleiteten LPMM-
Modellelemente konnten auch über die induktive Vorgehensweise ermittelt und damit
validiert werden. Als Kernelemente mit mehr als fünf Nennungen wurden Strategie
und Zielsetzung, Kriterien und Messung sowie das Anreizsystem identifiziert. Letzt-
genanntes wird insbesondere aus Sicht der Lieferanten als notwendig erachtet und
weniger als reaktive Maßnahme, sondern vielmehr als proaktives Steuerungselement
verstanden. Neben drei allgemeingültigen Anreizarten wurden drei weitere kontextspe-
zifische Anreize identifiziert. Neben dem Verschaffen eines Gesamtüberblicks, können
auch ein innovatives und agiles Arbeitsumfeld sowie gemeinsame Werte und eine of-
fene und vertrauensvolle Unternehmenskultur motivierend auf Lieferanten wirken. Um-
gesetzt werden könnte letztgenanntes z. B. durch die verpflichtende gemeinsame Teil-
nahme aller Projektbeteiligten an einem vom Auftraggeber angebotenen Seminar zu
Kommunikationsgrundsätzen, Kultur und Verhaltenskodex für solch komplexe Pro-
jekte. Auffällig war, dass u. a. Feedback ausschließlich von Lieferanten-Kontaktperso-
nen genannt wurde. Aus den Interviews ist hervorgegangen, dass einige Lieferanten
niemals direktes Feedback von OEMs erhalten haben, obwohl der Wunsch danach
bestand. Die scheinbar mangelnde Relevanz aus OEM-Sicht deutet darauf hin, dass
das Potenzial von Feedback zur Leistungsverbesserung möglicherweise in der Praxis
noch nicht ausreichend erkannt oder berücksichtigt wurde.
Diskussion und Beitrag zur Forschung 146
Hinsichtlich der notwendigen Dimensionen für das LPMM im Netzwerkkontext schlu-
gen die Teilnehmenden am häufigsten eine Unterscheidung hinsichtlich der Mess-
ebene und des Zeitpunkts der Messung vor. Damit bestätigt sich die anfängliche Ver-
mutung, dass in komplexen Lieferantennetzwerken Kennzahlen auf individueller und
aggregierter Ebene erforderlich sind.
In Hinblick auf die Beantwortung der FF 2d, konnten insgesamt 16 Faktoren für eine
erfolgreiche Integration ermittelt werden (siehe Tabelle 20), wobei ein Großteil lediglich
ein bis zwei Nennungen erhalten hat und damit kaum repräsentativ ist. 13 von 16 Er-
folgsfaktoren lassen sich nach Einschätzung der Autorin im Rahmen eines LPMM-
Prozesses umsetzen. Auch hier ist der Kommunikations-Aspekt von entscheidender
Relevanz, da dieser zusammen mit einer gemeinsamen Integration & Trouble Shoo-
ting zu den zwei am häufigsten genannten Erfolgsfaktoren zählt. Dies deckt sich wie-
derum mit der identifizierten Anforderung der Kollektivität sowie der Identifikation von
Kommunikation als einen der Haupteinflussfaktoren auf die Performance.
Zur Beantwortung von FF 3a wurde in Kapitel 3.6.5.2 geprüft, inwiefern die vorab er-
mittelten Anforderungen an das LPMM-Modell im Rahmen der Modellentwicklung um-
gesetzt werden konnten. Im Zuge dessen wurde zunächst festgestellt, dass alle erfor-
derlichen Modellelemente enthalten sind. Zehn von den insgesamt 16 Anforderungen
konnten unmittelbar im Rahmen des LPMM-Modelles oder der Scorecard implemen-
tiert werden. Die übrigen Anforderungen sind entweder teilweise erfüllt oder wurden
als Handlungsempfehlung aufgenommen (siehe Tabelle 23 und Anhang I). Das prak-
tische Gestaltungsziel des entwickelten LPMM-Modelles besteht letztendlich in der
Steigerung der Lieferanten- und Netzwerk-Performance durch die Anwendung dedi-
zierter Lieferantensteuerungsmechanismen und -prozesse im Kontext der Beschaf-
fung komplexer Integrationsgüter wie Embedded Software. Aufgrund der Erfüllung ei-
nes Großteils der Anforderungen wird die generelle Eignung des entwickelten Model-
les zur Erfüllung des vorgesehenen Zwecks vermutet. Die praktische Eignung kann
jedoch erst nach einer Anwendung im Rahmen von Pilot-Projekten final bestätigt wer-
den.
FF 3b bezieht sich auf die Herleitung von Handlungs- und Gestaltungsempfehlungen,
welche für das LPMM im Kontext der Embedded-Software-Beschaffung angewandt
werden können. Hierzu wurden die Aussagen der Interview-Teilnehmenden geprüft
und nach LPMM-Modellanforderungen und -elementen geclustert. In Kapitel 3.6.5.3
147 Zusammenfassung der Erkenntnisse
wurden die insgesamt 48 ermittelten Handlungsempfehlungen zur praktischen Umset-
zung der Anforderungen sowie zur Gestaltung der LPMM-Elemente tabellarisch dar-
gestellt. Hierbei ist zu berücksichtigen, dass es sich bei den meisten Handlungsemp-
fehlungen um die persönliche Meinung von Einzelpersonen handelt und folglich kein
Anspruch auf Korrektheit oder Vollständigkeit besteht.
4.2 Zusammenfassung der Erkenntnisse
Das Ziel dieses Forschungsvorhabens besteht einerseits in der Entwicklung eines de-
dizierten LPMM-Modelles, welches die Spezifika des vorliegenden Multi-Sourcing-Be-
schaffungskontextes adäquat adressiert und andererseits in der Ableitung von konkre-
ten Handlungsempfehlungen für die Steuerung von Lieferanten-Netzwerken bei der
Beschaffung von komplexen Integrationsgütern wie Embedded Software. Hinsichtlich
der Spezifika wurde der Fokus auf die Phänomene Aufgaben-Interdependenz, Forced
Coopetition und kollaborative Leistungen gelegt, da diese eine mutmaßliche Relevanz
für den vorliegenden Beschaffungskontext aufweisen. Zu diesem Zweck wurde in Ka-
pitel 2.1 eine Analyse des aktuellen Forschungsstandes durchgeführt, welche in der
Entwicklung eines konzeptionellen Bezugsrahmens sowie in der Schärfung der For-
schungslücke mündete. Darauf aufbauend fand in Kapitel 3.2 basierend auf einer sys-
tematischen Literaturrecherche im Bereich Netzwerk Performance Management eine
deduktive Herleitung der Anforderungen an ein dediziertes LPMM-Modell, welches die
Spezifika des Beschaffungskontextes adressiert, statt. Schließlich wurde in Kapitel 3.4
anhand einer eingebetteten Fallstudie zum einen eine Validierung der LPMM-Model-
lanforderungen vorgenommen. Zum anderen konnten in diesem Zuge induktiv weitere
Anforderungen sowie Handlungs- und Gestaltungsempfehlungen identifiziert werden.
Weiterhin konnten die Relevanz der o. g. Phänomene sowie deren Performance-Ein-
fluss im Rahmen der Fallstudie tiefgreifend untersucht werden. Basierend auf den Er-
kenntnissen wurde abschließend ein netzwerkspezifisches LPMM-Modell entwickelt,
welches in Kapitel 3.6.5.2 vorgestellt und bewertet wurde.
Bezugnehmend auf den konzeptionellen Bezugsrahmen aus Kapitel 2.1.4 kann fest-
gestellt werden, dass die Phänomene Aufgaben-Interdependenz, Forced Coopetition
und kollaborative Leistungen sowohl für das LPMM bei der Beschaffung komplexer
Integrationsgüter im Allgemeinen als auch für den speziellen Fall der Beschaffung von
Embedded Software von signifikanter Bedeutung sind. Dementsprechend konnte die
Notwendigkeit einer gezielten Steuerung im Rahmen eines LPMM aufgezeigt werden.
Diskussion und Beitrag zur Forschung 148
Hinsichtlich der Kontext-Faktoren, dem Konstrukt der Performance auf individueller
und Netzwerk-Ebene, den kontextspezifischen Phänomenen und der erfolgreichen In-
tegration konnte an den aktuellen Stand der Forschung angeknüpft und es konnte da-
hingehend ein tiefgreifendes Verständnis erlangt werden.
In sieben von acht untersuchten Fällen wurden die Phänomene Forced Coopetition,
Aufgaben-Interdependenz und kollaborative Leistungen in unterschiedlicher Intensität
von den Interview-Teilnehmenden wahrgenommen, wobei nur geringe Unterschiede
zwischen der Lieferanten- und Kundensicht festgestellt wurden. Auffällig ist, dass aus
Forced Coopetition resultierende Spannungen überwiegend von den Zulieferern wahr-
genommen wurden, was auf ein mangelndes Bewusstsein für die negativen Auswir-
kungen dieses Phänomens auf Seiten der OEMs hindeutet. Bei den identifizierten
Problemen und Anforderungen waren hingegen stärkere Unterschiede zwischen der
Lieferanten- und der Kundensicht zu verzeichnen. Während bei den Zulieferern Input-
faktoren und Aspekte der Zusammenarbeit im Vordergrund standen, wurden aus der
OEM-Perspektive vor allem produktbezogene bzw. technische Probleme verstärkt
wahrgenommen. Hinsichtlich der Wahrnehmung von Kommunikationsproblemen be-
stand ein genereller Konsens zwischen den Netzwerk-Akteuren. Dies bestätigt die Not-
wendigkeit, sowohl die vertikale als auch die horizontale Kommunikation im Lieferan-
ten-Netzwerk stärker zu fördern.
526
Im Rahmen dieser Studie konnten netzwerkspezifische LPMM-Modellanforderungen
deduktiv abgeleitet und empirisch validiert werden. Insbesondere die induktiv ermittelte
klare Abgrenzung von Verantwortlichkeiten und Schnittstellen wurde häufig genannt
und sollte als relevante Voraussetzung für das LPMM im Multi-Sourcing-Kontext be-
rücksichtigt werden. Von den sechs identifizierten Kernanforderungen sind Multi-Di-
mensionalität, d von Abhängigkeiten, Flexibilität, Kollektivi-
tät und die klare Abgrenzung von Verantwortlichkeiten mutmaß-
lich im Kontext von allen drei Phänomenen relevant. Dies gilt ebenfalls für die Kern-
elemente Kriterien & Messung, Strategie & Zielsetzung und Anreizsystem, wobei
dem Anreizsystem im Falle von kollaborativen Leistungen und der Berücksichtigung
von Abhängigkeiten bei Vorliegen von Aufgaben-Interdependenz eine höhere Rele-
vanz zukommt.
526
Vgl. Wilhelm (2011); Vgl. Wu et al. (2010).
149 Zusammenfassung der Erkenntnisse
Zusammenfassend lassen sich aus den gewonnenen Erkenntnissen die folgenden all-
gemeinen Theorieempfehlungen für ein LPMM-Modell im Netzwerkkontext ableiten:
Es bedarf keiner grundsätzlichen Anpassung des klassischen LPMM-Modells, sondern
vielmehr einer Anpassung einzelner Modellelemente. Bei der Gestaltung des LPMM-
Modells sollte der Fokus auf die identifizierten Kernanforderungen und -elemente ge-
legt werden, da diese, mit Ausnahme der Transparenz, für alle Phänomene Relevanz
aufzuweisen scheinen. So muss beispielsweise besonders darauf geachtet werden,
dass die Zulieferer möglichst frühzeitig in die Entwicklung des LPMM-Modells einbe-
zogen werden. Eine transparente Kommunikation der Ziele, Erwartungen, Kennzahlen
und Konsequenzen bei Nichterreichen der Ziele ist dabei unerlässlich.
527
Die Messung
und das Reporting sollten so kollaborativ wie möglich durchgeführt werden, um die
vorab ermittelten Interdependenzen entsprechend zu berücksichtigen.
528
Eine gegen-
seitige Bewertung von Lieferanten und die Einführung einer für alle Beteiligten sicht-
bare Lieferanten-Rangliste können durch die Erhöhung der Transparenz zur Steige-
rung der Netzwerk-Performance führen. Die Ergebnisse deuten daraufhin, dass eine
kollektivere Prozessgestaltung entlang des gesamten LPMM-Prozesses sowie eine
angemessene Belohnung und Anerkennung guter Leistungen den Zusammenhalt
stärken und für mehr Transparenz im Netzwerk sorgen können. Darüber hinaus sollten
regelmäßige gemeinsame Treffen genutzt werden, um zu überprüfen, ob eine Anpas-
sung bestimmter Prozessschritte oder Zielgrößen des LPMM-Modells aufgrund von
veränderten Rahmenbedingungen notwendig ist.
529
Wie gezeigt wurde, besteht eine weitere Steuerungsmöglichkeit der vorherrschenden
Netzwerkdynamik in der Performance-Messung auf individueller und Netzwerk-
ebene.
530
Durch die Ergänzung der bilateralen Betrachtung um eine Netzwerkperspek-
tive können Probleme besser lokalisiert und Steuerungsmechanismen gezielter einge-
setzt werden. Die hohe Relevanz von Kommunikationsproblemen sowohl auf der Zu-
lieferer- als auch auf OEM-Seite, gepaart mit dem beiderseitigen Wunsch nach mehr
Kollektivität, legt eine stärkere Förderung der vertikalen sowie der horizontalen Liefe-
ranten-Kommunikation aus Sicht des Abnehmers im Rahmen des LPMM nahe. An-
527
Vgl. Natour et al. (2011), S. 10.
528
Vgl. Pekkola/Ukko (2016), S. 1419; Vgl. Koppenjan (2008), S. 705f.
529
Vgl. Koppenjan (2008), S. 706.
530
Vgl. Pekkola/Ukko (2016), S. 1419.
Diskussion und Beitrag zur Forschung 150
knüpfend an die Erkenntnisse von Natour et al. (2011), S. 12 könne durch die Förde-
rung der Kommunikation zwischen allen Netzwerk-Akteuren Ziel-Konflikte verringert
und damit die Performance gesteigert werden. Die Implementierung einer Kommuni-
kationsplattform, die sowohl die zentrale als auch die dezentrale Kommunikation un-
terstützt und gleichzeitig den Datenschutz aller Akteure gewährleistet, ist unabdingbar,
um Informationsasymmetrien im Lieferantennetzwerk zu vermeiden.
531
Transparenz
sollte auch durch die Identifikation aller Abhängigkeiten und darauf aufbauend durch
eine klare Abgrenzung der Rollen und Verantwortlichkeiten der einzelnen Lieferanten
sowie ihrer Positionierung in der Gesamtstruktur erreicht werden.
4.3 Beiträge für Wissenschaft und Praxis
Im Rahmen dieser Dissertation konnten die wesentlichen Beiträge der aktuellen For-
schung in den Forschungsfeldern Software-Multi-Sourcing, Software-Outsourcing, Lie-
feranten Performance Management und Netzwerk Performance Management im Hin-
blick auf die zugrundeliegenden Forschungsfragen dargestellt werden. Darüber hinaus
konnte ein Beitrag zur Digitalisierung im Einkauf geleistet werden. In diesem Zusam-
menhang wurde gezeigt, dass die Verschmelzung der physischen und digitalen Welt
mit einer grundlegenden Veränderung der Lieferantenbeziehungen einhergeht und so-
mit neue Anforderungen an das LPMM stellt. Außerdem wurde die Relevanz der Phä-
nomene Aufgaben-Interdependenz, Forced Coopetition und kollaborative Leistungen
für das LPMM im Netzwerkkontext aufgezeigt und eine Erweiterung der wissenschaft-
lichen Erkenntnisse im Bereich dieser Phänomene erreicht. Damit wurde erstmals eine
ganzheitliche Untersuchung dieser drei Phänomene im Kontext der Beschaffung von
Embedded Software mit einer gleichzeitig zugrunde liegenden Netzwerkanalyseebene
durchgeführt. Nachfolgend wird der geleistete Beitrag zur Forschung im Bereich der
Phänomene genauer erläutert.
Im Zusammenhang mit Forced Coopetition wurden bereits bekannte Spannungen wie
Interessenkonflikte und eingeschränkter Informationsaustausch
532
bestätigt sowie wei-
tere Spannungen (allgemeine Zurückhaltung und Anspannung; ablehnendes und kont-
raproduktives Verhalten) identifiziert. Zusätzlich wurde eine gegensätzliche Wahrneh-
mung von Spannungen zwischen Zulieferern und Abnehmern aufgezeigt. Die Analyse
531
Vgl. Pekkola/Ukko (2016), S. 1417.
532
Vgl. Tidström (2014), S. 262; Vgl. Bengtsson et al. (2016), S. 6.
151 Beiträge für Wissenschaft und Praxis
der Wahrnehmung von Forced Coopetition im Rahmen von Projekt P12 ergab eine
mutmaßliche Abmilderung der negativen Auswirkungen durch die Einbindung eines
neutralen Dritten zwischen den konkurrierenden Unternehmen. Unter den fünf ermit-
telten Haupteinflussfaktoren, war einzig bei dem Phänomen Forced Coopetition ein
vorwiegend positiver Performance-Einfluss zu verzeichnen. Dies deckt sich mit den
Erkenntnissen von Bouncken/Fredrich (2012) und Mariani (2007), wonach Forced
Coopetition unter Bestimmten Bedingungen einen positiven Einfluss auf die Lieferan-
ten-Performance ausüben kann. Da OEM-Kontaktpersonen das Phänomen überwie-
gend als unbewussten Nebeneffekt wahrgenommen haben, deuten die Ergebnisse auf
eine mangelnde Wahrnehmung des performancesteigernden Potenzials durch ge-
zielte Steuerungsmaßnahmen wie Verträge und Zusatzvereinbarungen oder vertrau-
ensbildende Maßnahmen seitens OEM hin.
Das Verständnis von kollaborativen Leistungen wurde dahingehend erweitert, dass vor
allem die Lieferanten-Ansprechpersonen darunter primär einen zusätzlichen Entwick-
lungs- und Kommunikationsaufwand und weniger den Austausch sowie die Bereitstel-
lung von Informationen und Ressourcen verstehen.
533
Zudem wurde der Einfluss auf
die individuelle und die Netzwerk-Performance im Rahmen der Interviews vorwiegend
als negativ bewertet. Außerdem differierte das Verständnis kollaborativer Leistungen
hinsichtlich der Lieferanten- und OEM-Sicht, da aus OEM-Perspektive kein zusätzli-
cher Entwicklungsaufwand, sondern primär ein zusätzlicher Ressourceneinsatz wahr-
genommen wurde.
In Hinblick auf das Phänomen Aufgaben-Interdependenz konnten zahlreiche Über-
schneidungen hinsichtlich der damit im Zusammenhang stehenden Probleme und An-
forderungen mit dem Phänomen kollaborative Leistungen festgestellt werden. Dabei
wurden vor allem Kommunikationsprobleme und unklare Verantwortlichkeiten von den
Teilnehmenden aufgeführt. Klar abgegrenzte Verantwortlichkeiten, d
tigung von Abhängigkeiten, Transparenz, Multi-Dimensionalität und Kollektivi-
tätgehören zu den Anforderungen, welche in von Aufgaben-Interdependenz und kol-
laborativen Leistungen dominierten Projekten am häufigsten angesprochen wurden.
Eine weitere Erkenntnis lag in der besonders starken Wahrnehmung von Aufgaben-
Interdependenz durch Software-Lieferanten und Integratoren. Während sich bei den
Software-Lieferanten die Wahrnehmung der drei Phänomene nicht unterschied, fiel die
533
Vgl. Bapna et al. (2010), S. 790.
Diskussion und Beitrag zur Forschung 152
Wahrnehmung von Aufgaben-Interdependenz bei den Integratoren mit 100 % deutlich
am stärksten aus. Aus Lieferantensicht wurde das Phänomen außerdem als Haupt-
einflussfaktor auf die Netzwerk-Performance identifiziert.
Für den vorliegenden Beschaffungskontext konnten 16 netzwerkspezifische LPMM-
Modellanforderungen aus der bestehenden Forschungsliteratur deduktiv abgeleitet
und unter Zugrundelegung einer Netzwerkperspektive im Rahmen einer Fallstudie em-
pirisch ermittelt werden. Vergleichbare Studien in den Forschungsbereichen Lieferan-
ten Performance Management und Software-Multi-Sourcing basieren bisher überwie-
gend auf einer Einzellieferanten- oder dyadischen Perspektive.
534
Darüber hinaus ha-
ben nur wenige Studien in diesem Kontext eine gleichzeitige Untersuchung der Liefe-
ranten- und Abnehmerperspektive vorgenommen
535
oder sich auf horizontale Lieferan-
ten-Beziehungen im Kontext des Performance Managements konzentriert.
536
In Anleh-
nung an die Forschungsergebnisse von Wilhelm (2011) und Wu et al. (2010) wurde in
dieser Dissertation eine Netzwerkperspektive verwendet, um ein tiefgreifenderes Ver-
ständnis der dyadischen Lieferanten-Kunden-Beziehungen sowie der horizontalen Lie-
feranten-Beziehungen in komplexen Lieferanten-Netzwerken und der Rolle des Ab-
nehmers bei deren Steuerung zu gewinnen.
Zur Ermittlung der netzwerkspezifischen Anforderungen wurden Impulse aus der Lite-
ratur im Bereich Netzwerk Performance Management auf das Lieferanten Perfor-
mance Management übertragen. Durch diese Verknüpfung zwischen den beiden Lite-
raturströmungen konnten Anforderungen deduktiv ermittelt und anschließend am Bei-
spiel des Beschaffungsobjektes Embedded Software einer praktischen Validierung un-
terzogen werden. Aufgrund der fehlenden Beschaffungsperspektive sowie eines
grundlegend verschiedenen Netzwerkverständnisses in der Netzwerk-Performance-
Management-Literatur wurde die Übertragbarkeit der Anforderungen kritisch hinter-
fragt und nicht immer als gewährleistet befunden. Basierend auf den vorab ermittelten
Anforderungen wurde schließlich ein LPMM-Modell entwickelt, welches die Phäno-
mene Aufgaben-Interdependenz, Forced Coopetition und kollaborative Leistungen so-
wie den Netzwerkkontext bei der Embedded-Software-Beschaffung adressiert. Folg-
lich konnte mit den ermittelten Anforderungen und dem entwickeltem LPMM-Modell
534
Assmann/Punter (2004); Ebert (2017); Noshad/Awasthi (2015); Kumar/Thangavelu (2013).
535
Oza (2006); Plugge/Janssen (2014).
536
Pérez Mesa/Galdeano-Gómez (2015); Wu/Choi (2005); Wilhelm (2011).
153 Beiträge für Wissenschaft und Praxis
ein Beitrag zur LPMM-Literatur geleistet werden. Die Übertragbarkeit dieses Modells
auf Integrationsgüter anderer Branchen, die in einem Lieferanten-Netzwerk entwickelt
werden (z. B. Luft- und Raumfahrt, Maschinen- und Anlagenbau), wird aufgrund von
vergleichbaren Kontext-Faktoren angenommen. Darüber hinaus wird von einer An-
wendbarkeit für Zulieferer ausgegangen, die ihrerseits eine Vielzahl von Unterlieferan-
ten während der Produktentwicklung zu steuern haben.
Die im Rahmen der Dissertation ermittelten Handlungs- und Gestaltungsempfehlun-
gen sowie das LPMM-Modell können von Praktizierenden im Bereich Lieferantenma-
nagement als anwendungsorientierte Leitlinien für die Gestaltung und Anwendung von
LPMM-Modellen genutzt werden. Einblicke in die Wahrnehmung der Lieferanten kön-
nen außerdem zu einem besseren Verständnis der Lieferantenperspektive auf Seiten
der Abnehmer führen und damit einen gezielteren und lösungsorientierten Umgang mit
Problemen und Diskrepanzen ermöglichen. Praktizierende sollten bei der Anwendung
des entwickelten LPMM-Modells vor allem die identifizierten Kernanforderungen be-
rücksichtigen und sich dabei insbesondere auf die Probleme und Anforderungen kon-
zentrieren, die primär aus der Sicht der Lieferanten genannt werden. Darüber hinaus
sollten Projektkonstellationen mit geteilter Integrationsverantwortung und Setz-Liefe-
ranten entweder vermieden oder gezielter gesteuert werden, um die daraus resultie-
renden Probleme zu vermeiden. In Hinblick auf die verstärkte Wahrnehmung von Auf-
gaben-Interdependenz durch Integratoren, sollten Abnehmer diese bei der Identifika-
tion und Koordination von Abhängigkeiten gezielt unterstützen und dadurch für mehr
Transparenz im Lieferanten-Netzwerk sorgen.
Fazit und Limitationen 154
5 Fazit und Limitationen
5.1 Kritische Würdigung
Nachfolgend wird eine Prüfung der wissenschaftlichen Güte der angewandten For-
schungsmethodik anhand der in Kapitel 1.3 aufgeführten Gütekriterien durchgeführt.
Zur Gewährleistung der Konstruktvalidität fand zunächst eine a priori Spezifikation der
zu untersuchenden Konstrukte basierend auf einer umfassenden Literaturrecherche
statt. Im Zuge dessen wurden Anforderungen deduktiv hergeleitet, welche durch die
empirische Fallstudie anschließend validiert werden konnten. Folglich wurde durch die
deduktiv-induktive Vorgehensweise bei der Ermittlung der LPMM-Modellanforderun-
gen- und -elemente eine Methodentriangulation vorgenommen.
Zur Erhöhung der internen Validität wurde keine Einzelfallstudie, sondern eine einge-
bettete Fallstudie bestehend aus acht ähnlichen Fällen mit vergleichbaren Rahmenbe-
dingungen durchgeführt. Eine argumentative Validierung fand im Rahmen der Einzel-
fall- und fallübergreifenden Analyse statt. Außerdem wurden neben den Interviews die
vorab ausgefüllten Projektsteckbriefe als zusätzliche Datenquellen herangezogen.
Eine Triangulation durch den Einsatz mehrerer Forschenden wurde hingegen nicht
vorgenommen. Außerdem konnte durch das regelgeleitete Vorgehen in Anlehnung an
Mayring (2020), Kuckartz (2016) und Mayring/Fenzl (2014) eine Erhöhung der internen
Validität erreicht werden. Die Befragung der Teilnehmenden fand basierend auf einem
semi-standardisierten Interviewleitfaden statt. Eine Einschränkung ergibt sich aus der
iterativen Anpassung des Leitfadens im Verlauf der Studie aufgrund von festgestellten
Verständnisproblemen. Es handelt sich dabei jedoch lediglich um geringfügige Anpas-
sungen, welche vollständig dokumentiert wurden. Um die Notwendigkeit von Anpas-
sungen zu vermeiden, wäre eine Pilotstudie im Vorfeld der Interviews erforderlich ge-
wesen, welche im Rahmen dieser Arbeit nicht durchführbar war. Um eine mögliche
Beeinflussung der Teilnehmenden zu verhindern, wurden weitestgehend offene Fra-
gen gestellt und es wurde keine der deduktiv hergeleiteten Anforderungen in den Fra-
gen erwähnt.
Um die Reproduzierbarkeit der Studie zu gewährleisten und damit die externe Validität
zu erhöhen, wurden sowohl die Netzwerkakteure als auch die Interview-Teilnehmen-
den innerhalb der Unternehmen nach einheitlichen und vorab definierten Kriterien aus-
gewählt. Die Untersuchung großer Lieferanten-Netzwerke im Rahmen der Studie er-
155 Ausblick
forderte eine Komplexitätsreduktion durch die Befragung ausgewählter Netzwerkak-
teure. Durch die auf der Einschätzung der verantwortlichen Einkäuferinnen und Ein-
käufer beruhende Vereinfachung kann das Fehlen relevanter Lieferanten in den Netz-
werkausschnitten nicht ausgeschlossen werden, wodurch Ergebnis-Verzerrungen auf-
treten können. Das Risiko wird jedoch durch eine Triangulation verringert, welche
durch die Befragung unterschiedlicher kooperierender Netzwerkakteure zu denselben
Themen und Fragestellungen gewährleistet wurde. Aus der fehlenden Beteiligung von
OEM-Ansprechpersonen bei zwei Projekten resultierte ein Ungleichgewicht, woraus
sich stellenweise Lücken in der Netzwerkperspektive ergeben haben können.
Im Rahmen der Studie konnte ein Zusammenhang zwischen den Phänomenen und
der Lieferanten- und Netzwerk-Performance aufgezeigt werden, jedoch kann vorerst
keine Aussage über die Stärke des Einflusses getroffen werden. Außerdem ist unklar,
ob und inwiefern sich die Phänomene gegenseitig beeinflussen. Um die auftretenden
Probleme und Kontextfaktoren des Beschaffungskontextes in Gänze zu erfassen, wur-
den für die Fallstudie ausschließlich Entwicklungsprojekte ausgewählt, welche von den
zuständigen Einkäuferinnen und Einkäufern als besonders problembehaftet beschrie-
ben wurden. Möglicherweise resultiert aus der gezielten Auswahl kritischer Projekte
eine Neigung der Teilnehmenden zur Nennung primär negativ dominierter Aspekte.
Dies kann hinsichtlich der Analyse der Performance-Einflüsse zu einer Verzerrung der
Ergebnisse führen. Außerdem wurde die Performance nicht anhand objektiver Krite-
rien gemessen, sondern basierend auf dem Erfahrungswissen der Teilnehmenden
subjektiv eingeschätzt. Folglich kann eine Verzerrung der Ergebnisse nicht ausge-
schlossen werden und die daraus abgeleiteten Hypothesen bedürfen einer weiteren
Untersuchung im Rahmen quantitativer Forschungsdesigns.
In Anlehnung an die Erkenntnisse von Seuring (2008) wurde eine umfangreiche Do-
kumentation des Datenerhebungs- und -analyseprozesses durchgeführt, um Stringenz
und Nachvollziehbarkeit zu gewährleisten und damit zur Reliabilität beizutragen
537
5.2 Ausblick
Im Rahmen dieses Forschungsvorhabens konnten die Phänomene Forced Coopeti-
tion, Aufgaben-Interdependenz und kollaborative Leistungen unter Zugrundelegung ei-
537
Vgl. Seuring (2008), S. 135.
Fazit und Limitationen 156
ner Netzwerk-Perspektive im Kontext der Embedded-Software-Beschaffung tiefgrei-
fend untersucht werden. Im Zuge der empirischen Fallstudie wurde zunächst die ge-
nerelle Relevanz der Phänomene für den spezifischen Beschaffungskontext bestätigt
und zusätzlich konnten Zusammenhänge zwischen den Phänomenen und der indivi-
duellen sowie der Netzwerk-Performance aufgezeigt werden. Basierend auf den auf-
gestellten Hypothesen, sollten die Stärke und Richtung der Performance-Einflüsse in
weiterführenden quantitativ angelegten Studien tiefgreifender untersucht werden. So
könnten beispielsweise Projekte, die von einem oder mehreren der Phänomene be-
troffen sind, direkt mit Projekten verglichen werden, die von keinem der Phänomene
betroffen sind. Um eine Vergleichbarkeit zu gewährleisten, sollten die übrigen Rah-
menbedingungen wie z. B. Branche oder Netzwerkgröße möglichst konstant gehalten
werden. In einer solchen Studie sollten die Lieferanten- sowie die Netzwerk-Perfor-
mance anhand vorab definierter Metriken zu verschiedenen Projekt-Meilensteinen ge-
messen werden, um den Einfluss einer subjektiven Bewertung zu vermeiden. Alterna-
tiv könnte eine umfassende, deutschlandweit und branchenübergreifend durchge-
führte Umfrage bei relevanten Netzwerkakteuren quantitative Belege für die aufgestell-
ten Hypothesen liefern.
Weiterhin besteht die Vermutung für das Auftreten von Wechselwirkungen zwischen
den einzelnen Phänomenen, was im Rahmen weiterer Studien aufgegriffen werden
könnte. Schließlich sollte das entwickelte LPMM-Modell anhand von Pilotstudien in der
Praxis getestet und abschließend validiert werden. Damit kann schließlich neben dem
wissenschaftlichen Erkenntnisgewinn auch die Bereitstellung praktikabler Lösungen
für die mit der Digitalisierung im Einkauf einhergehenden neuen Anforderungen im
Kontext des Lieferanten Performance Management und Measurements gewährleistet
werden.
Die Analyse bestätigte zwar die Notwendigkeit einer Messung auf Lieferanten- und
Netzwerkebene, jedoch konnten hinsichtlich der konkreten Ausgestaltung nicht alle of-
fenen Punkte geklärt werden. So hat sich beispielsweise im Rahmen der empirischen
Studie keine eindeutige Tendenz bezüglich des Wechselspiels zwischen der Akteurs-
und Netzwerk-Scorecard ergeben. Außerdem konnte nicht eindeutig geklärt werden,
in welchen Fällen eine Messung der eigenen Performance durch den Lieferanten oder
den OEM und in welchen Fällen eine gegenseitige Lieferanten-Beurteilung zu empfeh-
len ist. Zu diesem zweck wären weiterführende Studien erforderlich. Denkbar wäre
beispielsweise eine Aggregation aller Messdaten, welche sowohl von Lieferanten als
157 Ausblick
auch von Abnehmern erhoben werden auf einer übergeordneten Netzwerkebene. Dies
könnte durch ein festgelegtes Gremium aller Beteiligten erfolgen. Bei schlechter Per-
formance würde von der Netzwerk- auf die Akteurs-Ebene gewechselt, um die Ursa-
che identifizieren und entsprechende Maßnahmen einleiten zu können.
Anhang 158
Anhang
Anhang A: Beitrag der Netzwerk Performance Management-Literatur für den
vorliegenden Beschaffungskontext
538
Quelle
Art des Netz-
werkes
Methodik
Beitrag (Auszug)
Bonatto et al.
(2017)
Versorgungs-/
Business-Netz-
werk
Literaturrecherche,
Analytic Hierarchy
Process (AHP)
Performance-Dimensionen
Kriterien wie z.
Agostino/Arnaboldi
(2018)
Öffentliches
Netzwerk
Fallstudie
Unterscheidung zwischen
zentralisiertem und organisati-
onalem PMS; Unterscheidung
zwischen sozialisierenden
Komponenten (informeller An-
satz basierend auf Normen,
Werten und Beziehungen) und
hierarchischen Komponenten
(formelle Praktiken wie KPIs)
Herranz (2010)
Öffentliches
Netzwerk
Vergleichende
Fallstudie
3 Level der Netzwerk-Effektivi-
tät: Organisation, Netzwerk
und Gemeinde, Netzwerk-Per-
formance-Indikatoren: Wachs-
tum der Mitglieder, starke Be-
ziehungen, breites Service-
Pyo (2010)
Tourismus-
Netzwerk
Interviews, Fuzzy
Set Theory
Performance-Indikatoren für
Tourismus-Netzwerk: Trans-
Heranz (2010)
Öffentliches
Netzwerk
Literaturrecherche,
konzeptioneller
Bezugsrahmen
Strategische Optionen der
Netzwerk-Koordination: büro-
kratisch, unternehmerisch, ge-
meinschaftsorientiert; Abhän-
gigkeit der Performance von
strategischer Koordinations-
Ausrichtung
Vesalainen et al.
(2017)
Versorgungs-/
Business-Netz-
werk
Design Science,
Analytisches Mo-
dell
Performance-
rien-Set: Klarheit der Kon-
zepte; einfache Lesbarkeit
durch Visualisierung; Netz-
werk-Kapital ergibt sich aus
Strategischer Integration, In-
ter-Firm Interaktion und Sozi-
alkapital
Sena Ferreira et
al. (2012)
Kollaboratives
Netzwerk
Entwicklung Be-
zugsrahmen und
Prozessmodell
LPMM-Prozessablauf; Ablei-
tung der Kriterien und Indika-
538
Eigene Darstellung.
159 Anhang
Quelle
Art des Netz-
werkes
Methodik
Beitrag (Auszug)
toren von Zielgrößen; Abhän-
gigkeit der KPIs von Stakehol-
der-Charakteristik
Alnatour/Gibson
(2011)
Versorgungs-/
Business-Netz-
werk
Literaturrecherche
Vertrauen notwendig zur Stei-
gerung der Netzwerk Effektivi-
tät; Netzwerk-Performance-
Messung anhand Grad der
Zielerreichung oder Agency-
Bayne et al.
(2017)
Strategisches
Netzwerk
Multiple Fallstudie
Messung der strategischen
Netzwerk-Performance an-
hand Effektivität und Effizienz
Ferreira et al.
(2011)
Kollaboratives
Netzwerk
Multi-Kriterien Ent-
scheidungsmodell
Anforderung der Kollektivität;
Berücksichtigung von Komple-
xität; Referenz-Modell für Kri-
terien-Auswahl; Relevanz von
Kontextfaktoren; Element
Kommunikations-Infrastruk-
tur
José Alfaro Saiz et
al. (2007)
Versorgungs-/
Business-Netz-
werk
Literaturrecherche,
konstruktivistischer
Ansatz, Bezugs-
rahmen
Multi-Dimensionalität; Perfor-
mance-
Zielen, Strategien und Erfolgs-
faktoren; Performance-Mes-
sung auf individueller, Liefer-
ketten- und Netzwerkebene
Kenis/Provan
(2009)
Öffentliches
Netzwerk
Theorieentwick-
lung
Kriterien müssen klar spezifi-
ziert, angemessen und er-
reichbar sein; Identifikation
von exogenen Faktoren, die
für Netzwerk-Performance re-
levant sind; Differenzierung
zwischen Management und
Measurement erforderlich
Koppenjan (2008)
Kollaboratives
Netzwerk
Multiple Fallstudie
Anforderungen Komplexitäts-
Reduktion, Multi-Dimensio-
nalität, Kollektivität, Flexibi-
lität; mehr Spielraum für orga-
nisationales Lernen zur Ver-
meidung von Opportunismus;
Berücksichtigung von Zielver-
flechtungen bei Definition der
Kriterien
Mandell/Keast
(2007)
Kollaboratives
Netzwerk
Netzwerk-Analyse
Starke Kontextabhängigkeit
von Kriterien; diverse Bei-
spiele für Performance-Indika-
toren
Anhang 160
Quelle
Art des Netz-
werkes
Methodik
Beitrag (Auszug)
Parung/Bititci
(2008)
Kollaboratives
Netzwerk
Fallstudie, AHP
Kriterien Commitment, Ko-
ordination, Vertrauen, Kon-
fliktlösungsfähigkeit & Operati-
onalisierung; Erfolgsfaktoren:
Input jeder teilnehmenden
Person, Kollaborations-Me-
chanismen, Netzwerk-Ge-
sundheit
Pekkola/Ukko
(2016)
Kollaboratives
Netzwerk
Fallstudie
Relevanz von Kontextfakto-
ren; Anforderungen Kollektivi-
tät, Flexibilität, Multi-Di-
mensionalität, Transparenz,
Messung auf individueller &
aggregierter Ebene
Straub et al.
(2004)
Versorgungs-/
Business-Netz-
werk
Spieltheoretischer
Ansatz
Kriterien Informationsaus-
tausch und Abhängigkeit;
Netzwerk-Performance kann
über Aggregation der Einzelfir-
men-Leistung oder über Erhe-
bung netzwerkspezifischer Er-
folgsgrößen gemessen wer-
den
Verdecho et al.
(2011)
Kollaboratives
Netzwerk
Fallstudie, AHP
Performance-Dimensionen
rien Commitment, Know-
How, Innovationskompe-
tenz, Koordination
Anhang B: Dimensionen und Kriterien der Balanced Scorecard (Entwurfs-
stand)
539
Dimension
Kriterium
Quellen
Wachstum & Ler-
nen540
Inter-organisationales Lernen
Vesalainen et al. (2011)
Lernfähigkeit
Kumar/Thangavelu (2013)
Innovationskompetenz
Bonatto et al. (2017); Verdecho et
al. (2012)
Trainings / Kurse
Bonatto et al. (2017);
Entwicklungs-Pro-
jekt541
Soll-/Ist-Abweichung
Bonatto et al. (2017); Verdecho et
al. (2012)
Liefertreue
José Alfaro Saiz et al. (2007);
Ebert et al. (2008)
Entwicklungskosten
Assmann/Punter (2004)
539
Eigene Darstellung.
540
in Anlehnung an Kaplan/Norton (1996b), S. 76.
541
in Anlehnung an Assmann/Punter (2004), S. 144.
161 Anhang
Dimension
Kriterium
Quellen
Fehlerrate
Verdecho et al. (2012); Ebert et
al. (2008)
Unit Testing
Bacon et al. (2017)
Prozesse542
Integrationsplanung & -strategie
Bacon et al. (2017); Ilyas/Khan
(2015); Zafar et al. (2011)
Standardisierte Prozessmodelle
Ilyas/Khan (2015); Zafar et al.
(2011)
Initiativen zur Leistungsverbes-
serung
Bonatto et al. (2017); Verdecho et
al. (2012)
Qualitätssicherung
Ilyas/Khan (2015); Zafar et al.
(2011)
Sozialkapital543
Gemeinsames Verständnis
Kumar/Thangavelu (2013)
Geteilte Ansichten, Normen
Vesalainen et al. (2011)
Unternehmensbeitrag zum Netz-
werk
Bonatto et al. (2017)
Vertrauen
Vesalainen et al. (2011)
Aufgaben-Interde-
pendenz544
Schnittstellen-Kompatibilität
Ilyas/Khan (2015); Zafar et al.
(2011)
Definierte Verantwortlichkeiten
Zafar et al. (2011); van Moll/Am-
merlaan (2008)
Technische Interdependenzen
Zafar et al. (2011)
Zusammenarbeit545
Bonatto et al. (2017); Pa-
rung/Bititci (2008)
Informationsaustausch
Vesalainen et al. (2011); Straub et
al. (2004)
Forced Coopetition
Wiener/Saunders (2014); Buttsch-
ardt (2017)
Kollaborative Fähigkeit
Bapna et al. (2010); Bonatto et al.
(2017); Vesalainen et al. (2011)
542
in Anlehnung an Kaplan/Norton (1996b), S. 76.
543
in Anlehnung an Vesalainen et al. (2017), S. 306; in Anlehnung an Bonatto et al. (2017), S. 6.
544
Vgl. Straub et al. (2004), S. 87; Vgl. Bapna et al. (2010), S. 790.
545
in Anlehnung an Verdecho et al. (2011), S. 156; in Anlehnung an Bonatto et al. (2017), S. 6.
Anhang 162
Anhang C: Interview-Leitfaden in ursprünglicher Form
546
Frage
Quelle
Adres-
sierte
FF
Erwartete Antworten
& Beitrag
Begrüßung, Vorstellung, Zielstellung, Hinweis
zur Aufnahme und Anonymisierung
eigene
-
-
Stellen Sie sich bitte einmal kurz vor. In wel-
cher Funktion sind bzw. waren Sie im Rahmen
des Projektes XY tätig? Welchen beruflichen
Hintergrund haben Sie?
eigene
-
Einordnung
Bitte beschreiben Sie kurz die Rolle Ihrer
Firma sowie die Rolle der Firmen X und Y im
Projekt Z. Wer hat welchen Beitrag geleistet?
Vgl.
Nemeh
(2014),
S. 303
-
Einordnung, Lieferanten-
Konstellation, Rollen & Ver-
antwortlichkeiten im Projekt
Beschreiben Sie die Zusammenarbeit mit an-
deren an der Entwicklung beteiligten Lieferan-
ten sowie dem OEM im Rahmen des Projektes
XY. Welche Probleme treten dabei auf?
Vgl.
Wu/Choi
(2005),
S. 51
1a, 1b
globale Frage nach Proble-
men, die bei Zusammenar-
beit im Netzwerk auftreten,
ggf. hinweise auf weitere
Phänomene
Inwiefern und in welchem Ausmaß sind Sie auf
unterstützende bzw. kollaborative Leistungen
von anderen Lieferanten im Projekt XY ange-
wiesen und umgekehrt? Inwiefern und in wel-
chem Ausmaß erfordert das Projekt XY von
Ihnen das Erbringen von kollaborativen Leis-
tungen, zusätzlich zu Ihrer vertraglich verein-
barten Leistung?
Vgl. Hsu
(2018),
S. 732
1b
Vorhandensein und Aus-
maß von kollaborativen
Leistungen prüfen, Erken-
nen, ob dieses Phänomen
in dem Kontext relevant ist,
Aufschluss über die Art die-
ser Leistungen
Inwiefern und in welchem Ausmaß treten Ab-
hängigkeiten oder Wechselwirkungen in der
Leistungserstellung zwischen Ihnen und ande-
ren Lieferanten im Rahmen des Projektes XY
auf?
Vgl.
Wu/Choi
(2005),
S. 50
Wu/Choi
(2005),
S. 50
1b
Vorhandensein und Aus-
maß von Aufgaben-Interde-
pendenz prüfen, Erkennen,
ob dieses Phänomen in
dem Kontext relevant ist,
Aufschluss über die Art der
Interdependenzen
Haben Sie das Gefühl, dass Ihr Kunde im Rah-
men des Projektes XY Kollaboration oder
Wettbewerb zwischen den Lieferanten oder
gar beides gleichermaßen aktiv forciert?
Vgl.
Wilhelm
(2011),
S. 674
1b
Vorhandensein und Aus-
maß von Forced Coopeti-
tion prüfen, Erkennen, ob
dieses Phänomen in dem
Kontext relevant ist
Treten dabei ggf. Spannungen oder Konflikte
für Sie auf? Bitte beschreiben Sie kurz Ihre Er-
fahrungen bei der Zusammenarbeit mit konkur-
rierenden Firmen.
Vgl.
Bengtss
on et al.
(2016),
S. 24
1b
Vorhandensein und Aus-
maß von Forced Coopeti-
tion prüfen, Erkennen, ob
dieses Phänomen in dem
Kontext relevant ist; Arten
von möglichen Spannun-
gen ermitteln
Welche Probleme sind im Rahmen des XY
Projekts speziell in Bezug auf die System-In-
tegration aufgetreten?
Vgl.
Larsson
et al.
(2009),
S. 1069
1a, 1b,
2d
Problem in Zusammenhang
mit Integration erfassen,
mögliche Hinweise auf wei-
tere Phänomene, Probleme
können mögliche Hinweise
546
Eigene Darstellung.
163 Anhang
Frage
Quelle
Adres-
sierte
FF
Erwartete Antworten
& Beitrag
auf Modell-Dimensionen
und Kriterien liefern
Inwiefern und in welchem Ausmaß kann Ihre
individuelle Leistung bzw. die gesamte Netz-
werk-Performance durch die zuvor angespro-
chenen Probleme negativ oder positiv beein-
flusst werden? Können Sie diesbezüglich Zu-
sammenhänge feststellen?
Vgl. Hsu
(2018),
S. 732
1a,1b,
1c
Einflussmöglichkeit der
Probleme und Phänomene
auf die Lieferanten-Perfor-
mance ermitteln und damit
Prüfung, ob die aufgestell-
ten Zusammenhänge be-
stätigt werden können
Validierung des Bezugsrah-
mens / Prüfung der Rele-
vanz der Phänomene im
Zusammenhang mit Netz-
werk-Performance
Inwiefern fördert Ihrer Meinung nach das aktu-
ell von [Abnehmer] gelebte Performance Ma-
nagement-Modell eine nahtlose Integration
der extern entwickelten Softwarekomponen-
ten? Werden Aufgaben-Interdependenzen und
die Zusammenarbeit im Netzwerk adäquat
adressiert?
Vgl.
Plugge/
Janssen
(2014),
S. 95
2b, 2c
Die Frage zielt darauf ab zu
erfahren, ob gewisse Ele-
mente des aktuell gelebten
LPMM für diesen Kontext
geeignet sind und über-
nommen werden könnten
Basierend auf Ihrer Projekterfahrung aus der-
artigen Multi-Lieferanten-Softwareentwick-
lungs-Projekten: Wie müsste Ihrer Meinung
nach das Lieferanten Performance Manage-
ment in einem solchen Kontext in Hinblick auf
die erfolgreiche Integration gestaltet sein?
Welche Mechanismen, Anreizsysteme oder
Prüfkriterien werden benötigt, um die Zusam-
menarbeit im Lieferanten-Netzwerk und damit
die Netzwerk-Performance zu verbessern?
Vgl.
Plugge/
Janssen
(2014),
S. 95
2b, 2c,
2d
Explorative Frage nach Lö-
sungsansätzen für das
LPMM-Modell
Welche Ziele verfolgen Sie im Rahmen des
Projektes XY? Was motiviert Sie im Rahmen
von Forced Coopetition / Multi-Supplier- Ent-
wicklungsprojekten bestmögliche Leistungen
zu erbringen?
Eigene
Frage
2c
LPMM sollte an Zielen aus-
gerichtet sein, kollektive
Ziele wichtig für Messung
auf Netzwerk-Level, Frage
nach Motivation zielt auf
gezielte Anreizsetzung im
Sinne von Korrektur-Maß-
nahmen ab
[Modell zeigen und erläutern] Sind Ihrer Mei-
nung nach alle wesentlichen Prozessschritte
enthalten? Ist der Performance Management-
Prozess zielführend? Was würden Sie verän-
dern?
Eigene
Frage
3a, 3b
Validierung des Modelles
Mit welchen konkreten Maßnahmen, Mecha-
nismen oder Instrumenten würden sie die ein-
zelnen Prozessschritte befüllen, um die Zu-
sammenarbeit im Netzwerk und damit den In-
tegrations-Erfolg zu steigern?
Eigene
Frage
3a, 3b
Operationalisierung des
Modelles, Ermittlung von
Gestaltungsempfehlungen
Anhang 164
Frage
Quelle
Adres-
sierte
FF
Erwartete Antworten
& Beitrag
[Scorecard zeigen und erläutern] Halten Sie
diese Auswahl an Dimensionen und Kriterien
sowie den Ansatz, die Lieferanten-Perfor-
mance einerseits individuell als auch netzwerk-
basiert zu steuern für zielführend? Würden Sie
Anpassungen vornehmen? Für welche Krite-
rien könnten Sie sich eine Messung auf Netz-
werkebene vorstellen? Welche messbaren In-
dikatoren würden Sie in diesem Kontext ein-
ordnen / für sinnvoll erachten?
Eigene
Frage
3a, 3b
Validierung und Operatio-
nalisierung des Modelles,
Ermittlung von Gestaltungs-
empfehlungen
Anhang D: Interview-Leitfaden in finaler Form
547
• Begrüßung, Vorstellung, Zielstellung, Hinweis zur Aufnahme und Anonymisie-
rung
• Stellen Sie sich bitte einmal kurz vor. In welcher Funktion sind Sie im Rahmen
des XY Projektes tätig? Welchen beruflichen Hintergrund haben Sie?
• Bitte beschreiben Sie kurz die Rolle von Firma XY im Rahmen des XY Projek-
tes. Gehen Sie dabei gern auch kurz auf die Rolle der Firmen Y und Z ein.
Wer hat welchen Beitrag geleistet?
• Bitte beschreiben Sie kurz wie sich im Rahmen des XY Projektes die Zusam-
menarbeit mit anderen Lieferanten sowie mit OEM X gestaltet. Welche Prob-
leme treten dabei auf?
• Inwiefern und in welchem Ausmaß treten Abhängigkeiten oder Interdependen-
zen in der Leistungserstellung zwischen Ihnen und anderen Lieferanten im
Rahmen des XY Projektes auf? Ist es im Rahmen des XY Projektes erforder-
lich, dass zusätzlich zur vertraglich vereinbarten Leistungserstellung unterstüt-
zende bzw. kollaborative Leistungen zwischen Lieferanten erbracht werden?
• Kommt es im Rahmen des XY Projektes vor, dass Wettbewerber miteinander
kollaborieren müssen? Haben Sie das Gefühl, dass OEM X im Rahmen des
XY Projektes die Koexistenz von Kollaboration und Wettbewerb zwischen Lie-
feranten während der Entwicklungsphase aktiv fördert? Sind Sie davon betrof-
fen?
• Treten dabei ggf. Spannungen oder Konflikte für Sie auf? Bitte beschreiben
Sie kurz Ihre Erfahrungen bei der Zusammenarbeit mit konkurrierenden Fir-
men.
• Welche Probleme sind im Rahmen des XY Projektes speziell in Bezug auf die
System-Integration aufgetreten und durch welche Maßnahmen hätten diese
ggf. verhindert werden können?
• Wie haben sich die gerade angesprochenen Probleme auf Ihre individuelle
Lieferanten-Performance einerseits und die aggregierte Netzwerk-Perfor-
mance andererseits im Rahmen dieses Projektes ausgewirkt? Können Sie
diesbezüglich Zusammenhänge feststellen?
547
Eigene Darstellung.
165 Anhang
• Wie nehmen Sie aus der Lieferantenperspektive das aktuell von OEM X ge-
lebte Lieferanten Performance Management wahr? Inwiefern fördert es eine
nahtlose Integration der extern entwickelten Softwarekomponenten?
• Basierend auf Ihrer Erfahrung aus dem XY Projekt oder vergleichbaren Pro-
jekten: Wie müsste Ihrer Meinung nach das Lieferanten Performance Manage-
ment in einem solchen netzwerkartigen Kontext in Hinblick auf die erfolgreiche
Integration gestaltet sein? Welche Mechanismen, Anreizsysteme oder Prüfkri-
terien werden benötigt, um die Zusammenarbeit im Lieferanten-Netzwerk und
damit die Netzwerk-Performance zu verbessern?
• Was motiviert Sie aus Lieferantensicht im Rahmen von derartigen Multi-Liefe-
ranten-Entwicklungsprojekten wie dem XY Projekt bestmögliche Leistungen
zu erbringen?
• Durch welche Maßnahmen kann Ihrer Meinung nach eine Angleichung der In-
teressen und Ziele der Akteure im Lieferanten-Netzwerk erfolgen? Gibt es Ih-
rer Meinung nach kollektive Ziele und Visionen im Rahmen des XY Projektes
bzw. werden diese klar kommuniziert?"
• [LPMM-Modell zeigen und erläutern] Wie bewerten Sie diesen Modellentwurf?
Sind Ihrer Meinung nach alle wesentlichen Prozessschritte enthalten? Ist der
Performance Management Prozess in Hinblick auf eine erfolgreiche Integra-
tion zielführend? Was würden Sie verändern?
• Mit welchen konkreten Maßnahmen, Mechanismen oder Instrumenten würden
sie die einzelnen Prozess-Schritte befüllen, um die Zusammenarbeit im Netz-
werk und damit den Integrations-Erfolg zu steigern?
• [Scorecard zeigen und erläutern] Halten Sie diese Auswahl an Dimensionen
und Kriterien sowie den Ansatz, die Lieferanten-Performance einerseits indivi-
duell als auch netzwerkbasiert zu steuern für zielführend? Würden Sie Anpas-
sungen vornehmen? Für welche Kriterien könnten Sie sich eine Messung auf
Netzwerkebene vorstellen und für welche nicht? Welche messbaren Indikato-
ren würden Sie in diesem Kontext einordnen / für sinnvoll erachten? Fallen
Ihnen abgesehen von den hier aufgezeigten Kriterien noch weitere Kriterien
ein, die in diesem Kontext von Relevanz sind?
• Dank, Fragen und Abmoderation
167 Anhang
548
Eigene Darstellung.
Anhang 168
Anhang F: Analyse und Implementation der Gestaltungsempfehlungen
549
Gestaltungsempfeh-
lung
Häu-
fig-
keit
Relevanz
Implementation
Direkte Kommunikati-
onswege zwischen Lie-
feranten
6
Ja: Entlastung des
OEM; Vorteil: kürzere
Informationswege &
Verschlankung
Doppelpfeile zwischen Lie-
feranten
Kürzere Iterationen
4
Ja: dynamischer Kon-
text, mehr Flexibilität
kann erreicht werden
Rückwärts gerichtete Pfeile
nach jedem Prozessschritt
Doppel-Pfeile bei allen
Prozessschritten des
LPMM
4
Ja: Zur Gewährleistung
von Kollektivität sollten
Lieferanten ein Mitbe-
stimmungsrecht bei der
Gestaltung des LPMM-
Modelles haben
Hinzufügen von Doppel-
Pfeil
Unterscheidung hinsicht-
lich Lieferanten-Rollen
wichtig
3
Ja: Berücksichtigung
der Sonderrolle des In-
tegrators, Gewährleis-
tung von Multi-Dimen-
sionalität
Separate Kästchen für Soft-
ware-Lieferant, System-Lie-
ferant und Dienstleister
Prozess dynamischer
gestalten
2
Ja: aufgrund des dyna-
mischen Umfeldes
möglichkeiten bislang nicht
identifiziert
Inputs durch interne Sta-
keholder integrieren
2
Ja: Bewertung & Ana-
lyse kann nur in Ab-
stimmung mit Quali-
tätssicherung und Ent-
wicklung erfolgen
Keine Integrationsmöglich-
keit identifiziert → Berück-
sichtigung bei Handlungs-
empfehlungen
Rollen & Verantwortlich-
keiten definieren
2
Ja: Klar abgegrenzte
Verantwortlichkeiten
als häufig genannte
Anforderung
Berücksichtigt unter dem
konfigura-
-
Steuerung
rieren
2
Ja: Berücksichtigung
von Abhängigkeiten als
häufig genannte Anfor-
derung
Berücksichtigt unter dem
konfigura-
Netzwerk-
Steuerung
Kürzere Informations-
wege
1
Nein: zielt auf Ände-
rung der Rahmenbe-
dingungen ab
-
Review und Rekalibrie-
rung als 2 separate
Punkte
1
Nein: Übersichtlichkeit
bewahren
-
Nur Frage-Recht, kein
Mitbestimmungsrecht für
Lieferanten
1
Nein: nicht darstellbar
-
549
Eigene Darstellung.
169 Anhang
Gestaltungsempfeh-
lung
Häu-
fig-
keit
Relevanz
Implementation
Umsetzung der Maß-
nahmen tracken
1
Nein: Monitoring um-
fasst bereits Tracking
der Umsetzung
-
Kontextfaktoren: Tech-
nologie-Reifegrad hinzu-
fügen
1
Ja
Als Punkt bei Kontextfakto-
ren hinzugefügt
Gestaltung wie "runder
Tisch", um Austausch im
Netzwerk besser zu cha-
rakterisieren
1
Nein: keine geeignete
Visualisierung identifi-
ziert
-
Individuelle Ziele sollten
kollektiven Zielen unter-
geordnet sein
1
Ja
mittels Pfeil veranschaulicht
Abgrenzung des Netz-
werkes (Steuergerät
oder Steugeräte-Ver-
bund?)
1
Ja: dynamisches Um-
feld, variable Netz-
werkkonfiguration
Berücksichtigt unter dem
konfigura-
Netzwerk-
Steuerung
Keine KPIs verwenden
1
Nein: ohne KPIs kann
keine objektive Bewer-
tung erfolgen
-
Fokus auf Ziele und
nicht Kriterien legen
1
Nein: Kriterien werden
von Zielen abgeleitet
-
Awards für gute Ergeb-
nisse
1
Ja: positive Anreiz im
Netzwerk besonders
wichtig
Netz-
werk-Steuerung
Transparenz bezüglich
KPI-Erreichung inner-
halb des Netzwerkes
1
Ja: Transparenz als
Anforderung definiert
der Netzwerk-Steuerung
Sub-Lieferanten integrie-
ren
1
Ja: Kontrolle über Sub-
Lieferanten bei Schlüs-
sel-Komponenten
Hinzufügen eines extra
Kästchens für Sub-Lieferan-
ten; zu klären: prozessuale
Umsetzung
Andere Zieldefinitionen
bei direct purchasing
1
Nein: Bedeutung unklar
-
Häufigkeit der Messung
definieren
1
Ja: Definition der Fre-
quenz als Anforderung
identifiziert
Netzwerkkonfiguration
Anhang 170
Anhang G: Analyse der Scorecard-Kriterien
550
Kriterium
Bestä-
tigt
Nicht
bestä-
tigt
Neu
Bsp. Für KPI [Einheit]
Technische Abhängig-
keiten
X
-
Schnittstellen-Kompati-
bilität
X
-
Definierte Verantwort-
lichkeiten
X
Vorliegen RASI Chart [ja/nein]
Termintreue
X
Meilenstein-Überschreitung
[Tage]
Unit Testing
X
Anzahl Compiler-Warnungen
[Stück]
Fehlerbehebung
X
-
Qualitätssicherung
X
A-SPICE [Level]
Standardisierte Pro-
zessmodelle
X
Erfüllungsgrad v. Normen [%]
Integrationsplanung
und -strategie
X
-
Geteilte Ansichten /
Normen
X
-
Vertrauen
X
-
Gemeinsames Ver-
ständnis
X
-
Trainings / Kurse
X
-
Anpassungsfähigkeit /
Lernfähigkeit
X
-
Interorganisationales
Lernen
X
-
Innovationskompetenz
X
-
Kommunikation / Infor-
mationsaustausch
X
-
Kollaborative Fähigkeit
X
-
Forced Coopetition
X
-
Health of collaboration
Index
X
-
Entwicklungskosten
X
-
Initiativen zur Leis-
tungsverbesserung
X
-
Unternehmensbeitrag
zum Netzwerk
X
-
Featureimplementie-
rung
X
Umgesetzte vs. geplante Fea-
tures [%]
550
Eigene Darstellung.
171 Anhang
Kriterium
Bestä-
tigt
Nicht
bestä-
tigt
Neu
Bsp. Für KPI [Einheit]
Lieferqualität
X
Anzahl Nachlieferungen
[Stück]
Funktionalität
X
Erfüllungsgrad Systemanforde-
rungen [%]
Fehlerbehebung
X
Mean Time To Repair (MTTR)
[Stunden]; durchschn. Bearbei-
tungsdauer Fehlerticket [Stun-
den]
Requirements Ma-
nagement
X
-
Flexibilität / Skalierbar-
keit
X
Reaktionsgeschwindigkeit bei
Änderungen [Tage]
System-Kompetenz
X
-
Program Management
Capability
X
Stakeholder Manage-
ment
X
-
Anhang H: Analyse und Implementation der Scorecard-Gestaltungsempfehlun-
gen
551
Gestaltungsempfehlung
Relevanz
Implementation
Kategorie "Other" für Projektspezifische
Kriterien
Ja
der Dimension hinzugefügt
Priorisierungen vornehmen, kein Anspruch
auf Vollständigkeit
Ja
Darstellung aus Platzgründen
nicht möglich, sollte aber vom
Anwender umgesetzt werden
Handlungsempfehlung
Für alle Kriterien Soll und Ist definieren
Ja
Darstellung aus Platzgründen
nicht möglich, sollte aber vom
Anwender umgesetzt werden
Handlungsempfehlung
Dimensionen und Kriterien sind sinnvoll
ausgewählt
Ja
Keine Implementation erforder-
lich
Fehlerzuschreibung im Netzwerk schwie-
rig
Nein
-
Gleiche Metriken auf Netzwerk- und Liefe-
rantenebene anwenden
Nein
Begründung: Manche Metriken
sind nur im Netzwerk oder nur
auf Lieferantenebene messbar
Nein
Kriterien sollten von individuel-
len Unternehmens-Zielen abge-
leitet werden und sind daher be-
gründet
551
Eigene Darstellung.
Anhang 172
Anhang I: Erfüllungsgrad der allgemeinen LPMM Modell- und Managementkon-
zeptanforderungen
552
Anforderung
Erfüllungsgrad
Begründung
Bewertungs- und Mess-
instrument
erfüllt
Modell enthält eine integrierte Scorecard
zur Performancemessung
Steuerungs- und Über-
wachungsinstrument
erfüllt
Feedbackinstrument
erfüllt
Entscheidungsunterstüt-
zungsinstrument
erfüllt
leistet
Beziehungsentwick-
lungsinstrument
erfüllt
Risikominderung
erfüllt
Wird über Transparenz durch Kommunikati-
onsinfrastruktur sowie den kontinuierlichen
- -Prozess unter
Einbezug sich ändernder Kontextfaktoren
gewährleistet
Review & Rekalibrierung
erfüllt
im Modell enthalten
Inklusion aller relevanter
Stakeholder
erfüllt
Unter Kontextfaktoren befindet sich der
Kontextorientierung
erfüllt
Einfluss der Kontextfaktoren als Umfeldele-
ment im Modell enthalten
Objektorientierung
erfüllt
Bezugsobjekt stellt Embedded Software
oder ein vergleichbares Beschaffungsobjekt
dar
Ursachen-Wirkungsori-
entierung
erfüllt
Die Zielgröße der Performance soll durch
den Einsatz des Modelles gesteigert wer-
den; Darstellung der Phänomene als Ein-
flussfaktoren
Erfolgsbeitragsorientie-
rung
erfüllt
Zielgrößen Lieferanten- und Netzwerk-Per-
formance im Modell enthalten
Prozess- und Rollenori-
entierung
erfüllt
Modell enthält Prozessablauf für das LPMM
inklusive Rückkopplungen; Klare Rollenauf-
teilung zwischen dem Abnehmer und Liefe-
ranten als Teil des Netzwerkes
Instrumentenorientierung
erfüllt
LPMM-Prozessschritte und Elemente der
Netzwerksteuerung stellen anwender- und
lösungsorientierte Instrumente dar
Regel- und Normorientie-
rung
Teilweise erfüllt
Modell enthält keine direkten Regeln und
Normen, jedoch können Handlungsempfeh-
lungen als solche verstanden werden
Integrationsfähigkeit
erfüllt
Modell soll als Referenz-Modell genutzt und
daher kontextspezifisch angepasst werden;
552
Eigene Darstellung.
173 Anhang
Anforderung
Erfüllungsgrad
Begründung
Netzwerkkonfiguration dient der Definition
des Wirkungsbereiches
Ganzheitlichkeit
erfüllt
Ist über Einfluss der Kontextfaktoren ge-
währleistet
Praktikabilität
erfüllt
Orientierung an einer praktischen Relevanz
ist gegeben; finales Modell basiert auf Ge-
staltungsempfehlungen von Praktizierenden
Methodische Fundierung
erfüllt
Anwendung einer methodischen Vorge-
hensweise bei der Modellentwicklung
Theoretische Fundierung
erfüllt
Modellentwurf wurde basierend auf einer Li-
teraturrecherche in den Bereichen Lieferan-
ten und Netzwerk Performance Manage-
ment entwickelt
Empirische Fundierung
erfüllt
Modell-Überarbeitung fand basierend auf
den Ergebnissen einer empirischen Fallstu-
die statt
Literaturverzeichnis 174
Literaturverzeichnis
Abramowicz, W. (Hrsg., 2017), Business Information Systems, Cham (Schweiz),
2017.
Abts, D./Mülder, W. (Hrsg., 2017), Grundkurs Wirtschaftsinformatik, Wiesbaden,
2017.
Abts, D./Mülder, W. (2017), Software, in: Abts; Mülder (Hrsg., 2017), S. 5587.
Adesanya, A./Yang, B./Bin Iqdara, F.W./Yang, Y. (2020), Improving sustainability
performance through supplier relationship management in the tobacco industry,
in: Supply Chain Management: An International Journal, 25(4), 2020, S. 413426.
Agostino, D./Arnaboldi, M. (2018), Performance measurement systems in public ser-
vice networks. The what, who, and how of control, in: Financial Accountability &
Management, 34(2), 2018, S. 103116.
Albers, S. (Hrsg., 2007), Methodik der empirischen Forschung, 2., überarb. und erw.
Aufl., Wiesbaden, 2007.
Albers, S./Klappner, D./Konradt, U./Walter, A./Wolf, J. (Hrsg., 2009), Methodik der
Empirischen Forschung, 3. Auflage, Wiesbaden, 2009.
Ali, S./Hongqi, L./Khan, S.U./Zhonggui, Y. (2018), Practices in Software Outsourcing
Partnership: Systematic Literature Review Protocol with Analysis, in: Journal of
Computers, 13(7), 2018, S. 839861.
Ali, S./Hongqi, L./Khan, S.U./Zhongguo, Y./Liping, Z. (2017), Success Factors for
Software Outsourcing Partnership Management: An Exploratory Study Using Sys-
tematic Literature Review, in: IEEE Access, 5, 2017, S. 2358923612.
Ali, S./Khan, S.U. (2014), Software Outsourcing Partnership (SOP): A Systematic Li-
terature Review Protocol with Preliminary Results, in: International Journal of Hyb-
rid Information Technology, 7(4), 2014, S. 377392.
AlMaian, R. (2014), A Strategic Approach to Effectively Manage Supplier Quality
within the Construction Industry. Dissertation, University of Arkansas, Fayetteville
2014.
Alnatour, A./Gibson, P. (2011), Managing the multi-agent Supply Network: Agents
Relationships, Risk, and Collaboration, 2011.
175 Literaturverzeichnis
Amaratunga, D./Baldry, D. (2002), Moving from performance measurement to perfor-
mance management, in: Facilities, 205/6, 2002, S. 217223.
Andres, H.P./Zmud, R.W. (2002), A contingency approach to software project coordi-
nation, in: Journal of Management Information Systems, 18(3), 2002, S. 4170.
Assmann, D./Punter, T. (2003), Don't make a mess with software subcontracting! on
Mass: a method for subcontractor selection in software application development,
in: Eighth International Conference on Advances in Production Management Sys-
tems, Eindhoven, 2003, S. 603618.
Assmann, D./Punter, T. (2004), Towards partnership in software subcontracting, in:
Computers in Industry, 54(2), 2004, S. 137150.
Association for Computing Machinery (Hrsg., 2006), ICSE'06: Proceedings of the
28th international conference on software engineering, Shanghai China, 2006.
Association for Computing Machinery (Hrsg., 2007), International Conference of Glo-
bal Software Engineering, Munich, 2007.
Association for Information Systems (Hrsg., 2015), Twenty-first Americas Conference
on Information Systems, Puerto Rico, 2015.
Association for Information Systems (Hrsg., 2016), Thirty Seventh International Con-
ference on Information Systems, Dublin, 2016.
Axel Springer SE (2020), Nächstes Debakel für VW - Lieferstopp bei Golf 8 wegen
Software-Problem, in: WELT, 2020, https://www.welt.de/wirtschaft/ar-
ticle208019893/Volkswagen-Lief, zugegriffen am: 24.03.2021.
Bachrach, D.G./Powell, B.C./Collins, B.J./Richey, R.G. (2006), Effects of task interde-
pendence on the relationship between helping behavior and group performance,
in: The Journal of applied psychology, 91(6), 2006, S. 13961405.
Backhaus, K. (2014), Industriegütermarketing: Grundlagen des business-to-busi-
ness-marketings, 10. Überarbeitete Auflage, Munich, Germany, 2014.
Backhaus, K./Voeth, M. (2010), Industriegütermarketing, 9. Auflage, München, 2010.
Bacon, L./Ma, J./MacKinnon, L.M. (Hrsg., 2017), 2017 15th IEEE/ACIS International
Conference on Software Engineering Research, Management and Applications
(SERA), London, UK, 2017.
Literaturverzeichnis 176
Bapna, R./Barua, A./Mehra, A., Mani, D. (2010), Research commentary - Coopera-
tion, coordination, and governance in multisourcing: An agenda for analytical and
empirical research, in: Information Systems Research, 21(4), 2010, S. 785795.
Bardmann, M. (2019), Grundlagen der Allgemeinen Betriebswirtschaftslehre, Wies-
baden, 2019.
Analysis Division, Fishermans Bend, Australia, 2013.
Baur, N./Blasius, J. (Hrsg., 2014), Handbuch Methoden der Empirischen Sozialfor-
schung, Wiesbaden, 2014.
Bayne, L./Schepis, D./Purchase, S. (2017), A framework for understanding strategic
network performance: Exploring efficiency and effectiveness at the network level,
in: Industrial Marketing Management, 67, 2017, S. 134147.
Bea, F.X./Dichtl, E./Schweitzer, M. (1994), Allgemeine Betriebswirtschaftslehre-Band
3: Leistungsprozeß, 6. Auflage, Stuttgart, 1994.
Bengtsson, M./Raza-Ullah, T./Vanyushyn, V. (2016), The coopetition paradox and
tension: The moderating role of coopetition capability, in: Industrial Marketing Ma-
nagement, 53, 2016, S. 128.
Bernard, M./Buckl, C./Döricht, V./Fehling, M./Fiege, L./Grolman, H. von/Ivandic,
N./Janello, C./Klein, C./Kuhn, K.-J./Patzlaff, C./Riedl, B.C./SChätz, B./Stanek, C.
(2011), Mehr Software (im) Wagen: Informations- und Kommunikationstechnik
(IKT) als Motor der Elektromobilität der Zukunft, in: ForTISS GmbH, München,
2011.
Berret, M./Mogge, F./Bodewig, M./Fellhauer, E./Söndermann, C./Schmidt, M. (2017),
Global Automotive Supplier Study 2018: Transformation in light of automotive dis-
ruption, in: Lazard/Roland Berger, 2017.
Blohm, I. (2013), Konzeptionelle Grundlagen, in: Blohm (Hrsg., 2013), S. 1146.
Blohm, I. (Hrsg., 2013), Open Innovation Communities, Wiesbaden, 2013.
Bogner, A./Littig, B./Menz, W. (2014), Interviews mit Experten: Eine praxisorientierte
Einführung, Wiesbaden, 2014.
177 Literaturverzeichnis
Bonatto, F./Resende, L.M.M./Pontes, J./Andrade Junior, P.P. (2017), A measure-
ment model for managing performance of horizontal business networks and a re-
search case, in: Production, 27(0), 2017, S. 117.
Borchardt, A./Göthlich, S.E. (2007), Definition und Einordnung von Fallstudien als
Forschungsansatz, in: Albers (Hrsg., 2007), S. 3448.
Borchardt, A./Göthlich, S.E. (2009), Erkenntnisgewinnung durch Fallstudien, in: Al-
bers; Klappner; Konradt; Walter; Wolf (Hrsg., 2009), S. 3348.
Bouncken, R.B./Fredrich, V. (2012), Coopetition: Performance implications and ma-
nagement antecedents, in: International Journal of Innovation Management,
16(05), 2012, S. 128.
Bourne, M./Melnyk, S./Bititci, U.S. (2018), Performance measurement and manage-
ment: Theory and practice, in: International Journal of Operations & Production
Management, 38(11), 2018, S. 20102021.
Brass, D.J./Galaskiewicz, J./Greve, H.R./Tsai, W. (2004), Taking Stock of Networks
and Organizations: A Multilevel Perspective, in: The Academy of Management
Journal, 47(6), 2004, S. 795817.
Brell (2020), Literaturrecherche planen und durchführen mit Checkliste,
https://cbrell.de/blog/literaturrecherche-planen-und-durchfuehren-mit-checkliste/,
zugegriffen am: 13.08.2024.
Broy, M. (2006), Challenges in Automotive Software Engineering, in: International
Conference on Software Engineering, Shanghai China, 2006, S. 3342.
Burkacky, O./Deichmann, J./Stein, J.P. (2019), Automotive software and electronics
2030: Mapping the sector's future landscape, in: McKinsey & Company, 2019.
Buttschardt, S. (2017), Evaluation of factors influencing the success of forced coope-
tition in IT multi-sourcing projects. Dissertation, Edinburgh Napier University, Edin-
burgh 2017.
Calvo-Manzano, J.A./San Feliu, T./Pursche, A. (2010), The forgotten practices of
subcontracting, in: 5th Iberian Conference on Information Systems and Technolo-
gies, Santiago de Compostela Chile, 2010, S. 14.
Literaturverzeichnis 178
Chan, F.T.S./Qi, H.J./Chan, H.K./Lau, H.C.W./Ip, R.W.L. (2003), A conceptual model
of performance measurement for supply chains, in: Management Decision, 41(7),
2003, S. 635642.
Chittister, C.G./Haimes, Y.Y. (1996), Systems Integration via Software Risk Manage-
ment, in: IEEE Transactions on Systems, Man and Cybernetics - Part A: Systems
and Humans, 26(5), 1996, S. 521532.
Cohen, L.R./Young, A. (2006), Multisourcing: Moving beyond outsourcing to achieve
growth and agility, Boston, Mass., 2006.
Connor, N.O./Lowry, P.B./Treiblmaier, H. (2020), Interorganizational cooperation and
supplier performance in high-technology supply chains, in: Heliyon, 6(3), 2020, 1-
16.
Corent, A./Deubener, H./Dhawan, R./Möller, T./Padhi, A./Schaufuss, P./Tschiesner,
A. (2019), Race 2050 - A Vision for the European Automotive Industry, in:
McKinsey Center for Future Mobility, 2019.
Crowston, K. (1997), A coordination theory approach to organizational process de-
sign, in: Organization Science, 8(2), 1997, S. 157175.
Cuthbertson, R./Piotrowicz, W. (2011), Performance measurement systems in supply
chains, in: International Journal of Productivity and Performance Management,
60(6), 2011, S. 583602.
Day, A. (2014), Spot the difference, in: Supply Management, 2014, S. 3233.
Deimling, C. von (2019), Komplexitätsmanagement in multinationalen Einkaufsko-
operationen am Beispiel des Verteidigungssektors, Wiesbaden, 2019.
Dorn, S./Schweiger, B./Albers, S. (2016), Levels, phases and themes of coopetition:
A systematic literature review and research agenda, in: European Management
Journal, 34(5), 2016, S. 484500.
Dücker, T. (Hrsg., 2020), Eigentümerstruktur und Unternehmenssteuerung in Wirt-
schaftlichen Krisenzeiten, Wiesbaden, 2020.
Dücker, T. (2020), Experteninterviews als qualitatives Untersuchungsdesign, in:
Dücker (Hrsg., 2020), S. 111165.
179 Literaturverzeichnis
Ebert, C. (2007), Optimizing Supplier Management in Global Software Engineering,
in: International Conference of Global Software Engineering, Munich, 2007, S.
177185.
Ebert, C. (2017), Supplier performance management: Risk mitigation and industry
benchmarks, in: 2017 IEEE 12th International Conference on Global Software En-
gineering (ICGSE), Buenos Aires, Argentina, 2017, S. 8695.
Ebert, C./Murthy, B.K./Jha, N.N. (2008), Managing risks in global software enginee-
ring: Principles and practices, in: 2008 IEEE International Conference on Global
Software Engineering (ICGSE), Bangalore India, 2008, S. 131140.
Eisenhardt, K.M. (1989), Building Theories from Case Study Research, in: The
Academy of Management Review, 14(4), 1989, S. 532550.
Eisenhart, M.A. (1991), Conceptual frameworks for research circa 1991: Ideas from
cultural anthropologist; Implications for mathematics education researchers. Re-
search Paper, University of Colorado, Boulder 1991.
Emmanuel-Ebikake, O./Roy, R./Shehab, E. (2014), Supplier sustainability assess-
ment for the UK defence industry, in: International Journal of Productivity and Per-
formance Management, 63(8), 2014, S. 968990.
European Association of Agricultural Economists (EAAE) (Hrsg., 2010), 116th EAAE
Seminar "Spatial dynamics in agri-food systems: implications for sustainability and
consumer welfare, Parma (Italien), 2010.
Fekete, Z.A./Hancu, L.-V. (2010), A Supplier Selection Model for Software Develop-
ment Outsourcing. Research Paper, University of Oradea, Oradea 2010.
Ferreira, R.P./Silva, J.N./do Rocio Straubs, F./Soares, A.L. (2011), Performance ma-
nagement in collaborative networks: A methodological proposal, in: Journal of
Universal Computer Science, 17(10), 2011, S. 14121429.
Fisher, G./Aguinis, H. (2017), Using Theory Elaboration to Make Theoretical Advan-
cements, in: Organizational Research Methods, 20(3), 2017, S. 127.
Flick, U. (2014), Gütekriterien qualitativer Sozialforschung, in: Baur; Blasius (Hrsg.,
2014), S. 411423.
Flick, U. (2020), Gütekriterien qualitativer Forschung, in: Mey; Mruck (Hrsg., 2020),
S. 247263.
Literaturverzeichnis 180
tegies based on published work, in: Organizational Research Methods, 13(4),
2010, S. 710737.
Goldberg, M./Satzger, G. (2015), Designing Organizational Models for Service In-
tegration in a Multi-sourcing Context, Puerto Rico, 2015, S. 120.
Goldberg, M./Satzger, G. (2016), Towards multi-sourcing maturity: A service integra-
tion capability model, Dublin, 2016, S. 119.
Grant, C./Osanloo, A. (2014), Understanding, Selecting, and Integrating a Theoretical
Administrative Issues Journal Education Practice and Research, 4(2), 2014, S.
1226.
Grimm, K. (2003), Software technology in an automotive company - major challen-
ges, in: 25th International Conference on Software Engineering, Portland Oregon,
2003, S. 498503.
Grochla, E. (1978), Einführung in die Organisationstheorie, Stuttgart, 1978.
Hammerschmidt, C. (2020), Reports: Volkswagen struggles with software problems
at ID.3, in: eeNews Automotive, 2020, https://www.eenewsautomo-
tive.com/news/reports-volkswagen-struggles-software-problems-id3, zugegriffen
am: 21.11.2020.
Hannewald, M./Deimling, C. von/Eßig, M. (2021), Supplier Performance Measure-
ment for Embedded Software Projects in Automotive Industry: Developing a Con-
ceptual Research Framework. Research Article, Universität der Bundeswehr Mün-
chen, München 2021.
Hawkins, T.G. (2016), Antecedents and Consequences of Supplier Performance
Evaluation Efficacy. Research Paper, Western Kentucky University, Bowling
Green KY 2016.
Hedge, R./Mishra, G./Gurumurthy, K.S. (2011), An Insight into the Hardware and
Software Complexity of ECUs in Vehicles, in: International Conference on Advan-
ces in Computing and Information Technology, Chennai, India, 2011, S. 99106.
Heranz, J. (2010), Network performance and coordination, in: Public Performance &
Management Review, 33(3), 2010, S. 311341.
181 Literaturverzeichnis
Herranz, J. (2010), Multilevel performance indicators for multisectoral networks and
management, in: The American Review of Public Administration, 40(4), 2010, S.
445460.
Herzig, A./Wirnsperger, P./Dassow, I. (2017), Automotive Software Quality: Was O-
EMs heute für morgen beachten müssen, in: Deloitte GmbH Wirtschaftsprüfungs-
gesellschaft, Zürich, 2017.
cations for Innovation, in: Management Science, 40(4), 1994, S. 429439.
Ho, W./Xu, X./Dey, P.K. (2010), Multi-criteria decision making approaches for supp-
lier evaluation and selection: A literature review, in: European Journal of Operatio-
nal Research, 202(1), 2010, S. 1624.
Hofmann, E. (2002), "Neue" Managementkonzepte - Entwicklungszüge, Eigenschaf-
ten, Erfolgsausprägungen und Integrationsdimensionen, in: Stölzle; Gareis (Hrsg.,
2002), S. 438.
Hsu, Y. (2018), Exploring task interdependence and cooperative conflicts among en-
gineering designers, in: Journal of Engineering Design, 29(12), 2018, S. 709734.
IEEE (Hrsg., 2013), International Conference on Computer Communication and Infor-
matics (ICCCI), 2013, Coimbatore India, 2013.
IEEE Computer Society (Hrsg., 2011), Proceedings 2011 Ninth International Con-
ference on Frontiers of Information Technology, Islamabad, 2011.
IEEE Computer Society (Hrsg., 2013), The International Conference on Information
Networking 2013 (ICOIN 2013): Bangkok, Thailand, 28 - 30 January 2013, Bang-
kok, 2013.
IEEE Press (Hrsg., 2003), 25th International Conference on Software Engineering,
Portland Oregon, 2003.
IEEE Press (Hrsg., 2008), 2008 IEEE International Conference on Global Software
Engineering (ICGSE), Bangalore India, 2008.
IEEE Press (Hrsg., 2009), 2nd International Conference on Emerging Trends in Engi-
neering and Technology (ICETET), 2009, Nagpur, India, 2009.
IEEE Press (Hrsg., 2010), 2010 International Conference on Logistics Systems and
Intelligent Management (ICLSIM), Harbin, China, 2010.
Literaturverzeichnis 182
IEEE Press (Hrsg., 2010), 5th Iberian Conference on Information Systems and Tech-
nologies, Santiago de Compostela Chile, 2010.
IEEE Press (Hrsg., 2012), 2012 15th International Multitopic Conference (INMIC), Is-
lamabad, Pakistan, 2012.
IEEE Press (Hrsg., 2015), 2015 IEEE/ACIS 16th International Conference on Soft-
ware Engineering, Artificial Intelligence, Networking and Parallel/Distributed Com-
puting (SNPD), Takamatsu, 2015.
IEEE Press (Hrsg., 2017), 2017 12th International Conference on Global Software
Engineering (ICGSE), Buenos Aires, Argentina, 2017.
Ilyas, M./Khan, S.U. (2012), Software Integration Challenges in Global Software De-
velopment Environment: A Systematic Literature Review Protocol, in: Journal of
Computer Engineering, 1(6), 2012, S. 2938.
Ilyas, M./Khan, S.U. (2012b), Software Integration Model for Global Software Develo-
pment, Islamabad, Pakistan, 2012, S. 452457.
Ilyas, M./Khan, S.U. (2015), Software integration in global software development:
Success factors for GSD vendors, in: 2015 IEEE/ACIS 16th International Con-
ference on Software Engineering, Artificial Intelligence, Networking and Paral-
lel/Distributed Computing (SNPD), Takamatsu, 2015, S. 16.
Ilyas, M./Khan, S.U. (2016), An Exploratory Study of Success Factors in Software In-
tegration for Global Software Development Vendors, in: Proceedings of the Pakis-
tan Academy of Sciences: A. Physical and Comutational Sciences, 53(3), 2016,
S. 239253.
Ilyas, M./Khan, S.U. (2017), An empirical investigation of the software integration
success factors in GSD environment, London, UK, 2017, S. 255262.
Imenda, S. (2014), Is there a conceptual difference between theoretical and concep-
tual frameworks?, in: Journal of Social Sciences, 38(2), 2014, S. 185195.
Imeri, S. (2013), Key performance criteria for vendor selection: A literature review, in:
Management Research & Practice, 5(2), 2013, S. 6375.
Institut für Wirtschaftsinformatik Leuphana Universität Lüneburg (Hrsg., 2018), Multi-
konferenz Wirtschaftsinformatik, Lüneburg, 2018.
183 Literaturverzeichnis
Jabareen, Y. (2009), Building a Conceptual Framework: Philosophy, Definitions, and
Procedure, in: International Journal of Qualitative Methods, 8(4), 2009, S. 4962.
Jagdev, H.S./Wortmann, J.C./Pels, H.J. (Hrsg., 2003), Collaborative Systems for Pro-
duction Management, Eindhoven, 2003.
Jenkins, N. (2020), VW wants to solve the software problems quickly ID.3 comes in
late summer, in: WheelsJoint.com, 2020, https://www.wheelsjoint.com/vw-wants-
to-solve-the-software-problems-quickly-id-3-comes-in-late-summer/, zugegriffen
am: 21.11.2020.
Jiang, H./Bai, L. (2010), Supplier performance management based on benchmarking
methodology, in: 2010 International Conference on Logistics Systems and Intelli-
gent Management (ICLSIM), Harbin, China, 2010, S. 14091412.
José Alfaro Saiz, J./Ortiz Bas, A./Rodríguez Rodríguez, R. (2007), Performance mea-
surement system for enterprise networks, in: International Journal of Productivity
and Performance Management, 56(4), 2007, S. 305334.
Kache, F./Seuring, S. (2014), Linking collaboration and integration to risk and perfor-
mance in supply chains via a review of literature reviews, in: Supply Chain Ma-
nagement: An International Journal, 195/6, 2014, S. 664682.
Kaplan, R.S./Norton, D.P. (1996), The Balanced Scorecard: Translating Strategy into
Action, Boston, Mass., 1996.
Kaplan, R.S./Norton, D.P. (1996), Using the Balanced Scorecard as a Strategic Ma-
nagement System, in: Harvard Business Review, 1996, S. 7585.
Katz-Navon, T.Y./Erez, M. (2005), When Collective- and Self-Efficacy Affect Team
Performance, in: Small Group Research, 36(4), 2005, S. 437465.
Kenis, P./Provan, K.G. (2009), Towards an exogenous theory of public network per-
formance, in: Public Administration, 87(3), 2009, S. 440456.
Keshavarz Ghorabaee, M./Amiri, M./Zavadskas, E.K./Antucheviciene, J. (2017),
Supplier evaluation and selection in fuzzy environments: A review of MADM ap-
proaches, in: Economic Research-
1118.
Kharb, L./Singh, R. (2008), Complexity Metrics for Component-Oriented Software
Systems, in: ACM SIGSOFT Software Engineering Notes, 33(2), 2008, S. 13.
Literaturverzeichnis 184
Kleindienst, B. (2017), Performance Measurement und Management: Gestaltung und
Einführung von Kennzahlen- und Steuerungssystemen, Wiesbaden, 2017.
Klijn, E.H./Koppenjan, J.F.M. (2014), Complexity in governance network theory, in:
Complexity, Governance & Networks, 1(1), 2014, S. 6170.
Könning, M./Westner, M./Strahringer, S. (2018), Multisourcing on the Rise: Results
from an Analysis of more than 1,000 IT Outsourcing Deals in the ASG Region, Lü-
neburg, 2018, S. 18131824.
Koppenjan, J. (2008), Creating a playing field for assessing the effectiveness of net-
work collaboration by performance measures, in: Public Management Review,
10(6), 2008, S. 699714.
Kotlarsky, J./Oshri, I./Willcocks, L.P. (Hrsg., 2014), Governing Sourcing Relations-
hips. A Collection of Studies at the Country, Sector and Firm Level: 8th Global
Sourcing workshop, Val d'Isere, F., 23-26 March, 2014, Revised selected papers,
1st ed. 2014, Cham (Schweiz), 2014.
Kuckartz, U. (2016), Qualitative Inhaltsanalyse: Methoden, Praxis, Computerunter-
stützung, 3., überarbeitete Auflage, Weinheim, Basel, 2016.
Kuckartz, U./Rädiker, S. (2014), Datenaufbereitung und Datenbereinigung in der
qualitativen Sozialforschung, in: Baur; Blasius (Hrsg., 2014), S. 383396.
Kumar, K./van Fenema, P.C./Glinow, M.A. von (2009), Offshoring and the global dis-
tribution of work: Implications for task interdependence theory and practice, in:
Journal of International Business Studies, 40(4), 2009, S. 642667.
Kumar, S.A./Thangavelu, A.K. (2013), Factors affecting the outcome of global soft-
ware development projects: An Empirical study, in: International Conference on
Computer Communication and Informatics (ICCCI), Coimbatore India, 2013, S. 1
10.
Kuthyola, K.F./Liu, J.Y.-C./Klein, G. (2017), Influence of Task Interdependence on
Teamwork Quality and Project Performance, in: Abramowicz (Hrsg., 2017), S.
135148.
Langfred, C.W. (2005), Autonomy and Performance in Teams: The Multilevel Mode-
rating Effect of Task Interdependence, in: Journal of Management, 31(4), 2005, S.
513529.
185 Literaturverzeichnis
Larsson, S. (2007), Key Elements of the Product Integration Process. Ph.D. Thesis
Proposal, Mälardalen University 2007.
Larsson, S./Myllyperkiö, P./Ekdahl, F./Crnkovic, I. (2009), Software product integra-
tion: A case study-based synthesis of reference models, in: Information and Soft-
ware Technology, 51(6), 2009, S. 10661080.
Lee, C./Lin, Y./Huang, H.-C./Huang, W./Teng, H. (2015), The Effects of Task Interde-
pendence, Team Cooperation, and Team Conflict on Job Performance, in: Social
Behavior and Personality: an international journal, 43(4), 2015, S. 529536.
Lefebre, V.M./Molnár, A./Gellynck, X. (2010), Network performance - What influences
it?, Parma (Italien), 2010, S. 119.
Lester, F.K. (2005), On the theoretical, conceptual, and philosophical foundations for
research in mathematics education, in: ZDM, 37(6), 2005, S. 457467.
Levina, N./Su, N. (2008), Global multisourcing strategy: The emergence of a supplier
portfolio in services offshoring, in: Decision Sciences, 39(3), 2008, S. 541570.
Lin, T. (2015), Multi-sourcing governance: In perception and in practice, in: Oshri;
Kotlarsky; Willcocks (Hrsg., 2015), S. 187205.
Lin, T. (2016), Deviations of governance in IT multi-sourcing: A case study. Disserta-
tion, University of Turku, Turku 2016.
Llopis-Albert, C./Rubio, F./Valero, F. (2021), Impact of digital transformation on the
automotive industry, in: Technological forecasting and social change, 162, 2021,
S. 19.
Lukhoba, E.J./Muturi, W. (2015), Effect of Supplier Development on Supplier Perfor-
mance: A survey of food manufacturing companies in Kisumu County, in: Interna-
tional Journal of Economics, Commerce and Management, 3(4), 2015.
Maestrini, V./Luzzini, D./Caniato, F./Maccarrone, P./Ronchi, S. (2018), The impact of
supplier performance measurement systems on supplier performance, in: Interna-
tional Journal of Operations & Production Management, 38(11), 2018, S. 2040
2061.
Maestrini, V./Luzzini, D./Caniato, F./Ronchi, S. (2018), Effects of monitoring and in-
centives on supplier performance: An agency theory perspective, in: International
Journal of Production Economics, 203, 2018, S. 322332.
Literaturverzeichnis 186
Maestrini, V./Maccarrone, P./Caniato, F./Luzzini, D. (2018), Supplier performance
measurement systems: Communication and reaction modes, in: Industrial Marke-
ting Management, 74, 2018, S. 298308.
Mahapatra, S.K./Narasimhan, R./Barbieri, P. (2010), Strategic interdependence,
governance effectiveness and supplier performance: A dyadic case study investi-
gation and theory development, in: Journal of Operations Management, 28(6),
2010, S. 537552.
Malone, T.W./Crowston, K. (1990), What Is Coordination Theory and How Can It
Help Design Cooperative Work Systems, Los Angeles, 1990, S. 357370.
Mandell, M./Keast, R. (2007), Evaluating network arrangements: Toward revised per-
formance measures, in: Public Performance & Management Review, 30(4), 2007,
S. 574597.
Mariani, M.M. (2007), Coopetition as an emergent strategy: Empirical evidence from
an italian consortium of opera houses, in: International Studies of Management &
Organisations, 37(2), 2007, S. 97126.
Marsicano, G./Oliveira, V.L. de/S. Mariz, L.M.R. de/Da Silva, F.Q.B. (2018), An initial
understanding of task interdependence in software engineering, in: ICSE '18: 40th
International Conference on Software Engineering, Gothenburg Sweden, 2018, S.
2128.
Marwedel, P. (2021), Embedded system design: Embedded systems foundations of
cyber-physical systems, and the internet of things, 2021.
Mayring, P. (2020), Qualitative Inhaltsanalyse, in: Mey; Mruck (Hrsg., 2020), S. 495
511.
Mayring, P./Fenzl, T. (2014), Qualitative Inhaltsanalyse, in: Baur; Blasius (Hrsg.,
2014), S. 543556.
Merkur tz Redaktions GmbH & Co. KG (2020), Softwarefehler bei weit über 100.000
Teslas großer Rückruf droht, in: tz.de, 2020, https://www.tz.de/auto/software-
fehler-ueber-100-000-teslas-rueckruf-auto-model-x-s-fehler-software-elektroauto-
90110496.html, zugegriffen am: 24.03.2021.
Mey, G./Mruck, K. (Hrsg., 2020), Handbuch Qualitative Forschung in der Psycholo-
gie: Band 2: Designs und Verfahren, 2. Auflage, Wiesbaden, 2020.
187 Literaturverzeichnis
Meyermann, A./Porzelt, M. (2014), Hinweise zur Anonymisierung von qualitativen
Daten, in: forschungsdaten bildung informiert(1), 2014, S. 117.
Militaru, G. (2009), Technological differentiation and performance measurement on
supplier integration in new product development, in: UPB Scientific Bulletin, Se-
ries D, 71(3), 2009, S. 131148.
Modi, S.B./Mabert, V.A. (2007), Supplier development: Improving supplier perfor-
mance through knowledge transfer, in: Journal of Operations Management, 25(1),
2007, S. 4264.
Narasimhan, V./T. Parthasarathy, P./Das, M. (2009), Evaluation of a Suite of Metrics
for Component Based Software Engineering (CBSE), in: Issues in Informing Sci-
ence and Information Technology, 6, 2009, S. 731740.
Narasimhan, V.L./Hendradjaya, B. (2007), A New Suite of Metrics for the Integration
of Software Components, in: Information Sciences, 177(3), 2007, S. 844864.
Natour, A./Kiridena, S./Gibson, P. (2011), Supply Chain Integration and Collaboration
for Performance Improvement: An Agency Theory Approach. Research Paper,
University of Wollongong, Wollongong 2011.
Nemeh, A. (2014), Coopetition Strategy and Technological Innovation: The Case of
European Wireless Telecommunications Industry. Dissertation, Université Mont-
pellier, Montpellier 2014.
Neus, W. (2018), Einführung in die Betriebswirtschaftslehre aus institutionenökono-
mischer Sicht, 10. Auflage, Tübingen, 2018.
Newswood Limited (Hrsg., 2009), Proceedings of the International MultiConference
of Engineers and Computer Scientists 2009 Vol II, Hong Kong China, 2009.
Noshad, K./Awasthi, A. (2015), Supplier quality development: A review of literature
and industry practices, in: International Journal of Production Research, 53(2),
2015, S. 466487.
and selection: Empirical evidence from public institutions in a developing country,
in: Asian Journal of Economics, Business & Accounting, 4(2), 2017, S. 113.
Literaturverzeichnis 188
Ojala, A./Paavilainen-Mäntymäki, E./Su, N./Lyytinen, K. (2017), Software complexity
and organization of firm's offshoring activities, in: 8th Scandinavian Conference on
Onformation Systems, SCIS 2017, Halden, 2017, S. 1527.
Oshri, I./Dibbern, J./Kotlarsky, J./Krancher, O. (2019), An Information Processing
View on Joint Vendor Performance in Multi-Sourcing: The Role of the Guardian,
in: Journal of Management Information Systems, 36(4), 2019, S. 12481283.
Oshri, I./Kotlarsky, J./Willcocks, L.P. (Hrsg., 2015), Achieving Success and Innova-
tion in Global Sourcing: Perspectives and Practices, Cham (Schweiz), 2015.
Oza, N. (2006), An empirical evaluation of client-vendor relationships in Indian soft-
ware outsourcing companies. Dissertation, University of Hertfordshire, Hertfords-
hire 2006.
Parkash, S./Kaushik, V.K. (2011), Simple, cost effective & result oriented framework
for supplier performance measurement in sports goods manufacturing industry, in:
LogForum, 7(3), 2011, S. 1124.
Parkash, S./Kaushik, V.K. (2011), Supplier Performance Monitoring and Improve-
ment (SPMI) through SIPOC analysis and PDCA model to the ISO 9001 QMS in
Sports Goods Manufacturing Industry, in: LogForum, 7(4), 2011, S. 115.
Parung, J./Bititci, U.S. (2008), A metric for collaborative networks, in: Business Pro-
cess Management Journal, 14(5), 2008, S. 654674.
Pathak, S.D./Wu, Z./Johnston, D. (2014), Toward a structural view of co-opetition in
supply networks, in: Journal of Operations Management, 32(5), 2014, S. 254267.
Patil, A./Gogte, J. (2016), Study of supplier performance scorecard systems of car
manufacturing companies in India: A literature review, in: International Journal of
Management, 7(7), 2016, S. 191203.
Patil, A.N. (2014), Modern Evolution in Supplier Selection Criteria and Methods, in:
International Journal of Management Research & Review, 4(5), 2014, S. 616
623.
Patton, E./Appelbaum, S.H. (2003), The Case for Case Studies in Management Re-
search, in: Management Research News, 26(5), 2003, S. 6071.
189 Literaturverzeichnis
and Sector Characteristics of Enterprises, in: Quality Innovation Prosperity, 24(1),
2020, S. 88.
Pekkola, S./Ukko, J. (2016), Designing a performance measurement system for colla-
borative network, in: International Journal of Operations & Production Manage-
ment, 36(11), 2016, S. 14101434.
Pérez Mesa, J.C./Galdeano-Gómez, E. (2015), Collaborative firms managing peris-
hable products in a complex supply network: an empirical analysis of perfor-
mance, in: Supply Chain Management: An International Journal, 20(2), 2015, S.
128138.
Plugge, A. (2018), Challenges in IT multisourcing arrangements: Creating value by
means of an eco-system approach, in: Compact, 2018(1), 2018, S. 110.
Plugge, A./Janssen, M. (2014), Governance of multivendor outsourcing arrange-
ments: A coordination and resource dependency view, in: Kotlarsky; Oshri; Will-
cocks (Hrsg., 2014), S. 7897.
Prahinski, C./Benton, W. (2004), Supplier evaluations: Communication strategies to
improve supplier performance, in: Journal of Operations Management, 22(1),
2004, S. 3962.
(1990), Proceedings of the 1990 ACM conference on Computer-supported coopera-
tive work, Los Angeles, 1990.
Pyo, S. (2010), Measuring tourism chain performance, in: The Service Industries
Journal, 30(10), 2010, S. 16691682.
Qian Li, Z./Chen Tan, H./Anumba, C./Choy Chia, F. (2017), Development of a web-
construction project, in: Built Environment Project and Asset Management, 7(2),
2017, S. 117129.
Rajamaki, J./Vuorinen, M. (2013), Multi-supplier integration management for public
protection and disaster relief (PPDR) organizations, in: 2013 International Con-
ference on Information Networking (ICOIN), Bangkok, 2013, S. 499504.
Ramaa, A./Rangaswamy, T.M./Subramanya, K.N. (2009), A review of literature on
performance measurement of supply chain network, in: 2009 Second International
Literaturverzeichnis 190
Conference on Emerging Trends in Engineering & Technology, Nagpur, India,
2009, S. 802807.
Richardson, J./Roumasset, J. (1995), Sole Sourcing, Competitive Sourcing, Parallel
Sourcing: Mechanisms for Supplier Performance, in: Managerial and Decision
Economics, 16(1), 1995, S. 7184.
Ritchie, B./Brindley, C. (2007), Supply chain risk management and performance, in:
International Journal of Operations & Production Management, 27(3), 2007, S.
303322.
Ritchie, B./Brindley, C.S./Armstrong, N. (2008), Risk assessment and relationship
management: practical approach to supply chain risk management, in: Internatio-
nal Journal of Agile Systems and Management, 33/4, 2008, S. 228.
Ritter, T./Wilkinson, I.F./Johnston, W.J. (2004), Managing in complex business net-
works, in: Industrial Marketing Management, 33(3), 2004, S. 175183.
Routroy, S./Kumar Pradhan, S. (2014), Benchmarking model of supplier develop-
ment for an Indian gear manufacturing company, in: Benchmarking: An Internatio-
nal Journal, 21(2), 2014, S. 253275.
Rowley, J. (2002), Using Case Studies in Research, in: Management Research
News, 25(1), 2002, S. 1627.
Salvetat, D./Géraudel, M. (2012), The tertius roles in a coopetitive context: The case
of the European aeronautical and aerospace engineering sector, in: European
Management Journal, 30(6), 2012, S. 603614.
Sanei, M./Mamizadeh, C.S./Samaei, M. (2011), Performance evaluation of multi-
supplier supply chains, in: Journal of Industrial Strategic Management, 8(23),
2011, S. 1016.
Saunders, M./Lewis, P./Thornhill, A. (2009), Research methods for business stu-
dents, 5. ed., Harlow, 2009.
Sena Ferreira, P./Shamsuzzoha, A.H.M./Toscano, C./Cunha, P. (2012), Framework
for performance measurement and management in a collaborative business en-
vironment, in: International Journal of Productivity and Performance Management,
61(6), 2012, S. 672690.
191 Literaturverzeichnis
Seuring, S.A. (2008), Assessing the rigor of case study research in supply chain ma-
nagement, in: Supply Chain Management: An International Journal, 13(2), 2008,
S. 128137.
Shapira, Z. (2011), "I've Got a Theory Paper-Do You?": Conceptual, Empirical, and
Theoretical Contributions to Knowledge in the Organizational Sciences, in: Orga-
nization Science, 22(5), 2011, S. 13121321.
Sharp, H./Souza, C.R.B. de/Graziotin, D./Levy, M./Socha, D. (Hrsg., 2018), Procee-
dings of the 11th International Workshop on Cooperative and Human Aspects of
Software Engineering, Gothenburg Sweden, 2018.
Shaw, S./Grant, D.B./Mangan, J. (2010), Developing environmental supply chain per-
formance measures, in: Benchmarking: An International Journal, 17(3), 2010, S.
320339.
Shokri, A./Nabhani, F./Hodgson, S. (2010), Supplier development practice: Arising
the problems of upstream delivery for a food distribution SME in the UK, in: Robo-
tics and Computer-Integrated Manufacturing, 26(6), 2010, S. 639646.
Simpson, P.M./Siguaw, J.A./White, S.C. (2002), Measuring the Performance of Supp-
liers: An Analysis of Evaluation Processes, in: Journal of Supply Chain Manage-
ment, 38(1), 2002, S. 2941.
Smith, P.C./Goddard, M. (2002), Performance mangement and Operational Rese-
arch: a marriage made in heaven?, in: Journal of the Operational Research
Society, 53, 2002, S. 247255.
Soni, G./Kodali, R. (2013), A critical review of supply chain management frameworks:
proposed framework, in: Benchmarking: An International Journal, 20(2), 2013, S.
263298.
Springer (Hrsg., 2011), International Conference on Advances in Computing and In-
formation Technology, Chennai, India, 2011.
Staron, M. (Hrsg., 2017), Automotive Software Architectures, Cham (Schweiz), 2017.
Staron, M. (2017), Introduction, in: Staron (Hrsg., 2017), S. 117.
Stigberg, S./Karlsen, J./Holone, H./Linnes, C. (Hrsg., 2017), Nordic Contributions in
IS Research, Halden, 2017.
Literaturverzeichnis 192
Stölzle, W./Gareis, K. (Hrsg., 2002), Integrative Management- und Logistikkonzepte,
Wiesbaden, 2002.
Straub, D./Rai, A./Klein, R. (2004), Measuring firm performance at the network level:
A nomology of the business impact of digital supply networks, in: Journal of Ma-
nagement Information Systems, 21(1), 2004, S. 83114.
Sundtoft Hald, K./Ellegaard, C. (2011), Supplier evaluation processes: The shaping
and reshaping of supplier performance, in: International Journal of Operations &
Production Management, 31(8), 2011, S. 888910.
Tangen, S. (2004), Evaluation and Revision of Performance Measurement Systems.
Dissertation, KTH Royal Institute of Technology, Stockholm, Schweden 2004.
Thanaraksakul, W./Phruksaphanrat, B. (2009), Supplier Evaluation Framework Ba-
sed on Balanced Scorecard with Integrated Corporate Social Responsibility Per-
spective, in: International MultiConference of Engineers and Computer Scientists,
Hong Kong China, 2009, S. 11062210.
Tidström, A. (2014), Managing tensions in coopetition, in: Industrial Marketing Ma-
nagement, 43(2), 2014, S. 261271.
Tidström, A./Rajala, A. (2016), Coopetition strategy as interrelated praxis and prac-
tices on multiple levels, in: Industrial Marketing Management, 58, 2016, S. 3544.
Tranfield, D./Denyer, D./Smart, P. (2003), Towards a methodology for developing evi-
dence-informed management knowledge by means of systematic review, in: Bri-
tish Journal of Management, 14(3), 2003, S. 207222.
Tungjitjarurn, W./Suthiwartnarueput, K./Pornchaiwiseskul, P. (2012), The impact of
supplier development on supplier performance: The Role of Buyer-Supplier Com-
mitment, Thailand, in: European Journal of Business and Management, 2012, S.
22222839.
van de Ven, H./Delbecq, A.L./König, R. (1976), Determinants of Coordination Modes
within Organizations, in: American Sociological Review, 41(2), 1976, S. 322338.
van Moll, J.H./Ammerlaan, R.W.M. (2008), Identifying Pitfalls of System Integration -
An Exploratory Study, in: 2008 IEEE International Conference on Software Tes-
ting Verification and Validation Workshop, 2008, S. 331338.
193 Literaturverzeichnis
van Weele, A.J./Eßig, M. (2017), Strategische Beschaffung: Grundlagen, Planung
und Umsetzung eines integrierten Supply Management, Wiesbaden, 2017.
Verdecho, M.-J./Rodríguez-Rodríguez, R./Alfaro-Saiz, J.-J. (2011), A Structured Me-
thodology to Implement Performance Measurement Systems in Collaborative Net-
works, 2011.
Vesalainen, J./Valkokari, K./Hellström, M. (2017), Practices for network management:
In Search of Collaborative Advantage, Cham (Schweiz), 2017.
Victor, B./Blackburn, R.S. (1987), Interdependence: An Alternative Conceptualiza-
tion, in: The Academy of Management Journal, 12(3), 1987, S. 486498.
Wacker, J.G. (1998), A definition of theory: research guidelines for different theory-
building methods in operations management, in: Journal of Operations Manage-
ment, 16, 1998, S. 361385.
Wacker, J.G. (2004), A theory of formal conceptual definitions: developing theory-
building measurement instruments, in: Journal of Operations Management, 22(6),
2004, S. 629650.
Wageman, R./Baker, G. (1997), Incentives and cooperation: the joint effects of task
and reward interdependence on group performance, in: Journal of organizational
behavior, 18, 1997, S. 139158.
Wannenwetsch, H. (2021), Integrierte Materialwirtschaft, Logistik, Beschaffung und
Produktion: Supply Chain im Zeitalter der Digitalisierung, 6. Auflage, Berlin, Hei-
delberg, 2021.
Weber, W./Kabst, R./Baum, M. (2018), Einführung in die Betriebswirtschaftslehre,
Wiesbaden, 2018.
WELT (2020), Krisenjet: Boeing findet schon wieder neues Software-Problem bei
737 Max, in: WELT, 2020, https://www.welt.de/wirtschaft/article205680063/Krisen-
jet-Boeing-findet-schon-wieder-neues-Software-Problem-bei-737-Max.html, zuge-
griffen am: 07.07.2024.
Wiener, M./Saunders, C. (2014), Forced coopetition in IT multi-sourcing, in: The Jour-
nal of Strategic Information Systems, 23(3), 2014, S. 210225.
Wiengarten, F./Pagell, M./Fynes, B. (2013), The importance of contextual factors in
the success of outsourcing contracts in the supply chain environment: the role of
Literaturverzeichnis 194
risk and complementary practices, in: Supply Chain Management: An Internatio-
nal Journal, 18(6), 2013, S. 630643.
Wilhelm, M.M. (2011), Managing coopetition through horizontal supply chain relati-
ons: Linking dyadic and network levels of analysis, in: Journal of Operations Ma-
nagement, 297-8, 2011, S. 663676.
Wilke, H. (2000), Systemtheorie I: Grundlagen, 6. Auflage, Stuttgart, 2000.
Wolf, F. (Hrsg., 2018), Fahrzeuginformatik, Wiesbaden, 2018.
Wolf, F. (2018), Software im Fahrzeug, in: Wolf (Hrsg., 2018), S. 4177.
Wolf, J. (2020), Organisation, Management, Unternehmensführung: Theorien, Pra-
xisbeispiele und Kritik, 6., überarbeitete und erweiterte Auflage, Wiesbaden, Hei-
delberg, 2020.
Wu, Z./Choi, T.Y. (2005), Supplier-supplier relationships in the buyer-supplier triad:
Building theories from eight case studies, in: Journal of Operations Management,
24(1), 2005, S. 2752.
Wu, Z./Choi, T.Y./Rungtusanatham, M.J. (2010), Supplier-supplier relationships in
buyer-supplier-supplier triads: Implications for supplier performance, in: Journal of
Operations Management, 28(2), 2010, S. 115123.
Zafar, A./Ali, S./Shahzad, R.K. (2011), Investigating integration challenges and soluti-
ons in global software development, in: 2011 Frontiers of Information Technology
(FIT 2011), Islamabad, 2011, S. 291297.
Zou, W./Brax, S.A./Vuori, M./Rajala, R. (2019), The influences of contract structure,
contracting process, and service complexity on supplier performance, in: Internati-
onal Journal of Operations & Production Management, 39(4), 2019, S. 525549.
