User manual | - Universität zu Köln

Organisatorische Gestaltung der Softwareentwicklung
unter Berücksichtigung von Offshore-spezifischen
Besonderheiten und Risiken.
Eine Fallstudie
Dissertation zur Erlangung des Doktorgrades
der Wirtschafts- und Sozialwissenschaftlichen Fakultät
an der Universität zu Köln
Januar 2007
Vorgelegt von
Diplom-Wirtschaftsinformatiker
Frank Trefflich
Für meine Frau Astrid Trefflich.
Vorwort des Autors
Referent: Prof. Dr. W. Mellis
Korreferent: Prof. Dr. D. Seibt
Promotionsdatum: 13. Juli 2007
Aus rechtlichen Gründen ist darauf hingewiesen, dass die in dieser Arbeit verwendeten
Namen von Firmen, Organisationen und Produkten möglicherweise die Warenzeichen
der jeweiligen Besitzer sind.
III
Vorwort des Autors
Vorwort des Autors
Seit Jahrzehnten vergeben Unternehmen Aufträge an andere Unternehmen, um individuelle Softwareprodukte entwickeln zu lassen. In Zeiten wachsender Globalisierung
werden dabei auch immer häufiger Unternehmen aus fernen Ländern wie zum Beispiel
Indien beauftragt. Für diese Art der Entwicklung hat sich der Begriff OffshoreEntwicklung etabliert.1
Doch welche Besonderheiten und Risiken sind mit einer solchen Offshore-Entwicklung
verbunden? Wie kann eine solche Offshore-Entwicklung organisatorisch gestaltet werden, damit sowohl der Auftraggeber als auch der Auftragnehmer ihre individuellen
Ziele erreichen?
Diesen Fragen wird in der vorliegenden Dissertation an der Wirtschafts- und Sozialwissenschaftlichen Fakultät der Universität zu Köln nachgegangen. Ich möchte an dieser
Stelle herzlich meinem Doktorvater Prof. Dr. W. Mellis danken, der mich bei meinem
Vorhaben stets unterstützt hat und mir gleichzeitig genügend Freiraum gelassen hat, um
meine Ideen verwirklichen zu können.
Nachdem in der vorliegenden Arbeit ein theoretischer Betrachtungsrahmen aufgestellt
wurde und durch ein Literatur-Review Besonderheiten, Risiken und Ziele von OffshoreEntwicklungen identifiziert wurden, erfolgt eine fallstudienbasierte Untersuchung einzelner Offshore-Projekte. Hierbei soll verstanden werden, welche Besonderheiten und
Risiken in diesem Fall eingetreten sind und mit welchen organisatorischen Maßnahmen
auf diese reagiert wurde.
Zwar habe ich insgesamt zehn Monate in Indien verbracht und dabei in zwei indischen
Softwareunternehmen Erfahrungen gesammelt, doch bei einer Fallstudienuntersuchung
konkreter Projekte ist die aktive Unterstützung von Unternehmen unerlässlich. Daher
möchte ich mich ganz besonders für den Beitrag durch das Anbieterunternehmen Infosys bei Debjit Datta Chaudhuri, Raju Bannur und Rajat Sen bedanken, dass sie bereit
waren mir erforderliche Informationen zur Verfügung zu stellen und die dafür notwendige Zeit aufgebracht haben. Dieser Dank gilt im gleichen Maße auch Herrn Dr. Graham Pedley und seinen Kollegen auf der Seite des auftraggebenden Unternehmens der
Zürcher Kantonalbank (ZKB).
1
Zu Beginn dieser Arbeit erfolgt im Kapitel 1.1 eine präzisere Begriffsdefinition.
IV
Schließlich gilt mein Dank auch meiner Familie und Freunden, die mich durch alle
Höhen und Tiefen meiner Promotion begleitet haben. Hervorzuheben sind meine Eltern,
die mich während des Studiums und der anschließenden Promotion unterstützt haben
und stets hinter meinen Entscheidungen stehen. Bei meiner Schwester Iris bedanke ich
mich für die Durchsicht der Arbeit. Ich danke meinem Freund Kai Oey, der stets ein
offenes Ohr für mich hat und meinem Freund Peer Osthoff, der mir mit Spieleabenden
und Abenden am Kickertisch einen Ausgleich bietet.
Meiner Frau Astrid danke ich von ganzem Herzen für ihr unendliches Verständnis
dafür, dass mir die Arbeit auch dann durch den Kopf ging, wenn ich nicht mehr am
Schreibtisch saß.
Köln, Januar 2007
Frank Trefflich
V
Inhaltsübersicht
Inhaltsübersicht
1. Einführung ....................................................................................................................1
1.1 Begriffsklärung – Outsourcing, Offshoring .............................................................1
1.2 Kurzer Überblick der historischen Entwicklung der OffshoreEntwicklung .............................................................................................................3
1.3 Motivation für die Thematik Offshore-Entwicklung ...............................................5
1.4 Problemstellung und Zielsetzung der Arbeit............................................................7
1.5 Gewähltes Vorgehen zur Beantwortung der Forschungsfragen.............................11
2. Darstellung der Offshore-Entwicklung.......................................................................23
2.1 Fokussierung auf relevante Elemente des Betrachtungsrahmens ..........................23
2.2 Darstellung des Elements Umwelt .........................................................................24
2.3 Darstellung des Elements Strategie........................................................................37
2.4 Darstellung des Elements Geschäftsprozess ..........................................................44
2.5 Darstellung des Elements Produkt und Service .....................................................61
2.6 Darstellung des Elements Anbieter- und Kundenunternehmen .............................63
2.7 Darstellung des Elements Ziele und Erwartungen .................................................66
2.8 Darstellung des Elements Risiken..........................................................................90
2.9 Darstellung des Elements negative Ergebnisse....................................................113
3. Fallstudien-Untersuchung .........................................................................................115
3.1 Design der Untersuchung.....................................................................................115
3.2 Methode der sozialen Netzwerkanalyse...............................................................118
3.3 Untersuchung der einzelnen Elemente des „work system“..................................125
4. Abschließende Betrachtung ......................................................................................188
4.1 Überprüfung der Zielerreichung ..........................................................................188
4.2 Beurteilung der angewendeten Forschungsmethode............................................198
4.3 Ausblick ...............................................................................................................202
Literaturverzeichnis .......................................................................................................203
Anhang...........................................................................................................................242
VI
Inhaltsverzeichnis
Inhaltsverzeichnis
Vorwort des Autors ........................................................................................................ IV
Inhaltsübersicht............................................................................................................... VI
Inhaltsverzeichnis .......................................................................................................... VII
Inhaltsverzeichnis .......................................................................................................... VII
Abkürzungsverzeichnis ................................................................................................. XII
Abbildungsverzeichnis ................................................................................................ XIV
Tabellenverzeichnis .................................................................................................... XVII
1. Einführung ....................................................................................................................1
1.1 Begriffsklärung – Outsourcing, Offshoring .............................................................1
1.2 Kurzer Überblick der historischen Entwicklung der OffshoreEntwicklung .............................................................................................................3
1.3 Motivation für die Thematik Offshore-Entwicklung ...............................................5
1.4 Problemstellung und Zielsetzung der Arbeit............................................................7
1.4.1 Zusammenhang
zwischen
Praxisproblem
und
Forschungsproblem.........................................................................................7
1.4.2 Praxisproblem .................................................................................................8
1.4.3 Forschungsfragen und Forschungsproblem....................................................8
1.5 Gewähltes Vorgehen zur Beantwortung der Forschungsfragen.............................11
1.5.1 Überblick über das Vorgehen .......................................................................11
1.5.2 Wissenschaftstheoretische Begründung des Vorgehens...............................12
1.5.3 Eignung der Fallstudien-Methodik ...............................................................14
1.5.4 Zugrundegelegte theoretische Betrachtungsrahmen.....................................15
1.5.4.1 „work system“ als Betrachtungsrahmen .............................................15
1.5.4.2 Modell zur Analyse und zum Management von Risiken ....................19
2. Darstellung der Offshore-Entwicklung.......................................................................23
2.1 Fokussierung auf relevante Elemente des Betrachtungsrahmens ..........................23
2.2 Darstellung des Elements Umwelt .........................................................................24
2.2.1 Räumliche Distanz........................................................................................24
2.2.2 Zeitliche Distanz...........................................................................................25
2.2.3 Kulturelle Unterschiede ................................................................................26
2.2.4 Unterschiede in den Personalkosten .............................................................31
2.2.5 Hohe Verfügbarkeit von qualifizierten Arbeitskräften.................................33
VII
Inhaltsverzeichnis
2.2.6 Prozessreife nach CMM ...............................................................................34
2.2.7 Rechtliche Aspekte .......................................................................................36
2.3 Darstellung des Elements Strategie........................................................................37
2.3.1 Grundsätzliche Sourcing-Formen der Softwareentwicklung........................37
2.3.2 Parameter zur Charakterisierung von Offshore-Beziehungen ......................38
2.3.3 Strategien der Anbieter .................................................................................42
2.4 Darstellung des Elements Geschäftsprozess ..........................................................44
2.4.1 Auswahl relevanter organisatorischer Gestaltungsbereiche .........................44
2.4.2 Begriffsklärung – Organisation ....................................................................46
2.4.3 Beziehung zwischen Koordination und Kontrolle........................................47
2.4.4 Organisatorischer Gestaltungsbereich der Spezialisierung ..........................49
2.4.4.1 Spezialisierungen in der Softwareentwicklung ...................................49
2.4.4.2 Fokussierung auf relevante Aufgaben eines OffshoreLebenszyklus.......................................................................................50
2.4.5 Organisatorischer Gestaltungsbereich der Kontrolle....................................51
2.4.5.1 Grundzüge der Kontrolle.....................................................................51
2.4.5.2 Kontrollmechanismen und Kontrollinstrumente .................................52
2.4.6 Organisatorischer Gestaltungsbereich der Konfiguration ............................55
2.4.7 Organisatorischer
Gestaltungsbereich
der
Entscheidungsdelegation ..............................................................................56
2.4.8 Organisatorischer Gestaltungsbereich der Ablauforganisation ....................57
2.4.9 Organisatorischer Gestaltungsbereich der Kommunikation.........................57
2.4.10 Beziehungen zwischen organisatorischen Gestaltungsbereichen .................60
2.5 Darstellung des Elements Produkt und Service .....................................................61
2.6 Darstellung des Elements Anbieter- und Kundenunternehmen .............................63
2.6.1 Anbieterunternehmen ...................................................................................63
2.6.2 Kundenunternehmen.....................................................................................65
2.7 Darstellung des Elements Ziele und Erwartungen .................................................66
2.7.1 Bedeutung von Zielen der Softwareentwicklung .........................................67
2.7.2 Ziele in der Offshore-Entwicklung...............................................................69
2.7.2.1 Vorgehen zur Identifikation der Ziele .................................................69
2.7.2.2 Ziele aus Perspektive des Kunden.......................................................71
2.7.2.3 Aussagen empirischer Studien über verfolgte Ziele in der
Offshore-Entwicklung.........................................................................71
VIII
Inhaltsverzeichnis
2.7.2.4 Monetäre Ziele ....................................................................................74
2.7.2.5 Strategische Ziele ................................................................................81
2.7.2.6 Prozessbezogene Ziele ........................................................................82
2.7.2.7 Produktbezogene Ziele........................................................................85
2.7.3 Ziele aus Perspektive des Anbieters .............................................................86
2.7.3.1 Prozessbezogene Ziele ........................................................................87
2.7.3.2 Kundenbindungsziele ..........................................................................88
2.8 Darstellung des Elements Risiken..........................................................................90
2.8.1 Klärung der Begriffe Risiko und Risikofaktoren..........................................90
2.8.2 Vorgehen zur Identifikation von Risiken in der OffshoreEntwicklung..................................................................................................91
2.8.3 Fokussierung auf ausgewählte Risiken.........................................................92
2.8.3.1 Kriterien zur Fokussierung auf ausgewählte Risiken..........................92
2.8.3.2 Risiken im Bereich Infrastruktur.........................................................93
2.8.3.3 Risiken im Bereich Umwelt ................................................................94
2.8.3.4 Risiken im Bereich Strategie...............................................................99
2.8.3.5 Risiken im Bereich Beteiligte ...........................................................102
2.8.3.6 Risiken im Bereich Technologie .......................................................106
2.8.3.7 Risiken im Bereich Geschäftsprozess ...............................................106
2.8.3.8 Risiken im Bereich Produkt und Service ..........................................108
2.8.3.9 Risiken im Bereich Anbieter- und Kundenunternehmen ..................109
2.8.3.10 Zusammenfassung der Fokussierung auf ausgewählte
Risikobereiche...................................................................................110
2.9 Darstellung des Elements negative Ergebnisse....................................................113
3. Fallstudien-Untersuchung .........................................................................................115
3.1 Design der Untersuchung.....................................................................................115
3.2 Methode der sozialen Netzwerkanalyse...............................................................118
3.2.1 Grundzüge der sozialen Netzwerkanalyse..................................................118
3.2.2 Anwendung der sozialen Netzwerkanalyse im Rahmen der
Fallstudie.....................................................................................................119
3.3 Untersuchung der einzelnen Elemente des „work system“..................................125
3.3.1 Systematik der Darstellung der Untersuchung ...........................................125
3.3.2 Untersuchung des Elements Anbieter- und Kundenunternehmen..............125
3.3.2.1 Anbieterunternehmen ........................................................................125
IX
Inhaltsverzeichnis
3.3.2.2 Kundenunternehmen .........................................................................126
3.3.3 Untersuchung des Elements Produkt und Service ......................................127
3.3.4 Untersuchung des Elements Technologie...................................................128
3.3.5 Untersuchung des Elements Infrastruktur ..................................................128
3.3.6 Untersuchung des Elements Umwelt..........................................................129
3.3.6.1 Räumliche und zeitliche Distanz.......................................................129
3.3.6.2 Kulturelle Unterschiede.....................................................................130
3.3.6.3 Prozessreife nach CMM ....................................................................135
3.3.6.4 Weitere Aspekte des Elements Umwelt ............................................136
3.3.7 Untersuchung der Elemente Ziele, Erwartungen und negatives
Ergebnis ......................................................................................................137
3.3.8 Untersuchung des Elements Einfluss durch andere Systeme und
Projekte .......................................................................................................143
3.3.9 Untersuchung des Elements Strategie ........................................................146
3.3.10 Untersuchung des Elements Beteiligte .......................................................147
3.3.11 Untersuchung des Elements Geschäftsprozess ...........................................148
3.3.11.1 Organisatorische Gestaltung: Spezialisierung...................................148
3.3.11.2 Organisatorische Gestaltung: Kontrolle ............................................150
3.3.11.3 Organisatorische Gestaltung: Konfiguration.....................................153
3.3.11.3.1
Konfiguration des Anbieters...........................................153
3.3.11.3.2
Konfiguration des Kunden..............................................156
3.3.11.4 Organisatorische Gestaltung: Ablauforganisation ............................157
3.3.11.4.1
Projekt Zürich Re-Engineering.......................................157
3.3.11.4.2
Projekt Zürich Maintenance ...........................................158
3.3.11.4.3
Projekt Zürich Development...........................................160
3.3.11.5 Organisatorische Gestaltung: Kommunikation .................................162
3.3.12 Untersuchung des Elements Risiken ..........................................................163
3.3.12.1 Hinweis zur Vorgehensweise ............................................................163
3.3.12.2 Risiken im Bereich Umwelt ..............................................................164
3.3.12.2.1
Räumliche und zeitliche Distanz ....................................164
3.3.12.2.2
Kulturelle Unterschiede ..................................................181
3.3.12.3 Risiken im Bereich Beteiligte ...........................................................185
3.3.12.4 Risiken im Bereich Geschäftsprozess ...............................................187
4. Abschließende Betrachtung ......................................................................................188
X
Inhaltsverzeichnis
4.1 Überprüfung der Zielerreichung ..........................................................................188
4.1.1 Zusammenfassende Darstellung der Forschungsantwort ...........................188
4.1.2 Beitrag zur Lösung des Praxisproblems .....................................................191
4.1.3 Wesentliche identifizierte organisatorische Maßnahmen ...........................192
4.2 Beurteilung der angewendeten Forschungsmethode............................................198
4.2.1.1 Validität der Konstrukte ....................................................................199
4.2.1.2 Externe Validität ...............................................................................200
4.2.1.3 Glaubwürdigkeit................................................................................201
4.3 Ausblick ...............................................................................................................202
Literaturverzeichnis .......................................................................................................203
Anhang...........................................................................................................................242
Anhang A: Verwendete Zeitschriften und Konferenzen.............................................242
Anhang B: Literaturreview über Risiken in Offshore-Entwicklungen .......................243
Anhang C: In der Fallstudie verwendete Fragebögen.................................................244
Anhang C-1: Fragebogen an den Anbieter..................................................................244
Anhang C-2: Fragebogen an den Kunden ...................................................................249
Anhang C-3: Fragebogen an alle Beteiligte im Rahmen der SNA .............................252
Anhang C-4: Erhobene Daten in der SNA ..................................................................254
XI
Abkürzungsverzeichnis
Abkürzungsverzeichnis
ACM
Association for Computing Machinery
AP
Anbieterperson (Mitarbeiter des Anbieters, der an einem konkreten
Projekt beteiligt war)
ASP
Application Service Providing
BITKOM
Bundesverband Informationswirtschaft, Telekommunikation und neue
Medien e.V.
BPO
Business Process Outsourcing
CIO
Chief Information Officer
CEO
Chief Executive Officer
CMM
Capability Maturity Model
CMMi
CMM integrated
CR
Change request
DACH
Deutschland (D), Österreich (A) und Schweiz (CH)
DEC
Digital Equipment Corporation; Unternehmen
DESIX
Deutsche Bank Eurasia Group Stability Indes
EBSCO
Elton B. Stephens Company; Unternehmen
EITO
European Information Technology Observatory
Engl.
Englisch
IDC
International Data Corporation; Unternehmen
IEEE
Institute of Electrical and Electronics Engineers
IBM
International Business Machines; Unternehmen
ISO
International Organization for Standardization
ISR
Information Systems Research
IST
Indian Standard Time
IT
Informationstechnologie (engl. information technology)
JMIS
Journal of Management Information Systems
KP
Kundenperson (Mitarbeiter des Kunden, der an einem konkreten
Projekt beteiligt war)
MESZ
Mitteleuropäische Sommerzeit
MEZ
Mitteleuropäische Zeit
MISQ
Management Information Systems Quarterly
NASSCOM
National Association of Software and Service Companies
XII
Abkürzungsverzeichnis
PSQM
Prozessorientiertes Softwarequalitätsmanagement
SAP
SAP AG ist der offizielle Name eines Softwareherstellers
SEI
Software Engineering Institute
SNA
Soziale Netzwerkanalyse
Tab.
Tabelle
TCS
Tata Consultancy Services Ltd.; Unternehmen
TPI
Technology Partners International
UBS
Union Bank of Switzerland; Unternehmen
UTC
Universal Time Coordonné; koordinierte Weltzeit
ZEW
Zentrum für europäische Wirtschaftsforschung
ZKB
Zürcher Kantonalbank; Unternehmen
z/OS
Betriebssystem (engl. operating system) für Großrechner von IBM
XIII
Abbildungsverzeichnis
Abbildungsverzeichnis
Abb. 1-1 Zusammenhang zwischen Praxisproblem und Forschungsproblem ..................7
Abb. 1-2 Vorgehen zur Beantwortung der Forschungsfrage...........................................11
Abb. 1-3 Der Betrachtungsrahmen „work system“ .........................................................16
Abb. 1-4 Modell zur Analyse und zum Management von Risiken .................................19
Abb. 2-1 Beispielhafte Gegenüberstellung der Arbeitszeiten in Indien und
Deutschland ..................................................................................................25
Abb. 2-2 Weltweite Verteilung erreichter CMM-Level ..................................................35
Abb. 2-3 Verteilung erreichter CMM-Level in Indien ....................................................35
Abb. 2-4 Nach CMM-Level 4 und 5 zertifizierte Organisationen nach
Ländern .........................................................................................................36
Abb. 2-5 Sourcing-Formen der Softwareentwicklung ....................................................38
Abb. 2-6 Umsatzverteilung nach Vertragstyp indischer Top-Anbieter...........................41
Abb. 2-7 Offshore Aufgaben ...........................................................................................50
Abb. 2-8 Wachstum der indischen Exporte von IT-Dienstleistungen und
Softwareprodukten........................................................................................63
Abb. 2-9 Entwicklung der Anzahl Mitarbeiter der indischen Top 3 OffshoreAnbieter ........................................................................................................65
Abb. 2-10 Umsätze der indischen Top 3 Offshore-Anbieter pro
Geschäftsjahr ................................................................................................65
Abb. 2-11 Prozentuale Verteilung der Branchenumsätze der indischen Top 3
Offshore-Anbieter im Geschäftsjahr 2004-05 ..............................................66
Abb. 2-12 Begriffliche Trennung von Risikofaktor - Risiko – Ziele ..............................90
Abb. 3-1 Erläuterung der grafischen Darstellung von Netzwerken ..............................119
Abb. 3-2 Befragungsinstrument zur sozialen Netzwerkanalyse....................................121
Abb. 3-3 Geografische Verteilung der Gewinne von Infosys .......................................126
Abb. 3-4 Zeitunterschiede zwischen Onsite- und Offshore-Standort in den
Projekten Zürich .........................................................................................130
Abb. 3-5 Aufbauorganisation des Anbieters in den Projekten Zürich
Maintenance und Zürich Development ......................................................154
Abb. 3-6 Aufbauorganisation des Anbieters in den Projekten Zürich ReEngineering.................................................................................................154
Abb. 3-7 Aufbauorganisation der IT-Abteilung des Kunden ........................................156
XIV
Abbildungsverzeichnis
Abb. 3-8 Aufbauorganisation des Kunden für die Projekte Zürich
Maintenance und Development ..................................................................156
Abb. 3-9 Zeitlicher Ablauf der einzelnen Teilaufgaben im Projekt Zürich
Re-Engineering ...........................................................................................157
Abb. 3-10 Prozentuale Verteilung des Aufwands des Anbieters auf die
unterschiedlichen Teilaufgaben im Projekt Zürich ReEngineering.................................................................................................158
Abb. 3-11 Prozentuale Verteilung des Aufwands des Anbieters auf die
einzelnen Teilaufgaben im Projekt Zürich Maintenance............................159
Abb. 3-12 Arbeitsabläufe im Projekt Zürich Maintenance ...........................................160
Abb. 3-13 Zeitlicher Ablauf der einzelnen Teilaufgaben im Projekt Zürich
Development...............................................................................................161
Abb. 3-14 Verteilung des Aufwands des Anbieters auf unterschiedliche
Teilaufgaben im Projekt Zürich Development (inkl. Aufwand
für Projektmanagement) .............................................................................162
Abb. 3-15 Verwendete Kommunikationsmedien in den Projekten Zürich
und deren Häufigkeit ..................................................................................163
Abb. 3-16 Synchrone Kommunikation im Projekt Zürich Development
(über alle Häufigkeiten) ..............................................................................166
Abb. 3-17 Synchrone Kommunikation im Projekt Zürich Maintenance (über
alle Häufigkeiten) .......................................................................................166
Abb. 3-18 Synchrone Kommunikation im Projekt Zürich Development
(täglich).......................................................................................................167
Abb. 3-19 Synchrone Kommunikation im Projekt Zürich Maintenance
(täglich).......................................................................................................167
Abb. 3-20 Asynchrone Kommunikation im Projekt Zürich Development
(mehrmals in der Woche) ...........................................................................168
Abb. 3-21 Asynchrone Kommunikation im Projekt Zürich Maintenance
(mehrmals in der Woche) ...........................................................................169
Abb. 3-22 Asynchrone Kommunikation im Projekt Zürich Development
(über alle Häufigkeiten) ..............................................................................169
Abb. 3-23 Asynchrone Kommunikation im Projekt Zürich Maintenance
(über alle Häufigkeiten) ..............................................................................170
XV
Abbildungsverzeichnis
Abb. 3-24 Kommunikation in den Projekten Zürich Development und
Zürich Maintenance ....................................................................................171
Abb. 3-25 Kommunikation (synchron und asynchron) im Projekt Zürich
Development (mindestens einmal wöchentlich).........................................175
Abb. 3-26 Kommunikation (synchron und asynchron) im Projekt Zürich
Development (über alle Häufigkeiten) .......................................................176
Abb. 3-27 Kommunikation (synchron und asynchron) im Projekt Zürich
Maintenance (über alle Häufigkeiten) ........................................................177
XVI
Tabellenverzeichnis
Tabellenverzeichnis
Tab. 1-1 Elemente und ihre Ausprägungen des Betrachtungsrahmens „work
system“ .........................................................................................................18
Tab. 1-2 Elemente und ihre Ausprägungen des Risiko-Modells.....................................21
Tab. 2-1 Dimensionen nationaler Kultur nach Hofstede .................................................27
Tab. 2-2 Anzahl der Beziehungen bei Outsourcing-Beziehungen ..................................39
Tab. 2-3 Vertragstypen einer Outsourcing-Beziehung....................................................40
Tab. 2-4 Charakterisierung der Sourcing-Form Offshore-Entwicklung im
Rahmen dieser Arbeit ...................................................................................42
Tab. 2-5 Teilaufgaben der Softwareentwicklung ............................................................49
Tab. 2-6 Beispiele für formale Kontrollinstrumente in OutsourcingBeziehung .....................................................................................................54
Tab. 2-7 Beispiele für informale Kontrollinstrumente in OutsourcingBeziehung .....................................................................................................55
Tab. 2-8 Informationspotentiale (media richness) von
Kommunikationsmedien...............................................................................58
Tab. 2-9 Top 15 der indischen Exporteure von IT-Dienstleistungen und
Softwareprodukten, 2004-05 ........................................................................64
Tab. 2-10 Übersicht verfolgter Ziele in Offshore-Projekten aus
Kundenperspektive .......................................................................................70
Tab. 2-11 Monetäre Ziele einer Outsourcing-Entwicklung aus
Kundenperspektive .......................................................................................75
Tab. 2-12 Strategische Ziele einer Outsourcing-Entwicklung aus
Kundenperspektive .......................................................................................81
Tab. 2-13 Prozessbezogene Ziele einer Outsourcing-Entwicklung aus
Kundenperspektive .......................................................................................83
Tab. 2-14 Produktbezogene Ziele einer Outsourcing-Entwicklung aus
Kundenperspektive .......................................................................................86
Tab. 2-15 Zusammenfassung der Fokussierung auf ausgewählte
Risikobereiche ............................................................................................110
Tab. 2-16 Zusammenfassung der identifizierten Risiken (1/2) .....................................111
Tab. 2-17 Zusammenfassung der identifizierten Risiken (2/2) .....................................112
Tab. 3-1 Ablauf der Fallstudienerhebung (1/2) .............................................................116
XVII
Tabellenverzeichnis
Tab. 3-2 Ablauf der Fallstudienerhebung (2/2) .............................................................117
Tab. 3-3 Erhobene Daten im Projekt Zürich Development über alle
Kommunikationsmedien zur Bestimmung der Glaubwürdigkeit ...............123
Tab. 3-4 Erhobene Daten im Projekt Zürich Maintenance über alle
Kommunikationsmedien zur Bestimmung der Glaubwürdigkeit ...............124
Tab. 3-5 Produkt und Service der drei Projekte Zürich.................................................128
Tab. 3-6 Verwendete Technologien in den Projekten Zürich........................................128
Tab. 3-7 Räumliche und zeitliche Differenz in den Projekten Zürich...........................129
Tab. 3-8 Sprache einzelner Dokumente in den Projekten Zürich..................................132
Tab. 3-9 Verwendete Sprachen in den erstellten Softwareprodukten der
Projekte Zürich ...........................................................................................133
Tab. 3-10 Sprache von Kommunikation in den Projekten Zürich.................................134
Tab. 3-11 Ziele aus der Perspektive des Anbieters und des Kunden für das
Projekt Zürich Re-Engineering...................................................................139
Tab. 3-12 Ziele aus der Perspektive des Anbieters und des Kunden für das
Projekt Zürich Maintenance .......................................................................141
Tab. 3-13 Ziele aus der Perspektive des Anbieters und des Kunden für das
Projekt Zürich Development.......................................................................143
Tab. 3-14 Übersicht der beteiligten Personen des Anbieters in den Projekten
Zürich..........................................................................................................144
Tab. 3-15 Übersicht der beteiligten Personen des Kunden in den Projekten
Zürich..........................................................................................................145
Tab. 3-16 Alle Projekte im Rahmen der Offshore-Beziehung zwischen dem
Anbieter und dem Kunden..........................................................................145
Tab. 3-17 Ausprägungen der Parameter zur Charakterisierung der OffshoreBeziehungen ...............................................................................................146
Tab. 3-18 Teilaufgaben in den Projekten Zürich...........................................................148
Tab. 3-19 Formale Kontrollinstrumente in den Projekten Zürich .................................152
Tab. 3-20 Informale Kontrollinstrumente in den Projekten Zürich...............................153
Tab. 3-21 Absolute Verteilung des Aufwands des Anbieters auf unterschiedliche Teilaufgaben im Projekt Zürich Re-Engineering...............................158
Tab. 3-22 Verteilung des Aufwands des Anbieters auf unterschiedliche Teilaufgaben im Projekt Zürich Development (inkl. Aufwand für
Projektmanagement) ...................................................................................161
XVIII
Tabellenverzeichnis
Tab. 3-23 Einschätzung über das Volumen der schriftlichen Kommunikation
in den Projekten Zürich im Verhältnis zu einer internen
Entwicklung................................................................................................173
Tab. 4-1 Auflistung aller betrachteten Elemente...........................................................189
Tab. 4-2 Zusammenfassende Gegenüberstellung von Risiken und
organisatorischen Maßnahmen (1/3) ..........................................................193
Tab. 4-3 Zusammenfassende Gegenüberstellung von Risiken und
organisatorischen Maßnahmen (2/3) ..........................................................194
Tab. 4-4 Zusammenfassende Gegenüberstellung von Risiken und
organisatorischen Maßnahmen (3/3) ..........................................................195
Tab. 4-5 Personen mit der höchsten globalen Zentralität in den Projekten
Zürich Maintenance und Development ......................................................198
Tab. 4-6 Gegenstände der Fallstudien-Dokumentation .................................................202
XIX
Einführung – Begriffsklärung – Outsourcing, Offshoring
1.
Einführung
Ziel des ersten Kapitels ist es, das Themengebiet dieser Arbeit darzustellen und damit
eine Motivation für die wissenschaftliche Auseinandersetzung mit diesem zu liefern.
Innerhalb des Themengebiets wird anschließend ein Praxisproblem identifiziert, aus
dem ein Forschungsproblem abgeleitet wird. Weiter wird in diesem Kapitel geschildert,
wie vorgegangen wird, um das Forschungsproblem zu lösen. Schließlich wird dieses
Vorgehen in eine wissenschaftstheoretische Betrachtung eingeordnet.
1.1
Begriffsklärung – Outsourcing, Offshoring
In der wissenschaftlichen Literatur, Managermagazinen und bei Unternehmensberatungen lässt sich eine Vielzahl an Begriffsschöpfungen um das Thema Offshore finden, die
munter kombiniert und in unterschiedlicher Weise verwendet werden.2
Im Rahmen dieser Arbeit stellt Offshoring3 eine besondere Form von Outsourcing dar.4
Unter Outsourcing5 wird allgemein die Vergabe einer Unternehmensfunktion von einer
Organisation an eine andere Organisation verstanden.6 In der deutschen Sprache lässt
sich am ehesten der Begriff Outsourcing mit „Auslagerung“ übersetzen.7 Insbesondere
soll in dieser Arbeit die Formulierung „das Auslagern von Unternehmensfunktionen“
als Pendant für die englische Formulierung „to outsource“ verwendet werden, um nicht
einen Begriff wie z. B. „outsourcen“ zu verwenden. Das Unternehmen, welches Unter-
2
3
4
5
6
7
Eine Auflistung unterschiedlicher Begriffe befindet sich z. B. bei Hackmann /Worthülsen/ 40.
Abhängig vom jeweiligen grammatikalischen Kontext wird in dieser Arbeit der Begriff „Offshoring“
und „Offshore“ synonym verwendet.
Grundsätzlich kann Offshoring auch innerhalb einer Organisation stattfinden, ohne eine Auslagerung an
einen Anbieter. Dies ist der Fall, wenn zum Beispiel ein Unternehmen eine eigene Entwicklungsabteilung in einem Offshore-Land unterhält. Vgl. z. B. Hermes, Schwarz /Outsourcing/ 33. Im Rahmen
dieser Arbeit wird allerdings der Begriff Offshore synonym zu Offshore-Outsourcing verwendet.
Damit umfasst Offshoring auch stets Outsourcing.
Das Wort „outsourcing“ ist ein Kunstwort aus den Begriffen „outside ressource using“ vgl. z. B. Heinzl
/Outsourcing/ 624.
Vgl. Murty /Impact/ 544 oder auch Ben, Claus /Offshoring/ 35. Bei Dibbern u. a. /Survey/ 10 werden
zehn ähnliche Definitionen von unterschiedlichen Autoren zusammengetragen.
Weiter ist vorstellbar in Abhängigkeit der vorliegenden Sourcing-Form (vgl. Kapitel 2.3.1) eine Unterscheidung zwischen „Auslagerung“ und „Ausgliederung“ vorzunehmen. Diese begriffliche Unterscheidung soll in der vorliegenden Arbeit aber nicht vorgenommen werden und die beiden Begriffe
werden synonym verwendet, da diese Arbeit sich auf eine bestimmte Sourcing-Form konzentriert
und nicht unterschiedliche Sourcing-Formen vergleicht. Siehe hierzu z. B. Stahlknecht, Hasenkamp
/Wirtschaftsinformatik/ 451.
1
Einführung – Begriffsklärung – Outsourcing, Offshoring
nehmensfunktionen auslagert, wird dabei als Kunde bezeichnet und das Unternehmen,
das diese Unternehmensfunktionen erfüllt, wird als Anbieter bezeichnet.
Yang und Huang haben drei Gemeinsamkeiten von Outsourcing Definitionen im Kontext von Informationssystemen bei unterschiedlichen Autoren identifiziert:8 Erstens
übernimmt ein externer Anbieter ausgewählte oder alle IT-Funktionen einer Organisation, zweitens trägt der Anbieter für diese Funktionen Verantwortung und drittens kann
der Kunde zusätzlich Mitarbeiter und Teile seiner Computer-Hardware an den Anbieter
übergeben.
Offshoring bezeichnet die Vergabe von Unternehmensfunktionen an eine Organisation
in einem Niedriglohnland, die eine größere geografische Entfernung zur vergebenden
Organisation besitzt.9 Im Rahmen dieser Arbeit bezeichnet Offshoring die Vergabe von
Unternehmensfunktionen von einem deutschsprachigen Land10 nach Indien.11 Dem
gegenüber lässt sich eine kürzere geografische Distanz wie zum Beispiel zwischen
Deutschland und der Tschechischen Republik als „Near-shore“ bezeichnen.
In Abschnitt 2.4.4 findet eine genauere Abgrenzung der betrachteten Unternehmensfunktionen statt. An dieser Stelle genügt es, die betrachtete Unternehmensfunktion mit
Softwareentwicklung zu bezeichnen, um ein grundsätzliches Verständnis der Thematik
dieser Arbeit zu vermitteln. Entsprechend obiger Ausführungen wird hier unter einer
Offshore-Entwicklung der Prozess zur Softwareentwicklung verstanden, der im Rahmen eines Offshoring stattfindet.
Gemäß den bisherigen Ausführungen wird eine in DACH ansässige Organisation, die
bestimmte Softwareentwicklungsaufgaben an eine andere Organisation vergibt, als
Kunde bezeichnet. Eine Organisation mit Sitz in Indien, die diese Entwicklungsaufgabe
8
9
Vgl. Yang, Huang /Decision model/ 227.
Vgl. Ben, Claus /Offshoring/ 35 oder Rajkumar, Mani /Offshore/ 63 wobei hier keine Unterscheidung
zwischen Off- und Near-shore vorgenommen wird. Eine ähnliche Begriffsverwendung befindet sich
auch bei Cullen, Willcocks /Intelligent/ 33; Gopal u. a. /Contracts/ 1671 oder Lacity, Willcocks
/Global/ 4.
10
11
Hierzu zählen Deutschland, Österreich und die Schweiz – abgekürzt mit DACH.
Die in dieser Arbeit geführten Diskussionen lassen sich in den meisten Fällen problemlos auch auf
andere Konstellationen wie z. B. Deutschland - Thailand, Deutschland - China oder auch USA - Indien übertragen. Doch um die Diskussion anschaulicher und nachvollziehbarer zu gestalten und
nicht permanent besondere Annahmen aufzuführen, wird hier die Konstellation DACH - Indien
zugrunde gelegt. Des Weiteren ist die Betrachtung zwischen DACH und Indien im Rahmen wissenschaftlicher Untersuchungen zum Thema Offshore-Entwicklung unterrepräsentiert, da primär eine
Betrachtung von USA – Indien vorliegt, sodass diese Arbeit eine sinnvolle Ergänzung darstellt. Über die Bedeutung Indiens im Rahmen von Offshore-Entwicklungen vgl. z. B. Clott /Perspectives/
157f. oder Stephan /Schlüsselfaktoren/ 214.
2
Einführung – Kurzer Überblick der historischen Entwicklung der Offshore-Entwicklung
übernimmt und folglich diese Dienstleistung anbietet, wird als Anbieter bezeichnet.
Der Anbieter teilt dabei seine Mitarbeiter, die an einer Offshore-Entwicklung beteiligt
sind, üblicherweise in ein in Indien agierendes Offshore-Team und in ein OnsiteTeam, welches vor Ort beim Kunden tätig ist.12
Neben dem oben dargestellten und hier verwendeten Begriffsverständnis von Offshore
wird der Begriff auch in anderen Bereichen verwendet. Wörtlich lässt sich „offshore“
mit „in einiger Entfernung von der Küste“ übersetzen.13 Dementsprechend werden mit
Offshore auch feststehende Bauwerke bezeichnet, die in der offenen See vor der Küste
errichtet wurden, wie zum Beispiel Bohrinseln oder Windenergieanlagen.14 Auch im
Bereich Finanzwirtschaft findet der Begriff Offshore Verwendung. So werden mit
Offshore-Finanzzentren Finanzplätze für internationale Finanzgeschäfte von Banken
und Unternehmen bezeichnet, „die den Finanzmarkt des Landes, in dem sie getätigt
werden, nicht berühren und deshalb von wesentlichen nationalen Beschränkungen
freigestellt sind“.15
1.2
Kurzer Überblick der historischen Entwicklung der Offshore-Entwicklung
Die ersten IT-Outsourcing-Aktivitäten lassen sich bereits in den 1950er Jahren finden,16
wobei das Thema IT-Outsourcing erst durch den Vertrag von 1989 zwischen Eastman
Kodak und IBM, DEC und Businessland an Popularität gewonnen hat.17 Zuvor hatte
noch kein gut bekanntes Unternehmen einen so umfangreichen Outsourcing-Vertrag
abgeschlossen.
12
13
14
15
16
17
Auf diese organisatorische Gestaltung wird genauer in Kapitel 3.3.11 eingegangen.
Vgl. o. V. /Brockhaus/ Band 16, 159.
Vgl. o. V. /Brockhaus/ Band 16, 159f. oder Wikipedia /Offshore/.
O. V. /Brockhaus/ Band 16, 160.
Bei Klepper, Jones /Outsourcing/ xxi wird auf einen IT-Outsourcing-Vertrag aus dem Jahre 1954
zwischen General Electric Corp., Arthur Andersen und Univac verwiesen. In ihrem historischen
Überblick über die IT-Outsourcing-Entwicklung beginnen Lee u. a. allerdings erst in den 1960ern vgl. Lee u. a. /Outsourcing/ 84.
Vgl. Applegate, Montealegre /Eastman Kodak/; Dibbern /Sourcing/ 1 und Lacity, Hirschheim /IS
Outsourcing/ 3f.
3
Einführung – Kurzer Überblick der historischen Entwicklung der Offshore-Entwicklung
Seitdem wachsen Umfang und Anzahl an IT-Outsourcing-Abkommen kontinuierlich.18
Dies gilt auch für Deutschland, allerdings auf einem niedrigeren Ausgangsniveau gegenüber den USA.19
Erste Offshore-Aktivitäten wurden Anfang der 1990er bekannt20 und kamen verstärkt
Ende der 1990er auf. Im Zuge des allgemeinen Booms in der IT-Branche, des Jahr2000-Problems und der Euroumstellung wuchs der Bedarf an IT-Fachkräften über das
in den Industriestaaten vorhandene Potential hinaus.21 Aus dieser Situation heraus entwickelte sich maßgeblich die Offshore-Entwicklung.22
Dabei wuchs dieser Trend in den USA und England schneller als in Deutschland. Noch
heute liegen deutsche Unternehmen in Bezug auf Umfang und Anzahl ihrer OffshoreAktivitäten weit hinter englischen und amerikanischen Unternehmen zurück, wobei
bereits das Gesamtvolumen des IT-Outsourcings in Deutschland in Relation zur USA
geringer ausfällt.23 So wurden die Ausgaben für IT-Offshore-Aktivitäten für 2004 in
den USA auf grob 9,7 Milliarden Euro geschätzt24 wogegen diese Ausgaben in Europa
für 2004 auf 1,1 Milliarden Euro geschätzt wurden.25
Dieser Trend ist auch in der historischen Entwicklung erfolgreicher indischer Anbieter
von Offshore-Dienstleistungen zu erkennen.26 Diese wachsen seit Mitte der 1990er
stark. Ihr Kerngeschäft liegt in den USA, wobei der Anteil europäischer Kunden am
18
19
20
21
22
23
24
25
26
Zahlreiche Marktanalysen bestätigen diese Entwicklung und prognostizieren ein weiteres Wachstum.
Vgl. z. B. Allweyer, Besthorn, Schaaf /IT-Outsourcing/; EITO /2005/; Lucacs /Outsourcing markets/
oder Metagroup /2003 Worldwide/.
Gemäß Marktanalysen von EITO /2005/ und Murphy, Chen /Worldwide outsourcing/. Über die beiden
anderen DACH-Staaten – Österreich und Schweiz – stehen dem Autor keine Markdaten zu Verfügung.
Vgl. Deutsche Bank Research /Outsourcing/ 8; Khan u. a. /Evaluating/ 2; Krepchin /Offshore/ 55 oder
Patane, Jurison /Global outscourcing/ 7.
Vgl. Barr, Tessler /Software talent shortage/ 2; Jones /The Euro/ 55-58; Karolak /Global software
development/ 2 oder Weber /Implications/ iii.
Vgl. Arora, Gambardella /Globalization/ 6; Capers /Euro/ 59 oder Deutsche Bank Research
/Outsourcing/ 8.
Vgl. Dibbern, Güttler, Heinzl /Theorie/ 676. Da dem Autor keine Markdaten der beiden übrigen
DACH-Staaten zur Verfügung stehen, beschränken sich diese Aussagen auf Deutschland.
Vgl. Studie von Global Insight /Impact/ 3. In dieser Studie wurde der Betrag von 13 Milliarden USD
genannt, der hier in Euro umgerechnet wurde.
Vgl. Studie von Forrester Research: Parker /Offshore spending/ 5. Bei dieser Studie betragen alleine
die Ausgaben englischer Unternehmen für Offshore-Aktivitäten 768 Millionen Euro. Eine andere
Schätzung (Amberg, Wiener /Erfolgsfaktoren/ 1) schätzt das Gesamtvolumen des deutschen Offshore-Marktes im Jahre 2003 auf 400 Millionen Euro ein.
In Abschnitt 2.6.1 wird die Entwicklung der indischen Offshore-Branche genauer dargestellt.
4
Einführung – Motivation für die Thematik Offshore-Entwicklung
Gesamtumsatz in den letzten Jahren stetig wächst. Unterstützt wurde dieser Trend auch
durch eine starke Liberalisierung Indiens Mitte der 1980er Jahre und insbesondere ab
1991.27 Der Anbietermarkt von Offshore-Dienstleistungen wird in den 2000er Jahren
deutlich von indischen Software-Unternehmen dominiert.28
1.3
Motivation für die Thematik Offshore-Entwicklung
Die im vorangegangenen Kapitel dargestellte historische Entwicklung zeigt eine weltweite Zunahme von Offshore-Projekten, die insbesondere durch die USA geprägt
wird.29 Doch auch in Deutschland nimmt in den vergangenen Jahren die Zahl der Offshore-Projekte stetig zu, allerdings auf einem niedrigeren Gesamtniveau als in den USA
oder Großbritannien.30 Diese Entwicklung spiegelt das allgemeine Interesse von Unternehmen wider, ein Offshore-Outsourcing zu betreiben. Einen weiteren Beleg für dieses
spezielle Interesse in Deutschland stellen auch Aktivitäten der BITKOM31 oder staatliche Initiativen wie zum Beispiel die „Software Offensive Bayern“32 dar.
Da auf der einen Seite die Anzahl von Offshore-Projekten in Deutschland noch relativ
gering ist und gleichzeitig mit einem Wachstum der Offshore-Branche gerechnet wird,33
ist mit einer steigenden Zahl von „Erstprojekten“ zu rechnen. Für diese liefert die vorliegende Arbeit nützliche Hinweise zum Verständnis der organisatorischen Gestaltung
27
28
29
30
31
32
33
Vgl. o. V. /Brockhaus/ Band 10, 458.
Vgl. z. B. Deutsche Bank Research /Outsourcing/ 1 oder eine Untersuchung der Deutsche Bank Research in Kooperation mit BITKOM in Schaaf, Weber /Offshoring-Report 2005/ 17.
Vgl. z. B. Murty /Impact/ 544.
Vgl. Studie von TPI (Technology Partners International) in Hackmann, Prehl /Europäische Anwender/
35.
BITKOM (Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V.) bezeichnet sich als „Sprachrohr der IT-, Telekommunikations- und Neue-Medien-Branche“ (BITKOM
/Wir/) und hat unterschiedliche Leitfäden zum Themenkomplex Outsourcing und Offshore veröffentlicht. Z. B. Leitfaden Business Process Outsourcing (BITKOM /Leitfaden BPO/); Leitfaden
Offshoring (BITKOM /Leitfaden Offshoring/) oder Positionspapier Outsourcing (BITKOM /ITOutsourcing/) sowie die Studie “Offshoring-Report 2005” in Zusammenarbeit mit dem Institut
Deutsche Bank Research – vgl. Schaaf, Weber /Offshoring-Report 2005/.
Hierzu gehört zum Beispiel der Leitfaden „Offshore IT für den Mittelstand“ (Software Forum e.V.
/Mittelstand/).
Vgl. Ben, Claus /Offshoring/ 37, die auf unterschiedliche Deutschland-bezogene Marktstudien und
Prognosen für den Offshore-Markt verweisen. Auch Schaaf, Weber /Offshoring-Report 2005/ 11
prognostiziert diesen Wachstumstrend auf Basis einer Umfrage mit 572 Teilnehmern. Siehe auch
Stephan /Schlüsselfaktoren/ 215.
5
Einführung – Motivation für die Thematik Offshore-Entwicklung
von Offshore-Projekten. Werden bereits Offshore-Projekte durchgeführt, kann diese
Arbeit Ansätze für Lösungen von eventuell auftretenden Problemen liefern.34
Insgesamt kommt die Betrachtung von deutschsprachigen Unternehmen in wissenschaftlichen Untersuchungen zum Thema Offshore zu kurz. Vielmehr findet eine Konzentration auf die beiden Länder USA und Indien statt. Dabei bestehen zwischen
DACH-Staaten und den USA Unterschiede, die sich auf die organisatorische Gestaltung
von Offshore-Entwicklungen auswirken könnten. Zu den Unterschieden zwischen den
DACH-Staaten und den USA zählen zum Beispiel, dass in den DACH-Staaten Englisch
nicht als Amtssprache gilt, kulturelle Unterschiede bestehen oder dass gegenüber Indien
unterschiedliche zeitliche und räumliche Entfernungen liegen.35
Daher liefert die vorliegende Betrachtung eine Ergänzung zu existierenden Betrachtungen und berücksichtigt dabei sowohl die Perspektive des Anbieters als auch des Kunden. Dabei wird die Situation zwischen einem deutschsprachigen Kunden und einem
indischen Anbieter von Offshore-Dienstleistungen detailliert betrachtet.
Der folgende Abschnitt kristallisiert ein Praxisproblem und eine zugehörige Forschungsfrage aus dem Themenkomplex der Offshore-Entwicklung heraus.
34
35
Z. B. 36% von 5.231 befragten Teilnehmer (davon 3.139 aus den USA) einer Studie gaben an, dass
Offshore-Projekte nicht erfolgreich waren. Vgl. Hatch /Offshore 2005/ 17.
Vgl. hierzu Ben, Claus /Offshoring/ 37; Krishna, Sahay, Walsham /Cross-cultural issues/ 64 oder
Schaaf, Weber /Offshoring-Report 2005/ 21. Stephan /Schlüsselfaktoren/ 215 sieht die noch relativ
zu den USA oder England gesehene geringere Verbreitung von Offshore-Projekten in Deutschland
durch vorhandene Sprach- und Kommunikationsbarrieren begründet.
6
Einführung – Problemstellung und Zielsetzung der Arbeit
1.4
1.4.1
Problemstellung und Zielsetzung der Arbeit
Zusammenhang zwischen Praxisproblem und Forschungsproblem
Die Zielsetzung der vorliegenden Arbeit lässt sich mit Hilfe des in Abbildung Abb. 1-1
aufgezeigten Zusammenhangs näher erläutern und motivieren.36 Ein in der Realität
identifiziertes Praxisproblem stellt die Ausgangssituation dar. Dieses Praxisproblem
motiviert eine Forschungsfrage, mit der ein Forschungsproblem definiert wird. Eine
Antwort auf das Forschungsproblem soll schließlich helfen, das ursprüngliche Praxisproblem zu lösen.
Im Folgenden werden nun Praxisproblem, Forschungsfrage und Forschungsproblem
charakterisiert und im Kontext dieser Arbeit erläutert. Die Forschungsantwort stellt das
Ergebnis dieser Arbeit dar und soll helfen, das ursprüngliche Praxisproblem zu lösen.
Die Antwort auf die Forschungsfragen wird in den Kapiteln 2 und 3 dieser Arbeit entwickelt.
Praxisproblem
hilft zu
motiviert
lösen
Forschungsantwort
Forschungsfrage
findet
definiert
Forschungsproblem
37
Abb. 1-1 Zusammenhang zwischen Praxisproblem und Forschungsproblem
36
37
Vgl. zu diesem Absatz Booth, Colomb, Williams /Craft/ 57-60.
In Anlehnung an Booth, Colomb, Williams /Craft/ 58.
7
Einführung – Problemstellung und Zielsetzung der Arbeit
1.4.2
Praxisproblem
Allgemein zeichnet sich ein Praxisproblem durch Unzufriedenheit mit einem Zustand
in der Realität aus.38
Im Kontext dieser Arbeit stellt die Offshore-Entwicklung den betrachteten Realitätsausschnitt dar. Weiter liegt dem betrachteten Realitätsausschnitt die Annahme zugrunde,
dass bereits auf Kundenseite eine Entscheidung für eine Offshore-Entwicklung gefällt
wurde und ein entsprechender Anbieter ausgewählt wurde. Im vorherigen Kapitel wurde
bereits die Motivation geliefert, dass hierbei ein Kunde aus einem deutschsprachigen
Staat und ein indischer Anbieter betrachtet werden.
Die Unzufriedenheit, die bei einer solchen Offshore-Entwicklung entstehen kann, kann
sich aus dem Verfehlen gesetzter Ziele ergeben. In der Regel schlägt sich eine solche
Verfehlung auch in einem finanziellen Verlust nieder.
Mit der Offshore-Entwicklung verfolgen sowohl Kunden als auch Anbieter individuelle
Ziele39, deren Erreichung allerdings von Risiken bedroht wird.40 Es stellt sich daher die
Frage, wie Offshore-Entwicklungen erfolgreich durchgeführt werden können, sodass
sowohl Kunden als auch Anbieter ihre individuellen Ziele erreichen.
1.4.3
Forschungsfragen und Forschungsproblem
Im Gegensatz zu einem Praxisproblem zeichnet sich ein Forschungsproblem durch
einen Mangel an Wissen bzw. an fehlendem Verständnis von etwas aus.41
Das oben dargestellte Praxisproblem ist sehr allgemein formuliert und es ist denkbar
dieses Problem innerhalb sehr unterschiedlicher Themenbereiche zu untersuchen. So
könnte die Betrachtung zum Beispiel eher juristischer Natur sein und rein auf die Vertragsgestaltung zwischen Kunden und Anbieter fokussieren.42 Die vorliegende Arbeit
38
39
40
41
42
Vgl. Booth, Colomb, Williams /Craft/ 59.
Siehe zur Darstellung der individuellen Ziele Abschnitt 2.7.
In einer Studie mit über 5.000 Beteiligten erzielen 53% der Offshore-Projekte keine Kostenersparnis
oder sind sogar steigenden Kosten ausgesetzt. In der gleichen Studie gaben über 70% der Befragten
Kostenersparnisse als Ziel der Offshore-Entwicklung an. Insgesamt gaben 36% der Teilnehmer an,
dass ihre Offshore-Entwicklung nicht erfolgreich war. Vgl. hierzu Hatch /Offshore 2005/ 14 und 1617. McKinsey hat 30 Outsourcing-Abkommen untersucht und festgestellt, dass nur 50% davon erfolgreich waren – vgl. McKinsey Quarterly /Outsourcing/.
Vgl. Booth, Colomb, Williams /Craft/ 59.
Vgl. z. B. Bräutigam /IT-Outsourcing/ hier werden umfassend rechtliche Aspekte (Arbeits-, Bank-,
Datenschutz, Steuer- und Urheberrecht) von IT-Outsourcing Beziehungen dargestellt. Gopal u. a.
/Contracts/ liefern eine empirische Analyse von Offshore-Verträgen.
8
Einführung – Problemstellung und Zielsetzung der Arbeit
verfolgt hingegen einen Fokus auf die organisatorische Gestaltung43 von OffshoreEntwicklungen. Dabei stellt sich insbesondere die Frage, welche Besonderheiten und
Risiken bei der Offshore-Entwicklung auftreten und wie diese bei der organisatorischen
Gestaltung berücksichtigt werden können.
Wenn bekannt ist, welche Besonderheiten und Risiken bei der Offshore-Entwicklung
vorliegen können und wie diesen mit organisatorischen Maßnahmen begegnet werden
kann, ist zu erwarten, dass die individuellen Ziele auf Kunden- und auf Anbieterseite
erfolgreicher verwirklicht werden. Über die hohe Relevanz der organisatorischen Gestaltung bei Softwareentwicklungen im Allgemeinen finden sich bei Mellis zahlreiche
Verweise auf Expertenmeinungen und empirische Untersuchungen.44 Daher ist es gerechtfertigt, auch in der vorliegenden Arbeit den Fokus auf die Betrachtung der organisatorischen Gestaltung zu setzen. Ein Literatur-Review zum Thema Erfolgsfaktoren in
der Offshore-Entwicklung schreibt den Erfolgsfaktoren der Kategorie Organisation die
größte Bedeutung zu und unterstreicht damit die Bedeutung der organisatorischen Gestaltung.45
Ein Bewusstsein möglicher Risiken bei der Offshore-Entwicklung wird auch dazu
beitragen, dass sowohl Kunden als auch Anbieter realisierbare Zielvorstellungen entwickeln und nicht die Offshore-Beziehung mit utopischen Vorstellungen eingehen.
Bei Offshore-Entwicklungen spielt die große geografische Entfernung zwischen Kunde
und Anbieter eine zentrale Rolle und ist charakteristisch für diese Art der Entwicklung.46 In dieser Arbeit soll daher das Hauptaugenmerk der Untersuchung auf den
Schnittstellen zwischen Anbietern und Kunden von Offshore-Dienstleistungen liegen,
da zum einen hier wesentliche Unterschiede gegenüber einer internen oder einer Auftragsentwicklung mit nur kurzen geografischen Entfernungen hervortreten. Zum ande-
43
44
45
46
Die organisatorische Gestaltung wird in Kapitel 2.4 in mehrere Gestaltungsbereiche geteilt und näher
vorgestellt. Jedem Gestaltungsbereich lassen sich dann organisatorische Maßnahmen zuordnen.
Vgl. Mellis /Projektmanagement/ 69.
Vgl. Amberg, Wiener /Erfolgsfaktoren/ 10-11. Es werden insgesamt 177 Erfolgsfaktoren in der untersuchten Literatur identifiziert; 90 davon werden der Kategorie Organisation zugeschrieben. Die
zweithäufigste von insgesamt acht Kategorien ist die Kategorie Entscheidung mit 23 identifizierten
Faktoren.
Siehe hierzu insb. Kapitel 2.2 in dem Besonderheiten der Offshore-Entwicklung dargestellt werden.
9
Einführung – Problemstellung und Zielsetzung der Arbeit
ren wird der Kommunikation zwischen den beteiligten Personen in einer Softwareentwicklung im Allgemeinen eine zentrale Bedeutung für den Erfolg zugeschrieben.47
Eine detaillierte interne Betrachtung von Offshore-Teams wird möglichst ausgeklammert und nur soweit behandelt, wie es für ein Verständnis der betrachteten Situation
notwendig ist.
Das Forschungsproblem besteht maßgeblich darin, dass es zurzeit an wissenschaftlicher
Literatur mangelt, die sich ausführlich mit einer Risikobetrachtung und der organisatorischen Gestaltung von Offshore-Entwicklungen in deutschsprachigen Ländern beschäftigt. Es lässt sich zwar eine Vielzahl an Literatur zum Thema Offshore-Entwicklung
finden, die auch in dieser Arbeit aufgegriffen wird, doch häufig sind diese Betrachtungen entweder auf einem relativ oberflächlichen Niveau oder beleuchten in der Tiefe nur
sehr eingegrenzte Aspekte einer Offshore-Entwicklung. Insbesondere wird aber in der
vorliegenden Literatur keine deutliche Verbindung zwischen Risiken einerseits und
organisatorischen Maßnahmen andererseits dargestellt.
Es wird ein Betrachtungsrahmen benötigt, um Offshore-Entwicklungen charakterisieren
zu können und um sie systematisch und umfassend darstellen zu können. Diese Darstellung dient dann als Grundlage um zu untersuchen, welche organisatorische Gestaltung
gewählt werden kann, um Besonderheiten und Risiken einer Offshore-Entwicklung zu
überwinden. Dabei liegt der Fokus der vorliegenden Untersuchung insbesondere auf
Kommunikationsprozessen zwischen dem Anbieter und dem Kunden.
Zusammenfassend ergeben sich aus den obigen Überlegungen die folgenden Forschungsfragen:
ƒ
Wie können Offshore-Entwicklungen vollständig und systematisch dargestellt
werden?
ƒ
Welche Besonderheiten und Risiken treten bei einer Offshore-Entwicklung auf?
ƒ
Wie können diese Besonderheiten und Risiken mit organisatorischen Maßnahmen berücksichtigt werden?
47
Vgl. Espinosa, Carmel /Dyad model/ 2; Herbsleb, Mockus /Empirical/ 481 und Lang /Organisation/ 79.
Kraut, Streeter /Coordination/ 80 weisen in ihrer empirischen Studie die Bedeutung von Kommunikation in Offshore-Entwicklungen nach.
10
Einführung – Gewähltes Vorgehen zur Beantwortung der Forschungsfragen
1.5
Gewähltes Vorgehen zur Beantwortung der Forschungsfragen
1.5.1
Überblick über das Vorgehen
Nachdem das Ziel der Arbeit in Form der Forschungsfragen formuliert wurde und durch
den Bezug zu dem identifizierten Praxisproblem motiviert wurde, wird nun erörtert, wie
in dieser Arbeit vorgegangen wird, um eine Antwort auf das Ausgangsproblem zu
generieren. Folgende Abbildung repräsentiert den Aufbau der vorliegenden Arbeit.
Forschungsantwort
Praxisproblem
(1.4.2)
Untersuchung ausgewählter
Offshore-Projekte (3)
Charakterisierung von
Offshore-Entwicklungen (2)
Forschungsproblem
(1.4.3)
Aufstellen eines
Untersuchungsrahmens
(1.5.4)
Forschungsfrage
(1.4.3)
Abb. 1-2 Vorgehen zur Beantwortung der Forschungsfrage
Bei der Formulierung der Forschungsfrage wurde bereits betont, dass es erforderlich ist
einen Betrachtungsrahmen aufzustellen, um Offshore-Entwicklungen zu charakterisieren und um sie systematisch und umfassend darstellen zu können. Dieser Rahmen wird
in Kapitel 1.5.4 aufgestellt. Er besteht aus mehreren Elementen, die in Kapitel 2 dargestellt werden. Dabei werden auf Basis von Literatur-Reviews und theoretischen Überlegungen auch Besonderheiten, Risiken und Ziele von Offshore-Entwicklungen verdeutlicht. Um in konkreten Projekten gewählte organisatorische Gestaltungen nachvollziehen zu können, wurde der Betrachtungsrahmen so gewählt, dass mit ihm möglichst
11
Einführung – Gewähltes Vorgehen zur Beantwortung der Forschungsfragen
umfangreich der vorliegende Kontext der Offshore-Entwicklung dargestellt werden
kann.48
In Kapitel 3 erfolgt dann eine fallstudienbasierte Untersuchung einzelner OffshoreProjekte, um zu verstehen welche Besonderheiten und Risiken auftraten und mit welchen organisatorischen Maßnahmen darauf reagiert wurde.
In Kapitel 1.5.3 wird die Fallstudien-Methodik näher vorgestellt und erläutert, warum
diese für die Beantwortung der Forschungsfrage geeignet ist. Innerhalb der FallstudienUntersuchung wird auch die soziale Netzwerkanalyse angewendet, um vorliegende
Kommunikationsflüsse zwischen den beteiligten Personen zu analysieren.49
Schließlich wird in Kapitel 4 reflektiert, inwieweit die erarbeitete Forschungsantwort
dazu beiträgt das Praxisproblem zu lösen. Weiter erfolgt an dieser Stelle eine Beurteilung der angewendeten Methode.
1.5.2
Wissenschaftstheoretische Begründung des Vorgehens
Dieses Kapitel soll die Vorgehensweise der vorliegenden Arbeit mit Hilfe wissenschaftstheoretischer Überlegungen begründen. Dabei sollen allerdings nicht sämtliche
unterschiedlichen theoretischen Perspektiven dargestellt und verglichen werden. Vielmehr wird an gegebener Stelle auf weiterführende und vertiefende Literatur verwiesen.
Ziel der Arbeit ist es, die organisatorische Gestaltung einzelner Offshore-Projekte möglichst exakt in ihrem jeweiligen Kontext zu untersuchen. Daher folgt diese Arbeit
grundsätzlich einem idiographischen Ansatz im Gegensatz zu einem nomothetischen
Ansatz.50 Denn Ziel ist es nicht, wie bei einem nomothetischen Ansatz, eine allgemein
gültige Gesetzmäßigkeit zu finden.51 Vielmehr soll die organisatorische Gestaltung
konkreter Offshore-Projekte verstanden werden.
48
49
50
51
Die Berücksichtigung eines komplexen organisationellen Kontextes, um ein Phänomen verstehen zu
können geht auf Annahmen bei Orlikowski /CASE tools/ 311 im Rahmen der Grounded Theory zurück.
In Kapitel 3.2 erfolgt eine genauere Darstellung der angewendeten sozialen Netzwerkanalyse.
Zur Unterscheidung und Definition dieser beiden Begriffe greifen Luthans, Davis /Idiographic approach/ 380f. auf Allport /General/ zurück.
Damit wird hier auch Franz und Robey gefolgt, die empfehlen im Bereich der IS-Forschung einen
ideographischen Ansatz zu verfolgen. Vgl. Franz, Robey /Investigation/ 1203.
12
Einführung – Gewähltes Vorgehen zur Beantwortung der Forschungsfragen
Im Kern der Arbeit geht es um das Verständnis, wie mit organisatorischen Maßnahmen
mit den Besonderheiten und Risiken einer Offshore-Entwicklung umgegangen werden
kann. Hierzu werden insbesondere Handlungen und Aussagen von an der Entwicklung
beteiligten Personen untersucht, um Kommunikations- und Koordinationsprozesse zu
verstehen.
Daher werden in der vorliegenden Arbeit qualitative Forschungsmethoden angewendet,
um soziale und kulturelle Phänomene zwischen einem Anbieter und einem Kunden von
Offshore-Dienstleistungen zu untersuchen.52 Dabei wird auf qualitative Daten aus Interviews und Fragebögen zurückgegriffen.
Folgt man den von Orlikowski und Baroudi verwendeten Kriterien zur Unterscheidung
zwischen einer positivistischen und einer interpretativen Forschungsmethode, so kann
die vorliegende Arbeit als interpretativ eingestuft werden.53 Da insbesondere keine
formalen Annahmen belegt werden, keine Hypothesen getestet werden, keine quantifizierbaren Messgrößen vorliegen und keine Schlussfolgerungen von einem repräsentativen Sample auf eine größere Population vorgenommen werden, kann die hier verfolgte
Forschungsmethode nicht als positivistisch eingestuft werden.
Weiter wird die Perspektive der am Projekt beteiligten Personen als primäre Informationsquelle für die vorliegende Untersuchung verwendet und es werden kulturelle und
weitere kontextbezogene Faktoren berücksichtigt.54 Daher lässt sich diese Untersuchung
der interpretativen Forschung zuordnen.
Zur Erreichung des Forschungsziels dieser Arbeit wird die Fallstudien-Methodik angewendet, die im folgenden Kapitel ausführlicher dargestellt wird. Die Fallstudien-
52
53
54
Vergleiche zu diesem Absatz den Einstieg in qualitative Forschungsmethoden der Association of
Information Systems - Myers /Qualitative research/. Auch Klein, Myers /Principles/ 89 und Orlikowski, Baroudi /Research approaches/ bieten einen interessanten Einstieg, in dem sie positivistische, interpretative und kritische Forschungsmethoden voneinander abgrenzen. Chen, Hirschheim
/Examination/ 201f. kontrastieren ein positivistisches gegenüber einem interpretativen Vorgehen.
Vgl. zu diesem Absatz zu den Kriterien Orlikowski, Baroudi /Research approaches/ 5. Orlikowski und
Baroudi verwenden diese Kriterien, um zu unterscheiden, ob veröffentlichte Artikel ein positivistisches oder interpretatives Vorgehen verfolgen. Auch Chen, Hirschheim /Examination/ 204 wenden
diese Kriterien zur Kategorisierung von Artikeln an. Eine Einführung zur interpretativen ISForschung liefern z. B. Darke, Shanks, Broadbent /Case study/ 276f.; Klein, Myers /Principles/ 69
oder Walsham /Interpretivism/ 384 bzw. Walsham /Organizations/ 4f.
Vgl. hierzu Walsham /Interpretive case studies/ 75f.
13
Einführung – Gewähltes Vorgehen zur Beantwortung der Forschungsfragen
Methodik gilt als eine sehr verbreitete qualitative Forschungsmethode im Bereich Informationssysteme.55
In Abhängigkeit der zugrunde gelegten philosophischen Perspektive können Fallstudien
sowohl positivistisch56 als auch – wie in der vorliegenden Arbeit – interpretativ57 angewendet werden.58
1.5.3
Eignung der Fallstudien-Methodik
Die Forschungsfragen dieser Arbeit umfassen die Frage, wie mit organisatorischen
Maßnahmen Besonderheiten und Risiken einer Offshore-Entwicklung berücksichtigt
werden können. Um dieser Frage nachzugehen eignet sich grundsätzlich eine qualitative
Untersuchungsmethode, da hierbei das Ziel verfolgt wird ein soziales Phänomen in
seiner natürlichen Umgebung und seinem kulturellen Kontext zu verstehen.59
Eine weit verbreitete qualitative Forschungsmethode in der InformationssystemForschung ist die Fallstudienmethode.60 Mit Fallstudien lassen sich nach Yin im Wesentlichen drei Ziele verfolgen:61 Es werden existierende Phänomene anhand konkreter
Ausprägungen erklärt (engl. explanatory), es werden existierende Phänomene beschrieben (engl. descriptive) oder es werden auf Basis konkreter Beobachtungen Theorien
entwickelt (engl. exploratory).
Die Stärke von Fallstudien liegt insbesondere darin „wie“- und „warum“-Fragen zu
beantworten, so wie auch die Forschungsfragen der vorliegenden Arbeit formuliert
sind.62
Ein Ziel der vorliegenden Arbeit ist es zu beschreiben, wie Besonderheiten und Risiken
einer Offshore-Entwicklung mit organisatorischen Maßnahmen berücksichtigt werden
55
56
57
58
59
60
61
62
Vgl. Alavi, Carlson /Review/ 54; Chen, Hirschheim /Examination/ 209 oder Orlikowski, Baroudi
/Research approaches/ 4.
Vgl. Benbasat, Goldstein, Mead /Case research strategy/ oder Yin /Case study/.
Vgl. Walsham /Interpretive case studies/ oder Walsham /Organizations/.
Vgl. Myers /Qualitative research/.
Vgl. Darke, Shanks, Broadbent /Case study/ 273 oder Yin /Case study/ 13.
Vgl. Benbasat, Goldstein, Mead /Case research strategy/ 369f.; Orlikowski, Baroudi /Research approaches/ 4 oder Pettigrew /Field research/ 268.
Vgl. hierzu Darke, Shanks, Broadbent /Case study/ 275 oder Yin /Case study crisis/ 59-61. Speziell zur
Bildung von Theorien auf Basis von Fallstudien siehe auch Eisenhardt /Building theories/ 532-550.
Vgl. Benbasat, Goldstein, Mead /Case research strategy/ 370 und Yin /Case study/ 1.
14
Einführung – Gewähltes Vorgehen zur Beantwortung der Forschungsfragen
können. Um dieses Ziel zu erreichen wird die deskriptive Fallstudien-Methode angewendet.
Dabei wird nicht angestrebt eine generell verallgemeinerbare Aussage zu treffen, wie es
zum Beispiel bei qualitativer Forschung der Fall ist, sondern es geht vielmehr darum
vorliegende Phänomene in ihrem Kontext zu verstehen. Aufbauend auf diesem Verständnis ist es dann möglich Theorien aufzustellen, die qualitativ überprüft werden
können.63
Nachdem nun allgemein die Eignung von Fallstudien zur Untersuchung der vorliegenden Forschungsfragen gezeigt wurde, erfolgt in Kapitel 3.1 eine konkrete Beschreibung
des in der vorliegenden Arbeit angewendeten Fallstudien-Designs.
1.5.4
Zugrundegelegte theoretische Betrachtungsrahmen
Um eine strukturierte Vorgehensweise bei der Erarbeitung der Ergebnisse dieser Arbeit
zu gewährleisten und konkrete Offshore-Projekte systematisch untersuchen zu können,
werden im Wesentlichen zwei Modelle zu Grunde gelegt. Zum einen der „work system
framework“ von Alter64 und zum anderen ein Modell zur Analyse und zum Management von Risiken65, welches auf dem „work system framework“ aufbaut. Diese beiden
Modelle werden im Folgenden näher vorgestellt.
1.5.4.1 „work system“ als Betrachtungsrahmen
Nach Alter ist ein „work system“ ein System in dem Menschen und/ oder Maschinen
Geschäftsprozesse ausüben, um mit Hilfe von Informationen, Technologie und anderen
Ressourcen ein Produkt oder einen Service für einen Kunden zu erzeugen.66
Durch seine Allgemeingültigkeit lässt sich der Betrachtungsrahmen auch auf SoftwareEntwicklungsprojekte wie die Offshore-Entwicklung anwenden und bietet damit in
dieser Arbeit einen Ansatzpunkt für eine systematische Untersuchung.67 Des Weiteren
63
64
65
66
67
Vgl. Walsham /Interpretive case studies/ 79 und Yin /Case study/ 10f.
Vgl. Alter /Work system method/.
Vgl. Alter, Sherer /Model of IS risk/.
Vgl. Alter /Work system method/ 92.
Allerdings ist dieser Betrachtungsrahmen in der Literatur nicht sehr weit verbreitet, doch bei Swanson,
Ramiller /Innovating mindfully/ 561 wird er z. B. aufgegriffen.
15
Einführung – Gewähltes Vorgehen zur Beantwortung der Forschungsfragen
stellt dieser Betrachtungsrahmen die Grundlage des verwendeten Modells zur Analyse
und zum Management von Risiken dar, welches im folgenden Kapitel näher vorgestellt
wird.
Der ursprünglich von Alter präsentierte Betrachtungsrahmen des „work system“ ist
primär auf die Marktentwicklung eines Produktes oder Services ausgelegt. Daher wird
im Kontext dieser Arbeit der ursprüngliche Betrachtungsrahmen wie im Folgenden
dargestellt angepasst. Abbildung Abb. 1-3 zeigt den hier verwendeten modifizierten
Betrachtungsrahmen.
Ursprünglich wird zwischen Kunden und Beteiligten unterschieden. Doch diese Unterscheidung erscheint bei einer Individual-Softwareentwicklung, wie der hier betrachteten
Offshore-Entwicklung, ungeeignet, da sowohl Mitarbeiter des Anbieters als auch Mitarbeiter des Kunden an dem Projekt beteiligt sind. Daher findet sich in dem angepassten
Betrachtungsrahmen nur das Element Beteiligte wieder. Innerhalb dieses Elements lässt
sich dann zwischen Beteiligten des Anbieters und Beteiligten des Kunden unterscheiden.
Das Element „Anbieter- & Kunden-Unternehmen“ wird hingegen dem ursprünglichen
Betrachtungsrahmen hinzugefügt. Mit diesem Element werden die hinter den beteiligten
Personen stehenden Unternehmen dargestellt, um ein umfangreicheres Verständnis des
untersuchten Falls zu vermitteln. Gleichzeitig wird unter dem Element „Anbieter- &
Kunden-Unternehmen“ auf einer abstrakteren Betrachtungsebene auch die Branche des
Anbieters – hier die Branche der Offshore-Dienstleister in Indien – dargestellt.
Anbieter-, Kunden-Unternehmen
Produkt & Services
Geschäftsprozesse
Technologie
Infrastruktur
Abb. 1-3 Der Betrachtungsrahmen „work system“
68
68
In Anlehnung an Alter /Work system method/ 93.
16
Strategie
Umwelt
Beteiligte
Einführung – Gewähltes Vorgehen zur Beantwortung der Forschungsfragen
Eine weitere Änderung gegenüber dem von Alter vorgestellten Betrachtungsrahmen des
„work system“ ist, dass „Information“ nicht mehr als eigenständiges Element aufgefasst
wird. Im Rahmen der vorliegenden Betrachtung wird das Element „Information“ unter
dem Element „Geschäftsprozess“ subsumiert. Nachdem zunächst die einzelnen Elemente in der Tabelle Tab. 1-1 vorgestellt werden, wird erläutert, warum die beiden Elemente
„Information“ und „Geschäftsprozesse“ zusammengefasst wurden.
Die Elemente Geschäftsprozesse, Beteiligte und Technologie bilden den Kern des betrachteten Systems, der maßgeblich zur Erstellung des Produktes/ Services beiträgt.69
Zwischen den insgesamt acht Elementen des Betrachtungsrahmens sind unterschiedliche Beziehungen vorstellbar, doch diese sollen in der Abbildung Abb. 1-3 aus Übersichtsgründen nicht dargestellt werden.70 Die Abbildung Abb. 1-3 spiegelt daher einen
statischen Überblick der Elemente, die auf Grundlage des „work system“Betrachtungsrahmens zur Darstellung einer Offshore-Entwicklung verwendet werden,
wider.71
In Tabelle Tab. 1-1 werden nun alle acht Elemente des Betrachtungsrahmens näher
vorgestellt, indem ihre Ausprägungen im Kontext der Offshore-Entwicklung dargestellt
werden.
Element
des
Models
Infrastruktur
Ausprägung im Kontext
der Offshore-Entwicklung
Nicht projektspezifische technische Hilfsmittel und Personal,
welche zur Projektabwicklung genutzt werden können, deren
Verwaltung bzw. Betreuung aber außerhalb des Projekts liegt.
Hierunter fallen z. B. Firmennetzwerke und deren Administration,
gemeinsame Datenbanken oder auch Schulungspersonal.
Umwelt
Sämtliche Umweltfaktoren des Projekts. Insb. sind hier Besonderheiten der Offshore-Entwicklung hervorzuheben.
Strategie
Strategische Ausrichtung des Anbieters und des Kunden; langfristige Ausrichtung von Handlungen beider Unternehmen.
69
70
71
Vgl. zu diesem Absatz Alter /Work system method/ 92.
Bei Alter /Work system method/ 93 wurden hingegen zum Teil gegenseitige Beziehung zwischen den
Elementen durch Pfeile eingezeichnet; jedoch geschieht dies nicht vollständig.
Im folgenden Kapitel werden diese acht Elemente um weitere Elemente aus einer Risikoperspektive
erweitert.
17
Einführung – Gewähltes Vorgehen zur Beantwortung der Forschungsfragen
Element
des
Models
Beteiligte
Ausprägung im Kontext
der Offshore-Entwicklung
Alle am Projekt beteiligten Personen des Anbieters und des Kunden wie z. B. Teammitglieder oder Projektleiter, unabhängig von
ihrem geografischen Einsatzort.
Technologie
Sämtliche projektspezifische Hard- und Software, die zur Aufgabenerfüllung, Kommunikation und dem Betrieb der zu entwickelnden Software eingesetzt wird.
Geschäftsprozess Ein oder mehrere Geschäftsprozesse dienen dazu, ein Produkt zu
erstellen oder einen Service anzubieten. Dabei kommen diese
Prozesse in sämtlichen Phasen des Projekts von der Anbahnung,
den Vertragsverhandlungen, der Anforderungsanalyse über die
Entwicklung und den Test bis zur Auslieferung der zu erstellenden Software vor. Die Darstellung eines Geschäftsprozesses konzentriert sich in der vorliegenden Arbeit auf die Beschreibung
seiner organisatorischen Gestaltung. Zum Beispiel zählt die
grundsätzliche Unterscheidung in ein Onsite- und Offshore-Team
zum Bereich Geschäftsprozess, da dies als eine aufbauorganisatorische Gestaltung verstanden werden kann.
Produkt &
Einerseits Darstellung ausgelagerter IT-Funktionen und anderer-
Service
seits eine funktionale Sicht auf das zu entwickelnde Softwareprodukt.
Anbieter-,
Die hinter den beteiligten Personen stehenden Unternehmen des
Kunden-
Anbieters und des Kunden werden dargestellt, um ein genaueres
Unternehmen
Verständnis
des
betrachteten
Falls
zu
vermitteln.
Gleichzeitig wird auf einer abstrakteren Betrachtungsebene die
Branche der indischen Offshore-Anbieter dargestellt.
Tab. 1-1 Elemente und ihre Ausprägungen des Betrachtungsrahmens „work system“
Das Element „Geschäftsprozess“ umfasst laut Definition auch organisatorische Gestaltungsbereiche. Diese werden im Kapitel 2.4.1 dargestellt. An dieser Stelle sei nur vorwegzunehmen, dass „Kommunikation“ dabei als ein organisatorischer Gestaltungsbe-
18
Einführung – Gewähltes Vorgehen zur Beantwortung der Forschungsfragen
reich angesehen wird.72 Kommunikation beinhaltet insbesondere den Austausch von
Informationen. Wird dieses Begriffsverständnis vorausgesetzt, deckt „Kommunikation“
vollständig das Element „Information“ ab, sodass eine differenzierte Betrachtung von
„Information“ und „Kommunikation“ als Teil des Elements „Geschäftsprozess“ als
nicht weiter sinnvoll erachtet wird. Daher wird auf diese Trennung im weiteren Verlauf
der Untersuchung verzichtet.
1.5.4.2 Modell zur Analyse und zum Management von Risiken
Neben der Möglichkeit einer systematischen Darstellung einer Offshore-Entwicklung
ist ein weiterer Vorteil für das Aufgreifen des „work system“-Betrachtungsrahmens,
dass auf seiner Basis bereits ein anschauliches Modell zur Analyse und zum Management von Risiken – im Folgenden als Risiko-Modell bezeichnet – existiert,73 welches
sich auch auf die Untersuchungsaspekte der vorliegenden Arbeit anwenden lässt.
Gleichzeitig dient das Risiko-Modell der weiteren Strukturierung dieser Arbeit, sodass
sich einzelne Aspekte des Modells in einzelnen Kapiteln der Arbeit widerspiegeln.
Abbildung Abb. 1-4 zeigt eine grafische Repräsentation des Risiko-Modells.
Risiken
Risiko-Management:
Unfälle…
•
•
Initiale & im Verlauf
Risiko-Identifikation
Risiko-Bewertung
auftretende Risikofaktoren
Produkt & Services
Beteiligte
Geschäftsprozesse
Technologie
Einfluss durch andere
Untersuchtes
Systeme und Projekte
„work system“
Ziele und
Negatives
Finanzieller
Erwartungen
Ergebnis
Verlust
74
Abb. 1-4 Modell zur Analyse und zum Management von Risiken
72
73
74
Im Abschnitt 2.4.9 findet eine umfassendere Erläuterung des Begriffs „Kommunikation“ statt.
Vgl. Alter, Sherer /Model of IS risk/. Diese Untersuchung basiert u. a. auf Grundlage eines Literaturreviews zum Thema „Information System risk“ in den Zeitschriften MISQ, ISR und JMIS.
In Anlehnung an Alter, Sherer /Model of IS risk/ 10.
19
Einführung – Gewähltes Vorgehen zur Beantwortung der Forschungsfragen
Die folgende Tabelle Tab. 1-2 stellt die einzelnen Elemente des Risikomodells vor und
beschreibt die jeweiligen Ausprägungen im Kontext der Offshore-Entwicklung. Des
Weiteren wird festgehalten, an welcher Stelle in der Arbeit das jeweilige Element behandelt wird. Anschließend werden die Zusammenhänge zwischen den Elementen des
Risikomodells, wie in Abbildung Abb. 1-4 durch die Pfeile symbolisiert, erläutert und
so ein Verständnis des Modells vermittelt. Diese Zusammenhänge sind für die vorliegende Arbeit von besonderem Interesse, da mit diesen die statische Sicht des „work
system“ um Ziele und Risiken, die zu einem negativen Projektergebnis führen können,
ergänzt werden.
Es sei noch darauf hingewiesen, dass die hier verwendete Form des Modells den Begriff
„Risiken“ anstelle von „Quelle von Unsicherheiten“ benutzt.75
Element des
Ausprägung im Kontext
Risikomodells
der Offshore-Entwicklung
Ziele und Erwar- Hiermit sind die Ziele und Erwartungen an ein konkretes Offtungen
shore-Entwicklungsprojekt gemeint. Dabei lassen sich grundsätzlich eine Anbieter- und eine Kundenperspektive unterscheiden.
Risiken
Unter einem Risiko wird hier die Gefahr verstanden, dass gesetzte Ziele einer Offshore-Entwicklung nicht erreicht werden. Neben anfänglichen und im Verlauf auftretenden Risikofaktoren76
werden hier auch die Besonderheiten der Offshore-Entwicklung
betrachtet. Auch interne oder externe Ereignisse, Unfälle oder
nicht beeinflussbare Veränderungen der Situation gelten als
Risiko.77
Negative
nisse
Ergeb- Werden ex-ante aufgestellte Ziele und Erwartungen an ein betrachtetes Projekt nicht erreicht, handelt es sich um ein negatives
Ergebnis. In der Regel lassen sich Ursache-Wirkungsketten
dergestalt aufstellen, dass ein negatives Ereignis direkt oder
75
76
77
Vgl. Alter, Sherer /Model of IS risk/ 12.
Eine begriffliche Abgrenzung zwischen Risiko und Risikofaktor erfolgt in Kapitel 2.8.1.
In Kapitel 2.8.1 erfolgt eine Abgrenzung der Begriffe Risiko und Risikofaktor.
20
Einführung – Gewähltes Vorgehen zur Beantwortung der Forschungsfragen
Element des
Risikomodells
Work system
Ausprägung im Kontext
der Offshore-Entwicklung
indirekt einen finanziellen Verlust darstellt.
Es besteht aus acht weiteren Elementen und dient der Darstellung
eines konkreten Offshore-Entwicklungsprojekts. Siehe hierzu
auch Tabelle Tab. 1.1
Risikomanagement Das Risikomanagement umfasst nach verbreiteter Meinung die
Aktivitäten der Risikoidentifikation, der Risikobewertung, Risikohandhabung und Risikoüberwachung.78
Einfluss
andere
durch Erfahrungen, die Beteiligte mit Offshore-Projekten und dem
Systeme jeweils anderen Vertragspartner besitzen, wirken sich auch auf
oder Projekte
nachfolgende Offshore-Projekte aus. Des Weiteren können sich
andere Systeme, die Schnittstellen zum Entwicklungsgegenstand
des betrachteten Projekts besitzen, auf dieses Projekt auswirken.
Tab. 1-2 Elemente und ihre Ausprägungen des Risiko-Modells
Die in Abbildung Abb. 1-4 dargestellten Pfeile repräsentieren Beziehungen zwischen
den jeweiligen Elementen. Ausgangspunkt der Betrachtung stellen die Ziele und Erwartungen des Offshore-Entwicklungsprojekts dar.79 Je nachdem, welche Ziele und Erwartungen in einem Projekt verfolgt werden, haben unterschiedliche Risikofaktoren und
Unsicherheiten eine verschiedene Relevanz. Die angestrebten Ziele und Erwartungen
wirken sich auch auf das „work system“ aus, z. B. welche Geschäftsprozesse gewählt
werden oder welche Technologie zum Einsatz kommt, um diese Ziele und Erwartungen
zu erreichen. Schließlich bilden die verfolgten Ziele und Erwartungen die Grundlage zur
Beurteilung, ob ein erzieltes Ergebnis, welches durch das „work system“ erzeugt wird,
als positiv oder als negativ eingestuft wird. Ein negatives Ergebnis stellt dabei das
Verfehlen anfänglich aufgestellter Ziele und Erwartungen dar. In Abhängigkeit des
aufgestellten Zielsystems lässt sich ein negatives Ergebnis mehr oder weniger direkt als
einen finanziellen Verlust darstellen.
Zwischen den Risiken und dem „work system“ besteht eine bidirektionale Beziehung.
Wenn zum Beispiel ein Risikofaktor „nicht adäquates Entwicklungspersonal“ existiert,
78
79
Vgl. Wallmüller /Risikomanagement/ 18 oder ähnlich bei Boehm /Software risk management/ 34.
Vgl. zu den folgenden Darstellungen des Risiko-Modells Alter, Sherer /Model of IS risk/ 1-28.
21
Einführung – Gewähltes Vorgehen zur Beantwortung der Forschungsfragen
könnte das Eintreten dieses Risikofaktors innerhalb des „work system“ zu einer zeitlichen Verzögerung führen. Durch diese zeitlichen Verzögerungen können dann weitere
Risiken entstehen wie z. B. das Ansteigen von Kosten.
Mit dem Risikomanagement wird versucht auf vorhandene und sich ändernde Risiken zu
reagieren. Das Risikomanagement und das untersuchte „work system“ können sich
gegenseitig beeinflussen. Werden zum Beispiel im Risikomanagement, als Reaktion auf
eine Risiko-Bewertung, konkrete Maßnahmen zu Veränderungen an Geschäftsprozesse
des „work system“ gerichtet, können diese Veränderungen wiederum eine Anpassung
bei der Risiko-Identifikation erforderlich machen, wenn es nun sinnvoll ist andere
Kennzahlen zur Risikoüberwachung zu erheben.
Allgemein kann zwischen dem betrachteten „work system“, hier ein OffshoreEntwicklungsprojekt, und anderen Systemen oder Projekten ein Einfluss bestehen.
Dieser Einfluss kann zum Beispiel die Weitergabe von (Teil-) Ergebnissen oder den
Austausch von Erfahrungen umfassen. Dementsprechend kann ein auftretendes (negatives) Ergebnis auch durch ein anderes als das untersuchte „work system“ beeinflusst
werden.
22
Darstellung der Offshore-Entwicklung – Fokussierung auf relevante Elemente des Betrachtungsrahmens
2. Darstellung der Offshore-Entwicklung
2.1
Fokussierung auf relevante Elemente des Betrachtungsrahmens
Im vorliegenden Kapitel erfolgt eine nicht projektbezogene Darstellung von OffshoreEntwicklungen. Dies dient zum einen dazu Offshore-Projekte möglichst exakt zu charakterisieren und zum anderen wird damit die Erhebung der Fallstudie in Kapitel 3
vorbereitet. Diese Darstellung ist notwendig, um ein Verständnis zu vermitteln, in welchem Kontext die organisatorische Gestaltung eines konkreten Offshore-Projekts stattfindet.
Da es sich an dieser Stelle um eine nicht projektspezifische und eine unternehmensunabhängige Darstellung handelt, wird auf folgende Elemente des „work system“Betrachtungsrahmens und des Risikomodells nicht eingegangen:80
ƒ
Infrastruktur
ƒ
Beteiligte
ƒ
Technologie
ƒ
Einfluss durch andere Systeme und Projekte
Auf das Element Risikomanagement wird an keiner Stelle explizit eingegangen, da der
Fokus der Arbeit auf der Untersuchung der organisatorischen Gestaltung von OffshoreEntwicklungsprojekten liegt. Das Risikomanagement umfasst nach verbreiteter Meinung die Aktivitäten der Risikoidentifikation, der Risikobewertung, Risikohandhabung
und Risikoüberwachung.81 Es lassen sich zwar sicherlich Berührungspunkte zur organisatorischen Gestaltung herstellen, doch im Rahmen dieser Arbeit würde dies über die
verfolgte Zielsetzung hinausführen.
Damit verbleiben die folgenden Elemente, die mit Bezug zur Offshore-Entwicklung im
Folgenden dargestellt werden:
ƒ
Umwelt, Strategie, Geschäftsprozess, Produkt und Service, Anbieter- und Kundenunternehmen, Ziele und Erwartungen, Risiken und negative Ergebnisse
80
81
Um diese Entscheidung vollständig nachvollziehen zu können, müssen die in den Tabellen Tab. 1-1
und Tab. 1-2 aufgeführten Definitionen der einzelnen Elemente berücksichtigt werden. Im Rahmen
der Fallstudien-Untersuchung werden diese Elemente hingegen betrachtet.
Vgl. Wallmüller /Risikomanagement/ 18 oder ähnlich bei Boehm /Software risk management/ 34.
23
Darstellung der Offshore-Entwicklung – Darstellung des Elements Umwelt
2.2
Darstellung des Elements Umwelt
In diesem Kapitel wird das Element Umwelt betrachtet, dabei werden objektiv wahrnehmbare Besonderheiten von Offshore-Entwicklungen gegenüber nationalen Outsourcing- oder Inhouse-Entwicklungen ohne jegliche Wertung oder Diskussion von Konsequenzen dargestellt. Ziel ist es diese Besonderheiten darzustellen, um aufzuzeigen
welche Unterschiede gegenüber anderen Sourcing-Formen82 der Softwareentwicklung
existieren.83
Eine Diskussion über die Konsequenzen dieser Besonderheiten findet erst bei der Betrachtung von Risiken in Abschnitt 2.8.3 statt.
2.2.1
Räumliche Distanz
Zwischen Indien und Deutschland liegen ca. 7.500 km Luftlinie.84 Aufgrund dieser
Entfernung wird der Austausch von physischen Gütern (z. B. gedruckten Handbüchern
oder Computer-Hardware) gegenüber sehr kurzen Entfernungen von wenigen Metern
zeitlich verzögert und teuer. Liegt zwischen zwei Personen eine solche Entfernung ist
ein Kontakt von Angesicht zu Angesicht85 nicht möglich. Höchstens ein Kontakt per
Video-Konferenz ist möglich.86
Zur Überwindung der räumlichen Distanz stehen mehrere Optionen zur Verfügung:
Wenn physische Güter ausgetauscht werden sollen oder ein face-to-face Kontakt zwischen zwei oder mehreren Personen notwendig ist, müssen die Güter transportiert werden oder mindestens eine der beteiligten Personen reisen. Hierbei ist zu beachten, dass
alleine die Flugzeit zwischen Frankfurt am Main (Deutschland) und Bangalore (Indien)
bei einem Nonstop-Flug ca. 9 Stunden beträgt.
82
83
84
85
86
Vgl. zum Begriff der Sourcing-Formen von Softwareentwicklungen Abschnitt 2.3.1.
DeLone u. a. /Boundaries/ 2f. verwenden eine ähnliche Kategorisierung von Besonderheiten, um
Zusammenhänge zwischen IS-Erfolg und globalen Grenzen bei verteilt arbeitenden Teams zu untersuchen. Auch Espinosa u. a. /Team boundary/ 157-190 verwenden eine ähnliche Kategorisierung
von Grenzen bei verteilt arbeitenden Teams.
Zur vereinfachten Berechnung wurde die Entfernung zwischen den Orten Köln (Deutschland, ungefähr
Breitengrad 51° (Nord), Längengrad 7° (Ost)) und Bangalore (Indien, ungefähr Breitengrad 13°
(Nord), Längengrad 78° (Ost)) verwendet.
Im Folgenden wird diese Art des Kontaktes als face-to-face bezeichnet.
„Höchstens“ bezieht sich auf eine Hierarchisierung von Kommunikationskanälen der Media-RichnessTheory nach dem Informationspotential einzelner Kommunikationskanäle, die in Kapitel 2.4.9 näher
vorgestellt wird.
24
Darstellung der Offshore-Entwicklung – Darstellung des Elements Umwelt
Wenn digitale Güter (z. B. Dateien oder Software) ausgetauscht werden sollen, stehen
elektronische Übertragungsformen wie das Internet zur Verfügung. Ist die Kommunikation zwischen zwei oder mehreren Personen nicht auf einen face-to-face Kontakt angewiesen, kann die Kommunikation z. B. per Video-Konferenz, Telefon, Internet-Chat
oder E-Mail erfolgen. Bei dieser Art des Austausches bzw. der Kommunikation spielt
die Entfernung zwischen den beteiligten Personen keine Rolle mehr.
2.2.2
Zeitliche Distanz
Die zeitliche Distanz ist eng mit der räumlichen Distanz verbunden.87 Jedoch sind diese
nicht gleichzusetzen. Die zeitliche Distanz beschreibt die sich überlappenden Arbeitszeiten eines Anbieters und eines Kunden in einer Offshore-Entwicklung. Maßgeblich
wird die zeitliche Distanz durch die Zeitverschiebung der beteiligten Standorte aus
unterschiedlichen Zeitzonen geprägt.
Im Sommer beträgt sie zwischen Indien und Deutschland 3,5 Stunden und im Winter
4,5 Stunden, wobei aus deutscher Sicht die Zeit in Indien „vorgeht“.88
Stellt man die Arbeitszeiten eines indischen und eines deutschen Teams, wie in Abbildung Abb. 2-1 dargestellt, einander gegenüber, ergibt sich unter Berücksichtigung von
Mittagspausen und der Annahme einer täglichen Arbeitszeit von jeweils acht Stunden,
eine Überschneidung der Arbeitszeit von 3,5 Stunden im Sommer und Winter. Weiter
müssen bei der Bestimmung der tatsächlich überlappenden Arbeitszeit auch Unterschiede im Arbeitsbeginn und –ende, Mittagspausen sowie unterschiedliche Feiertage in den
beteiligten Ländern bzw. Regionen berücksichtigt werden.89
Tageszeit in Deutschland (MEZ)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Indien
Deutschland
(Sommer)
Deutschland
(Winter)
Abb. 2-1 Beispielhafte Gegenüberstellung der Arbeitszeiten in Indien und Deutschland
87
88
89
Die Idee eine Unterscheidung zwischen geografischer und zeitlicher Distanz vorzunehmen ist an
Espinosa, Carmel /Dyad model/ 1-10 und Espinosa, Carmel /Impact/ 249-266 angelehnt.
Deutschland liegt in der Zeitzone MEZ (UTC + 1h) bzw. im Sommer MESZ (UTC + 2h) und Indien
liegt in der Zeitzone IST (UTC + 5.30h). Vgl. o. V. /Brockhaus/ Band 10, 453.
Vgl. Kobitzsch, Rombach, Feldmann /Outsourcing/ 81.
25
Darstellung der Offshore-Entwicklung – Darstellung des Elements Umwelt
Generell kann ein Mangel an sich überschneidenden Arbeitszeiten zu vermehrtem Einsatz asynchroner Kommunikation90 führen. Dadurch wächst die Gefahr, dass sich der
Kommunikationsprozess verzögert, wenn zum Beispiel auf eine Antwort aufgrund
unterschiedlicher Arbeitszeiten einen Tag gewartet werden muss.
Im Gegensatz zur räumlichen Distanz stellt die zeitliche Distanz eine asymmetrische
Beziehung dar.91 Denn in Abhängigkeit davon, ob die gemeinsame Arbeitszeit zu Beginn oder am Ende des Arbeitstages einer Person liegt, müssen Aufgaben zwischen
zwei zusammenarbeitenden Personen koordiniert werden, damit möglichst geringe
Wartezeiten entstehen.
2.2.3
Kulturelle Unterschiede
Die folgenden Erläuterungen des Begriffs Kultur sollen darstellen, wo kulturelle Unterschiede zwischen Personen aus unterschiedlichen Kulturkreisen liegen. Bei der hier
betrachteten Offshore-Entwicklung treffen Personen aus den DACH-Staaten und Indien
aufeinander.
Eine in der Literatur verbreitete Definition des Begriffs Kultur stammt von Hofstede:92
„culture is the collective programming of the mind which distinguishes one group or
category of people from another“93. Damit umfasst eine Kultur auch das jeweilige Wertesystem einer Gruppe. Gruppen können zum Beispiel die Familie, Unternehmen, Geschlecht, Religion oder Nationalität sein.
Die Kultur einer Gruppe, zu der ein Individuum gehört, bestimmt sein Verhalten.94
Dabei umfasst Kultur insbesondere Gewohnheiten, Sprache sowie gemeinsame Einstel-
90
91
92
93
94
Z. B. per E-Mail. Eine genauere Darstellung von synchroner und asynchroner Kommunikation befindet
sich in Kapitel 2.4.9.
Vgl. Espinosa, Carmel /Dyad model/ 1 und Espinosa, Carmel /Impact/ 256.
Diese Definition wird z. B. auch bei Chen, Nath /Nomadic culture/ 58; Paul u. a. /Collaborative
conflict management style/ 189 oder Triandis u. a. /Subjective culture/ 4 aufgegriffen und auf ihre
Verbreitung in der Literatur verwiesen. Meyer, Tan /National culture/ 24-32 haben 36 Studien aus
dem Bereich cross-cultural Issues in the IS field untersucht und festgestellt, dass 24 davon auf einige
oder alle der fünf Dimensionen von Hofstede zurückgreifen.
Hofstede /Cultures consequences/ 9.
Vgl. zu diesem und dem folgenden Satz Steinwachs /Information/ 195 und auch Czinkota, Ronkainen,
Moffett /International business/ 37 mit Bezug auf Kohls /Survival kit/.
26
Darstellung der Offshore-Entwicklung – Darstellung des Elements Umwelt
lungen und Empfindungen. Ein wesentliches Merkmal von Kultur ist, dass sie erlernt,
geteilt und von einer Person zur nächsten Person übertragen wird.95
Hofstede hat in einer breit angelegten und häufig zitierten Studie bei IBM fünf Dimensionen von nationaler Kultur untersucht:96
Dimension
Power Distance
Beschreibung
Ausmaß inwieweit weniger mächtige Personen einer Gruppe akzeptieren und erwarten, dass Macht ungleich in dieser
Gruppe verteilt ist.
Uncertainty avoidance
Ausmaß inwieweit Personen eine strukturierte Situation
einer unstrukturierten Situation (= neuartig, unbekannt,
unerwartet, von der Norm abweichend) bevorzugen.
Individualism
Ausmaß inwieweit Personen das Handeln als Individuum
(versus collectivism)
der Zugehörigkeit einer Gruppe bevorzugen.
Masculinity
Ausmaß inwieweit harte Werte (männlich) sich gegenüber
(versus femininity)
weichen Werten (weiblich) behaupten. Diese Dimension
behandelt das Ausmaß geschlechtsspezifischer Rollenunterschiede.
Long-term orientation
Ausmaß inwieweit Handlungen von Personen zukunftsori-
(versus short-term)
entiert gegenüber gegenwartsorientiert sind.
Tab. 2-1 Dimensionen nationaler Kultur nach Hofstede
Als Ergebnis seiner Untersuchung ordnet Hofstede die untersuchten Nationen, darunter
auch Deutschland und Indien, in jeder Dimension auf einer Skala an.97 Es wird dabei
deutlich, dass sich die DACH-Staaten und Indien in allen fünf Dimensionen unterscheiden,98 wobei diese Nationen nie eine extrem gegensätzliche Platzierung auf den Skalen
95
96
97
98
Czinkota, Ronkainen, Moffett /International business/ 37 verweisen auf eine Untersuchung von Kroeber, Kluckhihn /Culture/ in der diese Merkmale als Gemeinsamkeiten von über 160 Definitionen des
Begriffs Kultur erkannt werden.
Vgl. Hofstede /Cultures consequences/ xix-xx und Hofstede /National cultures/ 48-50. Hofstede hat in
zwei Erhebungen (1968 und 1972) über 116.000 Fragebögen bei IBM ausgewertet. Hinweise zur
Verbreitung der Studie s. o.
Vgl. Hofstede /Cultures consequences/ 151, 215, 286, 356 und auch Hofstede /National cultures/ 52.
Dies gilt sowohl für Deutschland - Indien, Schweiz - Indien als auch Österreich - Indien. Insbesondere
Deutschland und die Schweiz wurden in der Untersuchung von Hofstede sehr ähnlich bewertet. Vgl.
hierzu Hofstede /National cultures/ 52.
27
Darstellung der Offshore-Entwicklung – Darstellung des Elements Umwelt
einnehmen. Jedoch bleibt unklar, welche Bedeutung diese Unterschiede im Rahmen
einer Offshore-Beziehung haben könnten und ob diese auch noch im Jahr 2006, über 30
Jahren nach der Untersuchung von Hofstede, eine vergleichbare Ausprägung haben.
Aktuellere Untersuchungen von kulturellen Unterschieden lassen allerdings vermuten,
dass auch weiterhin kulturelle Unterschiede in international operierenden Teams von
Bedeutung sind.99
Im Rahmen einer Offshore-Entwicklung spielen aber nicht nur kulturelle Unterschiede
aufgrund der unterschiedlichen beteiligten Nationen eine Rolle. Bereits innerhalb derselben Nation treten zwischen Unternehmen unterschiedliche Unternehmenskulturen100
auf, die auch im Rahmen einer Offshore-Entwicklung relevant sein können. Eine Unternehmenskultur umfasst gemeinsame Grundauffassungen und Grundüberzeugungen von
Organisationsmitgliedern, um Probleme zu strukturieren und zu lösen.101 Die Unternehmenskultur beeinflusst dabei die Wahrnehmung und die Auseinandersetzung mit
Problemen der Unternehmensumwelt.
Des Weiteren lässt sich Kultur in unterschiedliche zentrale Elemente zerlegen:102
99
ƒ
Sprache
ƒ
Religion
ƒ
Wertvorstellungen und Einstellungen
ƒ
Sitten und Bräuche
ƒ
Materielle Elemente103
Z. B. stellen Herbsleb, Paulish, Bass /Siemens/ 531 im Jahre 2005 eine Fallstudie aus neun Projekten
bei Siemens vor, die Unterschiede zwischen asiatischer, europäischer und amerikanischer Kultur in
Bezug auf die Äußerung von Ablehnungen oder Zustimmungen und in der Art Fragen zustellen aufzeigt. In einer andern Fallstudie in der die Zusammenarbeit zwischen einem deutschen und einem
englischen Software-Entwicklungsteam untersucht wird, werden mehrere kulturelle Unterschiede
erkannt (z. B. direkte Art der Kommunikation der deutschen Teammitglieder, deutsche Teammitglieder hatten ein stärkeres Hierarchiebewusstsein) – vgl. Herbsleb, Grinter /Conway’s law/ 92-93.
100
101
102
103
In der Literatur zum Teil auch als Organisationskultur bezeichnet. Vgl. z. B. Theis-Berglmair
/Organisationskommunikation/ 206.
Vgl. Frese /Grundlagen/ 185 mit Bezug auf Schein /Leadership/. Siehe auch Schein /Culture/ 3.
Diese zentralen Elemente sind den Ausführungen von Czinkota, Ronkainen, Moffett /International
business/ 40-53 entnommen.
Materielle Elemente einer Kultur spiegeln die Verfügbarkeit und das Ausmaß einer wirtschaftlichen,
sozialen und finanzpolitischen Infrastruktur einer Kultur wider. Vgl. Czinkota, Ronkainen, Moffett
/International business/ 50.
28
Darstellung der Offshore-Entwicklung – Darstellung des Elements Umwelt
ƒ
Ästhetik104
ƒ
Bildung
ƒ
Soziale Institutionen
Der bisherige Versuch den Begriff Kultur genauer darzustellen verdeutlicht, dass Kultur
ein sehr vielschichtiges Konstrukt ist, welches nur schwer zu erfassen ist, da es sich um
ein kaum oder gar nicht kodifiziertes Werte- und Regelsystem handelt, das auf unterschiedliche Weise gebildet und geprägt wird. Im Rahmen dieser Untersuchung gilt es
daher grundsätzlich zu berücksichtigen, dass die Kultur einer Person ihre Einstellungen
und Erwartungen gegenüber anderen Personen sowie den Umgang mit anderen Personen prägt. Schließlich ist zu vermuten, dass kulturelle Unterschiede zwischen den beteiligten Personen einer Offshore-Entwicklung bestehen können. Untersuchungen haben
gezeigt, dass diese kulturellen Unterschiede Ursachen für Koordinationsschwierigkeiten
und ineffektive Kommunikation sein können.105
Element von Kultur: Sprache
Da diese Arbeit insbesondere auf Kommunikation zwischen Anbieter und Kunden von
Offshore-Dienstleistungen fokussiert, spielen sprachliche Unterschiede der beteiligten
Personen und ihre Konsequenz eine zentrale Rolle.106 Zusätzlich lassen sich die verwendeten Sprachen objektiv im Rahmen der Fallstudien erheben und Konsequenzen
analysieren. Dabei kann es sich sowohl um verbale, nonverbale als auch geschriebene
Sprache handeln.
Als Ausprägung sind auf der Kundenseite Deutsch als Muttersprache und Englisch als
vermutlich beherrschte Fremdsprache anzusehen. Auf der Anbieterseite ist es weniger
voraussehbar, welche Sprachkenntnisse vorliegen. Hindi gilt zwar in Indien als Amts-
104
105
106
Ästhetik beschreibt ein gemeinschaftliches Verständnis einer Kultur darüber, was unter „gutem
Geschmack“ in Bezug auf Kunst sowie bestimmten Symboliken von Farben, Formen und Musik
verstanden wird. Vgl. Czinkota, Ronkainen, Moffett /International business/ 51.
Hierzu verweisen Powell, Piccoli, Ives /Virtual teams/ 9 in ihrem Literatur-Review auf Untersuchungen von Johansson, Dittrich, Juustila /Boundaries/; Kayworth, Leidner /Global virtual manager/;
Maznevski, Chudoba /Bridging space/; Robey, Khoo, Powers /Learning/; Sarker, Sahay /USNorwegian/ und van Ryssen, Godar /International/.
Auf die Bedeutung sprachlicher Unterschiede im Rahmen einer indisch-europäischen Beziehung wird
auch in Oza u. a. /Critical factors/ 69 verwiesen. Czinkota, Ronkainen, Moffett /International business/ 41 präsentieren Beispiele für Missverständnisse, die auf die Verwendung von englischen bzw.
amerikanischen Ausdrücken mit regional unterschiedlichen Bedeutungen zurückzuführen sind.
29
Darstellung der Offshore-Entwicklung – Darstellung des Elements Umwelt
sprache und Englisch als assoziierte Sprache, doch darüber hinaus sind laut Verfassung
weitere 14 Regionalsprachen anerkannt.107
Element von Kultur: Wertvorstellungen und Einstellungen
Wertvorstellungen sind gemeinsame Überzeugungen oder Gruppennormen, die von
Individuen verinnerlicht worden sind.108 Einstellungen basieren auf diesen Wertvorstellungen. Im Rahmen einer Offshore-Beziehung können sich die zugrunde gelegten Wertvorstellungen der beteiligten Personen in ihrem Umgang miteinander widerspiegeln.
Beispiele hierfür sind:
ƒ
Umgang mit Konflikten
ƒ
Ausmaß der Direktheit bei der Äußerung von Meinungen oder Kritik
ƒ
Ausmaß der Einhaltung von Absprachen oder Terminen
ƒ
Fähigkeit negative Aussagen zu treffen
ƒ
Qualitätsbewusstsein
ƒ
Präferenzen über Umfang und Form (formal oder informal; mündlich oder
schriftlich) der Kommunikation109
Dieses Element von Kultur besitzt einen direkten Bezug zur Kommunikation und Koordination zwischen den beteiligten Personen einer Offshore-Entwicklung. Daher wird es
auch im Rahmen der Fallstudienuntersuchung unmittelbar untersucht.
Weitere Elemente von Kultur sind: Religion, Sitten und Bräuche, materielle Elemente,
Ästhetik, Bildung und soziale Institutionen
Diese Elemente könnten zwar Erwartungen und Verhalten einer Person im Umgang mit
anderen Personen beeinflussen, doch kann diese Beeinflussung kaum direkt erkannt
werden. Daher wird im Rahmen der vorliegenden Fallstudienuntersuchung nur auf die
beiden Elemente von Kultur – Sprache sowie Wertvorstellungen und Einstellungen –
direkt eingegangen. In diesen beiden Elementen spiegeln sich insbesondere die für eine
107
108
109
Vgl. o. V. /Brockhaus/ Band 10, 457.
Vgl. Czinkota, Ronkainen, Moffett /International business/ 47.
Krishna, Sahay, Walsham /Cross-cultural issues/ 64 führen hierzu die Unterschiede zwischen einem
amerikanischen und einem japanischen Kunden gegenüber einem indischen Anbieter auf.
30
Darstellung der Offshore-Entwicklung – Darstellung des Elements Umwelt
organisatorische Gestaltung relevanten kulturellen Einflüsse wider, da sie sich direkt auf
den vorliegenden Kommunikationsprozess auswirken.
Um die organisatorische Gestaltung einer betrachteten Offshore-Entwicklung zu verstehen, ist es nützlich kulturelle Unterschiede zu erkennen und zu beobachten, wie an der
Offshore-Entwicklung beteiligte Personen mit diesen umgehen. Dabei steht nicht im
Vordergrund, generelle kulturelle Unterschiede aufzuzeigen. Daher sollen in der vorliegenden Untersuchung auch nicht die von Hofstede verwendeten fünf Dimensionen von
Kultur erhoben werden, sondern es erscheint ausreichend die Elemente Sprache sowie
Wertvorstellungen und Einstellungen direkt zu erheben, um damit die Art des Umgangs
von an der Offshore-Entwicklung beteiligten Personen zu untersuchen.
Gegen die Erhebung der Dimensionen von Hofstede spricht auch die von Walsham
ausgeübte Kritik an der Eignung dieser fünf Dimensionen zur Untersuchung von Auswirkungen von kulturellen Unterschieden bei der Entwicklung von Informationssystemen.110 Alleine die Ebene der nationalen Kultur sei unangemessen, da eine Nation in
sich heterogen ist. Weiter sei die Übertragung von nationaler Kultur auf arbeitsbezogene
Aktionen und Einstellungen schwierig.
2.2.4
Unterschiede in den Personalkosten
Die Entwicklung von Softwareprodukten erfordert einen umfangreichen Einsatz
menschlicher Arbeitskraft. Daher fällt in der Regel ein Großteil der Entwicklungskosten
auf Gehälter der an der Entwicklung beteiligten Personen.111
Die Senkung der Arbeitskosten stellt damit einen Weg dar, die Entwicklungskosten zu
vermindern.
In Indien sind die Gehälter deutlich niedriger als in den DACH-Staaten oder anderen
westlichen Nationen.112 Die Aussagen, um wie viel tatsächlich die Gehälter in Indien
niedriger sind, schwanken je nach Untersuchung, werden aber zum Beispiel mit 40-80%
niedriger gegenüber Gehältern in Deutschland angegeben.113 Gründe für diese stark
110
111
112
113
Vgl. zu diesem Absatz Walsham /Software production/ 373-377.
Amoribieta u. a. /Programmers/ 130f. geben an, dass Gehaltskosten 75% der gesamten Entwicklungskosten betragen.
Vgl. z. B. Carmel /Global software teams/ 36.
Erläuterungen und Belege zu dieser Spanne werden im nächsten Absatz geliefert.
31
Darstellung der Offshore-Entwicklung – Darstellung des Elements Umwelt
variierenden Angaben sind zum einen die Betrachtung von unterschiedlichen Personengruppen mit jeweils unterschiedlichen Erfahrungen und Tätigkeitsgebieten, unterschiedliche Zeitpunkte der Erhebung sowie unterschiedliche Auffassungen des Begriffs „Gehaltsunterschiede“, da manche Autoren auch Offshore-bedingte zusätzliche Reise- und
Kommunikationskosten berücksichtigen. Weiter können die angegebenen Gehaltsunterschiede aus einem Vergleich zwischen ähnlichen, aber unterschiedlichen Staaten (USA,
England und Deutschland) resultieren.
Die folgenden Daten sollen ein Gefühl für die Gehaltsstrukturen in Indien liefern. Nach
einer Einschätzung von Moczadlo betragen die durchschnittlichen Tagessätze eines
Programmierers in Indien ein Fünftel der Tagessätze in Deutschland.114 Ramarapu,
Parzinger, Lado beziffern die indischen Gehälter auf ein Drittel der Gehälter für ITMitarbeiter in den USA.115 Amoribieta u. a. gehen davon aus, dass indische Entwickler
40-60% weniger Kosten verursachen als ihre Kollegen in den USA oder England.116
Deutsche Bank Research gibt an, dass deutsche bzw. US-amerikanische IT-Mitarbeiter
in einer nicht leitenden Position etwa USD 50-70.000 p. a. verdienen. Gehälter indischer Angestellter mit 1-2 Jahren Berufserfahrung liegen bei etwa USD 8.000 p. a., bei
Berufseinsteigern bei USD 6.500 p. a. und bei Projektmanagern bei ca. USD 31.000 p.
a.117 Gleichzeitig wird von jährlich steigenden Gehältern um 12-15% in Indien ausgegangen.118
Mertens, Groß-Wilde und Wilkens geben an, dass Einstiegsjahresgehälter bei indischen
Softwareunternehmen bei ca. USD 4.500 für die ersten vier Jahre liegen und sich im
fünften Jahr auf USD 12.000 steigern.119 Das Jahresgehalt eines Managers in großen
Projekten oder eines Leiters von größeren Teilbetrieben wird auf USD 100.000 geschätzt.
114
115
116
117
118
119
Vgl. Moczadlo in BITKOM /Leitfaden Offshoring/ 12.
Vgl. Ramarapu, Parzinger, Lado /Issues/ 28 – die Aussage wurde bereits 1997 veröffentlicht und
berücksichtigt bereits erhöhte Kosten für Reisen und Kommunikation bei einer OffshoreEntwicklung. Krepchin /Offshore/ 55f. gibt den Stundenlohn eines Programmierers im Jahr 1993 mit
USD 12-20 in Indien und USD 50-150 in USA an.
Vgl. Amoribieta u. a. /Programmers/ 130f. Chandrasekaran, Ensing /ODC/ 49 geben die Einsparungen
mit 40-50% an.
Vgl. Deutsche Bank Research /Outsourcing/ 5, 10.
Vgl. Deutsche Bank Research /Outsourcing/ 1.
Vgl. hierzu Mertens, Groß-Wilde, Wilkens /(Aus-)Wanderung/ 14.
32
Darstellung der Offshore-Entwicklung – Darstellung des Elements Umwelt
Trotz variierender Aussagen über die tatsächliche Höhe der Gehaltsunterschiede von an
der Entwicklung beteiligten Personen in Indien und in westlichen Staaten wird deutlich,
dass die Gehälter in Indien geringer sind als in den DACH-Staaten.
An dieser Stelle sei allerdings noch darauf hingewiesen, dass ein ausschließlicher Vergleich der Personalkosten zwischen Indien und dem Auftraggeber-Land nicht ausreicht,
um das Einsparpotenzial einer Offshore-Entwicklung gegenüber einer anderen Form der
Entwicklung korrekt darzustellen. Mit einer Auslagerung der Entwicklung nach Indien
sind in der Regel auch zusätzliche Kosten wie zum Beispiel für Kommunikation und
Koordination verbunden.120
2.2.5
Hohe Verfügbarkeit von qualifizierten Arbeitskräften
Insbesondere in Zeiten, in denen ein IT-Fachkräftemangel in Deutschland herrscht
(bzw. herrschte), wird hervorgehoben, dass in Indien eine Vielzahl qualifizierter Arbeitskräfte verfügbar ist.
Argumentiert wird dabei oft mit den hohen Absolventenzahlen indischer Hochschulen.
Die Zahl der Ingenieurstudenten, die jährlich ihren Abschluss in Indien erhalten, wird
mit 75.000121 bis 300.000122 angegeben. Die NASSCOM gibt die Zahl der Absolventen
im Ingenieurwesen für das Jahr 2004 mit 180.000 an.123 Deutsche Bank Research geht
von jährlich 130.000 Absolventen aus, wobei geschätzt wird, dass lediglich 10-20% den
Qualitätsansprüchen internationaler Unternehmen genügen.124 Stephan gibt die Zahl der
indischen Hochschulabsolventen im IT-Bereich mit jährlich 20.000 an.125 Zwar prognostiziert die Deutsche Bank Research, dass in Indien qualifizierter Nachwuchs knapp
wird, doch insbesondere die „großen“ indischen Software-Anbieter126 genießen einen
sehr guten Ruf in Indien und gelten als attraktive Arbeitgeber. So erhält Infosys zum
120
121
122
123
124
125
126
Vgl. hierzu die Hinweise über versteckte Kosten in der Offshore-Entwicklung in Kapitel 2.9.
Vgl. Rohde /Grenzenlose Arbeit/ 613.
Laut eines Interviews mit Nandan Nilekani, Chief Executive Officer (CEO) von Infosys in Prehl
/Offshoring/ 40.
Vgl. NASSCOM /Knowledge professionals/.
Vgl. Deutsche Bank Research /Outsourcing/ 6, 10; Veröffentlichung stammt aus dem Jahr 2005, das
Jahr der Datenerhebung ist allerdings nicht genauer angegeben.
Vgl. Stephan /Schlüsselfaktoren/ 214.
Vgl. hierzu Kapitel 2.6.1.
33
Darstellung der Offshore-Entwicklung – Darstellung des Elements Umwelt
Beispiel jährlich 1.2 bis 1.3 Millionen Bewerbungen,127 aus denen qualifizierte Kandidaten ausgewählt werden können.
Diese Ausführungen zeigen, dass pauschal für Indien nicht von einer hohen Verfügbarkeit von qualifizierten Fachkräften ausgegangen werden kann, da nur schwer abgeschätzt werden kann, wie viele Absolventen jährlich tatsächlich geeignet sind, in einem
internationalen Software-Entwicklungsprojekt mitzuarbeiten. Allerdings wirkt sich die
hohe Zahl an Absolventen tendenziell positiv auf die Verfügbarkeit von geeigneten
Fachkräften für die Offshore-Entwicklung aus. Für eine definitive Aussage muss auch
bekannt sein, wie hoch der Bedarf an Absolventen auf der Nachfrageseite – den Unternehmen in Indien – ist.
2.2.6
Prozessreife nach CMM
Neben den bis hierher aufgeführten Besonderheiten von Offshore-Entwicklungen gegenüber nationalen Outsourcing- oder Inhouse-Entwicklungen ist eine weitere Besonderheit, dass insbesondere indische Unternehmen über eine hohe Prozessreife nach dem
Capability Maturity Model (CMM) verfügen.
Das CMM ist ein Standard für Qualitätsmanagement, der unter anderem in der Softwareentwicklung eingesetzt werden kann.128 Beim CMM handelt es sich um ein Prozessmodell zur Beurteilung der Qualität des Softwareentwicklungsprozesses. Zum
anderen liefert es Vorgaben zur Verbesserung der Qualität des Softwareentwicklungsprozesses. Hierbei stehen fünf Reifestufen (Level) zur Beurteilung zur Verfügung.129
Wenn ein konkretes Unternehmen nach einer hohen Reifegradstufe zertifiziert ist, kann
dies für einen Außenstehenden ein Indikator sein, diesem Unternehmen die Fähigkeit zu
unterstellen, dass es in der Lage ist qualitativ besonders hochwertige Software zu entwickeln und dabei möglichst effizient vorzugehen.130 Hierbei wird die Annahme unter-
127
128
129
130
Laut eines Interviews mit Nandan Nilekani, Chief Executive Officer (CEO) von Infosys in Prehl
/Offshoring/ 40.
Vgl. z. B. Mellis /Projektmanagement/ 154 oder Paulk u. a. /Capability maturity model/ 4-6.
Diese Reifestufen lauten: Level 1: Initial; Level 2: Repeatable; Level 3: Defined; Level 4: Managed;
Level 5: Optimizing. Vgl. Paulk u. a. /Capability maturity model/ 9. Anmerkung: Das CMM für die
Softwareentwicklung hat seinen Nachfolger im CMMI gefunden, doch Angaben durch das SEI über
zertifizierte Unternehmen erfolgen zum gegenwärtigen Zeitpunkt noch auf Basis des CMM. Vgl.
hierzu Erläuterungen unter SEI /Homepage/.
Vgl. hierzu Pfleeger u. a. /Measurement/ 36. Die Autoren werfen allerdings gleichzeitig die Frage auf,
inwieweit eine Zertifizierung nach CMM diese Aussage unterstützt.
34
Darstellung der Offshore-Entwicklung – Darstellung des Elements Umwelt
stellt, dass, je höher die erreichte Reifegradstufe ist, desto hochwertiger das Softwareprodukt wird und desto effizienter die Entwicklung ist.
Die folgenden Ausführungen sollen zeigen, dass insbesondere indische Unternehmen
häufig nach CMM-Level 5 zertifiziert sind und damit den höchsten Reifegrad für Soft-
% derOrganisationen
wareentwicklungsprozesse nach CMM erreicht haben.131
50
40
30
Basis: 1.613 weltweit nach
CMM zertifizierte
Organisationen
20
10
0
Level 1
Level 2
Level 3
Level 4
Level 5
Abb. 2-2 Weltweite Verteilung erreichter CMM-Level
Abbildung Abb. 2-2 zeigt, wie sich 1.613 nach CMM zertifizierte Organisationen auf
die fünf Reifegradstufen verteilen.132 Level 5 haben knapp 10% oder 158 der untersuchten Organisationen erreicht. Über die Internetseite des SEI lassen sich auch landesspezifische Informationen über die Verteilung erreichter Reifegradstufen abrufen.133
Für Indien ergibt sich die in Abbildung Abb. 2-3 dargestellte Verteilung auf die fünf
% derOrganisationen
Reifegradstufen.
40
30
20
Basis: 249 indische nach CMM
zertifizierte Organisationen
10
0
Level 1
Level 2
Level 3
Level 4
Level 5
Abb. 2-3 Verteilung erreichter CMM-Level in Indien
131
132
Vgl. auch Amoribieta u. a. /Programmers/ 132 oder Chandrasekaran, Ensing /ODC/ 49.
Vgl. SEI /SW-CMM September 2005/ 5f. Das Datenmaterial beruht auf Berichten, die dem SEI bis
Juli 2005 eingereicht worden sind und die Reifegrad-Einstufungen im Zeitraum 2001 - Juni 2005 berücksichtigen. Die vorliegenden Daten beziehen sich auf 1.613 Organisationen, wobei eine Organisation ein Unternehmen, eine Abteilung oder eine andere Organisationseinheit sein kann. Diese
1.613 Organisationen gehören zu 860 Unternehmen.
35
Darstellung der Offshore-Entwicklung – Darstellung des Elements Umwelt
Der Vergleich zwischen der weltweiten Verteilung erreichter CMM-Level und der
Verteilung in Indien zeigt eine deutliche Rechtsverschiebung in der Abbildung für
Indien. Bei einer Betrachtung der weltweiten Verteilung ist eine deutliche Häufung bei
Level 2 und 3 zu erkennen. Bei indischen Organisationen findet hingegen das CMMLevel 5 die weiteste Verbreitung.
Abbildung Abb. 2-4 stellt dar, in welchen Ländern nach CMM-Level 4 und 5 zertifizierte Organisationen ansässig sind. Es ist zu erkennen, dass indische Organisationen hier
Anzahl der Organisationen
deutlich dominieren.
100
80
60
CMM-Level 4
40
CMM-Level 5
20
0
Indien
USA
China
Japan
Canada
übrige
Abb. 2-4 Nach CMM-Level 4 und 5 zertifizierte Organisationen nach Ländern
Laut einer Einschätzung von Deutsche Bank Research stammten im Jahr 2003 60 der
weltweit 80 nach CMM-Level 5 zertifizierten Unternehmen aus Indien.134
2.2.7
Rechtliche Aspekte
Neben den bisher aufgeführten Besonderheiten einer Offshore-Entwicklung stellen
rechtliche Aspekte einen weiteren offensichtlichen Unterschied zwischen einer Offshore-Beziehung und einer rein nationalen Outsourcing-Beziehung dar.
Diese rechtlichen Aspekte können sich auf unterschiedliche Bereiche beziehen. Zum
Beispiel können Probleme mit Ausländer-Behörden und der Beschaffung von Visa
entstehen oder unter Umständen bestehen Export-/ Import-Beschränkungen auf be-
133
134
Vgl. hierzu SEI /Interactive maturity profile/.
Vgl. Deutsche Bank Research /Outsourcing/ 6.
36
Darstellung der Offshore-Entwicklung – Darstellung des Elements Strategie
stimmte Software-Tools in einzelnen Ländern.135 Weiter kann es Unklarheiten bei der
Wahrung des Urheberrechts oder des Datenschutzes geben.136
Da sich die vorliegende Arbeit jedoch auf eine organisatorische Betrachtung konzentriert, sollen rechtliche Aspekte im Folgenden nicht weiter vertieft werden.
2.3
Darstellung des Elements Strategie
Die Strategie eines Unternehmens beschreibt, wie langfristig seine Unternehmensziele
erreicht werden sollen. Im Kontext der Softwareentwicklung stellt die Wahl einer Sourcing-Form eine strategische Entscheidung dar. Die wesentlichen Sourcing-Formen
werden im folgenden Abschnitt dargestellt. Anschließend werden Parameter eingeführt,
die Offshore-Beziehungen aus einer strategischen Sicht charakterisieren. Schließlich
erfolgt eine Darstellung von vier Strategien, die Anbieter zur Umsetzung von OffshoreEntwicklungsprojekten verfolgen können.
2.3.1
Grundsätzliche Sourcing-Formen der Softwareentwicklung
Eine Sourcing-Form stellt dar, von welcher Organisation eine bestimmte Unternehmensfunktion erfüllt wird.
Generell lassen sich zwei Sourcing-Formen der Softwareentwicklung gegenüberstellen:
die unternehmensinterne Eigenerstellung von Software und die unternehmensexterne
Auftragsentwicklung (Fremderstellung).137 Abbildung Abb. 2-5 illustriert diese Aufteilung. Zwischen diesen beiden extremen Ausprägungen von Sourcing-Formen existieren
diverse Mischformen, wie sie zum Beispiel bei Joint Ventures entstehen.
135
136
137
Vgl. Battin u. a. /Global software development/ 74f. Der Rechtsanwalt Bräutigam /IT-Outsourcing/
hat einen Sammelband herausgebracht, der sich intensiv mit rechtlichen Aspekten des ITOutsourcings befasst und damit einen Einstieg in diese Thematik liefert.
Vgl. Rao /Key issues/ 17.
Eine Unterteilung in Eigen- und Fremderstellung von Software ist in der Literatur weit verbreitet und
wird z. B. in Balzert /Software-Entwicklung/ 33f., Dibbern /Sourcing/ 13 (hier werden die Begriffe
In-House und Outsourcing verwendet), Mellis /Projektmanagement/ 11 (unternehmensinterne Softwareentwicklung und Auftragsentwicklung) aufgegriffen.
37
Darstellung der Offshore-Entwicklung – Darstellung des Elements Strategie
Sourcing-Form
Eigenerstellung
Auftragsentwicklung
total
Outsourcing
-umfang
selective
Outsourcing
Leistungs
(synonym: Fremdbezug, Outsourcing)
Abb. 2-5 Sourcing-Formen der Softwareentwicklung
Das Outsourcing von Softwareentwicklungen – die Auftragsentwicklung – lässt sich
weiter charakterisieren – zum Beispiel, wie in Abbildung Abb. 2-5 bereits eingezeichnet, nach dem Leistungsumfang der Outsourcing-Beziehung. Der folgende Abschnitt
geht näher auf Parameter zur Charakterisierung von Outsourcing-Beziehungen ein.
Unter einer Outsourcing-Beziehung wird im Folgenden das vertragliche Verhältnis
zwischen einem oder mehreren Anbietern und einem oder mehreren Kunden im Rahmen einer Auftragsentwicklung verstanden.
2.3.2
Parameter zur Charakterisierung von Offshore-Beziehungen
Die folgenden Parameter sind dabei behilflich, eine Outsourcing-Beziehung aus einer
strategischen Perspektive systematisch zu charakterisieren.138
ƒ
Leistungsumfang
Der Leistungsumfang einer Outsourcing-Beziehung kann als „selective“ oder „total“
eingestuft werden.139 Bei Lacity und Hirschheim umfasst eine „total“ OutsourcingBeziehung die Übertragung von Hardware, Personal und Management-Verantwortung,
die zur Erfüllung von IT-Funktionen140 benötigt werden, von einem internen Unterneh138
139
140
Die Parameter Leistungsumfang, Anzahl der Beziehungen, Besitzverhältnisse und Dauer sind an eine
Kategorisierung von Dibbern u. a. /Survey/ 12 angelehnt.
Bei Dibbern u. a. /Survey/ 12 wird hierzu der Begriff „degree“ verwendet. Bei Hermes, Schwarz
/Outsourcing/ 30 wird hingegen der aussagekräftigere Begriff „Leistungsumfang“ verwendet, der
auch hier aufgegriffen werden soll. Der Leistungsumfang einer Auslagerung kann auf einer Skala
von selektiv (oder partiell) bis total (oder full) eingeordnet werden. Siehe hierzu z. B. Küchler
/Grundlagen/ 62-64; Mertens, Knolmayer /Organisation/ 17 oder Schott /Outsourcing/ 51.
In Kapitel 2.5 wird der Begriff IT-Funktion näher dargestellt.
38
Darstellung der Offshore-Entwicklung – Darstellung des Elements Strategie
mensbereich an einen einzelnen externen Anbieter in einem Ausmaß von mehr als 80%
des gesamten IT-Budgets.141 Bei einer selektiven Outsourcing-Beziehung werden zwischen 20% und 80% des zur Verfügung stehenden IT-Budgets intern verwendet. Mit
dem restlichen Budget wird ein oder werden mehrere Anbieter mit einzelnen – selektierten – IT-Funktionen beauftragt.
ƒ
Anzahl Anbieter und Kunden einer Outsourcing-Beziehung
Abhängig von der Anzahl an Anbietern und Kunden, die eine Outsourcing-Beziehung
eingehen, lassen sich die in Tabelle Tab. 2-2 dargestellten Kombinationen unterscheiden.142
Ein Anbieter
Mehrere Anbieter
Ein Kunde
(1:1)
(1:n)
Mehrere Kunden
(m:1)
(m:n)
Tab. 2-2 Anzahl der Beziehungen bei Outsourcing-Beziehungen
ƒ
Besitzverhältnisse des Kunden gegenüber dem Anbieter
Eine Outsourcing-Beziehung lässt sich auch am Grad der rechtlichen Eigenständigkeit
des Anbieters charakterisieren.143 Die erste Möglichkeit ist, dass der Kunde vollständig
den Anbieter besitzt, zum Beispiel in Form eines Tochterunternehmens oder einer Niederlassung. Allerdings widerspricht dies dem in dieser Arbeit zugrunde gelegten
Verständniss des Begriffs Outsourcing.144 Die zweite Möglichkeit besteht darin, dass
der Kunde Anteile am Anbieter besitzt, zum Beispiel in Form eines Joint Ventures. Eine
weitere Möglichkeit stellt die vollständige Eigenständigkeit des Anbieters dar.
ƒ
Dauer der Outsourcing-Beziehung
Die Dauer – gemessen in Monaten – kann ebenfalls verwendet werden um eine Outsourcing-Beziehung zu charakterisieren.
141
142
143
144
Vgl. Lacity, Hirschheim /Outsourcing bandwagon/ 4.
Gallivan, Oh /Analyzing/ 4-6 und 14 stellen diese Taxonomie auf und präsentieren Beispiele sowie
eine Diskussion über Risiken und Vorteile für jede Kategorie.
Vgl. zu diesem Absatz Khan, Currie, Weerakkody /Strategies/ 2; Khan u. a. /Evaluating/ 5f. oder
Kumar, Willcocks /Country/ 1310.
Siehe hierzu Abschnitt 1.1.
39
Darstellung der Offshore-Entwicklung – Darstellung des Elements Strategie
ƒ
Vertragstyp
Ein Offshore-Entwicklungsprojekt kann auf einem der im Folgenden dargestellten
Vertragstypen basieren. In einer Studie über Verträge bei Outsourcing-Beziehungen
wurden sechs unterschiedliche Vertragstypen identifiziert, die in der nachfolgenden
Tabelle dargestellt werden.145
Vertragstyp
Aufwandsorientierte
Beschreibung
Die tatsächlich vom Anbieter verbrauchten Res-
Vergütung
sourcen (z. B. Arbeitsstunden) stellen die Grundlage
(Engl. time and material)
der dem Kunden in Rechnung gestellten Kosten dar.
Festpreis
Vor Projektbeginn wird für die vereinbarte Leistung
(Engl. fixed price)
ein Preis vereinbart.
Festpreis plus
Zusätzlich zum Festpreis werden eventuell auftre-
variable Elemente
tende Vertragsänderungen zusätzlich vergütet.
Kosten plus Gewinnmarge
Die dem Anbieter tatsächlich entstandenen Kosten
werden zzgl. einer prozentualen Gewinnmarge dem
Kunden in Rechnung gestellt.
Gebühr plus Bonus
Zusätzlich zu den anfänglich vereinbarten Vertragskosten erhält der Anbieter Bonuszahlungen, wenn
der Kunde einen höheren Nutzen aus dem Projekt
zieht oder die gelieferte Leistung die vertraglich
vereinbarte Leistung übersteigt.
Teilen von Risiken und Ge- Der Preis, den der Kunde bezahlt, hängt vom
winn
(Miss-)Erfolg des Projekts ab.
Tab. 2-3 Vertragstypen einer Outsourcing-Beziehung
Es ist zu beachten, dass die aufgeführte Abgrenzung der Vertragstypen nicht vollständig
überschneidungsfrei ist und dass im Einzelfall auch eine Kombination aus unterschiedlichen Vertragstypen möglich ist. Dennoch hilft diese Typisierung, eine Vorstellung
über mögliche vertragliche Beziehungen zwischen einem Anbieter und einem Kunden
zu vermitteln.
145
Vgl. Fitzgerald, Wilcocks /Contracts and partnerships/ 93.
40
Darstellung der Offshore-Entwicklung – Darstellung des Elements Strategie
In empirischen Untersuchungen über Outsourcing-Beziehungen werden allerdings
häufig nur die beiden Vertragstypen der aufwandsorientierten Vergütung und des Festpreises unterschieden.146 Auch die indischen Top-Anbieter147 – TCS, Infosys und Wipro
– unterscheiden in ihren Jahresabschlussberichten nur zwischen Festpreis und aufwandsorientierter Vergütung. Abbildung Abb. 2-6 zeigt, welche Umsatzanteile diese
Anbieter mit welchem Vertragstyp im Finanzjahr 2005 erzielt haben.
TCS
Infosys
Wipro
22%
31%
48%
52%
69%
Festpreis
78%
Aufwandsorientiert
148
Abb. 2-6 Umsatzverteilung nach Vertragstyp indischer Top-Anbieter
Neben diesen Parametern wird in der Presse häufig auch der monetäre Umfang von
Outsourcing-Verträgen angeführt, um Outsourcing-Beziehungen zu charakterisieren.149
Der monetäre Umfang beschreibt einen zusammengesetzten Parameter, der unter anderem die Dauer und den inhaltlichen Umfang einer Outsourcing-Beziehung berücksichtigt. Da diese Parameter bereits einzeln betrachtet werden, wird auf den monetären
Umfang in dieser Arbeit nicht weiter eingegangen. Zusätzlich ist diese monetäre Betrachtung eher für eine Marktperspektive als für eine Betrachtung auf Ebene der organisatorischen Gestaltung einer einzelnen Outsourcing-Beziehung relevant.
Bedeutsamer erscheint es, zusätzlich zu den bereits aufgeführten Parametern den Parameter „beteiligte Nationen“ zu betrachten, da sich damit insbesondere OffshoreEntwicklungen von anderen Outsourcing-Beziehungen, zum Beispiel zu einem inländischen oder Near-shore150 Partner, unterscheiden lassen. Die Kenntnis über beteiligte
146
147
148
149
150
Vgl. z. B. Gopal u. a. /Contracts/ 1672.
In Kapitel 2.6.1 werden die größten indischen Anbieter von Offshore-Dienstleistungen vorgestellt.
Die verwendeten Informationen stammen aus den Jahresabschlussberichten der drei Anbieter für das
Finanzjahr 2005. Die Berichte sind auf den Webseiten der Unternehmen verfügbar.
Vgl. z. B. die Rubrik aktuelle „Outsourcing-Deals“ der Computerwoche oder auch Yang, Huang
/Decision model/ 226.
Zum Begriff Near-shore siehe Abschnitt 1.1.
41
Darstellung der Offshore-Entwicklung – Darstellung des Elements Strategie
Nationen gibt auch einen direkten Aufschluss über die geografische Distanz und Zeitunterschiede sowie einen ersten Hinweis über kulturelle Unterschiede zwischen einem
Anbieter und einem Kunden.
Die Tabelle Tab. 2-4 fasst die zuvor eingeführten Parameter zusammen und liefert eine
Charakterisierung der in dieser Arbeit betrachteten Offshore-Entwicklungen.151
Parameter
Leistungsumfang
Ausprägung bei in dieser Arbeit
betrachteten Offshore-Entwicklungen
Selective Outsourcing
Anzahl Anbieter und Kunden 1 Anbieter : 1 Kunde
der Outsourcing-Beziehung
Besitzverhältnisse
Anbieter besitzt vollständige Eigenständigkeit
Dauer
Projektspezifisch
Vertragstyp
Projektspezifisch
Beteiligte Nationen
Kunde:
Deutschland, Österreich oder Schweiz
Anbieter: Indien
Tab. 2-4 Charakterisierung der Sourcing-Form Offshore-Entwicklung im Rahmen dieser Arbeit
2.3.3
Strategien der Anbieter
Vor dem Hintergrund der geografischen Verteilung der Projektmitglieder eines Entwicklungsprojekts lassen sich vier grundsätzliche Strategien von Offshore-Anbietern
abgrenzen, um Offshore-Projekte umzusetzen: Onsite, Offshore, Onsite-Offshore-Mix
und Multi-Site.
ƒ
Onsite
Onsite – das einfachste Offshore-Modell – gleicht dem Vorgehen von Zeitarbeitsfirmen,
die die Arbeitskraft eigener Mitarbeiter an andere Unternehmen verkaufen. Bei diesem
151
Diese Übersicht soll helfen, die in dieser Arbeit betrachteten Offshore-Entwicklungen klar von anderen Sourcing-Formen abzugrenzen. Ein Unternehmen aus einem deutschsprachigen Land, welches
eine Niederlassung in Indien eröffnet soll in dieser Arbeit nicht betrachtet werden. Wobei es denkbar ist, dass erarbeitete Aussagen auch auf andere Formen als die hier betrachteten Konstellationen
der Offshore-Entwicklung übertragbar sind.
42
Darstellung der Offshore-Entwicklung – Darstellung des Elements Strategie
Modell werden für eine befristete Zeit indische Fachkräfte beim Kunden vor Ort eingesetzt.152 Dies wird auch als „Body shopping“ bezeichnet.153
ƒ
Offshore
Bei diesem Modell ist das gesamte Projektteam des Anbieters im (Offshore-)Land des
Anbieters tätig.154
ƒ
Onsite-Offshore-Mix
Dieses Modell wird zurzeit von indischen Anbietern155 häufig eingesetzt.156 Grundgedanke hierbei ist, dass ein kleiner Teil der Projektmitglieder des Anbieters – OnsiteTeam – direkt beim Kunden tätig ist.157 Die übrigen Projektmitarbeiter des Anbieters –
das Offshore-Team – sind im Land des Offshore-Anbieters tätig.
Bei diesem Vorgehen sollen arbeitsintensive Aufgaben, die wenig Kontakt zum Kunden
benötigen, durch das Offshore-Team durchgeführt werden.158 Das Onsite-Team hingegen übernimmt Aufgaben, die eine enge Kooperation mit dem Kunden erfordern. Welche Aufgaben dies sind, muss im Einzelfall entschieden werden.159
ƒ
Multi-Site
Sind mehr als zwei geografisch verteilte Standorte an der Entwicklung beteiligt, kann
dies als „Multi-Site“ bezeichnet werden. Wenn die Aufgaben zwischen diesen Standorten entsprechend verteilt werden, lässt sich damit, unter Ausnutzung unterschiedlicher
152
153
154
155
156
157
158
159
Vgl. Lacity, Hirschheim /IS Outsourcing/ 2 oder Rajkumar, Dawley /Problems and issues/ 370f.
Ein Beispiel hierzu befindet sich in Carmel /Global software teams/ 223.
Vgl. hierzu z. B. Balaji, Ahuja /Team-Level/ 2.
Eine Übersicht indischer Anbieter von Offshore-Dienstleistungen befindet sich in Kapitel 2.6.1.
Z. B. stellt Chandrasekaran, Ensing /ODC/ 48 dieses Modell bei TCS dar und Gopalakrishnan, Kochikar, Yegneshwar /Infosys experience/ 392 stellt es bei Infosys dar.
Vgl. hierzu z. B. Balaji, Ahuja /Team-Level/ 2; Gopalakrishnan, Kochikar, Yegneshwar /Infosys
experience/ 392; Krepchin /Offshore/ 56; Krishna, Sahay, Walsham /Cross-cultural issues/ 62; Patane, Jurison /Global outscourcing/ 9; Rajkumar, Dawley /Problems and issues/ 371 oder Stephan
/Schlüsselfaktoren/ 217.
In Kapitel 2.4.4 werden die unterschiedlichen Teilaufgaben eines Softwareentwicklungsprojekts
dargestellt.
Beispiele werden z. B. hier aufgeführt: Aman, Nicholson /Knowledge transfer/ 9 oder Stephan
/Schlüsselfaktoren/ 217. Bei der fallstudienbasierten Untersuchung der organisatorischen Gestaltung
in Kapitel 3 wird ebenfalls auf diese Thematik eingegangen.
43
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
Zeitzonen in denen die einzelnen Standorte sich befinden, eine Entwicklung rund um
die Uhr realisieren.160 Die Standorte werden bei diesem Vorgehen so gewählt, dass am
Ende des Arbeitstages an einem Standort an einem anderen Standort ein neuer Arbeitstag beginnt. Daher wird dieses Vorgehen auch mit „Follow-the-sun” bezeichnet.161
2.4
Darstellung des Elements Geschäftsprozess
2.4.1
Auswahl relevanter organisatorischer Gestaltungsbereiche
Ein oder mehrere Geschäftsprozesse dienen dazu, ein Produkt zu erstellen oder einen
Service anzubieten. Dabei kommen diese Prozesse in sämtlichen Phasen des Projekts
von der Anbahnung, den Vertragsverhandlungen, der Anforderungsanalyse über die
Entwicklung und dem Test bis zur Auslieferung der zu erstellenden Software vor. Die
Darstellung eines Geschäftsprozesses konzentriert sich in der vorliegenden Arbeit auf
die Beschreibung seiner organisatorischen Gestaltung.
Nach Lang stellen „die Zerlegung einer Gesamtaufgabe in Teilaufgaben sowie deren
Gruppierung und Zuordnung zu organisatorischen Einheiten […] die wesentlichen
Aufgaben der organisatorischen Gestaltung dar“162. Das vorliegende Kapitel stellt einen
Betrachtungsrahmen auf, um die organisatorische Gestaltung von OffshoreEntwicklungsprojekten systematisch untersuchen zu können. Hierzu werden zuerst
notwendige organisatorische Begriffe geklärt, um anschließend ein Set von Gestaltungsbereichen zu unterscheiden. Das hier betrachtete Set an organisatorischen Gestaltungsbereichen ist an Mellis angelehnt163 und wird in den Unterkapiteln dieses Kapitels
näher erläutert. Mellis verwendet zur Darstellung des Projektmanagements in der Softwareentwicklung die organisatorischen Gestaltungsbereiche Spezialisierung, Koordination, Konfiguration, Entscheidungsdelegation, Ablauforganisation, Motivation und
Kommunikation.
160
161
162
163
Vgl. z. B. Chandrasekaran, Ensing /ODC/ 49; Delmonte, McCarthy /Offshore/ 1609; Jalote, Jain /24Hour/ 1-7 oder Khan u. a. /Evaluating/ 3.
Vgl. Carmel /Global software teams/ 25-32 oder Espinosa, Carmel /Dyad model/ 1.
Lang /Organisation/ 147 nach Laux, Liermann /Organisation/ und Meadows /Development/. Auch
Kieser, Kubicek /Organisation/ 96 vertreten diese Ansicht, da sie Arbeitsteilung als das erste und
Koordination als das zweite organisatorische Grundprinzip bezeichnen.
Nach Mellis /Projektmanagement/ 70. Mellis stützt sich bei den von ihm aufgegriffenen Bereichen
maßgeblich auf Kieser, Kubicek /Organisation/.
44
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
Dadurch, dass Mellis eine „interne“ Betrachtung der Softwareentwicklung aus der
Perspektive einer softwareentwickelnden Organisation annimmt und im Rahmen dieser
Arbeit hingegen auf eine Beziehung zwischen einem Kunden und einem Anbieter von
Softwareentwicklungsdienstleistungen fokussiert wird, erscheint es erforderlich, die
Auswahl der organisatorischen Gestaltungsbereiche von Mellis den Bedürfnissen dieser
Arbeit anzupassen. Diese Modifikation wird im Folgenden vorgenommen.
Bei Mellis wird der Bereich „Motivation“ zwar aufgelistet und definiert, jedoch wird
dieser bei ihm nicht weiter betrachtet.164 Auch in dieser Arbeit soll der Motivationsbereich nicht als eigenständiger Bereich betrachtet werden.
Der Bereich der Kommunikation wird zwar bei Mellis definiert,165 doch gleichzeitig
wird er bei ihm nicht als eigenständiger Gestaltungsbereich verwendet. Im Rahmen der
vorliegenden Arbeit hingegen stellt insbesondere die Kommunikation zwischen Offshore-, Onsite-Team und Kundenvertreter einen zentralen Untersuchungsgegenstand dar,
sodass die Kommunikation als eigenständiger Bereich betrachtet wird.
Bei der Spezialisierung findet eine Aufteilung von Aufgaben statt. Dadurch ergibt sich
die Notwendigkeit, die einzelnen Teilaufgaben gegenseitig abzustimmen.166 Diese
Abstimmung wird als Koordination bezeichnet.167 Ziel der Koordination ist es, Einzelaktivitäten von Personen in einem arbeitsteiligen System auf ein übergeordnetes Gesamtziel auszurichten.168 Es besteht zwar ein enger Bezug zwischen Koordination und
Kontrolle – dieser wird im Kapitel 2.4.3 dargestellt – doch im Rahmen dieser Arbeit
erscheint es hilfreicher, eine Kontrollperspektive anstatt einer Koordinationsperspektive
zu verfolgen. Eine Begründung dieser Entscheidung erfolgt ebenfalls in Kapitel 2.4.3.
164
165
166
167
168
Vgl. Mellis /Projektmanagement/ 72f.
Vgl. Mellis /Projektmanagement/ 73.
Vgl. hierzu Kieser, Kubicek /Organisation/ 74 und 95, Mellis /Projektmanagement/ 71 oder Frese
/Grundlagen/ 69.
In diesem Sinne bezeichnen auch Malone, Crowston /Coordination/ 90 sehr allgemein Koordination
als das Managen von Abhängigkeiten zwischen Aktivitäten.
Vgl. Frese /Grundlagen/ 10.
45
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
Hiermit ist die Auswahl der in dieser Arbeit zu betrachtenden organisatorischen Gestaltungsbereiche abgeschlossen. Sie umfasst:169
ƒ
Spezialisierung
ƒ
Kontrolle
ƒ
Konfiguration
ƒ
Ablauforganisation
ƒ
Kommunikation
Mit dieser Auswahl ist die Grundlage für ein Betrachtungs- und Analyseraster der organisatorischen Gestaltung von Offshore-Entwicklungen aufgestellt, das in den folgenden
Kapiteln detaillierter vorgestellt wird.
2.4.2
Begriffsklärung – Organisation
Dieser Abschnitt dient dazu, für die folgenden Ausführungen ein gemeinsames Verständnis grundlegender Begriffe zu schaffen. Daher wird darauf verzichtet, eine breite
Diskussion über die unterschiedliche Verwendung der Begriffe in der Literatur zu liefern. Vielmehr ist es die Absicht definitorisch festzulegen, wie die verwendeten Begriffe im Kontext der vorliegenden Arbeit zu verstehen sind.
Organisation
Organisationen stellen Ressourcenpools dar.170 Ressourcen können dabei sowohl monetäre Größen als auch Arbeitskraft oder bestimmte Rechte umfassen. Organisationen
bezeichnen „soziale Gebilde, die dauerhaft ein Ziel verfolgen und eine formale Struktur
aufweisen, mit deren Hilfe Aktivitäten der Mitarbeiter171 auf das verfolgte Ziel ausgerichtet werden sollen“172.
169
170
171
172
Da ein enger Zusammenhang zwischen Weisungsbefugnis (wird in der Konfiguration behandelt) und
Entscheidungsdelegation besteht, wird auf die Entscheidungsdelegation im Rahmen der Fallstudienuntersuchung nicht isoliert eingegangen. Vgl. hierzu auch 2.4.7.
Dieses Begriffsverständnis ist an Kieser, Kubicek /Organisation/ angelehnt. Vgl. insbesondere Kieser,
Kubicek /Organisation/ 1-25. Eine breite Diskussion über den in der Literatur zum Teil unterschiedlich verwendeten Organisationsbegriff findet sich z. B. in Lang /Organisation/ 71-82.
Mitarbeiter werden im Kontext dieser Arbeit synonym mit Organisationsmitgliedern verstanden, da
mit Organisation hier Unternehmen bezeichnet werden.
Kieser, Kubicek /Organisation/ 4. Kieser, Kubicek gehen sehr detailliert auf diese Aussage ein und
liefern eine umfangreiche Definition. Für die vorliegende Arbeit soll die aufgeführte Begriffsklärung
46
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
2.4.3
Beziehung zwischen Koordination und Kontrolle
In der angelsächsischen Literatur zur Organisationslehre findet der Begriff „Controlling“ eine weite Verwendung.173 Die folgenden Ausführungen sollen zeigen, dass ein
enger Bezug zwischen Kontrolle (engl. Controlling) und Koordination besteht.
In dieser Arbeit wird der Begriff Controlling in die deutsche Sprache mit dem Begriff
Kontrolle übersetzt und verwendet. Allerdings wird hierbei unter Kontrolle keine reine
Unterstützungsaufgabe im Rahmen der Softwareentwicklung verstanden, bei der nur ein
Vergleich zwischen geplanten und tatsächlichen Zielwerten stattfindet.174
Bei dem hier verwendeten Verständnis von Kontrolle geht es im Wesentlichen um eine
aktive Steuerung von Organisationsmitgliedern. Kontrolle umfasst dabei alle Bestrebungen um sicherzustellen, dass die Mitglieder einer Organisation so handeln, dass die
Ziele der Organisation erreicht werden.175
Koordination hat das Ziel, Einzelaktivitäten von Personen in einem arbeitsteiligen
System von Teilaufgaben, die aufgrund von Spezialisierungen entstanden sind, gegenseitig abzustimmen, um eine übergeordnete Aufgabe – ein bestimmtes Ziel – zu erreichen.176
Regelungen die dazu eingesetzt werden, werden als Koordinationsinstrumente bezeichnet.177 In der Literatur werden unterschiedliche Gruppen von Koordinationsinstrumenten (= Koordinationsmechanismen) verwendet:178
nicht weiter detailliert werden, da sie für ein gemeinsames Begriffsverständnis als ausreichend angesehen werden kann.
173
174
175
176
177
178
Vgl. z. B. Kirsch /Complex tasks/ 1; Kirsch /Portfolios/ 217 oder Nidumolu, Subramani /Managing
software development/ 160.
Vgl. zu dieser Begriffsauffassung z. B. Mellis /Projektmanagement/ 64.
Vgl. Kirsch /Complex tasks/ 1 oder Kirsch /Portfolios/ 215 und 217. Kontrolle wird demnach verstanden als Kontrolle über etwas oder jemanden zu besitzen.
Vgl. hierzu Carmel, Agarwal /Global software development/ 23; Frese /Grundlagen/ 10, 69; Kieser,
Kubicek /Organisation/ 74, 95 oder Mellis /Projektmanagement/ 71.
Vgl. Kieser, Kubicek /Organisation/ 95f.
Lang /Organisation/ 195 verweist in diesem Zusammenhang auf mehrere Autoren. Weitere Beispiele
finden sich in Adler /Interdepartmental interdependence/ 152; Grinter, Herbsleb, Perry /Geography/
314; Herbsleb, Grinter /Conway's law/ 64-66; Sabherwal /Evolution/ 156f., 158 oder Thompson
/Organizations/ 56.
Vgl. für die hier aufgeführte Einteilung Kieser, Kubicek /Organisation/ 103. Auch Mellis
/Projektmanagement/ 142-159 greift auf diese Einteilung zurück und lieferte eine Diskussion über
Vor- und Nachteile der einzelnen Mechanismen im Kontext der Softwareentwicklung. Kieser, Kubicek /Organisation/ 96 verwenden die Begriffe Mechanismus und Instrument synonym. Letztendlich
47
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
ƒ
Koordination durch persönliche Weisungen
ƒ
Koordination durch Selbstabstimmung179
ƒ
Koordination durch Programme
ƒ
Koordination durch Pläne
Diese beiden Definitionen verdeutlichen, dass Kontrolle und Koordination das gleiche
Ziel verfolgen, nämlich einzelne Handlungen auf ein gemeinsames Ziel auszurichten.
Daher kann der Kontrolle auch eine koordinierende Aufgabe zugeschrieben werden.
Lediglich in den Perspektiven der beiden Ansätze sind Unterschiede erkennbar. Koordination wird begründet durch eine verrichtungs- oder produktbezogene Arbeitsteilung
und fokussiert daher stärker auf einzelne Arbeitspakte.180 Diese Perspektive bietet sich
daher insbesondere für eine interne Betrachtung von Softwareentwicklungen an.
Die Kontroll-Perspektive bietet sich hingegen insbesondere für Softwareentwicklungen
im Rahmen einer Auftraggeber-Auftragnehmer-Beziehung an,181 da hier stärker auf
beteiligte Personen fokussiert wird, um diese zu steuern, zu überwachen und zu belohnen oder zu sanktionieren.182 Insbesondere Möglichkeiten zur Belohnung und Sanktionierung in Abhängigkeit vom jeweiligen Zielerreichungsgrad finden sich bei der Kontroll-Perspektive wieder, weniger aber bei der Koordinations-Perspektive.
Die eingesetzten Instrumente zur Ausrichtung von Handlungen auf ein übergeordnetes
Ziel können hingegen in beiden Perspektiven identisch sein. Zum Beispiel lassen sich
Regeln und Vorschriften sowohl als Koordination durch Programme als auch als Mechanismus von Kontrolle ansehen.183
Im Abschnitt 2.4.5 erfolgt eine genauere Darstellung von Kontrollmechanismen.
lässt sich diese Kategorisierung auf Thompson /Organizations/ 56 aus dem Jahre 1967 zurückführen.
Hier werden die Koordinationsmechanismen Standardisierung, Pläne und Termine sowie gegenseitige Abstimmung unterschieden.
179
180
181
182
183
Bei Nidumolu /Comparison/ 80 und auch bei Nidumolu /Performance risk/ 194f. wird die Koordination durch persönliche Weisung und durch Selbstabstimmung mit vertikaler und horizontaler Koordination bezeichnet.
Vgl. Kieser, Kubicek /Organisation/ 80 und Mellis /Projektmanagement/ 80.
Hierzu zählen auch die in dieser Arbeit betrachteten Offshore-Entwicklungen.
Vgl. hierzu Kirsch /Complex tasks/ 4 oder Kirsch /Portfolios/ 219, 223.
Vgl. hierzu Kirsch /Portfolios/ 217 und Ausführungen im 2.4.5.2. Carmel, Agarwal /Global software
development/ 23 bemerken, dass „coordination and control have in many ways blended together”.
48
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
2.4.4
Organisatorischer Gestaltungsbereich der Spezialisierung
2.4.4.1 Spezialisierungen in der Softwareentwicklung
Aufgrund der Größe der betrachteten Entwicklungsprojekte von mehreren MannMonaten184 und einer Vielzahl unterschiedlicher, zum Teil wissensintensiver Aufgaben
entsteht die Notwendigkeit, die Gesamtaufgabe der Softwareentwicklung in Teilaufgaben zu zerlegen.185 Tabelle Tab. 2-5 liefert einen Überblick dieser Teilaufgaben. Dabei
lassen sich grundsätzlich Entwicklungsaufgaben gegenüber Unterstützungsaufgaben
abgrenzen.186 Unterstützungsaufgaben haben einen Querschnitts-Charakter, da sie parallel zu den Entwicklungsaufgaben durchgeführt werden.
Teilaufgaben der Softwareentwicklung
Konzeption
Analyse
Entwicklungsaufgaben
Design (Grob- und Feinentwurf)
Implementierung
Abnahme und Einführung
Qualitätssicherung
Unterstützungsaufgaben
Konfigurationsmanagement
Dokumentation
Projektmanagement
187
Tab. 2-5 Teilaufgaben der Softwareentwicklung
Bei der Zuteilung einzelner Teilaufgaben zu Personen oder organisatorischen Einheiten
entsteht eine Spezialisierung einzelner Personen auf bestimmte Tätigkeiten. Unter einer
organisatorischen Einheit werden sowohl Stellen als auch Abteilungen verstanden.188
184
185
186
187
Im Rahmen des Projektmanagements stellt der „Mann-Monat“ eine Größe dar, mit der die zur Aufgabenerfüllung benötigte Arbeitszeit der beteiligten Person quantifiziert wird. Ein Mann-Monat lässt
sich dabei in Arbeitsstunden umrechnen. Z. B. 1 Mann-Monat = 40 Stunden*4 Wochen = 160 Stunden. Vgl. Boehm /Software engineering economics/ 59 – hier wird ein Mann-Monat mit 152 Arbeitsstunden angenommen.
Vgl. zu diesem Absatz Mellis /Projektmanagement/ 70 und auch allgemein zur Spezialisierung im
Rahmen einer organisatorischen Strukturierung Kieser, Kubicek /Organisation/ 74f.
Vgl. hierzu z. B. Lang /Organisation/ 34 und Mellis /Projektmanagement/ 64.
In Anlehnung an Lang /Organisation/ 34 und Mellis /Projektmanagement/ 64.
49
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
Die Begriffe Arbeitsteilung und Spezialisierung sind eng miteinander verknüpft. Kieser
und Kubicek bezeichnen „die Spezialisierung [als] eine bestimmte Form der Arbeitsteilung“189.
2.4.4.2 Fokussierung auf relevante Aufgaben eines Offshore-Lebenszyklus
An dieser Stelle soll zuerst ein Überblick über sämtliche Aufgaben eines OffshoreLebenszyklus vermittelt werden, um dann gezielt auf ausgewählte Aufgaben zu fokussieren, die zur Erarbeitung des Forschungsziels relevant sind. Dieses Vorgehen soll
helfen, die untersuchten Aufgaben einer Offshore-Entwicklung in ihrem Gesamtkontext
einordnen zu können.
Aus der Sicht eines Kunden lässt sich die Auslagerung bestimmter Unternehmensfunktionen im Rahmen einer Offshore-Beziehung in einzelne Aufgaben untergliedern. Abbildung Abb. 2-7 stellt diese Aufgaben dar.
Entscheidung
über
Auslagerung
Entscheidung die
Beziehung
zu erneuern
Anbieterauswahl
Bewertung
Vertragsverhandlungen
Durchführung
und Beziehung
190
Abb. 2-7 Offshore Aufgaben
Die weißen Pfeile mit den grauen Umrandungen der Abbildung Abb. 2-7 stellen Aufgaben dar, die außerhalb der Betrachtungen dieser Arbeit liegen. Dazu gehört die Auswahl
188
189
In Anlehnung an Kieser, Kubicek /Organisation/ 80 bezeichnet eine Stelle Aufgabenkomplexe für
einzelne Personen. Abteilungen ihrerseits umfassen mehrere Stellen.
Kieser, Kubicek /Organisation/ 75.
50
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
von Anbietern, Vertragsverhandlungen zwischen Anbieter und Kunde, die abschließende Bewertung einer Auslagerung und die sich daran anschließende Entscheidung die
Offshore-Beziehung zu erneuern.
Die beiden Aufgaben die mit grau hinterlegten Pfeilen in der Abbildung Abb. 2-7 sind
für die Beantwortung der Forschungsfrage191 von hoher Bedeutung und werden daher
detailliert im Rahmen dieser Arbeit untersucht.
Die Aufgabe „Entscheidung über eine Auslagerung“ wird aber nur als Teilaspekt berücksichtigt, da nicht alle Aspekte der Aufgabe für diese Arbeit relevant sind. Die Frage
ob und ggf. welche Unternehmensfunktionen ausgelagert werden sollen, wird in dieser
Arbeit nicht weiterverfolgt.192 Vielmehr wird angenommen, dass bereits die Entscheidung getroffen ist ein Softwareentwicklungsprojekt von einem indischen Anbieter
entwickeln zu lassen. Diese Arbeit konzentriert sich auf die Betrachtung von Risiken
und der verfolgten Ziele von Auslagerungen, die im Rahmen dieser Aufgabe erfolgen.
Die Aufgabe „Durchführung und Beziehung“ erstreckt sich im Laufe eines OffshoreProjekts über den längsten Zeitraum. Hier erbringt der Anbieter die zuvor vereinbarten
Leistungen. In diesem Zeitraum stellt der Anbieter Informationen über den aktuellen
Projektfortschritt bereit, liefert eventuell fertig gestellte Teilprodukte oder Prototypen
aus und erhält darüber Feedback vom Kunden, weiter kann der Kunde unter Umständen
seine Anforderungen genauer spezifizieren. Insbesondere werden in diesem Zeitraum
die in Tab. 2-5 dargestellten Teilaufgaben der Softwareentwicklung durchgeführt. Dieser Zeitraum wird intensiv bei der Fallstudienuntersuchung in Abschnitt 3 betrachtet.
2.4.5
Organisatorischer Gestaltungsbereich der Kontrolle
2.4.5.1 Grundzüge der Kontrolle
Kontrolle wird in dieser Arbeit verstanden als eine aktive Steuerung von Organisationsmitgliedern.193 Kontrolle umfasst dabei alle Bestrebungen um sicherzustellen, dass
die Mitglieder einer Organisation so handeln, dass die Ziele der Organisation erreicht
190
191
192
193
In Anlehnung an Ilie, Parikh /Process view/ 3562.
Vgl. hierzu Abschnitt 1.4.3.
Diese Fragestellung ist eng mit einer traditionellen „make-or-buy“-Entscheidung verbunden. Ein
Überblick mit Fokus auf IS-Outsourcing liefert z. B. Dibbern u. a. /Survey/ 24.
Zur Begriffsdefinition siehe Kapitel 2.4.3.
51
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
werden.194 Im Rahmen der Betrachtung von Offshore-Entwicklungsprojekten sind
insbesondere die Steuerungsmöglichkeiten des Kunden gegenüber Mitarbeitern des
Anbieters von Interesse.
Kontrollmechanismen stellen eine abstrakte Möglichkeit dar, die Handlungen einzelner
Mitglieder einer Organisation zu steuern. Kontrollinstrumente hingegen sind konkrete
Ausprägungen einzelner Mechanismen, wobei ein Instrument auch die Wirkungsweise
von mehr als einem Mechanismus unterstützen kann. So können zum Beispiel Pläne
sowohl eine konkrete Vorgehensweise und damit ein bestimmtes Verhalten als auch
Ergebnisse vorgeben.
Die folgenden Ausführungen werden dies näher erläutern. Dazu erfolgt im ersten Schritt
eine Kategorisierung von Kontrollmechanismen, um diese im Rahmen der FallstudienUntersuchung in Kapitel 3 systematisch untersuchen zu können. Anschließend werden
einzelne Kontrollinstrumente aufgeführt.
2.4.5.2 Kontrollmechanismen und Kontrollinstrumente
Eine elementare Kategorisierung stellt die Unterscheidung zwischen formalen und
informalen Kontrollmechanismen dar.195
Formale Kontrolle wird allgemein als eine Strategie der Leistungsüberwachung verstanden196 und lässt sich weiter in die Kontrollmechanismen „Behavior Control“ und
„Outcome Control“ differenzieren.197
Bei Behavior Control werden Regeln und Verfahren vorgegeben und ihre Einhaltung
überwacht, um das Verhalten der betroffenen Organisationsmitglieder so zu beeinflussen, dass die verfolgten Ziele erreicht werden.198 Bei Outcome Control werden hingegen
konkrete Ziele vorgegeben und deren Erreichung überprüft.
194
195
196
197
198
Vgl. Kirsch /Complex tasks/ 1 oder Kirsch /Portfolios/ 215, 217.
Diese Unterscheidung geht auf Jaworski /Theory/ 26 zurück und wird u. a. von Choudhury, Sabherwal /Control/ 293f.; Kirsch /Complex tasks/ 2f. und Kirsch /Portfolios/ 217f. aufgegriffen.
Vgl. Eisenhardt /Control approaches/ 135.
Vgl. Kirsch /Portfolios/ 217. Kirsch greift dabei auf Eisenhardt /Agency theory/ 59f. und Ouchi
/Conceptual framework/ 833-848 zurück. Da die englischen Begriffe eine weite Verbreitung in der
Literatur haben, wird in dieser Arbeit auf eine Übersetzung verzichtet.
Vgl. zu diesem Absatz Kirsch /Portfolios/ 217.
52
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
Informale Kontrolle wird als eine Strategie verstanden, bei der versucht wird die Interessensunterschiede der beteiligten Organisationsmitglieder zu minimieren.199 Informale
Kontrolle ist in der Regel undokumentiert und bezieht sich stärker auf soziales Verhalten als formale Kontrolle.200 Hier soll in Anlehnung an Kirsch informale Kontrolle in
die beiden Kontrollmechanismen „Clan Control“ und „Self Control“ differenziert werden.201
Clan Control setzt auf die Veröffentlichung von gemeinsamen Werten und Anschauungen innerhalb eines Clans, um diesen zu steuern.202 Dabei wird ein Clan als Gruppe von
Individuen verstanden, die voneinander abhängen und gemeinsame Ziele verfolgen.
Im Rahmen von Self Control setzt sich ein Individuum selbst Ziele für eine bestimmte
Aufgabe, wählt eine Vorgehensweise zur Zielerreichung und überwacht die Erreichung
der Ziele eigenständig, um eine entsprechende Sanktionierung oder Belohnung auszuführen.203
Choudhury und Sabherwal greifen die vorgestellten Kontrollmechanismen in ihrer
empirischen Untersuchung auf und wenden sie auf die IT-Outsourcing-Situation an.204
Zum einen konnten sie bestätigen, dass bei ausgelagerten Entwicklungen, genau wie bei
internen Entwicklungen, nicht nur ein bestimmter Kontrollmechanismus angewendet
wird, sondern ein Portfolio aus unterschiedlichen Mechanismen.205 Gleichzeitig konnten
sie auch Unterschiede im Einsatz von Kontrollmechanismen zwischen den beiden Situationen nachweisen. So wird der Einsatz von Behavior Control durch die beschränkten
Möglichkeiten des Kunden die Mitarbeiter des Anbieters zu beobachten erschwert.206
Auch die Anwendung von Clan Control wird in Outsourcing-Situationen erschwert, da
diese die Existenz gemeinsamer Ziele und Wertvorstellungen des Anbieters und des
Kunden voraussetzt.
199
200
201
202
203
204
205
206
Vgl. Eisenhardt /Control approaches/ 135.
Vgl. Jaworski /Theory/ 27.
Vgl. Kirsch /Portfolios/ 217.
Vgl. hierzu Ouchi /Conceptual framework/ 386f.
Vgl. Kirsch /Portfolios/ 218 mit Bezug auf Erez, Kanfer /Role/ 459f. und Manz, Mossholder, Luthans
/Self-control/. Vgl. auch Manz, Sims /Self-management/ 362.
Vgl. Choudhury, Sabherwal /Control/ 291-314.
Vgl. Kirsch /Portfolios/ 233 und für den weiteren Absatz Choudhury, Sabherwal /Control/ 310f.
Vgl. hierzu auch Kirsch /Portfolios/ 217.
53
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
Die Tabellen Tab. 2-6 und Tab. 2-7 stellen Kontrollinstrumente für die vier vorgestellten Kontrollmechanismen im Rahmen einer Outsourcing-Beziehung dar und geben an,
welches Ziel mit ihrem Einsatz verfolgt wird.207
Kontrollmechanismus
Kontrollinstrument und Ziel
Formale Kontrolle
Behavior Control
Ziele: - Kunde gibt Regeln, Prozesse vor, die der Anbieter befolgt
- Verhalten des Anbieters direkt überwachen
ƒ
ƒ
ƒ
Mitarbeiter des Kunden besuchen regelmäßig den Anbieter
Mitarbeiter des Anbieters arbeiten vor Ort beim Kunden
Walk-throughs (Inspektionen) durch den Kunden während und
nach der Entwicklung
ƒ Telefon-Konferenzen
ƒ Regelmäßige Berichte (wöchentlich, monatlich)
ƒ Kunde gibt Entwicklungsmodelle, Programmierrichtlinien oder
andere Vorgehensweisen vor
Ziele: - Messbare Ergebnisse vorgeben
- Einzelne Ergebnisse überprüfen
Outcome Control
ƒ
ƒ
ƒ
ƒ
(Zwischen-)Ergebnisse werden schriftlich vorgegeben und ihre
Einhaltung überprüft
o Funktionale Spezifikation
o Performance-Anforderungen
o Design-Dokumente
o Projektplan, Projektzeitplan
Regelmäßige Auslieferung von Softwareversionen
(z. B. wöchentlich, 14-tägig)
Kunde führt Softwaretests durch
Kunde führt zusätzliche Analysen durch
Tab. 2-6 Beispiele für formale Kontrollinstrumente in Outsourcing-Beziehung
207
Die aufgeführten Instrumente lehnen sich an eine Untersuchung von Choudhury, Sabherwal /Control/
305 an und sollen beispielhaft illustrieren, welche Instrumente denkbar sind.
54
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
Clan Control
Self Control
Informale Kontrolle
Kontrollmechanismus
Kontrollinstrument und Ziel
Ziele: - Gemeinsame Ziele des Anbieters und des Kunden etablieren
- Gemeinsame Wertvorstellungen aufbauen
ƒ
Anbieter-Team besucht den Kunden, um dessen Kultur zu verstehen
ƒ Gemeinsame regelmäßige Treffen; Dinner Meetings
ƒ Telefon-Konferenzen
Ziele: - Kunde möchte Anbieter motivieren Self Control auszuüben
- Kunde möchte die internen Kontrollmöglichkeiten des Anbieters verbessern.
ƒ
ƒ
Kunde empfiehlt einzelne Vorgehensweisen z. B. für Softwaretests
Kunde überwacht Mitarbeiter des Anbieters
Tab. 2-7 Beispiele für informale Kontrollinstrumente in Outsourcing-Beziehung
2.4.6
Organisatorischer Gestaltungsbereich der Konfiguration
Während Spezialisierung und Koordination – bzw. Kontrolle – grundlegende Mechanismen einer Organisationsstruktur darstellen, beschreibt die Konfiguration die äußere
Form eines Stellengefüges.208
Die Konfiguration umfasst dabei alle Regelungen, mit denen Weisungsbefugnisse festgelegt werden.209 Weisungsbefugnisse legen eine hierarchische Beziehung zwischen
den auf verschiedene Teilaufgaben spezialisierten Stellen fest. Eine hierarchisch übergeordnete Stelle hat dabei das Recht, eine untergeordnete Stelle anzuweisen, welche
Aktivitäten zu erfüllen sind.
Üblicherweise werden Konfigurationen grafisch in Form von Organigrammen abgebildet.210 In der Literatur werden im Kontext einer Konfiguration unterschiedliche Systeme
208
209
210
Vgl. Kieser, Kubicek /Organisation/ 126. Mit Organisationsstruktur wird die Zusammenfassung aller
Regelungen zur Arbeitsteilung und zur Koordination in einer Organisation bezeichnet. Mit Hilfe von
Organisationsstrukturen wird das Verhalten einzelner Mitarbeiter auf Organisationsziele ausgerichtet. Vgl. hierzu Kieser, Kubicek /Organisation/ 10, 18.
Vgl. zu diesem Absatz Mellis /Projektmanagement/ 71.
Vgl. z. B. Kieser, Kubicek /Organisation/ 126.
55
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
(Ein- und Mehrliniensysteme), Stellen (Linien- und Stabsstellen) und Vorgehen bei der
Abteilungsbildung (verrichtungsorientiert, kundengruppenorientiert) unterschieden.211
An dieser Stelle soll hierauf allerdings nicht vertiefend eingegangen werden, da dieser
Abschnitt einen Betrachtungsrahmen für die organisatorische Gestaltung von OffshoreEntwicklung liefern soll. Eine detaillierte Vorstellung dieser Konfigurationen im Allgemeinen ist für das Erreichen des Gesamtziels der Arbeit nicht notwendig, da der
Fokus im Wesentlichen auf Schnittstellen zwischen Anbieter und Kunden einer Offshore-Entwicklung liegt.
2.4.7
Organisatorischer Gestaltungsbereich der Entscheidungsdelegation
Entscheidungsbefugnisse beschreiben „das Recht, zukünftige Sachverhalte für die
Organisation nach innen und/oder außen verbindlich festzulegen“212.
Die Ausstattung einzelner Instanzen mit einem bestimmten Umfang an Entscheidungsbefugnissen wird als Entscheidungsdelegation bezeichnet.
Das Ausmaß der Entscheidungsdelegation nimmt ein Kontinuum zwischen zwei Extrema an.213 Zum einen handelt es sich um eine weitgehende Entscheidungsdelegation
(Entscheidungsdezentralisierung), bei der hierarchisch untergeordnete Einheiten einen
möglichst großen Entscheidungsspielraum besitzen. Zum anderen handelt es sich um
einen weitgehenden Verzicht auf Entscheidungsdelegation (Entscheidungszentralisation). In diesem Fall werden Entscheidungen auf einer hierarchisch möglichst hohen
Ebene getroffen.
Es besteht eine enge Beziehung zwischen Weisungsbefugnissen, die in der Konfiguration festgehalten werden, und Entscheidungsbefugnissen,214 denn Weisungen basieren
stets auf Entscheidungen.215 Daher wird im Rahmen der Fallstudien-Untersuchung die
Entscheidungsdelegation nicht separat dargestellt, sondern im Zusammenhang mit der
Konfiguration. Damit soll eine nachvollziehbare und redundanzfreie FallstudienUntersuchung ermöglicht werden.
211
212
213
214
215
Vgl. hierzu z. B. Kieser, Kubicek /Organisation/ 126-138 oder Mellis 161-167.
Kieser, Kubicek /Organisation/ 153.
Diese beiden Extrema sowie damit verbundene Vor- und Nachteile werden bei Mellis
/Projektmanagement/ 175-179 diskutiert. Siehe hierzu auch Kieser, Kubicek /Organisation/ 157.
Vgl. Mellis /Projektmanagement/ 173.
Vgl. Kieser, Kubicek /Organisation/ 153f.
56
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
2.4.8
Organisatorischer Gestaltungsbereich der Ablauforganisation
Die zeitliche und räumliche Anordnung der Teilaufgaben sowie deren Aggregation zu
(Geschäfts-)Prozessen wird mit der Ablauforganisation beschrieben.216 Damit wird
festgelegt, wie Ziele der Organisation von organisatorischen Einheiten erreicht werden
können. Die Ablauforganisation stellt daher im Vergleich zur Aufbauorganisation eine
eher dynamische Betrachtungsweise dar. Die Aufbauorganisation kann auch als Zusammenfassung von Spezialisierung, Konfiguration und Entscheidungsdelegation verstanden werden.
2.4.9
Organisatorischer Gestaltungsbereich der Kommunikation
Allgemein bezeichnet Kommunikation den Austausch von Informationen zwischen
einer übermittelnden (Sender) und einer empfangenden Einheit (Empfänger).217 In der
Literatur werden unterschiedliche Perspektiven des Kommunikationsbegriffes verfolgt.218 Eine wesentliche Unterscheidung ist dabei eine eher technische von einer eher
sozialen Perspektive. Bei einer technischen Perspektive wird Kommunikation als reiner
Informationsaustausch verstanden.219 Im Rahmen dieser Arbeit steht die Untersuchung
der organisatorischen Gestaltung und damit auch die Kommunikation zwischen Menschen im Vordergrund, daher ist ein rein technisches Begriffsverständnis von Kommunikation zu eng gefasst und nicht angemessen. Vielmehr wird hier die eher soziale
Perspektive des Kommunikationsbegriffs vertreten.
Diese Perspektive verbindet mit Kommunikation neben dem Austausch von Informationen auch ein soziales Verhalten der beteiligten Personen.220
216
217
218
219
220
Vgl. zu diesen und den folgenden Absatz Mellis /Projektmanagement/ 72 und auch Frese
/Grundlagen/ 7.
Vgl. hierzu Frese /Grundlagen/ 12. Auch Boland, Tenkasi /Communities of knowing/ 352; Lenke, Lutz,
Sprenger /Grundlagen/ 18 und Theis-Berglmair /Organisationskommunikation/ 30 stellen dieses
Kommunikationsmodell vor und verweisen auf dessen Ursprünge aus der mathematischen Informationstheorie bei Shannon, Weaver /Mathematical theory/.
Vgl. z. B. Theis-Berglmair /Organisationskommunikation/ 30-52, hier wird insb. die Unterscheidung
einer mechanistischen und einer psychologischen Perspektive diskutiert. Bei Lang /Organisation/
188 wird eine eher technische von einer eher sozialen Begriffsaufassung differenziert. Bei Schneider
/Lexikon der Informatik/ 464f. wird zwischen einer datentechnischen und einer zwischenmenschlichen Kommunikation unterschieden.
Vgl. z. B. Hansen, Neumann /Wirtschaftsinformatik I/ 411.
Vgl. Lang /Organisation/ 189.
57
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
Eine verbreitete Erweiterung des ursprünglichen Kommunikationsmodells von Shannon
und Weaver stellt die „media richness theory“221 dar.222 Hierbei werden insbesondere
die Aspekte der Mehrdeutigkeit und der Unsicherheit bei Kommunikation eingeführt.223
Mehrdeutigkeit bezeichnet dabei die unterschiedliche Interpretation der übermittelten
Information bei Empfänger bzw. Sender. Mit Unsicherheit wird das Fehlen von Informationen ausgedrückt. Daft, Lengel und Trevino stellen dar, dass bei unterschiedlichen
Situationen bestimmte Kommunikationsmedien (synonym: Kommunikationsformen)
geeigneter sind als andere.224 Dabei unterscheiden sie Kommunikationsmedien anhand
ihrer „media richness“ – in die deutsche Sprache lässt sich dieser Begriff mit „Informationspotential“ übersetzen.225
Das Informationspotential bewegt sich dabei auf einem Kontinuum von „hoch“ bis
„niedrig“. Veranschaulicht wird dies durch Tabelle Tab. 2-8, in der Kommunikationsmedien mit den höchsten, niedrigsten und dazwischen liegenden Informationspotentialen aufgezeigt werden.
Informationspotential
Kommunikationsmedium
(media richness)
Hoch
Face-to-face
Video-Konferenzen
Telefon
Schriftliche, adressierte Dokumente (Notizen, Briefe)
Niedrig
Unadressierte
Dokumente
(amtliche Bekanntmachungen)
226
Tab. 2-8 Informationspotentiale (media richness) von Kommunikationsmedien
221
222
223
224
225
226
Maßgeblich wurde diese Theorie von Daft begründet. Vgl. Daft, Lengel /Media richness/; Daft,
Lengel /Richness/ und Daft, Lengel, Trevino /Media selection/.
Vgl. Fulk /Social construction/ 932, Theis-Berglmair /Organisationskommunikation/ 334-340 und
Trittmann /Wirtschaftlichkeit/ 86.
Vgl. Daft, Lengel /Media richness/.
Vgl. Daft, Lengel, Trevino /Media selection/ 361-363.
Vgl. Theis-Berglmair /Organisationskommunikation/ 335.
In Anlehnung an Daft, Lengel, Trevino /Media selection/ 358.
58
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
Die Kategorisierung in unterschiedliche Informationspotentiale basiert dabei auf vier
Kriterien:227
ƒ
Feedback
Möglichkeiten für sofortige Rückfragen durch den Empfänger von Informationen.228
ƒ
Vielfalt des Übertragungskanals
Die Informationsübermittlung kann in unterschiedlicher Weise unterstützt werden. Z. B. durch physische Anwesenheit, Tonfall, Körpersprache, Wörter, Zahlen oder grafische Symbole.
ƒ
Interpretationsspielraum von Sprache
Die Bedeutung von sprachlichen Symbolen kann variieren. Zahlen gelten dabei
als präziser als natürliche Sprache, wobei Letztere eher geeignet ist Konzepte
und Ideen zu vermitteln.
ƒ
Persönlicher Fokus
Möglichkeit Informationen einer vorliegenden Situation anzupassen.
Die „media richness theory“ ist für die Betrachtungen der vorliegenden Arbeit interessant, da sie unterschiedliche Kommunikationssituationen unterscheidet und durch die
Einführung des Konzepts von Informationspotentialen einen Anhaltspunkt für eine
systematische Untersuchung der Kommunikation von Offshore-Entwicklung liefert.
An dieser Stelle sollte allerdings auch darauf hingewiesen werden, dass um die „media
richness theory“ eine kontroverse Diskussion entstanden ist, da empirische Studien
existieren, die zeigen, dass E-Mail, als ein Medium mit geringem Informationspotential,
effektiv dazu genutzt werden kann reichhaltige Information zu übermitteln und damit
scheinbar im Widerspruch zur „media richness theory“ steht.229 Hierbei werden insbe-
227
228
229
Vgl. Daft, Lengel, Trevino /Media selection/ 358.
In einer Arbeit von Karolak /Global software development/ 15 erfolgt eine Einteilung von Informationsmedien in die Kategorien real time, near-real time, non-real time. Dies wird hier mit Möglichkeiten zum Feedback abgedeckt.
Huang, Watson, Wei /E-mail/ 269 verweisen auf Untersuchungen von Chidambaram /Relational
development/; Fulk /Social construction/; Markus /Information richness theory/; Walther /Relational
aspects/ und Zack /Communication mode/. Auch hier findet eine kontroverse Diskussion statt Lee
/Rich communication/; Markus /Electronic mail/; McDonough, Kahn, Griffin /Managing communication/ 380 und Ngwenyama, Lee /Communication richness/.
59
Darstellung der Offshore-Entwicklung – Darstellung des Elements Geschäftsprozess
sondere situative und soziale Aspekte betrachtet, die in der ursprünglichen „media
richness theory“ nicht umfassend beachtet werden.230
Dennoch stellen die Kriterien zur Kategorisierung unterschiedlicher Informationspotentiale ein verbreitetes und fundamentales Instrument zur systematischen Analyse von
beobachteten Kommunikationsflüssen dar. Daher können die Kriterien zur Kategorisierung von Informationspotentialen in der Fallstudienuntersuchung angewendet werden.
Darüber hinaus gilt es zu ermitteln, ob die stattgefundene Kommunikation von Beteiligten des Entwicklungsprojekts als geeignet eingeschätzt wird und wie diese Einschätzung zustande kommt. Damit wird auch der in der Literatur geführten Diskussion über
Mängel der „media richness theory“ gerecht, da situationsspezifisch die Eignung der
gewählten Kommunikation untersucht wird.
2.4.10 Beziehungen zwischen organisatorischen Gestaltungsbereichen
Um ein umfassenderes Verständnis der vorgestellten organisatorischen Gestaltungsbereiche zu vermitteln, soll an dieser Stelle noch explizit darauf hingewiesen werden, dass
zwischen den einzelnen Gestaltungsbereichen Beziehungen bestehen, sodass eine gegenseitige Beeinflussung stattfinden kann. Ein Verständnis dieser Beziehungen hilft, die
in der Fallstudienerhebung gesammelten Informationen zu interpretieren, da zum Teil
die jeweiligen Ausprägungen der einzelnen Gestaltungsbereiche nicht direkt beobachtbar sind.
Wie bereits erwähnt, besteht eine enge Beziehung zwischen Weisungsbefugnissen, die
in der Konfiguration festgehalten werden, und Entscheidungsbefugnissen. Denn Weisungen basieren stets auf Entscheidungen. Auch auf Zusammenhänge zwischen Ablauforganisation und Koordination – bzw. Kontrolle – wurde bereits hingewiesen.
Eine bedeutende Rolle im Rahmen der vorliegenden Arbeit stellt der Gestaltungsbereich
Kommunikation dar, da dieser gewissermaßen eine Querschnittsfunktion übernimmt.
Zum einen wird Kommunikation ein koordinierender Charakter zugeschrieben,231 zum
230
231
Z. B. beurteilen McDonough, Kahn, Griffin /Managing communication/ 380 Kommunikationsmedien
anhand der Kategorien „speed, richness“ und „volume“.
Vgl. Espinosa, Carmel /Impact/ 254f.; Lang /Organisation/ 190f.; Malone, Crowston /Coordination/
99f. oder March, Simon /Organizations/ 162.
60
Darstellung der Offshore-Entwicklung – Darstellung des Elements Produkt und Service
anderen wird die Kommunikationsintensität wesentlich durch aufbauorganisatorische
Regelungen, insbesondere die Bildung von organisatorischen Einheiten, beeinflusst.232
Daher wird die Kommunikation im Rahmen der Fallstudienerhebung intensiv betrachtet, um darüber auch Erkenntnisse über Ausprägungen anderer organisatorischer Gestaltungsbereiche zu erlangen.
2.5
Darstellung des Elements Produkt und Service
Das Element Produkt und Service stellt zum einen dar, welche IT-Funktionen im Rahmen einer Offshore-Entwicklung ausgelagert werden und zum anderen erfolgt bei einer
Betrachtung konkreter Projekte, wie sie im Kapitel 3 vorgenommen wird, eine funktionale Beschreibung des jeweils entwickelten Softwareprodukts.
Der Begriff (IT-)„Funktion“ wird hier der Organisationslehre entnommen. Bei einer
funktionalen Betrachtung von Organisationen beschreibt eine Funktion einzelne Aufgaben, die wahrgenommen werden, um die Zweckerfüllung einer Unternehmung sicherzustellen.233
Mit Bezug auf die in einem Unternehmen eingesetzte Informationstechnologie (IT)
lassen sich unterschiedliche Aufgaben abgrenzen, die als IT-Funktion bezeichnet werden. Diese unterschiedlichen IT-Funktionen können grundsätzlich durch das jeweilige
Unternehmen selbst oder im Rahmen einer Outsourcing-Beziehung durch einen externen Anbieter erbracht werden. Stahlknecht und Hasenkamp führen zum Beispiel folgende IT-Funktionen auf, die ausgelagert werden können: Netzmanagement, Bereiche
des Rechenzentrumsbetriebs wie etwa Server- und Speichermanagement, Benutzerservicezentrum und der Betrieb von IT-Anwendungssystemen, dazu zählen die Modelle
Application Service Providing (ASP) oder Application Hosting.234 Eine weitere ITFunktion stellt die Softwareentwicklung dar.235 Hierbei geht es um die Entwicklung
neuer und die Wartung bestehender Anwendungssysteme. Die Zielsetzung der vorlie232
233
234
235
Vgl. Lang /Organisation/ 79.
Vgl. hierzu Schreyögg /Organisation/ 5. Schreyögg sieht dabei die Ursprünge einer funktionalen
Betrachtung durch Fayol /Administration/ begründet.
Vgl. hierzu Stahlknecht, Hasenkamp /Wirtschaftsinformatik/ 452f. Dort findet auch eine umfassendere Beschreibung der aufgeführten Bereiche statt.
Vgl. Stahlknecht, Hasenkamp /Wirtschaftsinformatik/ 459-465. An dieser Stelle sei darauf hingewiesen, dass die Begriffe Systementwicklung und Softwareentwicklung hier synonym verwendet werden.
61
Darstellung der Offshore-Entwicklung – Darstellung des Elements Produkt und Service
genden Arbeit fokussiert auf Offshore-Entwicklung, womit der Prozess zur Softwareentwicklung verstanden wird, der im Rahmen eines Offshoring stattfindet.236
Softwareentwicklungsprojekte lassen sich weiter in vier Entwicklungsarten unterteilen:237
ƒ
Neuentwicklungen, bei denen Softwareprodukte neu entstehen
ƒ
Wartungen (engl. Maintenance), bei denen existierende Softwareprodukte von
Fehlern bereinigt oder um kleinere Funktionen erweitert werden (bei umfangreicheren Erweiterungen ist eher von einer Neuentwicklung zu sprechen)
ƒ
Re-Engineering Projekte, bei denen die Funktionen eines existierenden Softwareproduktes für eine neue Plattform entwickelt werden
ƒ
Projekte zur kundenspezifischen Anpassungen von Standardsoftware (engl.
Customizing). Als Beispiel sind hier SAP-Module vorstellbar, die an existierende Systeme und Prozesse eines Unternehmens angepasst werden.
236
237
Vgl. zur Begriffsabgrenzung Kapitel 1.1 und zur Zielsetzung Kapitel 1.4.
Hinweis: Bei den Ausführungen dieser Arbeit handelt es sich stets um kundenindividuelle Entwicklungen oder Anpassungen. Die Entwicklung von Standardsoftwareprodukten für einen Markt wird
hier nicht betrachtet. Dies entspricht auch der Motivation der vorliegenden Arbeit aus Kapitel 1.3
und dem Kapitel 1.4.
62
Darstellung der Offshore-Entwicklung – Darstellung des Elements Anbieter- und Kundenunternehmen
2.6
Darstellung des Elements Anbieter- und Kundenunternehmen
Das Element Anbieter- und Kundenunternehmen stellt die hinter den beteiligten Personen stehenden Unternehmen dar, um ein genaueres Verständnis konkreter OffshoreEntwicklungsprojekte zu vermitteln. Auf einer nun folgenden abstrakteren Betrachtungsebene wird hingegen insbesondere die Branche der indischen Offshore-Anbieter
dargestellt. Diese Darstellung soll helfen die Bedeutung der indischen Softwarebranche
einschätzen zu können.
2.6.1
Anbieterunternehmen
Ein historischer Überblick über die Entstehung der indischen Offshore-Entwicklung
wurde bereits in Kapitel 1.2 dargestellt. An dieser Stelle folgt nun ein Überblick über
den indischen Markt der Anbieter von Offshore-Dienstleistungen.238
Der Umfang der indischen Exporte von IT-Dienstleistungen und Softwareprodukten ist
in der Zeit von 2000 bis 2005 stetig gewachsen, wie auch Abbildung Abb. 2-8 zeigt.
Die Wachstumsraten für diesen Zeitraum lagen jährlich zwischen 14% und 55%.
USD Mrd.
14
12
10
8
6
4
2
0
3,4
5,3
6,2
7,1
9,2
12,2
1999-00
2000-01
2001-02
2002-03
2003-04
2004-05
239
Abb. 2-8 Wachstum der indischen Exporte von IT-Dienstleistungen und Softwareprodukten
Zum einen wurde das Wachstum der indischen Softwarebranche durch die starke wirtschaftliche Liberalisierung Indiens Mitte der 1980er und insbesondere ab 1991 gefördert.240 Zum anderen unterstützt die indische Regierung seit dieser Zeit die gesamte
238
239
240
Eine kompakte Beschreibung der indischen Software Branche bis zum Jahr 2001 befindet sich bei
Moitra /India/ 77-80. Auch Deloitte & Touche /Outsourcing/ liefern eine kompakte Darstellung indischer Anbieter von Offshore-Dienstleistungen basierend auf Datenmaterial aus dem Jahr 2002.
Vgl. NASSCOM /Facts/; die Angaben beziehen sich stets auf die genannten Finanzjahre. Vgl. hierzu
auch Deutsche Bank Research /Outsourcing/ 1.
Vgl. o. V. /Brockhaus/ Band 10, 458 und auch Clott /Perspectives/ 157f.
63
Darstellung der Offshore-Entwicklung – Darstellung des Elements Anbieter- und Kundenunternehmen
indische IT-Branche stark. Ein Beispiel hierfür ist der Aufbau von Technologie Parks,
in denen Raum für Bürogebäude geschaffen und eine stabile Infrastruktur angeboten
wird.241 Des Weiteren gewährt die indische Regierung den Unternehmen Steuerersparnisse und schafft Grundlagen durch internationale Handelsabkommen.
Tabelle Tab. 2-9 zeigt die umsatzstärksten indischen Exporteure von ITDienstleistungen und Softwareprodukten aus dem Finanzjahr 2004-05.
Rang
Unternehmen
Export in USD Mill.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Tata Consultancy Services Ltd. (TCS)
Infosys Technologies Ltd.
Wipro Technologies
Satyam Computer Service Ltd.
HCL Technologies Ltd.
Patni Computer Systems Ltd.
i-flex Solutions Ltd.
Mahindra British Telecom Ltd.
Polaris Software Lab Ltd.
Perot Systems TSI (India) Ltd.
Hexaware Technologies Ltd.
Larsen & Toubro Infotech Ltd.
MASTEK Ltd.
iGate Global Solutions Ltd.
Siemens Information System Ltd.
1.644
1.502
1.198
745
588
342
245
202
154
145
129
123
121
118
111
242
Tab. 2-9 Top 15 der indischen Exporteure von IT-Dienstleistungen und Softwareprodukten, 2004-05
Im Folgenden wird kurz die Entwicklung der drei Top-Unternehmen des Rankings
(TSC, Infosys und Wipro) aus Tabelle Tab. 2-9 vorgestellt, um das rasante Wachstum
dieser Unternehmen zu veranschaulichen. Diese drei Unternehmen vereinen für das
Finanzjahr 2004-05 zusammen bereits ein Drittel der gesamten indischen Exporte von
IT-Dienstleistungen und Softwareprodukten.
Die Abbildung Abb. 2-9 spiegelt die Entwicklung der Mitarbeiterzahlen der drei Unternehmen wider und zeigt, dass die Belegschaft jährlich um 20% - 60% kontinuierlich
wächst. Auch die Umsätze der drei Unternehmen sind in dem betrachteten Zeitraum
kontinuierlich gestiegen, wie in der Abbildung Abb. 2-10 gezeigt wird.
241
242
Vgl. hierzu Bharati /Indias IT services industry/ 73.
Vgl. NASSCOM /Top 20/.
64
Anzahl Mitarbeiter
Darstellung der Offshore-Entwicklung – Darstellung des Elements Anbieter- und Kundenunternehmen
70.000
60.000
50.000
40.000
30.000
20.000
10.000
0
Infosys
TCS
Wipro
2001-02
2002-03
2003-04
2004-05
2005-06
243
Umsatz in USD Mrd.
Abb. 2-9 Entwicklung der Anzahl Mitarbeiter der indischen Top 3 Offshore-Anbieter
3,5
3
2,5
2
1,5
1
0,5
0
Infosys
TCS
Wipro
2001-02
2002-03
2003-04
2004-05
2005-06
244
Abb. 2-10 Umsätze der indischen Top 3 Offshore-Anbieter pro Geschäftsjahr
2.6.2
Kundenunternehmen
Einen Eindruck, welche Branchen eine Auslagerung von IT-Funktionen an einen Offshore-Dienstleister betreiben, liefert eine Verteilung der Umsätze auf einzelne Branchen
der drei indischen Top-Anbieter für Offshore-Dienstleistungen. Diese sind in Abbildung
Abb. 2-11 dargestellt.
243
244
Alle Angaben stammen aus den Quartalsberichten oder den jährlichen Geschäftsberichten des jeweiligen Unternehmens. Diese werden auf den Internetseiten der einzelnen Unternehmen veröffentlicht.
Alle Angaben stammen aus den Quartalsberichten oder den jährlichen Geschäftsberichten des jeweiligen Unternehmens. Diese werden auf den Internetseiten der einzelnen Unternehmen veröffentlicht.
Zur besseren Vergleichbarkeit wurden die Angaben, sofern nicht direkt in USD angegeben, von indischen Rupee in USD umgerechnet. Dabei wurden die folgenden Umrechnungskurse verwendet:
2001-02 (0,209), 2002-03 (0,208), 2003-04 (0,223) und 2004-05 (0,232).
65
TCS
11%
13%
8%
4%
0%
24%
Infosys
Andere
Energie,
Versorger
Einzelhandel
Fertigung
Telekomunikation
Banken und
Versicherungen
0%
Transport und
Logistik
11%
3%
3%
10%
10%
7%
12%
14%
19%
12%
20%
18%
30%
19%
16%
23%
40%
35%
38%
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
Wipro
Abb. 2-11 Prozentuale Verteilung der Branchenumsätze der indischen Top 3 Offshore-Anbieter im
245
Geschäftsjahr 2004-05
Die Abbildung Abb. 2-11 zeigt, dass insbesondere Banken und Versicherungen sowie
Telekommunikationsunternehmen auf die Leistungen der indischen Top-Anbieter von
Offshore-Dienstleistungen zurückgreifen.246
2.7
Darstellung des Elements Ziele und Erwartungen
In diesem Kapitel wird zuerst allgemein auf die Bedeutung von Zielen in der Softwareentwicklung eingegangen, um dann mit Hilfe eines Literatur-Reviews typische Ziele
einer Offshore-Entwicklung zu identifizieren. Es ist anzunehmen, dass sowohl Anbieter
als auch Kunden unterschiedliche und gegebenenfalls sogar gegensätzliche Ziele mit
Offshore-Entwicklungsprojekten verfolgen.247 Daher wird hier zwischen Zielen des
Anbieters und Zielen des Kunden unterschieden.
245
246
247
Die Datenbasis dieser Darstellung ist den Jahresberichten zum Finanzjahr 2004-05 der Unternehmen
Infosys, TSC und Wipro entnommen.
Zu dieser Einschätzung gelangt auch eine Marktanalyse von Deloitte & Touche. Vgl. Deloitte &
Touche /Outsourcing/ 11.
Vgl. z. B. Schott /Outsourcing/ 7.
66
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
2.7.1
Bedeutung von Zielen der Softwareentwicklung
Grundsätzlich lassen sich Fundamental- und Instrumentalziele unterscheiden.248 Fundamentalziele werden um ihrer selbst willen verfolgt. Instrumentalziele werden verfolgt,
da vermutet wird, dass ihre Erfüllung sich positiv auf die Erfüllung der angestrebten
Fundamentalziele auswirkt.
Bei der Betrachtung von Unternehmen sind Fundamentalziele die Ziele, die auf oberster
Entscheidungsebene vereinbart werden. Lang kommt nach einer fundierten Diskussion
zu dem Schluss, dass sich das Unternehmensziel eines Software-Unternehmens auf
Wettbewerbsfähigkeit mit den untergeordneten Zielen Gewinn und Zahlungsfähigkeit
reduzieren lässt.249 Das Ziel Gewinn lässt sich dabei weiter in Instrumentalziele zerlegen. Auch dem in der vorliegenden Arbeit verwendeten Modell zur Analyse und zum
Management von Risiken liegt die Annahme zugrunde, dass Gewinn angestrebt wird,
sodass sich ein negatives Ergebnis stets in einem finanziellen Verlust widerspiegelt.250
Auf der Ebene einzelner Projekte werden Ziele verfolgt, die letztendlich zur Erreichung
unternehmensweiter Fundamentalziele dienen sollen.251 Die vorliegende Arbeit konzentriert sich auf die Betrachtungsebene einzelner Projekte und die damit verfolgten
Ziele. Die Annahme, dass ein Kunde einer Offshore-Entwicklung mit diesem Projekt
letztendlich versucht seine Wettbewerbsfähigkeit zu steigern mag zutreffend sein, doch
dieses Ziel ist zu abstrakt, um ein Projekt zu steuern und zu kontrollieren. Konkrete
Projektziele dienen gleichzeitig als Kontrollinstrument, um beurteilen zu können wie
erfolgreich ein Projekt ist.252 Zusätzlich liefern konkrete Projektziele einen Ansatzpunkt
für Anforderungen an eine organisatorische Gestaltung des Projekts.253 Grundsätzlich
kann Softwareentwicklung als eine zielorientierte Aktivität bezeichnet werden.254
248
249
250
251
252
253
254
Vgl. Eisenführ, Weber /Entscheiden/ 56.
Vgl. Lang /Organisation/ 210f. Unter einem Software-Unternehmen werden bei Lang /Organisation/
20 Unternehmen verstanden, die ausschließlich Software entwickeln und vertreiben.
Vgl. hierzu Kapitel 1.5.4.2.
Vgl. Mellis /Projektmanagement/ 48.
Z. B. messen DeLone u. a. /Boundaries/ 2 (mit Bezug auf DeLone, McLean /Update/) Projekterfolg
bei globaler Softwareentwicklung u. a. daran inwieweit Projekte innerhalb des geplanten Zeitraums
und des geplanten Budget abgeschlossen worden oder inwieweit eine vereinbarte Spezifikation umgesetzt wurde. Dabei erfolgt die Beurteilung des Erfolgs am Grad der Zielerreichung.
Vgl. auch Lang /Organisation/ 204.
Vgl. Mellis /Projektmanagement/ 39.
67
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
Daher ist es auch im Rahmen dieser Arbeit hilfreich, Ziele auf Projektebene zu konkretisieren.
Das Ziel eines Softwareentwicklungsprojekts kann allgemein mit der Bereitstellung von
Software durch die Umsetzung funktionaler und nicht funktionaler Anforderungen
beschrieben werden.255 Dies gilt auch für Offshore-Entwicklungen. Auf einer konkreteren Ebene lassen sich verfolgte Projektziele zum Beispiel auf Entwicklungskosten,
Entwicklungsdauer, Prozess- oder Produktqualität beziehen. Im Fall der Individualentwicklung identifiziert Lang auf Projektebene insbesondere „Termintreue“ als Instrumentalziel.256
Im Rahmen dieser Arbeit soll allerdings keine Unterscheidung in Fundamental- und
Instrumentalziel vorgenommen werden, da hier eine Betrachtung auf Projektebene
stattfindet und eine Untersuchung der Eignung einzelner Instrumentalziele zur Erreichung bestimmter Fundamentalziele nicht im Fokus der Arbeit steht. Zusätzlich ist die
Festlegung, ob es sich um ein Fundamental- oder um ein Instrumentalziel handelt, vom
Abstraktionsgrad der Betrachtung abhängig. Auf einer untergeordneten Ebene mag ein
dort definiertes Fundamentalziel dem Instrumentalziel einer übergeordneten Ebene
entsprechen. Daher erscheint eine derartige Differenzierung bei der Betrachtung einzelner Projekte keinen zusätzlichen Nutzen zu stiften.
Zusammenfassend lässt sich festhalten, dass Ziele auf Ebene einzelner Projekte bei
Offshore-Entwicklungen zum einen dazu dienen, organisatorische Gestaltungsmaßnahmen auf die Erreichung dieser Ziele auszurichten257 und zum anderen helfen den Erfolg
eines Projekts zu beurteilen.
255
256
257
Vgl. zu diesem Absatz Mellis /Projektmanagement/ 47-50.
Vgl. Lang /Organisation/ 310.
Vgl. Mellis /Projektmanagement/ 40. Dort wird der Zusammenhang zwischen Gestaltungsempfehlungen, -wirkungen und –zielen, die alle von vorliegenden Rahmenbedingungen beeinflusst werden,
dargestellt. Die Besonderheiten einer Offshore-Entwicklung können in diesem Zusammenhang als
Rahmenbedingung aufgefasst werden.
68
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
2.7.2
Ziele in der Offshore-Entwicklung
2.7.2.1 Vorgehen zur Identifikation der Ziele
Um typische Ziele einer Offshore-Entwicklung für die vorliegende Arbeit zu identifizieren, wurden 17 bedeutende akademische Zeitschriften und drei angesehene Konferenzen
mit Hilfe webbasierter Suchmaschinen nach dem Begriff „Offshor*“ (um sowohl
„Offshore“ als auch „Offshoring“ zu finden) durchsucht.258
In einem ersten Durchlauf wurde, sofern dies durch die Suchmaschinen unterstützt
wurde, nur der Titel der veröffentlichten Artikel durchsucht. Dies ergab 34 Treffer.
Diese 34 Artikel wurden anschließend gelesen, um irrelevante Artikel (älter als aus
1985, kein Bezug zu Informationssystemen oder der Softwareentwicklung, keine Behandlung von Risiken oder Zielen259) zu eliminieren. Nach diesem Prozess wurden vier
Artikel identifiziert, die Risiken und/oder Ziele in der Offshore-Entwicklung behandeln
und daher als relevant eingestuft wurden.
In einem zweiten Durchlauf wurden, sofern dieses durch die Suchmaschinen unterstützt
wurde, alle in den Datenbanken hinterlegten Felder (z. B. Titel, Abstracts) nach dem
Begriff „Offshor*“ durchsucht. Dies ergab 129 Treffer, inklusive der 34 Treffer, die
bereits bei der reinen Titel-Durchsuchung gefunden wurden. Falls in einer Zeitschrift
mehr als 15 Treffer gefunden wurden, wurde die Suche mit dem Ausdruck ("risk* OR
goal*") weiter eingeschränkt. Die verbleibenden Treffer wurden gelesen und ihre Relevanz beurteilt. Dies führte zu 7 weiteren relevanten Artikeln.
Darüber hinaus wurden bei dem vorliegenden Review weitere 19 Artikel aus Büchern
und anderen Zeitschriften herangezogen.
Insgesamt wurden in den 30 identifizierten Artikeln 18 unterschiedliche Maßnahmen
zur Erreichung von Zielen aus Kundenperspektive ermittelt – Tabelle Tab. 2-10 stellt
diese in der Spalte „Zielerreichung durch“ dar. Diese Maßnahmen wurden anschließend
in zwei Schritten zu vier Oberzielen aggregiert. Als Ergebnis lassen sich aus Kundensicht die Oberziele monetäre, strategische, produktbezogene und prozessbezogene Ziele
258
259
Eine Übersicht der verwendeten Zeitschriften und Konferenzen befindet sich im Anhang A. Als
Suchmaschinen wurden Funktionalitäten der Internet-Seite „Ebsco-Host“ [http://search.epnet.com]
oder der Internetseite des jeweiligen Verlags verwendet.
Da sich Risiken stets auf das Verfehlen von Zielen beziehen, wurde nach beiden Begriffen gesucht.
Vgl. auch Kapitel 2.8.2.
69
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
bilden. Die Begriffe Ober- und Unterziel dienen lediglich zur Darstellung der hierarchischen Beziehung zwischen diesen Zielen.
Produktbezogene
Ziele
Prozessbezogene
Ziele
Strategische
Ziele
Monetäre Ziele
Oberziel
Unterziel
Kostenreduktion
Kurzfristiger
Kapitalzuwachs
Mit technologischem
Fortschritt der Softwarebranche Schritt halten
Konzentration auf Kernkompetenzen
Verkürzung der Entwicklungsdauer
Prozessverbesserung
beim Kunden
Steigerung der
Produktqualität
Zielerreichung durch
Umwandlung von Fixkosten in variable Kosten
Niedrigere Kosten für Büroräume
Skaleneffekte: Economies of scale or scope des
Anbieters
Ausnutzung von Marktmechanismen; neue
Absatzmärkte
Geringere Anschaffungs- und Wartungskosten
bei Hard- und Software
Personal: Geringere Personalkosten des Anbieters
Personal: Verringerung der Anzahl des eigenen
IT-Personals
Personal: Keine/ geringere Schulungskosten für
IT-Personal
Verkauf von Hardware
Zugang zu Technologien
Zugang zu IT-Personal
Auslagerung von Routineaufgaben
Steigerung der Produktivität
Ausnutzung unterschiedlicher Zeitzonen
Lösung interner Konflikte
Interne Überprüfung
Steigerung der Planbarkeit
Fähigkeiten des Anbieters
Tab. 2-10 Übersicht verfolgter Ziele in Offshore-Projekten aus Kundenperspektive
Das Kapitel 2.7.2.2 stellt die einzelnen Ziele und Möglichkeiten der Zielerreichung, die
in der Tabelle Tab. 2-10 dargestellt sind, detaillierter vor und führt die entsprechenden
Belege aus der Literatur auf.
70
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
2.7.2.2 Ziele aus Perspektive des Kunden
2.7.2.3 Aussagen empirischer Studien über verfolgte Ziele in der OffshoreEntwicklung
Welche Ziele letztendlich mit einer Offshore-Entwicklung verfolgt werden, kann von
Projekt zu Projekt variieren. Jedoch zeigen mehrere Untersuchungen, dass aus Sicht des
Kunden insbesondere Kostenreduktionen mit dem Auslagern von IT-Funktionen verfolgt werden.
In einer breit angelegten Umfrage mit ca. 5.200 teilnehmenden Kunden von Outsourcing-Dienstleistungen (inkl. Offshore-Dienstleistungen) verfolgten 70% der Befragten
das Ziel Kosteneinsparungen zu erreichen.260 In den untersuchten Projekten wurde eine
Kosteneinsparung von durchschnittlich 10-19% erzielt. Weitere Ziele, die mit Outsourcing-Projekten verfolgt wurden, waren Verbesserung der Qualität (50% der Befragten),
Verkürzung der Time-to-Market (40% der Befragten) und Erwerb technischen Wissens
(35% der Befragten).
Eine Untersuchung vom Zentrum für europäische Wirtschaftsforschung (ZEW) ermittelt
folgende Motive für ein Outsourcing:261 91% der Befragten verfolgen das Ziel Konzentration auf eigene Kernkompetenzen; 86% streben eine höhere Qualität der erbrachten
Leistungen durch einen externen Anbieter an; 84% stufen das eigene Unternehmen als
zu klein ein, um die gewünschten Leistungen erzielen zu können; 63% verfolgen das
Ziel Kostenersparnis.
Lacity und Willcock untersuchen in einer Studie 61 IT-Sourcing-Entscheidungen in 40
amerikanischen und britischen Unternehmen im Zeitraum von 1991 bis 1995.262 Bei
80% der Entscheidungen wurde das Ziel Kostenreduktion verfolgt; bei 59% der Entscheidungen ging es darum, eingesetzte Technologie oder den technischen Service zu
verbessern; 31% strebten eine Fokussierung auf Kernkompetenzen an.
260
261
262
Vgl. hierzu Hatch /Offshore 2005/ 10, 14, 16.
Vgl. ZEW /Forschungsergebnisse/. Die Untersuchung umfasst ca. 4.400 deutsche Unternehmen mit
fünf oder mehr Mitarbeiten im verarbeitenden Gewerbe und ausgewählten Dienstleistungsbranchen.
87% dieser Unternehmen betreiben Outsourcing von denen allerdings nur 6% Dienstleistungen aus
dem Ausland beziehen. Dabei werden maßgeblich Systembetreuung und Wartung von Hardware (in
66% der Fälle) und Entwicklung von Software (in 63% der Fälle) ausgelagert.
Vgl. hierzu Lacity, Willcocks /Empirical investigation/ 369.
71
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
Dibbern, Heinzl und Leibbrandt kommen bei einer Untersuchung von elf Fallstudien bei
deutschen Unternehmen und unter Anwendung der Transaktionskosten-Theorie zu der
Aussage, dass eine Entscheidung für einen Fremdbezug oder Eigenerstellung in der
Informationsverarbeitung vorwiegend vor dem Hintergrund eines Kostenvergleichs
beurteilt wird.263
Eine Untersuchung von 55 amerikanischen Unternehmen kommt zu dem Schluss, dass
in der Mehrheit der untersuchten Unternehmen Kostenersparnisse mit einer Auslagerung verfolgt werden.264
Eine Befragung von 25 Firmenvertretern namhafter amerikanischer Unternehmen durch
Deloitte & Touche im Zeitraum Oktober – Dezember 2004 ergab, dass 70% der Befragten mit einer Auslagerung Kosteneinsparungen verfolgten.265
Eine Umfrage bei 75 deutschen Unternehmen die Offshore-Entwicklungsprojekte
durchführen, ergab, dass 92% der Befragten geringere Lohnkosten im Land des Anbieters von Offshore-Dienstleistungen für sehr wichtig bei der Entscheidung über eine
Auslagerung erachten.266
Eine Befragung der Deutsche Bank Research in Kooperation mit der BITKOM ergab,
dass Kostensenkungen das dominierende Ziel der 572 Befragten war.267
In einer empirischen Studie über Gründe für Auslagerungen von IT-Funktionen im
amerikanischen Bankensektor wurde festgestellt, dass mit Auslagerungen Kostenersparnisse verfolgt wurden.268
Die Autoren eines umfangreichen und sorgfältig durchgeführten Literatur-Reviews zum
Themenkomplex IT-Outsourcing269 stellen fest, dass in einem Großteil der untersuchten
Artikel ökonomische oder strategische Managementkonzepte einer Entscheidung für ein
Outsourcing zugrunde gelegt werden. Insbesondere die ersten Untersuchungen, die im
263
264
265
266
267
268
269
Vgl. Dibbern, Heinzl, Leibbrandt /Interpretation/ 537.
Vgl. Loh, Venkatraman /Determinants/ 17-19.
Vgl. Deloitte /Calling/ 1, 5.
Vgl. Moczadlo /Chancen und Risiken/.
Vgl. Schaaf, Weber /Offshoring-Report 2005/ 12.
Vgl. Ang, Straub /Production/ 542. An der Fragebogen-Befragung hatten 243 amerikanische Banken
teilgenommen.
In diesem Literatur-Review wurden 84 Artikel aus 21 Quellen analysiert. Vgl. hierzu Dibbern u. a.
/Survey/ 22f., 44.
72
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
Bereich Outsourcing veröffentlicht wurden, fokussierten ausschließlich auf Kosteneinsparungen.
Schließlich stellen die Autoren eines anderen Literatur-Reviews Gründe für ein Outsourcing aus 14 Veröffentlichungen zusammen und kommen zu dem Schluss, dass
wirtschaftliche Motive bei einer Entscheidung für eine Auslagerung von hoher Bedeutung sind.270 Diese Autoren ermittelten durch eine eigens durchgeführte Befragung mit
306 Teilnehmern, die Outsourcing betreiben, dass dies vor einem strategischen Hintergrund geschieht oder um die Flexibilität der Entwicklungsabteilung oder um die Qualität des ausgelagerten Produktes bzw. Dienstes zu steigern.271
Damit sollten beispielhaft die Ergebnisse einiger Untersuchungen wiedergegeben werden, die zeigen, dass die Entscheidung für eine Auslagerung häufig vor dem Hintergrund der Kostenersparnis getroffen wird. Das folgende Kapitel geht auf diesen Aspekt
näher ein.
Bei der in den folgenden Kapiteln präsentierten Analyse der verwendeten Literatur und
empirischen Studien muss beachtet werden, dass viele Argumente und Aussagen aus
der Outsourcing-Literatur stammen und nicht zwingend Offshore-spezifisch sind. Daher
muss stets überlegt werden, ob die aufgeführten Ziele auch im Rahmen einer OffshoreEntwicklung relevant sind. Zusätzlich muss darauf geachtet werden, auf welche ITFunktionen sich die in der Literatur getroffenen Aussagen beziehen. So sind gegebenenfalls Aussagen in Bezug auf die Auslagerung von Rechenzentren nicht direkt auf die
Auslagerung der Softwareentwicklung übertragbar.
Die Ziele, die ein Anbieter von Offshore-Dienstleistungen verfolgt, werden seltener und
weniger umfassend in der vorliegenden Literatur diskutiert. Grundsätzlich lassen sich
einem Anbieter aber zwei Ziele unterstellen: Erzielen einer möglichst hohen Gewinnmarge und eine möglichst konstant fließende Gewinnmarge.
270
271
Vgl. Gonzalez, Gasco, Llopis /Spanish firms/ 118.
Vgl. Gonzalez, Gasco, Llopis /Spanish firms/ 129.
73
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
Eine möglichst hohe Gewinnmarge lässt sich auf das Unternehmensziel „Gewinn“272
zurückführen und kann durch die Umsetzung bestimmter Prozessziele erreicht werden.
Kapitel 2.7.3.1 stellt dies näher vor.
Eine möglichst konstante Gewinnmarge lässt sich auf das Unternehmensziel „Zahlungsfähigkeit“273 zurückführen und ist von hoher Bedeutung für den Fortbestand und für die
Weiterentwicklung eines Unternehmens. Kundenbindung an den Anbieter kann in
diesem Zusammenhang ein verfolgtes Ziel darstellen. Kapitel 2.7.3.2 stellt dies näher
vor.
2.7.2.4 Monetäre Ziele
Anhand der untersuchten Artikel274 lassen sich grundsätzlich zwei monetäre Ziele unterscheiden. Das erste und, wie bereits in Abschnitt 2.7.2.3 dargestellt, weit verbreitete
Ziel einer Outsourcing-Entwicklung aus der Perspektive des Kunden ist die Kostenreduktion. In der vorliegenden Literatur werden unterschiedliche Argumente angeführt,
wie eine Kostenreduktion erreicht werden kann.
Das zweite monetäre Ziel ist ein kurzfristiger Kapitalzuwachs durch den Verkauf von
Hardware.
Die Tabelle Tab. 2-11275 liefert einen Überblick der beiden Ziele sowie die gefundenen
Argumente zur Erreichung einer Kostenreduktion. Im Folgenden werden die Argumente
näher
erläutert
und
analysiert,
inwieweit
diese
auch
auf
eine
Offshore-
Softwareentwicklung anwendbar sind.276
272
273
274
275
276
Vgl. hierzu Kapitel 2.7.1.
Vgl. hierzu Kapitel 2.7.1.
Vgl. hierzu Kapitel 2.7.2.
Anmerkung: Die Zahlen in den Zellen der Tabelle sind die entsprechenden Seitenzahlen der angegebenen Literatur.
Teilweise wird in der folgenden Darstellung der Argumentation zur Erreichung der einzelnen Ziele
nicht auf alle in der Spalte „Autoren“ aufgeführte Artikel näher eingegangen. Insbesondere dann
nicht, wenn im Wesentlichen in den Artikeln nicht weitgehender argumentiert wird.
74
Autoren [in den Zellen ist die zugehörige Seitenzahl angegeben]
Alner /Effects/
Amoribieta u. a. /Programmers/
Apte u. a. /Outsourcing practices/
Baldwin, Irani, Love /Outsourcing/
Barthelemy /Hidden cost/
Carmel /Global software teams/
Chandrasekaran, Ensing /ODC/
Clark Jr., Zmud, McCray /Nature/
Dedene, De Vreese /Realities/
Delmonte, McCarthy /Offshore/
Dibbern, Heinzl, Leibbrandt
/Interpretation/
Grover, Cheon, Teng /Outsourcing/
Gupta, Gupta /Outsourcing/
Hatch /Offshore 2005/
Hayes, Hunton, Reck
/Announcements/
Heinzl /Outsourcing/
Jurison /Role of risk/
Karolak /Global software development/
Khan u. a. /Evaluating/ (auch in Khan,
Currie, Weerakkody /Strategies/)
Khosrowpour, Subramanian, Gunterman /Organizational benefits/
Klepper, Jones /Outsourcing/
Kobitzsch, Rombach, Feldmann
/Outsourcing/
Krepchin /Offshore/
Lacity, Hirschheim, Willcocks
/Realizing/
McFarlan, Nolan /IT Outsourcing/
McLellan, Marcolin, Beamish
/Financial and strategic motivations/
Ramarapu, Parzinger, Lado /Issues/
Slaughter, Ang /Employment/
Smith, Mitra, Narasimhan
/Outsourcing/
Tafti /Risks factors/
35
35
36
Verkauf von Hardware
Personal: Keine/ geringere Schulungskosten für IT-Personal
Personal: Verringerung der Anzahl des eigenen IT-Personals
Skaleneffekte: Economies of
scale/ scope des Anbieters
Geringere Anschaffungs- und
Wartungskosten bei Hard- und
Software
Personal: Geringere Personalkosten des Anbieters
Niedrigere Kosten für Büroräume
Erreichen des Ziels durch
Kostenreduktion
Umwandlung von Fixkosten in
variable Kosten
Ziele
Kurzfristiger
Kapitalzuwachs
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
35
130f.
296f.
130
23
23
60
6
49
228
228
47
228
228
228
44
1608
45-47
536
538
37
45-47
22
22
45-47
110
626
239f.
626
239
240
16
16
2,4
249
246
48
29
251
253
249
253
248
48
78
55f.
9f.
9f.
13
12
12
12
309
309
309
309
309
28
28
12-14
13
52
64
64
550
Tab. 2-11 Monetäre Ziele einer Outsourcing-Entwicklung aus Kundenperspektive
75
64f., 80
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
ƒ
Kostenreduktion
o
Umwandlung von Fixkosten in variable Kosten
Bei der Umwandlung von Fixkosten in variable Kosten wird eine Kostenreduktion
maßgeblich dadurch argumentiert, dass der Kunde nicht dauerhaft Ressourcen zur
Erfüllung von Aufgaben vorhalten muss. Im Falle der Auslagerung von Dienstleistungen eines Rechenzentrums, wie zum Beispiel der Bereitstellung von Speicher- und
Rechenkapazität, an ein Anbieterunternehmen bedeutet dies, dass der Kunde nicht zu
jedem Zeitpunkt eine maximale Kapazität vorhalten muss, sondern bedarfsorientiert die
benötigten Kapazitäten anfordern und bezahlen kann.
Auf die Offshore-Softwareentwicklung kann dieses Argument übertragen werden. In
der Regel werden in den unterschiedlichen Entwicklungsphasen der Erstellung einer
Software unterschiedlich viele Mitarbeiter und gegebenenfalls auch mit jeweils unterschiedlichem Know-how benötigt. Jedoch kann der eigene Personalumfang nicht dem
schwankenden Bedarf angepasst werden, sondern bleibt über die Zeit eher konstant.
Dagegen bezahlt ein Kunde im Fall der Offshore-Entwicklung im Wesentlichen nur die
benötigten Personalstunden.277 Ein Anbieter kann dies dadurch realisieren, dass er eine
Vielzahl an Projekten für unterschiedliche Kunden parallel und zeitlich überlappend
durchführt. Dadurch kann Personal, welches in einem Projekt nicht mehr benötigt wird,
einem anderen Projekt zugeordnet werden.
In der vorliegenden Literatur ist aber auch ein zweites, scheinbar genau gegensätzliches
Argument zu finden: Eine Auslagerung führt zur Wandlung von variablen Kosten in
Fixkosten.278 Hierbei liegt die Annahme zugrunde, dass Festpreisverträge zwischen dem
Anbieter und dem Kunden abgeschlossen werden. In diesem Fall sind die Kosten für
einzelne Projekte oder Dienstleistungen für den Kunden exakter planbar, da eventuell
auftretende zusätzliche Kosten durch den Anbieter getragen werden müssen. Dieses
Argument ist auch im Rahmen einer Offshore-Entwicklung gültig. Jedoch muss beachtet werden, dass diese scheinbar gegensätzlichen Argumente unterschiedliche Ziele
betreffen. Im ersten Fall „hin zu variablen Kosten“ geht es um Kostenreduktion. Im
zweiten Fall „hin zu festen Kosten“ geht es um Erhöhung der Planbarkeit.
277
278
Siehe hierzu Kapitel 2.3.2 in dem unterschiedliche Vertragsformen dargestellt werden. Auch ein
Festpreis-Vertrag basiert auf den (voraussichtlich) benötigten Personalstunden.
Vgl. zu diesem Abschnitt Alner /Effects/ 35; Grover, Cheon, Teng /Outsourcing/ 37 und Gupta, Gupta
/Outsourcing/ 45f.
76
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
Betrachtet man die Kosten, die bei sequentieller Durchführung mehrerer Projekte entstehen, wird deutlich, dass sich die beiden Argumente nicht widersprechen.
Denn ein ausgelagertes Festpreisprojekt (zweites Argument) führt gleichzeitig dazu,
dass Kosten bedarfsgerecht anfallen, nämlich nur dann, wenn ein Projekt durchgeführt
wird. Findet kein Projekt statt, fallen auch keine fixen Personalkosten oder Kosten für
andere Ressourcen an. Dies entspricht aber gleichzeitig der ersten Argumentation, dass
Fixkosten eines längeren Zeitraums in variable Kosten umgewandelt werden.
o
Niedrigere Kosten für Büroräume
Bei global verteilt arbeitenden Teams wird das Argument angeführt, dass bei diesen
eventuell gegenüber einem größeren Team an nur einem Standort niedrigere Kosten für
Büroräume entstehen, da die verteilten Teams kleinere Räume benötigen oder die
Teammitglieder von zuhause aus arbeiten.279
Auch im Falle der Offshore-Entwicklung können niedrigere Kosten für Büroräume
entstehen. Allerdings ist nicht davon auszugehen, dass Mitarbeiter des Anbieters von
zuhause aus an der Entwicklung beteiligt sind. Stattdessen ist anzunehmen, dass der
Anbieter seine Offshore-Mitarbeiter auch in einem zentralen Büroraum unterbringen
wird und letztendlich der Anbieter die Kosten für Büroräume an den Kunden weiterreichen wird. Allerdings wandeln sich für den Kunden diese ansonsten fixen Kosten in
variable Kosten, da sie nur noch projektspezifisch anfallen. Zusätzlich ist es denkbar,
dass die Kosten für Büroräume in Indien niedriger sind als in den DACH-Staaten.
o
Skaleneffekte des Anbieters
Skaleneffekte lassen sich in economies of scale und economies of scope unterscheiden.280
Die Theorie über economies of scale sagt aus, dass die Stückkosten bei der Produktion
eines Produktes mit steigenden Stückzahlen sinken.281
Economies of scale in Bezug auf die Individualentwicklung (Produktion) von Software
können dann entstehen, wenn einzelne Komponenten der zu entwickelnden Software
279
280
281
Vgl. Clark Jr., Zmud, McCray /Nature/ 228 und Karolak /Global software development/ 16.
Da dies verbreitete Begriffe sind, wird an dieser Stelle auf eine Übersetzung in die deutsche Sprache
verzichtet.
Vgl. Besanko u. a. /Economics/ 74; Lacity, Hirschheim /Bandwagon/ 76; Lacity, Hirschheim
/Outsourcing bandwagon/ 29 oder Porter /Competitive strategy/ 7.
77
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
bereits in anderen Entwicklungsprojekten erstellt worden sind und nun ohne oder nur
mit geringen Anpassungen übernommen werden können. Weiter kann in diesem Sinne
auch von economies of scale gesprochen werden, wenn das spezialisierte Wissen des
IT-Personals des Anbieters in unterschiedlichen Projekten eingesetzt werden kann.282
Häufig wird einem großen Anbieter unterstellt, dass dieser eher niedrigere Hardwarepreise und günstigere Softwarelizenzen im Einkauf aushandeln kann als ein einzelner
Kunde mit einem geringeren Einkaufsvolumen.283 Jedoch ist zu beachten, dass auch ein
Kunde Mengenrabatte in den Größenordnungen eines Offshore-Anbieters erzielen
kann.284
Diese Überlegungen zeigen, dass die Erzielung von economies of scale auf der Seite des
Anbieters von unterschiedlichen Faktoren beeinflusst wird und nicht als gegeben angenommen werden kann.285 Daher muss stets projektspezifisch untersucht werden, ob
economies of scale erzielt werden können und ob diese auch an den Kunden weitergeleitet werden.
Im Fall von economies of scope existiert die Annahme, dass ein Unternehmen Einsparungen erzielt, wenn es die Vielzahl an unterschiedlichen Produkten und Dienstleistungen steigert.286 Im Rahmen einer Outsourcing-Diskussion wird unterstellt, dass das
Personal eines Anbieters mehr Erfahrung in der Softwareentwicklung besitzt als das
Personal eines Unternehmens, dessen Kerngeschäft nicht IT ist.287 Es kann vermutet
werden, dass durch die umfangreicheren Erfahrungen des Anbieters seine Produktivität
höher liegt als die des weniger erfahrenen Kunden. Weiter kann dann vermutet werden,
dass dadurch der Anbieter weniger Arbeitsstunden zur Entwicklung der Software benö-
282
283
284
285
286
287
Porter /Competitive strategy/ 8f. stellt das Prinzip von “joint costs” dar, bei dem z. B. Kosten für
Wissen auf mehrere Anwendungen des Wissens verteilt werden. Siehe auch Besanko u. a.
/Economics/ 76.
Vgl. Barthelemy /Hidden cost/ 60; Dibbern, Heinzl, Leibbrandt /Interpretation/ 536; Grover, Cheon,
Teng /Outsourcing/ 37; Gupta, Gupta /Outsourcing/ 45f.; Jurison /Role of risk/ 239; Lacity, Hirschheim, Willcocks /Realizing/ 9-10; McLellan, Marcolin, Beamish /Financial and strategic motivations/ 309 oder Smith, Mitra, Narasimhan /Outsourcing/ 64.
Vgl. Lacity, Hirschheim /Bandwagon/ 77; Lacity, Hirschheim /Outsourcing bandwagon/ 29f. und
Lacity, Willcocks, Feeny /Flexibility/ 90.
Dass Skaleneffekte im Rahmen der Auslagerung der Softwareentwicklung nicht per se anzunehmen
sind wird z. B. auch von folgenden Autoren angenommen: Dibbern, Heinzl, Leibbrandt
/Interpretation/ oder Lacity, Hirschheim /Bandwagon/ 77.
Vgl. Besanko u. a. /Economics/ 74.
Vgl. Grover, Cheon, Teng /Outsourcing/ 37 und Hayes, Hunton, Reck /Announcements/ 110.
78
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
tigt als der Kunde. Die damit erzielten Einsparungen kann der Anbieter dann zumindest
teilweise an den Kunden weiterreichen.
o
Geringere Anschaffungs- und Wartungskosten bei Hard- und Software
Abgesehen von möglichen Skaleneffekten auf Seiten des Anbieters (siehe oben) benötigt der Kunde von Outsourcing- oder Offshore-Dienstleistungen weniger eigene Hardund Software zur Entwicklung von Software. Dadurch entstehen geringere Kosten in
Bezug auf Anschaffung und Wartung von Hard- und Software.288 Jedoch entstehen
diese Kosten auf Seiten des Anbieters und werden vermutlich an den Kunden weitergereicht. Möglicherweise sind diese Kosten für den Anbieter geringer als für den Kunden.
Denn neben möglichen economies of scale entstehen dem Anbieter im Verhältnis zu
einem deutschen Kunden niedrigere indische Personalkosten bei der Wartung. Zusätzlich besteht für den Anbieter die Möglichkeit diese Kosten auf mehrere Projekte für
unterschiedliche Kunden zu verteilen, wenn die Hard- und Software in mehreren Projekten eingesetzt werden kann. Jedoch muss auch hier auf der Ebene einzelner konkreter
Projekte entschieden werden, wie groß dieser Einfluss ist.
o
Personal: Geringere Personalkosten des Anbieters
Der Anteil der Personalkosten an den Gesamtkosten zur Entwicklung von Software
kann als hoch eingestuft werden.289 Daher wird versucht unter Ausnutzung der, im
Verhältnis zu Deutschland, geringeren Personalkosten in Indien die Gesamtkosten zur
Entwicklung von Software zu senken.290
o
Personal: Verringerung der Anzahl des IT-Personals
Durch eine Auslagerung der Softwareentwicklung besteht die Möglichkeit die Anzahl
des IT-Personals auf Seiten des Kunden zu verringern. Dadurch, dass die Personalkosten des Anbieters geringer sind und die bisherigen fixen Personalkosten des Kunden in
288
289
290
Vgl. Alner /Effects/ 36; Clark Jr., Zmud, McCray /Nature/ 228; Khosrowpour, Subramanian, Gunterman /Organizational benefits/ 246; McFarlan, Nolan /IT Outsourcing/ 12 oder McLellan, Marcolin,
Beamish /Financial and strategic motivations/ 309.
Amoribieta u. a. /Programmers/ 130 berichten, dass in den USA die Personalkosten einen Anteil von
75% an den Gesamtkosten besitzen. Siehe auch Mellis /Projektmanagement/ 22.
Zu den Unterschieden in den Personalkosten siehe Kapitel 2.2.4.
79
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
variable und bedarfsbezogene Kosten umgewandelt werden, ergibt sich ein Kostenvorteil gegenüber der Eigenentwicklung durch den Kunden.
o
Personal: Geringere Schulungskosten für IT-Personal
In Abhängigkeit vom Umfang der Auslagerung und der damit einhergehenden Verringerung der Anzahl des IT-Personals auf der Seite des Kunden entstehen dem Kunden
geringere Schulungskosten für sein IT-Personal. Der Anbieter muss dafür Sorge tragen,
dass sein IT-Personal notwendige Schulungen zum Beispiel in aktuellen Programmiersprachen oder Modellierungstechniken erhält. Der Kunde braucht diese Investition nicht
mehr zu leisten. Setzt der Anbieter seine Mitarbeiter in Projekten für unterschiedliche
Kunden ein, so besteht die Möglichkeit, die Schulungskosten auf mehrere Projekte zu
verteilen, sodass die umgelegten Kosten pro Kunde sinken (siehe auch oben: Skaleneffekte).
ƒ
Kurzfristiger Kapitalzuwachs
Neben der Kostenreduktion bei der Entwicklung von Software kann ein weiteres Ziel
der Auslagerung von IT-Funktionen darin bestehen einen kurzfristigen Kapitalzuwachs
durch den Verkauf von nicht mehr benötigter Hardware zu erzielen.291 Auch im Fall der
(teilweisen) Auslagerung der IT-Funktion Softwareentwicklung kann dieses Ziel verfolgt werden. Allerdings ist zu beachten, dass dieser monetäre Vorteil nur einmalig
auftritt und stark von dem Wert der veräußerten Hardware abhängt. Daher wird dieses
Ziel wahrscheinlich im Rahmen einer Offshore-Entwicklung seltener verfolgt, da langfristigen Offshore-Entwicklungen und der Bildung von partnerschaftlichen Beziehungen
eine höhere Bedeutung zugeschrieben wird.292
291
292
Vgl. Alner /Effects/ 35; Clark Jr., Zmud, McCray /Nature/ 228; Khosrowpour, Subramanian, Gunterman /Organizational benefits/ 248; McFarlan, Nolan /IT Outsourcing/ 13 und Smith, Mitra, Narasimhan /Outsourcing/ 64f.
Zu diesem Schluss kommt eine explorative Studie von Prof. M. Wiener in der 15 Studien über Erfolgsfaktoren aus dem IT-Outsourcing-Umfeld untersucht werden. Amberg, Wiener /Erfolgsfaktoren/ 27.
80
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
2.7.2.5 Strategische Ziele
Die zweite Kategorie von Zielen, die mit der Auslagerung von bestimmten ITFunktionen verfolgt wird, sind strategische Ziele. In der untersuchten Literatur293 lassen
sich grundsätzlich aus Perspektive des Kunden zwei strategische Ziele294 unterscheiden:
zum einen mit dem technologischen Fortschritt der Softwareentwicklung Schritt zu
halten und zum anderen eine Konzentration auf Kernkompetenzen.
Tabelle Tab. 2-12 fasst die Ergebnisse der Untersuchung zusammen.
Mit technologischem
Fortschritt der
Softwareentwicklung
Schritt halten
Zugang
Zugang
zu Techzu ITnologien
Personal
Ziele
Autoren [in den Zellen ist die zugehörige Seitenzahl angegeben]
Erreichen des Ziels durch
Alner /Effects/
Apte u. a. /Outsourcing practices/
Baldwin, Irani, Love /Outsourcing/
Barthelemy /Hidden cost/
Carmel /Global software teams/
Chandrasekaran, Ensing /ODC/
Clark Jr., Zmud, McCray /Nature/
Dedene, De Vreese /Realities/
Delmonte, McCarthy /Offshore/
Dibbern, Heinzl, Leibbrandt /Interpretation/
Grover, Cheon, Teng /Outsourcing/
Gupta, Gupta /Outsourcing/
Hayes, Hunton, Reck /Announcements/
Heinzl /Outsourcing/
Jurison /Role of risk/
Khan u. a. /Evaluating/
(auch in Khan, Currie, Weerakkody /Strategies/)
Khosrowpour, Subramanian, Gunterman /Organizational
benefits/
Klepper, Jones /Outsourcing/
Kobitzsch, Rombach, Feldmann /Outsourcing/
Krepchin /Offshore/
Lacity, Hirschheim, Willcocks /Realizing/
McFarlan, Nolan /IT Outsourcing/
McLellan, Marcolin, Beamish /Financial and strategic
motivations/
Ramarapu, Parzinger, Lado /Issues/
Slaughter, Ang /Employment/
Smith, Mitra, Narasimhan /Outsourcing/
Tafti /Risks factors/
36
23
60
4f.
49
229
537
37
45-47
110f.
626
239
36
297
23
60
Konzentration auf
Kernkompetenzen
Auslagerung
von Routineaufgaben
36
23
49
229
44
1609
47
229
37
45-47
37
45-47
110f.
626
626
239f.
2,4
4
246f.
246f.
251
49
49
78
49f.
11f.
14
11f.
13
55
11f.
14
310, 314
310, 314
309
28
28
47
64f.
52
64
64f.
550
Tab. 2-12 Strategische Ziele einer Outsourcing-Entwicklung aus Kundenperspektive
293
294
Siehe hierzu Kapitel 2.7.2.
Streng genommen kann die Bezeichnung „strategische Ziele“ irreführend sein, da jedes verfolgte Ziel
eine strategische Bedeutung besitzen kann. Falls z. B. der Kunde auf Unternehmensebene eine Strategie als Kostenführer verfolgt, kann die Verfolgung monetärer Ziele von strategischer Bedeutung
sein. Dennoch sollen hier die beiden identifizierten Ziele unter dem Dach strategische Ziele zusammengefasst werden, um die in der untersuchten Literatur gefundenen Ziele adäquat widerspiegeln zu
können. Vgl. zu Unternehmensstrategien Porter /Competitive strategy/ Kapitel 2.
81
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
ƒ
Mit technologischem Fortschritt der Softwareentwicklung Schritt halten
Um mit dem technologischen Fortschritt der Softwareentwicklung Schritt halten zu
können, benötigt ein Unternehmen zum einen Zugang zu diesen Technologien und zum
anderen IT-Personal mit entsprechendem Wissen. Verschafft sich ein Unternehmen
diesen Zugang durch Auslagerung entsprechender IT-Funktionen, kann es das Risiko in
eine unzweckmäßige Technologie zu investieren minimieren, da dieses nun durch den
Anbieter getragen wird.295
Verfügt das IT-Personal eines Unternehmens (Kunde) nicht über das notwendige technologische Wissen für eine geplante Softwareentwicklung, kann dieser Mangel bei einer
Auslagerung durch das IT-Personal eines Anbieters ausgeglichen werden.296 Ein weiterer Vorteil einer Auslagerung ist, dass der Kunde kein selten benötigtes Spezialwissen
vorhalten muss, sondern dieses nach Bedarf beim Anbieter abrufen kann.297 Für den
Anbieter besteht dagegen die Möglichkeit, IT-Personal mit solch selten benötigtem
Wissen bei unterschiedlichen Kunden einzusetzen und es so optimaler auszunutzen.
ƒ
Konzentration auf Kernkompetenzen
Ein weiteres Ziel, das mit der Auslagerung von IT-Funktionen verfolgt wird, ist die
Konzentration auf Kernkompetenzen. Im Wesentlichen werden dabei zwei Ideen verfolgt. Zum einen soll das IT-Personal des Kunden von Routineaufgaben entlastet werden, um mehr Kapazität in die Unternehmensentwicklung investieren zu können. Zum
anderen wird die Annahme getroffen, dass ein Anbieter aufgrund seiner Spezialisierung
produktiver bei der Entwicklung von Software ist und diesen Vorteil an seine Kunden
weiterreicht.298
2.7.2.6 Prozessbezogene Ziele
Die dritte Kategorie von Zielen, die mit der Auslagerung von bestimmten ITFunktionen verfolgt wird, sind prozessbezogene Ziele. Mit Prozess wird hier eine ein-
295
296
297
298
Vgl. Clark Jr., Zmud, McCray /Nature/ 229; Gupta, Gupta /Outsourcing/ 47 und Khosrowpour,
Subramanian, Gunterman /Organizational benefits/ 247.
Vgl. Tabelle Tab. 2-12.
Vgl. hierzu insb. Baldwin, Irani, Love /Outsourcing/ 23; Jurison /Role of risk/ 240 und Khosrowpour,
Subramanian, Gunterman /Organizational benefits/ 247.
Siehe hierzu auch Ausführungen zu „economies of scope“ im Kapitel 2.7.2.4.
82
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
heitliche projektübergreifende Arbeitsweise bezeichnet, um Softwareentwicklungen
durchzuführen.299
In der untersuchten Literatur300 lassen sich grundsätzlich aus Perspektive des Kunden
zwei prozessbezogene Ziele unterscheiden: Verkürzung der Entwicklungsdauer und
Prozessverbesserungen beim Kunden. Tabelle Tab. 2-13 fasst die Ergebnisse der Untersuchung zusammen.
Autoren [in den Zellen ist die
zugehörige Seitenzahl angegeben]
Apte u. a. /Outsourcing practices/
Baldwin, Irani, Love /Outsourcing/
Carmel /Global software teams/
Chandrasekaran, Ensing /ODC/
Clark Jr., Zmud, McCray /Nature/
Dedene, De Vreese /Realities/
Delmonte, McCarthy /Offshore/
Grover, Cheon, Teng /Outsourcing/
Heinzl /Outsourcing/
Jurison /Role of risk/
Karolak /Global software development/
Khan u. a. /Evaluating/
(auch in Khan, Currie, Weerakkody /Strategies/)
Khosrowpour, Subramanian, Gunterman
/Organizational benefits/
Klepper, Jones /Outsourcing/
Kobitzsch, Rombach, Feldmann /Outsourcing/
Krepchin /Offshore/
Lacity, Hirschheim, Willcocks /Realizing/
McFarlan, Nolan /IT Outsourcing/
Ramarapu, Parzinger, Lado /Issues/
299
300
Verkürzung der Entwicklungsdauer
Vgl. Mellis /Projektmanagement/ 49f.
Siehe hierzu Kapitel 2.7.2.
83
Steigerung der
Planbarkeit
297
23
49
228f.
1609
9
49
230
44
1609
44
37
626
240
17
4
246
252
29
50
51
82
55
15
14
28
14
Tab. 2-13 Prozessbezogene Ziele einer Outsourcing-Entwicklung aus Kundenperspektive
ƒ
Interne Überprüfung
Prozessverbesserung beim Kunden
Lösung interner
Konflikte
Steigerung der
Produktivität
Erreichen des Ziels durch
Ausnutzung unterschiedlicher
Zeitzonen
Verkürzung der
Entwicklungsdauer
Ziele
48
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
In der untersuchten Literatur sind zwei Wege erkennbar, mit denen versucht wird die
Entwicklungszeit zu verkürzen.301
o Steigerung der Produktivität
Zum einen wird dem Anbieter unterstellt, Software produktiver entwickeln zu können.
Dieses wird zurückgeführt auf eine im Verhältnis zum Kunden effizientere – und damit
auch schnellere – Softwareentwicklung des Anbieters aufgrund seiner umfangreichen
Erfahrungen. Weiter besitzt ein Offshore-Anbieter unter Umständen eine sehr hohe
Prozessreife, wobei einem Prozess mit hohem Reifegrad eine hohe Produktivität zugesagt wird.302
Schließlich besteht die Möglichkeit, bei gleich bleibenden Kosten – gegenüber einer
Entwicklung im Land des Kunden – mehr Personal im Land des Offshore-Anbieters
einzusetzen, da dort die Lohnkosten niedriger sind als in den DACH-Staaten.303 Dadurch lässt sich in gewissem Umfang auch die Entwicklungsdauer senken, wenn mehr
Personal die Entwicklungsaufgaben erfüllen.304
o Ausnutzung unterschiedlicher Zeitzonen
Zum anderen lässt sich die Länge eines Arbeitstages ausdehnen, wenn die Teammitglieder eines Projekts in unterschiedlichen Zeitzonen arbeiten. Überschneiden sich die
Arbeitszeiten von geografisch entfernten Teammitgliedern nur geringfügig, so kann eine
Aufgabe oder erstellte Ergebnisse am Ende des Arbeitstages von dem einen Teammitglied an ein anderes Teammitglied, dessen Arbeitstag gerade begonnen hat, weiter
gegeben werden.305 Dadurch wird sozusagen im „Schichtbetrieb“ an der Projekterfüllung gearbeitet.306 Inwieweit dies funktioniert hängt auch stark von den beteiligten
Standorten ab. Im Fall der DACH-Staaten und Indien beträgt der Zeitunterschied allerdings nur 3,5 bzw. 4,5 Stunden.307 Damit ist höchstens eine Verlängerung des Arbeitstages möglich.
301
302
303
304
305
306
307
Belege der im Folgenden getroffenen Aussagen lassen sich anhand der in der Tabelle Tab. 2-13
aufgeführten Quellen finden.
Vgl. hierzu Ausführungen im Kapitel 2.2.6.
Vgl. Kapitel 2.2.4.
Vgl. hierzu Krepchin /Offshore/ 55.
Vgl. Kobitzsch, Rombach, Feldmann /Outsourcing/ 82.
Siehe hierzu auch Erläuterungen zum „follow-the-sun“-Modell in Kapitel 2.3.3.
Vgl. hiezu Kapitel 2.2.2.
84
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
Um die Zeitverschiebung als Vorteil nutzen zu können, müsste die indische Seite am
Ende ihres Arbeitstages Aufgaben an die deutsche Seite richten, die diese erfüllen soll,
solange auf der indischen Seite Nachtruhe herrscht. Im Gegenzug müsste die deutsche
Seite am Ende ihres Arbeitstages Aufgaben nach Indien schicken, damit diese noch vor
dem deutschen Arbeitsbeginn des folgenden Tages begonnen werden können.
ƒ
Prozessverbesserung beim Kunden
Weitere prozessbezogene Ziele beziehen sich direkt auf existierende Prozesse des Kunden. Eine Auslagerung einzelner IT-Funktionen, wie zum Beispiel der Softwareentwicklung, kann von einem Kunden als Mittel eingesetzt werden, um interne Konflikte
zu lösen. Weiter erhöht eine Auslagerung die Transparenz der IT-Abteilung des Kunden, denn Kosten und Leistungen werden direkter sichtbar. Damit wird eine interne
Überprüfung der eigenen Effizienz erleichtert. Die Konditionen eines Anbieters im
Rahmen einer Auslagerung können dabei als Benchmark für die IT-Abteilung des Kunden dienen. Schließlich fördern insbesondere Entwicklungsprojekte auf Basis von Festpreisverträgen die Planbarkeit auf der Seite des Kunden, da die Kosten für die vereinbarten Leistungen bereits zu Beginn des Projekts feststehen.
2.7.2.7 Produktbezogene Ziele
Die vierte Kategorie von Zielen, die mit der Auslagerung von bestimmten ITFunktionen verfolgt wird, sind produktbezogene Ziele. Mit Produkt wird hier die zu
entwickelnde Software bezeichnet.
In der untersuchten Literatur308 lässt sich aus Perspektive des Kunden ein produktbezogenes Ziel erkennen, nämlich die Steigerung der Produktqualität. Die Autoren der untersuchten Literatur argumentieren, dass diese Steigerung durch eine höhere technische
Erfahrung des Anbieters erreicht werden kann. Tabelle Tab. 2-14 fasst die Ergebnisse
der Untersuchung zusammen. Im Einzelnen gehen die Autoren in den identifizierten
Artikeln jedoch nicht im Detail darauf ein, was unter einer hohen Produktqualität ver-
308
Siehe hierzu Kapitel 2.7.2.
85
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
standen wird. Insbesondere findet kein Bezug auf ein zugrunde gelegtes Qualitätsmodell309 statt.
Autoren [in den Zellen ist die zugehörige
Seitenzahl angegeben]
Erreichen des Ziels durch
Alner /Effects/
Baldwin, Irani, Love /Outsourcing/
Barthelemy /Hidden cost/
Clark Jr., Zmud, McCray /Nature/
Grover, Cheon, Teng /Outsourcing/
Jurison /Role of risk/
Khan u. a. /Evaluating/ (auch in Khan, Currie,
Weerakkody /Strategies/)
Khosrowpour, Subramanian, Gunterman
/Organizational benefits/
Klepper, Jones /Outsourcing/
Lacity, Hirschheim, Willcocks /Realizing/
McFarlan, Nolan /IT Outsourcing/
Ramarapu, Parzinger, Lado /Issues/
Tafti /Risks factors/
Fähigkeiten des
Anbieters
Steigerung der
Produktqualität
Ziele
35
23
60
228
37
240
4
246
49
13
13
28
550
Tab. 2-14 Produktbezogene Ziele einer Outsourcing-Entwicklung aus Kundenperspektive
2.7.3
Ziele aus Perspektive des Anbieters
Die Ziele eines Anbieters werden in der vorliegenden Literatur310 wesentlich seltener
untersucht, als dies mit Zielen von Kunden einer Offshore-Entwicklung der Fall ist.
Daher ist es nicht hilfreich die Ergebnisse eines Literatur-Reviews in tabellarischer
Form zu präsentieren, wie es mit Zielen aus Perspektive der Kunden in den vorangegangenen Kapiteln erfolgt ist.
309
310
Bekannte Qualitätsmodelle für Software sind zum Beispiel die Norm DIN /DIN 66272/ oder ISO, IEC
/ISO 9126/.
Siehe hierzu Kapitel 2.7.2.
86
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
2.7.3.1 Prozessbezogene Ziele
Das Tagesgeschäft eines Anbieters besteht darin, Entwicklungs- oder Wartungsprojekte
für unterschiedliche Kunden abzuwickeln. Dabei ist es für den langfristigen Unternehmenserfolg des Anbieters von Bedeutung, dass die Prozesse einzelner Projekte stabil
ablaufen. Mit (Prozess-)Stabilität werden dabei die Planbarkeit und die Vorhersehbarkeit in Bezug auf Projektdauer und -kosten sowie die Wiederholbarkeit ähnlicher Projekte bezeichnet.311
Insbesondere bei Festpreisprojekten ist es für den Anbieter notwendig über stabile
Prozesse zu verfügen, um Projektkosten möglichst präzise schätzen zu können. Denn
der Anbieter trägt die zusätzlichen Kosten, die entstehen, falls das mit dem Kunden
vereinbarte Budget überschritten wird, um die vereinbarte Leistung zu erbringen. Mit
der Umsetzung existierender Softwareentwicklungsmodelle wie zum Beispiel CMMi
oder ISO 9000 wird versucht, eine hohe Prozessstabilität zu erreichen. Diese Modelle
versuchen mittels Standardisierung, Reglementierung und Disziplinierung von Methoden, Verfahren und Vorgehensweisen sowie durch Dokumentation und quantitative
Kontrolle eine Stabilisierung der Entwicklungsprozesse zu erreichen, um die Entwicklungsproduktivität zu erhöhen und die Entwicklungskosten zu senken.312 Insbesondere
bei indischen Offshore-Anbietern ist zu erkennen, dass sie das Ziel verfolgen eine möglichst hohe Reifegradstufe der Softwareentwicklungsmodelle zu erreichen.313
Weiter ist der Anbieter an niedrigen Projektkosten interessiert. Zum einen kann er
dadurch dem Kunden ein niedriges Angebot zur Abwicklung eines Projekts unterbreiten
und sich so gegebenenfalls gegenüber seinen Konkurrenten durchsetzen. Zum anderen
besteht für ihn bei niedrigen Projektkosten die Möglichkeit die Gewinnmarge zu erhöhen. Neben dem Einsatz produktiver Projektteams314 können niedrige Projektkosten
auch durch die Ausnutzung von Lohnkostenunterschieden zwischen den DACH-Staaten
und Indien erreicht werden. Wenn dies angestrebt wird, wird der Anbieter versuchen
311
312
313
314
Eine ähnliche Begriffsverwendung findet sich bei Mellis /Projektmanagement/ 50f.
Vgl. Mellis, Stelzer /Rätsel/ 37.
Siehe hierzu auch Kapitel 2.2.6.
Siehe hierzu auch die Erläuterungen zur Erreichung einer kürzeren Entwicklungsdauer in Kapitel
2.7.2.6.
87
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
personalintensive Aufgaben eher von Projektmitgliedern in Indien erfüllen zu lassen als
von Personal in den DACH-Staaten.315
2.7.3.2 Kundenbindungsziele
Wie bereits in Kapitel 2.7.1 dargestellt, stellt die Gewährleistung der Zahlungsfähigkeit
ein wesentliches Ziel von Softwareunternehmen dar. Dieses kann durch die Erwirtschaftung konstanter Gewinnmargen erreicht werden.316 Aus Sicht des Anbieters haben
langfristige Beziehungen zu Kunden den Vorteil das Geschäftsvolumen zu stabilisieren
und damit die weitere Planung der Unternehmensentwicklung zu fördern.317
Zwei Mittel, um eine langfristige Kundenbindung zu erzielen, sind die Erreichung einer
hohen Kundenzufriedenheit und die Ausnutzung von Lock-In-Mechanismen.
ƒ
Kundenzufriedenheit
Grundsätzlich wird eine hohe Kundenzufriedenheit angestrebt, damit sich die Chancen
auf Folgeprojekte und neue Geschäftsbeziehungen aufgrund positiver Erfahrungsberichte von zufriedenen Kunden erhöhen.
Allgemein wird eine hohe Kundenzufriedenheit erreicht, wenn die Erwartungen des
Kunden an den Projektverlauf und das Projektergebnis erfüllt oder sogar übertroffen
werden.
ƒ
Lock-In
Mit Lock-In wird allgemein der Sachverhalt beschrieben, wenn durch den Wechsel von
einem System zu einem anderen Kosten entstehen.318 Diese Kosten können neben den
reinen Anschaffungskosten vor allem Kosten für die Migration von Datenbeständen,
den Erwerb von neuen Zusatzkomponenten, falls alte Komponenten nicht mehr unterstützt werden oder Trainingskosten für das neue System umfassen. Welche Wechselkosten im Einzelnen anfallen hängt von dem betrachteten System ab. Je höher die Wechselkosten sind, desto höher ist der Lock-In-Effekt, da somit der Wechsel erschwert wird.
315
316
317
318
Zu den Lohnkostenunterschieden siehe auch Kapitel 2.2.4 und 2.7.2.4.
Auch Dibbern u. a. /Survey/ 8 stellen als Unternehmensziel eines Anbieters das Erzielen von langfristigen Einnahmen dar.
Vgl. Dibbern u. a. /Survey/ 8.
Vgl. zu diesem Absatz Shapiro, Varian /Information rules/ 11-13 bzw. Shapiro, Varian /Online/ 25.
88
Darstellung der Offshore-Entwicklung – Darstellung des Elements Ziele und Erwartungen
Es können unterschiedliche Arten von Lock-In unterschieden werden. Bei Shapiro und
Varian werden sieben Arten von Lock-In unterschieden,319 wie zum Beispiel markenspezifisches Training oder Informationen und Datenbanken. Jede dieser Arten weist
dabei eigene Wechselkosten auf.
Lock-In-Effekte ergeben sich aber nicht nur bei Produkten, sondern können sich auch
bei der Individualsoftware-Entwicklung wie der Offshore-Entwicklung ergeben.320
Lock-In entsteht in diesem Fall durch die gegenseitig aufgebaute Erfahrung zwischen
Anbieter und Kunden. Diese Erfahrungen umfassen Kenntnisse über Arbeitsweisen und
Geschäftsprozesse des Kunden, persönliche Beziehungen zwischen Mitarbeitern beider
Unternehmen und eine aufgebaute Vertrauensbasis. Diese Erfahrungen müssten bei
einem Anbieterwechsel erst wieder neu aufgebaut werden. Zusätzlich trägt der Kunde
das Risiko einen neuen Anbieter in punkto Qualität, Zuverlässigkeit und Planungstreue
richtig einzuschätzen. Im Fall von Weiterentwicklung oder Wartung entstehen dem
Anbieter Kosten für die Einarbeitung in das existierende System. Diese Kosten wird der
neue Anbieter vermutlich auf den Kunden abwälzen.
Aus Sicht eines Anbieters sind die skizzierten Lock-In-Effekte als erstrebenswert zu
bewerten, da ein Kunde im Fall hoher Wechselkosten nicht so leicht den Anbieter wechseln wird und somit mit langfristigen Einnahmen zu rechnen ist. Daher wird ein Anbieter versuchen Lock-In-Mechanismen aufzubauen, um den Kunden möglichst langfristig
an sich zu binden. Aus Sicht des Kunden sind dagegen hohe Wechselkosten eher negativ zu beurteilen, da dadurch die Flexibilität zu einem anderen Anbieter zu wechseln
eingeschränkt wird.
Insgesamt treten Lock-In-Effekte vermehrt erst bei längerfristigen Beziehungen auf,
sodass diese Effekte auf der Ebene einzelner Projekte, wie sie bei der FallstudienUntersuchung in Kapitel 3 eingenommen wird, eine untergeordnete Bedeutung besitzen.
Daher wird nicht vertiefend untersucht, inwiefern Lock-In-Effekte in einem konkreten
Projekt aufgebaut werden.
319
320
Vgl. Shapiro, Varian /Information rules/ 117 bzw. Shapiro, Varian /Online/ 157.
Vgl. zu diesem Absatz Aubert, Patry, Rivard /Assessing/ 3; Heinzl /Outsourcing/ 626; Mellis
/Projektmanagement/ 26f. und Ramarapu, Parzinger, Lado /Issues/ 30.
89
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
2.8
Darstellung des Elements Risiken
Im Folgenden werden zunächst die Begriffe Risiko und Risikofaktoren geklärt. Anschließend werden systematisch Risiken anhand der vorliegenden Literatur identifiziert,321 einzelnen Bereichen des „work system“-Betrachtungsrahmens zugeordnet und
die Relevanz der einzelnen Bereiche für diese Arbeit diskutiert. Damit wird die Grundlage für eine zielgerechte Fallstudien-Untersuchung geschaffen.
2.8.1
Klärung der Begriffe Risiko und Risikofaktoren
Unter einem Risiko wird hier die Gefahr verstanden, dass gesetzte Ziele einer OffshoreEntwicklung nicht erreicht werden.322 Im Folgenden werden diese Risiken genauer
dargestellt. Eine Möglichkeit, das Konstrukt Risiko zu präzisieren, ist die Unterscheidung von Risiken und Risikofaktoren. Dabei sind Risikofaktoren Einflussgrößen,
deren Präsenz die Wahrscheinlichkeit des Eintretens eines Risikos erhöht.323 Zum Beispiel erhöht der Risikofaktor „Rauchen“ die Wahrscheinlichkeit, einen Herzinfarkt (=
Risiko) zu erleiden, und gefährdet damit das Ziel eines langen Lebens.324 Die folgende
Abbildung (Abb. 2-12) soll diese Zusammenhänge veranschaulichen.
Risikofaktor
Ursache,
Sachverhalt,
Risiko
Ziele
erhöht
Wahrscheinlichkeit auf
Gefahrensituation,
problematisches
Ereignis
gefährdet
Ziele
Rauchen
erhöht
Wahrscheinlichkeit auf
Herzinfarkt
gefährdet
langes
Leben
Große geogr.
Distanz zw.
Anbieter und
Kunde
erhöht
Wahrscheinlichkeit auf
Kommunikationsprobleme
gefährden
Kostenreduktion
Abb. 2-12 Begriffliche Trennung von Risikofaktor - Risiko – Ziele
321
322
323
Siehe hierzu Kapitel 2.7.2 und Kapitel 2.8.2.
Damit liegt in dieser Arbeit ein traditionelles „Risiko“-Begriffsverständnis vor, wie es auch laut einer
Umfrage des Cutter Consortiums mehrheitlich von den befragten IT-Managern verstanden wird.
Vgl. hierzu Cutter Consortium /Risk management/. Auch bei IEEE /IEEE Std 1540-2001/ 3 oder
Wallmüller /Risikomanagement/ 6 wird Risiko ebenfalls mit dem Eintreten eines negativen Ergebnisses definiert. Bei Alter, Sherer /Model of IS risk/ 5 werden hingegen auch unerwartete positive
Ergebnisse unter dem Begriff Risiko subsumiert.
Vgl. Sherer, Alter /Risk factors/ 32.
90
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
Die Trennung in Risikofaktoren und Risiken soll helfen Ursachen zu erkennen, die das
Erreichen verfolgter Ziele gefährden. Gleichzeitig ist diese Trennung nicht deterministisch, sondern eher interpretativ.
Risiken und Risikofaktoren können meistens in weitere Ursache-Wirkungs-Ketten
zerlegt werden, sodass erstmalig identifizierte Risikofaktoren nach einer Zerlegung als
Risiko bezeichnet werden können. Die Verwendung der Begriffe Risiko und Risikofaktoren hängt damit von der jeweils betrachteten Detailebene, bzw. von den jeweils
zugrunde gelegten Zielen ab.
Aus diesem Grund wird grundsätzlich im Folgenden auf eine begriffliche Trennung
zwischen Risikofaktor und Risiko verzichtet und allgemein von Risiken gesprochen.
Erst wenn es bei einer genaueren Analyse der Ursachen einzelner Risiken nützlich ist,
wird zwischen Risikofaktoren und Risiken unterschieden. Grundsätzlich werden Risiken in dieser Arbeit so verstanden, dass ihr Eintreten zu einer Gefährdung der Erreichung aufgestellter Ziele von Offshore-Projekten führt.
2.8.2
Vorgehen zur Identifikation von Risiken in der Offshore-Entwicklung
Um in der Literatur behandelte Risiken von Offshore-Projekten zu identifizieren, wurde
die gleiche Vorgehensweise angewendet wie bei der Identifikation von Zielen.325
Bei dem vorliegenden Review wurden die durch das schematische Vorgehen gefundenen Artikel um Artikel aus weiteren Zeitschriften und Büchern ergänzt, sodass insgesamt über 40 Artikel verwendet wurden.
Die identifizierten Risiken wurden anschließend den acht Elementen des „work system“
(= Bereiche) zugeordnet, um sie systematisch betrachten zu können.326 Eine tabellarische Darstellung aller identifizierten und zugeordneten Risiken befindet sich im Anhang
B.
324
325
326
Das Beispiel ist angelehnt an Wallmüller /Risikomanagement/ 6.
Eine ausführliche Beschreibung dieses Vorgehens befindet sich in Kapitel 2.7.2.
Diese Vorgehen entspricht dem Vorgehen bei Sherer, Alter /Risk factors/ 47-56.
91
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
2.8.3
Fokussierung auf ausgewählte Risiken
2.8.3.1 Kriterien zur Fokussierung auf ausgewählte Risiken
Mit Hilfe der acht Elemente (= Bereiche) des Betrachtungsrahmens „work system“, die
im Abschnitt 1.5.4 genauer dargestellt wurden, lassen sich Risiken eines OffshoreEntwicklungsprojekts klassifizieren und damit systematisch betrachten.327
Bevor Risiken in den einzelnen Bereichen im Rahmen der Fallstudienerhebung genauer
betrachtet werden, bietet es sich an zu entscheiden, ob Risiken in allen Bereichen (=
Risikobereiche) für den Fokus der Arbeit relevant sind. Dazu werden insbesondere die
folgenden Entscheidungskriterien angewendet:
ƒ
Offshore-spezifische Risiken:
Risiken des betrachteten Bereichs müssen im Zusammenhang mit Besonderheiten328 der Offshore-Entwicklung stehen.
ƒ
Organisatorische Beeinflussbarkeit:
Risiken des betrachteten Bereichs müssen durch die organisatorische Gestaltung
beeinflussbar sein, da dies der Zielsetzung der vorliegenden Arbeit entspricht.
ƒ
Projektebene:
Da der Fokus der Arbeit auf der organisatorischen Gestaltung von OffshoreProjekten liegt, müssen die erkannten Risiken auf der Ebene einzelner Projekte
auftreten.
Im Folgenden wird nun die Relevanz der einzelnen Bereiche mit Hilfe dieser Kriterien
beurteilt. Anschließend kann sich die Erhebung der Fallstudie auf diese als relevant
erachteten Bereiche konzentrieren. Innerhalb der relevanten Bereiche helfen die genannten drei Entscheidungskriterien konkrete Risiken in der vorliegenden Literatur zu identifizieren, die im Rahmen dieser Arbeit näher betrachtet werden sollen. Wurden in einem
327
328
Sherer und Alter haben mit Hilfe des Betrachtungsrahmens 228 Risikofaktoren aus 46 Artikeln
klassifiziert. Vgl. Sherer, Alter /Risk factors/ 47-56.
Zu den Besonderheiten der Offshore-Entwicklung siehe insb. Kapitel 2.2.
92
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
Bereich relativ viele Risiken identifiziert, wurden diese aus Gründen der Übersichtlichkeit zusätzlich in einzelne Arten gegliedert.
2.8.3.2 Risiken im Bereich Infrastruktur
Zum Bereich Infrastruktur gehören nicht projektspezifische technische Hilfsmittel und
Personal, welche zur Projektabwicklung genutzt werden können, deren Verwaltung
bzw. Betreuung aber außerhalb des Projekts liegt. Hierunter fallen zum Beispiel Firmennetzwerke und deren Administration, gemeinsame Datenbanken oder auch Schulungspersonal.
Die Zuverlässigkeit der Telekommunikationsinfrastruktur und der Stromversorgung von
Offshore-Anbietern wurde zwar von manchen Autoren als problematisch dargestellt,329
doch heutzutage stellt die technische Infrastruktur bei den „großen“ indischen Anbietern330 kein Problem mehr dar. Sie verfügen über eigene „Technologie Parks“ oder sind
an staatliche „Technologie Parks“ angebunden, die über Satellitenanbindung, unabhängige Stromversorgung und moderne Netzwerke verfügen.331
Eine adäquate Infrastruktur ist zwar die Voraussetzung zur Implementierung von Kommunikationsprozessen, doch im Rahmen dieser Arbeit stehen organisatorische Gestaltungsmaßnahmen im Vordergrund und nicht deren technische Implementierung.
Ziel dieser Arbeit ist es die organisatorische Gestaltung einzelner OffshoreEntwicklungsprojekte zu untersuchen. Daher werden projektübergreifende technische
Hilfsmittel und Personal nicht näher betrachtet. Dementsprechend wird auf Risiken im
Bereich der Infrastruktur nicht weiter eingegangen.
Eine Fragebogenerhebung mit Teilnehmern aus 275 Unternehmen – 75 davon führen
Offshore-Entwicklungen in Nicht-G7-Staaten durch – hat ergeben, dass aus dem Bereich Infrastruktur nur selten Probleme resultieren, die die tägliche Zusammenarbeit
329
330
331
Vgl. Aron, Clemons, Reddi /Understanding/ 3; Carmel, Agarwal /Maturation of offshore sourcing/ 68;
Dedene, De Vreese /Realities/ 44; Deutsche Bank Research /Outsourcing/ 11; Khan u. a.
/Evaluating/ 4; Kliem /Managing the risks/ 25 und Ramarapu, Parzinger, Lado /Issues/ 29.
In Kapitel 2.6.1 werden die großen indischen Anbieter von Offshore-Entwicklungen vorgestellt.
Vgl. Deutsche Bank Research /Outsourcing/ 11 oder Rao /Key issues/ 17. Auch auf den Webseiten
und in Unternehmensbroschüren der Anbieter und auf den Webseiten der NASSCOM sind diese Informationen über die vorhandene Infrastruktur nachzulesen. Vgl. NASSCOM /Infrastructure/;
NASSCOM /Tech parks/; TCS /Application development/; WIPRO /Infrastructure/; Infosys /Client
connectivity/.
93
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
erschweren.332 Dies unterstützt die Entscheidung, Risiken in diesem Bereich im Rahmen der vorliegenden Arbeit nicht zu vertiefen.
2.8.3.3 Risiken im Bereich Umwelt
Der Bereich Umwelt umfasst insbesondere die Besonderheiten333 der OffshoreEntwicklung und übernimmt damit eine zentrale Rolle in dieser Arbeit. Daher werden
Risiken in diesem Bereich betrachtet, sofern ihnen mit organisatorischen Maßnahmen
begegnet werden kann und die Risiken auf der Ebene einzelner Projekte auftreten.
Risiken im Bereich Umwelt lassen sich in drei Arten gliedern: landesspezifische Risiken, Risiken aufgrund räumlicher und zeitlicher Distanz und Risiken aufgrund kultureller Unterschiede.
ƒ
Landesspezifische Risiken
Zu den landesspezifischen Risiken zählen insbesondere politische und juristische Unsicherheiten im und gegenüber dem Land des Anbieters.334 Zu den politischen Unsicherheiten gehören zum Beispiel Instabilität im Land oder Gefahr von Streiks.335 Allerdings
wird insbesondere Indien eine relativ hohe Stabilität zugeschrieben.336 Beispiele für
juristische Unsicherheiten können mangelnde Erfahrungen mit dem jeweils anderen
Rechtssystem sein, Handelsbeschränkungen oder keine ausreichende juristische Grundlage zum Schutz des geistigen Eigentums.337
332
333
334
335
336
337
Vgl. Moczadlo /Chancen und Risiken/.
Die Besonderheiten der Offshore-Entwicklung werden in Kapitel 2.2 ausführlich vorgestellt. Sie
umfassen u. a. die räumliche und zeitliche Distanz und kulturelle Unterschiede zwischen den am
Projekt beteiligten Personen.
Vgl. hierzu Aron, Clemons, Reddi /Understanding/ 3; Delmonte, McCarthy /Offshore/ 1609; Khan,
Currie, Weerakkody /Strategies/ 4; Khan u. a. /Evaluating/ 4 oder eine Studie über kulturelle und
rechtliche Barrieren von Deloitte & Touche: Outsourcing und Offshoring mit indischen ITUnternehmen. Die IT-Welt im Wandel, 2003 nach Ben, Claus /Offshoring/ 37.
Vgl. Delmonte, McCarthy /Offshore/ 1609; Deutsche Bank Research /Outsourcing/ 11; Khan u. a.
/Evaluating/ 4 oder Ramarapu, Parzinger, Lado /Issues/ 29.
Vgl. Bremmer /Managing risk/ 53. Hier wird auf den Deutsche Bank Eurasia Group Stability Index
(DESIX) von März 2005 zurückgegriffen.
Vgl. Apte u. a. /Outsourcing practices/ 297; Aubert, Patry, Rivard /Assessing/ 6; Aubert u. a. /British
Petroleum/ 2; Kliem /Managing the risks/ 25 oder Ramarapu, Parzinger, Lado /Issues/ 29.
94
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
Weiter umfassen landesspezifische Risiken auch Währungsrisiken,338 die Schwierigkeit
notwendige Arbeitsvisa zu bekommen,339 Schwierigkeiten bestimmte technische Geräte
oder Verschlüsselungsalgorithmen aufgrund staatlicher Reglementierungen zu verwenden340 oder generelle Mängel in einer unternehmensübergreifenden Infrastruktur.
Diese Darstellung landesspezifischer Risiken verdeutlicht, dass diese Risiken nicht
durch eine organisatorische Gestaltung auf der Ebene einzelner Projekte beeinflusst
werden können und daher im weiteren Verlauf dieser Arbeit nicht tiefgehender betrachtet werden.
ƒ
Risiken aufgrund räumlicher und zeitlicher Distanz
Eine Trennung zwischen Risiken aufgrund räumlicher Distanz und Risiken aufgrund
zeitlicher Distanz ist an dieser Stelle nicht hilfreich, da eine starke gegenseitige Beeinflussung stattfindet. Zum Beispiel führt sowohl die räumliche als auch die zeitliche
Distanz dazu, dass keine face-to-face Kommunikation stattfinden kann. Konsequenzen
von mangelnder face-to-face Kommunikation werden in unterschiedlichen Studien
untersucht341 und im Folgenden näher betrachtet.
Bei global verteilt arbeitenden Teams wird vermehrt über computergestützte Medien
(engl. computer mediated communication) kommuniziert342 – dazu zählen zum Beispiel
E-Mail, Internet-Chat, Diskussionsforen – dies kann gegenüber einer face-to-face
Kommunikation eher zu Missverständnissen führen.343 Ein Grund dafür kann sein, dass
bei computergestützter Kommunikation die Gefahr steigt unvollständige Informationen
zu übermitteln und so zum Beispiel relevante Kontextinformationen fehlen, um die
übermittelte Nachricht korrekt verstehen zu können.344 Zum anderen bieten Kommuni338
339
340
341
342
343
344
Vgl. Aron, Clemons, Reddi /Understanding/ 3; Delmonte, McCarthy /Offshore/ 1609 oder Kliem
/Managing the risks/ 25.
Vgl. Carmel, Agarwal /Maturation of offshore sourcing/ 68 oder Kumar, Willcocks /Country/ 1317.
Vgl. Ramarapu, Parzinger, Lado /Issues/ 30.
Vgl. z. B. Armstrong, Cole /Managing distances/; Maznevski, Chudoba /Bridging space/ 475; Mortensen, Hinds /Conflict/; Nardi, Whittaker /Face-to-face/; Straus, McGrath /Medium/ 93; Kraut u. a.
/Task requirements/ oder Warkentin, Sayeed, Hightower /Virtual teams/.
Vgl. z. B. Krepchin /Offshore/ 56.
Vgl. Armstrong, Cole /Managing distances/ 168, 170; Cramton /Mutual knowledge problem/ 355,
Espinosa, Carmel /Dyad model/ 6f. und Kraut u. a. /Task requirements/ 387f.
Vgl. Cramton /Mutual knowledge problem/ 355, 360.
95
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
kationsmedien gegenüber einer face-to-face-Kommunikation ein niedrigeres Informationspotential345, da sie gegebenenfalls auf paraverbale (Stimmlage, Betonung) und nonverbale (Augenbewegungen, Körpersprache) Elemente verzichten.346 Die Entstehung
von Missverständnissen wird auch dadurch gefördert, dass insbesondere bei asynchroner Kommunikation über verschiedene Zeitzonen hinweg ein schnelles korrigierendes
Feedback erschwert oder sogar verhindert werden kann, wenn zum Beispiel Wartezeiten
zwischen den Antworten entstehen.347
In unterschiedlichen Untersuchungen wurde beobachtet, dass Kommunikation bei geografisch verteilt arbeitenden Teams langsamer und weniger effektiv abläuft.348 Gegenüber einem Team, das nur an einem Ort arbeitet, kann es zu Verzögerungen bei Abstimmungsprozessen kommen,349 wenn zum Beispiel auf Antworten gewartet werden
muss.350 Eine weitere Schwierigkeit ist, dass es aufwändiger ist Termine für gemeinsame Telefon- oder Videokonferenzen zu organisieren.351
Aufgrund des geringeren Informationspotentials352 von computergestützter Kommunikation gegenüber face-to-face Kommunikation besteht auch die Gefahr, dass quantitativ
umfangreichere Informationen ausgetauscht werden, um dieses Defizit auszuglei-
345
346
347
348
349
350
351
352
Vgl. Kapitel 2.4.9.
Vgl. Karolak /Global software development/ 17f. oder Warkentin, Sayeed, Hightower /Virtual teams/
978.
Vgl. Armstrong, Cole /Managing distances/ 170; Cramton /Mutual knowledge problem/ 362f.;
Espinosa, Carmel /Dyad model/ 6f. und Warkentin, Sayeed, Hightower /Virtual teams/ 978.
Vgl. Aron, Clemons, Reddi /Understanding/ 3; Carmel, Agarwal /Global software development/ 23;
Espinosa, Carmel /Dyad model/ 2; George u. a. /Collaborative group work/ 408f.; Herbsleb, Mockus
/Empirical/ 491; Hightower, Sayeed /Effects/ 462; Karolak /Global software development/ 17; Kraut
u. a. /Task requirements/ 390; McDonough, Kahn, Griffin /Managing communication/ 379; Prikladnicki, Audy, Evaristo /Lessons learned/ 275; Straus /Technology/ 252; Straus, McGrath /Medium/
93; Teasley u. a. /Rapid software development/ 672f. und Warkentin, Sayeed, Hightower /Virtual
teams/ 978. Allerdings konnten hingegen z. B. Chudoba u. a. /Virtuality/ 296 in ihrer Studie diesen
Effekt nicht nachweisen.
Vgl. Espinosa, Carmel /Dyad model/ 6f.; Herbsleb, Mockus /Empirical/ 491; Herbsleb u. a. /Distance/
323 und Prikladnicki, Audy, Evaristo /Lessons learned/ 275.
Dies konnte zum Beispiel bei Experimenten mit Studenten beobachtet werden. Vgl. hierzu Kraut u. a.
/Task requirements/ 390.
Vgl. Armstrong, Cole /Managing distances/ 171.
Zur Erläuterung des Begriffs Informationspotential im Rahmen der „media richness theory“ siehe
Abschnitt 2.4.9.
96
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
chen.353 Dadurch kann sowohl bei der Erstellung der übermittelten Information als auch
bei der Aufnahme der Information ein höherer Aufwand entstehen, als dies bei einer
face-to-face Kommunikation der Fall gewesen wäre.
Schließlich kann durch räumliche und zeitliche Distanz das Auffinden des richtigen
Ansprechpartners erschwert werden354 oder es können längere Kommunikationswege
zwischen Endanwendern und Entwicklern entstehen.355 Dadurch können sich zeitliche
Verzögerungen und zusätzlicher Aufwand ergeben.
Eine weitere Konsequenz von räumlicher und zeitlicher Distanz und dem damit verbundenen verstärkten Einsatz von computergestützter Kommunikation ist, dass informelle
und spontane Kommunikation erschwert wird und weniger häufig stattfindet.356 Dabei
fördert informelle Kommunikation Koordination, gegenseitiges Lernen in Teams und
die Entwicklung von Vertrauen.357 Grundsätzlich wird der informellen Kommunikation
bei der Softwareentwicklung eine hohe Bedeutung zugeschrieben.358
Zusammenfassend kann festgehalten werden, dass räumliche und zeitliche Distanz
innerhalb von Projektteams folgende Risiken verstärken:
353
354
355
356
357
358
ƒ
Missverständnisse in der Kommunikation
ƒ
Weniger effiziente Kommunikation
ƒ
Weniger informelle und spontane Kommunikation
Dies konnte z. B. in einem Experiment mit Studenten bei Kraut u. a. /Task requirements/ 387f. nachgewiesen werden. Vgl. auch Battin u. a. /Global software development/ 70f.
Vgl. Herbsleb, Mockus /Empirical/ 489; Herbsleb u. a. /Distance/ 325 oder Szulanski /Internal stickiness/ 31f.
Vgl. Earl /Risks/ 30.
Vgl. Armstrong, Cole /Managing distances/ 169; Herbsleb, Mockus /Empirical/ 481; Mortensen,
Hinds /Conflict/ 214; Nardi, Whittaker /Face-to-face/ 84, 86f. und Straus /Technology/ 255. Herbsleb u. a. /Distance/ 320 verweisen auf mehrere Studien die belegen, dass die Häufigkeit an Kommunikation mit zunehmender Entfernung abnimmt. In einer Untersuchung von Damian, Zowghi
/Impact/ 6 konnten in einer zwischen Australien und Neuseeland verteilten Entwicklung keine negativen Konsequenzen nachgewiesen werden. Allerdings fand in diesem Fall eine häufige synchrone
Kommunikation statt und beide Seiten verfügten über ein sehr umfangreiches Wissen über das betroffene IT-System.
Vgl. Faraj, Sproull /Coordinating expertise/ 1557; Heeks u. a. /Synching/ 59 oder Nardi, Whittaker
/Face-to-face/86f.
Vgl. u. a. Curtis, Krasner, Iscoe /Software design process/ 1279; Delmonte, McCarthy /Offshore/
1609; Herbsleb, Moitra /Global software development/ 18; Herbsleb u. a. /Distance/ 320; Kraut,
Streeter /Coordination/ 75, 77; Teasley u. a. /Rapid software development/ 672f. oder Perry, Staudenmayer, Votta /Process improvement/ 42.
97
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
Diese Risiken können sich negativ auf die Erreichung der Projektziele Budgeteinhaltung, Termintreue und Umsetzung der vom Kunden erwarteten Produktanforderungen
auswirken.
ƒ
Risiken aufgrund kultureller Unterschiede
McDonough, Kahn, Griffin haben beobachtet, dass Sprache einen Einfluss auf die
Zusammenarbeit von globalen Teams hat.359 Die Komplexität und der Umfang der
verbal vermittelten Informationen ist in einer multi-lingualen Situation geringer, als
wenn die Beteiligten die gleiche Muttersprache sprechen.
Sprachliche Unterschiede können daher insbesondere bei verbaler Kommunikation zu
Missverständnissen führen, die eine Erreichung der gesetzten Projektziele gefährden
können.360 Gleichzeitig besteht die Möglichkeit, dass bei einer Kommunikation in englischer Sprache bei den deutschsprachigen Beteiligten ein gewisses Gefühl der Unsicherheit und des Unwohlseins auftritt.361
Bei schriftlicher Kommunikation fällt dies weniger ins Gewicht, da unklare Aussagen
oder Begriffe im Lexikon nachgeschlagen werden können. Dabei entsteht allerdings ein
zusätzlicher Aufwand. Sprachliche Unterschiede können sich auch auf die technische
Realisierung auswirken, wenn zum Beispiel unvorhergesehene Komplikationen bei der
Verwendung unterschiedlicher Datumsformate oder von landesspezifischen Sonderzeichen auftreten.362
Abweichende Wertvorstellungen und Einstellungen aufgrund kultureller Unterschiede
können in global agierenden Teams Ursache für Missverständnisse363 oder Konflikte
sein.364 Insbesondere kann das Verhalten in Vertragsverhandlungen oder dem Berichten
359
360
361
362
363
364
Vgl. zu diesem Absatz McDonough, Kahn, Griffin /Managing communication/ 379. Auch bei Apte u.
a. /Outsourcing practices/ 297 und Ramarapu, Parzinger, Lado /Issues/ 29 wird auf Konsequenzen
unterschiedlicher Sprachen hingewiesen.
Vgl. auch Apte u. a. /Outsourcing practices/ 297; DeLone u. a. /Boundaries/2f.; Delmonte, McCarthy
/Offshore/ 1609 oder Ramarapu, Parzinger, Lado /Issues/ 29.
Vgl. Stephan /Schlüsselfaktoren/ 216.
Vgl. Apte u. a. /Outsourcing practices/ 297; Herbsleb, Moitra /Global software development/18 oder
Ramarapu, Parzinger, Lado /Issues/ 29.
Vgl. Hatch /Offshore 2005/ 19 oder Prikladnicki, Audy, Evaristo /Lessons learned/ 275.
Vgl. Carmel, Agarwal /Maturation of offshore sourcing/ 68; Heinzl /Outsourcing/ 627 oder Kumar,
Willcocks /Country/ 1317.
98
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
von Schwierigkeiten während eines Projekts zwischen einem Asiaten und einem Europäer stark unterschiedlich sein.365
Kulturelle Unterschiede können den Aufbau von Vertrauen zwischen den Beteiligten
erschweren.366 Dieser Aspekt wird im Rahmen der Betrachtung von Risiken im Bereich
Beteiligte umfassender dargestellt.
Zusammenfassend sei erwähnt, dass die Ausführungen zu Risiken aufgrund räumlicher
und zeitlicher Distanz sowie kultureller Unterschiede gezeigt haben, dass alle drei Bereiche Einfluss auf die Kommunikation zwischen einem Anbieter und einem Kunden
von Offshore-Dienstleistungen haben. Kommunikationsfehler und Verzögerungen in
der Kommunikation können sich dabei stets negativ auf die verfolgten Projektziele
auswirken. Daher sind Risiken im Bereich Umwelt von signifikanter Bedeutung bei der
vorliegenden Untersuchung von Offshore-Entwicklungen.367 Gleichzeitig ist zu beachten, dass Kommunikationsrisiken aufgrund von Besonderheiten im Bereich Umwelt eng
mit Risiken im Bereich Geschäftsprozesse verbunden sind, da dort der organisatorische
Gestaltungsbereich der Kommunikation behandelt wird.
2.8.3.4 Risiken im Bereich Strategie
Unter dem Bereich Strategie wird in dieser Arbeit die strategische Ausrichtung des
Anbieters und des Kunden verstanden. Damit beschreibt dieser Bereich die langfristige
Ausrichtung von Handlungen der beiden Unternehmen. Dieses Element ist eng mit dem
Element Anbieter- und Kundenunternehmen verbunden.
Aus Perspektive des Kunden lassen sich grundsätzlich drei Arten strategischer Risiken
unterscheiden:368 Shirking, Poaching und Lock-In369
ƒ
365
366
367
368
369
Shirking
Vgl. z. B. Stephan /Schlüsselfaktoren/ 216.
Vgl. Bradach, Eccles /Price/ 107f.; Carmel, Agarwal /Maturation of offshore sourcing/ 68; Mayer,
Davis, Schoorman /Organizational trust/ 715 oder Maznevski, Chudoba /Bridging space/ 476.
Vgl. hierzu auch Delmonte, McCarthy /Offshore/ 1609.
Diese Unterscheidung wird von Aron, Clemons, Reddi /Understanding/ 3 aufgegriffen. Die Autoren
verwenden allerdings anstatt des Begriffs „Lock-In“ den Begriff „vendor hold-up“.
Da diese englischen Begriffe griffiger klingen als ihre deutschen Übersetzungen (Drückebergerei,
Wilderei und eingeschlossen) wird im Folgenden auf eine Übersetzung verzichtet.
99
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
Hiermit wird das Risiko bezeichnet, dass der Anbieter sich nicht im Sinn des Kunden
verhält und zum Beispiel weniger Engagement in die Erfüllung des Vertrags investiert
als vereinbart wurde und dadurch die erwarteten Leistungen nicht erbracht werden.370
ƒ
Poaching
Hiermit wird das Risiko bezeichnet, dass der Anbieter Daten, Informationen oder Software des Kunden an Dritte weitergibt.371 Dadurch kann der Kunde einen Nachteil erleiden, wenn das Vertrauen zu seinen Endkunden gestört wird oder Konkurrenten einen
Wettbewerbsvorteil erhalten.
ƒ
Lock-In
Hiermit wird das Risiko bezeichnet, dass der Kunde in eine Abhängigkeit vom Anbieter
gerät. Dies kann sowohl hohe Wechselkosten für den Kunden als auch kostspielige
Vertragsänderungen umfassen.372 In der Literatur wird dieser Effekt auch als Lock-In
bezeichnet.373
Die folgende exemplarische Diskussion für das Risiko Lock-In soll verdeutlichen, dass
generell Risiken im Bereich Strategie nicht im Fokus dieser Arbeit liegen und daher
nicht weiter betrachtet werden. Begründet kann dieser Ausschluss damit werden, dass
Risiken im Bereich Strategie zum Teil auf Mängeln in der Vertragsgestaltung oder auf
vorvertraglichen Entscheidungen, wie zum Beispiel Anbieter- oder Projektauswahl,
beruhen und kaum durch organisatorische Maßnahmen auf der Ebene einzelner Projekte
reduziert werden können.
370
371
372
373
Vgl. Aron, Clemons, Reddi /Understanding/ 3; Earl /Risks/ 28; Grover, Cheon, Teng /Outsourcing/
38; Hatch /Offshore 2005/ 105; Jurison /Role of risk/ 240 oder Kliem /Managing the risks/ 25.
Vgl. Alner /Effects/ 37; Earl /Risks/ 30; Apte u. a. /Outsourcing practices/ 297; Grover, Cheon, Teng
/Outsourcing/ 38; Hatch /Offshore 2005/ 102; Herbsleb, Moitra /Global software development/ 18;
Jurison /Role of risk/ 240; Khan u. a. /Evaluating/ 4; Khan, Currie, Weerakkody /Strategies/ 4;
Khosrowpour, Subramanian, Gunterman /Organizational benefits/ 256; Klepper, Jones
/Outsourcing/ 56; Tafti /Risks factors/ 553 und zur genaueren Verwendung des Begriffs poaching
siehe auch Clemons, Hitt /Poaching/.
Vgl. Aubert, Patry, Rivard /Assessing/ 6; Aubert u. a. /British Petroleum/ 2; Earl /Risks/ 28; Heinzl
/Outsourcing/ 626; Jurison /Role of risk/ 240 oder McLellan, Marcolin, Beamish /Financial and strategic motivations/ 309.
Erläuterungen zu Lock-In befinden sich in Kapitel 2.7.3.2. Lock-In als Risiko im Rahmen von Outsourcing-Projekten wird u. a. von Jurison /Role of risk/ 240; Khosrowpour, Subramanian, Gunterman /Organizational benefits/ 254 und Ramarapu, Parzinger, Lado /Issues/ 30 genannt.
100
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
Das Risiko Lock-In-Effekten374 ausgesetzt zu sein ist für die vorliegende Arbeit nicht
relevant, da in dieser Arbeit eine Betrachtung auf Projektebene erfolgt. Lock-In-Effekte
entstehen aber in der Regel über einen längeren Zeitraum und über mehrere Projekte.
Ein Kunde hat die Möglichkeit, bereits im Vorfeld einer Offshore-Entwicklung das
Risiko von Lock-In-Effekten zu minimieren. Dies kann durch die Projektauswahl (weniger strategische Projekte), vertraglich vereinbarte Projektleistungen (umfassende
Dokumentation, Verwendung von Standards, Übergabe von Quellcode) oder der Anbieterauswahl (nicht nur einen Anbieter auswählen) erfolgen.375 Dieser Arbeit liegt allerdings die Annahme zugrunde, dass diese Entscheidungen bereits getroffen wurden. Im
Mittelpunkt dieser Arbeit steht die organisatorische Gestaltung einzelner OffshoreEntwicklungsprojekte. Auf dieser Betrachtungsebene wird allerdings nicht primär gegen
Lock-In-Effekte vorgegangen.
Daher spielen Risiken im Bereich Strategie auf der Ebene einzelner Projekte eine untergeordnete Rolle und werden in dieser Arbeit nicht weiter betrachtet.
Neben den drei vorgestellten Arten von Risiken im Bereich Strategie zählt auch die
Gefahr, dass eine Outsourcing-Entscheidung die zukünftige Handlungsfähigkeit einschränkt, zu diesem Bereich. Diese Gefahr kann darin bestehen, dass die Flexibilität bei
Reaktion auf Unsicherheiten abnimmt, falls nicht mehr das eigene Personal (aus Sicht
des Kunden) mit der Entwicklungsaufgabe betraut ist.376 Weiter fällt in diesen Bereich
die Gefahr, dass strategisch bedeutende Aufgaben ausgelagert werden und damit die
eigenständige strategische Weiterentwicklung des Kunden eingeschränkt wird.377
Grundsätzlich gehören auch die verfolgten Ziele der Offshore-Entwicklung des Anbieters und des Kunden zum Bereich Strategie. Da sich Risiken stets auf das Verfehlen
374
375
376
377
Es ist zu beachten, dass Lock-In-Effekte nur aus der Perspektive des Kunden ein Risiko darstellen.
Aus der Perspektive des Anbieters kann dies hingegen sogar ein verfolgtes Ziel darstellen.
Die in den Klammern aufgeführten Beispiele dienen der Illustration.
Vgl. Clark Jr., Zmud, McCray /Nature/ 231; Earl /Risks/ 28; Grover, Cheon, Teng /Outsourcing/ 37f.;
Gupta, Gupta /Outsourcing/ 47-49; Jurison /Role of risk/ 240; Khan u. a. /Evaluating/ 4; Khan, Currie, Weerakkody /Strategies/ 4 oder Klepper, Jones /Outsourcing/ 56.
Vgl. Earl /Risks/ 28; Gupta, Gupta /Outsourcing/ 47-49; Khosrowpour, Subramanian, Gunterman
/Organizational benefits/ 254 oder Klepper, Jones /Outsourcing/ 57.
101
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
angestrebter Ziele beziehen,378 ist es im Rahmen dieser Arbeit nicht erforderlich im
Kontext von Risiken im Bereich Strategie zusätzlich auf einzelne Ziele näher einzugehen. Wenn zum Beispiel das Ziel „Kostenreduktion“ verfolgt wird, wäre es für die
Untersuchung in dieser Arbeit zu abstrakt das Risiko des Verfehlens dieses Ziels zu
betrachten. Vielmehr muss mit Hilfe der anderen Bereiche des „work system“ geklärt
werden, wodurch das Erreichen des Ziels „Kostenreduktion“ negativ beeinflusst werden
kann. Erst auf dieser Detailstufe lassen sich organisatorische Maßnahmen finden, um
dem Risiko entgegenzuwirken.
2.8.3.5 Risiken im Bereich Beteiligte
Der Bereich Beteiligte umfasst sämtliche Personen sowohl des Anbieters als auch des
Kunden, die an dem Projekt der Offshore-Entwicklung beteiligt sind.
Die organisatorische Gestaltung, die im Rahmen dieser Arbeit untersucht wird, betrifft
stets Mitglieder der betrachteten organisatorischen Einheiten. Abstimmungsprozesse
oder Kommunikation finden zwischen den beteiligten Personen statt. Demzufolge können organisatorische Maßnahmen maßgeblich Risiken im Bereich Beteiligte beeinflussen. Daher werden Risiken in diesem Bereich betrachtet.
Risiken im Bereich Beteiligte können zum Beispiel durch kulturelle Unterschiede der
Beteiligten hervorgerufen werden.379 Dieses Beispiel verdeutlicht, dass der Bereich
Beteiligte nicht überschneidungsfrei zum Bereich Umwelt ist. Allerdings fokussiert der
Bereich Beteiligte wesentlich stärker auf die einzelnen Individuen der OffshoreEntwicklung als dies im Bereich Umwelt der Fall ist.
In der vorliegenden Literatur zur Offshore-Entwicklung380 konnten folgende Risiken im
Bereich Beteiligte identifiziert werden:
ƒ
Fachliche, technische und organisatorische Kenntnisse der Beteiligten
Es besteht das Risiko, dass das Personal des Anbieters nicht über ausreichende fachliche
und/ oder technische Kenntnisse verfügt381 und dadurch mehr Zeit für die Projektab-
378
379
380
Vgl. zum Zusammenhang zwischen Risiken, Zielen und negativen Ergebnissen Kapitel 1.5.4.2 und
Kapitel 2.9.
Zu den kulturellen Unterschieden zählen auch sprachliche Unterschiede. Hierauf wird in Kapitel 2.2.3
eingegangen.
Eine Übersicht der dieser Arbeit vorliegenden Literatur befindet sich in 2.8.2.
102
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
wicklung benötigt bzw. die Kommunikation von Anforderungen umfangreicher und
detaillierter erfolgen muss. Falls das Management des Kunden über zu geringe Erfahrungen mit Offshore-Projekten verfügt, kann sich dies ebenfalls negativ auf eine reibungslose Projektabwicklung auswirken.382
ƒ
Sprachliche Fähigkeiten der Beteiligten
Da sprachliche Fähigkeiten der Beteiligten insbesondere bei der Zusammenarbeit von
Personen aus unterschiedlichen Nationen eine Rolle spielen, wird dieser Bereich an
potentiellen Risiken separat dargestellt und nicht bereits im vorherigen Absatz behandelt.
Als Ursache von Schwierigkeiten in Offshore-Projekten werden mangelnde englische
Sprachkenntnisse genannt.383 In der Literatur geschieht dies häufig aus der Perspektive
eines amerikanischen Kunden gegenüber einem Offshore-Anbieter aus unterschiedlichen Gegenden wie zum Beispiel Südamerika, Israel, Indien, den Philippinen oder
China. In der in dieser Arbeit betrachteten Ausgangslage mit einem deutschsprachigen
Kunden und einem indischen Anbieter ergibt sich eine etwas andere Situation. Mitarbeiter des indischen Unternehmens verfügen in der Regel über sehr gute englische Sprachkenntnisse. Dies beruht unter anderem darauf, dass in Indien neben Hindi Englisch als
zweite Amtssprache gilt.384 Zusätzlich findet in den Universitäten ein Großteil der
angebotenen Kurse auf Englisch statt. Auch der indische Alltag ist von der englischen
Sprache geprägt: Kinofilme, Fernsehprogramme, Tageszeitungen und Zeitschriften sind
auch auf Englisch verfügbar.
Allerdings sollte nicht außer Acht gelassen werden, dass in der Regel in Indien das
gesprochene Englisch mit einem starken Akzent behaftet ist und es dadurch für westliche Beteiligte eines Projekts anfänglich schwierig sein kann den Mitarbeiter zu verstehen.385 Schwierigkeiten aufgrund von sprachlichen Problemen können aus zwei Situationen heraus entstehen. Sollte die Kommunikation, sowohl schriftlich als auch verbal, in
einem Projekt ausschließlich auf Deutsch gehalten sein, besteht die Gefahr, dass auf der
381
382
383
384
Vgl. Carmel, Agarwal /Maturation of offshore sourcing/ 68; Earl /Risks/ 27f.; Jurison /Role of risk/
240; Kumar, Willcocks /Country/ 1319 oder Ramarapu, Parzinger, Lado /Issues/ 29.
Vgl. Earl /Risks/ 27 oder Kliem /Managing the risks/ 25.
Vgl. zum Beipiel Carmel, Agarwal /Maturation of offshore sourcing/ 68.
Vgl. Kapitel 2.2.3.
103
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
indischen Seite Verständnisprobleme entstehen. Auf der deutschsprachigen Seite hingegen sind kaum sprachliche Probleme zu erwarten, wenn unterstellt wird, dass Mitarbeiter des Kunden der deutschen Sprache mächtig sind. Eine andere Situation stellt eine
Projektabwicklung in rein englischer Sprache dar. Hierbei ist zu vermuten, dass der
indische Anbieter kaum sprachliche Probleme bekommen wird. Auf der Seite des Kunden hingegen hängt es nun stark von den englischen Sprachkenntnissen der Beteiligten
ab, ob sprachliche Probleme auftreten. Insbesondere bei der Kommunikation mit einer
betroffenen Fachabteilung kann es notwendig werden Gespräche in deutscher Sprache
zu führen, falls hier nur geringe Englischkenntnisse vorhanden sind. Dadurch werden
Übersetzungen notwendig, die einen zusätzlichen Aufwand darstellen können und die
die Gefahr von Übersetzungsfehlern beinhalten.
Auch wenn beide Seiten sich weitgehend problemlos auf Englisch oder Deutsch verständigen können, können Verständnisprobleme aufgrund von unterschiedlich verwendeten Fachbegriffen auftreten.
Um Wiederholungen bei der Betrachtung von Risiken in den unterschiedlichen Bereichen zu vermeiden, werden Risiken aufgrund sprachlicher Unterschiede im Rahmen der
Fallstudien-Untersuchung in Kapitel 3 ausschließlich bei der Betrachtung von kulturellen Unterschieden betrachtet.
ƒ
Ausmaß an Vertrauen zwischen den Beteiligten
Vertrauen lässt sich wie folgt definieren: Vertrauen ist die Bereitschaft verletzlich durch
die Handlungen einer Gruppe zu sein, basierend auf der Erwartung, dass diese Gruppe
eine bestimmte, für den Vertrauensgeber wichtige, Handlung durchführt, unbeachtet
von Kontroll- und Überwachungsmöglichkeiten gegenüber dieser Gruppe.386
Für diese Arbeit bedeutet Vertrauen aus Sicht des Kunden, davon überzeugt zu sein,
dass der Anbieter die vereinbarten Leistungen in der vereinbarten Zeit und dem vereinbarten Budget erbringt ohne einen Schaden zu verursachen.387
385
386
387
Vgl. Ramarapu, Parzinger, Lado /Issues/ 29 und persönliche Erfahrungen des Autors.
Vgl. Mayer, Davis, Schoorman /Organizational trust/ 712: „trust […] is the willingness of a party to
be vulnerable to the actions of another party based on the expectation that the other will perform a
particular action important to the trustor, irrespective of the ability to monitor or control that other
party.” Eine ähnliche Definition wird auch von Bradach, Eccles /Price/ 104 verwendet.
Vgl. Kern, Willcocks /relationships in IT outsourcing/ 12.
104
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
Untersuchungen haben gezeigt, dass Vertrauen zwischen den Beteiligten einer Outsourcing-Beziehung von entscheidender Bedeutung für eine erfolgreiche Beziehung ist.388
Bei vorhandenem Misstrauen besteht das Risiko umfangreiche formelle Kontrollen wie
zum Beispiel Berichte durchzuführen.389 Dies kann dazu führen, dass weniger Zeit zur
Erfüllung der Entwicklungsaufgaben verfügbar ist und es dadurch zu Verzögerungen in
der Entwicklung kommen kann. Vertrauen kann somit als eine Ergänzung formeller
Kontrollmechanismen aufgefasst werden.
Allerdings wird aufgrund der Besonderheiten390 einer Offshore-Situation die Bildung
von Vertrauen erschwert. Denn Vertrauen basiert auf einem häufigen, offenen, ehrlichen und umfassenden Informationsaustausch und kann erst im Laufe einer Beziehung
aufgebaut werden.391 Eine weitere Voraussetzung zur Bildung von Vertrauen ist, dass
eine gemeinsame Vergangenheit und Zukunft gegeben ist.392 Schließlich existiert die
Annahme, dass persönliche Kontakte zum Aufbau von Vertrauen notwendig sind.393
Es besteht das Risiko, dass aufgrund fehlender face-to-face Kontakte der Aufbau von
Vertrauen erschwert wird.394 Allgemein können mangelnde persönliche Beziehungen,
die durch informelle und spontane Kommunikation gefördert werden, die Entwicklung
von Vertrauen negativ beeinflussen.395 Des Weiteren können kulturelle Unterschiede
zwischen den Beteiligten die Bildung von Vertrauen beeinträchtigen.396
388
389
390
391
392
393
394
395
396
Vgl. hierzu z. B. DeLone u. a. /Boundaries/ 3; Herbsleb, Paulish, Bass /Siemens/ 531; Kern, Willcocks /relationships in IT outsourcing/ 12 oder Sabherwal /IS development projects/ 81.
Vgl. hierzu Handy /Trust/ 44f.; Inkpen, Currall /Coevolution/ 590 oder Sabherwal /IS development
projects/ 81f.
Vgl. hierzu die Darstellung des Elements Umwelt in Kapitel 2.2.
Vgl. auch Kern, Willcocks /relationships in IT outsourcing/ 12.
Vgl. Bradach, Eccles /Price/ 108; Herbsleb, Paulish, Bass /Siemens/531; Jarvenpaa, Leidner
/Communication/ 809 und Powell /Market/ 326.
Vgl. Handy /Trust/ 46.
Vgl. Karolak /Global software development/ 18.
Vgl. Heeks u. a. /Synching/ 59.
Vgl. Bradach, Eccles /Price/ 107f.; Carmel, Agarwal /Maturation of offshore sourcing/ 68; Mayer,
Davis, Schoorman /Organizational trust/ 715 oder Maznevski, Chudoba /Bridging space/ 476.
105
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
2.8.3.6 Risiken im Bereich Technologie
Sämtliche projektspezifische Hard- und Software, die zur Aufgabenerfüllung und Kommunikation eingesetzt wird, zählt zum Bereich Technologie. Ebenfalls zählt die Technik, wie zum Beispiel eine bestimmte Hardware, in der das im Rahmen der OffshoreEntwicklung entstandene Softwareprodukt betrieben wird, zu diesem Bereich. Risiken
in dem Bereich Technologie stellen zum Beispiel inkompatible Entwicklungstools,
Komplikationen bei der Konvertierung von Datenbanken oder unvorhergesehene
Schwierigkeiten bei der Implementierung dar.397
Die Umsetzung von organisatorischen Maßnahmen wird zwar durch den Einsatz von
Technologie unterstützt, doch in dieser Arbeit steht eine organisatorische Sichtweise im
Vordergrund und nicht ihre technologische Umsetzung. Eine technologische Umsetzung
unterliegt gegenüber einer rein organisatorischen Betrachtung einem starken zeitlichen
Wandel und soll auch deshalb nicht umfassend in dieser Arbeit betrachtet werden.
Daher werden Risiken im Bereich Technologie nicht direkt untersucht. Jedoch können
Risiken im Bereich Technologie mit Risiken anderer Bereiche des „work system“ zusammenhängen. Diese werden dann dort indirekt betrachtet. Zum Beispiel kann aufgrund des Einsatzes einer neuen und unbekannten Technologie der Kommunikationsaufwand zwischen dem Anbieter und dem Kunden steigen, um während der Entwicklung auftretende Unklarheiten zu beseitigen. Dieser gesteigerte Kommunikationsaufwand wird dann im Bereich Geschäftsprozesse betrachtet.
Risiken, die darauf beruhen, dass der Anbieter die im Rahmen des Projekts eingesetzten
Technologien nicht ausreichend beherrscht, sind maßgeblich für eine anbieterinterne
Prozessbetrachtung relevant. Da in der vorliegenden Arbeit allerdings der Fokus auf der
organisatorischen Gestaltung zwischen dem Anbieter und dem Kunden von OffshoreEntwicklungen liegt, sollen Risiken im Bereich Technologie nicht näher betrachtet
werden. Zusätzlich sind Risiken in diesem Bereich zu einem geringeren Ausmaß Offshore-spezifisch, sodass eine Betrachtung weniger relevant erscheint.
2.8.3.7 Risiken im Bereich Geschäftsprozess
Ein oder mehrere Geschäftsprozesse dienen dazu ein Produkt zu erstellen oder einen
Service anzubieten. Dabei kommen diese Prozesse in sämtlichen Phasen des Projekts
397
Vgl. Herbsleb, Moitra /Global software development/18 und Kliem /Managing the risks/ 25.
106
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
von der Anbahnung, den Vertragsverhandlungen, der Anforderungsanalyse über die
Entwicklung und den Test bis zur Auslieferung der zu erstellenden Software vor. Die
Darstellung eines Geschäftsprozesses umfasst vor allem die Beschreibung seiner organisatorischen Gestaltung. Zum Beispiel zählt auch die grundsätzliche Unterscheidung in
ein Onsite- und Offshore-Team zum Bereich Geschäftsprozess, da dies als eine aufbauorganisatorische Gestaltung verstanden werden kann.
Da die organisatorische Gestaltung von Offshore-Entwicklungen im Mittelpunkt der
Untersuchung dieser Arbeit liegt, sind die Risiken im Bereich Geschäftsprozess von
zentraler Bedeutung und werden daher genauer betrachtet.
Kommunikation wird in dieser Arbeit als ein organisatorischer Gestaltungsbereich
betrachtet. Daher umfasst der Bereich Geschäftsprozess auch sämtliche schriftliche oder
mündliche Informationen, die zwischen den Beteiligten einer Offshore-Entwicklung
ausgetauscht werden. Allerdings wurden Kommunikationsrisiken bereits im Bereich
Umwelt betrachtet, da sie dort als Konsequenz von räumlicher und zeitlicher Trennung
sowie kulturellen Unterschieden identifiziert wurden. Die Zuordnung von Kommunikationsrisiken zu einem bestimmten Element unterliegt einem interpretativen Spielraum,
da sie davon abhängt, inwieweit eine Ursache-Wirkungs-Beziehung einzelner Risiken
zurückverfolgt wird.398 Letztendlich ist diese Zuteilung aber für die Erhebung der vorliegenden Arbeit von untergeordneter Bedeutung, da es entscheidend ist, wie auf diese
Risiken mit organisatorischen Maßnahmen eingegangen werden kann. Dennoch sind die
acht verwendeten Risikobereiche für eine systematische Vorgehensweise hilfreich und
werden daher angewendet. Da Kommunikationsrisiken bereits dem Bereich Umwelt
zugeordnet wurden, erfolgt an dieser Stelle keine erneute Aufführung dieser Risiken,
um eine Wiederholung zu vermeiden.
Neben Risiken in der Kommunikation ist ein in der vorliegenden Literatur oft erwähntes
Risiko die Gefahr eines Kontrollverlusts.399 Damit wird die Befürchtung des Kunden
398
399
Vergleiche hierzu auch Kapitel 4.1.1, in dem eine kritische Betrachtung der Vorgehensweise dieser
Arbeit vorgenommen wird.
Vgl. z. B. Benamati, Rajkumar /Application development/ 40; Grover, Cheon, Teng /Outsourcing/
37f.; Gupta, Gupta /Outsourcing/ 47-79; Jurison /Role of risk/ 240; Khan u. a. /Evaluating/ 4; Klepper, Jones /Outsourcing/ 56; Kliem /Managing the risks/ 23; Lacity, Willcocks /Global/ 335 oder
Ramarapu, Parzinger, Lado /Issues/ 30. Zum Begriff Kontrolle und Controlling siehe auch Kapitel
2.4.3. In einer empirischen Untersuchung Deloitte /Calling/ 9 zählt das Risiko Kontrollverlust zu
den am häufigsten genannten Risiken bei Outsourcing-Projekten.
107
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
ausgedrückt, den Softwareentwicklungsprozess nicht mehr im gewohnten Umfang, wie
bei einer Entwicklung durch den Kunden selbst, steuern und kontrollieren zu können.
Dadurch wird befürchtet, verfolgte Budget-, Termin- und Produktziele nicht zu erreichen beziehungsweise ein Verfehlen dieser Ziele nicht frühzeitig zu erkennen.
Auch der Anbieter ist der Gefahr eines Kontrollverlusts ausgesetzt.400 Unterscheidet
nämlich der Anbieter zwischen einem Onsite-Team, welches vor Ort beim Kunden tätig
ist, und einem Offshore-Team, welches in Indien tätig ist, kann es zu einem Verlust an
Kontrolle zwischen diesen beiden Teams kommen.
2.8.3.8 Risiken im Bereich Produkt und Service
Der Bereich Produkt und Service umfasst eine funktionale Sicht auf das Softwareprodukt, welches Gegenstand der Offshore-Entwicklung ist.
Im Bereich Produkt und Service kann das Risiko der Unsicherheit auftreten. Dies kann
zum Beispiel passieren, wenn das Produkt sehr komplex oder innovativ ist beziehungsweise viele Schnittstellen zu anderen Systemen besitzt.401 Dann können zu Beginn der
Entwicklung nicht alle Anforderungen an das zu entwickelnde Produkt erfasst werden.
Unsicherheit besteht auch, wenn vor Beginn der Entwicklung nicht im Detail bekannt
ist, welche Auswirkungen Änderungen oder Erweiterungen der bestehenden Informationssysteme nach sich ziehen.402
Ähnlich wie bei Unsicherheiten im Bereich der Technologie wird auch hier die Planbarkeit der Offshore-Entwicklung in Bezug auf Termin- und Budgettreue sowie Einhaltung
der geplanten Funktionalität erschwert. Jedoch ist dieses Risiko nicht Offshorespezifisch und kann auch unabhängig von einer Auslagerung auftreten. Daher werden
Risiken im Bereich Produkt und Service nicht weiter betrachtet.
Wenn im Laufe eines zu Beginn unsicheren Projekts der Erkenntnisstand steigt, ergibt
sich daraus ein gesteigerter Kommunikationsbedarf zwischen Anbieter und Kunden.
Risiken, die sich daraus ergeben können, werden im Bereich Geschäftsprozess betrachtet.
400
401
402
Vgl. hierzu Ramarapu, Parzinger, Lado /Issues/ 30.
Vgl. hierzu eine Literaturübersicht zu Risiken im Bereich Produkt und Service in Sherer, Alter /Risk
factors/ 53.
Vgl. Earl /Risks/ 31.
108
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
2.8.3.9 Risiken im Bereich Anbieter- und Kundenunternehmen
Der Bereich Anbieter- und Kundenunternehmen umfasst die hinter den beteiligten
Personen stehenden Unternehmen und soll ein umfassenderes Verständnis des betrachten Falls vermitteln.
Ein Risiko in diesem Bereich ist zum Beispiel ein langfristiger Kompetenzverlust auf
der Seite des Kunden, wenn bestimmte Aufgaben ausgelagert werden und dadurch
einzelne Fähigkeiten der Mitarbeiter nicht mehr benötigt werden.403 Dies kann sowohl
technische Fähigkeiten404 als auch das organisatorische Lernen405 betreffen. Dieser
Kompetenzverlust kann sich negativ auf die Innovationsfähigkeit des Kunden auswirken.406
Des Weiteren besteht das Risiko, dass Mitarbeiter des Kunden durch die Auslagerungsentscheidung demoralisiert werden und dadurch die Zusammenarbeit mit dem Anbieter
erschweren.407 Mitarbeiter des Kunden können sich in ihren Fähigkeiten unterschätzt
fühlen, Angst vor einem Arbeitsplatzverlust entwickeln oder ihre persönlich geplanten
Karrierepläne bedroht sehen.408
Für das Anbieterunternehmen besteht hingegen die Gefahr, dass sich die Durchführung
von Projekten für bestimmte Kundengruppen negativ auf das Image des Anbieters
auswirkt und potentielle Kunden davon abhält eine Beziehung mit den Anbieter einzugehen. Insbesondere Kunden aus der Rüstungs- oder Tabakindustrie könnten solche
Wirkungen erzeugen.
Der vorliegenden Arbeit liegt die Annahme zu Grunde, dass bereits eine Entscheidung
für eine Offshore-Entwicklung auf der Seite des Kunden getroffen ist. Gleichfalls hat
der Kunde bereits einen Offshore-Anbieter ausgewählt. Daher liegen Risiken im Be-
403
404
405
406
407
408
Vgl. Aron, Clemons, Reddi /Understanding/ 3; Aubert u. a. /British Petroleum/ 2; Aubert, Patry,
Rivard /Assessing/ 6; Jurison /Role of risk/ 240 oder Tafti /Risks factors/ 557.
Vgl. Clark Jr., Zmud, McCray /Nature/ 231; Earl /Risks/ 29; Gupta, Gupta /Outsourcing/ 47-49 oder
Khosrowpour, Subramanian, Gunterman /Organizational benefits/ 254.
Earl /Risks/ 29 stellt das Risiko dar, dass durch eine Auslagerung der Lernprozess gestört werden
kann, der sich ergibt, wenn der Wert einer Anwendung durch ihre Nutzung und die Entwicklung
neuer Möglichkeiten erkannt wird.
Vgl. Earl /Risks/ 30 oder Jurison /Role of risk/ 240.
Vgl. hierzu Delmonte, McCarthy /Offshore/ 1607; Dué /Real costs/ 98; Gupta, Gupta /Outsourcing/
47-49; Hatch /Offshore 2005/ 18 oder Khosrowpour, Subramanian, Gunterman /Organizational
benefits/ 258.
Vgl. Grover, Cheon, Teng /Outsourcing/ 37f.; Kumar, Willcocks /Country/ 1317 und Rost /political
reasons/ 104f.
109
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
reich Anbieter- und Kundenunternehmen außerhalb des Einflussbereiches der hier
betrachteten organisatorischen Gestaltungsbereiche und werden daher nicht weiter
untersucht.
2.8.3.10 Zusammenfassung der Fokussierung auf ausgewählte Risikobereiche
Aus der Diskussion über die Relevanz der Risiken einzelner Bereiche in den vorangegangenen Kapiteln ergibt sich eine Fokussierung bei der Betrachtung von Risiken auf
drei der acht Bereiche des „work system“. Die nachfolgende Tabelle Tab. 2-15 stellt
dies zusammenfassend dar.
Bereich des „work system“
Infrastruktur
Umwelt
Strategie
Beteiligte
Technologie
Geschäftsprozess
Produkt und Service
Anbieter- und Kundenunternehmen
Werden Risiken in diesem Bereich in der
vorliegenden Arbeit betrachtet?
Nein
Ja
Nein
Ja
Nein
Ja
Nein
Nein
Tab. 2-15 Zusammenfassung der Fokussierung auf ausgewählte Risikobereiche
Tabelle Tab. 2-16 fasst die identifizierten Risiken in den drei relevanten Risikobereichen dieser Arbeit zusammen. Diese Auflistung dient auch einer systematischen und
zielorientierten Untersuchung der Fallstudie in Abschnitt 3.3.12.
110
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
Risikobereich
Risiko
Erläuterung
ƒ
Missverständnisse in
der Kommunikation
Unvollständige Informationen; insb. wenn
Kontextinformationen fehlen
ƒ
Kein direktes Feedback bei asynchroner
Umwelt: Räumliche und zeitliche Distanz
Kommunikation
ƒ
Bei asynchroner Kommunikation entstehen
Wartezeiten auf Antworten
ƒ
Mangels face-to-face Kommunikation werden quantitativ umfangreichere schriftliche
Informationen ausgetauscht (Aufwändiger in
Weniger effiziente
Kommunikation
der Erstellung und in der Verarbeitung)
ƒ
Terminvereinbarung für gemeinsame synchrone Kommunikation ist aufwändiger
ƒ
Schwierigkeiten den richtigen Ansprechpartner zu finden
Weniger informelle und
spontane Kommunikation
ƒ
Längere Kommunikationswege
ƒ
Entwicklung von Vertrauen wird erschwert
ƒ
Informelle Kommunikation fördert Koordination
Tab. 2-16 Zusammenfassung der identifizierten Risiken (1/2)
111
Darstellung der Offshore-Entwicklung – Darstellung des Elements Risiken
Risikobereich
Risiko
Erläuterung
ƒ
Sprachliche Unterschiede:
• Bei unterschiedlichen Muttersprachen
Umwelt: Kulturelle Unterschiede (inkl. Sprache)
kann die Komplexität und der Umfang
verbal vermittelter Informationen geringer
sein
Missverständnisse in
• Beteiligte fühlen sich unsicher und unwohl
der Kommunikation
bei der Kommunikation in einer fremden
Sprache
• Fehler bei Übersetzungen
ƒ
grund unterschiedlicher Wertvorstellungen
und Einstellungen
Weniger effiziente
Kommunikation
Technische
Komplikationen
Beteiligte
Mängel in der Erfüllung
ƒ
Aufwand durch Übersetzungen
ƒ
Bei Verwendung landesspezifischer Sonderzeichen
ƒ
Aufgrund unterschiedlicher Datumsformate
ƒ
Negative Auswirkungen von mangelnden
fachlichen, technischen oder organisatori-
der Projektanforderungen
Geringes Vertrauen
schen Kenntnissen auf die Zielerreichung
ƒ
prozesse
Kontrollverlust
Umfangreichere formelle Kontrollen, die zu
höherem Aufwand und zeitlichen Verzöge-
zwischen den Beteiligten
Geschäfts-
Abweichendes Verhalten der Beteiligten auf-
rungen führen können
ƒ
Bezogen auf Budget-, Termin- und Produktziele
Tab. 2-17 Zusammenfassung der identifizierten Risiken (2/2)
112
Darstellung der Offshore-Entwicklung – Darstellung des Elements negative Ergebnisse
2.9
Darstellung des Elements negative Ergebnisse
Werden ex ante aufgestellte Ziele und Erwartungen an ein betrachtetes Projekt nicht
erreicht, erzielt das Projekt ein negatives Ergebnis.409 In der Regel lassen sich UrsacheWirkungsketten dergestalt aufstellen, dass ein negatives Ergebnis direkt oder indirekt
einen finanziellen Verlust darstellt.
Welches Ergebnis in einem konkreten Projekt als negativ interpretiert wird hängt nach
obiger Definition maßgeblich von den jeweils verfolgten Zielen ab. Wird zum Beispiel
ein angestrebtes prozessbezogenes Ziel wie das Einhalten von Terminen nicht erreicht,
stellt dies ein negatives Ergebnis dar. Ein Beispiel für ein negatives Ergebnis in Bezug
auf produktbezogene Ziele wäre eine Service-Verschlechterung oder abnehmende Produktqualität.410
In Kapitel 2.7.2.4 wurde gezeigt, dass mit Offshore-Projekten häufig das Ziel Kostensenkung verfolgt wird. Wird dies nicht erreicht, ist von einem negativen Ergebnis zu
sprechen. „Versteckte Kosten“ (engl. hidden costs“) können zu einem negativen Ergebnis von Offshore-Projekten führen. Versteckte Kosten sind Kosten, die bei der ursprünglichen Kalkulation der Projektkosten zu niedrig oder gar nicht berücksichtigt
wurden. Diese Kosten können in unterschiedlichen Bereichen entstehen, wie zum Beispiel bei der Suche eines geeigneten Anbieters,411 bei der Vertragsgestaltung,412 bei
Verhandlungen413 oder sie können aufgrund von Gebühren für notwendige SoftwareLizenzen414 sowie versteckten oder steigenden Servicekosten415 entstehen.
409
410
411
412
413
414
415
Vgl. hierzu Alter, Sherer /Model of IS risk/ 13.
Vgl. Aubert u. a. /British Petroleum/ 2; Aubert, Patry, Rivard /Assessing/ 6; Aubert, Patry, Rivard
/Tale/ 182, 186; Clark Jr., Zmud, McCray /Nature/ 230; Gupta, Gupta /Outsourcing/ 47-49; Hatch
/Offshore 2005/ 15; Khosrowpour, Subramanian, Gunterman /Organizational benefits/ 255 oder
Klepper, Jones /Outsourcing/ 57.
Vgl. Barthelemy /Hidden cost/ 61; Ramarapu, Parzinger, Lado /Issues/ 30; Tafti /Risks factors/ 556.
Barthelemy /Hidden cost/ 61-66 stützt seine Aussagen über unerwartete Kosten auf eine Umfrage
bei 50 Unternehmen. Dabei werden Kosten in unterschiedlichen Bereichen aufgeführt.
Vgl. Barthelemy /Hidden cost/ 61 und Earl /Risks/ 29.
Vgl. Barthelemy /Hidden cost/ 61.
Vgl. Grover, Cheon, Teng /Outsourcing/ 37f.; Lacity, Hirschheim /IS Outsourcing/ 20 oder Khan u. a.
/Evaluating/ 4.
Vgl. Lacity, Willcocks, Feeny /Flexibility/ 91 oder Tafti /Risks factors/ 556.
113
Darstellung der Offshore-Entwicklung – Darstellung des Elements negative Ergebnisse
Versteckte Kosten können durch Analysefehler entstehen und sowohl beim Kunden,
insbesondere wenn ein time & material Vertrag vorliegt, als auch beim Anbieter, insbesondere bei Festpreisprojekten, entstehen.416
An dieser Stelle sei noch darauf hingewiesen, dass manche Autoren Risiken mit negativen Ergebnissen vermischen, sodass „hidden costs“ als Risiko einer OffshoreEntwicklung angesehen werden.417 Diese Sichtweise entspricht allerdings nicht dem
hier zugrunde gelegten Begriffsverständnis von Risiko, Ziel und negativem Ergebnis.
416
417
Vgl. Khan u. a. /Evaluating/ 4.
Vgl. z. B. Deloitte /Calling/ 17: Eine Befragung von 25 Unternehmen ergab, dass 52% der Befragten
kostenbezogene Risiken als Hauptrisiko einer Auslagerung ansahen. Dabei wurden unter kostenbezogenen Risiken auch versteckte Kosten verstanden.
114
Fallstudien-Untersuchung – Design der Untersuchung
3.
Fallstudien-Untersuchung
3.1
Design der Untersuchung
In Kapitel 1.5.4 wurde zuerst der grundlegende Betrachtungsrahmen für OffshoreEntwicklungen in dieser Arbeit festgelegt. Anschließend wurde in Kapitel 2 mit seiner
Hilfe die Offshore-Entwicklung im Allgemeinen dargestellt und ihre Besonderheiten
der Umwelt sowie Risiken identifiziert.
Nun soll der Forschungsfrage nachgegangen werden, mit welchen organisatorischen
Maßnahmen diese Besonderheiten und Risiken berücksichtigt werden können.418
Dies erfolgt, wie bereits in Kapitel 1.5.3 begründet, durch eine FallstudienUntersuchung, die durch den verwendeten Betrachtungsrahmen strukturiert wird.
Grundsätzlich ist das gewählte Vorgehen der vorliegenden Fallstudien-Untersuchung an
die Empfehlungen von Yin angelehnt.419 Yin und Walsham schlagen vor, die Erhebung
der Informationen einer Fallstudie und deren Analyse zu dokumentieren, damit auch
Außenstehende diese nachvollziehen können.420 Dieser Forderung wird nun Rechnung
getragen:
ƒ
Details über die untersuchten Unternehmen
Es handelt sich um einen Schweizer Kunden und einen indischen Anbieter von Offshore-Dienstleistungen. Die beiden Unternehmen werden im Kapitel 3.3.2 näher vorgestellt.
ƒ
Gründe für die Wahl dieser Unternehmen
Der Fokus der vorliegenden Arbeit liegt auf einer Offshore-Beziehung zwischen einem
deutschsprachigen Kunden und einem indischen Anbieter. Der gewählte Anbieter gehört zu den größten Anbietern von Offshore-Dienstleistungen Indiens und es bestand
die Bereitschaft sich aktiv an einer empirischen Studie zu beteiligen. Nachdem der
Anbieter ausgewählt wurde, wurden gemeinsam mit dem Anbieter und dem Autor der
Studie geeignete Projekte eines deutschsprachigen Kunden ausgewählt. Kriterien waren,
418
419
420
Zu den Forschungsfragen siehe 1.4.3.
Vgl. Yin /Case study/.
Vgl. Walsham /Interpretive case studies/ 79 und Yin /Case study/ 68f.
115
Fallstudien-Untersuchung – Design der Untersuchung
dass ein Entwicklungs-, Wartungs- oder Re-Engineering-Projekt durchgeführt wurde,421
dass an dem Projekt mindestens 5 Personen des Anbieters beteiligt waren, dass es in
einem Zeitraum von mindestens vier Monaten umgesetzt wurde und dass das Projektende innerhalb der letzten vier Jahre stattfand. Damit sollte sichergestellt werden, dass das
Projekt eine gewisse Größe hatte, damit überhaupt eine organisatorische Gestaltung
sichtbar wird. Schließlich musste der Kunde auch Interesse zeigen, sich an der Studie zu
beteiligen und damit einverstanden sein, relevante Informationen zur Verfügung zu
stellen.422
ƒ
Ablauf und Vorgehen der Untersuchung
Die folgende Tabelle zeigt den zeitlichen Ablauf der Erhebung und wie die entsprechenden Informationen erhoben wurden.
Zeitraum
11.2005
Inhalt
ƒ Erste Kontaktaufnahme zu einem indischen Anbieter und Vorstellung
der Ziele der Studie.
12.2005
ƒ Persönliche Präsentation der Ziele und des Vorgehens der Studie gegenüber einem Accountmanager für Kunden im deutschsprachigen
Raum. Absprache über nächste Schritte der Untersuchung.
01.2006
ƒ Suche nach einzelnen Projekten bei unterschiedlichen Kunden, die
untersucht werden können. Entscheidende Kriterien:
Größe der Projekte, Anzahl Teammitglieder, Dauer, Bereitschaft des
Kunden an der Studie teilzunehmen.
ƒ Auswahl eines Kunden, der motiviert war sich an der Studie zu beteiligen und mit dem geeignete Projekte durchgeführt wurden.
02.2006
ƒ Telefonische Absprachen mit dem zuständigen Projektmitarbeiter des
Anbieters, der beim ausgewählten Kunden vor Ort arbeitet (OnsiteKoordinator): Vorstellung der Untersuchung und Abstimmung des
weiteren Vorgehens.
Tab. 3-1 Ablauf der Fallstudienerhebung (1/2)
421
422
Reine Anpassungsprojekte (z. B. SAP, Siebel) wurden ausgeschlossen, da hierbei andere Aufgaben
stattfinden als dies bei den aufgezählten Projekttypen der Fall ist.
Auch Kelliher /Interpretivism/ 125 weisen in ihrer Diskussion über eine Forschungsanleitung für
Fallstudien auf diese Notwendigkeit hin.
116
Fallstudien-Untersuchung – Design der Untersuchung
Zeitraum
03.2006
Inhalt
ƒ Persönliche Präsentation der Untersuchung vor dem Kunden in Zürich
sowie Auswahl von drei Projekten die in der Untersuchung berücksichtigt werden sollen und Absprachen, um das weitere Vorgehen festzulegen.
ƒ Persönliche Beantwortung erster Fragen insbesondere bezüglich Aufbau und Ablauf der ausgewählten Projekte durch den OnsiteKoordinator in Zürich.
04.2006
bis
08.2006
ƒ Schriftliche Befragung des Onsite-Koordinators und telefonische Klärung von Unklarheiten der gelieferten Antworten.
ƒ Anschließende schriftliche Befragung des Kunden und telefonische
Klärung von Unklarheiten der gelieferten Antworten.
ƒ Schriftliche Befragung aller übrigen Beteiligten des Anbieters.
ƒ Kontinuierliche Auswertung und schriftliche Fixierung der erhaltenen
Antworten, sobald diese überreicht wurden.
ƒ Klärung von Fragen, die sich aufgrund der Auswertung ergaben.
09.2006
bis
11.2006
ƒ Abschließende Analyse der erhobenen Informationen.
ƒ Letzte Nachfragen bei Schlüsselpersonen der untersuchten Projekte um
Unklarheiten zu beseitigen.
Tab. 3-2 Ablauf der Fallstudienerhebung (2/2)
Auf Basis des in Kapitel 2 aufgestellten theoretischen Betrachtungsrahmens wurden
unterschiedliche Fragebögen entwickelt, um die einzelnen Elemente des Betrachtungsrahmens zu untersuchen.423 Der umfangreichste Fragebogen – mit 105 Fragen – wurde
an den Onsite-Koordinator geschickt.424 Weiter erhielten die drei Projektverantwortlichen des Kunden einen ersten Fragebogen mit 47 Fragen und einen zweiten Fragebogen
mit weiteren 21 Fragen. Alle übrigen Projektmitglieder erhielten 15 Fragen.
Die im Zeitraum April bis August 2006 gelieferten Antworten sind durchweg sehr
aussagekräftig und zum Teil ausführlich geliefert worden.
423
424
Siehe Anhang C.
Der Onsite-Koordniator (AP07) hat diese Fragen gemeinsam mit dem Projektmanager (AP03) und
dem Architekten (AP02) eines der Projekte beantwortet. „APxx“ steht für die durchnummerierten
Anbieterpersonen. In Kapitel 3.3.8 erfolgt eine Auflistung aller an den untersuchten Projekten beteiligten Personen.
117
Fallstudien-Untersuchung – Methode der sozialen Netzwerkanalyse
Alle organisatorischen Aspekte des Betrachtungsrahmens – dazu zählen insbesondere
die Elemente Geschäftsprozesse und Risiken in diesen Geschäftsprozessen – wurden
durch Befragungen von Schlüsselpersonen erhoben. Kieser und Kubicek argumentieren,
dass dieses Vorgehen prinzipiell geeignet ist.425 Darüber hinaus wurden alle an den
Projekten beteiligten Personen befragt. Dabei wurde bei der Auswertung der erhaltenen
Antworten auch die Methode der sozialen Netzwerkanalyse angewendet. Im Kapitel 3.2
wird diese Methode vorgestellt und ihr Einsatzzweck dargestellt.
Wie bereits bei der wissenschaftstheoretischen Begründung der gewählten Vorgehensweise in Kapitel 1.5.2 erläutert, wird in dieser Arbeit ein interpretativer Forschungsansatz verfolgt. In diesem Sinne wird bei der Untersuchung der Elemente in den folgenden
Kapiteln nicht davon ausgegangen Fakten zu berichten, sondern dass es sich dabei um
die Interpretationen des Autors von Interpretationen der Befragten handelt.426 Allerdings
wurde stets versucht neben persönlichen Einschätzungen auch objektiv beantwortbare
Fragen zu formulieren.
3.2
Methode der sozialen Netzwerkanalyse
3.2.1
Grundzüge der sozialen Netzwerkanalyse
Eine Methode, die im Rahmen der Fallstudien-Untersuchung angewendet wurde und
eine zentrale Rolle übernimmt, ist die soziale Netzwerkanalyse. Sie wurde eingesetzt,
um Kommunikationsbeziehungen zwischen den an den Projekten beteiligten Personen
systematisch untersuchen zu können.
Die soziale Netzwerkanalyse lässt sich auf Radcliffe-Brown zurückführen und wurde
von den 1930ern bis in die 1970ern von vielen Soziologen und Anthropologen aufgegriffen und erweitert.427 Grundsätzlich verfolgt die soziale Netzwerkanalyse das Ziel,
Beziehungen zwischen sozialen Entitäten zu betrachten und Interaktionsmuster zwi425
426
427
Vgl. Kieser, Kubicek /Organisation/ 172.
Vgl. Walsham /Interpretive case studies/ 78.
Vgl. Scott /Social network analysis/ 4 und Tichy, Tushman, Fombrun /Social network analysis/ 508.
Eine ausführliche Darstellung der historischen Entwicklung der sozialen Netzwerkanalyse liefern z.
B. Scott /Social network analysis/ 7-16 oder Wasserman, Faust /Social network analysis/ 10-17. Ein
Review über die Verwendung der SNA im Zeitraum 1950er - 2000er liefern Knox, Savage, Harvey
/Social networks/ 113-140.
118
Fallstudien-Untersuchung – Methode der sozialen Netzwerkanalyse
schen diesen zu verstehen.428 Daher ist sie auch dazu geeignet Organisationen darzustellen.429
Die soziale Netzwerkanalyse ist ein formalisierter Ansatz, der auf der Graphentheorie
beruht430 und sowohl die Datenerhebung als auch die Analyse von Daten umfasst.431
Bei einer grafischen Darstellung eines Netzwerkes (Abb. 3-1) repräsentieren Knoten
soziale Entitäten und Kanten zwischen diesen Knoten Beziehungen bzw. Informationsflüsse.432
Knoten
Kante = Beziehung,
= soziale Entität
Informationsfluss
Abb. 3-1 Erläuterung der grafischen Darstellung von Netzwerken
3.2.2
Anwendung der sozialen Netzwerkanalyse im Rahmen der Fallstudie
Im Rahmen der vorliegenden Fallstudie wurde eine Erhebung des gesamten Netzwerks
– im Gegensatz zu einem egozentrierten Netzwerk – vorgenommen, da alle an einem
Projekt beteiligten Personen eine klar abgrenzbare Population darstellen.433
Um die relevanten Daten zu erheben, wurde für jedes Projekt im Vorfeld eine Liste aller
beteiligten Personen – sowohl Anbieterpersonen (AP) als auch Kundenpersonen (KP) –
erstellt.434 Diese Liste wurde jedem Beteiligten zugeschickt mit der Bitte anzugeben,
428
429
430
431
432
433
434
Vgl. Wasserman, Faust /Social network analysis/ 3 auch Haythornthwaite /Social network analysis/
323 und Nelson /Strenght/ 380 greifen diese Definition auf.
Vgl. Tichy, Tushman, Fombrun /Social network analysis/ 513 und Zack /Organizational systems/ 1.
Vgl. Zack /Organizational systems/ 2. Zack verweist an dieser Stelle auch auf zahlreiche Studien, die
die soziale Netzwerkanalyse sowohl zur Beschreibung sozialer Strukturen als auch zur Beschreibung computer-gestützter Kommunikation anwenden.
Vgl. Tichy, Tushman, Fombrun /Social network analysis/ 507.
Vgl. z. B. Ahuja, Galletta, Carley /Individual centrality/ 27; Scott /Social network analysis/ 38-40 und
Wasserman, Faust /Social network analysis/ 73-75.
Vgl. zu dieser Abgrenzung z. B. Haythornthwaite /Social network analysis/ 328f.; Knox, Savage,
Harvey /Social networks/ 118 oder Mead /Social network analysis/ 33.
Nach Wasserman, Faust /Social network analysis/ 45 ist diese Form der Datenerhebung am weitesten
verbreitet. Beispiele für ihre Anwendung liefern u. a. Mead /Social network analysis/ 34 und Nelson
/Strenght/ 383f.
119
Fallstudien-Untersuchung – Methode der sozialen Netzwerkanalyse
wie häufig eine Interaktion435 über ein bestimmtes Medium mit einer am Projekt beteiligten Person stattfand.436 Zusätzlich bestand die Aufforderung die Liste zu ergänzen,
falls mit anderen Personen im Kontext des jeweiligen Projekts kommuniziert wurde, als
denjenigen, die in der Liste aufgeführt wurden.
Abbildung Abb. 3-2 stellt eine anonymisierte Form des Befragungsinstruments dar. Bei
den durchgeführten Erhebungen wurden statt der Variablen APxx und KPxx die realen
Namen der Beteiligten eingetragen.437 Die Datenerhebung einer sozialen Netzwerkanalyse kann grundsätzlich nicht anonym erfolgen.438 Daher wurden die Teilnehmer der
Studie darauf hingewiesen, dass die Daten nicht anonym erhoben werden, jedoch nach
der Erhebung anonymisiert und streng vertraulich behandelt werden. Weiter wurde
zugesichert, dass in allen öffentlich verfügbaren Auswertungen keine Namen von Personen enthalten sein werden und dass die gegebenen Antworten keine persönlichen
Konsequenzen nach sich ziehen werden. Alle Beteiligten haben diesem Vorgehen zugestimmt.
Im Anhang befinden sich anonymisiert alle erhobenen Daten der sozialen Netzwerkanalyse der untersuchten Projekte.439
435
436
437
438
439
Die Häufigkeit wurde in fünf mögliche Ausprägungen unterschieden: nie (0), seltener als einmal in
der Woche (1), einmal in der Woche (2), häufiger als einmal in der Woche (3) oder täglich (4).
Wasserman, Faust /Social network analysis/ 46f. bezeichnen die Vorgabe von möglichen Personen
während der Befragung als „rooster“ im Gegensatz zu „free call“. Weiter ist das gewählte Vorgehen
als „free choice“ – im Gegensatz zu „fixed choice“ – zu bezeichnen, da nicht vorgegeben wurde wie
viele Beziehungen eine Person eingehen muss oder höchstens darf.
In Abhängigkeit der Muttersprache der beteiligten Personen wurde die Erhebung in englischer oder in
deutscher Sprache durchgeführt.
Vgl. hierzu Borgatti, Molina /Ethical guidelines/ 112f.; Cross, Nohria, Parker /Informal networks/ 71
oder Kadushin /Ethics/ 140-152.
Alle erhobenen Daten der sozialen Netzwerkanalyse befinden sich im Anhang C-4.
120
Fallstudien-Untersuchung – Methode der sozialen Netzwerkanalyse
Abb. 3-2 Befragungsinstrument zur sozialen Netzwerkanalyse
Die Auswertung der erhobenen Daten und ihre grafische Aufbereitung erfolgte mit der
Software UCINET, NetDraw440 und Visio von Microsoft. Die Ergebnisse der Auswertungen werden bei der Untersuchung einzelner Elemente – insbesondere bei der Betrachtung von Risiken im Bereich Umwelt – verwendet.
Bevor nun die einzelnen Ergebnisse der sozialen Netzwerkanalyse dargestellt und interpretiert werden, sei an dieser Stelle noch auf den Aspekt der Vollständigkeit der Erhebung hingewiesen.441
Insgesamt werden in der Fallstudien-Untersuchung drei Projekte – Zürich ReEngineering, Zürich Development und Zürich Maintenance – zwischen einem Anbieter
und demselben Kunden betrachtet.442 Der Beginn des frühesten der drei Projekte (Zürich Re-Engineering) liegt vier Jahre zurück, nämlich im Jahr 2002. Dadurch, dass
dieses Projekt länger zurückliegt, wurde für dieses Projekt keine soziale Netzwerkanalyse nach dem oben geschilderten Vorgehen durchgeführt, da vermutet wird, dass das
Erinnerungsvermögen der Beteiligten über die Häufigkeit der Kommunikation mit
anderen Beteiligten des Projekts mit fortschreitender Zeit ungenauer wird.
440
441
442
Vgl. Borgatti, Everett, Freeman /Ucinet/. Siehe hierzu auch Mead /Social network analysis/ 33 oder
Scott /Social network analysis/ 63.
Stork, Richards /Nonrespondents/ 196 haben festgestellt, dass eine vollständige Datenerhebung in den
seltensten Fällen möglich ist und haben sich daher Gedanken über Konsequenzen von unvollständigen Daten gemacht, die nun hier aufgegriffen werden.
Die Entwicklungsgegenstände dieser drei Projekte werden in Kapitel 3.3.3 genauer dargestellt.
121
Fallstudien-Untersuchung – Methode der sozialen Netzwerkanalyse
Zürich Maintenance ist ein fortlaufendes Wartungsprojekt. Zwar begann es bereits im
März 2002, jedoch wird im Rahmen der vorliegenden Untersuchung nicht die gesamte
Projektdauer betrachtet, sondern lediglich der Zeitraum Januar 2005 bis März 2006.
Von allen fünf Personen des Anbieters, die direkt an dem Projekt Zürich Development
beteiligt waren, wurden notwendige Daten für die soziale Netzwerkanalyse erhoben.
Zwei weitere Personen des Anbieters waren indirekt auf einer höheren Managerebene
an dem Projekt beteiligt. Sie wurden aber nicht befragt. Auf der Kundenseite waren
insgesamt vier Personen an dem Projekt beteiligt. Leider standen die Daten von nur
einer dieser Personen zur Verfügung. Da in den Untersuchungen allerdings maßgeblich
die Schnittstelle zwischen Anbieter und Kunde untersucht wird, sind die erhobenen
Daten dennoch brauchbar. Lediglich die Beziehungen zwischen den Personen des Kunden konnten nicht vollständig dargestellt werden. Durch den Abteilungsleiter des Kunden (KP01) wurde nach Abschluss der Informationserhebung darauf hingewiesen, dass
zum Beispiel eine intensive Kommunikation zwischen ihm und den Projektleitern
(KP02 und KP05) in den Projekten Zürich stattfand. Die Beziehungen zwischen dem
Anbieter und dem Kunden konnten hingegen rekonstruiert werden. Die Methode der
Rekonstruktion wird im Folgenden vorgestellt.
An dem Projekt Zürich Maintenance waren direkt 11 Personen des Anbieters und vier
Personen des Kunden beteiligt. Hiervon konnten sieben Antworten von Personen des
Anbieters und eine Antwort des Kunden für die soziale Netzwerkanalyse verwendet
werden. Weitere fünf Personen des Anbieters waren indirekt an dem Projekt auf einer
höheren Managementebene oder durch eine technische beratende Rolle an dem Projekt
beteiligt. Zwar ist die Erhebung in diesem Projekt nicht vollständig, aber von Personen
mit zentraler Bedeutung – z. B. Personen, die vor Ort beim Kunden gearbeitet haben,
oder dem Projektmanager – konnten die Daten erhoben werden.
Um mit den erhobenen Daten zur sozialen Netzwerkanalyse bestmöglich arbeiten zu
können wurde, statt eine Beziehung von zwei Personen beschreiben zu lassen, nur auf
eine Person zugegriffen und die Annahme unterstellt, dass die nicht antwortende Person
diese Beziehung genauso beschreiben würde.443 Es wird empfohlen bei dieser Art der
443
Vgl. zu dieser Rekonstruktionsmöglichkeit Stork, Richards /Nonrespondents/ 198f.
122
Fallstudien-Untersuchung – Methode der sozialen Netzwerkanalyse
Rekonstruktion anzugeben, wie hoch die Glaubwürdigkeit (engl. reliability) der verfügbaren Daten ist. Dabei wird überprüft, wie häufig die Befragten Beziehungen zueinander identisch beschrieben haben. Es existiert kein allgemein anerkanntes Level der
Glaubwürdigkeit, ab wann eine Rekonstruktion zulässig ist oder ab wann auf eine Rekonstruktion verzichtet werden sollte. Dennoch liefern die folgenden Angaben zur
Glaubwürdigkeit einen Anhaltspunkt dafür, wie die präsentierte soziale Netzwerkanalyse durchgeführt wurde.
Im Projekt Zürich Development standen Daten von 6 Personen zur Verfügung. Diese
können (6x5) = 30 gerichtete Kommunikationsflüsse (= 15 Beziehungen) untereinander
ohne zu sich selbst beschreiben. Tabelle Tab. 3-3 beinhaltet die erhobenen Informationen. Die Glaubwürdigkeit im Fall der gesamten Kommunikation444 liegt hier bei 60% (9
Beziehungen wurden von beiden beteiligten Personen identisch angegeben).
Bildet man aus den vorhandenen Daten eine Gruppe mit der Häufigkeit „0“ (= nie)445
und eine Gruppe mit der Häufigkeit größer „0“, ergibt sich eine Glaubwürdigkeit von
87% (nur 2 der 15 Beziehungen wurden abweichend angegeben).
AP03
AP14
AP08
AP07
AP13
KP03
AP03 AP14 AP08 AP07 AP13 KP03
0
4
4
4
4
1
4
0
4
4
3
0
4
4
0
4
4
1
4
2
4
0
3
3
4
3
2
4
0
4
0
0
0
4
4
0
Tab. 3-3 Erhobene Daten im Projekt Zürich Development über alle Kommunikationsmedien zur Bestim446
mung der Glaubwürdigkeit
Die Untersuchung der Glaubwürdigkeit zur synchronen447 und asynchronen448 Kommunikation im Projekt Zürich Development ergab ebenfalls eine Übereinstimmung von
444
445
446
447
448
Hierbei wird das Maximum der Kommunikationshäufigkeit über alle erhobenen Kommunikationsmedien pro Personen gebildet.
Die Häufigkeit wurde in fünf mögliche Ausprägungen unterschieden: nie (0), seltener als einmal in
der Woche (1), einmal in der Woche (2), häufiger als einmal in der Woche (3) oder täglich (4).
Die Tabelle wird von links nach rechts gelesen. AP14 gibt an mit AP07 eine Kommunikationshäufigkeit von 4 (täglich) zu haben. Allerdings gibt AP07 die Kommunikationshäufigkeit zu AP14 mit 2
(wöchentlich) an. Graue Zellen markieren diese Abweichungen.
Hierbei wird das Maximum über face-to-face und telefonische Kommunikation pro Personen gebildet.
Dies entspricht der Kommunikation per E-Mail.
123
Fallstudien-Untersuchung – Methode der sozialen Netzwerkanalyse
60% und bei Bildung der beiden Gruppen („0“ und größer „0“) 93% (1 der 15 Beziehungen wurde abweichend angegeben).449
Im Projekt Zürich Maintenance standen Daten von 8 Personen zur Verfügung. Diese
können (8x7) = 56 gerichtete Kommunikationsflüsse (= 28 Beziehungen) untereinander
ohne zu sich selbst beschreiben. Tabelle Tab. 3-4 beinhaltet die erhobenen Informationen. Die Glaubwürdigkeit im Fall der gesamten Kommunikation450 liegt hier bei 43%
(12 Beziehungen wurden von beiden beteiligten Personen identisch angegeben).
Bildet man aus den vorhandenen Daten eine Gruppe mit der Häufigkeit „0“ (= nie) und
eine Gruppe mit der Häufigkeit größer „0“, ergibt sich eine Glaubwürdigkeit von 96%
(nur 1 der 28 Beziehungen wurde abweichend angegeben).
AP03
AP14
AP18
AP17
AP13
AP21
KP03
AP07
AP03 AP14 AP18 AP17 AP13 AP21 KP03 AP07
0
4
4
4
4
4
0
4
4
0
3
3
4
4
0
4
3
3
0
3
2
3
0
2
2
2
2
0
2
2
0
2
4
3
1
1
0
0
4
0
1
4
3
3
3
0
0
3
0
0
0
0
1
0
0
1
4
3
3
3
4
3
4
0
Tab. 3-4 Erhobene Daten im Projekt Zürich Maintenance über alle Kommunikationsmedien zur Bestim451
mung der Glaubwürdigkeit
Die Untersuchung der Glaubwürdigkeit zur synchronen Kommunikation im Projekt
Zürich Maintenance ergab eine Übereinstimmung von 50% und bei Bildung der beiden
Gruppen („0“ und größer „0“) 93% (2 der 28 Beziehungen wurden abweichend angegeben.
Die Untersuchung der Glaubwürdigkeit zur asynchronen Kommunikation im Projekt
Zürich Maintenance ergab eine Übereinstimmung von 43% und bei Bildung der beiden
Gruppen („0“ und größer „0“) 89% (3 der 28 Beziehungen wurden abweichend angegeben.
449
450
451
Alle erhobenen Daten der sozialen Netzwerkanalyse befinden sich im Anhang C-4.
Hierbei wird das Maximum der Kommunikationshäufigkeit über alle erhobenen Kommunikationsmedien pro Personen gebildet.
Erläuterung siehe vorherige Tabelle.
124
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
3.3
Untersuchung der einzelnen Elemente des „work system“
3.3.1
Systematik der Darstellung der Untersuchung
Im Folgenden werden nach und nach alle Elemente des aufgestellten Frameworks für
den ausgewählten Fall untersucht. In dem Fall werden drei Projekte zwischen dem
gleichen Kunden und dem gleichen Anbieter betrachtet. Innerhalb der Betrachtung
einzelner Elemente wird entweder zwischen den drei Projekten unterschieden oder es
werden, um Wiederholungen zu vermeiden, die drei Projekte gleichzeitig betrachtet.
Es sei an dieser Stelle noch darauf hingewiesen, dass gegenüber dem Kapitel 2 im
Folgenden die Reihenfolge der untersuchten Elemente des Betrachtungsrahmens variiert. Grund dafür ist, dass in dem ersten Teil eine allgemein gültige Betrachtung von
Offshore-Entwicklungen aus einer Markt-Perspektive erfolgt. In Kapitel 3 hingegen
werden konkrete Unternehmen und Projekte untersucht. Um die Darstellungen bei
diesen unterschiedlichen Perspektiven bestmöglich nachvollziehen zu können, wurde
die Reihenfolge der untersuchten Elemente angepasst.
3.3.2
Untersuchung des Elements Anbieter- und Kundenunternehmen
3.3.2.1 Anbieterunternehmen
Bei dem Anbieterunternehmen handelt es sich um das indische Unternehmen Infosys
Ltd. Wie in Kapitel 2.6.1 bereits dargestellt, handelt es sich bei Infosys um einen der
größten indischen Anbieter von Offshore-Softwareentwicklungen.
Infosys erzielt den Großteil seiner Gewinne mit Kunden in den USA. Ein Viertel der
Gewinne werden in Europa erwirtschaftet – siehe Abbildung Abb. 3-3.452
452
Sämtliche hier dargestellten Unternehmensdaten stammen aus dem Jahresbericht für das Geschäftsjahr 2005-2006. Vgl. Infosys /Annual report 2005-06/.
125
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Indien
1%
andere
Länder
9%
Europa
25%
USA
65%
Abb. 3-3 Geografische Verteilung der Gewinne von Infosys
Infosys eröffnete 1987 sein erstes internationales Büro in den USA. Das erste europäische Büro folgte 1996 in England und das erste deutsche Büro wurde 1999 eröffnet.453
3.3.2.2 Kundenunternehmen
Im Rahmen der Fallstudienuntersuchung wurden drei Projekte
ƒ
Zürich Re-Engineering
ƒ
Zürich Maintenance
ƒ
Zürich Development
untersucht. Sie wurden von der Zürcher Kantonalbank (ZKB) bei Infosys in Auftrag
gegeben.
Die Zürcher Kantonalbank wurde 1870 gegründet, beschäftigte im Geschäftsjahr 2005
4.244 Mitarbeiter und verfügte über 85 Filialen.454 In der IT-Abteilung sind ca. 600
Mitarbeiter beschäftigt. Die ZKB ist eine selbständige öffentlich-rechtliche Anstalt des
Kantons Zürich. Sie betreut sowohl Privat- als auch Firmenkunden und ist im Bereich
Investment und Private Banking aktiv. Mit einer Bilanzsumme von 86 Mrd. CHF ist die
ZKB die größte Kantonalbank und die viertgrößte Schweizer Bank.455 Insgesamt verwaltet die ZKB ein Kundenvermögen von 129 Mrd. CHF.
453
454
455
Vgl. Infosys /History/.
Vgl. zu diesem Abschnitt den Geschäftsbericht der Zürcher Kantonalbank für das Geschäftsjahr 2005
(ZKB /Geschäftsjahr 2005/) und Ritschard /Zürcher Kantonalbank/.
Lediglich die UBS, Credit Swiss und Raiffeisen Banken weisen eine höhere Bilanzsumme auf.
126
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
3.3.3
Untersuchung des Elements Produkt und Service
Im Rahmen der Fallstudie werden die letzten drei Projekte – von insgesamt vier Projekten – zwischen der ZKB und Infosys betrachtet.456 Die folgende Tabelle (Tab. 3-5) stellt
den Entwicklungsgegenstand und den Projektzeitraum der drei ausgewählten Projekte
näher dar. Im Folgenden werden mit „Projekte Zürich“ diese drei Projekte gemeinsam
bezeichnet.
Projekt
Projektzeitraum
Einsatzort des
Softwareprodukts
Unterschiedli-
Entwicklungsart
und Funktionalität
Zürich
August 2002 bis
Re-Engineering
Re-
April 2003
Eine existierende Software- che
Engineering
Bibliothek wurde ersetzt.
andere
Softwareprodukte
greifen
auf diese Bibliothek zurück.
Zürich
Januar 2005 bis
Wartung
In allen Bankfi-
Maintenance
März 2006
Anforderungsänderungen
lialen und im
(Da dies ein fort- (engl. change requests (CR)) Back Office.
laufendes
War- aufgrund
tungsprojekt
veränderter
Ge-
ist, schäftsabläufe oder interagie-
wurde ein Untersu- render Anwendungen wurden
chungszeitraum
umgesetzt sowie Fehler wäh-
festgelegt.)
rend des laufenden Betriebs
behoben.
456
Ein Teil der für die Untersuchung notwendigen Informationen wird durch Interviews erhoben. Je
länger ein Projekt zurückliegt, desto schwieriger wird es, auf alle Beteiligten des Projekts zurückzugreifen und desto größer ist die Gefahr, dass sich Beteiligte nicht mehr vollständig an alle relevanten
Geschehnisse erinnern können. Daher wurde das erste Projekt, das im März 2002 begann und nur
wenige Monate dauerte, nicht untersucht. Darüber hinaus bestand dieses erste Projekt aus mehreren
kleineren Re-Engineering Projekten. Diese kleinen Projekte entsprechen nicht den aufgestellten
Auswahlkriterien – vgl. 3.1.
127
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Projekt
Entwicklungsart
und Funktionalität
Projektzeitraum
Einsatzort des
Softwareprodukts
In allen Bankfi-
Zürich
Dezember 2004 bis
Neuentwicklung
Development
Juni 2005
Modul zur Kommunikation lialen und im
mit Druckern und Bankauto- Back Office.
maten. Es stand bereits ein
Modul zur Verfügung, das
aber aufgrund der umfangreichen Änderungswünsche neu
geschrieben werden sollte.
Tab. 3-5 Produkt und Service der drei Projekte Zürich
3.3.4
Untersuchung des Elements Technologie
Tabelle Tab. 3-6 zeigt die wesentlichen Technologien, die bei der Entwicklung in den
drei Projekten eingesetzt wurden.
Projekt
Verwendete Technologien
Zürich Re-Engineering
Edit plus, REX, C++
Zürich Maintenance
Edit plus, ISA Dialog Manager, C++
Zürich Development
Edit plus, Eclipse, JAVA, C++
Tab. 3-6 Verwendete Technologien in den Projekten Zürich
3.3.5
Untersuchung des Elements Infrastruktur
In allen drei Projekten Zürich wurde das Internet genutzt, um Daten zwischen dem
Kunden, dem Onsite-Team und dem Offshore-Team auszutauschen. Dazu stand dem
Anbieter auch ein File-Server zur Verfügung, der zusätzlich von Projekten mit anderen
Kunden genutzt wurde.
Das Element Infrastruktur umfasst auch Schulungen, deren Verwaltung außerhalb der
Projektorganisation liegt. So wurden in allen Projekten Zürich Beteiligte des Anbieters
im Vorfeld in Schulungen auf kulturelle Unterschiede aufmerksam gemacht. Darüber
hinaus wurde ein Teil der Beteiligten des Anbieters in der deutschen Sprache unterrichtet. In den Projekten Zürich Maintenance und Re-Engineering durchliefen die Beteilig-
128
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
ten des Anbieters vor Projektbeginn ein technisches Training und eine Einführung in
bankenspezifische Abläufe.
3.3.6
Untersuchung des Elements Umwelt
3.3.6.1 Räumliche und zeitliche Distanz
Die Tabelle Tab. 3-7 stellt die räumliche und zeitliche Distanz in den Projekten Zürich
dar.
Projekt
Ort des Kunden und
Ort des Off-
des Onsite-Teams
shore-Teams
Arbeitszeiten (lokal)
Onsite
Offshore
Zürich
ReEngineering
Zürich, Schweiz
8:30 – 17:30
Das Onsite-Team ist
8:30 –
17:30
in Büros des Kunden
Zürich
Maintenance
Zürich
Development
untergebracht. Zusätzlich verfügt Infosys
Bangalore,
über eigene Büros in
Indien
8:00 – 17:30
9:00 –
18-23:00
Zürich, die jedoch in
8:30 – 17:30
der Regel nicht zur
Projektabwicklung
genutzt werden.
(Onsite-
8:30 –
Koordinator
17-22:00
bis 19:30)
Tab. 3-7 Räumliche und zeitliche Differenz in den Projekten Zürich
Zwischen Zürich und Bangalore liegt eine Luftlinie von ca. 7.400 km.457 Zwischen
Zürich und Bangalore gibt es zurzeit keine direkte Flugverbindung. Dadurch beträgt die
Reisezeit zwischen den beiden Städten mindestens 18 Stunden.
Aufgrund der Zeitdifferenz zwischen dem Onsite- und dem Offshore-Standort von 4,5
Stunden im Winter und 3,5 Stunden im Sommer458 ergibt sich bei den Projekten Zürich
eine Überschneidung in den Kernarbeitszeiten von 4,5 Stunden im Winter und 5,5
Stunden im Sommer, wobei noch Zeiten für Mittagspausen abgezogen werden müssen.
457
458
Zur Berechnung wurde Zürich mit den Koordinaten 47° Nord und 8° Ost und Bangalore mit 13° Nord
und 78° Ost angenommen.
Siehe hierzu auch Kapitel 2.2.2.
129
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Abbildung Abb. 3-4 veranschaulicht diese Zusammenhänge. Hierbei wurde die Sommerzeit in Zürich als Referenzzeit genommen.
Tageszeit in Zürich (MEZ)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Bangalore
Zürich
(Sommer)
Zürich
(Winter)
Abb. 3-4 Zeitunterschiede zwischen Onsite- und Offshore-Standort in den Projekten Zürich
Der Zeitpunkt des Feierabends im Projekt Zürich Development und Zürich Maintenance
am Offshore-Standort variierte allerdings pro Mitarbeiter. Während ein Projektmitglied
um 17:00 Uhr seine Arbeit beendete, arbeitete ein anderer Mitarbeiter in der Regel bis
22:00 Uhr oder auch mal bis 23:00 Uhr. Dadurch erhöhte sich teilweise die Arbeitszeit,
innerhalb derer an beiden Standorten parallel gearbeitet wurde, erheblich.
Auch die Mitarbeiter des Kunden haben nicht alle den gleichen Arbeitsbeginn bzw. das
gleiche Arbeitsende. Die Zeiten schwanken zwischen 8:00-17:00 Uhr und 8:30-17:30
Uhr.
3.3.6.2 Kulturelle Unterschiede
Der Schweizer Projektleiter des Projekts Zürich Re-Engineering (KP05) sagt über unterschiedliche Wertvorstellungen und Einstellungen459 gegenüber dem indischen Anbieter aus, er habe die Erfahrung gemacht hat, dass die indischen Mitarbeiter ungern „nein“
sagen oder kommunizieren, dass bestimmte Anforderungen technisch nicht zu realisieren sind. „Stattdessen probieren sie im Hintergrund sämtliche Möglichkeiten aus, um
die Anforderungen des Kunden zu erfüllen, auch wenn keine Chance besteht diese
umzusetzen.“
Ein gut zu beobachtender kultureller Unterschied sind die unterschiedlichen Muttersprachen der an den Projekten Zürich beteiligten Personen: Die Mitarbeiter des Anbieters haben zum Teil unterschiedliche indische Regionalsprachen als Muttersprache,
kommunizieren aber in der Regel untereinander auf Hindi oder Englisch. Mitarbeiter
459
Wertvorstellungen und Einstellungen sowie Sprache werden in dieser Arbeit als Teil von Kultur
angesehen. Siehe hierzu auch Kapitel 2.2.3.
130
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
des Kunden sprechen hauptsächlich (Schweizer-)Deutsch als Muttersprache, aber auch
Italienisch und Englisch kommen als Muttersprache vor. Insbesondere die Endanwender
des Softwareprodukts in den Fachabteilungen des Kunden verfügen nur über geringe
Englischkenntnisse. Lediglich die IT-Abteilung des Kunden verfügt über mittelmäßige
bis gute Englischkenntnisse – insbesondere ist die Muttersprache des Abteilungsleiters
(AP01) Englisch. Im Gegenzug verfügen die Mitarbeiter des Anbieters, dazu gehört
auch das Onsite-Team, nur über äußerst geringe bis keine Deutschkenntnisse. Aufgrund
dieser Konstellation gestaltet sich gelegentlich die Kommunikation zwischen dem
Onsite-Team und manchen Mitarbeitern des Kunden schwierig, da sich diese nicht sehr
wohl mit einer englischen Kommunikation fühlen.460 Dies führt dazu, dass Informationen auf Englisch nicht so umfangreich und präzise ausgetauscht werden wie in der
eigenen Muttersprache.
Des Weiteren stellt ein Mitarbeiter des Kunden (KP03) fest, dass insbesondere das
Projekt Zürich Maintenance einen engen Kontakt mit den betroffenen Endanwendern
erfordert, da diese Probleme mit dem Softwareprodukt erkennen und an die Entwicklungsabteilung kommunizieren. Neben den sprachlichen Unterschieden macht sich an
dieser Stelle ein unterschiedliches Hintergrundwissen der Beteiligten bemerkbar. Bei
den Endanwendern handelt es sich um Bankfachleute und bei den Entwicklern um
Informatiker. Bei einer Kommunikation zwischen diesen beiden Personengruppen ist
daher nach Ansicht des Kunden (KP03) die Rolle eines Vermittlers auf sprachlicher und
inhaltlicher Ebene von hoher Bedeutung.
Bei den Projekten Zürich wurden unterschiedliche Dokumente in deutscher (D) oder
englischer (E) Sprache eingesetzt – Tabelle Tab. 3-8 stellt dies dar. Auch auf der Ebene
der erstellten Softwareprodukte traten die sprachlichen Unterschiede zum Vorschein
(Tab. 3-9).
460
Nach einer Aussage des Onsite-Koordinators (AP07).
131
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
E
Zürich Maintenance
D
D, E
E
D
D
E
E, D
Zürich Development
E
E
E
D
D
E
E, D
Dokumentation,
Sitzungsprotokolle
E
Statusberichte
-
Wöchentliche
D
Benutzerhandbuch
Testfälle
E
Impact Analyse
D
Zürich Re-Engineering
Spezifikation; bzw.
D, E
Projekt
Angebot, Vertrag
Design-Dokumente
(minutes of meetings)
Sprache einzelner Dokumente
461
Tab. 3-8 Sprache einzelner Dokumente in den Projekten Zürich
Die Spezifikation bildet das Referenzdokument des Kunden, in der die zu erbringende
Leistung festgehalten wird. Der Kunde stellt dem Anbieter keine Dokumente in englischer Sprache bereit. Protokolle von Sitzungen auf der Onsite-Seite wurden zum Teil in
Deutsch, meistens aber in Englisch verfasst. Technische Dokumente, wie zum Beispiel
Design-Dokumente, die durch den Anbieter erstellt wurden, waren stets in englischer
Sprache und wurden durch den Kunden akzeptiert.
Da es sich bei dem Projekt Zürich Development um eine Neuentwicklung handelt,
existierten keine Dokumente, die vom Deutschen ins Englische übersetzt werden mussten.
Bei dem Projekt Zürich Maintenance, dem Wartungsprojekt, hingegen war es notwendig vorhandene deutsche Dokumente in Englisch zu übersetzen. Dieser Übersetzungsaufwand wurde allerdings durch den Onsite-Koordinator als gering eingestuft und es
wurde vermutet, dass die Übersetzungen keine Auswirkung auf die Dauer der Entwicklung gehabt haben.462 Dieser Einschätzung steht gegenüber, dass kleinere Übersetzungsschwierigkeiten auftraten, von denen angenommen werden kann, dass sie zu einer
Erhöhung des Aufwands führten.
Die folgende Tabelle (Tab. 3-9) zeigt die verwendeten Sprachen in den erstellten Softwareprodukten der Projekte Zürich. Als „Sprache des Quellcodes“ sind in diesem Kon-
461
462
Legende: D = Deutsch; E = Englisch; - = Dokument in diesem Projekt nicht verwendet
Vgl. Anhang C.
132
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
text nicht Programmiersprachen gemeint, sondern damit wird die Landessprache bezeichnet, in der Kommentare, Variablen- oder Prozedurnamen verfasst sind.
Benutzeroberflä-
Zürich
Zürich
Zürich
Re-Engineering
Maintenance
Development
Das Softwarepro- Bereits
existie- Das Softwarepro-
che des Software- dukt verfügt über rende
produkts
keine
Benutzer- dukt verfügt über
Benutzer- oberflächen sind keine Benutzeroberauf Deutsch.
Interaktion mit dem Endanwender:
oberfläche.
fläche.
Zusätzlich ist das Allerdings ist das
Softwareprodukt
Softwareprodukt in
in weitere Soft- weitere
Software-
wareprodukte in- produkte integriert,
tegriert, die über die über deutschdeutschsprachige
sprachige Benutzer-
Benutzeroberflä-
oberflächen
chen verfügen.
gen.
verfü-
Sprache
von Das Softwarepro- Deutsch
Das
Ausgaben
oder dukt erstellt keine
dukt erstellt keine
Berichten
des Ausgaben
Softwareprodukts
Sprache
des
oder
Ausgaben
Berichte.
im Deutsch
Softwarepro-
oder
Berichte.
Vorhandener
Zwar
wurde
das
Vorfeld
existieren-
Quellcode ist in Produkt neu entwi-
den
Quellcodes
Deutsch,
neuer ckelt, doch da eine
(Kommentare, Vari-
Quellcode
wird enge Interaktion mit
ablen- und Proze-
auf
durnamen)
verfasst.
Englisch vorhandenen
temen
Sys-
stattfindet,
musste teilweise auf
existierenden deutschen
Quellcode
zurückgegriffen
werden.
Sprache
des
neu
Englisch
erstellten Quellcodes
Tab. 3-9 Verwendete Sprachen in den erstellten Softwareprodukten der Projekte Zürich
133
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
In dem Projekt Zürich Re-Engineering beschränkte sich der Übersetzungsaufwand
maßgeblich auf den Quellcode – z. B. Kommentare, sodass der Übersetzungsaufwand
geringer als derjenige in dem Projekt Zürich Maintenance eingeschätzt wird.463 Durch
deutsche Kommentare und Variablenbezeichnungen schätzt der Anbieter, dass es den
indischen Entwicklern erschwert wird den vorliegenden alten Quellcode zu verstehen.
Es wird vermutet, dass im Verhältnis zum Quellcode in englischer Sprache 10-15%
mehr Aufwand für die Realisierung des Projekts Zürich Re-Engineering benötigt wurde.
Zürich Re-Engineering
Zürich Maintenance
Zürich Development
E
E
D, E
D
E
E
D, E
D
E
E
D, E
D
D, E
schriftlich: D
mündlich: E
E
requests) durch den Kunden an Infosys
Änderungsanforderungen (engl. change
Endanwenders an Infosys
Fehlermeldungen des
die IT-Abteilung des Kunden
Fehlermeldungen des Endanwenders an
des Kunden an Infosys
Fehlermeldungen der IT-Abteilung
Diskussion während der Angebotsphase
Anbieter und Kunden
Projekt
Erster Kontakt zwischen
Sprache von Kommunikation
D
D
D
464
Tab. 3-10 Sprache von Kommunikation in den Projekten Zürich
Die Tabelle Tab. 3-10 stellt dar welche Sprachen für unterschiedliche Kommunikationszwecke eingesetzt wurden.
Aufgrund der deutschen Spezifikation (siehe Tab. 3-8) und der deutschen Anforderungsänderungen (siehe Tab. 3-10) wäre es nach Einschätzungen des OnsiteKoordinators und des Projektleiters des Kunden von Vorteil, wenn das Offshore-Team
der deutschen Sprache mächtig wäre, um diese Dokumente besser verstehen zu können.
Dies gilt insbesondere für das Projekt Zürich Maintenance, da hier Anforderungsände463
464
Siehe hierzu Tabelle Tab. 3-9.
Legende: D = Deutsch; E = Englisch
134
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
rungen häufiger auftraten als bei den anderen beiden Projekten. Weiter schätzt ein leitender Mitarbeiter der IT-Abteilung des Kunden, dass es möglich wäre den Umfang der
Offshore-Beziehung auch auf beratende Tätigkeiten auszudehnen, falls die Mitarbeiter
des Anbieters mit Kundenkontakt über deutsche Sprachkompetenzen verfügen würden.
Bei dem Projekt Zürich Maintenance wurden Fehlermeldungen oder neue Anforderungsänderungen durch den Endanwender auf Deutsch erfasst und an die IT-Abteilung
des Kunden gerichtet. Wenn diese dort nicht bearbeitet werden konnten, wurden sie an
den Onsite-Koordinator weitergeleitet. Der Onsite-Koordinator setzte dann eine Übersetzungssoftware ein, um die Anfrage in die englische Sprache zu übersetzen. In der
Regel sind diese wörtlichen Übersetzungen nur dann verständlich, wenn der Kontext
der Anfrage dem Onsite-Koordinator bekannt ist. Bei Fehlermeldungen ist dies meistens
der Fall. Doch insbesondere bei der Anfrage nach neuen Funktionalitäten ist es für das
Verständnis nötig, dass der Onsite-Koordinator mit der IT-Abteilung des Kunden oder
direkt mit dem Endanwender Rücksprache hält. Ist dann die Anfrage verstanden, wird
diese zur Umsetzung an das Offshore-Team weitergereicht. Dieser Prozess verdeutlicht,
dass aufgrund der unterschiedlichen Sprachen ein zusätzlicher Aufwand entsteht und
Verzögerungen bei der Bearbeitung von Anfragen entstehen können.
3.3.6.3 Prozessreife nach CMM
Infosys ist ein nach CMM Level 5 zertifiziertes Unternehmen und verwendet daher für
die Softwareentwicklung standardisierte Prozesse. Die IT-Abteilung des Kunden hingegen ist nicht nach CMM zertifiziert. Um Projekte durchzuführen, die den Anforderungen des CMM Level 5 entsprechen, war es daher notwendig, auf der Seite des Kunden
entsprechende Prozesse und Dokumentationen einzuführen. Der Anbieter vertritt den
Standpunkt, dass der zusätzliche Aufwand, der bei der Einführung und Durchführung
der Prozesse entsteht, auf lange Sicht in Bezug auf die Produktqualität und die Planungstreue sinnvoll ist.465
Der Kunde schätzt, dass die Prozesse seiner IT-Abteilung den Anforderungen des CMM
Level 3 entsprechen.466 Gleichzeitig strebt er eine stärkere Prozessorientierung an,
sodass er bereit ist, seine Prozesse den Anforderungen des Anbieters anzupassen.
465
466
Diese (erhoffte) Wirkung des CMM wurde von Aussagen des Onsite-Koordinators übernommen und
deckt sich mit den Annahmen der Befürworter des Prozessorientierten Softwarequalitätsmanagements (PSQM), die in Mellis /Projektmanagement/ 327-330 zusammenfassend dargestellt werden.
Nach Aussagen von KP01 und KP05.
135
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
3.3.6.4 Weitere Aspekte des Elements Umwelt
Bei den Ausführungen im Kapitel 2.2 wurden neben räumlicher und zeitlicher Distanz,
der Prozessreife sowie kulturellen Unterschieden weitere Aspekte des Elements Umwelt
behandelt. Zu diesen zählen Unterschiede in den Personalkosten, die hohe Verfügbarkeit von qualifizierten Arbeitskräften und rechtliche Aspekte. In Bezug auf rechtliche
Aspekte wurden von den an den Projekten beteiligten Personen weder Besonderheiten
noch Schwierigkeiten genannt, sodass dieser Aspekt nicht in einem separaten Abschnitt
untersucht wird.
Zu dem Aspekt Unterschiede in den Personalkosten wurden keine Informationen bereitgestellt, sodass an dieser Stelle keine Untersuchung erfolgen kann.
Zu dem Aspekt hohe Verfügbarkeit qualifizierter Arbeitskräfte lässt sich festhalten, dass
ein Motivationsgrund des Kunden zur Auslagerung einzelner Aufgaben an einen externen Anbieter darin lag, dass es ihm zum Zeitpunkt der Entscheidung an qualifiziertem
Personal mangelte.467 Weitere Aussagen zu diesem Aspekt sind auf der Ebene einzelner
Projekte und des vorliegenden Informationsmaterials nicht möglich.
467
Vgl. hierzu Untersuchung der Ziele in Kapitel 3.3.7. Hier wird auch auf weitere Ziele des Kunden
hingewiesen.
136
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
3.3.7
Untersuchung der Elemente Ziele, Erwartungen und negatives Ergebnis
Das Element Ziele und Erwartungen und das Element negatives Ergebnis stehen in
einem direkten Bezug zueinander.468 Denn werden Ziele und Erwartungen an ein Projekt nicht erfüllt, so handelt es sich um ein negatives Ergebnis. Daher werden an dieser
Stelle die beiden Elemente gemeinsam untersucht.
Die folgenden Tabellen – Tab. 3-11, Tab. 3-12 und Tab. 3-13 – stellen für alle drei
Projekte Zürich die Perspektive des Anbieters und die Perspektive des Kunden in Bezug
auf Ziele und Erwartungen an die Projekte gegenüber. Sind die Aussagen identisch,
wird pro Zeile eine gemeinsame Antwort-Zelle verwendet. Liegt keine Antwort vor, so
bleibt die entsprechende Zelle leer. Die auffälligste Abweichung in den Antworten des
Anbieters und des Kunden liegt in der Einschätzung des Projektserfolgs in dem Projekt
Zürich Re-Engineering vor. Während für den Kunden das Projekt seine Ziele eindeutig
nicht erreicht hat, gibt der Anbieter an, Teilziele erreicht zu haben. Diese Abweichung
verdeutlicht die unterschiedlichen Sichtweisen auf die Projekte.
Der Kunde hat angegeben, dass er den Umfang der Projekte mit dem Anbieter auch
aufgrund veränderter Rahmenbedingungen und eines Strategiewechsels nicht weiter
ausgedehnt hat.469 Zum einen waren nach dem dot-com-Boom in der Schweiz wieder
mehr benötigte Fachkräfte verfügbar, sodass aufgrund eines Fachkräftemangels nicht
mehr auf einen externen Anbieter zurückgegriffen werden musste. Weiter wurde auf
Unternehmensebene entschieden, dass in Zukunft verstärkt auf Standardsoftwareprodukte gesetzt und dadurch weniger Aufwand für eigene Entwicklungsprojekte betrieben
werden soll.
Ein grundlegendes Ziel des Kunden für die gesamte Offshore-Beziehung war das Erreichen einer hohen Flexibilität bei neutralen Kosten. Damit ist gemeint, dass der Kunde in
der Lage sein möchte bedarfsorientiert – mal mehr, mal weniger – Personal in Projekten
einzusetzen ohne selbst dazu notwendige personelle Ressourcen dauerhaft vorzuhalten.
468
469
Vgl. zur Darstellung des Elements negatives Ergebnis insbesondere Kapitel 2.9.
Telefoninterview am 05.07.2006 mit dem Projektleiter von Zürich Maintenance auf Seite des Kunden.
137
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Projekt:
Zürich
Re-Engineering
Aus Sicht des Anbieters
Aus Sicht des Kunden
Nein,
War das Projekt für
das Projekt wurde abgebrochen. Der Anbieter erlitt dadurch
den Anbieter erfolgreich?
einen Imageschaden beim Management des Kunden.
War das Projekt für
Nein,
den Kunden erfolg-
das vereinbarte Softwareprodukt konnte nicht eingesetzt wer-
reich?
den.
Reduzierung
Monetär
der
Entwick-
lungskosten
Zugang
Umwandlung von Fixkosten
in variable Kosten, dadurch
Steigerung der Flexibilität.
zu
IT-Know-how
Ziel des Kunden
bzw. Verteilung des IT-Know- Zugang zu IT-Know-how.
hows auf mehrere Personen, Pilotprojekt:
Strategisch
Möglichkeiten
um nicht von einigen wenigen von Offshore-Projekten abPersonen bei der Wartung der schätzen.
IT-Systeme abhängig zu sein.
Lernen wie ein nach CMM
Prozess-
Erreichung
einer
bezogen
Planungstreue.
höheren
Level 5 zertifiziertes Unternehmen arbeitet. Verstehen
wie
eine
Offshore-
Entwicklung funktioniert.
Produkt-
Verbesserung der Qualität.
bezogen
Einschätzung:
Teilweise.
Wurden die Ziele Das geplante Softwareprodukt
des
Kunden
er- (Software-Bibliotheken) wur-
reicht?
de nicht fertig gestellt. Jedoch
wurden im Rahmen der Ent-
(Frage wurde nur dem Anbieter gestellt)
wicklung erstellte Tools vom
Kunden eingesetzt.
Ziele des Anbieters
Aufbau einer umfangreichen Kundenbeziehung
und Kunde soll als Referenzkunde genutzt werden.
138
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Projekt:
Zürich
Re-Engineering
Aus Sicht des Anbieters
Einschätzung:
Aus Sicht des Kunden
Teilweise, da trotz Folgepro-
Hat der Anbieter jekten die Kundenbeziehung
seine
Ziele
Nein.
er- nicht im gewünschten Umfang
reicht?
ausgebaut werden konnte.
Ist die ausgelieferte Ja.
Produktqualität
Allerdings trat in bestimmten
zufriedenstellend?
Situationen
ein
technischer
Fehler aufgrund der Interakti-
Nein.
on mit einem fehlerhaften
System eines Dritt-Anbieters
auf.
Wurden alle funk- Alle funktionalen Anfordetionalen und nicht- rungen wurden erfüllt. Die
funktionalen
forderungen
An- nicht-funktionalen
Anforde-
er- rungen wurden nicht vollstän-
füllt?
dig erfüllt – insbesondere
aufgrund der Fehler im inter-
Nein. Die zu entwickelnde
Software war auf dem System
des Kunden nicht lauffähig.
agierenden System eines DrittAnbieters.
Tab. 3-11 Ziele aus der Perspektive des Anbieters und des Kunden für das Projekt Zürich Re470
Engineering
Das Projekt Zürich Re-Engineering wurde durch den Kunden vorzeitig abgebrochen
und es wurde nie eine auf dem System des Kunden lauffähige Version des geplanten
Produkts ausgeliefert. Der Kunde begründet das Scheitern des Projekts damit, ihm sei
während des Projekts stets versichert worden, dass die zeitliche und funktionale Planung eingehalten wird. Dadurch fiel eine Planabweichung erst während des Systemtests
auf – zu spät um noch Gegenmaßnahmen treffen zu können.
Dem Anbieter hingegen standen keine ausreichenden Simulationsmöglichkeiten des ITSystems des Kunden am Offshore-Standort zur Verfügung, sodass die entwickelte
470
Die Aussagen stammen aus den Antworten der schriftlichen Befragung. Siehe hierzu auch Anhang C.
139
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Software nicht frühzeitig getestet werden konnte, sondern Komplikationen mit dem
System eines Drittanbieters erst bei Systemtests am Ort des Kunden aufgetreten sind.
Weiter gab es ein Missverständnis über den Umfang der Projektleistung zwischen dem
Anbieter und dem Kunden, sodass der Anbieter mehr leisten musste, als er dies zu
Beginn des Projekts verstanden und geplant hatte.
Projekt:
Zürich
Maintenance
War das Projekt für
Aus Sicht des Anbieters
den Anbieter er-
Aus Sicht des Kunden
Ja.
folgreich?
War das Projekt für
den Kunden erfolg-
Ja.
reich?
Monetär
Reduzierung der
Umwandlung von Fixkosten
Entwicklungskosten.
in variable Kosten, dadurch
Steigerung der Flexibilität.
Zugang
zu
IT-Know-how
bzw. Verteilung des IT-Knowhows auf mehrere Personen,
Ziel des Kunden
um nicht von einigen wenigen
Strategisch
Personen bei der Wartung der
IT-Systeme abhängig zu sein.
Mit
technologischem
Zugang zu IT-Know-how.
Fort-
schritt und Veränderung des
Geschäftsumfeld Schritt halten
können.
Lernen wie ein nach CMM
Level 5 zertifiziertes Unter-
Prozess-
nehmen arbeitet. Verstehen
bezogen
wie eine OffshoreEntwicklung funktioniert.
Produktbezogen
140
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Projekt:
Zürich
Maintenance
Einschätzung:
Aus Sicht des Anbieters
Wurden die Ziele
des
Kunden
er-
Aus Sicht des Kunden
(Frage wurde nur dem Anbie-
Ja.
ter gestellt)
reicht?
Ziele des Anbieters
Aufbau einer umfangreichen Kundenbeziehung
und Kunde soll als Referenzkunde genutzt werden.
Einschätzung:
Hat der Anbieter
seine
Ziele
er-
Teilweise, da trotz Folgeprojekten die Kundenbeziehung nicht
im gewünschten Umfang ausgebaut werden konnte.
reicht?
Ist die ausgelieferte
Produktqualität
Ja.
zufriedenstellend?
Wurden alle funktionalen und nichtfunktionalen
An-
forderungen
er-
Ja.
füllt?
471
Tab. 3-12 Ziele aus der Perspektive des Anbieters und des Kunden für das Projekt Zürich Maintenance
Projekt:
Zürich
Development
War das Projekt für
Aus Sicht des Anbieters
den Anbieter er-
Aus Sicht des Kunden
Ja.
folgreich?
471
Die Aussagen stammen aus den Antworten der schriftlichen Befragung. Siehe hierzu auch Anhang C.
141
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Projekt:
Zürich
Development
War das Projekt für
Aus Sicht des Anbieters
Aus Sicht des Kunden
Ja.
den Kunden erfolgreich?
Monetär
Reduzierung der
Umwandlung von Fixkosten
Entwicklungskosten.
in variable Kosten, dadurch
Steigerung der Flexibilität.
Ziel des Kunden
Ausnutzung
Strategisch
des
IT-Know-
hows des Anbieters aus dem Zugang zu IT-Know-how.
Projekt Zürich Maintenance.
Produktentwicklung in einer Lernen wie ein nach CMM
möglichst kurzen Zeit.
Prozess-
Level 5 zertifiziertes Unternehmen arbeitet. Verstehen
bezogen
wie Offshore-Entwicklung
funktioniert.
Produktbezogen
Einschätzung:
Wurden die Ziele
des
Kunden
er-
(Frage wurde nur dem Anbie-
Ja.
ter gestellt)
reicht?
Ziele des Anbieters
Aufbau einer umfangreichen Kundenbeziehung
und Kunde soll als Referenzkunde genutzt werden.
Einschätzung:
Hat der Anbieter
seine
Ziele
er-
Teilweise, da trotz Folgeprojekten die Kundenbeziehung nicht
im gewünschten Umfang ausgebaut werden konnte.
reicht?
Ist die ausgelieferte
Produktqualität
Ja.
zufriedenstellend?
142
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Projekt:
Zürich
Aus Sicht des Anbieters
Development
Wurden alle funk- Ja,
Aus Sicht des Kunden
tionalen und nicht- allerdings hatte ein – gegenfunktionalen
An- über einem im Vorfeld genutz-
forderungen
er- ten IT-System, das ersetzt
füllt?
werden
sollte
Laufzeitverhalten
–
stabileres
eine
Ab-
nahme der Performance zur
Ja.
Konsequenz. (Konkret: Der
Durch höhere Stabilität sogar
Drucker startet später mit dem
übertroffen.
Druck, nachdem der Druckauftrag erteilt wird.) Dieses
Trade-Offs zwischen Performance und Stabilität war sich
die Kundenseite zu Beginn des
Projekts nicht bewusst.
Tab. 3-13 Ziele aus der Perspektive des Anbieters und des Kunden für das Projekt Zürich Develop472
ment
3.3.8
Untersuchung des Elements Einfluss durch andere Systeme und Projekte
Erfahrungen, die Beteiligte mit Offshore-Projekten und dem jeweils anderen Vertragspartner besitzen, wirken sich auch auf nachfolgende Offshore-Projekte aus.473 Des
Weiteren können sich andere Systeme, die Schnittstellen zum Entwicklungsgegenstand
des betrachteten Projekts besitzen, auf dieses Projekt auswirken.
Auch bei den Projekten Zürich liegt es nahe, dass sich die Projekte untereinander beeinflusst haben. Ein offensichtliches Indiz dafür ist, dass in den Projekten Zürich zum Teil
auf die gleichen Mitarbeiter zurückgegriffen wurde. Die Tabellen Tab. 3-14 und Tab.
3-15 zeigen dies für das Personal des Anbieters und des Kunden. Die Tabellen zeigen,
dass mehrere Beteiligte an mindestens zwei der drei Projekte Zürich beteiligt waren.
472
473
Die Aussagen stammen aus den Antworten der schriftlichen Befragung. Siehe hierzu auch Anhang C.
Vgl. allgemein zu dieser Beeinflussung Alter, Sherer /Model of IS risk/ 13.
143
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Dadurch konnten die Beteiligten bei Folgeprojekten auf bereits aufgebaute Erfahrungen
mit der vorliegenden Systemlandschaft und auf Erfahrungen im Umgang mit Personen –
sowohl aus dem eigenen Unternehmen als auch mit Personen des Vertragspartners –
zurückgreifen.
Die Tabelle Tab. 3-16 liefert zusätzlich eine chronologische Übersicht aller Projekte,
die zwischen dem Anbieter und dem Kunden stattgefunden haben. Das Projekt Zürich
First-Re bestand aus mehreren kleineren Re-Engineering Projekten, aber es wird im
Rahmen der vorliegenden Untersuchung nicht näher betrachtet.
Beteiligte Personen
des Anbieters
AP01
AP02
AP03
AP04
AP05
AP06
AP07
AP08
AP09
AP10
AP11
AP12
AP13
AP14
AP15
AP17
AP18
AP19
AP20
AP21
AP22
AP23
AP24
AP25
Anzahl direkt beteiligter
Personen des Anbieters
Zürich
Re-Engineering
Projektmanager
Architekt
Projektleiter
Projektleiter
Onsite-Koordinator
Entwickler
Entwickler
Entwickler
Entwickler
Entwickler
Entwickler
Entwickler
Zürich
Maintenance
Projektmanager
Projektmanager
Onsite-Koordinator
Projektleiter
Entwickler
Onsite-Koordinator
Projektleiter
Entwickler
Entwickler
Entwickler
Entwickler
Entwickler
Entwickler
Key Account Manager Key Account Manager
Entwickler
Programm-Manager
Manager
Manager
Qualitätssicherung
12
Zürich
Development
Entwickler
Entwickler
Key Account Manager
Programm-Manager
11
5
474
Tab. 3-14 Übersicht der beteiligten Personen des Anbieters in den Projekten Zürich
474
Die Anbieterpersonen AP20, AP22-AP25 sind dem Projekt übergeordnet und übernehmen eine
Management- oder beratende Funktion und werden daher nicht als direkt Beteiligte gezählt. AP16
war am Projekt Zürich Maintenance beteiligt, allerdings erst nach März 2006 und wird daher nicht
weiter in der vorliegenden Untersuchung betrachtet.
144
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Beteiligte Personen
des Kunden
Zürich
Re-Engineering
Zürich
Maintenance
Zürich
Development
Abteilungsleiter und
Verantwortlicher für
das gesamte System Abteilungsleiter
Projektleiter
KP01
KP02
Abteilungsleiter
Projektleiter
Technischer Berater
Architekt und Senior als Architekt und
Entwickler
Senior Entwickler
Analyst
(Schnittstelle
Deutsch/ Englisch)
Unterstützung aufgrund der Erfahrungen als Projektleiter
Vertreter aus der
Fachabteilung
KP03
KP04
KP05
Projektleiter
KP06
Anzahl direkt beteiligter Personen des Kunden
2
4
5
03.2006
01.2005
Zürich
Maintenance
03.2002
Zürich
Development
06.2005
11.2004
Zürich
Re-Engineering
04.2003
08.2002
Zürich
First-Re
09.2002
05.2002
Tab. 3-15 Übersicht der beteiligten Personen des Kunden in den Projekten Zürich
475
Tab. 3-16 Alle Projekte im Rahmen der Offshore-Beziehung zwischen dem Anbieter und dem Kunden
Neben der Beeinflussung der Projekte Zürich untereinander besteht auch die Möglichkeit, dass zum Beispiel Systeme eines Drittanbieters das gegenwärtige Projekt beeinflussen. Im vorherigen Kapitel wurde dieser Fall im Projekt Zürich Re-Engineering kurz
dargestellt. Durch Fehler in einem interagierenden System eines Drittanbieters konnten
nicht alle geplanten Funktionalitäten des Projekts Zürich Re-Engineering umgesetzt
werden. Die Komplikationen mit dem System des Drittanbieters wurden erst sehr spät
475
Hinweis: Zürich Maintenance ist ein fortlaufendes Projekt, bei dem ein konkreter zeitlicher Abschnitt
für die Untersuchung in dieser Arbeit festgelegt wurde.
145
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
im Entwicklungsprozess festgestellt, da der Anbieter das entwickelte Softwareprodukt
erst gegen Ende der Entwicklung in der vollständigen Systemlandschaft des Kunden
getestet hat. Der Anbieter verfügt aufgrund von spezifischer Hard- und Software nicht
über die Möglichkeit die Systemlandschaft des Anbieters vollständig simulieren zu
können.
3.3.9
Untersuchung des Elements Strategie
Wie in Kapitel 2.3.2 dargestellt, lässt sich eine Offshore-Beziehung durch die Ausprägungen unterschiedlicher Parameter charakterisieren. Für eine fokussierte Betrachtung
in dieser Arbeit wurden die Ausprägungen mancher Parameter vorgegeben. So werden
nur Offshore-Beziehungen mit dem Leistungsumfang einer selektiven Auslagerung
betrachtet. Auf der Ebene der betrachteten einzelnen Projekte treffen stets ein Kunde
und ein Anbieter aufeinander, auch wenn insbesondere bei einer unternehmensweiten
Betrachtung der Anbieter zu unterschiedlichen Kunden eine Offshore-Beziehung eingeht.
Weiter ist bei der vorliegenden Untersuchung vorgegeben, dass der Anbieter über eine
rechtlich vollständige Eigenständigkeit verfügt.
Die Ausprägungen der restlichen Parameter zur Charakterisierung einer OffshoreBeziehung wurden nicht weiter vorgegeben und sind in den einzelnen Projekten unterschiedlich. Sie werden in der Tabelle Tab. 3-17 dargestellt.
Beteiligte
Nationen
Projekt
Projektdauer
Vertragstyp
Zürich
Von August 2002 bis
Festpreis
Re-Engineering
April 2003
(fixed price)
Zürich
Maintenance
Anbieter: Indien Betrachteter ZeitKunde: Schweiz raum: Januar 2005 –
März 2006
Zürich
Von November 2004
Development
bis Juni 2005
Festpreis
(fixed price)
Aufwandsorientierte
Vergütung
(time and material)
Tab. 3-17 Ausprägungen der Parameter zur Charakterisierung der Offshore-Beziehungen
Der Anbieter der untersuchten Projekte verfolgt das Modell der Onsite-Offshore-Mix
Ressourcenverteilung.
146
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
3.3.10 Untersuchung des Elements Beteiligte
Das Element Beteiligte umfasst sämtliche am Projekt beteiligte Personen sowohl des
Anbieters als auch des Kunden. Die Ausführungen in Kapitel 3.3.8 liefern bereits eine
Auflistung der beteiligten Personen. Eine bedeutende Eigenschaft der Beteiligten zur
Erreichung der jeweiligen Projektziele sind deren Fähigkeiten und Erfahrungen.
ƒ
Sprachliche Kenntnisse
Auf die sprachlichen Kenntnisse der am Projekt Beteiligten wurde bereits bei der Untersuchung des Elements Umwelt in Kapitel 3.3.6.2 eingegangen, um kulturelle Unterschiede hervorzuheben.
ƒ
Technische Kenntnisse
In den Projekten Zürich verfügten die Teammitglieder des Anbieters zu Beginn der
Projekte nicht über alle notwendigen technischen Kenntnisse.
Im Projekt Zürich Re-Engineering und Zürich Maintenance lag dies daran, dass die
Projekte auf einem vorhandenen proprietären System des Kunden aufbauten.
Im Fall des Projekts Zürich Development hatten die Mitarbeiter des Anbieters bis zum
Beginn des Projekts noch kein Softwareprodukt dieser Art entwickelt. Jedoch verfügten
die Mitarbeiter des Anbieters in dem Projekt Zürich Development bereits aus dem
Projekt Zürich Maintenance über Kenntnisse mit der Systemlandschaft des Kunden.
ƒ
Projektspezifische Schulung
Alle Mitarbeiter des Anbieters der Projekte Zürich wurden vor Projektbeginn in einer
Schulung auf kulturelle Unterschiede aufmerksam gemacht.
Im Projekt Zürich Re-Engineering erhielten die Mitarbeiter des Anbieters eine erste
Einführung in die deutsche Sprache. Allerdings gibt der Projektleiter des Kunden an,
dass die Mitarbeiter des Anbieters über keine Deutschkenntnisse verfügen.
Um den Mangel an technischen Kenntnissen in den Projekten Zürich Maintenance und
Zürich Development auszugleichen, absolvierten die Teammitglieder des Anbieters eine
technische Schulung. Des Weiteren erhielten diese Projektmitglieder auch eine Einführung in die grundsätzlichen Geschäftsprozesse einer Bank.
Die Mitarbeiter des Kunden haben kein projektspezifisches Training – wie zum Beispiel
Sprach- oder Kulturtrainings – erhalten.
147
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
ƒ
Erfahrungen
Die Beziehung zu diesem Offshore-Anbieter ist für die Mitarbeiter des Kunden der erste
Kontakt mit einem Offshore-Anbieter.
Die meisten Mitarbeiter des Anbieters haben bereits vor den Projekten Zürich Erfahrungen in Offshore-Projekten mit anderen Kunden aufgebaut.476
3.3.11 Untersuchung des Elements Geschäftsprozess
3.3.11.1 Organisatorische Gestaltung: Spezialisierung
In den Projekten Zürich wurden für die Softwareentwicklung übliche Teilaufgaben
unterschieden.477 Tabelle Tab. 3-18 stellt diese Teilaufgaben dar, die im Folgenden kurz
charakterisiert werden. Die Projekte Zürich verwenden dieselben Teilaufgaben mit
Ausnahme der Anforderungsanalyse beziehungsweise der Impact Analyse. Maßgeblich
wurden, sofern dies nicht anders erwähnt wird, diese Aufgaben durch Mitarbeiter des
Anbieters erfüllt.
Zürich
Re-Engineering
Anforderungsanalyse
Zürich
Maintenance
Impact Analyse
Zürich
Development
Anforderungsanalyse
Design
Implementierung und Unit-Test
Integration und Integrationstest
Systemtest
Systemtest
(für ein paar Tools)
Abnahme und Einführung
(für ein paar Tools)
Abnahme und Einführung
Tab. 3-18 Teilaufgaben in den Projekten Zürich
476
477
Eine exaktere Aussage ist an dieser Stelle leider aufgrund des vorliegenden Datenmateriales nicht
möglich.
Zu Teilaufgaben in der Softwareentwicklung siehe z. B. Lang /Organisation/ 33-35, Mellis
/Projektmanagement/ 65-69 oder speziell für Teilaufgaben bei Infosys Jalote /CMM/ 75-85.
148
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
ƒ
Impact Analyse
Sind im Rahmen des Wartungsprojekts Fehler im Softwareprodukt zu beheben, so wird
während der Impact Analyse zuerst deren Ursache gesucht. Weiter werden bei der
Impact Analyse sowohl bei Fehlerbehebungen als auch bei Erweiterungen (engl. change
requests) die Konsequenzen der Änderungen auf andere Teile des gesamten Systems
analysiert.
Bei Fehlerbehebungen oder Erweiterungen von geringem Umfang findet keine klare
Trennung zwischen den Teilaufgaben Impact Analyse und Design statt.
ƒ
Anforderungsanalyse
Im Wesentlichen wird bei der Anforderungsanalyse das zu entwickelnde Softwareprodukt definiert und eine Spezifikation über das Softwareprodukt zwischen Auftraggeber
und Auftragnehmer vereinbart.
ƒ
Design
Während des Designs findet eine logische Betrachtung des zu entwickelnden Softwareproduktes statt. Es werden die Produktarchitektur und das Datenbankdesign festgelegt
und, sofern benötigt, werden an dieser Stelle auch Benutzeroberflächen geplant. Während des Designs werden auch einzelne Teile des Softwareprodukts (Units) voneinander
abgegrenzt, die später durch unterschiedliche Mitarbeiter realisiert werden können.
Wie bereits oben erwähnt, kam es bei Zürich Maintenance vor, dass keine strikte Trennung zwischen Impact Analyse und Design vorgenommen wurde.
ƒ
Implementierung und Unit-Test
Bei der Implementierung werden die zuvor spezifizierten einzelnen Teile des Softwareprodukts (Units) realisiert und im Rahmen von Unit-Tests werden diese separat getestet.
ƒ
Integration und Integrationstest
Bei der Integration werden die einzelnen Units zu einem Softwareprodukt zusammengefügt. Weiter wird das Softwareprodukt in die bestehende Systemlandschaft integriert.
Der Integrationstest prüft, ob die einzelnen Units untereinander und mit dem übrigen
System wie geplant zusammenarbeiten.
149
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
ƒ
Systemtest
Im Systemtest erfolgt eine Prüfung des entwickelten Softwareprodukts gegen die Spezifikation. Dabei können auch Fehler entdeckt werden, die sich durch das Zusammenspiel
des Softwareprodukts mit dem gesamten System ergeben.
ƒ
Abnahme und Einführung
Bei dieser Teilaufgabe nimmt der Kunde das entwickelte oder modifizierte Softwareprodukt ab und gibt es für den Betrieb frei.
Diese Teilaufgaben werden von Projektbeteiligten in unterschiedlichen Rollen übernommen. Diese Rollen werden im Rahmen der Konfiguration in Kapitel 3.3.11.3 näher
vorgestellt.
3.3.11.2 Organisatorische Gestaltung: Kontrolle
In dem Projekt Zürich Maintenance wurden nach Aussagen des technischen Beraters
(KP03) und des Mitarbeiters KP02 formale Kontrollen nur in einem sehr geringen
Umfang ausgeübt. So wurden keine Zwischenergebnisse oder ausgelieferte Produkte
mit im Vorfeld festgelegten Anforderungen überprüft. Es wurden zwar während der
Entwicklung vorab Softwareversionen ausgeliefert, dies geschah allerdings nur um
Probleme und Unklarheiten zwischen Mitarbeitern des Kunden und dem OnsitePersonal des Anbieters zu klären und nicht, um den Fortschritt des Projekts zu überwachen.
In den Projekten Zürich Re-Engineering und Development hingegen wurden schriftliche
Vorgaben an das Projekt gegenüber dem Anbieter formuliert und deren Einhaltung
während und am Ende des Projekts überprüft.
Im Sinne von Outcome Control hat der Kunde in den Projekten Zürich Softwaretests
durchgeführt. Zusätzlich hat der Kunde in den Projekten Zürich Development und
Maintenance eigene Analysen erstellt.
Code-Inspektionen (engl. walk throughs) wurden während der Entwicklung und nach
Auslieferung der Software durch den Kunden in dem Projekt Zürich Re-Engineering
und teilweise in dem Projekt Zürich Maintenance vorgenommen. Es gab in allen Projekten Zürich keine regelmäßigen Telefonkonferenzen zwischen dem Kunden und den
Projektmitarbeitern des Anbieters in Indien. Zwischen dem Abteilungsleiter (KP01) des
150
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Kunden und dem Management des Anbieters in Indien gab es lediglich jährliche Feedback-Telefonate. Weiter hat der Kunde dem Anbieter keine Entwicklungsmodelle,
Programmierrichtlinien oder andere Vorgehensweisen vorgegeben.
Als Instrumente von Behavior Control wurde der Kunde im Projekt Zürich Maintenance
monatlich und in den Projekten Zürich Re-Engineering und Development wöchentlich
in einem Statusbericht über den Projektstand informiert. Weiter standen die Personen
des Anbieters, die permanent beim Kunden vor Ort gearbeitet haben, unter der direkten
Beobachtung des Kunden.
Informale Kontrollen wurden in allen Projekten Zürich durch den Kunden nur in einem
geringen Umfang ausgeübt. Dadurch, dass stets ein bis zwei Mitarbeiter des Anbieters
beim Kunden vor Ort sind, besteht hier für den Kunden die Möglichkeit diese zu überwachen. Weiter gab es in den Projekten Zürich informelle Treffen zwischen Mitarbeitern des Kunden und des Anbieters. Diese Treffen sind hilfreich um gemeinsame Ziele
und Wertvorstellungen im Sinne der Clan Control zu etablieren.
Die Befragten des Kunden haben weiter ausgesagt, dass keine weiteren Instrumente
eingesetzt wurden, um die Einhaltung der Zeit- und Produktanforderungen zu überwachen. Lediglich eine Budgetüberwachung hat während und nach den Projekten stattgefunden.
151
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Die beiden folgenden Tabellen liefern einen Überblick der in den Projekten Zürich
eingesetzten formalen und informalen Kontrollinstrumente.
Outcome Control
Formale Kontrolle
Behavior Control
Mitarbeiter des Kunden besuchen regelmäßig den Anbieter
Nein
Mitarbeiter des Anbieters arbeiten vor
Ort beim Kunden
Inspektionen (engl. walk throughs)
durch den Kunden während und nach
der Entwicklung
Konferenz-Telefonate (Anbieter-Kunde)
Ja
Ja*
teilweise
Nein
Nein
wöchentwöchentmonatlich
lich
lich
Regelmäßige Berichte
Kunde gibt Entwicklungsmodelle,
Programmierrichtlinien oder andere
Vorgehensweisen vor
(Zwischen-)Ergebnisse werden schriftlich vorgegeben und ihre Einhaltung
überprüft
Funktionale Spezifikation
Performance-Anforderungen
Design-Dokumente
Projektplan, Projektzeitplan
Regelmäßige Auslieferung von Softwareversionen
Kunde führt Softwaretests durch
Kunde führt zusätzliche Analysen
durch
Tab. 3-19 Formale Kontrollinstrumente in den Projekten Zürich
478
Development
Kontrollinstrument
Maintenace
Kontrollmechanismus
ReEngineering
Projekt Zürich
Nein
Nein
Nein
Ja
Ja
Nein
Ja
teilweise
Nein
Nein
Ja*
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Ja*
478
Die Informationen stammen von Aussagen von Mitarbeitern des Anbieters. Dabei wurden mehrere
Mitarbeiter befragt, überraschenderweise gab es auf diese eindeutigen Fragen z. T. konträre Antworten. An dieser Stelle wird die Annahme getroffen, dass eine positive Antwort über die Anwendung
spezifischer Kontrollmechanismen einer negativen Antwort überwiegt, da davon ausgegangen wird,
152
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Informale Kontrolle
Clan Control
Anbieter-Team besucht den Kunden um
dessen Kultur zu verstehen
Self Control
Gemeinsame regelmäßige Treffen; Dinner
Meetings
Es arbeiten stets Mitarbeiter
des Anbieters beim Kunden
vor Ort, jedoch findet keine
regelmäßige Rotation statt,
sodass die meisten Mitarbeiter des Anbieters nie persönlichen Kontakt zum Kunden
hatten.
Ja
Konferenz-Telefonate
Nein
Kunde empfiehlt einzelne Vorgehensweisen, damit der Anbieter lernt sich selbst zu
kontrollieren
Nein
Kunde überwacht Mitarbeiter des Anbieters
Development
Kontrollinstrument
Maintenance
Kontrollmechanismus
ReEngineering
Projekt Zürich
Ja, aber nur Personen am Ort
des Kunden
Tab. 3-20 Informale Kontrollinstrumente in den Projekten Zürich
3.3.11.3 Organisatorische Gestaltung: Konfiguration
3.3.11.3.1 Konfiguration des Anbieters
Die Konfiguration beschreibt die äußere Form eines Stellengefüges in einer Organisation.479
Die Abbildungen Abb. 3-5 und Abb. 3-6 zeigen die Aufbauorganisation des Anbieters
in den Projekten Zürich. Die weißen Rechtecke entsprechen dabei den unterschiedlichen
Rollen der Mitarbeiter sowohl Onsite als auch Offshore (graue Rechtecke). Die verwendeten Pfeile entsprechen der folgenden Bedeutung:
dass nicht alle befragten Mitarbeiter des Anbieters über alle Details der Projekte informiert sind.
Diese Fälle sind in der Tabelle mit (*) markiert.
479
Vgl. Kapitel 2.4.6.
153
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Erstatten Bericht
Informelle Kommunikation
Onsite
Offshore
Projektmanager
Onsite-Koordinator
(plus personelle Unterstützung)
Projektleiter
Entwickler
Abb. 3-5 Aufbauorganisation des Anbieters in den Projekten Zürich Maintenance und Zürich Development
Im Zeitraum März 2005 bis Mitte Juni 2005 wurde der Onsite-Koordinator zusätzlich
durch einen Entwickler aus Indien unterstützt, da die Projekte Zürich Development und
Zürich Maintenance zeitgleich abliefen.
Onsite
Offshore
Projektmanager
Onsite-Koordinator
Projektleiter
Architekt
Entwickler
Abb. 3-6 Aufbauorganisation des Anbieters in den Projekten Zürich Re-Engineering
Gegen Ende des Projekts Zürich Re-Engineering sind der Projektmanager und der
Architekt zum Kunden (Onsite) gereist, um den Onsite-Koordinator zu unterstützen.
Im Folgenden werden die in den Abbildungen Abb. 3-5 und Abb. 3-6 aufgeführten
Rollen näher vorgestellt, um ein genaueres Verständnis der vorliegenden Konfiguration
und der Aufgabenverteilung zu vermitteln.
154
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
ƒ
Projektmanager
Der Projektmanager trägt die Verantwortung dafür, dass die vereinbarten Leistungen
erbracht, unternehmensweite Qualitätsprozesse angewendet und die vereinbarten Ergebnisse ausgeliefert werden. Er teilt den Projektmitgliedern einzelne Aufgaben zu,
überwacht die Leistungen der Projektmitglieder, den Projektfortschritt und berichtet an
hierarchisch übergeordnete Bereichsleiter und Accountmanager seines Unternehmens.
Weiter ist er Ansprechpartner für Angelegenheiten, die von außen an das Projekt getragen werde.
ƒ
Projektleiter
Der Projektleiter ist dafür verantwortlich, dass einzelne Teile des Softwareprodukts
(Units) fertig gestellt werden. Dazu verfolgt er deren Entwicklungsfortschritt. Er ist an
der Anforderungsanalyse und der Erstellung des Designs beteiligt. Er unterstützt Entwickler bei der Lösung technischer Probleme und übernimmt das Konfigurationsmanagement.480 Weiter übernimmt er Aufgaben der Qualitätssicherung wie Code-Reviews
und begleitet den Systemtest. Schließlich unterstützt der Projektleiter den Projektmanager bei der Definition und Einhaltung von Arbeitsabläufen.
ƒ
Architekt
Die Rolle des Architekten wurde nur im Projekt Zürich Re-Engineering explizit vergeben. Der Architekt entwickelt das Design und die grundlegende Architektur des zu
entwickelnden Softwareprodukts.
ƒ
Entwickler
Die Entwickler übernehmen die Detaillierung des Designs, die Implementierung, die
Unit-Tests, die Integration und den Integrationstest.
ƒ
Onsite-Koordinator
Der Onsite-Koordinator ist dauerhaft am Ort des Kunden. Er nimmt Produktanforderungen des Kunden entgegen und klärt unklare Anforderungen und Erwartungen an das
Projekt mit ihm ab. Er ist verantwortlich für die Koordination zwischen Kunde und
480
Das Konfigurationsmanagement umfasst insbesondere eine Versionsverwaltung des zu entwickelnden
Softwareprodukts. Vgl. z. B. Mellis /Projektmanagement/ 68.
155
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Offshore-Team. Er ist an der Erstellung des Designs und der Implementierung einzelner
Units beteiligt. Im Projekt Zürich Development nahm der Onsite-Koordinator auch
Code-Reviews vor. Weiter ist er für die Auslieferung, Installation und Konfiguration
des Softwareproduktes verantwortlich und führt Integrationstests durch. Während der
Abnahme durch den Kunden und der Einführungsphase des Softwareprodukts löst der
Onsite-Koordinator nötigenfalls dringende Konfigurationsprobleme oder andere Komplikationen.
3.3.11.3.2 Konfiguration des Kunden
Die Aufbauorganisation des Kunden für die IT-Abteilung und für die Projekte Zürich
Maintenance und Development sind in Abbildung Abb. 3-7 und Abb. 3-8 dargestellt.
WeisungsCIO
befugnis
Bereichsleiter
Logistik/ Verarbeitung
Bereichsleiter
Projektmanagement
Abteilungsleiter
für ein bestimmtes
System (KP01)
Projektleiter Zürich ReEngineering (KP05)
Abb. 3-7 Aufbauorganisation der IT-Abteilung des Kunden
Abteilungsleiter (KP01)
Weisungsbefugnis
Projektleiter (KP02)
Mitarbeiter (KP03, KP04)
Abb. 3-8 Aufbauorganisation des Kunden für die Projekte Zürich Maintenance und Development
Der Mitarbeiter KP03 war in den Projekten Zürich Maintenance und Development als
Architekt und Senior Entwickler beteiligt und übernahm insbesondere im Projekt Zürich
Development die Rolle eines technischen Beraters. Des Weiteren war er an Abnahme-
156
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
tests beteiligt. Der Mitarbeiter KP04 war nur im Projekt Zürich Development aktiv und
übernahm dort die Rolle des Analysten.
3.3.11.4 Organisatorische Gestaltung: Ablauforganisation
Die Ablauforganisation beschreibt die zeitliche und räumliche Anordnung der Teilaufgaben sowie deren Aggregation zu (Geschäfts-)Prozessen.481 Im Folgenden wird die
Ablauforganisation der drei Projekte Zürich dargestellt.482
3.3.11.4.1 Projekt Zürich Re-Engineering
Abbildung Abb. 3-9 zeigt den zeitlichen Ablauf der einzelnen Teilaufgaben im Projekt
Zürich Development. Hier wird die sequentielle Abfolge der Teilaufgaben deutlich, die
sich an dem Wasserfallmodell von Boehm orientiert.483
08.2002 09.2002 10.2002 11.2002 12.2002 01.2003 02.2003 03..2003 04.2003
Anforderungsanalyse
Design
Implementierung
und Unit-Test
Integration und
Integrationstest
Systemtest
(für ein paar Tools)
Abnahme und
Einführung
(für ein paar Tools)
Abb. 3-9 Zeitlicher Ablauf der einzelnen Teilaufgaben im Projekt Zürich Re-Engineering
Tabelle Tab. 3-21 und Abb. 3-10 geben die absolute und die prozentuale Verteilung des
Aufwands des Anbieters auf die unterschiedlichen Teilaufgaben im Projekt Zürich ReEngineering wieder. Genauere Informationen über die Verteilung des Aufwands zwischen dem Offshore- und dem Onsite-Standort für die einzelnen Aufgaben lagen für
dieses Projekt nicht vor. Da am Offshore-Standort nicht die spezifische Systemumge-
481
482
483
Vgl. Kapitel 2.4.8.
Da für die einzelnen Projekte unterschiedliche Daten vorlagen, weicht die Art der Darstellung zwischen den Projekten voneinander ab.
Vgl. zum Wasserfallmodell Boehm /Software engineering economics/ 35-38.
157
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
bung des Kunden – Hard- und Software – abgebildet werden konnte, wurden alle Tests
beim Kunden vor Ort (Onsite) durchgeführt.
Aufwand in
Personen-Stunden
595
389
2830
510
454
1156
5934
Anforderungsanalyse
Design
Implementierung und Unit-Test
Integration und Integrationstest
Systemtest (für ein paar Tools)
Aufwand für Projektmanagement
Gesamtaufwand
Tab. 3-21 Absolute Verteilung des Aufwands des Anbieters auf unterschiedliche Teilaufgaben im Projekt
Zürich Re-Engineering
10%
19%
Anforderungsanalyse
7%
Design
8%
Implementierung und Unit-Test
Integration und Integrationstest
9%
Systemtest
47%
Projektmanagement
Abb. 3-10 Prozentuale Verteilung des Aufwands des Anbieters auf die unterschiedlichen Teilaufgaben im
Projekt Zürich Re-Engineering
3.3.11.4.2 Projekt Zürich Maintenance
Die Darstellung des zeitlichen Ablaufs der einzelnen Teilaufgaben ist in dem Projekt
Zürich Maintenance nicht wie bei den anderen beiden Projekten in Form einer Übersicht
möglich. Denn das Wartungsprojekt Zürich Maintenance besteht aus einer Vielzahl an
Änderungswünschen (engl. change requests) von jeweils nur geringem Umfang.484 In
dem in dieser Arbeit untersuchten Zeitraum vom Januar 2005 bis März 2006 wurden die
einzelnen Teilaufgaben der Softwareentwicklung pro Änderungswunsch sequentiell
durchlaufen.
484
Hier bezieht sich „geringer Umfang“ auf einen Vergleich mit den Anforderungen, die in den anderen
beiden Projekten jeweils zu Beginn der Entwicklung spezifiziert wurden.
158
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Der absolute Aufwand, der zur Erfüllung der Teilaufgaben des Wartungsprojekts Zürich
Maintenance vom Anbieter benötigt wird, schwankt je Änderungswunsch bzw. je gefundenem Fehler. Idealtypisch findet aber folgende prozentuale Aufwandsverteilung auf
die unterschiedlichen Teilaufgaben statt:
10%
10%
Impact Analyse
10%
Design
20%
Implementierung und Unit-Test
Integration und Integrationstest
Systemtest
50%
Abb. 3-11 Prozentuale Verteilung des Aufwands des Anbieters auf die einzelnen Teilaufgaben im Projekt
Zürich Maintenance
Bei der räumlichen Verteilung des Aufwands des Anbieters über alle Teilaufgaben
wurde eine Aufteilung von 25% Onsite und 75% Offshore für das Projekt Zürich Maintenance angestrebt und auch erreicht.
Abbildung Abb. 3-12 zeigt die Arbeitsabläufe im Projekt Maintenance unter Berücksichtigung der Organisationszugehörigkeit der beteiligten Organisationseinheiten. Ausgangspunkt ist der Endanwender in der Fachabteilung des Kunden. Dieser gibt entdeckte Fehler in eine Anwendung zur Berichterstattung (engl. Reporting Application) ein.
Die IT-Abteilung des Kunden wertet diese Fehlermeldungen aus und versucht das
Problem zu beheben. Ist sie dazu nicht in der Lage, reicht sie den berichteten Fehler an
den Onsite-Koordinator weiter. Zwar verfügt der Onsite-Koordinator über Leserechte
für die Reporting Application, doch werden meistens entdeckte Fehler mündlich von
einem Mitarbeiter der IT-Abteilung des Kunden an den Onsite-Koordinator übermittelt.
Dieser versucht selbstständig den Fehler zu beheben. Falls dies für ihn nicht möglich ist
oder die Behebung aufwendiger ist, leitet er den Fehler an das Offshore-Team weiter,
wo dieser behoben wird.
Entwickelt ein Endanwender Ideen für Änderungen oder neue Anforderungen an die
bestehende Software, richtet er diese an das IT-Management. Unterstützt das IT-
159
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Management diese Ideen oder hat es eigene Ideen, leitet es diese an die IT-Abteilung
weiter. Die IT-Abteilung kommuniziert mündlich – gegebenenfalls gestützt durch ein
kurzes schriftliches Anforderungsdokument – diese Änderungswünsche an den OnsiteKoordinator. Dieser spezifiziert die Anforderungen formal und leitet sie, nach Absprache mit der IT-Abteilung über die Konsequenzen und den Aufwand für die Realisierung
der Anforderungen, an das Offshore-Team weiter.
Der Endanwender kommuniziert stets in deutscher Sprache. Dadurch findet entweder
bei der Kommunikation zum Onsite-Koordinator eine Übersetzung in die englische
Sprache statt oder der Onsite-Koordinator muss selber die ihm übermittelten Meldungen
ins Englische übersetzen.
Kunde
Änderung; neue
Anbieter
IT-Management
Änderung; neue
Anforderungen
Anforderungen
Endanwender
IT-Abteilung
Onsite-
Offshore
Koordinator
Team
Reporting
Fehlermeldung
Application
Abb. 3-12 Arbeitsabläufe im Projekt Zürich Maintenance
3.3.11.4.3 Projekt Zürich Development
Abbildung Abb. 3-13 zeigt den zeitlichen Ablauf der einzelnen Teilaufgaben im Projekt
Zürich Development. Auch hier wird die sequentielle Abfolge der Teilaufgaben deutlich.
Insgesamt wurden für die Projektabwicklung auf der Seite des Anbieters 3.750 Personen-Stunden in 6,5 Monaten benötigt. Diese Stunden wurden von fünf Mitarbeitern des
Anbieters erbracht, wobei zum einen nicht alle Mitarbeiter während der gesamten 6,5
Monate beteiligt waren und zum anderen Mitarbeiter parallel auch an dem Projekt
160
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Zürich Maintenance beteiligt waren, sodass sie nicht ihre gesamte Arbeitszeit für das
Projekt Zürich Development aufgewendet haben.485
12.2004
01.2005
02.2002
03.2002
04.2002
05.2003
06.2003
Anforderungsanalyse
Design
Implementierung
und Unit-Test
Integration und
Integrationstest
Systemtest
Abnahme und
Einführung
Abb. 3-13 Zeitlicher Ablauf der einzelnen Teilaufgaben im Projekt Zürich Development
Die Tabelle Tab. 3-22 und die Abbildung Abb. 3-14 zeigen die Verteilung des Aufwands des Anbieters auf die unterschiedlichen Teilaufgaben. Dabei werden sowohl die
absolut benötigten Personen-Stunden als auch die prozentuale Verteilung zwischen
Onsite und Offshore erbrachtem Aufwand dargestellt. Insgesamt werden 68% des gesamten Aufwands in Indien (Offshore) erbracht. Zu beachten ist, dass der präsentierte
Gesamtaufwand auch den Aufwand für Projektmanagementtätigkeiten beinhaltet.486
Anforderungsanalyse
Design
Implementierung und Unit-Test
Integration und Integrationstest
Systemtest
Abnahme und Einführung
Gesamtaufwand
Aufwand in Personen-Stunden
Onsite
Offshore
Gesamt
187
0
187
187
561
748
467
1401
1868
95
285
380
95
285
380
187
0
187
1218
2532
3750
Aufwand
Onsite
100%
25%
25%
25%
25%
100%
32%
Tab. 3-22 Verteilung des Aufwands des Anbieters auf unterschiedliche Teilaufgaben im Projekt Zürich
Development (inkl. Aufwand für Projektmanagement)
485
486
In Kapitel 3.3.8 befindet sich eine Übersicht der beteiligten Personen des Anbieters in den Projekten
Zürich.
Daten mit separat ausgewiesenem Aufwand für Projekmanagementtätigkeiten lagen nicht vor.
161
2000
1800
1600
1400
1200
1000
800
600
400
200
0
Offshore
fü
hr
un
g
Ei
n
un
d
e
Sy
st
em
te
st
In
te
gr
at
io
ns
te
st
In
te
gr
at
io
n
Ab
na
h
m
un
d
un
d
Un
itT
De
sig
n
en
t ie
ru
ng
Im
pl
em
An
fo
rd
er
un
gs
an
al
ys
es
t
Onsite
e
Personen-Stunden
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Abb. 3-14 Verteilung des Aufwands des Anbieters auf unterschiedliche Teilaufgaben im Projekt Zürich
Development (inkl. Aufwand für Projektmanagement)
Die Arbeitsabläufe im Projekt Zürich Development sind analog zu den Arbeitsabläufen
im Projekt Zürich Maintenance – siehe hierzu auch Abbildung Abb. 3-12.
Basierend auf Bedürfnissen des Endanwenders hat das IT-Management der Entwicklung des Softwareprodukts zugestimmt. Die IT-Abteilung hat die Anforderungen spezifiziert und an den Anbieter übergeben. Klärungen von Unstimmigkeiten und die Konkretisierung der Anforderungen wurden mit Hilfe des Onsite-Koordinators zwischen
dem Offshore-Team und der IT-Abteilung des Kunden kommuniziert. Wenn es notwendig war, hat die IT-Abteilung des Kunden zusätzlich mit dem Endanwender Rücksprache gehalten.
3.3.11.5 Organisatorische Gestaltung: Kommunikation
Neben einer objektiven Darstellung der verwendeten Kommunikationsmedien sollen
auch Erfahrungen der Beteiligten in den einzelnen Projekten über die verwendeten
Kommunikationsmedien im Rahmen der Fallstudienuntersuchung dargestellt werden.487
Diese Erfahrungen werden im Rahmen der Untersuchung des Elements Risiko im folgenden Kapitel präsentiert. Dort werden auf Grundlage der sozialen Netzwerkanalyse
(SNA) die Kommunikationsflüsse zwischen den beteiligten Personen in den Projekten
487
Siehe hierzu Kapitel 2.4.9.
162
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Zürich Development und Zürich Maintenance dargestellt und präsentiert, wie diese von
den Beteiligten wahrgenommen wurden.488
Die folgende Abbildung liefert einen Überblick der in den Projekten Zürich eingesetzten Kommunikationsmedien. Dabei werden die drei Kommunikationspartner Kunde,
Onsite-Koordinator und Offshore-Team unterschieden.
Kunde
ƒ
Face-to-face (täglich)
ƒ
E-Mail (selten)
ƒ
Impact Analyse, Design-
ƒ
Telefon (selten)
ƒ
E-Mail (selten)
ƒ
Schriftlich Statusberichte
OffshoreTeam
& Anforderungsdokumente
ƒ
Reporting Application
OnsiteKoordinator
ƒ
Telefon (täglich)
ƒ
E-Mail (täglich)
ƒ
Impact Analyse, Design- &
Anforderungsdokumente
ƒ
Dateiaustausch
489
Abb. 3-15 Verwendete Kommunikationsmedien in den Projekten Zürich und deren Häufigkeit
3.3.12 Untersuchung des Elements Risiken
3.3.12.1 Hinweis zur Vorgehensweise
Im Folgenden werden systematisch die bei der theoretischen Betrachtung als relevant
identifizierten Risiken in den Bereichen Umwelt, Beteiligte und Geschäftsprozesse
untersucht.490 Dazu wird festgestellt ob in den Projekten Zürich ein bestimmtes Risiko
aufgetreten ist, warum dieses Risiko aufgetreten ist bzw. warum es nicht aufgetreten ist
und mit welchen organisatorischen Maßnahmen in den Projekten mit diesen Risiken
488
489
490
In Kapitel 3.2.2 wird begründet, warum für das Projekt Zürich Re-Engineering keine SNA durchgeführt wurde.
Die Häufigkeitsangaben bei den Medien face-to-face, Telefon und E-Mail stammen aus der SNA.
„Selten“ bedeutet hierbei weniger als einmal in der Woche.
In Kapitel 2.8.3 erfolgt eine begründete Fokussierung auf diese für die Zielsetzung der Arbeit relevanten Risikobereiche.
163
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
umgegangen wurde. Bei dieser Untersuchung wird auch auf Ergebnisse der sozialen
Netzwerkanalyse zurückgegriffen.
Wie bereits in Kapitel 3.2.2 dargestellt wurde für das Projekt Zürich Re-Engineering
keine soziale Netzwerkanalyse durchgeführt. Damit stehen für eine Betrachtung über
den Umgang mit potentiellen Risiken in diesem Projekt nicht immer ausreichend Informationen zur Verfügung. Daher konzentriert sich die Untersuchung des Elements Risiken auf die Projekte Zürich Maintenance und Zürich Development. Diese Untersuchung
wird um Erkenntnisse aus dem Projekt Zürich Re-Engineering ergänzt, wenn hierzu
Informationen vorliegen.
Um eine systematische Untersuchung zu gewährleisten, wird im Folgenden auf die
Übersicht (Tab. 2-16) aus Kapitel 2.8.3.10 zurückgegriffen und pro Bereich die identifizierten Risiken untersucht.
3.3.12.2 Risiken im Bereich Umwelt
3.3.12.2.1 Räumliche und zeitliche Distanz
Risiko: Missverständnisse in der Kommunikation
ƒ Unvollständige Informationen; insbesondere wenn Kontextinformationen fehlen
ƒ Kein direktes Feedback bei asynchroner Kommunikation
In Bezug auf das Projekt Zürich Maintenance hat der Onsite-Koordinator ausgesagt,
dass gewünschte Anforderungsänderungen (engl. change requests) manchmal nicht
vollständig kommuniziert wurden. So hat bei manchen Anforderungsänderungen der
Kunde nicht berücksichtigt, dass Änderungen auch Auswirkungen auf andere, interagierende Systeme haben können. Diese Auswirkungen zogen allerdings weitere Änderungen nach sich, die zuerst mit dem Kunden abgeklärt werden mussten. Dadurch entstand
gegenüber einer vollständigen Beschreibung von Anforderungsänderungen zusätzlicher
Kommunikations- und Koordinationsaufwand.
Allerdings kann diese Unvollständigkeit in der Kommunikation nicht eindeutig auf die
räumliche und zeitliche Trennung zwischen Kunde und Offshore-Team zurückgeführt
werden. Stattdessen ist es ebenfalls vorstellbar, dass diese Komplikationen auch bei
nationalen Outsourcing-Beziehungen oder internen Entwicklungen auftreten.
164
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Um diesem Risiko entgegenzuwirken und möglichst vollständige Informationen auszutauschen, wurden in den Projekten Zürich Maintenance und Zürich Development bei der
schriftlichen Kommunikation im Rahmen der Impact Analyse und des Designs standardisierte Formulare eingesetzt.
Insgesamt sind die Missverständnisse in der Kommunikation aufgrund von räumlicher
und zeitlicher Distanz in dem Projekt Zürich Maintenance sehr gering und wurden vom
Kunden nicht wahrgenommen. In dem Projekt Zürich Development haben sogar Anbieter und Kunde angegeben, dass keine Missverständnisse aufgetreten sind.
Die folgenden Überlegungen untersuchen, warum dies der Fall ist.
Bei Betrachtung der Kommunikation zwischen den Beteiligten in den Projekten Zürich
Maintenance und Zürich Development fällt auf, dass zum einen synchrone Kommunikation (face-to-face oder telefonisch) von den meisten direkt an der Projektabwicklung
Beteiligten eingesetzt wird (Abb. 3-16 und Abb. 3-17) und zum anderen von vielen
Beteiligten täglich verwendet wird (Abb. 3-18 und Abb. 3-19).491
Die beiden Abbildungen zeigen, dass die beim Kunden sitzenden Mitarbeiter des Anbieters – der Onsite-Koordinator (AP07) und die Person AP13 – täglich synchrone
Kommunikation mit dem Kunden (hier face-to-face) und dem Offshore-Team (hier
telefonisch) hatten. Diese umfangreiche synchrone Kommunikation gegenüber dem
Offshore-Team wurde durch eine Angleichung der Arbeitszeiten des indischen Standorts unterstützt, so dass ein Zeitfenster für synchrone Kommunikation von bis zu acht
Stunden pro Tag zur Verfügung stand.492
491
492
An dieser Stelle ist noch einmal darauf hingewiesen, dass nicht von allen beteiligten Personen die
Daten zur sozialen Netzwerkanalyse erhoben werden konnten. Insbesondere können Kommunikationsflüsse zwischen Beteiligten des Anbieters nicht vollständig dargestellt werden. Vgl. auch Kapitel
3.2.2.
Vgl. zu den Arbeitszeiten in den Projekten Zürich Kapitel 3.3.6.1.
165
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
KP01
AP20
KP02
AP22
AP07
AP08
AP03
KP04
KP06
AP13
AP14
KP03
493
Abb. 3-16 Synchrone Kommunikation im Projekt Zürich Development (über alle Häufigkeiten)
494
Abb. 3-17 Synchrone Kommunikation im Projekt Zürich Maintenance (über alle Häufigkeiten)
493
494
Bzgl. der Vollständigkeit der dargestellten Kommunikation ist Kapitel 3.2.2 zu beachten.
Bzgl. der Vollständigkeit der dargestellten Kommunikation ist Kapitel 3.2.2 zu beachten.
166
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
495
Abb. 3-18 Synchrone Kommunikation im Projekt Zürich Development (täglich)
496
Abb. 3-19 Synchrone Kommunikation im Projekt Zürich Maintenance (täglich)
495
496
Bzgl. der Vollständigkeit der dargestellten Kommunikation ist Kapitel 3.2.2 zu beachten.
Bzgl. der Vollständigkeit der dargestellten Kommunikation ist Kapitel 3.2.2 zu beachten.
167
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Zwischen den Mitarbeitern des Anbieters, die beim Kunden vor Ort arbeiten (AP07 und
AP13), und dem Offshore-Team wird zusätzlich auch regelmäßige und intensive asynchrone Kommunikation eingesetzt (vgl. Abbildung Abb. 3-20 und Abb. 3-21). Die
asynchrone Kommunikation gegenüber dem Kunden ist hingegen weniger intensiv
ausgeprägt und wird erst in den Abbildungen Abb. 3-22 und Abb. 3-23 sichtbar, da hier
die Kommunikationshäufigkeit weniger als mehrmals in der Woche beträgt.
Abb. 3-20 Asynchrone Kommunikation im Projekt Zürich Development (mehrmals in der Woche)
168
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
497
Abb. 3-21 Asynchrone Kommunikation im Projekt Zürich Maintenance (mehrmals in der Woche)
498
Abb. 3-22 Asynchrone Kommunikation im Projekt Zürich Development (über alle Häufigkeiten)
497
498
Bzgl. der Vollständigkeit der dargestellten Kommunikation ist Kapitel 3.2.2 zu beachten.
Bzgl. der Vollständigkeit der dargestellten Kommunikation ist Kapitel 3.2.2 zu beachten.
169
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
AP19
AP09
AP17
AP18
KP01
AP14
AP07
KP02
AP21
KP03
AP08
KP05
AP13
AP15
AP20
AP25
AP24
AP23
AP03
AP22
499
Abb. 3-23 Asynchrone Kommunikation im Projekt Zürich Maintenance (über alle Häufigkeiten)
Die folgende Abbildung (Abb. 3-24) verdeutlicht die Ergebnisse der sozialen Netzwerkanalyse und fasst die vorherigen Graphen zusammen.
Die vorliegende Art der Kommunikation zwischen dem Kunden, dem Onsite-Personal
und dem Offshore-Team führt dazu, dass insgesamt keine Missverständnisse in der
Kommunikation aufgrund von räumlicher und zeitlicher Trennung in den untersuchten
Projekten aufgetreten sind. Insbesondere wurde durch die permante Arbeit des OnsiteKoordinators beim Kunden vor Ort die Problematik umgangen, dass asynchrone Kommunikation kein direktes Feedback zulässt.
Hinzu kommt, dass durch eine Angleichung der Arbeitszeiten in Indien und bei den
Mitarbeitern des Anbieters, die beim Kunden vor Ort arbeiten, das Zeitfenster für synchrone Kommunikation gegenüber den theoretischen Überlegungen erhöht wird.500
499
500
Bzgl. der Vollständigkeit der dargestellten Kommunikation ist Kapitel 3.2.2 zu beachten.
Zu den theoretischen Überlegungen siehe 2.2.2 und zu den Arbeitszeiten in den Projekten Zürich
siehe 3.3.6.1. Die Strategie der Anpassung der Arbeitszeiten wurde auch bei Espinosa, Carmel
/Impact/ 252 beobachtet.
170
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Synchrone Kommunikation: sehr selten
Asynchrone Kommunikation: selten
Kunde
Offshore-Team
Onsite-Personal
Anbieter
Synchrone Kommunikation: sehr häufig
Synchrone Kommunikation: sehr häufig
Asynchrone Kommunikation: selten
Asynchrone Kommunikation: sehr häufig
501
Abb. 3-24 Kommunikation in den Projekten Zürich Development und Zürich Maintenance
Auch eine formale Auswertung der Kommunikation in den beiden Projekten mit Hilfe
der sozialen Netzwerkanalyse unterstützt die bisher getroffenen Aussagen. Im Projekt
Zürich Development lassen sich bei Betrachtung der synchronen und asynchronen
Kommunikation mit mindestens wöchentlicher Häufigkeit (vgl. Abbildung Abb. 3-25 )
zwei Cliquen identifizieren:
{AP03 AP07 AP08 AP13 AP14} und
{AP07 AP13 KP02 KP03 KP04}502.
In dem Projekt Zürich Maintenance wurden drei Cliquen erkannt:
{AP03 AP07 AP13 AP14 AP17 AP18 AP19 AP21},
{AP03 AP07 AP09 AP13 AP14 AP17 AP18 AP21} und
{AP03 AP07 AP08 AP13 AP14 AP17 AP18 AP21}.503
501
502
503
Erläuterung zu den Häufigkeiten: Sehr selten = weniger als einmal in der Woche; selten = einmal/
mehrmals wöchentlich; sehr häufig = täglich.
Wobei die Verbindung zwischen KP02 und KP04 nicht erhoben wurde, da von diesen Personen keine
Daten zur Verfügung stehen. Aber es wird vermutet, dass zwischen diesen beiden Personen mindestens einmal wöchentliche Kommunikation stattfand, da sie in der gleichen Abteilung arbeiten.
Diese Cliquen bestehen ausschließlich aus Mitarbeitern des Anbieters. Dies ist auf den Umfang der
zur Verfügung stehenden Informationen zurückzuführen. Es ist zu erwarten, dass auf der Seite des
Anbieters weitere Cliquen bestehen. Allerdings können keine weiteren Cliquen mit dem OffshorePersonal auftreten, da diese ansonsten bereits direkte Verbindungen zum Kunden haben müssten.
171
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
In einer Clique steht jedes Mitglied in einem direkten Kontakt zu jedem anderen Mitglied dieser Clique.504 Es wird davon ausgegangen, dass innerhalb einer Clique ein
direkter Informationsfluss ohne Intermediaries existiert und dadurch tendenziell weniger
Missverständnisse sowie eine schnelle und einfache Verbreitung von Informationen
stattfindet.505
Risiko: Weniger effiziente Kommunikation
ƒ Bei asynchroner Kommunikation entstehen Wartezeiten auf Antworten
ƒ Mangels face-to-face Kommunikation werden quantitativ umfangreichere schriftliche Informationen ausgetauscht (Aufwand für Erstellung und Verarbeitung)
ƒ Terminvereinbarung für gemeinsame synchrone Kommunikation ist aufwendiger
ƒ Schwierigkeit den richtigen Ansprechpartner zu finden
ƒ Längere Kommunikationswege
ƒ
Bei asynchroner Kommunikation entstehen Wartezeiten auf Antworten
Der technische Berater des Kunden (KP03) in den Projekten Zürich Maintenance und
Development sowie der Abteilungsleiter des Kunden (KP01; alle Projekte Zürich)
haben ausgesagt, dass ihnen keine Wartzeiten auf Antworten aufgefallen sind, sondern
sie im Gegenteil das Antwortzeitverhalten der Mitarbeiter des Anbieters als schnell
empfanden. Eine Begründung hierfür könnte sein, dass viele Fragen direkt durch den
Onsite-Koordinator vor Ort beantwortet werden konnten oder dieser zumindest ein
direktes Feedback geben konnte, dass das Anliegen an die Kollegen in Indien weitergeleitet wird.
Bei den Beteiligten des Anbieters wurde hingegen berichtet, dass es teilweise zu Verzögerungen aufgrund der zeitlichen Distanz gekommen ist, wenn auf Antworten oder auf
Möglichkeiten für synchrone Kommunikation zwischen dem Onsite-Koordinator und
dem Team in Indien gewartet werden musste.
504
505
Vgl. Haythornthwaite /Social network analysis/ 332 oder Wasserman, Faust /Social network analysis/
254.
Vgl. Haythornthwaite /Social network analysis/ 334.
172
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Dass der Kunde Wartezeiten aufgrund asynchroner Kommunikation weniger stark
wahrgenommen hat als die Beteiligten des Anbieters lässt sich auch mit Hilfe der sozialen Netzwerke für die Projekte Zürich Maintenance und Zürich Development in Abbildungen Abb. 3-20 und Abb. 3-21 erklären. Asynchrone Kommunikation zwischen dem
Kunden und dem Anbieter findet nicht mehrmals wöchentlich statt. Synchrone Kommunikation findet hingegen täglich zwischen dem Kunden und dem Onsite-Personal des
Anbieters statt. Dadurch ergibt sich nicht die Situation, dass der Kunde auf eine Antwort warten muss.
Zwischen dem Onsite-Personal des Anbieters und den Mitarbeitern in Indien findet
hingegen eine häufigere und mehrere Personen umfassende asynchrone Kommunikation
statt. Hinzu kommt, dass diese beiden Gruppen in unterschiedlichen Zeitzonen arbeiten.
Durch diese Unterschiede lassen sich die unterschiedlichen Aussagen des Kunden und
des Anbieters in Bezug auf Wartezeiten bei asynchroner Kommunikation interpretieren.
ƒ
Mangels face-to-face Kommunikation werden quantitativ umfangreichere
schriftliche Informationen ausgetauscht (Aufwand für Erstellung und Verarbeitung)
Bei der Befragung der Beteiligten des Kunden zu diesem Risiko ergab sich ein uneinheitliches Bild, aus zum Teil gegensätzlichen Einschätzungen. Tabelle Tab. 3-23 führt
die Einschätzungen von drei Kundenpersonen auf. Die Einschätzungen sind im Verhältnis des jeweiligen Offshore-Projekts gegenüber einer internen Entwicklung formuliert.
KP01
KP02
KP03
Zürich
Zürich
Zürich
Re-Engineering
Maintenance
Development
Weder mehr noch Mehr und umfangrei- Mehr und umfangreiumfangreichere
Do- chere Dokumente
chere Dokumente
kumente
Weniger, aber umfang- Kaum
zusätzliche Mehr und umfangreireichere Dokumente
Dokumente
chere Dokumente
Kaum zusätzliche
Dokumente
Kaum
zusätzliche
Dokumente
Kaum zusätzliche
Dokumente
Tab. 3-23 Einschätzung über das Volumen der schriftlichen Kommunikation in den Projekten Zürich im
Verhältnis zu einer internen Entwicklung
173
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Dass das Volumen der schriftlichen Kommunikation uneinheitlich eingeschätzt wird,
lässt sich vermutlich zum einen auf die jeweiligen subjektiven Wahrnehmungen und
zum anderen auf die unterschiedlichen Rollen der Beteiligten in den Projekten Zürich
zurückführen.506
Auf Grundlage dieser zum Teil gegensätzlichen Einschätzungen lässt sich nicht beurteilen, ob das Risiko quantitativ umfangreicherer schriftlicher Informationen, die aufgrund
mangelnder face-to-face Kontakte ausgetauscht werden, in den Projekten Zürich eingetreten ist.
ƒ
Terminvereinbarung für gemeinsame synchrone Kommunikation ist aufwendiger
Nach Aussage von Mitarbeitern des Kunden (KP02 und KP03) trat dieses Risiko nicht
auf, da diese in allen Projekten Zürich keine gemeinsamen synchronen Konferenzen –
zum Beispiel Telefonkonferenzen – mit Mitarbeitern des Anbieters in Indien hatten.
Die Ergebnisse der sozialen Netzwerkanalyse bestätigen diese Aussagen und zeigen
weiter, dass synchrone Kommunikation zwischen Kunde und Anbieter nur vor Ort beim
Kunden stattfand (vgl. Abbildungen Abb. 3-16 und Abb. 3-17).
Zwischen den Mitarbeiten des Anbieters (Onsite-Personal und Offshore-Team) in den
Projekten Zürich ist es nach eigenen Aussagen hingegen durchaus vorgekommen, dass
auf Terminvereinbarungen für eine synchrone Kommunikation gewartet werden musste.
Allerdings wurde dies nicht als gravierende Schwierigkeit bezeichnet.
ƒ
Schwierigkeit den richtigen Ansprechpartner zu finden
Sowohl Beteiligte des Kunden (KP01, KP02 und KP03) als auch Mitarbeiter des Anbieters haben ausgesagt, dass es in den Projekten Zürich keine Schwierigkeiten gab, den
richtigen Ansprechpartner zu finden.
In das Projekt Zürich Development waren maßgeblich fünf Mitarbeiter des Kunden und
sieben Mitarbeiter des Anbieters involviert. Abbildung Abb. 3-25 zeigt die Kommunikation über die Medien E-Mail, Telefon und face-to-face, die mindestens wöchentlich
506
Zu den Rollen: KP01 = Abteilungsleiter; KP02 = Projektleiter; KP03 = technischer Berater.
174
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
stattgefunden hat. Dabei wird deutlich, dass Kontakte zwischen Kunde und Anbieter nur
über die beiden Mitarbeiter des Anbieters (AP07 und AP13) aufgebaut werden.
Dieser enge Kontakt ist auf Seite des Anbieters bewusst gewollt und wird von ihm als
„single point of contact“ bezeichnet. Ziel ist es, dass der Kunde genau einen Ansprechpartner für alle Fragen hat und auf der anderen Seite das Team in Indien nur über den
Onsite-Koordinator mit den Kunden in Kontakt treten kann.507 Der „single point“ besteht in diesem Projekt allerdings aus zwei Personen (AP07 und AP13), die beide vor
Ort beim Kunden tätig sind.
Aufgrund dieser klaren Schnittstelle zwischen Kunde und Anbieter konnten hier keine
Schwierigkeiten entstehen den richtigen Ansprechpartner zu finden. Für das OnsitePersonal des Anbieters (AP07 und AP13) war es auch keine Schwierigkeit den richtigen
Ansprechpartner im Offshore-Team zu finden, da diese einen tiefen Einblick in die
Aufgabenverteilung innerhalb des Offshore-Teams hatten und mit allen Mitgliedern in
Indien täglich Kontakt hatten.
Abb. 3-25 Kommunikation (synchron und asynchron) im Projekt Zürich Development (mindestens
508
einmal wöchentlich)
507
508
Battin u. a. /Global software development/ 71 schildern ein vergleichbares Vorgehen in einem global
verteiltem Team bei Motorola.
Bzgl. der Vollständigkeit der dargestellten Kommunikation ist Kapitel 3.2.2 zu beachten.
175
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Betrachtet man die Kommunikation zwischen den am Projekt Zürich Development
Beteiligten, die seltener als einmal in der Woche stattfand, ergibt sich ein etwas anderes
Bild (vgl. Abbildung Abb. 3-26).
Zum einen ist zu erkennen, dass die Anbieterperson AP20 sowohl Kontakt zum Kunden, zum Onsite-Team des Anbieters und zu Projektmitgliedern in Indien hat. Dies lässt
sich damit begründen, dass AP20 ein Accountmanager ist, der unterschiedliche Kunden
vor Ort in Deutschland und der Schweiz betreut. Dabei pflegt dieser sowohl Kontakte
zum Kunden als auch zu Schlüsselpersonen des Projektteams des Anbieters.
Weiter fällt auf, dass zwei Mitarbeiter des Kunden (KP01 und KP03) an der definierten
Schnittstelle des Onsite-Koordinators vorbei direkten Kontakt zu jeweils zwei Mitarbeitern in Indien hatten.
Leider konnten diese Mitarbeiter des Kunden zum Zeitpunkt der Befragung keinen
Grund oder die Inhalte dieser Kommunikation nennen. Daher lässt sich festhalten, dass
es zwar wenige Ausnahmen des Prinzips „single point of contact“ gab, dies aber zu
keinen Schwierigkeiten bezüglich des Auffindens des richtigen Ansprechpartners führte.
Abb. 3-26 Kommunikation (synchron und asynchron) im Projekt Zürich Development (über alle Häufig509
keiten)
176
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Dieselbe Situation findet sich auch in dem Projekt Zürich Maintenance wieder. Abbildung Abb. 3-27 zeigt die gesamte Kommunikation in diesem Projekt über alle Häufigkeiten. Auch hier ist das Prinzip des single point of contact deutlich zu erkennen, wobei
dieser single point die beiden vor Ort beim Kunden arbeitenden Mitarbeiter des Anbieters (AP07 und AP13) umfasst. Aufgrund dieser Kommunikations- und Rollenverteilung wird die Schwierigkeit den richtigen Ansprechpartner zu finden umgangen.
AP19
AP09
AP17
AP18
KP01
AP14
AP07
KP02
AP21
KP03
AP08
KP05
AP13
AP15
AP20
AP25
AP24
AP23
AP03
AP22
Abb. 3-27 Kommunikation (synchron und asynchron) im Projekt Zürich Maintenance (über alle Häufig510
keiten)
509
510
Bzgl. der Vollständigkeit der dargestellten Kommunikation ist Kapitel 3.2.2 zu beachten.
Bzgl. der Vollständigkeit der dargestellten Kommunikation ist Kapitel 3.2.2 zu beachten.
177
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
ƒ
Längere Kommunikationswege
Die Länge von Kommunikationswegen wird durch die Anzahl benötigter Kontakte von
einer Person zu allen anderen Personen definiert.
In den Projekten Zürich Maintenance und Zürich Development ergeben sich ähnliche,
jedoch nicht vollständig identische Bilder.
Wie bereits in der vorherigen Betrachtung dargestellt, wurde im Projekt Zürich Maintenance strikt das Prinzip des single point of contact eingehalten (vgl. Abbildung Abb.
3-27) und die Kommunikation zwischen Anbieter und Kunde findet nur über die Anbieterpersonen AP07 und AP13, die vor Ort beim Kunden arbeiten, statt. Hierdurch ergeben sich zwangsläufig längere Kommunikationswege zwischen Kunde und Mitarbeiter
des Anbieters in Indien.511
Auch im Projekt Zürich Development wird bei der Kommunikation, die mindestens
wöchentlich stattfindet (vgl. Abb. 3-25), das Prinzip single point of contact angewendet.
Jedoch ist auch zu beobachten (vgl. Abb. 3-26), dass zwei Mitarbeiter des Kunden und
zwei Mitarbeiter des Anbieters in Indien direkten nicht wöchentlichen Kontakt miteinander haben und dadurch sehr kurze Kommunikationswege entstehen.
In beiden Projekten herrscht innerhalb des Anbieters ein sehr enges Kommunikationsnetz, mit sehr vielen direkten und damit sehr kurzen Kommunikationswegen.512
Die in Abschnitt 3.3.6.2 dargestellten sprachlichen Unterschiede verhindern, dass Mitarbeiter des Anbieters direkt mit dem Endanwender kommunizieren können, sondern
auf einen Übersetzer zurückgreifen müssen, sodass an dieser Stelle längere Kommunikationswege entstehen.
Insgesamt wurde die Länge der Kommunikationswege von den Befragten in den Projekten Zürich Maintenance und Zürich Development nicht als problematisch beurteilt.
511
512
„Länger“ in Bezug auf die kürzestmögliche Kommunikation, die direkte Kommunikation zwischen
zwei Personen.
Siehe hierzu auch die Identifikation von Cliquen mit Hilfe der sozialen Netzwerkanalyse im vorherigen Abschnitt zum Risiko von Missverständnissen in der Kommunikation aufgrund räumlicher und
zeitlicher Distanz.
178
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
ƒ
Risiko: Weniger informelle und spontane Kommunikation
Entwicklung von Vertrauen wird erschwert
ƒ
Informelle Kommunikation fördert Koordination
Negative Effekte, die auf einer verringerten informellen und spontanen Kommunikation
beruhen, konnten in den Projekten Zürich nicht identifiziert werden. Im Folgenden wird
gezeigt, dass in den Projekten Zürich informelle und spontane Kommunikation stattfand.
Der Onsite-Koordinator hat in den betrachteten Projekten eine zentrale Rolle übernommen, um informelle und spontane Kommunikation zwischen dem Anbieter und dem
Kunden zu ermöglichen. Seine permanente Anwesenheit beim Kunden unterstützte
diese Form der Kommunikation und sorgte dafür, dass eine häufige und synchrone
Kommunikation praktiziert wurde.513 Bei der Untersuchung der verwendeten Kontrollinstrumente in den Projekten Zürich zeigt sich auch, dass regelmäßig gemeinsame
informelle Treffen zwischen Mitarbeitern des Anbieters und des Kunden stattfanden.514
Weiter bestand ein informeller Informationsaustausch zwischen dem OnsiteKoordinator und den Entwicklern sowie dem Architekten in Indien.515 Dieser wurde
durch häufige synchrone Kommunikation zwischen dem Onsite-Koordinator und dem
Offshore-Team gefördert.516 Dadurch besaß der Onsite-Koordinator einen umfassenden
Überblick über die Tätigkeiten der einzelnen Projektmitglieder in Indien und trug dazu
bei, dass gegenseitige Abstimmungen zwischen den am Projekt Beteiligten erleichtert
wurden.
Innerhalb des Offshore-Teams herrschte ebenfalls eine umfangreiche informelle und
spontane Kommunikation, die dadurch gefördert wurde, dass diese Projektmitglieder in
dem gleichen Büro arbeiteten.
Weil informelle und spontane Kommunikation in den Projekten Zürich vorhanden ist,
die Beteiligten die Kommunikation als offen und ehrlich517 bezeichnen und keine Koor513
514
515
516
517
Vgl. hierzu die oben dargestellten sozialen Netzwerkanalysen.
Vgl. zu den angewendeten Kontrollinstrumenten Kapitel 3.3.11.2.
Vgl. hierzu Kapitel 3.3.11.3.1.
Vgl. hierzu die oben dargestellten sozialen Netzwerkanalysen.
Vgl. hierzu die Untersuchungen zum Risiko „geringes Vertrauen zwischen den Beteiligten“ in Kapitel
3.3.12.3.
179
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
dinationsprobleme erkannt wurden, wird vermutet, dass der Umfang der informellen
und spontanen Kommunikation ausreichend vorhanden war.
Risiken im Bereich Umwelt in den Projekten Zürich,
die anhand der theoretischen Überlegungen nicht identifiziert wurden:
Verfügbarkeit der Systemumgebung
In den Projekten Zürich trat immer wieder das Problem auf, dass die IT-Systeme und
die dazugehörige Hardware des Kunden – in diesem Fall Kontoauszugsdrucker und
Bankautomaten – dem Entwicklerteam des Anbieters in Indien nicht zur Verfügung
standen. Aufgrund der großen räumlichen Distanz zwischen Entwicklerteam in Indien
und dem Standort der Systeme des Kunden in der Schweiz war es nicht möglich die
Softwareprodukte unter „realen“ Bedingungen zu entwickeln.
Daher wurde versucht, die Hardware in Indien durch ein Software-Tool zu simulieren,
um erste Tests durchführen zu können. Diese Simulation erforderte allerdings zusätzlichen Aufwand, da entsprechende Software-Tools erst entwickelt werden mussten.
Grundsätzlich besteht die Gefahr, dass die Simulation die Originalsysteme nicht exakt
widerspiegelt und daher keine präzisen Aussagen über die Lauffähigkeit der entwickelten Softwareprodukte unter „realen“ Bedingungen getroffen werden können. Daher
mussten zum Teil Unit Tests und Integration Tests beim Kunden vor Ort durchgeführt
werden. Darüber hinaus wurden auch einzelne Teile des Softwareprodukts (Units) vor
Ort beim Kunden entwickelt, falls ein direkter Zugriff auf andere Systeme oder Hardware des Kunden notwendig war.
Im Projekt Zürich Re-Engineering führte dieses Vorgehen dazu, dass das zu entwickelnde Softwareprodukt erst spät im Projektverlauf unter realen Bedingungen getestet
wurde. Erst dabei wurde festgestellt, dass es nicht mit den existierenden Systemen
zusammenarbeitet.
180
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
3.3.12.2.2 Kulturelle Unterschiede
Risiko: Missverständnisse in der Kommunikation
ƒ Sprachliche Unterschiede
o Bei unterschiedlichen Muttersprachen kann die Komplexität und der Umfang
verbal vermittelter Informationen geringer sein
o Beteiligte fühlen sich unsicher und unwohl bei der Kommunikation in einer
fremden Sprache
o Fehler bei Übersetzungen
ƒ Abweichendes Verhalten der Beteiligten aufgrund unterschiedlicher Wertvorstellungen und Einstellungen
Risiko: Weniger effiziente Kommunikation
ƒ Aufwand durch Übersetzungen
Sprachliche Unterschiede können zum Beispiel bei Übersetzungsfehlern zu Missverständnissen in der Kommunikation führen. Gleichzeitig rufen sprachliche Unterschiede
einen gewissen Aufwand für Übersetzungen hervor. Um eine redundanzfreie Darstellung der untersuchten Projekte zu gewährleisten, werden im folgenden Abschnitt die
unterschiedlichen Risiken aufgrund unterschiedlicher Sprachen gemeinsam betrachtet.
ƒ
Sprachliche Unterschiede
In Kapitel 3.3.6.2 wurde dargestellt, welche Sprachen bei der Projektabwicklung verwendet wurden.
Gespräche zwischen Onsite-Personal des Anbieters und dem Kunden fanden auf Englisch statt. Insbesondere der Endanwender verfügt nur über geringe Englischkenntnisse
und fühlte sich nicht sehr wohl mit der englischen Kommunikation.518 Wenn nötig
wurde bei Gesprächen mit dem Endanwender ein Übersetzer hinzugezogen.
Der technische Berater des Kunden (KP03), der über sehr gute Englischkenntnisse
verfügt, gab hingegen bekannt, dass ihm Dokumente in englischer Sprache keine
Schwierigkeit bereitet haben.
Wie die Darstellungen der sozialen Netzwerke in den Projekten Zürich Maintenance
und Zürich Development (vgl. Abb. 3-18 und Abb. 3-19) zeigen, fand zwischen dem
518
Diese Aussage wird durch AP13 gestützt. AP13 war beim Kunden vor Ort tätig.
181
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Kunden und dem Onsite-Personal eine häufige verbale Kommunikation statt.519 Inwieweit hierbei die Komplexität und der Umfang gegenüber der verbalen Kommunikation
zwischen zwei Personen mit identischer Muttersprache abgenommen haben, kann aufgrund der vorliegenden Informationen nicht endgültig geklärt werden. Allerdings bestand nach Einschätzung des Abteilungsleiters des Kunden (KP01), der als Muttersprache Englisch spricht, insbesondere während der Anforderungsanalyse bzw. der Impact
Analyse und des Designs in den Projekten Zürich Development und Maintenance eine
besondere Herausforderung in der sprachlichen Verständigung. Der Onsite-Koordinator
hingegen hat bei diesen Projekten keine sprachlichen Schwierigkeiten wahrgenommen.
Mitglieder des Offshore-Teams in den Projekten Zürich Development und Maintenance
gaben an, dass Übersetzungen von existierenden Dokumenten oder Quellcode mit signifikantem Aufwand verbunden war. Zum Beispiel werden Fehlermeldungen des vorhandenen Systems in Deutsch ausgegeben, die durch die indischen Entwickler erst übersetzt und verstanden werden müssen. Falls kein Übersetzer zur Verfügung stand und auf
Übersetzungssoftware zurückgegriffen werden musste, konnte dies zu Missverständnissen führen. Insbesondere in Fällen, in denen orthografische Fehler in den deutschen
Formulierungen vorlagen, wurde die softwaregestützte Übersetzung beeinträchtigt. Die
Entwickler des Anbieters in Indien gaben an, dass das Verständnis eines vorliegenden
Quellcodes erschwert wurde, wenn dieser in Deutsch – zum Beispiel deutsche Variablen- oder Funktionsbezeichnungen – vorlag.
Sowohl im Projekt Zürich Re-Engineering als auch im Projekt Zürich Maintenance
musste umfangreicher auf existierenden deutschen Quellcode und deutsche Dokumente
zurückgegriffen werden als im Projekt Zürich Development. Obwohl Zürich Development eine Neuentwicklung war, existierte bereits ein Modul, das neu geschrieben werden sollte. Daher traten auch bei diesem Projekt die genannten beobachteten Effekte
auf.
Die Mitarbeiter des Anbieters haben den Aufwand für Übersetzungen bewusst wahrgenommen und gaben für das Projekt Zürich Maintenance an, dass es aufgrund von Übersetzungen zu zeitlichen Verzögerungen bei der Bearbeitung einzelner Anforderungsän-
519
Die Abbildungen beziehen sich auf synchrone Kommunikation, die in diesem Fall ausschließlich
Telefonate und face-to-face Kontakte umfasst und damit mit verbaler Kommunikation gleichgesetzt
werden kann.
182
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
derungen gekommen ist, die bei einer rein englischen Kommunikation und einem vollständig englischen Softwareprodukt nicht entstanden wären.
Diese Beobachtungen zeigen, dass aufgrund der sprachlichen Unterschiede und der
mangelnden sprachlichen Fähigkeiten in der jeweils anderen Sprache ein zusätzlicher
Aufwand entstand. Allerdings konnten den durch Übersetzungsfehler verursachten
Missverständnissen keine gravierenden negativen Auswirkungen auf das Erreichen der
Projektziele nachgewiesen werden.
ƒ
Abweichendes Verhalten der Beteiligten aufgrund unterschiedlicher Wertvorstellungen und Einstellungen
Den Mitarbeitern des Anbieters in Indien in den Projekten Zürich Development und
Maintenance fielen keine unterschiedlichen Wertvorstellungen oder Einstellungen auf.
Dies ist insoweit nachvollziehbar, da die Mitarbeiter des Anbieters in Indien kaum
direkten Kundenkontakt hatten.520
Der Onsite-Koordinator im Projekt Zürich Development bemerkte hingegen, dass es
dem Kunden gelegentlich an Qualitätsbewusstsein mangelt, sodass diesem die Bedeutung von Produkt- und Prozessqualität an einzelnen Stellen erläutert werden musste.
Diese Einschätzung deckt sich mit den vom Kunden verfolgten Zielen, nämlich die
Prozessqualität der Entwicklung zu verbessern und von einem nach CMM Level 5
zertifizierten Unternehmen, wie es der Anbieter ist, zu lernen.521
Dem technischen Berater des Kunden im Projekt Zürich Development sind kulturelle
Unterschiede aufgefallen. Er gibt an, dass „man alles so genau und vollständig wie nur
möglich sagen oder schreiben muss. Was wir in der Schweiz als selbstverständlich
halten (und deshalb normalerweise verschweigen), ist es für unsere Infosys-Partner
nicht (und umgekehrt). Auch die Körpersprache ist unterschiedlich: um etwas zu bejahen, nicken wir mit dem Kopf, im Osten hingegen schüttelt man den Kopf.“.522
Der Projektleiter des Kunden im Projekt Zürich Re-Engineering sagt über die kulturellen Unterschiede gegenüber dem indischen Anbieter aus, dass er die Erfahrung gemacht
hat, dass die indischen Mitarbeiter ungern „nein“ sagen oder kommunizieren, dass
520
521
522
Vgl. hierzu Abb. 3-25, Abb. 3-26 und Abb. 3-27.
Vgl. zu den Zielen Kapitel 3.3.7.
Auszug aus der schriftlichen Befragung.
183
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
bestimmte Anforderungen technisch nicht zu realisieren sind. Stattdessen probieren sie
im Hintergrund sämtliche Möglichkeiten aus, um die Anforderungen des Kunden zu
erfüllen, auch wenn keine Chance besteht diese umzusetzen. Dazu gibt der Abteilungsleiter des Kunden an, dass Schwierigkeiten in der Projektabwicklung im Projekt Zürich
Re-Engineering lange durch den Anbieter verschwiegen wurden und der Kunde darüber
nicht informiert wurde.
Insgesamt geben die Beteiligten in den Projekten Zürich Maintenance und Zürich Development jedoch an, dass keine Missverständnisse aufgrund unterschiedlichen Verhaltens
aufgetreten sind.
Als vorbeugende Maßnahme haben die Beteiligten des Anbieters bereits im Vorfeld der
Projekte ein kulturelles Training erhalten. Weiter ist zu bemerken, dass alle Mitarbeiter
des Anbieters, mit denen der Kunde direkten Kontakt hat, an allen Projekten Zürich
mitgearbeitet haben.523 Dadurch bestand die Möglichkeit, über die Dauer der gesamten
Beziehung, mit dem jeweils anderen Kulturkreis vertraut zu werden. Deswegen ist es
nachvollziehbar, dass zum gegenwärtigen Zeitpunkt keiner der Beteiligten Missverständnisse aufgrund unterschiedlichen Verhaltens erkannt hat.
Risiko: Technische Komplikationen
ƒ Bei Verwendung landesspezifischer Sonderzeichen
ƒ Aufgrund unterschiedlicher Datumsformate
Bei keinem der Projekte Zürich traten technische Komplikationen aufgrund landesspezifischer Sonderzeichen oder unterschiedlicher Datumsformate auf.
Es ist zu vermuten, dass der Anbieter über ausreichende Erfahrungen aus Projekten mit
anderen Kunden verfügt, sodass diese Komplikationen nicht aufgetreten sind.
523
Vgl. hierzu Kapitel 3.3.8.
184
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
3.3.12.3 Risiken im Bereich Beteiligte
Risiko: Mängel in der Erfüllung der Projektanforderungen
ƒ Negative Auswirkungen von mangelnden fachlichen, technischen oder organisatorischen Kenntnissen auf die Zielerreichung
Der Abteilungsleiter des Kunden hat angegeben, dass die Mitarbeiter des Anbieters in
den Projekten Zürich Maintenance und Development über die notwendigen Kenntnisse
zur Projekterfüllung verfügt haben. Bei dem Projekt Zürich Re-Engineering vermutet er
allerdings, dass der Anbieter nicht über das notwendige technische Know-how verfügte
und dass dies im Vorfeld nicht umfassend genug als Risiko identifiziert wurde.
Nach Aussage des Onsite-Koordinators verfügten bei allen Projekten Zürich die Mitarbeiter des Anbieters nicht von Beginn des Projekts an über alle notwendigen technischen Kenntnisse, da es sich bei den Systemen des Kunden zum Teil um proprietäre
Technologien handelt. Weiter waren die meisten Mitarbeiter des Kunden nicht mit den
Arbeitsabläufen einer Bank vertraut. Daher erhielten sie in den Projekten Zürich Maintenance und Development einführende technische und fachliche Trainings.
Da die Projekte Zürich Maintenance und Development erfolgreich verliefen und die
Projektziele erreicht wurden,524 können hier keine negativen Auswirkungen aufgrund
eines anfänglichen Mangels an technischen und fachlichen Kenntnissen festgestellt
werden.
Das Projekt Zürich Re-Engineering hingegen wurde nicht erfolgreich abgeschlossen. Es
ist denkbar, dass mangelnde Kenntnisse der Mitarbeiter des Anbieters dazu beigetragen
haben, jedoch lassen sich diese mangelnden Kenntnisse nicht als alleinige Ursache dafür
verantwortlich machen. Zum Beispiel hat der Kunde erst mit Beginn der Beziehung zu
diesem Anbieter seine ersten Erfahrungen mit Offshore-Projekten aufgebaut, sodass
eventuell die Anforderungen in dem Projekt Zürich Re-Engineering nicht deutlich
genug formuliert worden sind oder es Defizite im Projektmanagement auf Seite des
Kunden gegeben haben könnte.
524
Vgl. hierzu 3.3.7.
185
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
Risiko: Geringeres Vertrauen zwischen den Beteiligten
ƒ Umfangreichere formelle Kontrollen, die zu höherem Aufwand und zeitlichen
Verzögerungen führen können
Sowohl die Mitarbeiter des Anbieters als auch des Kunden haben für alle Projekte
Zürich angegeben, dass sie den jeweils anderen als ehrlich und offen einschätzen. Des
Weiteren ist der Kunde davon überzeugt, dass keine sensiblen Daten durch den Anbieter
an einen Dritten weitergereicht wurden.
Im Kapitel 2.8.3.5 wurde bereits festgestellt, dass Vertrauen auf einem häufigen, offenen, ehrlichen und umfassenden Informationsaustausch basiert, erst im Laufe einer
Beziehung aufgebaut werden kann und durch persönliche face-to-face Kontakte gefördert wird.
Diese Voraussetzungen werden in der betrachteten Beziehung zwischen dem Anbieter
und dem Kunden erfüllt. So hat sich die Beziehung über mehrere Jahre in unterschiedlichen Projekten bei zum Teil gleichbleibendem Personal entwickelt.525 Insbesondere
durch den Onsite-Koordinator des Anbieters, der permanent in den Büros des Kunden
arbeitet, konnte ein häufiger und umfassender face-to-face Informationsaustausch stattfinden.526 Dadurch wird nicht nur die Kommunikation erleichtert, sondern auch der
Aufbau von Vertrauen gefördert. Gleichzeitig steht der Onsite-Koordinator im engen
Kontakt zu seinen Kollegen in Indien, mit denen er eine gemeinsame Kultur und eine
gemeinsame Firmenzugehörigkeit teilt. Damit übernimmt er eine bedeutende Vermittlerrolle, nicht nur um die räumliche Distanz, sondern auch um die kulturellen Unterschiede zu überwinden.
In den Projekten Zürich wurden zwar formale Kontrollen durchgeführt, dies aber nicht
in einem überdurchschnittlich umfangreichen Ausmaß, sodass nicht erkennbar ist, dass
hierfür auf der Seite des Kunden ein hoher Aufwand und zeitliche Verzögerungen entstanden sind.527
525
526
527
Vgl. hierzu Kapitel 3.3.8.
Vgl. hierzu die grafische Darstellung der sozialen Netzwerkanalyse in Abb. 3-18 und Abb. 3-19 im
Kapitel 3.3.12.2.1. Battin u. a. /Global software development/ 71 beobachten ein vergleichbares
Vorgehen. Bei der Untersuchung eines global verteilt arbeitenden Teams bei Motorola stellen sie
fest, dass Verbindungsleute genutzt werden, um durch einen anfänglichen persönlichen Kontakt
Vertrauen zwischen den Beteiligten aufzubauen. Auch Espinosa, Carmel /Impact/ 252 stellen ein
Vorgehen dar, bei dem Mitarbeiter eines indischen Softwareunternehmens vor Ort beim Kunden
Vertrauen zu Personen aufbauen.
Vgl. hierzu Kapitel 3.3.11.2.
186
Fallstudien-Untersuchung – Untersuchung der einzelnen Elemente des „work system“
3.3.12.4 Risiken im Bereich Geschäftsprozess
Risiko: Kontrollverlust
ƒ Bezogen auf Budget-, Termin- und Produktziele
Der Abteilungsleiter (KP01) und der Projektleiter (KP02) des Kunden wurden direkt
befragt, ob sie das Gefühl von Kontrollverlust in den Projekten Zürich gehabt haben.
Nach ihrer Aussage entstand bei ihnen in dem gescheiterten Projekt Zürich ReEngineering das Gefühl von Kontrollverlust. Dies kann damit begründet werden, dass
erst während des Integration Tests – am Ende der gesamten Projektlaufzeit – erkannt
wurde, dass die Projektziele nicht erreicht werden können und das Softwareprodukt in
der Systemumgebung des Kunden nicht vollständig lauffähig ist. Der Kunde war während der Entwicklung nicht in der Lage einzuschätzen, dass das Projekt seine Ziele
verfehlen wird, und konnte so auch keine frühzeitigen Gegenmaßnahmen einleiten.
In den erfolgreichen Projekten Zürich Maintenance und Zürich Development trat auf
Seite des Kunden kein Gefühl von Kontrollverlusten auf.
Ein deutlicher Zusammenhang zwischen in den Projekten Zürich eingesetzten Kontrollinstrumenten und dem unterschiedlich wahrgenommenen Gefühl von Kontrollverlusten
ist auf Basis der vorliegenden Informationen nicht zu erkennen.528
Die Mitarbeiter des Anbieters haben zwischen dem Offshore-Team und dem OnsiteKoordinator keine Kontrollverluste wahrgenommen.
528
Zu den eingesetzten Kontrollinstrumenten siehe Kapitel 3.3.11.2.
187
Abschließende Betrachtung – Überprüfung der Zielerreichung
4.
Abschließende Betrachtung
In diesem Kapitel wird zum einen überprüft, ob die Ziele dieser Arbeit erreicht wurden,
und zum anderen wird das Vorgehen zur Zielerreichung beurteilt.
Dazu wird in einem ersten Schritt die erarbeitete Forschungsantwort zusammenfassend
dargestellt. Darauf aufbauend wird im zweiten Schritt gezeigt, inwieweit die Forschungsantwort zur Lösung des Praxisproblems beiträgt und welche wesentlichen organisatorischen Maßnahmen identifiziert wurden, um Offshore-spezifische Besonderheiten und Risiken zu bewältigen. Schließlich erfolgt im dritten Schritt eine Beurteilung
der angewendeten Untersuchungsmethode, mit der die Forschungsantwort generiert
wurde. Das Kapitel endet mit einem Ausblick auf die nächsten Schritte, die notwendig
sind, um zu quantitativ bestätigten Aussagen im organisatorischen Umgang mit Besonderheiten und Risiken in Offshore-Projekten zu gelangen.
4.1
4.1.1
Überprüfung der Zielerreichung
Zusammenfassende Darstellung der Forschungsantwort
Zu Beginn dieser Arbeit wurden die folgenden drei Forschungsfragen formuliert und
motiviert:
ƒ
Wie können Offshore-Entwicklungen vollständig und systematisch dargestellt
werden?
ƒ
Welche Besonderheiten und Risiken treten bei einer Offshore-Entwicklung auf?
ƒ
Wie können diese Besonderheiten und Risiken mit organisatorischen Maßnahmen berücksichtigt werden?
Im Folgenden wird nun eine kurze Zusammenfassung der Forschungsantworten präsentiert und damit gezeigt, dass die verfolgten Fragen beantwortet wurden.
ƒ
Wie können Offshore-Entwicklungen vollständig und systematisch dargestellt
werden?
188
Abschließende Betrachtung – Überprüfung der Zielerreichung
Um Offshore-Entwicklungen vollständig und systematisch darzustellen, wurde auf den
allgemein gültigen „work system“-Betrachtungsrahmen von Alter529 und die RisikoModell-Erweiterung von Alter, Sherer zurückgegriffen.530
Dieser wurde für den Zweck der Darstellung und Untersuchung von OffshoreEntwicklungen angepasst. Die folgende Tabelle gibt alle Elemente des in dieser Arbeit
verwendeten Betrachtungsrahmens wieder.
Produkt und Service
Anbieter-, KundenUnternehmen
Infrastruktur
Umwelt
Strategie
Ziele und Erwartungen
Beteiligte
Negative Ergebnisse
Technologie
Risiken
Geschäftsprozess
Einfluss durch andere
Systeme oder Projekte
Tab. 4-1 Auflistung aller betrachteten Elemente
Auf Grundlage dieser Elemente wurde im zweiten Kapitel dieser Arbeit in einer projektübergreifenden Perspektive die Offshore-Entwicklung dargestellt. Damit wurde auch
ein Verständnis über den Kontext von Offshore-Entwicklungen vermittelt. Diese Kontextinformationen sind relevant, um organisatorische Gestaltungen in OffshoreEntwicklungen verstehen zu können.531
Im dritten Kapitel wurden dann mit Hilfe des Betrachtungsrahmens konkrete OffshoreProjekte untersucht.
Der Betrachtungsrahmen erfüllt die beiden Ziele, eine vollständige und systematische
Darstellung von Projekten zu ermöglichen.
Erstens unterstützt er eine vollständige Betrachtung von Offshore-Entwicklungen.
Aufgrund seiner zwölf Elemente wird eine umfassende Darstellung gewährleistet. Ins529
530
531
Vgl. Alter /Work system method/.
Vgl. Alter, Sherer /Model of IS risk/.
Über die Bedeutung der Berücksichtigung des Kontextes, um ein Phänomen verstehen zu können
siehe auch Darke, Shanks, Broadbent /Case study/ 273; Orlikowski /CASE tools/ 311 oder Yin
/Case study/ 13.
189
Abschließende Betrachtung – Überprüfung der Zielerreichung
besondere wird durch die projektübergreifende Darstellung auch auf den Kontext eines
Offshore-Projekts eingegangen. Dies ist hilfreich, um komplexe Situationen darzustellen und vorgefundene Entscheidungen – zum Beispiel über die Wahl der organisatorischen Gestaltung – nachvollziehen zu können.
Zweitens unterstützt er eine systematische Darstellung von Offshore-Entwicklungen.
Der Betrachtungsrahmen gibt mit seinen einzelnen Elementen eine klare Struktur für die
Betrachtung von Projekten vor, die eine systematische Fallstudienuntersuchung ermöglicht.
Jedoch fiel während der Anwendung des Betrachtungsrahmens auf, dass manche Aspekte mehrere Elemente betreffen können und es so zu Überschneidungen kommt.
Dadurch ergibt sich ein Interpretationsspielraum, wo die entsprechenden Aspekte diskutiert werden sollen. Zum Beispiel betrifft der Aspekt Sprache sowohl das Element Produkt und Service, das Element Umwelt (Kultur) und das Element Beteiligte. Ähnlich
können Kommunikationsrisiken im Bereich Geschäftsprozess oder im Bereich Umwelt
betrachtet werden. Schließlich lassen sich Risiken aufgrund mangelnden Vertrauens aus
Perspektive der Beteiligten oder als Konsequenz von räumlicher und zeitlicher Distanz
oder kulturellen Unterschieden im Bereich Umwelt untersuchen.
Durch diesen Interpretationsspielraum wurde zwar die Zuordnung eines Aspekts zu
einem Bereich erschwert, jedoch hat dies nicht die Identifikation des Aspekts beeinträchtigt, sodass der Betrachtungsrahmen dennoch eine systematische Darstellung von
Offshore-Entwicklungen ermöglicht hat.
ƒ
Welche Besonderheiten und Risiken treten bei einer Offshore-Entwicklung auf?
Insbesondere die Darstellung des Elements Umwelt geht auf die Besonderheiten einer
Offshore-Entwicklung ein. Als zentrale Besonderheiten wurden räumliche und zeitliche
Distanz sowie kulturelle Unterschiede identifiziert.
Der gewählte Betrachtungsrahmen unterstützt die Kategorisierung von Risiken, die in
der untersuchten Literatur identifiziert wurden, und liefert damit die Grundlage für eine
systematische Betrachtung.532 In Kapitel 2.8 erfolgt zum einen eine begründete Fokussierung auf für diese Arbeit relevante Risikobereiche. Zum anderen werden in Literatur
532
Zum Interpretationsspielraum bei dieser Kategorisierung siehe vorheriges Kapitel.
190
Abschließende Betrachtung – Überprüfung der Zielerreichung
identifizierte Risiken für die einzelnen Bereiche zusammengetragen, um einen Ausgangspunkt für die Untersuchung konkreter Projekte zu bilden.
ƒ
Wie können diese Besonderheiten und Risiken mit organisatorischen Maßnahmen berücksichtigt werden?
Auf Basis der in der Literatur erkannten Risiken erfolgt eine Untersuchung konkreter
Projekte, um zu erkennen, wie diesen Risiken mit organisatorischen Gestaltungsmaßnahmen begegnet werden kann.533 In Kapitel 4.1.3 erfolgt eine zusammenfassende
Darstellung der wesentlichen identifizierten organisatorischen Gestaltungsmaßnahmen.
4.1.2
Beitrag zur Lösung des Praxisproblems
Das Praxisproblem, das dieser Arbeit zugrunde liegt lautet: Es besteht die Gefahr, dass
Anbieter und Kunden ihre individuellen Ziele eines Offshore-Entwicklungsprojekts
nicht erreichen.
Die vorliegende Arbeit liefert einen Beitrag zur Lösung des Praxisproblems. Allerdings
handelt es sich dabei nicht um eine allgemein gültige Schritt-für-Schritt-Anleitung, wie
die organisatorische Gestaltung eines beliebigen Offshore-Projekts zu wählen ist, damit
das Projekt für beide Seiten erfolgreich abgeschlossen werden kann. Vielmehr unterstützt die Arbeit die an Offshore-Projekten beteiligten Personen Schwierigkeiten zu
identifizieren und Möglichkeiten zur Lösung dieser Schwierigkeiten zu erkennen.
Zum einen liefern die fundierten Darstellungen von Besonderheiten, Zielen und Risiken
von Offshore-Projekten in Kapitel 2 einen Anhaltspunkt, um vor Projektbeginn sich
dieser bewusst zu werden, um das Projekt gezielt darauf auszurichten.534
Zum anderen gibt das Kapitel 3 einen detaillierten Einblick über die Wahl der organisatorischen Gestaltung in konkreten Offshore-Projekten, um deren Besonderheiten und
Risiken zu überwinden.535 Die umfangreiche Darstellung des Kontexts der jeweiligen
533
534
535
Vgl. hierzu Kapitel 3.3.12.
Es sei an dieser Stelle darauf hingewiesen, dass selbst wenn die in der Literatur zu hunderten aufgeführten Risikofaktoren von unterschiedlichen Autoren kombiniert werden, dennoch stets das Risiko
der „Unvollständigkeit“ übrig bleiben wird, da in einem konkreten Projekt trotz sorgfältiger Risikoanalyse unvorhergesehene Ereignisse eintreten können. Vgl. hierzu Alter, Sherer /Model of IS risk/
9.
Die wesentlichen identifizierten organisatorischen Maßnahmen werden auch zusammenfassend im
folgenden Kapitel präsentiert.
191
Abschließende Betrachtung – Überprüfung der Zielerreichung
Projekte ermöglicht es, Wirkungen und Zusammenhänge von organisatorischen Gestaltungen zu erkennen.536
4.1.3
Wesentliche identifizierte organisatorische Maßnahmen
An dieser Stelle erfolgt nun eine Zusammenfassung der wesentlichen organisatorischen
Maßnahmen, mit denen in dem untersuchten Fall Offshore-spezifische Besonderheiten
und Risiken überwunden wurden.
Insbesondere bei der Untersuchung von Risiken in dem betrachteten Fall wurde auf die
Forschungsfrage der vorliegenden Arbeit eingegangen, wie mit organisatorischen Maßnahmen die Offshore-spezifischen Besonderheiten und Risiken überwunden werden
können. Die folgenden Tabellen fassen die Ergebnisse zusammen.
536
Auf die Grenzen der Aussagekraft von Fallstudienuntersuchungen wird in Kapitel 4.2 eingegangen.
192
537
Umwelt:
Räumliche
und zeitliche Distanz
Risikobereich
Eine ausführliche Darstellung der Inhalte dieser Tabelle erfolgt im Kapitel 3.3.12.
193
Quantitativ umfangreichere Informationen (Aufwändiger in der Erstellung und
in der Verarbeitung
Terminvereinbarung für gemeinsame
synchrone Kommunikation ist aufwändiger
Schwierigkeiten den richtigen Ansprechpartner zu finden
Längere Kommunikationswege
Entwicklung von Vertrauen wird erschwert
Informelle Kommunikation fördert Koordination
ƒ
ƒ
ƒ
ƒ
ƒ
Weniger informelle und
spontane
Kommunikation
ƒ
Bei asynchroner Kommunikation entstehen Wartezeiten auf Antworten
ƒ
Weniger
effiziente
Kommunikation
Kein direktes Feedback bei asynchroner
Kommunikation
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Unvollständige Informationen; insb.
wenn Kontextinformationen fehlen
ƒ
Missverständnisse
in der
Kommunikation
Onsite-Koordinator sorgt durch synchrone
Kommunikation zum Anbieter und zum
Offshore-Team auch für eine informelle und
spontane Kommunikation. Weiter gab es informelle Treffen zw. Anbieter und Kunde
(wurde nicht als Schwierigkeit eingestuft)
Kommunikation zwischen Anbieter und
Kunde nur über Onsite-Koordinator; Ansprechpartner ist immer gleich
Schwierigkeit konnte nicht festgestellt werden, auch weil keine synchrone Kommunikation zw. Offshore-Team und Kunde stattfand
(Schwierigkeit konnte nicht festgestellt
werden)
Face-to-face Kontakt zum Kunden; gegenüber Offshore-Team: nicht vermeidbar, da
mehr asynchrone Kommunikation
Häufige synchrone Kommunikation (längere
Arbeitszeiten in Indien; Onsite-Koordinator
ist vor Ort beim Kunden)
Standardisierte Dokumentation von Anforderungsänderungen
Organisatorische Maßnahmen
Erläuterung
Risiko
Abschließende Betrachtung – Überprüfung der Zielerreichung
Tab. 4-2 Zusammenfassende Gegenüberstellung von Risiken und organisatorischen Maßnahmen (1/3)
537
538
Umwelt:
Kulturelle
Unterschiede
(inkl.
Sprache)
Risikobereich
Organisatorische Maßnahmen
(Schwierigkeit konnte nicht festgestellt
werden)
(Schwierigkeit konnte zwar festgestellt werden, doch es existierte keine orga. Maßnahme zur Lösung)
(Schwierigkeit konnte nicht festgestellt
werden; orga. Maßnahme zur Vermeidung
konnte jedoch nicht identifiziert werden)
Offshore-Team hatte kaum direkten Kontakt
zum Kunden; kulturelles Training des Onsite-Personals; Personal des Anbieters, das
Kundenkontakt hat, bleibt über mehrere Projekte identisch (Lerneffekte)
Einsatz von Übersetzungssoftware
Sprach-Training
(Schwierigkeit konnte nicht festgestellt
werden)
(Schwierigkeit konnte nicht festgestellt
werden)
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Erläuterung
Bei unterschiedlichen Muttersprachen
kann die Komplexität und der Umfang
verbal vermittelter Informationen geringer sein
Beteiligte fühlen sich unsicher und unwohl bei der Kommunikation in einer
fremden Sprache
Fehler in Übersetzungen
Abweichendes Verhalten der Beteiligten
aufgrund unterschiedlicher Wertvorstellungen und Einstellungen
Übersetzungsaufwand
Bei Verwendung landesspezifischer
Sonderzeichen
Aufgrund unterschiedlicher Datumsformate
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Risiko
Missverständnisse
in der
Kommunikation
Weniger
effiziente
Kommunikation
Technische
Komplikationen
Abschließende Betrachtung – Überprüfung der Zielerreichung
Tab. 4-3 Zusammenfassende Gegenüberstellung von Risiken und organisatorischen Maßnahmen (2/3)
538
Eine ausführliche Darstellung der Inhalte dieser Tabelle erfolgt im Kapitel 3.3.12.
194
539
Geschäftsprozesse
Beteiligte
Risikobereich
Umfangreichere formelle Kontrollen, die
zu höherem Aufwand und zeitlichen
Verzögerungen führen können
Bezogen auf Budget- Termin und Produktziele
ƒ
ƒ
Geringes
Vertrauen
zwischen
den Beteiligten
Kontrollverlust
ƒ
ƒ
ƒ
ƒ
ƒ
Negative Auswirkungen von mangelnden fachlichen, technischen oder organisatorischen Kenntnissen
ƒ
Mängel in
der Erfüllung
der Projektanforderungen
Es wurden keine besonderen orga. Maßnahmen zur Lösung identifiziert
Aufbau von Vertrauen durch langfristige
Beziehung (mit zum Teil identischen Mitarbeitern)
persönliche face-to-face Kontakte zum
Kunden
Schulungen der Mitarbeiter des Anbieters
(fachlich und technisch)
Aufbau einer langfristigen Beziehung, um
von Lerneffekten zu profitieren
Organisatorische Maßnahmen
Erläuterung
Risiko
Abschließende Betrachtung – Überprüfung der Zielerreichung
Tab. 4-4 Zusammenfassende Gegenüberstellung von Risiken und organisatorischen Maßnahmen (3/3)
539
Eine ausführliche Darstellung der Inhalte dieser Tabelle erfolgt im Kapitel 3.3.12.
195
Abschließende Betrachtung – Überprüfung der Zielerreichung
Eine wesentliche organisatorische Maßnahme, die in den untersuchten Projekten identifiziert wurde, um Offshore-spezifische Besonderheiten und Risiken zu überwinden, ist
die Rolle des Onsite-Koordinators.
Bei dem Onsite-Koordinator handelt es sich um einen Mitarbeiter des Anbieters, der im
Rahmen konkreter Projekte permanent beim Kunden vor Ort tätig ist. Er gehört zum
gleichen Kulturkreis wie seine Kollegen in Indien und erhält im Vorfeld ein kulturelles
Training, das ihn auf die Zusammenarbeit mit dem Kunden vorbereitet. Weiter arbeitet
er über einen längeren Zeitraum für den gleichen Kunden.
Die Rolle des Onsite-Koordinators erzielt drei wesentliche Wirkungen. Erstens führt sie
dazu, dass der Kunde in einem permanenten face-to-face Kontakt mit dem Anbieter
steht. Damit wird informelle und spontane Kommunikation zwischen dem Anbieter und
dem Kunden erleichtert und der Aufbau von Vertrauen gefördert. Weiter erhält der
Kunde während des Projekts ein direktes Feedback auf seine Anfragen. Die gegenseitige Möglichkeit der direkten Nachfrage hilft Missverständnisse in der Kommunikation
zu minimieren. Da der Onsite-Koordinator aktiv an der Integration und Integrationstests
sowie Abnahmetests vor Ort beim Kunden beteiligt ist, „erlebt“ er persönlich dabei
auftretende Schwierigkeiten. Dadurch braucht der Kunde diese Schwierigkeiten nicht
mehr im Detail zu dokumentieren, um den Anbieter darüber zu informieren.
Zweitens wird durch eine Angleichung der Arbeitszeiten des Offshore-Teams eine
umfangreiche synchrone Kommunikation zwischen Onsite-Koordinator und OffshoreTeam gefördert. Da zusätzlich diese beiden Kommunikationspartner dem gleichen
Kulturkreis angehören, wird auch hier eine informelle und spontane Kommunikation
erleichtert. Diese Umstände unterstützen, trotz räumlicher und zeitlicher Distanz, ein
schnelles Feedback auf Anfragen. Die Möglichkeit der direkten Nachfrage hilft auch an
dieser Stelle, Missverständnisse in der Kommunikation zu minimieren.
Drittens fungiert der Onsite-Koordinator als offizielle Schnittstelle zwischen Kunde und
Anbieter. Dadurch ergibt sich eine extrem schmale Schnittstelle, die, gegenüber einer
mehrere Personen umfassenden breiten Schnittstelle, leichter zu beherrschen ist. Ebenso
wird die Schwierigkeit umgangen, den richtigen Ansprechpartner zu finden. Auch die
Koordination von Anforderungsänderungen wird erleichtert, weil sie stets über den
Onsite-Koordinator laufen und dieser somit den Überblick über sämtliche Anforderungsänderungen behält. Schließlich übernimmt der Onsite-Koordinator noch die Rolle
des Vermittlers zwischen den Kulturen.
196
Abschließende Betrachtung – Überprüfung der Zielerreichung
Insgesamt wird mit der Rolle des Onsite-Koordinators versucht, Schwierigkeiten, die
aufgrund der räumlichen und zeitlichen Distanz oder kultureller Unterschiede zwischen
Kunden und Anbieter auftreten können, auf das Innere der Organisation des Anbieters –
Onsite-Koordinator versus Offshore-Team – zu beschränken. Denn der Anbieter verfügt
über umfangreiche Erfahrungen mit diesen Schwierigkeiten und kann daher tendenziell
effektiver mit diesen umgehen.540
Die Bedeutung des Onsite-Koordinators beziehungsweise der Mitarbeiter des Anbieters,
die beim Kunden vor Ort tätig sind, für den Informationsfluss innerhalb der Projekte
lässt sich auch mit Hilfe der sozialen Netzwerkanalyse erkennen.541 Hierzu stehen insbesondere zwei Kennzahlen zur Verfügung. Die erste ist die lokale Zentralität (engl.
local centrality) einer Person, die angibt, wie viele Beziehungen aller möglichen Beziehungen dieser Knoten eingeht.542 Damit lassen sich die Popularität und die Bedeutung
einer Person ermitteln.
Zürich Development: AP13 9/11; AP07 9/11; KP03 9/11; AP03 8/11
Zürich Maintenance: AP13 18/19; AP07 14/19; AP03 13/19543
Die zweite Kennzahl ist die globale Zentralität (engl. global centrality).544 Sie gibt für
jede Person (= Knoten im Netzwerk) die minimale Summe aller Kanten an, die notwendig sind alle anderen Personen zu erreichen. Die Person mit dem niedrigsten Wert ist
diejenige mit der höchsten globalen Zentralität. Die folgende Tabelle führt die Personen
mit der höchsten globalen Zentralität in den beiden Projekten auf.
540
541
542
543
Eine vergleichbare Strategie wird bei Battin u. a. /Global software development/ 75 vorgestellt, als
bemerkt wird, dass es häufig schwierig ist, separate unabhängige Teams in ein gemeinsames Team
zu integrieren.
An dieser Stelle sei nochmals auf den Umfang der bei der Analyse zur Verfügung gestandenen Informationen hingewiesen und dass insbesondere auf der Seite des Kunden keine vollständigen Daten
für die soziale Netzwerkanalyse erhoben werden konnten. Vgl. hierzu 3.2.2. Dennoch sind die vorgenommenen Analysen hilfreich um die Bedeutung des Onsite-Personals des Anbieters zu demonstrieren. Die folgenden Auswertungen beziehen sich auf synchrone und asynchrone Kommunikation
über alle Häufigkeiten in den Projekten Zürich Maintenance und Development.
Vgl. hierzu Scott /Social network analysis/ 82-85. Knoten sind die grafischen Repräsentationen von
Personen in sozialen Netzwerken.
Schreibweise: x-Beziehungen / max. mögliche Anzahl Beziehungen
Rollen: AP13 (Onsite-Personal); AP07 (Onsite-Koordinator); AP03 (Projektmanager); KP03 (Architekt)
544
Vgl. hierzu Scott /Social network analysis/ 86f.
197
Abschließende Betrachtung – Beurteilung der angewendeten Forschungsmethode
Globale Zentralität
Person
Zürich Maintenance
Zürich Development
AP13 (Onsite-Personal)
22
13
KP03 (Architekt)
36
13
AP07 (Onsite-Koordinator)
26
13
AP03 (Projektmanager)
28
14
Tab. 4-5 Personen mit der höchsten globalen Zentralität in den Projekten Zürich Maintenance und
Development
Diese beiden Kennzahlen zeigen die Bedeutung des Onsite-Personals für die Kommunikation in den Projekten Zürich Maintenance und Zürich Development.
In den untersuchten Projekten wurden noch weitere Maßnahmen identifiziert, die helfen
Offshore-spezifische Besonderheiten und Risiken zu bewältigen. Zum Beispiel werden
Aufgaben dergestalt zwischen den Standorten des Anbieters verteilt, dass möglichst
wenig interglobale Kommunikation stattfindet.545 Weiter wurde versucht eine langfristige Beziehung zwischen dem Anbieter und dem Kunden aufzubauen. Dadurch wird die
Entwicklung von Vertrauen gefördert, womit der Aufwand für formale Kontrollen
reduziert werden kann. Eine langfristige Beziehung fördert auch Lerneffekte im Umgang mit der jeweils anderen Kultur, um Missverständnisse in der Kommunikation zu
verringern. Der Anbieter lernt dabei auch die spezifische Systemlandschaft des Kunden
besser kennen und kann so effizienter in dieser arbeiten.
4.2
Beurteilung der angewendeten Forschungsmethode
Nachdem im vorangegangenen Kapitel der Zielereichungsgrad dieser Arbeit überprüft
wurde, erfolgt nun eine Beurteilung der angewendeten Forschungsmethode. Hierzu
werden in einem ersten Schritt Beurteilungskriterien vorgestellt, um diese anschließend
auf die vorliegende Arbeit anzuwenden.
545
Diese Taktik wurde auch in vorherigen Untersuchungen identifiziert. Vgl. z. B. Carmel, Agarwal
/Global software development/ 24; Herbsleb, Mockus /Empirical/ 482; Mockus, Weiss
/Globalization/ 35 oder Olson, Olson /Distance/ 152.
198
Abschließende Betrachtung – Beurteilung der angewendeten Forschungsmethode
4.2.1.1 Validität der Konstrukte
Bei der Validität der Konstrukte gilt es zu verifizieren, ob die untersuchten Konzepte
korrekt operationalisiert sind. Das bedeutet, es wird überprüft inwiefern mit den erhobenen Informationen das gezeigt werden kann, was untersucht werden sollte.
Insbesondere bei Fallstudien-Untersuchungen ist es problematisch zu zeigen, ob ein
dokumentiertes Ereignis und dessen Ursachen tatsächlich objektiv aufgetreten sind oder
ob es mehr die subjektive Interpretation des Beobachters widerspiegelt.546
Yin gibt drei Taktiken an, mit denen eine möglichst hohe Validität der Konstrukte
erreicht werden soll.547 Diese wurden auch in der vorliegenden Untersuchung angewendet:
ƒ
Taktik 1: Verwendung mehrerer Informationsquellen bei der Datenerhebung
Um in der Fallstudie Informationen zu erheben, wurden sowohl mehrere Personen des
Anbieters als auch mehrere Personen des Kunden befragt.548 Weiter wurden im Rahmen
der sozialen Netzwerkanalyse sämtlichen an den Projekten beteiligten Personen die
gleichen Fragen gestellt.
ƒ
Taktik 2: Aufstellen einer Beweiskette
Bei dieser Taktik geht es darum, dass der Leser der Untersuchung die Möglichkeit hat,
jeden einzelnen Schritt der Untersuchung von der ursprünglichen Forschungsfrage über
die Datenerhebung bis zu den Schlussfolgerungen nachzuvollziehen.549 Dieser Taktik
wird dadurch Rechnung getragen, dass in der gesamten Arbeit stets dem „work system“-Betrachtungsrahmen gefolgt und dadurch ein strukturiertes Vorgehen ermöglicht
wird. Weiter sind im Anhang C die einzelnen Fragen und ihre Zugehörigkeit zu dem
jeweiligen Element des Betrachtungsrahmens dokumentiert, so dass nachvollziehbar ist,
wie die präsentierten Informationen gewonnen wurden.
546
547
548
549
Vgl. Yin /Case study/ 35.
Vgl. Yin /Case study/ 34-36.
Vgl. hierzu 3.1 Design der Untersuchung.
Vgl. hierzu Yin /Case study/ 105.
199
Abschließende Betrachtung – Beurteilung der angewendeten Forschungsmethode
ƒ
Taktik 3: Der Entwurf des Fallstudienberichts wird von Hauptinformanten geprüft.
Auf der Anbieterseite wurden die meisten Fragen im Rahmen der Informationserhebung
durch den Onsite-Koordinator (AP07) beantwortet. Bei Unklarheiten hat dieser gemeinsam mit dem Projektmanager (AP03) und dem Architekten (AP02) eine Antwort erstellt.
Auf der Kundenseite hat der Abteilungsleiter (KP01) die erhobenen FallstudienInformationen vor Veröffentlichung der Untersuchung gegengelesen.
Das Verfolgen dieser Taktiken stellt ein Indiz für eine hohe Validität der Konstrukte
dar.
4.2.1.2 Externe Validität
Bei externer Validität geht es darum Anhaltspunkte zu liefern, inwieweit die Ergebnisse
einer Fallstudienuntersuchung generalisierbar sind.550
Grundsätzlich kann der Fallstudienmethodik vorgeworfen werden, keine verallgemeinerbaren Ergebnisse zu generieren, da es sich stets um die Betrachtung von Einzelfällen
handelt. Hierbei sollten aber zwei Arten der Generalisierbarkeit unterschieden werden:
statistische und analytische Generalisierbarkeit. Ein Beispiel für statistische Generalisierbarkeit ist die Auswertung von Fragebogenerhebungen. Hierbei wird von einer
ausreichend großen Samplegröße auf die Allgemeinheit geschlossen. Bei analytischer
Generalisierung wird hingegen von konkreten Ergebnissen (einer Einzelfalluntersuchung) auf eine breitere Theorie geschlossen.
Daher ist bei einer Fallstudienuntersuchung die Analogie zu Samplegröße und Universum wie bei Umfragen unzulässig. Es geht bei Fallstudienuntersuchungen nicht darum
von dem betrachteten Fall auf andere Fälle zu schließen, sondern darum vom betrachteten Fall auf theoretische Erkenntnisse zu schließen, wie es auch bei Experimenten praktiziert wird. Um dies zu ermöglichen wurden die betrachteten Offshore-Projekte dieser
Arbeit möglichst umfangreich dargestellt. Damit sollen die Wirkungszusammenhänge
der gewählten organisatorischen Gestaltungsmaßnahmen in ihrem jeweiligen Kontext
zu erkennen sein. Insbesondere die in Kapitel 4.1.3 als wesentlich identifizierten organi-
550
Vgl. zu diesem Abschnitt Yin /Case study/ 37.
200
Abschließende Betrachtung – Beurteilung der angewendeten Forschungsmethode
satorischen Gestaltungsmaßnahmen liefern die Basis für das Aufstellen von Hypothesen
über Wirkungszusammenhänge.551
4.2.1.3 Glaubwürdigkeit
Eine hohe Glaubwürdigkeit (engl. reliability) kann erreicht werden, wenn sichergestellt
wird, dass die gleiche Fallstudie von einer dritten Person wiederholt werden kann,
sodass die gleichen Ergebnisse erzielt werden.552 Voraussetzung hierfür ist, dass zum
einen der gleiche Fall untersucht wird und dass die angewendete Vorgehensweise dokumentiert wird. Tabelle Tab. 4-6 zeigt zum einen die Gegenstände dieser Dokumentation nach Yin und zum anderen, an welcher Stelle der vorliegenden Arbeit diese berücksichtigt wurden.553
Gegenstand
Vorkommen in der vorliegenden
Arbeit
Erläuterung
Ziele, Berücksichtigung
Einführung in das
der relevanten Literatur,
Fallstudienprojekt theoretischer Rahmen der
Kapitel 1 und 2
Untersuchung
Wann und wie wurden
Prozedur der
die Daten erhoben?
Datenerhebung
Welche Informations-
Kapitel 3.1
quellen wurden genutzt?
Welche Fragen wurden
Fallstudien-
im Rahmen der Fallstu-
Fragen
dienuntersuchung ge-
Anhang C
stellt?
551
552
553
Vgl. Kapitel 4.3 zu den notwendigen nächsten Schritten, um empirisch bestätigte Aussagen bezüglich
der organisatorischen Gestaltung bei Offshore-Projekten zu erhalten.
Vgl. zu diesem Abschnitt Yin /Case study/ 37-39.
Vgl. Yin /Case study/ 69.
201
Abschließende Betrachtung – Ausblick
Gegenstand
Vorkommen in der vorliegenden
Arbeit
Die Präsentation der gesammelten
Erläuterung
Informationen richtet sich nach
dem im Vorfeld aufgestellten theoFestlegen von Datenfor-
retischen Betrachtungsrahmen.
maten für die Erhebung
„Datenformate“ mussten bei dieser
Leitfaden für den
und Präsentation der
Untersuchung nicht festgelegt
Fallstudienbericht
Daten.
werden, da es sich bei den erhobe-
Angabe von bibliografi-
nen Informationen um verbal-
schen Informationen.
sprachliche Äußerungen handelte.
Bibliografische Informationen
befinden sich im Literaturverzeichnis.
Tab. 4-6 Gegenstände der Fallstudien-Dokumentation
Jeder Gegenstand der obigen Tabelle wurde umfangreich und präzise in der vorliegenden Arbeit dargestellt, sodass gewährleistet ist, dass diese Untersuchung wiederholbar
und damit glaubwürdig ist.
4.3
Ausblick
Nachdem nun die Zielerreichung der Arbeit überprüft wurde, wesentliche Erkenntnisse
der Arbeit zusammenfassend wiederholt wurden und die angewendete Forschungsmethode beurteilt wurde, gilt es nun auf die nächsten Schritte hinzuweisen, die notwendig
sind, um zu bestätigten Aussagen im organisatorischen Umgang mit Besonderheiten
und Risiken in Offshore-Projekten zu gelangen.
Auf Grundlage der untersuchten Fallstudie können Hypothesen über die Wirkung von
organisatorischen Maßnahmen in Bezug auf die Überwindung von Offshorespezifischen Besonderheiten und Risiken formuliert werden. Diese Hypothesen gilt es
in einem ersten Schritt qualitativ mit Hilfe von Erkenntnissen aus Untersuchungen
anderer Autoren zu untermauern. Anschließend sollten diese in einer breit angelegten
Untersuchung quantitativ überprüft werden.
202
Literaturverzeichnis
Adler /Interdepartmental interdependence/
Paul S. Adler: Interdepartmental interdependence and coordination: The Case of the
design; manufacturing interface. In: Organization Science. Nr. 2, 1995, S. 147-167.
Ahuja, Galletta, Carley /Individual centrality/
Manju K. Ahuja, Dennis F. Galletta, Kathleen M. Carley: Individual centrality and
performance in virtual R&D groups: an empirical study. In: Management Science. Nr.
1, 2003, S. 21-38.
Alavi, Carlson /Review/
Maryam Alavi, Patricia Carlson: A review of MIS research and disciplinary development. In: Journal of Management Information Systems. Nr. 4, 1992, S. 45-62.
Allport /General/
Gordon W. Allport: The general and unique in psychological science. In: Journal of
Personality. 1962, Nr. 3, S. 405-422.
Allweyer, Besthorn, Schaaf /IT-Outsourcing/
Thomas Allweyer, Thomas Besthorn, Jürgen Schaaf: IT-Outsourcing. Zwischen Hungerkur und Nouvelle Cuisine, Deutsche Bank Research. Frankfurt am Main,
06.04.2004.
Alner /Effects/
Marie Alner: The effects of outsourcing on information security. In: Information Systems Security. Nr. 2, 2001, S. 35-43.
Alter /Work system method/
Steven Alter: The work system method for understanding information systems and
information system research. In: Communications of the Association for Information
Systems (CAIS). Vol. 9, Artikel 6, 2002, S. 90-104.
203
Alter, Sherer /Model of IS risk/
Steven Alter, Susan A. Sherer: A general but readliy adaptable model of information
system risk. In: Communications of the Association for Information Systems (CAIS).
2004, Vol. 14, Artikel 1, S. 1-28.
Aman, Nicholson /Knowledge transfer/
Aini Aman, Brain Nicholson: Managing knowledge transfer process in offshore software development: Overcoming the complexity of tacit knowledge. Working Paper,
Manchester, UK, o. J.
Amberg, Wiener /Erfolgsfaktoren/
Michael
Amberg,
Martin
Softwareentwicklungsprojekte
Wiener:
-
Kritische
Eine
Erfolgsfaktoren
explorative
Studie.
für
Offshore-
www.wi3.uni-
erlangen.de/OSE/Studie_KritischeErfolgsfaktorenOffshoreSoftwareentwicklungs
projekte_Amberg+Wiener.pdf, Abruf am 13.02.2006.
Amoribieta u. a. /Programmers/
Inigo Amoribieta, Kaushik Bhaumik, Kishore Kanakamedala, Ajay D. Parkhe: Programmers abroad - A primer on offshore software development. In: McKinsey Quarterly. Nr. 2, 2001, S. 128-139.
Ang, Straub /Production/
Soon Ang, Detmar W. Straub: Production and transaction economies and IS outsourcing
- a study of the US bank industry. In: MIS Quarterly. Nr. 4, 1998, S. 535-552.
Applegate, Montealegre /Eastman Kodak/
Lynda M. Applegate, Ramiro Montealegre: Eastman Kodak Co. managing information
systems through strategic alliances. In: Harvard Business School Case, 9-192-030.
Boston, Massachusetts 1991.
204
Apte u. a. /Outsourcing practices/
Uday M Apte, Marion Sobol, Sho Hanaoka, Tatsumi Shimada, Timo Saarinen, Timo
Salmela, P.J. Vepsalainen: IS outsourcing practices in the USA, Japan and Finland: A
comparative study. In: Journal of Information Technology. Nr. 12, 1997, S. 289-304.
Armstrong, Cole /Managing distances/
David J. Armstrong, Paul Cole: Managing distances and differences in geographically
distributed work groups. In: Pamela Hinds, Sara Kieser (Hrsg.): Distributed Work.
Cambridge, London 2002, S. 167-189.
Aron, Clemons, Reddi /Understanding/
Ravi Aron, Eric K. Clemons, Sashi Reddi: Just right outsourcing: Understanding and
managing the risk. In: Proceedings of the 38th Hawaii International Conference on
System Sciences. 2005, S. 1-10.
Arora, Gambardella /Globalization/
Ashish Arora, Alfonso Gambardella: The globalization of the software industry. Perspectives and opportunities for developed and developing countries. In: NBER Innovation Policy & the Economy. Nr. 1, 2005, S. 1-32.
Aubert u. a. /British Petroleum/
Benoit A. Aubert, Michel Patry, Suzanne Rivard, Heather Smith: IT outsourcing risk
management at British Petroleum. In: Proceedings of the 34th Hawaii International
Conference on System Sciences. 2001, S. 1-10.
Aubert, Patry, Rivard /Assessing/
Benoit A. Aubert, Michel Patry, Suzanne Rivard: Assessing the risk of IT outsourcing.
In: Proceedings of the 31st Hawaii International Conference on System Sciences. Hawaii 1998, S. 685-693.
Aubert, Patry, Rivard /Tale/
Benoit A. Aubert, Michel Patry, Suzanne Rivard: A tale of two outsourcing contracts.
An agency-theoretical perspective. In: Wirtschaftsinformatik. Nr. 2, 2003, S. 181-190.
205
Balaji, Ahuja /Team-Level/
S. Balaji, Manju K. Ahuja: Critical team-level success factors of offshore outsourced
projects: A knowledge integration perspective. In: Proceedings of the 38th Hawaii
International Conference on System Sciences. 2005, S. 1-8.
Baldwin, Irani, Love /Outsourcing/
Lynne P. Baldwin, Zahir Irani, Peter E.D. Love: Outsourcing information systems drawing lessons from a banking case study. In: European Journal of Information Systems. Nr. 1, 2001, S. 15-24.
Balzert /Software-Entwicklung/
Helmut Balzert: Lehrbuch der Software-Technik. Software-Entwicklung. Heidelberg,
Berlin, Oxford 1996.
Barr, Tessler /Software talent shortage/
Avron Barr, Shirley Tessler: How will the software talent shortage end? In: American
Programmer. Nr. 1, 1998, S. 2-7.
Barthelemy /Hidden cost/
Jerome Barthelemy: The hidden costs of IT outsourcing. In: MIT Sloan Management
Review. Nr. 3, 2001, S. 60-69.
Battin u. a. /Global software development/
Robert D. Battin, Ron Crocker, Joe Kreidler, K. Subramanian: Leveraging resources in
global software development. In: IEEE Software. Nr. 2, 2001, S. 70-77.
Ben, Claus /Offshoring/
Esther Ruiz Ben, Regina Claus: Offshoring in der deutschen IT Branche. In: Informatik
Spektrum. Nr. 2, 2005, S. 34-39.
Benamati, Rajkumar /Application development/
John Benamati, T.M. Rajkumar: The application development outsourcing decision: An
application of the technology acceptance model. In: Journal of Computer Information
Systems. Nr. 4, 2002, S. 35-44.
206
Benbasat, Goldstein, Mead /Case research strategy/
Izak Benbasat, David K. Goldstein, Melissa Mead: The case research strategy in studies
of information systems. In: MIS Quarterly. Nr. 3, 1987, S. 369-386.
Besanko u. a. /Economics/
David Besanko, David Dranove, Mark Shanley, Scott Schaefer: Economics of strategy.
3. Aufl., New York, Paris 2004.
Bharati /Indias IT services industry/
Pratyush Bharati: Indias IT services industry: A comparative analysis. In: IEEE Computer. Nr. 1, 2005, S. 71-75.
BITKOM /IT-Outsourcing/
BITKOM:
Positionspapier
IT-Outsourcing.
Veröffentlicht
12.2004,
www.bitkom.org/files/documents/BITKOM_Positionspapier_IT-Outsourcing.pdf,
Abruf am 11.12.2006.
BITKOM /Leitfaden BPO/
BITKOM: Leitfaden Business Process Outsourcing. Veröffentlicht am 20.09.2005,
www.bitkom.de/files/documents/BITKOM_Leitfaden_BPO_Stand_20.09.05.pdf, Abruf
am 11.12.2006.
BITKOM /Leitfaden Offshoring/
BITKOM: Leitfaden Offshoring. Veröffentlicht am 31.01.2005,
www.bitkom.de/files/documents/BITKOM_Leitfaden_Offshoring_31.01.2005.pdf,
Abruf am 11.12.2006.
BITKOM /Wir/
BITKOM: Wir über uns. www.bitkom.org/de/wir_ueber_uns/2843.aspx, Abruf am
17.01.2006.
Boehm /Software engineering economics/
Barry W. Boehm: Software engineering economics. Englewood Cliffs 1981.
207
Boehm /Software risk management/
Barry W. Boehm Boehm: Software risk management: Principles and practices. In: IEEE
software. Nr. 1, 1991, S. 32-41.
Boland, Tenkasi /Communities of knowing/
Richard J. Boland, Ramkrishnan V. Tenkasi: Perspective making and perspective taking
in communities of knowing. In: Organization Science. Nr. 4, 1995, S. 350-372.
Booth, Colomb, Williams /Craft/
Wayne C. Booth, Gregory G. Colomb, Joseph M. Williams: The craft of research. 2.
Aufl., Chicago, London 2003.
Borgatti, Everett, Freeman /Ucinet/
S.P. Borgatti, M.G. Everett, L.C. Freeman: Ucinet for Windows: Software for social
network analysis. o. J.
Borgatti, Molina /Ethical guidelines/
Stephen P. Borgatti, José-Luis Molina: Toward ethical guidelines for network research
in organizations. In: Social Networks. Nr. 2, 2005, S. 107-117.
Bradach, Eccles /Price/
Jeffrey L. Bradach, Robert G. Eccles: Price, authority, and trust: From ideal types to
plural forms. In: Annual Review of Sociology. 1989, S. 97-118.
Bremmer /Managing risk/
Ian Bremmer: Managing risk in an unstable world. In: Harvard Business Manager. Nr.
6, 2005, S. 51-60.
Bräutigam /IT-Outsourcing/
Peter Bräutigam: IT-Outsourcing. 1. Aufl., Berlin 2004.
Capers /Euro/
Jones Capers: The Euro, Y2K, and US software labor shortage. In: IEEE Software. Nr.
3, 1999, S. 55-61.
208
Carmel /Global software teams/
Erran Carmel: Global software teams. Collaborating across borders and time zones.
Upper Saddle River 1999.
Carmel, Agarwal /Global software development/
Erran Carmel, Ritu Agarwal: Tactical approaches for alleviating distance in global
software development. In: IEEE Software. Nr. 2, 2001, S. 22-29.
Carmel, Agarwal /Maturation of offshore sourcing/
Erran Carmel, Ritu Agarwal: The Maturation of offshore sourcing of information technology work. In: MIS Quarterly Executive. Nr. 2, 2002, S. 65-77.
Chandrasekaran, Ensing /ODC/
N. Chandrasekaran, Geert Ensing: ODC: A global IT services delivery model. In: Communications of the ACM. Nr. 5, 2004, S. 47-49.
Chen, Hirschheim /Examination/
WenShin Chen, Rudy Hirschheim: A paradigmatic and methodological examination of
information systems research from 1991 to 2001. In: Information Systems Journal. Nr.
3, 2004, S. 197-235.
Chen, Nath /Nomadic culture/
Leida Chen, Ravi Nath: Nomadic culture. In: Information Systems Management. Nr. 3,
2005, S. 56-64.
Chidambaram /Relational development/
Laku Chidambaram: Relational development in computer-supported groups. In: MIS
Quarterly. Nr. 2, 1996, S. 143-165.
Choudhury, Sabherwal /Control/
Vivek Choudhury, Rajiv Sabherwal: Portfolios of control in outsourced software development projects. In: Information Systems Research. Nr. 3, 2003, S. 291-314.
209
Chudoba u. a. /Virtuality/
Katherine M. Chudoba, Eleanor Wynn, Mei Lu, Mary B. Watson-Manheim: How virtual are we? Measuring virtuality and understanding its impact in a global organization.
In: Information Systems Journal. Nr. 4, 2005, S. 279-306.
Clark Jr., Zmud, McCray /Nature/
Thomas D. Clark Jr., Robert W. Zmud, Gordon E. McCray: The outsourcing of information services - transforming the nature of business in the information industry. In:
Journal of Information Technology. Nr. 4, 1995, S. 221-237.
Clemons, Hitt /Poaching/
Eric K. Clemons, Lorin M. Hitt: Poaching and the misappropriation of information:
Transaction risks of information exchange. In: Proceedings of the 37th Hawaii International Conference on System Sciences. 2004, S. 1-10.
Clott /Perspectives/
Christopher B. Clott: Perspectives on global outsourcing and the changing nature of
work. In: Business and society Review. Nr. 2, 2004, S. 153-170.
Cramton /Mutual knowledge problem/
Catherine Durnell Cramton: The mutual knowledge problem and its consequences for
dispersed collaboration. In: Organization Science. Nr. 3, 2001, S. 346-371.
Cross, Nohria, Parker /Informal networks/
Rob Cross, Nitin Nohria, Andrew Parker: Six myths About informal networks - and
how to overcome them. In: MIT Sloan Management Review. Nr. 3, 2002, S. 67-75.
Cullen, Willcocks /Intelligent/
Sara Cullen, Leslie P. Willcocks: Intelligent IT outsourcing: Eight building blocks to
success. Oxford, Burlington 2003.
Curtis, Krasner, Iscoe /Software design process/
Bill Curtis, Herb Krasner, Neil Iscoe: A field study of the software design process for
large systems. In: Communications of the ACM. Nr. 11, 1988, S. 1268-1287.
210
Cutter Consortium /Risk management/
Cutter
Consortium:
What
exactly
is
risk
management?
www.cutter.com/press/020606.html, Abruf am 27.05.2005.
Czinkota, Ronkainen, Moffett /International business/
Michael R. Czinkota, Ilkka A. Ronkainen, Michael H. Moffett: International business.
7. Aufl., Mason, Ohio 2005.
Daft, Lengel /Media richness/
Richard L. Daft, Robert H. Lengel: Organizational information requirements, media
richness and structural design. In: Management Science. Nr. 5, 1986, S. 554-571.
Daft, Lengel /Richness/
Richard L. Daft, Robert H. Lengel: Information richness: A new approach to managerial
information processing and organizational design. In: Barry Staw, Larry L. Cummings
(Hrsg.): Research in Organizational Behavior. Grennwich 1984, S. 191-233.
Daft, Lengel, Trevino /Media selection/
Richard L. Daft, Robert H. Lengel, Linda Klebe Trevino: Message equivocality, media
selection, and manager performance: Implications for information systems. In: MIS
Quarterly. September, Nr. 3, 1987, S. 355-366.
Damian, Zowghi /Impact/
Daniela E. Damian, Didar Zowghi: The impact of stakeholders’ geographical distribution on managing requirements in a multi-site organization. In: Proceedings of the IEEE
Joint International Conference on Requirements Engineering. 2002, S. 1-10.
Darke, Shanks, Broadbent /Case study/
Peta Darke, Graeme Shanks, Marianne Broadbent: Successfully completing case study
research. combining rigour, relevance and pragmatism. In: Information Systems Journal. Nr. 4, 1998, S. 273-289.
211
Dedene, De Vreese /Realities/
Guido Dedene, Jean-Pierre De Vreese: Realities of off-shore reengineering. In: IEEE
Software. Nr. 1, 1995, S. 35-45.
Delmonte, McCarthy /Offshore/
Anthony J. Delmonte, Richard V. McCarthy: Offshore software development: Is the
benefit worth the risk? In: Ninth Americas Conference on Information Systems. 2003,
S. 1607-1613.
Deloitte & Touche /Outsourcing/
Deloitte & Touche: Outsourcing und Offshoring mit indischen Unternehmen. Die ITWelt im Wandel. München 2003.
Deloitte /Calling/
Deloitte: Calling a Change in the outsourcing market. Veröffentlicht 04.2005,
www.deloitte.com/dtt/cda/doc/content/us_outsourcing_callingachange.pdf, Abruf am
14.11.2005.
DeLone, McLean /Update/
William H. DeLone, Ephraim R. McLean: The DeLone and McLean model of information system success: A ten-year update. In: Journal of Management Information Systems. Nr. 4, 2003, S. 9-30.
DeLone u. a. /Boundaries/
William DeLone, J. Alberto Espinosa, Gwanhoo Lee, Erran Carmel: Bridging gobal
boundaries for IS project success. In: Proceedings of the 38th Hawaii International
Conference on System Sciences. 2005, S. 1-10.
Deutsche Bank Research /Outsourcing/
Deutsche Bank Research: Outsourcing nach Indien: der Tiger auf dem Sprung. In:
Aktuelle Themen, Indien Spezial. Nr. 335, 2005, S. 1-15.
212
Dibbern /Sourcing/
Jens Dibbern: The sourcing of application software services. Empirical evidence of
cultural, industry and functional differences. Heidelberg 2004.
Dibbern u. a. /Survey/
Jens Dibbern, Tim Goles, Rody Hirschheim, Bandula Jayatilaka: Information systems
outsourcing: A survey and analysis of the literature. In: The DATA BASE for Advances
in Information Systems. Nr. 4, 2004, S. 6-102.
Dibbern, Güttler, Heinzl /Theorie/
Jens Dibbern, Wolfgang Güttler, Armin Heinzl: Die Theorie der Unternehmung als
Erklärungsansatz für das selektive Outsourcing der Informationsverarbeitung. Entwicklung eines theoretischen Bezugsrahmens. In: Zeitschrift für Betriebswirtschaft. Nr. 6,
2001, S. 675-700.
Dibbern, Heinzl, Leibbrandt /Interpretation/
Silvia Leibbrandt, Armin Heinzl, Jens Dibbern: Interpretation des Sourcings der Informationsverarbeitung - Hintergründe und Grenzen ökonomischer Einflussgrößen. In:
Wirtschaftsinformatik. Nr. 5, 2003, S. 533-540.
DIN /DIN 66272/
DIN (Hrsg.): DIN 66272: Informationstechnik - Bewerten von Softwareprodukten Qualitätsmerkmale und Leitfaden zu ihrer Verwendung. Berlin 1994.
Dué /Real costs/
Richard T. Dué: The real costs of outsourcing. In: Mehdi Khosrowpour (Hrsg.): Managing Information Technology investments with outsourcing. 1. Aufl., Harrisburg (USA),
London 1995, S. 96-103.
Earl /Risks/
Michael J. Earl: The risks of outsourcing IT. In: Sloan Management Review. Nr. 3,
1996, S. 26-33.
213
Eisenführ, Weber /Entscheiden/
Franz Eisenführ, Martin Weber: Rationales Entscheiden. 4. Aufl., Berlin, Heidelberg,
New York 2003.
Eisenhardt /Agency theory/
Kathleen M. Eisenhardt: Agency theory: An assesment and review. In: Academy of
Management Review. Nr. 1, 1989, S. 57-74.
Eisenhardt /Building theories/
Kathleen M. Eisenhardt: Building theories from case study research. In: Academy of
Management Review. Nr. 4, 1989, S. 532-550.
Eisenhardt /Control approaches/
Kathleen M. Eisenhardt: Control: Organizational and economic approaches. In: Management Science. Nr. 2, 1985, S. 134-149.
EITO /2005/
EITO: European Information Technology Observatory (EITO) 2005 - ICT markets incl.
UK. Brüssel, 03.2005.
Erez, Kanfer /Role/
Miriam Erez, Frederick H. Kanfer: Role. In: Academy of Management Review. Nr. 3,
1983, S. 454-563.
Espinosa u. a. /Team boundary/
J. Alberto Espinosa, Jonathon N. Cummings, Jeanne M. Wilson, Brandi M. Pearce:
Team boundary issues across multiple global firms. In: Journal of Management Information Systems. Nr. 4, 2003, S. 157-190.
Espinosa, Carmel /Dyad model/
J. Alberto Espinosa, Erran Carmel: The effect of time seperation on coordination costs
in global software teams: A dyad model. In: Proceedings of the 37th Hawaii International Conference on System Sciences. 2004, S. 1-10.
214
Espinosa, Carmel /Impact/
J. Alberto Espinosa, Erran Carmel: The impact of time separation on coordination in
gloabal software team: A conceptual foundation. In: Software Process - Improvement
and Practice. Nr. 8, 2003, S. 249-266.
Faraj, Sproull /Coordinating expertise/
Samer Faraj, Lee Sproull: Coordinating expertise in software development teams. In:
Management Science. Nr. 12, 2000, S. 1554-1568.
Fayol /Administration/
Henry Fayol: Administration industrielle et générale. Paris 1916.
Fitzgerald, Wilcocks /Contracts and partnerships/
Guy Fitzgerald, Leslie Wilcocks: Contracts and partnerships in the outsourcing of IT.
In: Janice I. DeGross, Sid L. Huff, Malcolm C. Munro (Hrsg.): International Conference
on Information Systems. Vancouver, 1994, S. 91-98.
Franz, Robey /Investigation/
Charles R. Franz, Daniel Robey: An investigation of user-led system design: Rational
and political perspectives. In: Communications of the ACM. Nr. 12, 1984, S. 12021217.
Frese /Grundlagen/
Erich Frese: Grundlagen der Organisation. Konzept - Prinzipien - Strukturen. 8. Aufl.,
Wiesbaden 2000.
Fulk /Social construction/
Janet Fulk: Social construction of communication technology. In: Academy of Management Journal. Nr. 5, 1993, S. 921-950.
Gallivan, Oh /Analyzing/
Michael J. Gallivan, Wonseok Oh: Analyzing IT outsourcing relationships as alliances
among multiple clients and vendors. In: Proceedings of the 32nd Hawaii International
Conference on System Sciences. 1999, S. 1-15.
215
George u. a. /Collaborative group work/
Joey F. George, George K. Easton, J.F. Nunamaker Jr., Gregory B. Northcraft: A study
of collaborative group work with and without computer-based support. In: Information
Systems Research. Nr. 4, 1990, S. 394-415.
Global Insight /Impact/
Global Insight: Executive summary. The comprehensive impact of offshore IT software
and services outsourcing on the U.S. economy and the IT industry. Veröffentlicht
03.2004, www.globalinsight.com/publicDownload/genericContent/03-30-04_
execsum.pdf, Abruf am 17.03.2005.
Gonzalez, Gasco, Llopis /Spanish firms/
Reyes Gonzalez, Jose Gasco, Juan Llopis: Information systems outsourcing reasons in
the largest Spanish firms. In: International Journal of Information Management. Nr. 2,
2005, S. 117-136.
Gopal u. a. /Contracts/
Anandasivam Gopal, Konduru Sivaramakrishnan, M. S. Krishnan, Tridas Mukhopadhyay: Contracts in offshore software development: An empirical analysis. In:
Management Science. Nr. 12, 2003, S. 1671-1683.
Gopalakrishnan, Kochikar, Yegneshwar /Infosys experience/
S. Gopalakrishnan, V. P. Kochikar, S. Yegneshwar: The offshore model for software
development: The Infosys experience. In: Proceedings of the 1996 ACM
SIGCPR/SIGMIS conference on Computer personnel research. 1996, S. 392-393.
Grinter, Herbsleb, Perry /Geography/
Rebecca E. Grinter, James D. Herbsleb, Dewayne E. Perry: The geography of coordination: Dealing with distance in R&D work. In: Proceedings of GROUP'99, International
Conference on Supporting Group Work, 14.-17. November 1999. Phoenix, 1999, S.
306-315.
216
Grover, Cheon, Teng /Outsourcing/
Varun Grover, Myun Joong Cheon, James T.C. Teng: A descriptive study on the outsourcing of information systems functions. In: Information & Management. Nr. 1, 1994,
S. 33-44.
Gupta, Gupta /Outsourcing/
Uma G. Gupta, Ashok Gupta: Outsourcing the IS function - Is it necessary for your
organization. In: Information Systems Management. Nr. 3, Vol. 9, 1992, S. 44-50.
Hackmann /Worthülsen/
Joachim Hackmann: Worthülsen verunsichern Anwender. In: Computerwoche. Nr. 8,
2005, S. 40.
Hackmann, Prehl /Europäische Anwender/
Joachim Hackmann, Sabine Prehl: Europäische Anwender halten sich beim Outsourcing
zurück. In: Computerwoche. Nr. 29, 2005, S. 35.
Handy /Trust/
Charles Handy: Trust and the virtual organization. In: Harvard Business Review. Nr. 3,
1995, S. 40-50.
Hansen, Neumann /Wirtschaftsinformatik I/
Hans R. Hansen, Gustaf Neumann: Wirtschaftsinformatik I. 8. Aufl., Stuttgart 2002.
Hatch /Offshore 2005/
Phillip J. Hatch: Offshore 2005 research - preliminary findings and conclusions - Vers.
1.2.5. www.ventoro.com/Offshore2005ResearchFindings.pdf, 11.10.2004, Abruf am
12.08.2005.
Hayes, Hunton, Reck /Announcements/
David C. Hayes, James E. Hunton, Jacqueline L. Reck: Information systems outsourcing announcements - investigating the impact on the market value of contract-granting
firms. In: Journal of Information Systems. Nr. 2, 2000, S. 109-125.
217
Haythornthwaite /Social network analysis/
Caroline Haythornthwaite: Social network analysis: An approach and technique for the
study of information exchange. In: LISR. 1996, S. 323-342.
Heeks u. a. /Synching/
Richard Heeks, S. Krishna, Brain Nicholson, Sundeep Sahay: Synching or sinking:
Global software outsourcing realtionships. In: IEEE Software. Nr. 2, 2001, S. 54-60.
Heinzl /Outsourcing/
Armin Heinzl: Outsourcing der Informationsverarbeitung. In: Wirtschaftsstudium
(WISU). Nr. 5, 2003, S. 624-267.
Herbsleb u. a. /Distance/
James D. Herbsleb, Audris Mockus, Thomas A. Finholt, Rebecca E. Grinter: Distance,
dependencies, and delay in a global collaboration. In: Proceedings of the 2000 ACM
conference on Computer supported cooperative work. Philadelphia, 2000, S. 319-328.
Herbsleb, Grinter /Conway's law/
James D. Herbsleb, Rebecca E. Grinter: Architectures, coordination, and distance:
Conway's law and beyond. In: IEEE Software. Nr. 5, 1999, S. 63-70.
Herbsleb, Mockus /Empirical/
James D. Herbsleb, Audris Mockus: An empirical study of speed and communication in
globally distributed software development. In: IEEE Transactions on Software Engineering. Nr. 6, 2003, S. 481-494.
Herbsleb, Moitra /Global software development/
James D. Herbsleb, Deependra Moitra: Global software development. In: IEEE Software. Nr. 2, 2002, S. 16-20.
Herbsleb, Paulish, Bass /Siemens/
James D. Herbsleb, Daniel J. Paulish, Metthew Bass: Global software development at
Siemens - experience from nine projects. In: Proceedings of ICSE, 15.-21.05.2005. St.
Louis, 2005, S. 524-533.
218
Hermes, Schwarz /Outsourcing/
Heinz-Josef Hermes, Gerd Schwarz: Outsourcing: Eine Einführung. In: Heinz-Josef
Hermes, Gerd Schwarz (Hrsg.): Outsourcing. Chancen und Risiken, Erfolgsfaktoren,
rechtliche Umsetzung. Freiburg u. a. 2005, S. 15-37.
Hightower, Sayeed /Effects/
Ross Hightower, Lutfus Sayeed: Effects of communication mode and prediscussion
information distribution characteristics on information exchange groups. In: Information
Systems Research. Nr. 4, 1996, S. 451.
Hofstede /Cultures consequences/
Geert Hofstede: Cultures consequences. Comparing values, behaviors, institutions, and
organization across nations. 2. Aufl., Thousand Oaks, London, New Delhi 2001.
Hofstede /National cultures/
Geert Hofstede: National cultures in four dimensions - A research-based theory of
cultural differences among nations. In: International Studies of Management and Organization. 1-2, 1983, S. 46-74.
Huang, Watson, Wei /E-mail/
W. Huang, R. T. Watson, K. K. Wei: Can a lean e-mail medium be used for rich communication? A psychological perspective. In: European Journal of Information Systems.
Nr. 4, 1998, S. 269-274.
IEEE /IEEE Std 1540-2001/
IEEE (Hrsg.): IEEE Standard for Software Life Cycle Processes - Risk Management.
IEEE Std 1540-2001. New York 2001.
Ilie, Parikh /Process view/
Virginia Ilie, Mihir Parikh: A process view of information systems outsourcing research: Conceptual gaps and future research directions. In: Proceedings of the Tenth
Americas Conference on Information Systems. 2004, S. 3561-3569.
219
Infosys /Annual report 2005-06/
Infosys: Annual report 2005-06.
www.infosys.com/investor/reports/annual/Infosys_AR06.pdf, Abruf am 11.12.2006.
Infosys /Client connectivity/
Infosys:
Client
connectivity
infrastructure.
www.infosys.com/gdm/client-
connectivity.asp, Abruf am 29.09.2006.
Infosys /History/
Infosys: History. www.infosys.com/about/history.asp, Abruf am 11.12.2006.
Inkpen, Currall /Coevolution/
Andrew C. Inkpen, Steven C. Currall: The Coevolution of trust, control, and learning in
joint ventures. In: Organization Science. Nr. 5, 2004, S. 586-599.
ISO, IEC /ISO 9126/
ISO, IEC (Hrsg.): International Standard ISO/IEC 9126: Information technology software product evaluation. Quality characteristics and guidelines for their use. First
edition 15.12.1991. Geneva 1991.
Jalote /CMM/
Pankaj Jalote: CMM in practice - Processes for executing software projects at Infosys.
7. Aufl., India 2004.
Jalote, Jain /24-Hour/
Pankaj Jalote, Gourav Jain: Assigning tasks in a 24-hour software development model.
In: Proceedings of the 11th Asia-Pacific Software Engineering Conference (APSEC 04).
2004, S. 1-7.
Jarvenpaa, Leidner /Communication/
Sirkaa L. Jarvenpaa, Dorothy E. Leidner: Communication and trust in global virtual
teams. In: Organization Science. Nr. 6, 1999, S. 791-815.
220
Jaworski /Theory/
Bernard J. Jaworski: Towards a theory of marketing control: Environmental context,
control types, and consequences. In: Journal of Marketing. Nr. 3, 1988, S. 23-39.
Johansson, Dittrich, Juustila /Boundaries/
C. Johansson, Y. Dittrich, A. Juustila: Software engineering across boundaries: Student
project in distributed collaboration. In: IEEE Transactions on Professional Communikation. Nr. 4, 1999, S. 286-296.
Jones /The Euro/
Capers Jones: The Euro, Y2K, and the US software labor shortage. In: IEEE Software.
Nr. 3, 1999, S. 55-61.
Jurison /Role of risk/
Jaak Jurison: The role of risk and return in information technology outsourcing decisions. In: Journal of Information Technology. Nr. 4, 1995, S. 239-247.
Kadushin /Ethics/
Charles Kadushin: Who benefits from network analysis: ethics of social network research. In: Social Networks. Nr. 2, 2005, S. 139-153.
Karolak /Global software development/
Dale W. Karolak: Global software development. Managing virtual teams and environments. Los Alamitos, u. a. 1998.
Kayworth, Leidner /Global virtual manager/
Timothy R. Kayworth, Dorothy E. Leidner: The global virtual manager: A prescription
for success. In: European Management Journal. Nr. 2, 2000, S. 183-194.
Kelliher /Interpretivism/
Feicity Kelliher: Interpretivism and the pursuit of research legitimisation: An integrated
approach to single case design. In: The Electronic Journal of Business Research Methodology. Nr. 2, 2005, S. 123-132.
221
Kern, Willcocks /relationships in IT outsourcing/
Thomas Kern, Leslie P. Willcocks: relationships in IT outsourcing. In: European Journal of Information Systems. Nr. 1, 2002, S. 3-19.
Khan u. a. /Evaluating/
Naureen Khan, Wendy L. Currie, Vishanth Weerakkidy, Bhavini Desai: Evaluating
offshore IT outsourcing in India: Supplier and customer scenarios. In: Proceedings of
the 36th Hawaii International Conference on System Sciences. 2002, S. 1-10.
Khan, Currie, Weerakkody /Strategies/
Baureen Khan, Wendy L. Currie, Vishanth Weerakkody: Offshore information systems
outsourcing: Strategies and scenarios (research in progress). In: Proceedings of the
Eleventh European Conference on Information Systems, Neapel. 2003, S. 1-8.
Khosrowpour, Subramanian, Gunterman /Organizational benefits/
Mehdi Khosrowpour, Girish H. Subramanian, John Gunterman: Outsourcing: Organizational benefits abd potential problems. In: Mehdi Khosrowpour (Hrsg.): Managing
Information Technology investments with outsourcing. 1. Aufl., Harrisburg, London.
1995, S. 244-268.
Kieser, Kubicek /Organisation/
Alfred Kieser, Herbert Kubicek: Organisation. 3. Aufl., Berlin - New York 1992.
Kirsch /Complex tasks/
Laurie J. Kirsch: The management of complex tasks in organizations: Controlling the
systems development prozess. In: Organization Science. Nr. 1, 1996, S. 1-21.
Kirsch /Portfolios/
Laurie J. Kirsch: Portfolios of control modes and IS project management. In: Information Systems Research. Nr. 3, 1998, S. 215-239.
222
Klein, Myers /Principles/
Heinz K. Klein, Michael D. Myers: A set of principles for conducting and evaluating
interpretive field studies in information systems. In: MIS Quarterly. Nr. 1, 1999, S. 6793.
Klepper, Jones /Outsourcing/
Robert Klepper, O. Wendell Jones: Outsourcing information technology, systems and
services. Upper Saddle River, NJ, USA 1998.
Kliem /Managing the risks/
Ralph Kliem: Managing the risks of offshore IT development projects. In: Information
Systems Management. Nr. 3, Vol. 21, 2004, S. 22-27.
Knox, Savage, Harvey /Social networks/
Hannah Knox, Mike Savage, Penny Harvey: Social networks and the study of relations:
networks as method, metaphor and forms. In: Economy and Society. Nr. 1, 2006, S.
113-140.
Kobitzsch, Rombach, Feldmann /Outsourcing/
Werner Kobitzsch, Dieter Rombach, Raimund L. Feldmann: Outsourcing in India. In:
IEEE Software. Nr. 2, 2001, S. 78-86.
Kohls /Survival kit/
Robert L. Kohls: Survival kit for overseas living. 3. Aufl., Chicago 1979.
Kraut u. a. /Task requirements/
Robert Kraut, Jolene Galegher, Robert Fish, Barbara Chalfonte: Task requirements and
media choice in collaborative writing. In: Human-Computer Interaction. Nr. 4, 1992, S.
375-407.
Kraut, Streeter /Coordination/
Robert E. Kraut, Lynn A. Streeter: Coordination in software development. In: Communications of the ACM. Nr. 3, 1995, S. 69-81.
223
Krepchin /Offshore/
Ira Krepchin: When offshore programming works. In: Datamation. Nr. 14, 1993, S. 5556.
Krishna, Sahay, Walsham /Cross-cultural issues/
S. Krishna, Sundeep Sahay, Geoff Walsham: Managing cross-cultural issues in the
gloabl software outsourcing. In: Communications of the ACM. Nr. 4, 2004, S. 62-66.
Kroeber, Kluckhihn /Culture/
Alfred Kroeber, Clyde Kluckhihn: Culture - A critical review of concepts. 11. Aufl.,
New York 1985.
Kumar, Willcocks /Country/
Kuldeep Kumar, Leslie Willcocks: Offshore outsourcing: A country too far? In: Proceedings of the Fourth European Conference on Information Systems, Lisabon, Portugal. 1996, S. 1309-1326.
Küchler /Grundlagen/
Peter Küchler: Teil 1: Technische und wirtschaftliche Grundlagen. In: Peter Bräutigam
(Hrsg.): IT-Outsourcing. 1. Aufl., Berlin 2004, S. 51-160.
Lacity, Hirschheim /Bandwagon/
Mary C. Lacity, Rudy Hirschheim: The information systems outsourcing bandwagon.
In: Sloan Management Review. Nr. 1, 1993, S. 73-86.
Lacity, Hirschheim /IS Outsourcing/
Mary C. Lacity, Rudy Hirschheim: Information systems outsourcing. Chichester u. a.
1993.
Lacity, Hirschheim /Outsourcing bandwagon/
Marcy C. Lacity, Rudy Hirschheim: Beyond the information systems outsourcing
bandwagon. Chichester u. a. 1995.
224
Lacity, Hirschheim, Willcocks /Realizing/
Mary C. Lacity, Rudy Hirschheim, Leslie P. Willcocks: Realizing outsourcing expectations. Incredible expectations, credible outcomes. In: Information Systems Management. Nr. 4, Vol. 11, 1994, S. 7-18.
Lacity, Willcocks /Empirical investigation/
Mary C. Lacity, Leslie P. Willcocks: An empirical investigation of information technology sourcing - Lessons from Experience. In: MIS Quarterly. Nr. 3, 1998, S. 363-408.
Lacity, Willcocks /Global/
Mary C. Lacity, Leslie P. Willcocks: Global information technology outsourcing. West
Sussex 2001.
Lacity, Willcocks, Feeny /Flexibility/
Marry C. Lacity, Leslie P. Willcocks, David F. Feeny: IT Outsourcing: Maximize flexibility and control. In: Harvard Business Review. Nr. 3, 1995, S. 84-93.
Lang /Organisation/
Carsten Lang: Organisation der Software-Entwicklung. Probleme, Konzepte, Lösungen.
Wiesbaden 2004.
Laux, Liermann /Organisation/
Helmut Laux, Felix Liermann: Grundlagen der Organisation: Die Steuerung von Entscheidungen als Grundproblem der Betriebswirtschaftslehre. 4. Aufl., Berlin u. a. 1997.
Lee /Rich communication/
Allen S. Lee: Electronic mail as a medium for rich communication: An empirical investigation using hermeneutic interpretation. In: MIS Quarterly. Nr. 2, 1994, S. 143-157.
Lee u. a. /Outsourcing/
Jae-Nam Lee, Minh Q. Huynh, Ron C.-W. Kwok, Shih-Ming Pi: IT Outsourcing evolution - past, present, and future. In: Communications of the ACM. Nr. 5, 2003, S. 84-89.
225
Lenke, Lutz, Sprenger /Grundlagen/
Nils Lenke, Hans-Dieter Lutz, Michael Sprenger: Grundlagen sprachlicher Kommunikation. München 1995.
Loh, Venkatraman /Determinants/
Lawrence Loh, N. Venkatraman: Determinants of information technology outsourcing:
A cross-sectional analysis. In: Journal of Management Information Systems. Nr. 1,
1992, S. 7-27.
Lucacs /Outsourcing markets/
M. Lucacs: European outsourcing markets and trends. 1996-2002. No. P04E, International Data Corporation (IDC), 1998.
Luthans, Davis /Idiographic approach/
Fred Luthans, Tim R.V Davis: An idiographic approach to organizational behavior
research: The use of single case experimental designs and direct measures. In: Academy
of Management Review. Nr. 3, 1982, S. 380-391.
Malone, Crowston /Coordination/
Thomas W. Malone, Kevin Crowston: The interdisciplinary study of coordination. In:
ACM Computing Surveys. Nr. 1, 1994, S. 87-119.
Manz, Mossholder, Luthans /Self-control/
Charles C. Manz, Kevin W. Mossholder, Fred Luthans: An integrated perspective of
self-control in organizations. In: Administration and Society. Nr. 1, 1987, S. 3-24.
Manz, Sims /Self-management/
Charles C. Manz, Henry P. Sims: Self-management as a substitute for leader-ship: A
social learning theory perspective. In: Academy of Management Review. Nr. 3, 1980, S.
361-367.
March, Simon /Organizations/
James G. March, Herbert A. Simon: Organizations. New York 1958.
226
Markus /Electronic mail/
M. Lynne Markus: Electronic mail as the medium of managerial choice. In: Organization Science. Nr. 4, 1994, S. 502-527.
Markus /Information richness theory/
M. Lynne Markus: Is information richness theory rich enough? or how managers using
e-mail cope lack of richness. University of California, LA, USA, 1991.
Mayer, Davis, Schoorman /Organizational trust/
Roger C. Mayer, James H. Davis, F. David Schoorman: An integrative model of organizational trust. In: Academy of Management Review. Nr. 3, 1995, S. 709-734.
Maznevski, Chudoba /Bridging space/
Martha L. Maznevski, Katherine M. Chudoba: Bridging space over time: Global virtual
team dynamics and effectiveness. In: Organization Science. Nr. 5, 2000, S. 473-492.
McDonough, Kahn, Griffin /Managing communication/
Edward F. McDonough III, Kenneth B. Kahn, Abbie Griffin: Managing communication
in global product development teams. In: IEEE Transactions on Engineering Management. Nr. 4, 1999, S. 375-386.
McFarlan, Nolan /IT Outsourcing/
F. Warren McFarlan, Richard L. Nolan: How to manage an IT outsourcing alliance. In:
Sloan Management Review. Nr. 2, 1995, S. 9-23.
McKinsey Quarterly /Outsourcing/
McKinsey
Quarterly:
Outsourcing
grows
up.
www.mckinseyquarterly.com/article_page.aspx?ar=1582&L2=5&L3=4&srid=200&gp
=1_, Abruf am 25.08.2005.
McLellan, Marcolin, Beamish /Financial and strategic motivations/
Kerry MCLellan, Barbara L. Marcolin, Paul W. Beamish: Financial and strategic motivations behind IS outsourcing. In: Journal of Information Technology. Nr. 4, 1995, S.
299-321.
227
Mead /Social network analysis/
Stephen P. Mead: Using social network analysis to visualize project teams. In: Project
Management Journal. Nr. 4, 2001, S. 32-38.
Meadows /Development/
C. J. Meadows: Globalizing software development. In: Journal of Global Information
Management. Nr. 1, 1996, S. 5-14.
Mellis /Projektmanagement/
Werner Mellis: Projektmanagement der SW-Entwicklung. Eine umfassende und fundierte Einführung. Wiesbaden 2004.
Mellis, Stelzer /Rätsel/
Werner Mellis, Dirk Stelzer: Das Rätsel des prozeßorientierten Softwarequalitätsmanagements. In: Wirtschaftsinformatik. Nr. 1, 1999, S. 31-39.
Mertens, Groß-Wilde, Wilkens /(Aus-)Wanderung/
Peter Mertens, Jörn Groß-Wilde, Ingrid Wilkens: Die (Aus-)Wanderung der Softwareproduktion - Eine Zwischenbilanz. In: T. Brinda, M. Dal Chin, R. German, G. Görz, G.
Greiner, U. Herzog, F. Hofmann, J. Hornegger, S. Jablonski, K. Leeb, P. Mertens, K.
Meyer-Wegener, H. Müller, H. Niemann, Ch. Pflaum, M. Philippsen, U. Rüde, F.
Saglietti, H. J. Schneider, W. Schröder-Preikschat, M. Stamminger, H. Stoyan, J. Teich,
R. Wanka, H. Wedekind (Hrsg.): Arbeitsberichte des Instituts für Informatik - Friedrich-Alexander-Universität Erlangen Nürnberg, Band 38, Nr. 3. Erlangen 2005, S. 1-64.
Mertens, Knolmayer /Organisation/
Peter Mertens, Gerhard Knolmayer: Organisation der Informationsverarbeitung. Grundlagen - Aufbau - Arbeitsteilung. 3. Aufl., Wiesbaden 1998.
Metagroup /2003 Worldwide/
Metagroup: 2003 worldwide IT benchmarking report. Stamford, 2002.
228
Meyer, Tan /National culture/
Michael D. Meyer, Felix B. Meyer: Beyond models of national culture in information
systems research. In: Journal of Global Information Management. Nr. 1, 2002, S. 24-32.
Mockus, Weiss /Globalization/
Audris Mockus, David M. Weiss: Globalization by chunking: A quantitative approach.
In: IEEE Software. Nr. 2, 2001, S. 30-37.
Moczadlo /Chancen und Risiken/
Regina Moczadlo: Chancen und Risiken des Offshore-Development. Empirische Analyse der Erfahrungen deutscher Unternehmen. Fachtagung ver.de-Landesfachbereich TK /
IT / DV „IT-Offshoring“. Leinfelden-Echterdingen, 12.03.2004, www.verdi-it.de/itfachtagung/r-moczadlo_verdi-fachtagung-it-offshoring-12032004.pdf
,
Abruf
am
28.04.2005.
Moitra /India/
Deependra Moitra: Indias software industry. In: IEEE Software. Nr. 1, 2001, S. 77-80.
Mortensen, Hinds /Conflict/
Mark Mortensen, Pamela J. Hinds: Conflict and shared identity in geographically distributed teams. In: The international Journal of Conflict Management. Nr. 3, 2001, S.
212-238.
Murphy, Chen /Worldwide outsourcing/
S. Ker Murphy, S. Chen: U.S. and worldwide outsourcing markets and trends. 19982003. Nr. 19322, International Data Corporation (IDC), 1999.
Murty /Impact/
Subramanyam Murty: The impact of global IT outsourcing on IT providers. In: Communications of the Association for Information Systems (CAIS). Vol. 14, Artikel 25,
2004, S. 543-557.
229
Myers /Qualitative research/
Michael D. Myers: Qualitative research in information systems. In: Association for
Information Systems (AIS), www.qual.auckland.ac.nz, Abruf am 03.0.2006.
Nardi, Whittaker /Face-to-face/
Bonnie A. Nardi, Steve Whittaker: The place of face-to-face communication in distributed work. In: Pamela Hinds, Sara Kieser (Hrsg.): Distrubuted Work. Cambridge, London. 2002, S. 83-110.
NASSCOM /Facts/
NASSCOM: Facts & figures. www.nasscom.org/artdisplay.asp?cat_id=810#6, Abruf
am 14.03.2006.
NASSCOM /Infrastructure/
NASSCOM: Infrastructure. www.nasscom.org/artdisplay.asp?cat_id=34, Abruf am
17.08.2005.
NASSCOM /Knowledge professionals/
NASSCOM: Knowledge professionals. www.nasscom.org/artdisplay.asp?cat_id=303,
Abruf am 13.03.2006.
NASSCOM /Tech parks/
NASSCOM: Infrastructure tech parks. www.nasscom.org/artdisplay.asp?cat_id=547,
Abruf am 17.08.2005.
NASSCOM /Top 20/
NASSCOM: Top 20. www.nasscom.org/artdisplay.asp?art_id=4413#top20, Abruf am
14.03.2006.
Nelson /Strenght/
Reed E. Nelson: The strenght of strong ties: social networks and intergroup conflict in
organizations. In: Academy of Management Journal. Nr. 2, 1989, S. 377-401.
230
Ngwenyama, Lee /Communication richness/
Ojelanki K. Ngwenyama, Allen S. Lee: Communication richness in electronic mail:
Critical social theory and the contextuality of meaning. In: MIS Quarterly. Nr. 2, 1997,
S. 145-167.
Nidumolu /Comparison/
Sarma R. Nidumolu: A comparison of the structural contingency and risk-based perspectives on coordination in software-development projects. In: Journal of Management
Information Systems. Nr. 3, 1996, S. 77-113.
Nidumolu /Performance risk/
Sarma Nidumolu: The effect of coordination and uncertainty on software project performance: Residual performance risk as an intervening variable. In: Information Systems Research. Nr. 3, 1995, S. 191-219.
Nidumolu, Subramani /Managing software development/
Sarma, R. Nidumolu, Mani R. Subramani: The matrix of control: Combining process
and structure approaches to managing software development. In: Journal of Management Information Systems. Nr. 3, 2003, S. 159-196.
o. V. /Brockhaus/
o. V.: Brockhaus die Enzyklopädie. 20. Aufl., Leipzig, Mannheim 1997.
Olson, Olson /Distance/
Gary M. Olson, Judith S. Olson: Distance matters. In: Human-Computer Interaction.
2000, S. 139-178.
Orlikowski /CASE tools/
Wanda J. Orlikowski: CASE tools as organizational change: Investigating incremental
and radical changes in systems development. In: MIS Quarterly. Nr. 3, 1993, S. 309340.
231
Orlikowski, Baroudi /Research approaches/
Wanda J. Orlikowski, Jack J. Baroudi: Studying information technology in organizations: Research approaches and assumptions. In: Information Systems Research. Nr. 1,
1991, S. 1-28.
Ouchi /Conceptual framework/
William G. Ouchi: A conceptual framework for design of organizational control mechanisms. In: Management Science. Nr. 9, 1979, S. 833-848.
Oza u. a. /Critical factors/
Nilay Oza, Tracy Hall, Austen Rainer, Susan Grey: Critical factors in software outsourcing - A pilot study. In: Proceedings of WISER, Californien. 2004, S. 67-71.
Parker /Offshore spending/
Parker: Forrester Research. Mapping europe's offshore spending impact. Cambridge,
07.2004.
Patane, Jurison /Global outscourcing/
Joseph R. Patane, Jaak Jurison: Is global outscourcing diminishing the prospects for
American programmers? In: Journal of Systems Management. Nr. 6, 1994, S. 6-10.
Paul u. a. /Collaborative conflict management style/
Souren Paul, Imad M. Samarah, Priya Seetharaman, Peter P. Jr. Mykytyn: An empirical
investigation of collaborative conflict management style in group support system based global virtual teams. In: Journal of Management Information Systems. Nr. 3,
2004, S. 185-222.
Paulk u. a. /Capability maturity model/
Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber: Capability maturity
model for software. Version 1.1. Technical Report CMU/SEI-93-TR-024. Pittsburgh
1993.
232
Perry, Staudenmayer, Votta /Process improvement/
Dewayne Perry, Nancy Staudenmayer, Lawrence Votta: People, Organizations and
process improvement. In: IEEE Software. Nr. 4, 1994, S. 36-45.
Pettigrew /Field research/
Andrew M. Pettigrewa: Longitudinal field research on change: Theory and practice. In:
Organization Science. Nr. 3, 1990, S. 267-292.
Pfleeger u. a. /Measurement/
Shari L. Pfleeger, Ross Jeffery, Bill Curtis, Barbara Kitchenham: Status report on software measurement. In: IEEE Software. Nr. 2, 1997, S. 33-43.
Porter /Competitive strategy/
Michael Porter: Competitive strategy: Techniques for analyzing industrie and competitors. New York 1980.
Powell /Market/
Walter W. Powell: Neither market nor hierarchy: Network forms of organizations. In:
Organizational Behavior. 1990, S. 295-336.
Powell, Piccoli, Ives /Virtual teams/
Anne Powell, Gabriele Piccoli, Blake Ives: Virtual teams: A review of current literature
and directions for future research. In: The DATABASE for Advances in Information
Systems. Nr. 1, 2004, S. 6-36.
Prehl /Offshoring/
Sabine Prehl: Offshoring: Wo die Inder schwächeln. In: Computerwoche. Nr. 41, 2005,
S. 40.
Prikladnicki, Audy, Evaristo /Lessons learned/
Rafael Prikladnicki, Jorge L. N. Audy, Roberto Evaristo: Global software development
in practice lessons learned. In: Software Process - Improvement and Practice. Nr. 8,
2003, S. 267-281.
233
Rajkumar, Dawley /Problems and issues/
T.M. Rajkumar, Donald L. Dawley: Problems and issues in offshore development of
software. In: Leslie P. Willcocks, Mary C. Lacity (Hrsg.): Strategic Sourcing of Information Systems. Perspectives and Practices. Chichester u. a. 1998, S. 369-386.
Rajkumar, Mani /Offshore/
T.M. Rajkumar, R.V.S. Mani: Offshore software development - The view from Indian
suppliers. In: Information System Management. Nr. 2, Vol. 18, 2001, S. 63-73.
Ramarapu, Parzinger, Lado /Issues/
Narender Ramarapu, Monica J. Parzinger, Augistine A. Lado: Issues in foreign outsourcing. In: Information System Management. Nr. 2, Vol. 13, 1997, S. 27-31.
Rao /Key issues/
Mahu T. Rao: Key issues for global IT sourcing: Country and individual factors. In:
Information Systems Management. Nr. 3, Vol. 21, 2004, S. 16-21.
Ritschard /Zürcher Kantonalbank/
Christoph Ritschard: Zürcher Kantonalbank - Unternehmensprofil, Strategie, finanzielle
Entwicklung. www.zkb.ch/zkb/about/profil/cp-en.pdf, 04.2005, Abruf am 22.04.2006.
Robey, Khoo, Powers /Learning/
Daniel Robey, Huoy M. Khoo, Carolyn Powers: Situated learning in cross-functional
virtual teams. In: IEEE Transactions on Professional Communication. Nr. 1, 2000, S.
51-66.
Rohde /Grenzenlose Arbeit/
Gerhard Rohde: Grenzenlose Arbeit. In: WSI Mitteilungen. Nr. 10, 2003, S. 610-616.
Rost /Political reasons/
Johann Rost: Political reasons for failed software projects. In: IEEE Software. Nr. 6,
2004, S. 102-104.
234
Sabherwal /Evolution/
Rajiv Sabherwal: The evolution of coordination in outsourced software development
projects: A comparison of client and vendor perspectives. In: Information and Organization. Nr. 3, 2003, S. 153-202.
Sabherwal /IS development projects/
Rajiv Sabherwal: The role of trust in outsourced IS development projects. In: Communications of the ACM. Nr. 2, 1999, S. 80-86.
Sarker, Sahay /US-Norwegian/
S. Sarker, S. Sahay: Information systems development by US-Norwegian virtual teams:
Implications of time and space. In: Proceedings of the Thirty-Fifth Annual Hawai International Conference on System Sciences. 2002, S. 18-27.
Schaaf, Weber /Offshoring-Report 2005/
Jürgen Schaaf, Mathias Weber: Offshoring-Report 2005. Ready for take-off. In: Economics - Digitale Ökonome und struktureller Wandel. Nr. 52, 2005, S. 1-24.
Schein /Culture/
Edgar H. Schein: Coming to a new awareness of organizational culture. In: Sloan Management Review. Nr. 2, 1984, S. 3-16.
Schein /Leadership/
Edgar H. Schein: Organizational culture and leadership. 2. Aufl., San Francisco 1992.
Schneider /Lexikon der Informatik/
Hans-Jochen Schneider: Lexikon der Informatik und Datenverarbeitung. 4. Aufl., München u. a. 1998.
Schott /Outsourcing/
Eberhard Schott: Markt und Geschäftsbeziehungen beim Outsourcing. Eine marketingorientierte Analyse für die Informationsverarbeitung. Wiesbaden 1997.
235
Schreyögg /Organisation/
Georg Sychryögg: Organisation. Grundlagen moderner Organisationsgestaltung. Mit
Fallstudien. 3. Aufl., Wiesbaden 1999.
Scott /Social network analysis/
John Scott: Social network analysis. A handbook. 2. Aufl., London, Thousand Oaks,
New Delhi 2000.
SEI /Homepage/
Software Engineering Institute (SEI): Homepage. www.sei.cmu.edu, Abruf am
11.12.2006.
SEI /Interactive maturity profile/
Software Engineering Institute (SEI): Interactive maturity profile - Software CMM.
seir.sei.cmu.edu/seir/domains/CMMspi/Benefit/IMP/frmset.Prof_All_Country.asp?REL
=IMPSEP05&VER=September&YR=2005&COUNTRY=India, Abruf am 03.07.2006.
SEI /SW-CMM September 2005/
Software Engineering Institute (SEI): Process maturity profile - software CMM 2005
mid-year update, Veröffentlicht September 2005, Carmegie Mellon Software Engineering
Institute.
www.sei.cmu.edu/appraisal-program/profile/pdf/SW-
CMM/2005sepSwCMM.pdf, Abruf am 07.03.2006.
Shannon, Weaver /Mathematical theory/
Claude Shannon, Warren Weaver: The mathematical theory of communication. 1. Aufl.,
Urbana 1949.
Shapiro, Varian /Online/
Carl Shapiro, Hal R. Varian: Online zum Erfolg. Strategie für das Internet-Business.
München 1999.
Shapiro, Varian /Information rules/
Carl Shapiro, Hal R. Varian: Information rules: A strategic guide to the network economy. Boston. 1999.
236
Sherer, Alter /Risk factors/
Susan A. Sherer, Steven Alter: Information system risks and risk factors - Are they
mostly about information systems? In: Communications of the Association for Information Systems (CAIS). Vol 14, Artikel 2, 2004, S. 29-64.
Slaughter, Ang /Employment/
Sandra Slaughter, Soon Ang: Employment outsourcing in information systems. In:
Communications of the ACM. Nr. 7, 1996, S. 47-54.
Smith, Mitra, Narasimhan /Outsourcing/
Michael Alan Smith, Sabyasachi Mitra, Sridhar Narasimhan: Information systems
outsourcing - A study of pre-event firm characteristics. In: Journal of Management
Information Systems. Nr. 2, 1998, S. 61-93.
Software Forum e.V. /Mittelstand/
Software Forum e.V.: Offshore IT für den Mittelstand. Leitfaden zur Schaffung und
Sicherung von Arbeitsplätzen durch offshore IT- Entwicklung im Rahmen der Internationalisierung des Mittelstandes in Bayern. Veröffentlicht 07.2002, www.softwareoffensive-bayern.de/pdf/OffshoreIT.pdf, Abruf 17.01.2006.
Stahlknecht, Hasenkamp /Wirtschaftsinformatik/
Peter Stahlknecht, Ulrich Hasenkamp: Einführung in die Wirtschaftsinformatik. 11.
Aufl., Berlin - Heidelberg - New York 2005.
Steinwachs /Information/
Katarina Steinwachs: Information and culture - the impact of national culture on information processes. In: Journal of Information Science. Nr. 3, 1999, S. 193-204.
Stephan /Schlüsselfaktoren/
Rolf Stephan: Kommunikation und Wissenstransfer - Schlüsselfaktiren für erfolgreiche
Offshore-Projekte. In: Heinz-Josef Hermes, Gerd Schwarz (Hrsg.): Outsourcing Chancen und Risiken, Erfolgsfaktoren, rechtssichere Umsetzung. 1. Aufl., Freiburg 2005, S.
213-234.
237
Stork, Richards /Nonrespondents/
Diana Stork, William D. Richards: Nonrespondents in communication network studies.
In: Group & Organization Management. Nr. 2, 1992, S. 193-209.
Straus /Technology/
Susan G. Straus: Technology, group process, and group outcomes: Testing the connections in computer-mediated and face-to-face groups. In: Human-Computer Interaction.
Nr. 3, 1997, S. 227-266.
Straus, McGrath /Medium/
Susan G. Straus, Joseph E. McGrath: Does the medium matter? The interaction of task
type and technology on group performance and member reactions. In: Journal of Applied Psychology. Nr. 1, 1994, S. 87-97.
Swanson, Ramiller /Innovating mindfully/
E. Burton Swanson, Neil C. Ramiller: Innovating mindfully. In: MIS Quarterly. Nr. 4,
2004, S. 553-583.
Szulanski /Internal stickiness/
Gabriel Szulanski: Exploring internal stickiness. Impediments to the transfer of best
practice within the firm. In: Strategic Management Journal. Winter Special Issue, 1996,
S. 27-43.
Tafti /Risks factors/
Mohammed H.A. Tafti: Risks factors. In: Industrial Management & Data Systems. Nr.
5, 2003, S. 549-560.
TCS /Application development/
TCS: Application development.
www.tcs.com/0_service_practices/ADM/adm_application_dev.htm, Abruf am
29.09.2006.
238
Teasley u. a. /Rapid software development/
Stephanie D. Teasley, Lisa A. Covi, Mayuram S. Krishnan, Judy S. Olson: Rapid software development through team collocation. In: IEEE Transactions on Software Engineering. Nr. 7, 2002, S. 671-683.
Theis-Berglmair /Organisationskommunikation/
Anna M. Theis-Berglmair: Organisationskommunikation. Theoretische Grundlagen und
empirische Forschungen. 2. Aufl., Münster, Hamburg, London 2003.
Thompson /Organizations/
James D. Thompson: Organizations in action. Social science bases of administrative
theory. New York 1967.
Tichy, Tushman, Fombrun /Social network analysis/
Noel M. Tichy, Michael L Tushman, Charles Fombrun: Social network analysis for
organizations. In: Academy of Management Review. Nr. 4, 1979, S. 507-519.
Triandis u. a. /Subjective culture/
Harry Triandis, Vasso Vassiliou, George Vassiliou, Yasumasa Tanaka, A. V. Shanmugam: The analysis of subjective culture. New York 1972.
Trittmann /Wirtschaftlichkeit/
Ralph Trittmann: Wirtschaftlichkeit von Wissenstransfers in der Softwareentwicklung Ein kostenorientiertes Gestaltungskonzept. Aachen 2004.
van Ryssen, Godar /International/
S van Ryssen, Hayes Godar: Going international without going international: Multinational virtual teams. In: Journal of International Management. Nr. 6, 2000, S. 19-60.
Wallmüller /Risikomanagement/
Ernest Wallmüller: Risikomanagement für IT- und Software-Projekte. Ein Leitfaden für
die Umsetzung in der Praxis. München, Wien 2004.
239
Walsham /Interpretive case studies/
Geoff Walsham: Interpretive case studies in IS research: nature and method. In: European Journal of Information Systems. Nr. 1, 1995, S. 74-81.
Walsham /Interpretivism/
Geoff Walsham: The emergence of interpretivism in IS Research. In: Information Systems Research. Nr. 4, 1995, S. 376-394.
Walsham /Organizations/
Geoffrey Walsham: Interpreting information systems in organizations. Chichester 1992.
Walsham /Software production/
Geoff Walsham: Cross-cultural software production and use - A structurational analysis.
In: MIS Quarterly. Nr. 4, 2002, S. 359-380.
Walther /Relational aspects/
Joseph B Walther: Relational aspects of computer-mediated communication: Experimental observations over time. In: Organization Science. Nr. 2, 1995, S. 186-203.
Warkentin, Sayeed, Hightower /Virtual teams/
Merrill E. Warkentin, Lutfus Sayeed, Ross Hightower: Virtual teams. In: Decision
Sciences. Nr. 4, 1997, S. 975-996.
Wasserman, Faust /Social network analysis/
Stanley Wasserman, Katherine Faust: Social network analysis: Methods and applications. 1. Aufl., Cambridge, New York, Melbourne 1994.
Weber /Implications/
Ron Weber: Some implications of the year-2000 era, dot-com era, and offshoreing for
information systems pedagogy. In: MIS Quarterly. Nr. 2, 2004, S. iii-xi.
Wikipedia /Offshore/
Wikipedia: Offshore. de.wikipedia.org/wiki/offshore, Abruf am 26.09.2006.
240
WIPRO /Infrastructure/
WIPRO:
Infrastructure.
www.wipro.com/aboutus/infrastructure.htm,
Abruf
am
29.09.2006.
Yang, Huang /Decision model/
Chyan Yang, Jen-Bor Huang: A decision model for IS outsourcing. In: International
Journal of Information Management. Nr. 3, 2000, S. 225-239.
Yin /Case study crisis/
Robert K. Yin: The case study crisis: Some answers. In: Administrative Science Quarterly. Nr. 1, 1981, S. 58-65.
Yin /Case study/
Robert K. Yin: Case study research. Design and methods. 3. Aufl., Thousand Oaks,
London, New Delhi 2003.
Zack /Communication mode/
Michael H. Zack: Interactivity and communication mode choice in ongoing management groups. In: Information Systems Research. Nr. 3, 1993, S. 207-239.
Zack /Organizational systems/
Michael H. Zack: Researching organizational systems using social network analysis. In:
Proceedings of the 33rd Hawaii International Conference on System Sciences. 2000, S.
1-7.
ZEW /Forschungsergebnisse/
ZEW: Aktuelle Forschungsergebnisse.
www.zew.de/de/topthemen/meldung_show.php?LFDNR=443&KATEGORIE=2, Abruf
am 15.03.2005.
ZKB /Geschäftsjahr 2005/
Zürcher Kantonalbank (ZKB): Wo Kompetenz zählt. Bericht über das Geschäftsjahr
2005 und den Leistungsauftrag der ZKB.
www.zkb.ch/zkb/presse/pdf/geschaeftsbericht_2005.pdf, Abruf 2005-04-24
241
Anhang
Anhang A: Verwendete Zeitschriften und Konferenzen
Relevante Treffer
nach Suche im Titel
(„Offshor*“)
Name der im Literatur-Review
verwendeten Zeitschrift
Relevante neue
Treffer nach
Suche in allen
Feldern
(„Offshor*“)
Academy of Management Journal
Academy of Management Review
Administrative Science Quarterly
Communications of the ACM (CACM)
Communications of the AIS (CAIS)
European Journal of Information Systems
Harvard Business Review
Dedene, De Vreese
/Realities/
IEEE Software
Information Systems Journal (ISJ)
Information Systems Research (ISR)
Journal of Information Technology (JIT)
Journal of Management Information Systems (JMIS)
Journal of Strategic Information Systems (JSIS)
Journal of the ACM (JACM)
Journal of the AIS (JAIS)
Management Science MS
MIS Quarterly
MIS Quarterly Executive (MISQE)
Organization Science
Sloan Management Review MIT
Name der im LiteraturReview verwendeten
Konferenz
European Conference on
Information Systems (ECIS)
Relevante Treffer nach Suche
im Titel („Offshor*“)
Khan, Currie, Weerakkody
/Strategies/;
Kumar, Willcocks /Country/
Balaji, Ahuja /Team-Level/
Hawaii International Conference On System Sciences
(HICSS)
International Construction
Information Society (ICIS)
242
Carmel, Agarwal
/Global software
development/;
Heeks u. a.
/Synching/;
Rost /Political
reasons/
Relevante neue Treffer nach
Suche in allen Feldern
(„Offshor*“)
Aron, Clemons, Reddi
/Understanding/;
Clemons, Hitt /Poaching/;
DeLone u. a. /Boundaries/;
Khan u. a. /Evaluating/
243
Autoren [in den Zeilen ist die zugehörige Seitenzahl angegeben]
29
29f
1317
25
25
672f.
379
17f.
319-328
481-494
30
56
6
75, 77
18, 20
326f.
1609
275
29
1317
379
17
19
1609
68
38
30
25
553
4
4
256
56
240 240
18
105 102
38
28
309
240
626
28
29
1319
25
240
27f.
68
68
81f.
12
531
590
3
25
18
30
56
4
240
37f.
47-49
Kontrollverlust
4
4
1609
68
Geschäftsprozess
Anbieter- und Kundenunternehmen
557
254
240
47-49
29f.
231
3
2
6
104f.
1317
258
38
47-49
18
Demoralisierung von
Mitarbeitern des
Kunden
4
4
44
23
2
6
Lock-In
68
Shirking
3
37
297
Technologie
Beteiligte
Langfristiger Kompetenzverlust beim
Kunden
68
Landesspezifische
Risiken
3
Risiken aufgrund
räumlicher Distanz
297
Risiken aufgrund
kultureller Unterschiede
Risiken aufgrund
räumlicher und
zeitlicher Distanz
Risiken aufgrund
zeitlicher Distanz
297
Poaching
297
3
2
6
37
Strategie
Ausmaß an Vertrauen zwischen den
Beteiligten
Sprachliche Fähigkeiten der Beteiligten
Fachlich, technische
und organisatorische
Kenntnisse der
Beteiligten
3
Risiko
Umwelt
Unvorhergesehene
Schwierigkeiten bei
der Implementierung
Alner /Effects/
Apte u. a. /Outsourcing practices/
Aron, Clemons, Reddi /Understanding/
Aubert u. a. /British Petroleum/
Aubert, Patry, Rivard /Assessing/
Ben, Claus /Offshoring/
Carmel, Agarwal /Global software development/
Carmel, Agarwal /Maturation of offshore sourcing/
Clark Jr., Zmud, McCray /Nature/
Dedene, De Vreese /Realities/
Delmonte, McCarthy /Offshore/
DeLone u. a. /Boundaries/
Earl /Risks/
Espinosa, Carmel /Dyad model/
Grover, Cheon, Teng /Outsourcing/
Gupta, Gupta /Outsourcing/
Hatch /Offshore 2005/
Heinzl /Outsourcing/
Herbsleb u. a. /Distance/
Herbsleb, Mockus /Empirical/
Herbsleb, Moitra /Global software development/
Herbsleb, Paulish, Bass /Siemens/
Inkpen, Currall /Coevolution/
Jurison /Role of risk/
Karolak /Global software development/
Kern, Willcocks /relationships in IT outsourcing/
Khan u. a. /Evaluating/
Khan, Currie, Weerakkody /Strategies/
Khosrowpour, Subramanian, Gunterman /Organizational benefits/
Klepper, Jones /Outsourcing/
Kliem /Managing the risks/
Kraut, Streeter /Coordination/
Krepchin /Offshore/
Kumar, Willcocks /Country/
McDonough, Kahn, Griffin /Managing communication/
McLellan, Marcolin, Beamish /Financial and strategic motivations/
Prikladnicki, Audy, Evaristo /Lessons learned/
Ramarapu, Parzinger, Lado /Issues/
Rost /Political reasons/
Sabherwal /IS development projects/
Tafti /Risks factors/
Teasley u. a. /Rapid software development/
Infrastruktur
Mangelnde Zuverlässigkeit der Telekommunikationsinfrastruktur und der
Stromversorgung
Bereich
Anhang B: Literaturreview über Risiken in Offshore-Entwicklungen
Anhang C: In der Fallstudie verwendete Fragebögen
Anhang C-1: Fragebogen an den Anbieter
Der folgende Fragebogen wurde an den Onsite-Koordinator (AP07) gerichtet. Dabei
wurde jede Frage für alle Projekte Zürich beantwortet. Die Spalte „Element“ war in dem
ausgehändigten Fragebogen nicht vorhanden, sondern diente bei der Erstellung des
Fragebogens der Zuordnung einzelner Fragen zu bestimmten Bereichen. Die Reihenfolge der Fragen entspricht dem ausgehändigten Fragebogen.
Beteiligte; Einfluss
auf andere Systeme/ Projekte
Beteiligte
Element No.
Question
1 What was your position at the different projects?
2 What is your mother tongue?
What is the mother tongue of the customer? (maybe it is necessary to distinguish different roles or departments)
3
For how many years have you worked in this position before? (for each
project)
4
Have you worked together with a German speaking customer before?
5
6
Umwelt
7
8
(E.g. - Handling of conflicts.
- Degree of expressing directly opinions or critic.
- Degree of meeting arrangements (e.g.. dates, fulfilling tasks)
- Ability to make negative statements.
- Awareness of quality)
9
10
Beteiligte
In which cities/places where the involved teams/ persons (offshore, onsite,
customer) located?
What were the normal working hours at each side (Offshore, Onsite, customer)? What are the overlapping working hours?
Did the project face any legal difficulties (e.g. getting Visa, governmental
regulations, intellectual property, copyrights, currency risk)?
If you compare this project with another project (same/ different customer,
same/ different country) are there any cultural differences?
11
12
13
14
15
16
17
Did these differences have any influences to the project? (language differences are also discussed later) - e.g. extra effort, process slow down, make
use of specific methods,...
How high are the skills of the Onsite-coordinator regarding the language of
the customer? (how long has he been in the country of the customer)
How high are the skills of the Backup-Onsite-coordinator regarding the language of the customer? (how long has he been in the country of the customer)
How high are the English skills of the customer's IT department?
How high are the English skills of the customer's business user?
What language skills did have the project members generally? Mother tongue?
Did all team members have the necessary technical skills at the beginning of
the project?
Did the team members attend to any project specific training (e.g. technical,
cultural or related to the business)? (if yes: explain shortly)
Do you think that the client was always honest and frank to you?
244
Infrastruktur
22
Technologie
Geschäftsprozess
Ziele und
Erwartungen
Umwelt
Produkt
Umwelt
Strategie
18
Produkt
Element No.
19
20
21
Question
Which data connection was used between India and the customer (Internet,
VPN, encryption)?
Did you face any difficulties because of internet connection between onsite
and offshore team?
Which infrastructure at this project is shared with other projects (e.g. data
base or file server,…)?
Did you face any difficulties because of power cuts at the offshore team?
Have been the projects of these types? [Re-Engineering, Maintenance, Development]
23 What is the main functionality of the developed software?
24 Who will use the software in the end? (e.g. name department of the customer)
25
What type of contract do you have?
[time & material, capped time & material, fixed price, other]
Did the product have a user interface (screen)? If yes, what was/ were the
26 language(s) of the user interface (screen)?
In which languages were the reports/ outputs created be the software? (if
27 any)
In case of existing code (e.g. at Maintenance or Re-engineering projects):
… are all comments, variable & procedure names of the existing/ old code in
28 English?
… in case of Non-English code comments, variable & procedure names, have
29 this decreased easiness to understand the old system? (compared to English)
30 … what was the language of the existing user interface?
… how high is the complexity of the code/ logic?
31
32 What will be the language of new code comments?
In case of Non-English product components (e.g. user interface, code comments), …
33 … did you face any difficulty because of inexact translations?
… how high where the extra effort for Infosys to handle the affected compo34 nents, compared if all components where in English?
Was the project successful for Infosys?
35
36
37
38
39
40
41
Was the project successful for the customer?
Are these the correct beginning and end dates of the projects? [dd.mm.yyyy]
What is the amount of total elapsed days of each project?
Which stages of each project can be distinguished?
What is the main activity/ output of each stage?
What are the start/ end date of each stage?
What is the effort for each stage (in person hours, for each stage, separated
42 by offshore/ onsite, total)
In general, what was the biggest challenge at each stage? How are these
43 challenges meet?
44
Which hardware/ development tools/ programming language have been used
at Offshore and Onsite for the project (for development and the target system)?
245
Produkt
Element No.
45
Delivered defects = Acceptance defects + Warranty Defects
46
47
48
Type according to PCB definition (type 1-4)
Total Build/ Ratio
Size in FP
49
50
51
Geschäftsprozess
52
53
54
55
56
57
58
59
60
Umwelt, Produkt
Question
In case of a Development or Re-Engineering project:
In case of a Maintenance project:
number of Bug Fixes
Minor/ Major Enhancements
High/ Low Level Language
For each stage and project: Please create a list with all participants and the
site where the person has worked Offshore, Onsite (=customer?) or other.
Who has done what kind of work (role description)?
Who travelled when and why?
How was the hierarchical structure of the project team (Offshore and Onsite)?
Who made decision about which topic/ task? Was the project managed from
India or from the client side? Who reports whom? (Maybe it's easier to make
a small sketch to answer this question)
Which planning documents are created during the project? Which goals are
written down at these planes? Which are shared with the customer?
Which standards and guidelines were used for communication with the customer? (e. g. process guidelines, templates/ forms for communication with the
customer, …)
Which communication mediums are used (between offshore and onsite as
well as to the customer)? (e.g. file transfer (documents), data base entries,
intranet entries, discussion boards, email, fax, phone calls, face-to-face
meeting,…)
Have been the requirements stabile and complete after the requirements
engineering stage? Or have they changed/ enhanced? Why? Did these
changes cause any consequences to the original planes (time, budget)? How
have been the changes/ enhancements communicated?
Will the customer accept any documents, products or meetings in English
language?
What is the language of the
- (weekly) status report, MoM (minutes of meeting) doc., technical doc.
61
62 - proposal, contract
63 - requirements document
64 - design documents
65 - test cases
66 - documentation/ user manual
67 - other?
68 and did you face any problems/ challenges related to these documents?
69 In which language were the documents referenced by the customer?
In case of English documents, were there any problems/ misunderstanding
70 because of customer specific vocabulary? If yes, which?
In case of Non-English documents from the customer, …
71 … how big were the problems because of inexact translations?
… how high were the extra efforts for your team [offshore or onsite] to handle
72 with these documents compared if all documents where in English?
73
If all documents were in English, do you think the duration of the project
would be shorter?
Who was responsible for the linguistic correctness of the Non-English user
74 interface (screen)?
246
Question
If all product components were in English, would be the project duration
75 significantly shorter?
Ziele und Erwartungen
Umwelt
Umwelt, Produkt
Element No.
Regarding to all errors/ problems of the product, how many occurred because
76 of linguistic problems/ misunderstandings?
77 In which language was the first contact to the customer?
78 In which language was the discussion during the proposal stage?
In which language does the IT department reports errors/ incidents to Info79 sys? Which communication medium is used?
In which language does the business user reports errors/ incidents to the
Reporting Application of the customer? Which communication medium is
80 used?
In which language does the business user reports errors/ incidents to Info81 sys? (if he does this directly) Which communication medium is used?
In which language does the customer communicate change request? Which
82 communication medium is used?
Would it be an advantage if the offshore team speaks the same language as
83 the business users? If yes, why?
In case of non-English interaction with the customer, how high is the extra
effort for your team [offshore or onsite] to handle these interaction compared
84 if all interaction where in English?
In case of non-English customer requests, how high is the delay in respond85 ing because of translations?
86 Have it been always easy for you to find the right contact person?
Did the other side response quickly or did you have to wait for some time?
What could be the reasons for the delay (time differences, finding right con87 tact person, unclear request/ answer, missing information, misunderstanding)
Were there any misunderstood requirements (if yes, which, when was this
88 notified, what was the consequence, what could be the reason)
Did the project face technical problems because of special characters of the
89 German language?
Did the project face any other technical difficulties? How did they resolved
90 (interaction with customer?)
Why does the customer use offshore outsourcing for his software development?(- because of Offshore Advantages (e.g.): cost reduction, being technical up-todate, access to IT personal, concentration to core competencies, shorten development
time, process enhancement at the customer, higher product quality- because of Onsite
Disadvantages: maybe there are shortcomings at the customer site)
91
92 Do you think the customer has reached these goals?
What was the aim of Infosys for this project? (e.g. margin, build up relation93 ship, reference customer, efficiency)
94 Do you think Infosys has reached these goals?
95 Are you satisfied with the delivered product/ service quality?
Were all functional and non-functional (like performance) requirements ful96 filled?
Risiken
Were there any risks identified at the beginning of the project which could
97 harm the project goals?
98 In which way are these risks identified (checklist, personal experiences)?
99 What was the reaction to these identified risks?
During the project, were other risks identified, analyzed and/ or priorised?
100 What was the reaction?
101 Did Infosys and the customer discussed jointly about identified risks?
247
Geschäftsprozess
Element No.
102
103
104
105
Question
Could you draw a picture of the picture of the customer organization (End
user, IT Department, IT Management, IT Team members (different roles)) and
where will be the contact points to Infosys?
For the Maintenance project: Could you draw a picture of the workflow of a
change request and an emerging error? (starting at the End user and the way
to Infosys and back) Which persons/ roles are involved; Which tasks are done
(e.g. translation of error reports or other documents)
What are the exact start/ End dates of all four projects for THE CUSTOMER?
Please explain shortly the reporting applications (will the end user fill out a
electonic form, does the system automatically generate a report, is the reporting application used to track customer issues,…?)
248
Anhang C-2: Fragebogen an den Kunden
Der folgende Fragebogen wurde durch den Abteilungsleiter des Kunden (KP01) für alle
drei Projekte Zürich beantwortet. Auch der Projektleiter des Kunden im Projekt Zürich
Re-Engineering hat die Fragen für dieses Projekt beantwortet.
No.
Question
1
What was your position at the project?
Beteiligte
2
For how many other projects have you worked in this position before?
Did the project face any legal difficulties (e.g. getting Visa, governmental
Umwelt
3
regulations, intellectual property, copyrights, currency risk)?
What language skills did have the project members of THE
4
CUSTOMER generally? Mother tongue?
How high are the English skills of the THE CUSTOMER's business
5
user? What is the mother tongue?
How high are the English skills of THE CUSTOMER's IT department?
6
What is the mother tongue?
How high are the skills of the Onsite-coordinator regarding the language
7
of the customer?
How high are the skills of the Backup-Onsite-coordinator regarding the
8
language of the customer?
Did the team members of THE CUSTOMER attend to any project spe9
cific training (e.g. technical or cultural)? (if yes: explain)
Which departments of THE CUSTOMER are involved in the project?
10
(e.g. IT and business unit)
KundenHow many employees have THE CUSTOMER and the IT department of
11
Unternehmen
THE CUSTOMER in total?
If you compare this project with a non-offshore project are there any
cultural differences?
Umwelt
Beteiligte
Element
12
19
Did these differences influenced the project in any case? (language
differences are discussed later)
Did you/ the team members of THE CUSTOMER have experiences with
Offshore projects before this project?
If this is not the first project of it's kind, which experiences influenced
this project? Which potential problems/ doubts have been in mind
before starting the project?
Do you think that people from Infosys was always honest and frank to
you?
Infosys is a CMM level 5 certificated company. Was it neccessary to
change or enhance some (quality) processes at THE CUSTOMER to
match together with Infosys? If yes, what has been changed and do you
think the changes are usefull?
Please describe shortly the normal workflow of a change request or in
case of a maintenance project the workflow of error finding and fixing
(starting at the business user).
Did you face the problem of loosing control? (regarding budget, schedule, quality, delivered functionality)
Has Infosys passed on any confidential Information to a 3rd party?
20
Was the project successful for Infosys? If not, why?
21
Was the project successful for THE CUSTOMER? If not, why?
Beteiligte
13
14
Geschäftsprozess
15
Ziele und
Erwartungen
( - Handling of conflicts.
- Degree of expressing directly opinions or critic.
- Degree of meeting arrangements (eg. dates, fullfilling tasks)
- Ability to make negative statements.
- Awareness of quality)
16
17
18
249
Element
No.
Geschaäfsprozess
22
23
24
25
26
Geschäftsprozess,
Umwelt
27
28
Umwelt
29
30
31
Question
What was the biggest challenge at each stage of the project? How are
these challenges meet? (These stages can be distinguish:
1. Analysis or Requirements Engineering
2. Design
3. Build and unit test
4. Integration Testing
5. System testing
6. Go Live
For each stage: Please create a list with all persons from THE
CUSTOMER beeing involved in the project (Please also give the emailadresses of the persons. This list will be used for the social network
analysis)
For each stage and all involved persons from THE CUSTOMER:
- who has done what kind of work (role)?
- Please mention also if someone has travelled to the offshore location.
How was the hierarchical structure of the project team at THE
CUSTOMER? Who reports to whom? (Maybe it's easier to make a small
sketch to answer the question)
Have been the requirements stabile and complete after the requirements engineering stage? Or have they changed/ enhanced? If yes,
why? Did these changes cause any consequences to the original planes
(time, budget)? How have been the changes/ enhancements communicated?
In which language does the business user of THE CUSTOMER reports
errors/ incidents to the IT department of THE CUSTOMER? Which
communication medium is used?
Would it be an advantage if the offshore team speaks the same language as the business users? If yes, why?
Have it been always easy to find the right contact person?
Did the other side [offshore] response quickly or did you have to wait for
some time? What could be the reasons for the delay (time differences,
finding right contact person, unclear request/ answer, missing information, misunderstanding)
Were there any misunderstood requirements? (if yes, which, when was
this notified, what was the consequence, what could be the reason?)
Did the project face any technical difficulties? How did they resolved?
Why does THE CUSTOMER use offshore outsourcing for his software
development?
32
Ziele und
Erwartungen
33
Example for offshore advantages: cost reduction, being technical up-to-date, access to IT
personal, concentration to core competencies, shorten development time, process
enhancement at the customer, higher product quality
Example for onsite disadvantages: maybe there are shortcomings at the customer site
Strategie
34
Would it be difficult/ cost extensive to change the offshore vendor?
Why?
What was the aim of Infosys for this project? ( e.g. margin, build up
relationship, reference customer)
Do you think Infosys has reached this goals?
Ziele und Erwartungen
Technologie
35
36
37
38
Risiken
39
40
41
42
Are you satisfied with the delivered product/ service quality?
Were all functional and non-functional (like performance) requirements
fulfilled?
Were there any risks identified at the beginning of the project which
could harm the project goals?
In which way are these risks identified (checklist, personal experiences)?
What was the reaction to these identified risks?
During the project, were other risks identified, analyzed and/ or priorised? What was the reaction?
250
Risiken
Element
Ziele und
Erwartungen
No.
Question
Did Infosys and THE CUSTOMER discussed jointly about identified
43
risks?
How does the decision for offshore development influences the current
44
flexibility to react on changing condition or to implement new IT strategies? (lost flexibility)
Did employees of THE CUSTOMER accept the offshore decision with45
out complication, or have they been demoralized and fear to loose their
jobs?
Are THE CUSTOMER thinking to extent the amount of offshore projects
46
in the next 2 years (more projects, larger projects)?
47
Would you recommend Infosys to friends/ colleagues of you?
Der folgende Fragebogen wurde durch den Abteilungsleiter (AP01), den Architekten
(AP03) und dem Projektleiter (AP02) für jedes Projekt Zürich beantwortet.
Element
Nr.
1
2
3
4
5
6
7
Geschäftsprozess (Kontrolle)
8
9
10
11
12
13
14
15
16
17
18
19
Frage
Wurden folgende Vorgaben schriftlich an Infosys zu Projektbeginn gestellt/
vereinbart?
- Funktionale Spezifikation
- Performance-Anforderungen
- Design-Dokumente
- Projektplan
- Projektzeitplans für (Zwischen-) Ergebnisse
Wurde die Einhaltung der oben genannten Vorgaben anhand von Zwischenergebnissen oder gelieferten Produkten durch die ZKB überprüft?
Wurden regelmäßig während des Projekts Softwareversionen ausgeliefert (z.
B. wöchentlich, 14-tägig)?
Hat die THE CUSTOMER selbst Softwaretests im Rahmen des Projekts
durchgeführt?
Hat die THE CUSTOMER selbst zusätzliche Analysen im Rahmen des Projekts durchgeführt?
Hat die THE CUSTOMER während der Entwicklung den von Infosys entwickelten Programm-Code inspiziert (code walk-through)?
Hat die THE CUSTOMER nach der Entwicklung den von Infosys entwickelten
Programm-Code inspiziert (code walk-through)?
Fanden regelmäßige Telefon-Konferenzen mit den indischen Mitarbeitern in
Indien statt? Wenn ja, in welchen Abständen und worüber wurde berichtet?
Gab es regelmäßige Statusberichte über den aktuellen Projektstand? Wenn
ja, in welchen Abständen?
Hat die THE CUSTOMER Infosys bestimmte Entwicklungsmodelle, Programmierrichtlinien oder andere Vorgehensweisen zur Projektumsetzung
vorgeschrieben?
Hat Infosys der THE CUSTOMER bestimmte Entwicklungsmodelle, Programmierrichtlinien oder andere Vorgehensweisen zur Projektumsetzung
vorgeschlagen und wurden diese angewendet?
Bestand die Möglichkeit für die THE CUSTOMER die Leistung einzelner
Mitarbeiter von Infosys zu überprüfen? Wenn ja, wie wurde dies gemacht?
Gab es gemeinsame informelle Treffen (z. B. gemeinsames Mittag- oder
Abendessen) zwischen Mitarbeitern der THE CUSTOMER und Infosys im
Rahmen des Projekts?
Wurden andere als die oben aufgeführten Instrumente von der THE
CUSTOMER eingesetzt, um die Einhaltung der Zeit- und Produktanforderungen zu überwachen? Wenn ja, welche?
Wurde die Einhaltung des Budgets während und nach dem Projekt überwacht?
251
Nr.
Frage
Wie schwierig war es einen Termin für Telefonkonferenzen zwischen der
ZKB
und
Infosys
in
Indien
zu
vereinbaren?
20
(Kontrolle)
Geschäftsprozess
Element
[Skala 1-5 mit 1=sehr leicht; 5=sehr schwer]
Verglichen mit nicht Offshore-Projekten, würden Sie sagen, dass bei diesem
Offshore-Projekt mehr und umfangreichere schriftliche Informationen ausgetauscht wurden (z. B. Emails, Dokumente, Zugriff auf gemeinsame Daten
zum Projektmanagement)?
21
Anhang C-3: Fragebogen an alle Beteiligte im Rahmen der SNA
Der folgende Fragebogen wurde im Rahmen der sozialen Netzwerkanalyse an alle
beteiligten Personen des Anbieters (englisch) und des Kunden (deutsch) verschickt. Sie
wurden aufgefordert den Fragebogen nur in Bezug für einen vorgegeben Zeitraum und
ein vorgegebenes Projekt auszufüllen.
Geschäftsprozess
Element
No.
Question
1 What's your name
2 What was your role at the project?
When (time periode) and at which stages have you worked at the project?
3 (Requirements or Impact Analysis; Design; Build and unit test; Integration and Testing; System
testing; Go Live)
4
5
Beteiligte
6
7
Which tasks have you done at the different project stages?
Please distinguish different stages (Requirements or Impact Analysis, Design, Build
and unit test, Integration and Testing, System testing, Go Live) and describe shortly what
you have done.
What were our normal working hours (please also mention your lunch break)
during this project?
What is your mother tongue?
How good are your German language skills? (scale: 1 perfect to 5 none)
8
In case of communication with offshore: Did offshore response quickly to
your requests or did you have to wait for some time? What could be the
reasons for the delay (time differences, finding right contact person, unclear request/
9
In case of inquire, do you always know the right person to contact and find
this person without multiple contacts?
answer, missing information, misunderstanding)
If you compare this project with another project (different customer, different
country) are there any cultural differences?
Umwelt
10
11
12
13
(E.g. - Handling of conflicts.
- Degree of expressing directly opinions or critic.
- Degree of meeting arrangements (e.g.. dates, fulfilling tasks)
- Ability to make negative statements.
- Awareness of quality)
Did these differences have any influences to the project? - e.g. extra effort,
process slow down, make use of specific methods,...
Did you have worked with documents, source code or computer programs in
a different language then your mother tongue? If yes, which language and
documents? Please explain some difficulties you may face. (e.g. misunderstandings, delays because of translation effort,…)
Did you have communicate with people in a different language then your
mother tongue? If yes, which language and medium (email, phone, face-toface)? Please explain some difficulties you may face. (e.g. misunderstandings, delays because of translation effort,…)
Did you face any difficulties because of the geografical distance between the
customer site and the offshore site? If yes, please explain.
252
Element
No.
Umwelt
14
Question
Beside face-to-face meetings, telephon calls or e-mails which other media
are used to comunicate between offshore and onsite (customer and Onsite
coordinator)? (E.g. planning documents, other documents, internet boards,
task tracking tools, instant messenger,...)
Geschäftsprozess
15. Question
How often did you have had contact to persons related to this project at the time of
your participation and which medium did you have used on average?
Please write your answer into the following table and enter in each cell a value
between 0 and 4, whereas this stands for the following frequencies:
0 = never
1 = less than once a week
2 = once a week
3 = more than once a week
4 = daily
If your contact frequency vary a lot during the project please differentiate between
time periodes or the stages you have worked at this project (Requirements/ Impact
Analysis, Design, Build and Unit Test, Integration Testing, System Testing; Go
Live).
253
Anhang C-4: Erhobene Daten in der SNA
Zürich Maintenance: Kommunikation über alle Medien
Zürich Maintenance: Asynchrone Kommunikation (E-Mail)
254
Zürich Maintenance: Synchrone Kommunikation (face-to-face und Telefon)
Zürich Development: Kommunikation über alle Medien
Zürich Development: Asynchrone Kommunikation (E-Mail)
Zürich Development: Synchrone Kommunikation (face-to-face und Telefon)
255

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project