Viele Wege führen nach Indien

Reorganisation von Arbeit im Zuge

der Internationalisierung der IT-Industrie

Dissertation

zur Erlangung des sozialwissenschaftlichen Doktorgrades

der Sozialwissenschaftlichen Fakultät der
Georg-August-Universität Göttingen

vorgelegt von
Patrick Feuerstein
aus Bremen
Göttingen, 2011
1. Gutachter: Prof. Dr. Volker Wittke
2. Gutachter: Prof. Dr. Martin Baethge
Tag der mündlichen Prüfung: 01.09.2011
Inhaltsverzeichnis

Abbildungsverzeichnis 5

Danke 7

1 Einleitung 9
1.1 Die Debatte über IT-Offshoring: Internationalisierung und Industrialisierung von
IT-Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Fragestellung der Studie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Empirisches Design und methodisches Vorgehen . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Zum Aufbau der Studie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2 Variierende Internationalisierungswege im IT-Bereich 23

2.1 Das „Global Delivery Model“ der IT-Dienstleister . . . . . . . . . . . . . . . . . . . . . 23
2.2 Die Herausbildung verteilter Entwicklungsmodelle bei Software-Herstellern . . . . 27
2.3 Internationalisierungswege und Reorganisationsmodi . . . . . . . . . . . . . . . . . . . 29

3 Indien als Offshore-Standort 33

3.1 Der Boom der indischen IT-Industrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Der indische Markt für IT-Arbeitskräfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Indischer Arbeitsmarkt und Reorganisationsmodi . . . . . . . . . . . . . . . . . . . . . 40

4 Reorganisationsmodi: Varianten betrieblicher Arbeitsprozesskontrolle 45

4.1 IT-Industrialisierung: ein grundlegender Strategiewechsel . . . . . . . . . . . . . . . . . 45
4.2 Managementstrategien zwischen „verantwortlicher Autonomie“ und „direkter Kon-
trolle“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Betriebliche Kontrolle: zur strategischen Gestaltung von Aktivitätsfeldern . . . . . 49
4.3.1 Aufgabenorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.2 Kontrollstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3.3 Kooperationsstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.4 Arbeitsmarktbeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4 Reorganisationsmodi zwischen variierenden Internationalisierungswegen und in-
dischem Arbeitsmarkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5 „It’s like making a car“ – Kontrolle von Arbeit beim indischen IT-Dienstleister Service-
Tec 59
5.1 Das Profil von ServiceTec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2 ServiceTecs globales Geschäftsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3 „Jack of all trades and master of none“ – Betriebliche Kontrollstrategien bei Ser-
viceTec im Entwicklungszentrum in Bangalore . . . . . . . . . . . . . . . . . . . . . . . 68
5.3.1 Aufgabenorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3
 5.3.2 Kontrollstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3.3 Kooperationsbeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.3.4 Arbeitsmarktbeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.4 Zusammenfassung und Bewertung der bei ServiceTec verfolgten Kontrollstrategie 117

6 „Struggle for Ownership“ – Arbeit und Kontrolle bei der deutschen Produktfirma No-
voProd 121
6.1 Das Profil von NovoProd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.2 Global verteilte Entwicklung bei NovoProd . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.3 Betriebliche Kontrollstrategien bei NovoProd im Entwicklungszentrum in Bangalore 133
6.3.1 Aufgabenorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.3.2 Kontrollstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.3.3 Kooperationsbeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
6.3.4 Arbeitsmarktbeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
6.4 Zusammenfassung und Bewertung der bei NovoProd verfolgten Kontrollstrategie 190

7 Zusammenführung und Ausblick: Die heterogene Reorganisation von IT-Arbeit im

Zuge ihrer Internationalisierung 195
7.1 Zwischen „Wissensarbeit“ und „Industrialisierung“ – Zur Entwicklung von IT-
Arbeit im Zuge ihrer Internationalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . 199
7.2 Betriebliche Reorganisationsmodi zwischen globalen Geschäftsmodellen und den
Arbeitsmärkten der Standorte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
7.3 Zur zukünftigen Untersuchung betrieblicher Reorganisationsmodi im Zuge der
Internationalisierung der IT-Industrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

8 Anhang 209
8.1 Interviews bei ServiceTec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
8.2 Interviews bei NovoProd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Literatur 213
Abbildungsverzeichnis

1.1 Reorganisationsmodi unter Einfluß von Verlagerungsvarianten und Arbeitsmarkt

des Offshore-Standortes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Umsatzwachstum der indischen IT-Industrie von 1997 – 2009 . . . . . . . . . . . . . . 34

3.2 Zielregionen der indischen IT-Exporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 Umsatz der indischen IT-Industrie nach Branchensegmenten von 2004 - 2009 . . . . 36
3.4 Entwicklung der Beschäftigtenzahlen der indischen IT-Industrie von 2002 – 2009 . 37

4.1 Managementstrategien, Aktivitätsfelder und strategische Dimensionen . . . . . . . . 50

4.2 Betriebliche Kontrolle zwischen Geschäfts- und Verlagerungsmodellen und indi-
schem Arbeitsmarkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.1 Wasserfall-Modell der Softwareentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . 69

5
Danke
Ich bin froh, jetzt da die Arbeit an meiner Dissertation beendet ist, die Gelegenheit zu haben,
mich bei all jenen zu bedanken, ohne die diese Arbeit nicht möglich gewesen wäre. Ganz praktisch
ist hier zunächst die Deutsche Forschungsgemeinschaft (DFG) zu nennen, die das Forschungspro-
jekt am Soziologischen Forschungsinstitut Göttingen (SOFI), aus dem heraus diese Dissertation
entstanden ist, von 2006 bis 2009 finanzierte.

Gleichermaßen unverzichtbar war die Gesprächsbereitschaft unserer zahlreichen Gesprächs-

partnerInnen: den indischen und deutschen Beschäftigten in den untersuchten Unternehmen, aber
auch der zahlreichen BranchenexpertInnen in Indien und Deutschland. Ihnen sei für ihre Geduld
und Bereitschaft zur Teilnahme an dieser Studie ganz herzlich gedankt.

Ebenso herzlich möchte ich mich auch bei meinen KollegInnen am SOFI bedanken, die diese
Arbeit über die Jahre bei vielen Gelegenheiten diskutiert und kritisch kommentiert haben. Ganz
besonders herauszuheben ist dabei natürlich Volker Wittke – mein Doktorvater – der mich mit sei-
nen anregenden Hinweisen und kritischen Fragen stets unterstützte, sowie meine Kollegin Nicole
Mayer-Ahuja, die mir in der täglichen Projektarbeit den Rücken frei hielt und immer ein offenes
Ohr und gute Ratschläge hatte, wenn ich mich verrannt hatte. Aber auch unseren studentischen
Hilfskräften Jannis Bullian, Nina Hoyler, Anne Hunker-Wormser und Katharina Zöller möchte
ich für ihren Einsatz und ihre Geduld beim Transkribieren unserer Interviews ganz herzlich dan-
ken. Den TeilnehmerInnen des Promotionskolloquiums am SOFI möchte ich für ihre konstrukti-
ve Kritik und die guten Hinweise in den vielen Sitzungen danken, die wir zusammen hatten.

Doch es ist nicht nur die praktische und fachliche Unterstützung, für die ich mich an dieser Stelle
bedanken möchte. Ein ganz besonderer Dank geht auch an all diejenigen, die mich in den letzten
4 Jahren persönlich unterstützt haben. Das sind meine engen Freunde, auf die ich immer zählen
kann, meine Familie, die mir stets eine „Fluchtmöglichkeit“ bietet, um den Kopf frei zu kriegen
und neue Kraft zu sammeln, und schließlich in ganz besonderem Maße meine Frau Lotte, die mir
in einem mehr als turbulenten Lebensabschnitt trotz schwieriger Umstände immer zur Seite stand
und mich immer wieder aufgebaut hat, wenn ich zweifelte oder nicht weiter wusste. Ihnen allen ist
diese Arbeit gewidmet, weil ich ohne sie kaum die Kraft gehabt hätte, diesen Schritt zu machen.

7
8 Danksagung
1 Einleitung

1.1 Die Debatte über IT-Offshoring: Internationalisierung und

Industrialisierung von IT-Arbeit
Betrachtet man die gegenwärtig geführte Debatte über die Verlagerung von hochqualifizierter
Dienstleistungsarbeit in der Software-Entwicklung und den IT-Dienstleistungen aus den kapita-
listischen Zentren in die aufstrebenden Niedriglohnregionen der kapitalistischen Semi-Peripherie,
so scheinen sich seit Ende der 90er Jahre große Veränderungen zuzutragen. Viele Autoren sind
sich einig, dass sich die IT-Industrie in einer „neuen Entwicklungsphase“ befinde (u.a. Boes und
Schwemmle 2004; Kämpf 2008; Aspray, Mayadas und Vardi 2006; Sahay, Nicholson und Krishna
2003; Herbsleb und Moitra 2001; Oecking, Jahnke und Kiehle 2009), einige Autoren sprechen gar
von einer „Revolution“ (Meyer 2006).
Worin diese grossen Veränderungen gesehen werden, fasst eine Karrikatur pointiert zusammen,
die eine Bildersuche bei Google nach dem Terminus „IT-Offshoring“ als einen der ersten Treffer
präsentiert:

Ein Mann liegt weit zurückgelehnt auf seinem Schreibtischstuhl, die Füße auf dem
Tisch, die Arme hinter dem Kopf verschränkt und mit einem entspannten Gesichts-
ausdruck. Das Schildchen auf seinem Schreibtisch weist ihn als „Star-Entwickler“ aus.
Vor seiner Bürotür stehen zwei weitere Männer, im Gegensatz zu dem Mann am
Schreibtisch tragen sie Anzüge und sind so als Vertreter des Managements erkenn-
bar. Die beiden sind in ein kleines Gerangel verwickelt, in dem sie beide versuchen,
als erster das Büro des „Star-Entwicklers“ zu betreten. Der eine Mann fleht dabei den
anderen an: „Bitte, bitte - lass mich derjenige sein, der ihm sagt, dass wir seinen Job
ausgelagert haben!“

Diese kleine Szene zeigt sehr anschaulich die beiden wesentlichen Aspekte, die im Zusammen-
hang mit der Verlagerung von IT-Arbeit gegenwärtig nicht nur in der Öffentlichkeit, sondern auch
von wissenschaftlicher Seite diskutiert werden.
Zunächst spielt die Karikatur auf die konkrete Gefährdung von Arbeitsplätzen in den kapita-
listischen Zentren an, die in der Karikatur in Form der unmittelbar bevorstehenden Kündigung
auftaucht. Dies stellt für den IT-Bereich eine Neuerung dar, da die Arbeitsplätze in dieser Branche
lange als schwer verlagerbar und damit im Vergleich zu Arbeitsplätzen in anderen Industriesek-
toren als gesichert galten. Dementsprechend aufgeregt waren die Reaktionen, als kurz nach der
Jahrtausendwende die ersten Hochrechnungen von Unternehmensberatungen über die Zahl po-
tentieller Jobverlagerungen veröffentlicht wurden.
Für diese Studie steht jedoch ein anderer Aspekt im Zentrum der Aufmerksamkeit, der in der
Karikatur mindestens ebenso deutlich zu Tage tritt. Die Freude der beiden Managementvertreter,
die sich darum reissen, dem „Star-Entwickler“ die Kündigung zu überbringen, verweist nur zu
deutlich auf eine veränderte Machtverteilung zwischen Beschäftigten und Management.

9
10 Einleitung

Die Körperhaltung des Entwicklers verweist (sicherlich übertrieben dargestellt) auf zentrale An-
nahmen über Arbeit im IT-Bereich1 . Die Branche befindet sich gewöhnlich im Fokus von Studien,
die sich in unterschiedlicher Weise mit post-fordistischen Arbeitsformen beschäftigen. Unabhängig
davon, ob eine gesellschaftliche Entwicklung hin zu einer Wissens- oder Informationsgesellschaft
behauptet wird (Willke 1998, Heidenreich 2003, Castells 1996), ob die „New Economy“ mit ih-
rem „New Workplace“ der „Old Economy“ und deren tayloristischen Arbeitsformen gegenüber-
gestellt wird (einen guten Überblick bieten dazu Thompson und McHugh 2002), Untersuchungs-
feld ist immer auch die IT-Industrie, in der die angeblich „neuen Formen“ von Arbeit untersucht
werden. Arbeit in der IT-Industrie komme demnach dem Idealtypus wissensintensiver, kreativer
Tätigkeiten besonders nahe, weshalb ihrer konkreten organisatorischen Gestaltung weitreichen-
de Konsequenzen für die Zukunft der Arbeit beigemessen werden. Durch die spezielle Qualität
von IT-Arbeit, ihren wissensintensiven und kreativen Charakter, entzöge diese sich „traditionel-
len“ Formen der manageriellen Kontrolle, worunter meist Formen bürokratischer oder direkter
Kontrolle (vgl. z.B. Boes und Baukrowitz 2002, auch Smith und McKinlay 2009) verstanden wer-
den. Das Management sei angeblich nicht in der Lage, den Arbeitsprozess ähnlich weitreichend
zu durchdringen und zu modellieren, wie in anderen, weniger kreativen oder wissensintensiven
Bereichen, wie z.B. der Automobilindustrie (vgl. auch Kalkowski und Mickler 2005). Vielmehr
fänden sich bei Tätigkeiten im IT-Bereich Formen der Arbeitskontrolle, die nach Friedman mit
dem Begriff der „verantwortlichen Autonomie“ gefasst werden können (Friedman 1977). Gekenn-
zeichnet seien diese Formen durch den großen Handlungs- und Verantwortungsspielraum, der den
Beschäftigten bei der Verrichtung ihrer Arbeitsaufgaben gelassen wird (Alvesson 2004, Boes und
Baukrowitz 2002, McKinlay und Smith 2009). Statt Bearbeitungsschritte kleinteilig vorzuschrei-
ben, verlasse sich das Management weitgehend darauf, dass die Beschäftigten selbst entscheiden,
wie sie ihre Arbeit effizient erledigen (u.a. Töpsch, Menez und Malanowski 2001, Heidenreich
und Töpsch 1998).
Voraussetzung dieser Art der Arbeitskontrolle ist Eigeninitiative der Beschäftigten, sowie de-
ren Bereitschaft, die Ziele des Managements zu ihren eigenen zu machen. In der Literatur wer-
den unterschiedliche Ansätze diskutiert, mit denen Unternehmen versuchen, dies sicherzustellen,
seien es leistungsbezogene Bewertungssysteme, die das Profit-Interesse des Betriebes mit den Ei-
geninteressen der Beschäftigten verknüpfen (Töpsch, Menez und Malanowski 2001), die Inszenie-
rung von Firmenkultur (Kunda 1992), die Machtverhältnisse verschleiert, oder auch einfach der
bloße Rückgriff auf die ohnehin vorhandene professionelle, schwerpunktmäßig arbeitsinhaltliche
Motivationsstruktur von Hochqualifizierten (Kotthoff 1997). Gemein ist allen Ansätzen, dass es
sich um Formen der „indirekten“ Einflußnahme handelt, die den Beschäftigten im Arbeitspro-
zess hohe Grade der Selbstorganisation und -steuerung lässt (Voß und Pongratz 1998). Entspre-
chend wird das Selbstverständnis der hochqualifizierten IT-Beschäftigten häufig als das des „Kunst-
handwerkers“ charakterisiert, das die integrierten Tätigkeitsprofile, die damit verknüpften großen
Verantwortungs- und Dispositionsspielräume sowie die in diesen Arbeitsformen grundsätzlich er-
forderliche Kreativität und Selbstorganisationsfähigkeit der Beschäftigten reflektiere (Janßen 2005;

1
Das, was in dieser Arbeit im folgenden unter IT-Industrie (gleiches gilt für Begriffe wie IT-Arbeit, etc.) verstanden
wird, bildet gemäß der Definition des Branchenverbandes BITKOM nur einen Unterbereich der Informations-
und Telekommunikationsbranche (ITK) ab. Innerhalb dieser wird vom BITKOM zwischen den beiden Unterbe-
reichen Informationstechnik und Telekommunikation unterschieden. Der Fokus dieser Studie ist auf den Bereich
der Informationstechnik und innerhalb dieses Bereiches auch ausschließlich auf die Segmente Software und IT-
Dienstleistungen gerichtet. Es sind diese Bereiche, die im Fokus der Debatte über IT-Offshoring stehen, wohingegen
die Verlagerung von Arbeit im dritten vom BITKOM definierten Branchensegment, dem der IT-Hardware, bereits
eine lange Geschichte aufweisen kann (vgl. dazu z.B. Lüthje 2006).
Die Debatte über IT-Offshoring 11

Adler 2006). Grundsätzlich werden IT-Beschäftigten aufgrund der spezifischen Kontrollformen

hohe Primärmachtpotenziale (Crozier und Friedberg 1979) zugeschrieben, die sich aus einem er-
heblichen impliziten Wissen über den Arbeitsprozess speisen, Beschäftigte schwer ersetzbar und
damit ihre Jobs sicherer machten.
Glaubt man nun den Studien, die sich mit der Verlagerung von Arbeit im IT-Bereich – dem
IT-Offshoring – beschäftigen, so hat sich diese Situation grundsätzlich gewandelt.
Zum einen straft die im Laufe der 90er Jahre einsetzende Verlagerungsdynamik im Bereich der
IT-Dienstleistungen und der Softwareentwicklung die Annahme Lügen, dass sich hochqualifizier-
te Dienstleistungsarbeit nicht global verlagern lasse. Immerhin erproben auch IT-Unternehmen
zunehmend die neuen Möglichkeiten der Verlagerung2 und entwicklen globale Produktionsmo-
delle, mit der sowohl Lohnkostenunterschiede zwischen Regionen genutzt als auch neue Gruppen
von Arbeitskräften erschlossen werden können. Die Beschäftigten in den Hochlohnregionen der
kapitalistischen Wirtschaft konkurrieren dadurch in zunehmendem Maße auch im Bereich der
hochqualifizierten Tätigkeiten mit Beschäftigten in den aufstrebenden Niedriglohnregionen um
ihre Jobs.
Damit scheint sich zum anderen auch das Machtverhältnis zwischen IT-Beschäftigten und Ma-
nagement im Arbeitsprozess zugunsten des Managements zu verschieben. Der Grund dafür ist die
Veränderung zentraler Strukturmerkmale der Branche, die in der Literatur häufig unter dem Stich-
wort der „IT-Industrialisierung“ gefasst werden (z.B. Walter, Böhmann und Krcmar 2007; Boes,
Kämpf und Trinks 2005; Brenner u. a. 2007). Obwohl je nach Autoren im Detail unterschiedliche
Definitionen dessen kursieren, was unter „Industrialisierung“ gefasst wird, bzw. wie weit in diesem
Bereich auf einen an den „klassischen Industrien“ geprägten Industrialisierungsbegriff rekurriert
werden kann, so kann die folgende von Walter, Böhmann und Krcmar (2007) vorgenommene De-
finition als weitgehend typisch für die Debatte angesehen werden:

„Industrialisierung basiert also auf technischem und organisatorischem Fortschritt, ist

durch Automatisierung der Produktion charakterisiert und führt dadurch zu signifi-
kant sinkenden Kosten für die zentralisierte, spezialisierte und global verteilte Produk-
tion standardisierter Produkte.“ (ebd., S.2; für eine etwas andere Formulierung, siehe
Brenner u. a. 2007)

Dieser Definition folgend, besteht Industrialisierung im wesentlichen in Veränderungen (vor-

wiegend Standardisierungsprozessen) auf den Ebenen der technischen Grundlagen, der Produkte
bzw. Leistungen und der organisatorischen Prozesse im IT-Bereich (vgl. Kämpf 2008, S.65; Boes
2004, S.45 ff; siehe auch Sahay 2003):
Auf der technischen Ebene betrifft dies vor allem das Aufkommen und die Durchsetzung von (of-
fenen) Technologiestandards hinsichtlich Programmiersprachen, Netzwerkprotokollen u.ä. (Boes
und Trinks 2006, S.88). Dies mache es in der Folge möglich, Software unabhängig der verwandten
technologischen Plattform für eine größere Zahl von Systemen zu entwickeln und auch entspre-
chend zu betreuen. Diese Entwicklung bringe somit einen separaten – von der Hardware unabhän-
gigen – Software-Bereich überhaupt erst hervor (ebd.), indem Software unabhängig der eingesetz-
ten Rechnerarchitektur entwickelt und von vielen Nutzern auf unterschiedlichen technologischen
Plattformen eingesetzt werden könne.
2
Die neuen Verlagerungsmöglichkeiten basieren auf einer Reihe von Veränderungen im technischen, wirtschaftlichen
und politischen Bereich, die sich in den letzten Jahren durchgesetzt haben. Für nähere Ausführungen siehe z.B.
Aspray, Mayadas und Vardi 2006, Boes 2004 oder Boes und Schwemmle 2004
12 Einleitung

Die technische Standardisierung ermögliche damit in der Folge auch eine Standardisierung der
angebotenen Produkte und Leistungen. Boes und Trinks (2006) sprechen in diesem Zusammenhang
auch von der Ablösung des Paradigmas der Individualsoftware durch das der Standardsoftware,

„[...] welche stets ein universales Konzept für die Lösung eines verallgemeinerbaren
Problems enthält. Dieses Standardprodukt wird in mehreren Anpassungsschritten in
eine Lösung für den Kunden überführt.“ (S. 89, vgl. auch Walter, Böhmann und Krc-
mar 2007, S. 2f)

Die Durchsetzung des Paradigmas der Standardsoftware habe nach Ansicht der zitierten Au-
toren weitreichende Konsequenzen für die Akteure in der IT-Industrie. Zunächst beinhalte sie
eine Umorientierung der Anwender. Statt benötigte IT-Systeme für individuelle Bedürfnisse ent-
wickeln zu lassen, könnten diese zunehmend auf verfügbare und meist kostengünstigere Standard-
software zurückgreifen. Dies bedeute damit auch eine Umorientierung der Anbieter von Software.
Statt kundenindividuelle Software zu entwickeln, würden Standardprodukte entwickelt, die an-
schließend an eine große Zahl von Kunden vertrieben werden könnten. Schließlich entstehe durch
diese Veränderungen auch ein ganz eigener Markt für IT-Dienstleistungsunternehmen, die sich auf
die Implementierung, Wartung und ggf. kundenspezifische Anpassung der Standardprodukte an
die unterschiedlichen Kundenbedürfnisse spezialisierten. Wenn die Anwender zunehmend Stan-
dardsoftware einsetzen, könnten auch Dienstleistungsunternehmen entsprechend standardisierte
Leistungen und Lösungen anbieten. Dies bilde in der Folge den Hintergrund dafür, dass Anwender-
unternehmen zunehmend vorher intern erbrachte Leistungen auch an externe Dienstleister ausla-
gerten (Outsourcing), da die externen Dienstleister bei der Leistungserbringung durch zunehmen-
de Spezialisierung und Standardisierung auch Skaleneffekte erzielen können und dementsprechend
häufig kostengünstiger seien als die vormals internen IT-Abteilungen der Anwenderunternehmen
(vgl. Taubner 2001, Brenner u. a. 2007).
Die bei den Akteuren der IT-Industrie aufscheinenden Veränderungen im Zuge der Durchset-
zung des Paradigmas der Standardsoftware, führten demnach in der Folge zu einer neuen, die
Branche dominierenden Arbeitsteilung. Hat schon die Trennung von Hard- und Software-Sektor
im Zuge der Standardisierung der technischen Grundlagen zu einer vertikalen Desintegration der
die IT-Industrie lange Zeit dominierenden vertikal integrierten IT-Großunternehmen geführt3 , so
führe die Standardisierung der Produkte und Leistungen zu einer weiteren Differenzierung des
Software-Sektors, mit den Herstellern von standardisierten Software-Produkten auf der einen und
IT-Dienstleistern, welche diese Produkte in eine kundenspezifische Lösung überführen und zudem
im Betrieb betreuen, auf der anderen Seite4 .
Die Standardisierung der technischen Grundlagen, sowie der Produkte und Leistungen biete
schließlich den IT-Unternehmen (sowohl der Standardsoftware-Hersteller als auch den IT-Dienst-
leistern) die Möglichkeit, auch die eigenen Prozesse und Arbeitsabläufe zum Gegenstand von Ratio-
nalisierungs- und Standardisierungsbemühungen zu machen (Boes 2004, S. 48, Kämpf 2008, S.64).
Gemeint ist damit der Versuch, den Erstellungsprozess von Software – aber auch von spezialisier-
ten Dienstleistungen – in einer neuen Art und Weise zu organisieren.
3
Dieser Prozess wird in der Literatur mit dem Begriff des „Wintelismus“ (Borrus und Zysman 1997) bezeichnet. Der
Begriff des Wintelismus beschreibt dabei als Wortzusammensetzung aus den beiden Namen „Windows“ und „Intel“
die angesprochene Trennung von Hard- und Softwaresektor.
4
Eine separate Dienstleistungsfunktion ist in der Form nicht neu in der IT-Industrie, jedoch wurde diese früher ent-
weder als zusätzlicher Service von Großcomputerherstellern geleistet, oder von den Anwenderunternehmen intern
durch eigene Abteilungen erbracht. Neu ist demnach ein separates Marktsegment mit auf diesen Bereich spezialisier-
ten Unternehmen (vgl. Boes 2004).
Die Debatte über IT-Offshoring 13

Die erwartete Richtung der Reorganisationsbemühungen der Unternehmen ziele dabei nach
Lage der Literatur zentral darauf ab, die Arbeitsprozesse z.B. durch standardisierte Tools und Ent-
wicklungsumgebungen, aber auch durch veränderte Managementstrategien, weitreichend zu stan-
dardisieren und zu formalisieren. Sei für die frühere Phase der IT-Industrie – wie ausgeführt –
das Bild des Software-Entwicklers als „Kunsthandwerker“ prägend gewesen, so sollten Entwick-
ler in industrialisierten Arbeitsprozessen eher Spezialisten sein, die mit klaren und robusten Pro-
zessen Software arbeitsteilig entwickeln (Meyer 2006). Dieser Argumentation zufolge würden in
der Folge nicht nur die für Entwickler traditionell hohen Handlungs- und Entscheidungsspiel-
räume durch den gestiegenen Grad der (globalen) Arbeitsteilung eingeschränkt (Boes 2004, auch
Flecker und Meil 2010, Flecker und Holtgrewe 2008), sondern durch die formelle Durchdringung
und Zerlegung der Arbeitsprozesse mithilfe standardisierter Prozessvorgaben würde die Arbeit der
Entwickler auch zunehmend der direkten Kontrolle des Managements unterworfen, da detailliert
definierte und standardisierte Prozesse häufig mit entsprechenden Kennziffern und Evaluations-
metriken hinterlegt seien, die es gestatteten, die Arbeitsleistung der Entwickler gänzlich anders zu
erheben und zu bewerten, als dies vorher der Fall gewesen sei (Kämpf 2008, S.73). Damit wären
auch die impliziten Wissensbestände der Beschäftigten über den Arbeitsprozess gefährdet, die die
traditionell hohen Primärmachtpotenziale der Beschäftigten bisher begründeten und diese schwer
ersetzbar machten.
Die „Industrialisierung“ der Arbeitsabläufe verändere nach Ansicht der genannten Autoren da-
mit nicht nur grundsätzlich die Organisation und Kontrolle von Arbeit in der IT-Industrie, son-
dern ermögliche es den IT-Unternehmen in der Folge auch, räumlich entfernt ausführbare Pro-
zesse und Funktionen zu identifizieren und entsprechend aus den vor Ort ablaufenden Prozessen
herauszulösen, zu verlagern und so u.a. Lohnkostenunterschiede zwischen unterschiedlichen Welt-
regionen zu nutzen. Waren die Bereiche der Softwareentwicklung und IT-Dienstleistungen damit
lange Zeit geografisch vorwiegend auf die entwickelten Industrieländer beschränkt, so werden im
Zuge der Internationalisierung damit zunehmend andere Regionen in die globalen Produktionss-
trukturen der IT-Unternehmen eingebunden5 .
Nach Lage der Literatur dürfe jedoch kein einseitiges Kausalverhältnis zwischen Industrialisie-
rung und Internationalisierung der IT-Industrie angenommen werden. Vielmehr bildeten Indus-
trialisierung und Internationalisierung nach Ansicht vieler Autoren einen dynamischen Wirkungs-
zusammenhang, in dem sich beide Entwicklungen gegenseitig bedingen und weiter vorantreiben.
So wird einerseits eine weitreichende Industrialisierung in Form zunehmender Standardisierung
und Formalisierung der Arbeitsprozesse als eine zentrale Voraussetzung für die Etablierung glo-
bal verteilter Arbeitsprozesse angesehen, da sie die vormals ganzheitlichen Tätigkeitsprofile der
Beschäftigten, die für die IT-Industrie lange Zeit als typisch galten, zu stärker arbeitsteiligen und
spezialisierten Funktionen transformiere. Dadurch komme es in den Arbeitsabläufen zu differen-
zierten Rollen mit festen Zuständigkeiten in separat ablaufenden, klar beschriebenen und spezi-
fizierten Prozessen (vgl. u.a. ebd., 69ff.; Boes 2004, 126f.; Aspray, Mayadas und Vardi 2006, S.61;
Sahay 2003). Erst auf dieser Grundlage sei es in der Folge dann auch möglich, die räumlich ent-
fernt ausführbaren Prozesse und Funktionen zu identifizieren und entsprechend aus den vor Ort
ablaufenden Prozessen herauszulösen und zu verlagern. Zudem sei die Relevanz von direkter Kom-
munikation und face-to-face Kontakt bei standardisierten und vor allem auch formalisierten Ar-
beitsprozessen wesentlich geringer.

5
Historisch beginnt dieser Prozess durch eine Einbeziehung anderer Hochlohnregionen, wie z.B. amerikanische Nie-
derlassungen europäischer IT-Unternehmen. Zunehmend werden aber vor allem Niedriglohnregionen als Ziel der
Arbeitsverlagerung gewählt (vgl. ebd.).
14 Einleitung

Zum anderen wird umgekehrt erwartet, dass „die Realisierung von Offshoring-Projekten [...]
Standardisierungswirkungen auf die verbleibenden Arbeitsprozesse [hat] und [...] insofern ein
wichtiger Treiber weiterer Standardisierungsbestrebungen [ist]“ (Boes 2004, S.127; ähnlich auch
Kämpf 2008, S.66).
Nach Ansicht der Vertreter der „Industrialisierungsthese“, bilden Industrialisierung und Inter-
nationalisierung also eine Art „Teufelskreis“, dessen dynamische Entwicklung die Arbeitsprozesse
in der IT-Industrie zunehmend standardisiere, formalisiere und zudem global fragmentiere. Für
die IT-Beschäftigten bedeuten diese Entwicklungen damit potentiell einen großen Umbruch ihrer
Arbeitssituation. Sowohl auf der Ebene der Beschäftigungsverhältnisse – als „neue Unsicherheits-
erfahrung“ (Kämpf) – als auch auf der Ebene der Arbeitsorganisation – als Zunahme restriktiver
Formen der Arbeitskontrolle im Zuge von Standardisierung und Formalisierung der Arbeitspro-
zesse – drohen sich zentrale Charakteristika einer Beschäftigung in der IT-Industrie zu verändern,
die lange Zeit als typisch für diese Art der Arbeit angesehen wurden.

1.2 Fragestellung der Studie

Zweifellos lassen sich eine Reihe der in der Debatte thematisierten Entwicklungen gegenwärtig in
der IT-Industrie beobachten. So befindet sich die IT-Industrie ganz offensichtlich in einer Phase
der zunehmenden Internationalisierung ihrer Leistungserstellungsprozesse. Regionen in der kapi-
talistischen Semiperipherie, wie z.B. Indien und China, haben in den letzten Jahren einen sprung-
haften Anstieg der Software-Exporte zu verzeichnen und viele der großen IT-Unternehmen haben
mittlerweile Dependancen in unterschiedlichen Weltregionen gegründet und operieren damit glo-
bal verteilt über verschiedene Standorte hinweg. Auch die Standardisierungstendenzen der techni-
schen Grundlagen und der Produkte und Leistungen in der IT-Industrie, die mit dem Begriff der
Industrialisierung angesprochen werden, sind schwerlich von der Hand zu weisende Entwicklun-
gen, welche die Gestalt der Branche in den letzten 20 Jahren z.T. stark verändert haben.
Die Frage jedoch, ob es im Zuge der Internationalisierung der IT-Industrie auch zu der von
den Vertretern der Industrialisierungsthese behaupteten Standardisierung und Formalisierung der
Arbeitsprozesse durch veränderte betriebliche Kontrollkonzepte kommt, ist nach wie vor offen.
Das liegt zum einen daran, dass bisher nur wenige empirische Studien zu diesem Thema verfügbar
sind (vgl. zu der Einschätzung auch Upadhya 2009), zum anderen aber auch daran, dass schon die
wenigen verfügbaren Studien die behauptete Industrialisierung der Arbeitsprozesse im Zuge der
Internationalisierung nur sehr eingeschränkt belegen können. So gestehen selbst die Vertreter der
Industrialisierungsthese zu, dass die Durchsetzung der veränderten Organisationskonzepte in den
Unternehmen

„[...] keinesfalls ein determinierter unilinearer Prozess [ist]. Vielmehr brechen sich
die Umsetzung und die Ausgestaltung der internationalen Arbeitsteilung in der Praxis
an betrieblichen Kräfteverhältnissen, gesellschaftlichen Rahmenbedingungen und den
kulturellen settings vor Ort“ (Kämpf 2008, S.81, Hervorhebung im Original).

Derselbe Autor konstatiert in seiner Studie dann überraschenderweise sogar, dass es einigen IT-
Beschäftigten im Zuge der Verlagerungsbemühungen ihres Unternehmens durchaus gelinge, die
eigene Macht- und Verhandlungsposition zu stärken. Die Standardisierung und Formalisierung in
jenen Unternehmen sei nicht derart fortgeschritten, dass sie die Abhängigkeit des Managements
von zentralen Akteuren aufgrund deren Stellung im Arbeitsprozess in größerem Maße reduzieren
Fragestellung der Studie 15

würde, weshalb die erfolgreiche Koordination mit den Offshore-Standorten noch stark an zentra-
len „Key-Playern“ in diesen Unternehmen hänge (ebd., S. 372ff). Letztlich zeigt sich somit, dass der
von den Vertretern der Industrialisierungsthese unterstellte Zusammenhang zwischen Industriali-
sierung und Internationalisierung der IT-Industrie in der Realität wesentlich weniger zwingend
und eindeutig sein könnte, als gewöhnlich behauptet wird.
Die vorliegende Studie richtet ihren Blick daher auch genau auf diesen Zusammenhang von In-
dustrialisierung und Internationalisierung der IT-Industrie. Sie geht der Frage nach, ob es durch die
zunehmende Internationalisierung der IT-Industrie tatsächlich zu dem von den Vertretern der Indus-
trialisierungsthese erwarteten weitreichenden Umbruch in den Formen der betrieblichen Kontrolle von
IT-Arbeit kommt. Für die arbeitssoziologische Forschung ist diese Frage von besonderem Interesse,
da IT-Arbeit stets geradezu als Paradebeispiel bei der Analyse hochqualifizierter Tätigkeiten diente
und diesen Tätigkeiten generell zugeschrieben wurde, sich eher „direkten“ Formen der Kontrolle
zu sperren (siehe Kapitel 1.1). Von daher würde ein derart umfassender Bruch in der Form der
betrieblichen Kontrolle von IT-Arbeit, wie ihn die genannten Autoren prognostizieren, das Bild
von Arbeit in der IT-Industrie nachhaltig verändern.
Für die Vertreter der Industrialisierungsthese ist die selbst festgestellte Uneinheitlichkeit der be-
trieblichen Reorganisationsbemühungen kein Grund, den prognostizierten Zusammenhang von
Industrialiserung und Internationalisierung in Frage zu stellen. So behandelt Kämpf die noch auf
die individuellen Selbstorganisationsfähigkeiten der Beschäftigten abzielenden Formen der Ar-
beitsorganisation in seinen Fallunternehmen lediglich als Ausdruck „ökonomische[n] Druck[s]
und mangelnde[r] Prozessreife“, wodurch „das Management zu ‘hektischen’ und nicht immer sys-
tematischen Formen der Integration der Offshore-Standorte genötigt“ werde (ebd., S. 373). Kon-
trollstrategien, die dem Muster der „verantwortlichen Autonomie“ folgen, seien dieser Auffassung
nach daher nur „Überbleibsel“ traditioneller Formen der Arbeitsorganisation und -kontrolle in
den IT-Unternehmen und verwiesen auf einen Rückstand in den Industrialisierungsstrategien die-
ser Unternehmen (ebd., S. 373). Gemäß dieser Einschätzung kommt er dann auch zu dem Schluss,
dass

„[...] Standardisierung und Industrialisierung [...] als wesentliche Voraussetzung der

Internationalisierung im Bereich Software-Entwicklung und IT-Dienstleistungen zu
gelten [haben], auch wenn es den konkreten Fallunternehmen nicht ohne weiteres
gelingt, diese Voraussetzung zu erfüllen.“ (ebd., S. 374)

Dieser Schlußfolgerung will die vorliegende Studie widersprechen. Statt die empirisch vorfind-
bare Varianz der Reorganisationsprozesse als (langfristig schwächer werdende) Abweichungen von
einem die Branche dominierenden Meta-Trend zu deuten, soll hier argumentiert werden, dass in-
nerhalb der IT-Industrie statt branchenübergreifend eindeutiger Industrialisierungstendenzen viel-
mehr unterschiedliche Reorganisationsmodi als spezifische Strategien und Formen der (Re-) Orga-
nisation und Kontrolle von Arbeit zur Etablierung der neuen globalen Arbeitsprozesse entstehen,
die ganz unterschiedliche Folgen für die Arbeitssituation der Beschäftigten haben. Diese Arbeit
konzentriert sich auf jene Phänomene, die in der bisherigen Debatte häufig vernachlässigt werden.
Geht die Debatte, wie im vorigen Kapitel gezeigt, davon aus, dass sich die Industrialisierung in der
IT-Industrie als branchenweit eher einheitlicher Prozess vollzieht, so berücksichtigt diese Studie
explizit die unterschiedlichen, in der IT-Industrie vorfindbaren Internationalisierungswege und die
in die entstehenden globalen Wertschöpfungsketten eingebundenen neuen Standorte in die Analy-
se mit ein. Das zentrale Argument lautet, dass die unterschiedlichen Reorganisationsmodi und die
Formen der Arbeitsorganisation und -kontrolle, die sie beinhalten, abhängig sind vom Wechsel-
16 Einleitung

spiel der von den Unternehmen verfolgten Internationalisierungswegen mit lokalen Charakteristika
der Offshore-Standorte.
Damit wird auf der einen Seite dem Umstand Rechnung getragen, dass sich die Verlagerung
von IT-Arbeit aus den kapitalistischen Zentren an Offshore-Standorte in Niedriglohnregionen der
kapitalistischen Semi-Peripherie in unterschiedlichen Formen vollzieht, die auf unterschiedliche
Geschäftsmodelle der beteiligten Unternehmen zurückgeführt werden können (vgl. Flecker 2006;
Flecker u. a. 2007). In dieser Studie wird mit „Offshore-Outsourcing“ und „Captive-Offshoring“
zwischen zwei wichtigen Varianten der Verlagerung von IT-Arbeit – und damit der Internationali-
sierung der IT-Industrie – unterschieden.
Unter „Offshore-Outsourcing“ wird das gleichzeitige Aus- und Verlagern von vorher intern er-
brachten IT-Leistungen eines Unternehmens an einen externen und auf diese Tätigkeiten spezia-
lisierten IT-Dienstleister verstanden, der seinerseits dann die Leistung (zumindest z.T.) Offshore
erbringen lässt. Meist handelt es sich bei den verlagernden Unternehmen um IT-Anwender, al-
so Unternehmen, deren Kerngeschäft nicht in der Erstellung von IT-Leistungen oder -Produkten
besteht, wie z.B. klassischerweise Banken oder Versicherungen. Auf der Seite der externen Dienst-
leister finden sich in diesem Markt einerseits die großen, amerikanischen und europäischen IT-
Dienstleister, wie Accenture, IBM, EDS oder auch T-Systems, die, nachdem sie ihre Kunden lange
Zeit aus den Hochlohnregionen der USA oder Europas bedient haben, im Zuge der verschäften
Konkurrenz angefangen haben, Offshore-Kapazitäten in ihre Leistungserstellungsprozesse einzu-
binden. Vorreiter und zunehmend Vorbilder für die organisatorische Umsetzung dieses Geschäfts-
modells sind gegenwärtig allerdings aufstrebende IT-Dienstleister aus Indien, wie z.B. TCS, Infosys
und Wipro, die in den letzten Jahren durch enorme Umsatzwachstumsraten und spezielle Organi-
sationsmodelle aufgefallen sind, und zunehmend Marktanteile in den USA und Europa erobern.
Mit „Captive-Offshoring“ wird hingegen die räumliche Verlagerung von Arbeit innerhalb der
Firmengrenzen des verlagernden Unternehmens gefasst. Diese Variante der Verlagerung wird als
„Captive-Offshoring“ bezeichnet, weil die in entfernten Regionen gegründete Niederlassung Ei-
gentum des Mutterunternehmens bleibt. Vor allem die großen amerikanischen und europäischen
Standardsoftware-Hersteller, wie z.B. Microsoft, SAP, Oracle, Adobe, aber auch Unternehmen, die
Software z.B. als Teil von Großmaschinen (sogen. „Embedded Software“) entwickeln, unterhalten
mittlerweile große Offshore-Entwicklungszentren in Niedriglohnregionen, in denen sie Teile ih-
rer Produkte entwickeln lassen.
Die vorliegende Studie argumentiert, dass diese beiden Verlagerungsvarianten ganz entschei-
denden Einfluß auf die entstehenden Reorganisationsmodi haben, weil mit dem Verlagerungs-
modell weitreichende Festlegungen im Hinblick auf die Art der verlagerten und im Offshore-
Entwicklungszentrum ausgeführten Arbeiten getroffen werden. Entschieden wird damit, welche
konkreten Tätigkeiten, mit welchen Qualifikationsansprüchen und welchen kreativen Anforde-
rungen von den Unternehmen an den neuen Standorten ausgeführt werden.
Doch es sind nicht nur diese unterschiedlichen Verlagerungsvarianten, die sich auf die Reorga-
nisationsmodi von Arbeit auswirken. Wie sich zeigen wird, ist die Form der Reorganisation der
Arbeitsprozesse zudem stark von zentralen Eigenschaften des Offshore-Standortes abhängig, an
dem die Tätigkeiten ausgeführt werden sollen.
So berücksichtigt diese Studie auf der anderen Seite – neben den variierenden Internationalisie-
rungswegen – auch den Einfluß des lokalen IT-Arbeitsmarktes (als ein wesentliches Charakteristi-
kum des Ziel-Standortes) auf die entstehenden Formen der Arbeitsorganisation und -kontrolle,
weil dieser durch das lokal verfügbare Arbeitskräfteangebot auch über Möglichkeiten und Be-
schränkungen der Organisation der Arbeitsprozesse an diesen Standorten bestimmt (vgl. z.B. auch
Athreye 2005a, S. 35). So hängt z.B. die Art der an den neuen Standorten ausführbaren Tätig-
Fragestellung der Studie 17

keiten ganz entscheidend von der Existenz einer ausreichenden Zahl entsprechend qualifizierter
Arbeitskräfte ab. Zudem kann das Kräfteverhältnis auf dem Arbeitsmarkt auch über mögliche
Kontrollpraktiken entscheiden, weil den Beschäftigten durch eine überhängende Nachfrage auf
dem Arbeitsmarkt Machtpotenziale zufallen, etwa in Form erleichterter Jobwechsel, die eine an-
spruchsvolle Haltung in Bezug auf die Tätigkeiten möglich machen, denen betrieblich Rechnung
getragen werden muss (Smith (2006) spricht in diesem Zusammenhang von „mobility power“ der
Beschäftigten). Umgekehrt kann ein Überangebot auf dem Arbeitsmarkt helfen, bestimmte For-
men der Organisation von Arbeit durchzusetzen, die ansonsten von den Beschäftigten nicht ak-
zeptiert würden. Die Situation auf dem Arbeitsmarkt wird damit zu einem ganz eigenständigen
Einflußfaktor auf die Reorganisationsbemühungen der an dem Standort aktiven Unternehmen.

Die zentrale Hypothese dieser Studie lautet zusammenfassend also, dass sich in der IT-Industrie
im Zuge ihrer Internationalisierung statt einheitlicher und gleichförmiger Industrialisierungspro-
zesse vielmehr spezifische Reorganisationsmodi identifizieren lassen, die sowohl von variierenden
Internationalisierungswegen innerhalb der Branche, als auch von den Arbeitsmärkte an den Off-
shore-Standorten geprägt werden, und die – so die Hypothese weiter – unterschiedliche Formen
der Kontrolle von Arbeit beinhalten. Abbildung 1.1 fasst den Ansatz der Studie noch einmal zu-
sammen.

Varianten der Verlagerung

von Tätigkeiten
Betriebliche
Reorganisationsmodi

Arbeitsmarkt
der
Onsite Zielregion

Offshore

Abbildung 1.1: Reorganisationsmodi unter Einfluß von Verlagerungsvarianten und Arbeitsmarkt

des Offshore-Standortes
18 Einleitung

1.3 Empirisches Design und methodisches Vorgehen

Die vorliegende Studie beinhaltet Betriebsfallstudien von zwei IT-Unternehmen, die in unter-
schiedlicher Weise an der Verlagerung von IT-Arbeit von Deutschland nach Indien mitwirken.
Die Beschränkung auf zwei Fälle hat den Nachteil, dass keine repräsentativen Ergebnisse für die
IT-Industrie erwartet werden können. Allerdings wird mit einem IT-Dienstleistungsunternehmen
und einem Standardsoftware-Entwickler der Fokus der Studie auf zwei Akteure gerichtet, die an
der gegenwärtigen Phase der Internationalisierung der IT-Industrie in besonderem Maße betei-
ligt sind und deren Geschäfts- und Organisationsmodelle die Entwicklung stark prägen. Wie sich
in Kapitel 2 noch genauer zeigen wird, beschreiten die beiden gewählten Unternehmen sehr un-
terschiedliche Internationalisierungswege, die auf die jeweils verfolgten Geschäftsmodelle zurück-
geführt werden können, und die weitreichende Konsequenzen für die entstehenden Formen der
standortübergreifenden Arbeitsteilung haben. Die vorliegende Studie erlaubt durch die Beschrän-
kung auf zwei Fälle daher zwar keine repräsentativen Aussagen zu der branchenweiten Reichweite
der untersuchten Entwicklung, jedoch kann sie die Unterschiede in den entstehenden Reorgani-
sationsmodi innerhalb der IT-Industrie anhand der intensiven Untersuchung der Formen der Ar-
beitsorganisation und -kontrolle von zwei besonders typischen Akteuren detailliert herausarbei-
ten. Insofern trägt die Auswahl der Fallunternehmen Züge eines „most different case“-Designs6 .
Die Intensivfallstudien bestanden aus leitfadengestützten Interviews mit Beschäftigten und Ma-
nagementvertretern mit unterschiedlichen Funktionen und auf unterschiedlichen Hierarchiestu-
fen von jeweils 90-120 Minuten Länge, sowie zusätzlicher Dokumentenanalyse von zugänglich
gemachten Firmendokumenten.

Die Fokussierung auf den Standort Indien als Untersuchungsfeld ist dem Umstand geschuldet,
dass Indien gegenwärtig mit Abstand der größte Standort für das Offshoring von IT-Arbeit ist (vgl.
auch Stamm 2005). Weltweit wurde das Handelsvolumen von IT- und BPO7 -Offshoring-Projekte
schon 2005 auf ca. 40 Mrd. US-Dollar geschätzt (Deutsche Bank Research 2005, S.3). Indien hatte
zu diesem Zeitpunkt schätzungsweise zwei Drittel aller weltweiten und ein Drittel aller europäi-
schen IT-Offshoring Aufträge angezogen (Forrester Research 2004, S. 32, Upadhya und Vasavi
2006, S. 8). Die starke Zunahme der weltweiten Ausgaben für Offshoring-Projekte (für 2008 wird
das Marktvolumen bereits auf 89-93 Mrd. US-Dollar geschätzt; NASSCOM 2010) sorgte – zusam-
men mit einer investorenfreundlichen Politik der indischen Zentralregierung und vieler Bundes-
staatsregierungen – im vergangenen Jahrzehnt für ein beeindruckendes Wachstum des indischen
Software und IT-Dienstleistungsbereiches: Dieser legte in den 1990ern teilweise über 50 Prozent
jährlich zu (Upadhya und Vasavi 2006, S. 8ff.). Zwar nahmen die Wachstumsraten auch in Indien
ab, doch selbst von 2004 bis 2006 war immerhin noch ein jährliches Umsatzwachstum von ca. 33
Prozent zu verzeichnen (Deutsche Bank Research 2005, S. 5; Upadhya und Vasavi 2006, S. 8).
Als Untersuchungsfälle wurden mit einem deutschen Standardsoftware-Hersteller und einem in-
dischen IT-Dienstleister zwei unterschiedliche Varianten der Verlagerung von IT-Arbeit ausgewählt.
6
Die beiden Fallstudien wurden im Zeitraum von 2007-2008 im Rahmen des Forschungsprojektes „IT-Offshoring“
erstellt, das am Soziologischen Forschungsinstitut Göttingen (SOFI) in den Jahren zwischen 2006 und 2009 durch-
geführt wurde. Das Projekt wurde gefördert von der Deutschen Forschungsgemeinschaft (DFG). Der Projektleiter
war Volker Wittke und das Projekt wurde von Nicole Mayer-Ahuja in Zusammenarbeit mit dem Autor dieser Studie
bearbeitet.
7
BPO (Business Process Outsourcing) bezeichnet eher den Bereich der IT-gestützten Dienstleistungen. Gewöhnlich
werden z.B. Dienstleistungen im Bereich Rechnungslegungen oder Mitarbeiterverwaltung zu diesen Leistungen ge-
zählt. Da in diesen Bereichen nur mithilfe von IT gearbeitet wird, aber keine IT-Arbeit im engeren Sinne geleistet
wird, bleibt dieser Bereich in dieser Studie aussen vor.
Empirisches Design und methodisches Vorgehen 19

Das indische IT-Unternehmen bietet seinen Kunden Offshore-Outsourcing Dienstleistungen. Der

deutsche Standardsoftware-Hersteller hat eine eigene Niederlassung im indischen Bangalore ge-
gründet und entwickelt dort ein Modul eines neuen Softwareproduktes („Captive Offshoring“).
Da diese Studie explizit die Auswirkung der Verlagerung auf die Formen der betrieblichen Kon-
trolle des Arbeitsprozesses in den indischen Entwicklungszentren berücksichtigen möchte, wur-
den bei den Fallstudien nicht ausschließlich Beschäftigte im indischen Entwicklungszentrum be-
fragt, sondern zudem Beschäftigte aus den deutschen Niederlassungen, die direkt in die Koopera-
tion mit den indischen Entwicklungszentren involviert sind. Auf diese Weise sollte die konkrete
Praxis der standortübergreifenden Kooperation erfasst werden, da dies wichtige Erkenntnisse über
die Form und den Formalisierungsgrad der globalen Arbeitsteilung versprach.
Bei den untersuchten Unternehmen handelt es sich auf der einen Seite um einen großen indi-
schen IT-Dienstleister, der im folgenden als ServiceTec8 bezeichnet wird. ServiceTec ist eines der
großen indischen IT-Dienstleistungsunternehmen, die in den letzten Jahren durch ihre enormen
Wachstumsraten sowohl der Umsätze als auch der Beschäftigtenzahlen aufgefallen sind. So weist
ServiceTec in den letzten Jahren Umsatzwachstumsraten von z.T. weit über 30% auf, die Zahl der
weltweit Beschäftigten des Unternehmens verzehnfachte sich alleine in den Jahren von 2002 bis
2008 annähernd. Der Standort in Bangalore ist die Firmenzentrale von ServiceTec und weltweit
eines der größten Entwicklungszentren.
Auf der anderen Seite handelt es sich um einen deutschen Standardsoftware-Hersteller, der in die-
ser Studie NovoProd heißt. NovoProd unterhält bereits seit mehreren Jahren Niederlassungen in
unterschiedlichen Weltregionen. Der indische Standort in Bangalore wurde Anfang der 90er Jahre
eröffnet. An diesem Standort arbeiten mit über 3000 Beschäftigten9 knapp 20% der Gesamtbe-
schäftigten NovoProds.
Die Fallstudie bei ServiceTec beinhaltete Interviews mit Beschäftigten, die in zwei Projekten für
deutsche Kunden arbeiten. Es handelte sich dabei einerseits um ein klassisches Wartungsprojekt
und andererseits um ein Entwicklungsprojekt, in dem eine individuelle Software für einen Kun-
den geschrieben wurde. Zum Zeitpunkt der empirischen Erhebung war die Entwicklungsphase
bereits abgeschlossen und die Beschäftigten waren vor allem mit der Fehlerbereinigung und dem
Testen der Software beschäftigt. Bei ServiceTec wurden 22 Gespräche vorwiegend im indischen
Mutterhaus in Bangalore10 (bei der Zitation der Gesprächspartner mit SI abgekürzt) und 9 in der
deutschen Niederlassung (SD) geführt. Auch hier wurde darauf geachtet, an beiden Standorten
Beschäftigte zu interviewen, die in den selben Projekten arbeiten, und unterschiedliche Hierar-
chiestufen und Funktionen zu berücksichtigen (nähere Informationen zum Sample bei ServiceTec
bietet Tabelle 8.1 im Anhang, S. 209). Leider war es für diese Studie nicht möglich, die vor Ort di-
rekt beim Kunden arbeitenden Beschäftigten ServiceTecs zu interviewen, da vonseiten ServiceTecs
große Befürchtungen bestanden, dass der Kunden ein solches Vorgehen nicht gutheißen würde.
In vielen Fällen handele es sich um Kunden, die ihr Engagement mit indischen IT-Dienstleistern
gerne geheimhalten würden und daher eine Untersuchung in ihrem Unternehmen nicht dulden
würden.
Die Gespräche bei NovoProd konzentrierten sich auf ein Team, das ein neues Software-Produkt
entwickelt. Dieses Team umfasste Beschäftigte sowohl im deutschen Hauptquartier (ND), als auch
8
Aus Gründen der Anonymisierung werden in dieser Studie (auch in den Zitaten) alle Namen durch willkürlich ge-
wählte andere Namen oder Bezeichnungen ersetzt.
9
Diese Zahl bezieht sich auf den Zeitpunkt der Untersuchung. Bei Erscheinen dieser Studie wird die Zahl weiter
gewachsen sein, da der Standort in der Zeit nach der Befragung personell verstärkt wurde.
10
Einige Beschäftigte konnten während des Forschungsaufenthaltes leider nicht in Bangalore zugegen sein und wurden
daher per Telefon interviewt.
20 Einleitung

im indischen Entwicklungszentrum (NI). Dem Standort in Bangalore oblag dabei die Erstellung
eines wichtigen Moduls für dieses neue Produkt, weitere Module wurden u.a. in Deutschland ent-
wickelt. In Deutschland konnten insgesamt 9 Interviews mit Beschäftigten in unterschiedlichen
Projektfunktionen geführt werden. Interviewt wurden Beschäftigte, die in direktem Kontakt zum
indischen Entwicklungszentrum stehen und eng mit diesem kooperieren. Auf der indischen Seite
wurden 29 Gespräche mit Beschäftigten dieses Entwicklungsteams geführt. Auch hier streuen die
Interviews über die unterschiedlichen Hierarchiestufen und Funktionen (siehe Tabelle 8.2 (S. 210)
im Anhang für nähere Details hinsichtlich des Gesprächsprogramms).
Die beiden Intensivfallstudien bilden die zentrale empirische Grundlage für diese Studie. Zur
besseren Einschätzung der in diesen Studien erhobenen Informationen wurden zusätzlich 8 Ex-
pertengespräche in weiteren IT-Unternehmen sowohl in Deutschland als auch in Indien geführt.
Interviewt wurden dort jedoch ausschließlich Vertreter des Managements sowie der Personalabtei-
lung. Dies diente dazu, eine „Kontrastfolie“ zu den Intensivfallstudien zu erhalten, um die Beson-
derheiten der Fälle besser einschätzen zu können.
Neben den Interviews mit betrieblichen Akteuren wurden zudem Expertengespräche mit Ver-
tretern aus Politik, Wissenschaft und Wirtschaft geführt, die vor allem dem besseren Verständnis
des Phänomens IT-Offshoring galten und der Identifizierung relevanter Themenfelder dienten.
Alle Interviews wurden vom Projektteam durchgeführt, digital aufgezeichnet und anschließend
transkribiert. Die Erhebungen im indischen Bangalore wurden durch zwei Forschungsaufenthalte
von 2 und 14 Wochen ermöglicht. Das erhobene Material wurde anschließend unter Verwendung
des Analyseprogramms „[Link]“ inhaltsanalytisch ausgewertet.

1.4 Zum Aufbau der Studie

Die Argumentation der vorliegenden Studie gliedert sich in die folgenden Kapitel:

In einem ersten Schritt werden die beiden Formen der Verlagerung von Arbeit, die in dieser Stu-
die im Zentrum der Aufmerksamkeit stehen – „Offshore-Outsourcing“ und „Captive-Offshoring“
– näher behandelt (Kapitel 2). Es wird gezeigt, dass die beiden Verlagerungsvarianten auf die Ge-
schäftsmodelle der jeweiligen Akteure zurückgeführt werden können, die wesentliche Unterschie-
de hinsichtlich des angebotenen Produkt-, bzw. Leistungsspektrums und der Form der globalen
Arbeitsteilung zwischen den beiden berücksichtigten Fallunternehmen begründen (2.1 und 2.2).
Schließlich lassen sich in den beiden Varianten spezifische Formen von Standardisierung als Grund-
lage der Internationalisierung bestimmen, die – so die in diesem Abschnitt explizierte Hypothese
– damit auch unterschiedliche Reorganisationsmodi bedingen (2.3).

Im zweiten Schritt werden die Eigenschaften des indischen Arbeitsmarktes für IT-Fachkräfte
behandelt (Kapitel 3). In diesem Kapitel wird gezeigt, dass der durch den IT-Boom auf dem in-
dischen Arbeitsmarkt herrschende Nachfrageüberhang nach IT-Fachkräften für die dort aktiven
IT-Unternehmen zu Problemen geführt hat, da die Beschäftigten in die Lage versetzt wurden, für
die mittlerweile in Bangalore sprichwörtlichen „few Rupees“ zu einer Konkurrenzfirma zu wech-
seln (3.1 und 3.2). Für die am indischen Standort aktiven Unternehmen stellen die daraus folgenden
hohen Fluktuationsraten und die damit verknüpften Erwartungen der Beschäftigten hinsichtlich
Gehalt und Karriere eine entscheidende Rahmenbedingung für die Organisation ihrer Arbeitspro-
zesse dar. Die in diesem Abschnitt ausgeführte Hypothese lautet, dass diese Rahmenbedingungen
berücksichtigt werden müssen, wenn man die Reorganisationsbemühungen und -modi der Unter-
nehmen verstehen will, die IT-Arbeit nach Indien verlagern (3.3).
Zum Aufbau der Studie 21

Im Anschluß an die beiden Kapitel, in denen die für zentral erachteten Einflußfaktoren auf be-
triebliche Reorganisationsmodi im Zuge der Internationalisierung näher ausgeführt wurden, wird
im dritten Schritt ein konzeptioneller Zugriff entwickelt, der den Einfluß sowohl der beiden Verla-
gerungsvarianten als auch des indischen Arbeitsmarktes auf die in den beiden Unternehmen iden-
tifizierbaren Reorganisationsmodi fasst (Kapitel 4). Die variierenden Reorganisationsmodi werden
dabei als unterschiedliche Strategien der Arbeitskontrolle interpretiert (4.1). Dazu greife ich auf
ein Untersuchungskonzept von Andrew Friedman zurück, das auf der mittlerweile klassischen
Unterscheidung von Kontrollstrategien der „direkten Kontrolle“ und „verantwortlichen Autono-
mie“ beruht (4.2) und die Form der betrieblichen Kontrolle als strategische Gestaltung zentraler
Aktivitätsfelder durch das Management fasst (4.3).

Auf diese konzeptionellen Überlegungen folgen die beiden in dieser Studie durchgeführten Fall-
studien in je einem separaten Kapitel (Kapitel 5 und 6). Das Ziel der Fallstudien besteht darin, den
in den vorausgehenden Kapiteln in Form von Hyothesen skizzierten Zusammenhang von spezifi-
schen Internationalisierungswegen, indischem Arbeitsmarkt und daraus resultierenden variieren-
den Reorganisationsmodi empirisch zu belegen und näher auszuführen. Beide Fallstudien gliedern
sich – nach einem jeweils kurzen Unterkapitel zur Charakteristik des Unternehmens und der Rol-
le des indischen Entwicklungszentrums im globalen Geschäftsmodell (5.1/ 5.2, bzw. 6.1/ 6.2) –
entsprechend der im Konzeptionskapitel vorgestellten Operationalisierung des Kontrollbegriffs
(5.3bzw. 6.3). Jede Fallstudie endet mit einer kurzen Zusammenfassung der Ergebnisse (5.4/ 6.4).

Zum Abschluß (Kapitel 7) werden die in den Fallstudien identifizierten Reorganisationsmodi

noch einmal gegenübergestellt und die zentralen Befunde der Studie zugespitzt zusammengefasst
(7.1 und 7.2). Die Studie schießt mit einigen Gedanken zu offenen Fragen und weiterem For-
schungsbedarf (7.3).
22 Einleitung
2 Variierende Internationalisierungswege im
IT-Bereich
Die zentrale Hypothese dieser Studie lautet, dass sich in der IT-Industrie weniger eine gleichför-
mige Industrialisierung als vielmehr unterschiedliche Reorganisationsmodi im Zuge ihrer zuneh-
menden Internationalisierung identifizieren lassen, die unterschiedliche Formen der betrieblichen
Kontrolle begründen. Diese Reorganisationsmodi, so die These weiter, sind in ihrer Form durch
das Wechselspiel zwischen den variierenden Internationalisierungswegen in der IT-Industrie und
dem Arbeitsmarkt an den Ziel-Standorten bestimmt.
In diesem Kapitel soll gezeigt werden, dass sich mit „Offshore-Outsourcing“ und „Captive Offs-
horing“ zwei unterschiedliche Varianten der Internationalisierung in der IT-Industrie identifizie-
ren lassen, die sich aus einem speziellen Produkt- bzw. Leistungsspektrum und einem damit ver-
knüpften Geschäftsmodell der beteiligten Unternehmen ergeben und die jeweils eine bestimmte
Form der globalen Arbeitsteilung und Beziehung der miteinander in Beziehung gesetzten Stand-
orte beinhalten. In diesen beiden Internationalisierungswegen lassen sich Unterschiede in der In-
tensität und Form der Standardisierung und Formalisierung der zugrundeliegenden Arbeitspro-
zesse festmachen, die – so die hier ausgeführte Hypothese – unterschiedliche Reorganisationsmodi
in den Unternehmen begründen.

2.1 Das „Global Delivery Model“ der IT-Dienstleister

Die erste Variante der Internationalisierung in der IT-Industrie, die in diesem Kapitel in ihrer
Wirkung auf den zugrundliegenden Reorganisationsmodus näher bestimmt werden soll, ist das
„Offshore-Outsourcing“. Unter Offshore-Outsourcing werden Verlagerungsprozesse verstanden,
die sowohl organisationsübergreifende Aus- (Outsourcing) als auch regionale Verlagerungsprozesse
(Offshoring) beinhalten (vgl. Aspray, Mayadas und Vardi 2006, S.45f.).
Die organisationsübergreifende Verlagerung besteht darin, dass von Kundenunternehmen vor-
her intern durch die eigenen IT-Abteilungen erbrachte IT-Funktionen an einen auf diese Funktio-
nen spezialisierten externen IT-Dienstleister ausgelagert werden (Outsourcing)1 .
Lange Zeit wurde dieses Outsourcing-Geschäft von den großen westlichen IT-Dienstleistungs-
unternehmen (wie z.B. IBM, Accenture oder EDS) dominiert, die am selben Standort ansässig
waren wie die Kundenunternehmen. Diese Form des Outsourcings beinhaltete zunächst also kaum
oder nur in geringem Umfang auch eine räumliche Verlagerung der Tätigkeiten von Hoch- in
Niedriglohnregionen (vgl. Boes 2004, S.92).
Diese Situation ändert sich jedoch, seit mit den indischen IT-Dienstleistern ein neuer Akteur das
Geschäftsfeld betritt2 . Diese – gemeint sind vor allem die „5 Großen“ der indischen IT-Industrie:
1
Sicher erbringen IT-Dienstleister z.T. auch Leistungen für andere IT-Unternehmen, jedoch stellt die Verlagerung an
externe Dienstleister bei reinen IT-Unternehmen eher die Ausnahme dar (vgl. Boes 2004, S.77f, Kämpf 2008, S.43)
2
Zur Internationalisierung der indischen IT-Dienstleister siehe auch Niosi und Tschang (2009); sowie Fortanier und
Tulder (2009).

23
24 Variierende Internationalisierungswege im IT-Bereich

TCS, Infosys, Wipro, Mahindra Satyam und HCL3 – kombinierten als erste systematisch das orga-
nisationsübergreifende Outsourcing von IT-Leistungen mit der Nutzung von Offshore-Standorten
in Niedriglohnregionen, fügten der organisatorischen also eine räumliche Verlagerung hinzu (vgl.
Dossani 2007, S. 223). Dadurch erreichen diese Unternehmen erheblich reduzierte Kosten mit de-
nen sie die westlichen IT-Dienstleister unter Druck setzen und in den letzten Jahren zunehmend
Marktanteile erobern konnten (vgl. in der Einschätzung z.B. auch Singh 2005, S. 811). So wurde
den indischen IT-Dienstleistern bereits 2005 zugeschrieben, ein Fünftel des weltweiten Marktes für
„Custom Software“, d.h. die Anpassung oder Entwicklung von Erweiterungen auf der Basis von
Standardsoftware, abgedeckt zu haben (Athreye 2005a).
In der Folge gehen auch die großen westlichen IT-Dienstleister dazu über, Offshore-Kapazitäten
in ihre Wertschöpfungsketten zu integrieren, um ihre Kosten zu reduzieren. So haben alle großen
Dienstleister mittlerweile Offshore-Entwicklungszentren mit teilweise erheblichen Beschäftigten-
zahlen u.a. in Indien gegründet4 . Doch obwohl damit auch die westlichen IT-Dienstleister das
Outsourcing mit dem Offshoring kombinieren, gelten nach wie vor die indischen Dienstleister als
Vorreiter und Leitbilder bei der Entwicklung dieses neuen globalen Verlagerungsmodells im Be-
reich der IT-Dienstleistungen (vgl. Athreye 2005b, Boes u. a. 2007, auch Pohl und Onken 2003). Als
„early adopters“ haben sie eine Nische der zunehmend globalen IT-Industrie besetzt und sich auf
dieses Branchen-Segment, die Bereitstellung von Offshore-Dienstleistungen spezialisiert (Dossani
2007, S.225). Aus diesem Grund konzentriert sich diese Arbeit zur Untersuchung der Reorganisa-
tionsmodi bei „Offshore-Outsourcing“ auf einen indischen IT-Dienstleister.
Der Vorteil der indischen IT-Dienstleister war und ist, dass diese ihre indischen Entwicklungs-
zentren von Anfang an5 als Offshore-Komponente in ihr auf den globalen – wenn auch anfänglich
fast ausschließlich amerikanischen – Markt ausgerichtetes Geschäftsmodell eingebunden haben. So
entwickelten sie früh tragfähige Produktionsprozesse und -strukturen, wohingegen die etablierten
großen europäischen und amerikanischen IT-Dienstleister ihre Prozesse erst an die neuen Erfor-
dernisse globaler Arbeitsteilung anpassen müssen, mit allen Rigiditäten und Konflikten, die mit
der Umgestaltung der internen Arbeitsabläufe einhergehen (siehe Boes u. a. 2007, S.29).

Das von den indischen Dienstleistern entwickelte – und zunehmend von den westlichen IT-
Dienstleistern kopierte – Geschäftsmodell wird in der Literatur häufig als „Global Delivery Mo-
del“ bezeichnet (siehe z.B. Upadhya 2009 oder auch Boes u. a. 2007). Wesentliche Eigenschaften die-
ses Geschäftsmodells sind zum einen die spezielle Form der globalen Arbeitsteilung und zum ande-
ren die konsequente Prozessorientierung (vgl. ebd., Lema und Hesbjerg 2003, Mayer-Ahuja 2011,
Athreye 2005b), die damit auch einen ganz speziellen Modus der Organisation der Arbeitsprozesse
begründen.
Das „Global Delivery Model“ verbindet Vertriebsniederlassungen am Ort des Kunden (häufig
auch Frontend- genannt) mit sich offshore befindlichen Entwicklungszentren (Backend) und be-
ruht somit auf einer konsequenten Trennung der kundennah und den auch aus der Entfernung
zu erbringenden Leistungen (vgl. Kämpf 2008, S. 44, Boes u. a. 2007). Dies bedeutet, dass der IT-
3
„Groß“ bezieht sich in diesem Zusammenhang vor allem auf die enormen Beschäftigtenzahlen jener Unternehmen:
Laut Hackmann (2010) beschäftigt TCS gegenwärtig (2010) weltweit 140.000 Beschäftigte, Infosys 115.000, Wipro
110.000, HCL 62.000 und Mahindra Satyam 29.000.
4
IBM beschäftigt z.B. angeblich mittlerweile über 100.000 Angestellte in Indien, Accenture 50.000 und Capgemini
23.000 (ebd.).
5
Als Anfang wird hier der Moment verstanden, als die indischen IT-Dienstleistungsunternehmen ihr Geschäftsmo-
dell von dem die Anfänge der indischen IT-Industrie dominierenden Body-Shopping-Modell auf die Offshore-
Erbringung von IT-Dienstleistungen umstellten. Ausführlichere Erläuterungen zu diesen Veräderungen finden sich
bei u.a. bei Athreye 2005a,bund Dossani 2007.
Das „Global Delivery Model“ der IT-Dienstleister 25

Dienstleister mit einer Niederlassung am Ort des Kunden präsent ist, und von dort aus (neben
Sales- und Marketing-Aktivitäten) die Tätigkeiten bearbeitet, für die enger Kundenkontakt nötig
ist. So finden sich in diesen Niederlassungen vor allem die beratungs- und kommunikationsinten-
siven Tätigkeiten, wie z.B. strategische Beratungsleistungen, oder – wenn es um die Entwicklung
kundenspezifischer Software geht – das Design und die Anforderungsanalyse.
Komplementär zu diesen Niederlassungen am Standort des Kunden (also gegenwärtig noch
schwerpunktmäßig in den westlichen Industrieländern) beinhaltet das Modell Entwicklungszen-
tren in Offshore-Regionen. Liegt der Schwerpunkt der Aktivitäten der Onsite-Niederlassungen im
Bereich der kommunikations- und beratungsintensiven Tätigkeiten, so entfallen auf die Offshore-
Entwicklungszentren die eher personal- und arbeitsintensiven Tätigkeiten wie das Codieren und
das Testing der zu entwickelnden oder zu wartenden Applikation (vgl. auch Heeks 1995, S. 371,
Upadhya und Vasavi 2006, S.16).
Doch es sind nicht nur die konsequente Verknüpfung von Onsite- und Offshore-Kapazitäten
und die darin begründete Form der globalen Arbeitsteilung, die das „Global Delivery Model“ aus-
machen. Vielmehr betonen mehrere Autoren explizit die ausgeprägte Prozessorientierung als zen-
trales Merkmal der indischen IT-Dienstleister (vgl. Boes u. a. 2007, Athreye 2005b). Unter Prozes-
sorientierung werden dabei stark formalisierte und standardisierte Geschäftsprozesse verstanden.
Dies beinhaltet, dass für die Erbringung der unterschiedlichen Leistungen jeweils standardisier-
te Prozessbeschreibungen definiert werden. In diesen Prozessbeschreibungen sind dann die nöti-
gen Schritte der Leistungserbringung detailliert vorgeschrieben. Eine Prozessbeschreibung enthält
dementsprechend z.B. Informationen über die am Prozess beteiligten Rollen und deren genaue
Zuständigkeiten sowie die in jedem Arbeitsschritt zu leistenden Tätigkeiten. Zudem beinhalten
sie häufig klare Vorgaben für die einzelnen Tätigkeiten, wie z.B. Vorlagen für die Protokollierung
von Kundengesprächen (Die Prozessbeschreibungen werden bei der späteren Falldarstellung des
indischen IT-Dienstleisters noch ausführlich behandelt).
Die Prozessorientierung der IT-Dienstleister wird schon durch das von ihnen bereitgestellten
Leistungsspektrum und das damit zusammenhängende Ertragsmodell gefördert (vgl. auch Fle-
cker u. a. 2007, S.139). IT-Dienstleister erbringen schwerpunktmäßig Leistungen, die zuvor aus
den Abläufen der Kundenunternehmen herausgelöst wurden. Ihr Leistungsspektrum reicht da-
bei von Beratungsleistungen über Implementierungs- und Systemintegrations-Projekte bis hin zu
Wartungs- und Hosting-Projekten. Zumeist handelt es sich dabei um relativ stark standardisier-
te IT-Funktionen, die zudem häufig wiederkehren. So beinhaltet z.B. die firmenweite Installation
einer neuen Windowsversion in vielen Organisationen zum größten Teil dieselben Arbeitsschrit-
te, so dass diese von den IT-Dienstleistern dementsprechend leicht standardisiert und modelliert
werden können. Und auch die Anpassung eines Standardproduktes, wie z.B. einer SAP-Lösung,
an unterschiedliche Unternehmensumwelten hat eine überschaubare Zahl von Varianten. Für die
IT-Dienstleister schafft dies eine Möglichkeit, sich auf bestimmte, standardisierte IT-Leistungen
spezialisieren zu können und damit auch Skalenerträge zu erzielen. Grundlage dessen ist aber die
klare Standardisierung und auch Formalisierung der zugrundeliegenden Arbeitsprozesse, die eine
wiederholbare und möglichst effiziente Durchführung der jeweiligen Projekte erlaubt (vgl. auch
ebd., S. 85ff.). Im Zentrum der Aufmerksamkeit der IT-Dienstleister stehen daher nicht die kon-
kreten Projekte, sondern vielmehr die jeweils für ein Projekt auszuführenden Prozesse und die
dazu nötigen Aufwände (Boes u. a. 2007, S.26f:). Im Endeffekt besteht ein jeweils auszuführendes
Projekt damit aus dem Ablauf einer bestimmten Zahl miteinander kombinierter Prozesse.

Diese Orientierung an standardisierten Prozessen statt an jeweils unterschiedlichen konkreten

Projekten, wird durch das Ertragsmodell von IT-Dienstleistern noch zusätzlich verstärkt. Die an
26 Variierende Internationalisierungswege im IT-Bereich

IT-Dienstleister ausgelagerten IT-Funktionen können aufgrund ihres standardisierten Charakters

grundsätzlich von vielen Dienstleistern in vergleichbarer Qualität erbracht werden. Demnach kon-
kurrieren IT-Dienstleister bei der Vergabe von Kundenaufträgen in erster Linie über die Preise und
die Verlässlichkeit der Leistungserbringung.
Zur Festlegung der Preise haben sich im Bereich der IT-Dienstleistungen in den letzten Jah-
ren vor allem aufwandsbezogene Ertragsmodelle in Form von sogen. „Service Level Agreements“
(SLA) herauskristallisiert (Flecker u. a. 2007; Taylor 2010). Dabei handelt es sich um vertragliche
Vereinbarungen zwischen den Anbietern von Dienstleistungen und deren Kunden, in denen die
Art der zu liefernden Leistung möglichst detailliert beschrieben, in unterschiedlichen Kategori-
en, z.B. nach Art der Teilleistungen, gefasst und dann entsprechend auch preislich bestimmt wird.
Ferner sind in solchen Vereinbarungen häufig die Zeiträume der Bearbeitung, Qualitätsstandards,
Eskalationsstufen und entsprechende Verantwortlichkeiten zwischen den Parteien geregelt.
Die SLA’s beinhalten häufig umfangreiche Regelungen bzgl. der zu liefernden Leistung und
und greifen damit teilweise auch weit regelnd in die Arbeitsabläufe der Dienstleister ein, indem
bestimmte Vorgehensmodelle oder Verfahren vertraglich festgelegt werden6 . Ein kleines Beispiel
veranschaulicht diesen Punkt:

Der in dieser Arbeit untersuchte indische IT-Dienstleister ServiceTec hatte in einem

Wartungsprojekt permanent Auseinandersetzungen mit dem Kunden. Hintergrund
war, dass die von ServiceTec zu wartende – aber nicht selbst entwickelte – Applikation
diverse Fehler aufwies, die ein reibungsloses Funktionieren nahezu unmöglich mach-
ten. Dementsprechend hoch war der Wartungsaufwand für ServiceTec. Nun wollte der
Kunde die identifizierten Fehler im Rahmen des mit ServiceTec abgeschlossenen War-
tungsvertrages korrigieren lassen. ServiceTec verweigerte dies jedoch mit dem Hin-
weis, dass es sich bei dieser Tätigkeit um einen ganz anderen Prozess (Debugging statt
Maintenance) mit anderen Tagessätzen handele. Dementsprechend sei zwar das Korri-
gieren der Folgefehler der Applikation vom Wartungsvertrag abgedeckt, das Ausbes-
sern der Applikation selbst aber nicht. Diese Art von Konflikt sei nach Angaben von
Beschäftigten bei ServiceTec durchaus typisch für ihre Projekte.

Dieses kleine Beispiel verdeutlicht die Konsequenzen des im Bereich der IT-Dienstleistungen
dominierenden Ertragsmodells. Die SLA’s forcieren die Standardisierung und Formalisierung der
Arbeitsprozesse, weil die für den Kunden erbrachten Leistungen möglichst genau in einzeln ab-
rechenbare Einheiten zerlegt werden müssen (vgl. auch Flecker u. a. 2007, S.97). Die von den IT-
Dienstleistern implementierten Prozessmodelle mit ihren stark standardisierten und formalisier-
ten Abläufen bieten ihnen dabei die Möglichkeit, die nötigen Arbeitsschritte der Leistungserbrin-
gung für den Kunden (meist schon im voraus) detailliert auszuweisen und somit den Gesamtauf-
wand leichter einschätzbar zu machen.

Dies ist auch der Grund, warum IT-Dienstleister stärker als andere IT-Firmen auf internationale
Zertifizierungen der Leistungserbringungsprozesse wie CMMI, ISO9000 oder Six-Sigma – um nur
einige zu nennen – setzen.
Diese Zertifikate dienen einerseits als Werbung gegenüber Kunden, denen mit der erfolgreichen
Zertifizierung Qualität und Effizienz in der Projektabwicklung demonstriert werden soll. In ei-
6
Vgl. Flecker u. a. 2007, ganz ähnlich ist dies auch im Bereich der Call-Center (vgl. Taylor 2010)
Verteilte Entwicklungsmodelle bei Software-Herstellern 27

nigen Bereichen stellt eine erfolgreiche Zertifizierung, z.B. nach CMMI7 , bereits eine notwendige
Voraussetzung dar, um überhaupt an bestimmte Aufträge zu kommen, da sie von den Kunden
als Qualitätsausweis der Leistungserbringung eingefordert wird. Die indischen IT-Dienstleister
sind auch in dieser Hinsicht Vorreiter, denn gerade sie hatten anfänglich mit erheblichen Vor-
behalten der Kunden gegenüber der von ihnen gelieferten Qualität zu kämpfen. Die indischen
IT-Dienstleister versuchten diesen Zweifeln durch erfolgreiche Zertifizierungen zu begegnen. So
kamen im Jahr 2003 von den 80 nach CMMI Level 5 zertifizierten Unternehmen 60 aus Indien
(Deutsche Bank Research 2005, S.6).
Doch auch wenn eine wichtige Funktion der externen Zertifizierung in Kundenwerbung be-
steht, unterstützt die erfolgreiche Implementierung dieser Standards auch die Standardisierung und
Formalisierung der Arbeitsprozesse in den Unternehmen. Schließlich sind die Prozessmodelle, un-
abhängig von dem Grund ihrer Einführung, auch real wirksam, indem sie helfen, die Arbeitspro-
zesse in einzelne, einfacher zu beherrschende und abrechenbare Teilschritte zu zerlegen, und es
zudem erlauben, die Befolgung der Prozesse mit integrierten Kennzahlen zu messen (für eine kriti-
sche Auseinandersetzung mit den Prozessmodellen in Bezug auf die Arbeitsprozesskontrolle, siehe
Prasad 1998).
Die vielfach bemerkte „Zertifizierungswut“ (ebd.) der indischen IT-Dienstleister und die starke
„Prozessorientierung“ können daher als ein integraler Bestandteil des „Global Delivery Models“
der indischen IT-Dienstleister verstanden werden – sie sind seine Voraussetzung und seine Konse-
quenz zugleich.

2.2 Die Herausbildung verteilter Entwicklungsmodelle bei

Software-Herstellern
Die andere Form der Verlagerung von IT-Arbeit, die in dieser Arbeit behandelt wird, ist das
„Captive-Offshoring“. Unter „Captive-Offshoring“ werden Verlagerungsprozesse verstanden, die
sich innerhalb der organisatorischen Grenzen des verlagernden Unternehmens vollziehen. Kon-
kret handelt es sich dabei um Verlagerungen von IT-Arbeit an eine dem Unternehmen eigene Nie-
derlassung („captive“) in einer Niedriglohnregion.
Die zentralen Akteure dieser Verlagerungsvariante sind Unternehmen, die in ihren Offshore-
Entwicklungszentren Produktentwicklung betreiben (vgl. Upadhya und Vasavi 2006). Dies kön-
nen auf der einen Seite Standardsoftware-Hersteller sein, die Teile ihrer Softwareprodukte8 in
Niedriglohnregionen entwickeln lassen, wie z.B. Adobe, Microsoft, Oracle. Auf der anderen Seite
finden sich jedoch auch Unternehmen, die Software als Teil anderer nicht IT-spezifischer Produkte,
wie z.B. Waschmaschinen entwickeln (sogen. „embedded software“). So sind auch Firmen wie Sie-
mens, Bosch u.a. seit Jahren mit eigenen auf Softwareentwicklung spezialisierten Niederlassungen
in Niedriglohnregionen wie Indien präsent.

7
„Das Capability Maturity Model Integration (kurz CMMI) ist eine Familie von Referenzmodellen für unter-
schiedliche Anwendungsgebiete – derzeit für die Produktentwicklung, den Produkteinkauf und die Serviceer-
bringung. Ein CMMI-Modell ist eine systematische Aufbereitung bewährter Praktiken, um die Verbesserung
einer Organisation zu unterstützen“ (Wikipedia 2010b). Die Entwiclung begann 1986 auf Initiative des US-
Verteidigungsministeriums am Software Engineering Institute (SEI) an der Carnegie Mellon University/Pittsburgh,
welches dem US-Verteidigungsministerium untersteht. Eine erste Version des CMMI wurde 1991 veröffentlicht,
diese wurde und wird seitdem stetig weiterentwickelt (für nähere Informationen, siehe auch Herbsleb u. a. 1997).
8
z.B. eine Standardapplikation, die direkt einsatzfähig ist oder mit unterschiedlich umfangreicher Anpassung bei den
Kunden installiert werden kann (wie z.B. Microsofts bekanntes Bürosoftware-Paket)
28 Variierende Internationalisierungswege im IT-Bereich

Diese Form der Verlagerung unterscheidet sich in zweierle Hinsicht von der Verlagerung nach
dem Muster des Offshore-Outsourcing:

1. Die Beschäftigten in den Offshore-Entwicklungszentren erbringen keine Leistungen für ex-

terne Kunden, sondern sind in die Produktentwicklung des westlichen Mutterunternehmens
eingebunden.

2. Kundenkontakt findet bei Produkt-Herstellern zumeist lediglich am Ende der Produktion

über den Vertrieb des Produktes statt. Zwar unterhalten einige große Software-Hersteller
zudem strategische Partnerschaften zu Unternehmen, mit denen über zukünftige Produk-
tinnovationen und Anforderungen an die zu entwickelnde Software beraten wird, und die
auch meist für einen Testeinsatz von Prototypen und Betaversionen der Software herangezo-
gen werden, jedoch findet der Produktionsprozess der Software-Produkte im engeren Sinne
unabhängig von konkreten Kundenbeziehungen statt (vgl. Upadhya und Vasavi 2006, S.20).

Dementsprechend kreisen die Verlagerungsstrategien von Produkt-Herstellern auch nicht um

die Trennung von kundennah und kundenfern zu erbringenden Tätigkeiten, wie es für IT-Dienst-
leister charakteristisch ist. Die Verlagerungsstrategien von Produkt-Herstellern sind vielmehr pro-
dukt-zentriert, d.h. das Produkt wird in sogen. „verteilter Entwicklung“ hergestellt. Grundlage
eines solchen Modells sind modulare Produkt- und Prozessarchitekturen, die es erlauben, das Pro-
dukt in verschiedenen Modulen parallel an verschiedenen Standorten entwickeln zu lassen. Modu-
lare Produkt- und Prozessstrukturen basieren auf einem Produktionsprozess, der aus vielen unter-
schiedlichen Teilen besteht, deren Schnittstellen jedoch klar und eindeutig spezifiziert sind, um die
anschließende problemlose Reintegration im Produkt zu gewährleisten.

Im Gegensatz zum Offshore-Outsourcing von IT-Dienstleistungen kann bei Captive-Offshoring

allerdings gegenwärtig (noch?) nicht von einem eindeutig dominierenden Offshoring-Modell aus-
gegangen werden. Vielmehr befinden sich die Akteure gegenwärtig in einer Art Experimentiersta-
dium, in dem nach dem für sie richtigen Modell gesucht wird (Boes u. a. 2007, S.12ff.; vgl. auch
Flecker u. a. 2007, S.47ff.). So begründen modulare Strukturen und unternehmensinterne Arbeits-
teilung noch keinen „best way“ der internen Verlagerung, wie Flecker u. a. (ebd., S. 62) zu recht
bemerkt:

„However, it is both possible to hand off modules or ‘black boxes’ of sub-(projects) (a

matter of longer-term collaborations) or smaller, circumscribed or standardized tasks.“

So wurden die Offshore-Entwicklungszentren von den Unternehmen anfänglich oft nur dafür
genutzt, Standardprodukte zu lokalisieren, d.h. z.B. betriebswirtschaftliche Softwarepakete an län-
derspezifische Steuerregelungen anzupassen (Aspray, Mayadas und Vardi 2006, S.136f.; Boes u. a.
2007, S.10f.) oder relativ einfache Programmier- und Codiertätigkeiten zu erledigen. Auch später
bestehen bei vielen Unternehmen Strukturen fort, die diesem Muster folgen. Nach Boes kann die-
ses Vorgehen als Etablierung einer „verlängerten Werkbank“ bezeichnet werden. Im Fokus stehen

„gut spezifizierte Aufgabenstellungen auf einem vergleichsweise einfachen Komplexitäts-

und Technologieniveau mit geringer strategischer Bedeutung für das Unternehmen.“
(Boes 2004, S.97)
Internationalisierungswege und Reorganisationsmodi 29

Dieser Ansatz der Verlagerung betrifft also lediglich die Schritte der Softwareentwicklung, die
gemeinhin als besonders leicht zu verlagern gelten, wie das reine Codieren und Testen der Appli-
kation. Dieses Vorgehen impliziert auch eine globale Arbeitsteilung zwischen Standorten in Bezug
auf planende und ausführende Tätigkeiten. Die anspruchsvollen, planenden Tätigkeiten der Kon-
zeption und des Designs verbleiben bei diesem Modell allerdings meist an den westlichen (Heimat-)
Standorten der Unternehmen (vgl. auch Flecker u. a. 2007, S.50), wohingegen die in Niedriglohn-
regionen lokalisierten Entwicklungszentren klar spezifizierte, wenig komplexe Arbeitspakete zu-
gewiesen bekommen.
Gegenüber der Verlagerung nach dem Muster der „verlängerten Werkbank“ gibt es jedoch zu-
nehmend auch andere Formen der Verlagerungen in diesem Bereich. So haben einige der großen
Unternehmen, als mit zunehmender Erfahrung mit verteilter Entwicklung die Zuversicht in die
eigenen Fähigkeiten stieg, den Schritt gewagt, auch komplexe Tätigkeiten Offshore erledigen zu
lassen (Farrell u. a. 2005, S.204f.). Dieses Vorgehen beinhaltet im wesentlichen den Aufbau „ei-
gener Produktionsintelligenz“ (Boes 2004, S.97) und die Vergabe auch strategisch wichtiger und
fachlich anspruchsvoller Arbeitspakete an die Entwickler an den neuen Standorten. Diese Form
der Verlagerung findet eher netzwerkförmig statt und setzt auf modulare Strukturen mit hohen In-
terdependenzen der einzelnen Standorte. Dadurch werden die neuen Standorte zunehmend auch
mit planenden und konzeptionellen Verantwortlichkeiten betraut.

Im Bereich des Captive-Offshoring kann daher zwar gegenwärtig noch nicht in dem Maße von
einem Leitbild in Bezug auf ein globales Verlagerungsmodell ausgegangen werden, wie es im Be-
reich des Offshore-Outsourcing der Fall ist und es lassen sich daher noch wichtige Unterschie-
de in dem Grad feststellen, in dem die neu eröffneten Standorte Verantwortung für strategische
Entscheidungen übernehmen und welche Arten von Tätigkeiten dementsprechend dort geleistet
werden. Jedoch lässt sich feststellen, dass viele Unternehmen in den letzten Jahren dazu überge-
gangen sind, die Offshore-Standorte stärker in die entstehenden globalen Produktionsnetzwerke
einzubinden und folglich auch mit strategisch wichtigeren Aufgaben zu betrauen (vgl. Flecker und
Holtgrewe 2008).

Diese Studie konzentriert sich daher zur Untersuchung der Reorganisationsmodi in diesem Be-
reich mit NovoProd auch auf einen Standardsoftware-Hersteller, der in seinem indischen Ent-
wicklungszentrum höherwertige Tätigkeiten mit hoher strategischer Bedeutung für den Unter-
nehmenserfolg bearbeiten lässt. Diese Festlegung schränkt die Aussagekraft der gewonnen Ergeb-
nisse zwar ein, stellt aber in diesem Zuschnitt gerade im Vergleich zum Bereich des Offshore-
Outsourcing einen interessanten Kontrast dar. Denn gerade in dieser Variante des Captive-Off-
shoring treten die Unterschiede zwischen den beiden Verlagerungsvarianten und zwischen den zu-
grundeliegenden Reorganisationsmodi besonders deutlich hervor. Es kann demnach gezeigt wer-
den, wie unterschiedlich sich die Reorganisation der Arbeitsprozesse in den beiden berücksich-
tigten Konstellationen darstellen kann und welch unterschiedliche Folgen dies für die Form der
Kontrolle von Arbeit hat.

2.3 Internationalisierungswege und Reorganisationsmodi

Laut der Hypothese dieser Studie gehen die beiden skizzierten Varianten der Verlagerung und
der damit einhergehenden Internationalisierung der Produktion mit unterschiedlichen Modi der
Reorganisation der zugrundliegenden Arbeitsprozesse einher, die im Zusammenspiel mit dem in-
30 Variierende Internationalisierungswege im IT-Bereich

dischen Arbeitsmarkt auch die Form der Kontrolle von Arbeit an den indischen Offshore-Ent-
wicklungszentren prägen.
Auch wenn die genaue Analyse der Formen der Arbeitskontrolle in den späteren Kapiteln folgt,
können an dieser Stelle doch bereits aus der Analyse der Verlagerungsvarianten erste Erkenntnis-
se darüber gewonnen werden, wie sich die beiden näher beschrieben Varianten der Verlagerung
auf die Form der Reorganisation der Arbeitsprozesse auswirken. Wie bei der Darstellung der De-
batte über die Industrialisierung der IT-Industrie bereits erläutert (Kapitel 1.1.) wird die Indus-
trialisierung von IT-Arbeit vor allem als zunehmende Standardisierung und Formalisierung der
Arbeitsprozesse definiert. Anhand der in den beiden vorhergehenden Unterkapiteln erläuterten
Unterschiede der Verlagerung und der damit zusammenhängenden Geschäftsmodelle der Akteure
kann gerade in dieser Hinsicht ein wesentlicher Unterschied konstatiert werden. So kann in Be-
zug auf Offshore-Outsourcing und Captive-Offshoring mit Mayer-Ahuja (2011, S.69) konstatiert
werden, dass es sich im Bereich der IT-Dienstleistungen in erster Linie um Prozess-Standardisierung
handelt, wohingegen Produkt-Hersteller primär Produkt-Standardisierung betreiben.

Das Geschäftsmodell der – gerade indischen – IT-Dienstleister ist extrem prozessorientiert. Dies
lässt sich – wie im vorigen Unterkapitel erläutert – auf die von IT-Dienstleistern für ihre Kunden
erbrachten Leistungen und das damit verknüpfte Ertragsmodell zurückführen. So sind die Standar-
disierungsbemühungen der IT-Dienstleister zentral auf die Rationalisierung ihrer Leistungserbrin-
gungsprozesse gerichtet. Augenfälligstes Merkmal dieses Bemühens sind die vielfältigen Zertifizie-
rungen, die IT-Dienstleister für ihre Geschäftsprozesse durchlaufen, und die den Arbeitsprozess
in stark formalisierte und standardisierte Teilabläufe zerlegen und separat vergleich- und messbar
machen sollen.
Demnach schlägt bei IT-Dienstleistern die Standardisierung und Formalisierung von Prozessen
bis auf die Ebene der Einzelarbeiten durch. Viele Autoren sprechen daher von einem geradezu
„tayloristischen“ Ansatz, der die Tätigkeitsprofile der Beschäftigten auf einzelne Teilarbeiten be-
schränkt, damit fragmentiert und teilweise auch dequalifiziert (Upadhya und Vasavi 2006, Flecker
u. a. 2007, Mukherjee 2008).

Demhingegen kann die bei Produkt-Herstellern vorfindbare Form der Standardisierung, im Ge-
gensatz zum Bereich der IT-Dienstleister mit Mayer-Ahuja primär als Produkt-Standardisierung be-
schrieben werden (Mayer-Ahuja 2011, S.69). Zentraler Gegenstand von Standardisierung sind im
Bereich der Produkt-Herstellung (als Folge der Herausbildung modularer Produkt- und Prozess-
strukturen) eher die Eigenschaften des Produkts als die Eigenschaften von der Erstellung zugrunde
liegenden Produktionsprozessen. Wenn Teams an unterschiedlichen Orten separate Module einer
Applikation entwickeln, so müssen diese einzelnen Komponenten entsprechend klar spezifiziert
und in ihren Schnittstellen genau beschrieben sein, damit sich das Produkt anschließend auch in-
tegrieren und zusammenfügen lässt. Von daher findet zwar eine Aufspaltung des Gesamtprozes-
ses in einzelne Module statt und es kommt dadurch auch zu einer gewissen Fragmentierung des
Arbeitsprozesses. Ob und wie jedoch diese Fragmentierung die Arbeitsprozesse innerhalb jedes
einzelnen Moduls betrifft, ist damit noch nicht bestimmt. Es kann vielmehr erwartet werden, dass
die Form der Standardisierung und Formalisierung der Arbeitsprozesse in den jeweiligen Modu-
len stark davon abhängig ist, ob die Verlagerung nach dem Muster der „verlängerten Werkbank“
erfolgt, oder ob die neuen Standorte mit strategisch wichtigen Aufgaben betraut werden und ent-
sprechend komplexere Tätigkeiten zugewiesen bekommen. Die Standardisierungsbemühungen bei
Produkt-Herstellern im Bereich der Software-Entwicklung beziehen sich primär auf die verwende-
ten Tools der Entwicklung, die gemeinsam genutzten Programm-Bibliotheken und das (modulare)
Internationalisierungswege und Reorganisationsmodi 31

Design der Software. Einer der augenscheinlichsten Hinweise darauf ist der Umstand, dass die ex-
terne Zertifizierung, die bei den IT-Dienstleistern mittlerweile geradezu „zum Geschäft“ gehört,
bei den Standardsoftware-Herstellern nur eine nebensächliche Rolle spielt. So findet sich unter den
seit 2006 mit CMMI Level 5 bewerteten Unternehmen kein einziger der großen Standardsoftware-
Hersteller9 . Den Hintergrund dieses auf den ersten Blick überraschenden Fehlens erläutert die
Qualitätsbeauftragte der im Rahmen dieser Studie untersuchten deutschen Produktfirma, die eine
lange Karriere durch die unterschiedlichsten Firmen der indischen IT-Industrie vorzuweisen hat,
wie folgt:

„Very few product companies in the world ever go for CMMI – it’s mostly service
companies, who go. Because they work in a project mode – we work in a product
mode. We per se don’t have a direct end-customer for each product. [...] So mostly
there is product companies – [...] they take best practices, but they don’t necessarily
go for a formal certification and maintaining the certificate. Whereas you go and talk
to any service companies, like Accenture may be, or, I don’t know, I-Flex, Infy, Wipro,
TCS – any company. They will first start with telling that: We are CMM Level 5
blablabla. [...] The way that they work is: every project is with the customer. And
most of these customers expect you to work at a particular maturity level in your
organization.“ (NB19)

Dieser Aussage zufolge haben Standardsoftware-Hersteller durch die Abwesenheit von unmit-
telbaren Kundenbeziehungen einen größeren Spielraum, ihre Arbeitsprozesse den eigenen Bedürf-
nissen nach zu strukturieren. Demnach können Elemente von bekannten Prozessmodellen, wie
CMMI oder Six Sigma, zwar durchaus auch bei Standardsoftware-Herstellern vorfindbar sein, je-
doch besteht für Standardsoftware-Hersteller nicht in dem Maße der Zwang, sich für diese Modelle
auch extern zertifizieren zu lassen, wie es bei Dienstleistungsunternehmen der Fall ist.
Freilich bedeutet dies nicht den völligen Verzicht auf Prozessstandardisierung, die, wie gezeigt,
den Bereich der IT-Dienstleistungen dominiert. Auch die Hersteller von (Software-)Produkten ste-
hen unter Kosten- und Zeitdruck bei der Entwicklung und versuchen dementsprechend auch,
den Arbeitsprozess organisatorisch zu optimieren. Doch aufgrund der vorwiegend auf das Pro-
dukt gerichteten Standardisierungsbemühungen und der Abwesenheit direkter Kundenbeziehun-
gen im Produktionsprozess kann für die folgende Untersuchung des deutschen Standardsoftware-
Herstellers erwartet werden, dass die Standardisierung und Formalisierung nicht notwendigerwei-
se bis auf die Ebene der einzelnen Tätigkeiten durchschlägt.

Zusammenfassend kann also für die folgenden Fallstudien die Erwartung formuliert werden,
dass die Standardisierung und Formalisierung der Arbeitsprozesse im Falle von IT-Dienstleistern
eine wesentlich wichtigere und weitreichendere Funktion besitzt als für die Hersteller von (Soft-
ware-) Produkten. Es wird sich bei der später folgenden Darstellung des deutschen Standardsoft-
ware-Herstellers und des indischen IT-Dienstleisters zeigen, wie sich dies auf die betrieblichen Kon-
trollformen von Arbeit auswirkt.

9
Die Liste dieser Unternehmen kann auf der Seite des SEI unter [Link] eingesehen
werden.
32 Variierende Internationalisierungswege im IT-Bereich
3 Indien als Offshore-Standort
Neben den unterschiedlichen Internationalisierungswegen werden in dieser Studie die Arbeits-
märkte der Zielregionen der räumlichen Verlagerung als wichtiger Einflußfaktor auf die Reorgani-
sationsmodi von IT-Unternehmen im Zuge der Internationalisierung der IT-Industrie betrachtet.
Durch Einbeziehung der Arbeitsmärkte der Offshore-Standorte wird somit der Ort der Pro-
duktion in die Analyse der Art und Weise der Arbeitskontrolle integriert. Hintergrund ist die
Annahme, dass eine bestimmte Art der Arbeitsorganisation und -kontrolle immer auch auf die
Verfügbarkeit von entsprechend qualifizierten Arbeitskräften angewiesen ist. Doch es ist nicht
nur die reine Verfügbarkeit, sondern – gerade im Hinblick auf den indischen Standort – auch die
Möglichkeit, die Beschäftigten an das Unternehmen zu binden und gemäß den Bedürfnissen des
Unternehmens weiterzuentwickeln, die die Formen betrieblicher Kontrolle prägt.
In diesem Kapitel wird anhand der indischen IT-Industrie gezeigt, wie eine spezifische Konstel-
lation auf dem Arbeitsmarkt für die IT-Unternehmen zu einer organisatorischen Herausforderung
wird und somit die Organisation der Arbeitsprozesse in den Offshore-Entwicklungszentren in
starkem Maße beeinflusst.
Zunächst wird in einem kurzen Überblick die boomartige Entwicklung der indischen IT-In-
dustrie skizziert, bevor wir uns in einem zweiten Unterkapitel der Frage zuwenden, welche Aus-
wirkungen diese Entwicklungen auf den indischen Arbeitsmarkt hatten und haben und wie das
Arbeitskräfteangebot auf dem indischen Arbeitsmarkt näher charakterisiert werden kann.
Das dritte Unterkapitel schließlich beleuchtet den Zusammenhang zwischen der Situation auf
dem indischen Arbeitsmarkt und den Reorganisationsmodi der Unternehmen, wirft also einen
ersten Blick auf die Bereiche, in denen sich der Arbeitsmarktdruck auf betriebliche Organisations-
und Kontrollkonzepte auswirkt.

3.1 Der Boom der indischen IT-Industrie

Die indische IT-Industrie ist eine der erfolgreichsten der Welt. Daher hat sie in den letzten Jahren
auch viel Aufmerksamkeit aus dem wissenschaftlichen Bereich auf sich gezogen. Ihre boomartige
Entwicklung und die Gründe dafür waren Gegenstand zahlreicher Untersuchungen der letzten
Jahre1 . Wir beschränken uns daher an dieser Stelle auf einige wichtige Punkte, die notwendig sind,
um den Kontext zu verstehen, in dem sich die beiden Untersuchungsfälle im indischen Bangalore
bewegen, und die die Situation auf dem indischen Arbeitsmarkt wesentlich beeinflußen.
Abbildung 3.1 (S. 34) zeigt das rasante Umsatzwachstum der indischen IT-Industrie in den letz-
ten Jahrzehnten2 . Diese legte in den 1990ern teilweise über 50 Prozent jährlich zu (vgl. auch Upad-
hya und Vasavi 2006, S. 8ff.). Zwar nahmen die Wachstumsraten auch in Indien ab, doch selbst von
1
Für zusammenfassende Übersichten, siehe v.a. Dossani 2007, Athreye 2005a und Arora u. a. 2001.
2
Leider ist die Datenlage zur Entwicklung der indischen IT-Industrie sehr mäßig. Die einzigen, regelmäßig erhobenen
Daten stammen vom indischen Branchenverband NASSCOM. Leider ist es relativ unklar, wie belastbar diese Daten
sind, da z.B. wenig Informationen darüber erhältlich sind, wie genau die Daten erhoben und ausgewertet werden,
bzw. wie umfangreich die Datengrundlage ist. Nichtsdestotrotz bilden die von NASSCOM bereitgestellten Daten
die Grundlage fast aller zu diesem Thema veröffentlichten Studien.

33
34 Indien als Offshore-Standort

Abbildung 3.1: Umsatzwachstum der indischen IT-Industrie von 1984 – 2009 (Die Zahlen für die-
se Grafik sind bis einschließlich 2003 Athreye (2005b) und ab 2004 NASSCOM
(2007, 2009) entnommen. Für die Zeit von 1985-1990 sind leider keine Angaben
zum Gesamtumsatz vorhanden. Die Angaben für das Jahr 2009 sind Schätzungen
von NASSCOM.)

2004 bis 2008 war immerhin noch ein jährliches Umsatzwachstum von ca. 33 Prozent zu verzeich-
nen (vgl. auch Deutsche Bank Research 2005, S. 5; Upadhya und Vasavi 2006, S. 8).
Ein Merkmal, das die indische IT-Industrie von anderen aufstrebenden IT-Industrien, wie Chi-
na und Brasilien unterscheidet (vgl. Athreye 2005b), ist die starke Exportausrichtung. So wird das
Wachstum der IT-Industrie wesentlich vom Wachstum der Exporte getragen (vgl. auch Radhakris-
hnan 2003). Als Exporte werden sowohl Umsätze erfasst, die von indischen IT-Dienstleistern für
ausländische Kunden erbracht werden, als auch die Umsätze von Leistungen, die von multinatio-
nalen Unternehmen in ihren indischen Niederlassungen erbracht werden und die auf den Welt-
markt, statt auf den indischen Markt ausgerichtet sind. Getragen wird das Wachstum des IT- bzw.
IT-Dienstleistungsbereiches zum Großteil von den indischen IT-Dienstleistern. Lediglich 20% der
Exportumsätze wurden 2002 von den Niederlassungen der MNC’s erwirtschaftet (Singh 2005, vgl.
auch Athreye 2005a).
Im Gegensatz zum Exportbereich haben der indische IT-Markt und die Umsätze, die auf diesem
erzielt werden, nur geringen Anteil am Wachstum der Industrie3 .
Allerdings verteilt sich der Umsatz der indischen IT-Industrie in sehr unterschiedlichem Maße
auf verschiedene Zielregionen. Wie Abbildung 3.2 (S. 35) zeigt, geht der Großteil der Exporte in
3
Mit dieser Abhängigkeit vom Export und damit von globalen Kapitalströmen, wird die indische IT-Industrie auch in
erhöhtem Maße von externen öknomischen Einflüssen abhängig, ein Punkt der als mögliches Risiko für die weitere
Entwicklung der Industrie diskutiert wird (Upadhya und Vasavi 2006, S. 13).
Der Boom der indischen IT-Industrie 35

die USA. Historisch ist die indische IT-Industrie vor allem mit Geschäften auf dem amerikanischen
IT-Markt gewachsen, bevor man sich langsam davon emanzipierte und auch andere Regionen er-
schlossen werden konnten. Wie sich aus derselben Abbildung leicht ersehen lässt, ist es v.a. der
europäische Markt, der zunehmend das Wachstum der indischen IT-Industrie trägt und im Ver-
gleich zu den USA im Laufe der Jahre immer größere Exportanteile auf sich zieht.

Abbildung 3.2: Zielregionen der indischen IT-Exporte (Quelle: NASSCOM 2007, 2009)

In Bezug auf das Produkt- und Leistungsspektrum kann für die indische IT-Industrie konstatiert
werden, dass der Großteil des Umsatzes durch das Erbringen von IT- und BPO-Dienstleistungen4
erzielt wird. Abbildung 3.3 (S. 36) zeigt die Anteile der unterschiedlichen Branchensegmente am
Gesamtumsatz.
Zwar ist ersichtlich, dass sich gerade in den letzten Jahren der Anteil des BPO-Bereiches rela-
tiv vergrößert, jedoch stellt der IT-Dienstleistungsbereich gegenwärtig noch den dominierenden
4
Unter BPO werden jene Aktivitäten gefasst, die zwar auf einer IT-Infrastruktur basieren, deren Kernaktivitäten je-
doch nicht IT-spezifisch sind, wie z.B. ausgelagerte Buchführung oder andere HR-Funktionen für externe Kunden.
Auch Call-Center werden gewöhnlich in diesen Bereich gerechnet.
36 Indien als Offshore-Standort

Abbildung 3.3: Umsatz der indischen IT-Industrie nach Branchensegmenten von 2004 - 2009
(Quelle: NASSCOM 2009)

Bereich der indischen IT-Industrie dar. Höherwertige Tätigkeiten, also Forschungs- und Entwick-
lungsleistungen oder Produktentwicklung sind relativ konstant nur mit einem kleinen Umsatz-
anteil vertreten, wenngleich auch deren Umsatz in absoluten Zahlen wächst5 . Allerdings arbeiten
Beschäftigte in der Produktentwicklung zum überwiegenden Teil in den Niederlassungen west-
licher IT-Unternehmen, die Komponenten ihrer Software-Produkte in Indien entwickeln lassen.
Wenngleich indischen IT-Unternehmen attestiert wird, auch langsam in die Produktentwicklung
vorzustoßen, sind sie in diesem Bereich bisher nicht besonders erfolgreich (vgl. Upadhya und Va-
savi 2006, Radhakrishnan 2003).

Das Profil der indischen IT-Industrie spiegelt somit die besondere Funktion wider, welche die-
se in der globalen IT-Industrie gegenwärtig einnimmt. So wird Indien gegenwärtig zugesprochen,
der mit Abstand größte Standort für das Offshoring von IT-Arbeit zu sein, wenngleich Statisti-
ken zu diesem Thema sehr selten, häufig widersprüchlich und zudem noch politisch aufgeladen
sind6 (vgl. auch Stamm 2005, Forrester Research 2004, Upadhya und Vasavi 2006). Im Gegensatz
5
Der Anteil an Produktentwicklung wird in letzter Zeit sehr genau beobachtet und diskutiert, weil in einem steigen-
den Umsatzanteil an höherwertigen Arbeiten wie Forschung & Entwicklung und Produktentwicklung wichtige
Upgrading-Tendenzen des indischen Standortes gesehen werden. Ob es in letzter Zeit jedoch zu solchen Upgrading-
Tendenzen gekommen ist, bzw. wie wahrscheinlich solche Tendenzen in Zukunft sind, ist gegenwärtig noch um-
stritten (vgl. z.B. Parthasarathy 2006, Arora 2006, auch Nath und Hazra 2002
6
Zum Problem der Messung des Offshoring, siehe auch Deutsche Bank Research 2005.
Der indische Markt für IT-Arbeitskräfte 37

zu anderen Offshore-Standorten mit ähnlich hohen Exportanteilen, wie Israel oder Irland, liegt
der Schwerpunkt der Aktivitäten der indischen IT-Industrie jedoch vorwiegend im Bereich der IT-
Dienstleistungen und zunehmend auch des BPO. Höherwertige Tätigkeiten, wie z.B. die Entwick-
lung von Standardsoftware, findet gegenwärtig in Indien fast ausschließlich in den Niederlassungen
der großen westlichen IT-Unternehmen statt.

3.2 Der indische Markt für IT-Arbeitskräfte

Das im vorigen Unterkapitel skizzierte, rasante Wachstum der indischen IT-Industrie hat Konse-
quenzen für den IT-Arbeitsmarkt in Indien. Galten die vielen englischsprachigen, gut ausgebildeten
und im weltweiten Vergleich günstigen IT-Fachkräfte Indiens stets als besonderes Erfolgsgeheimnis
der indischen IT-Industrie (u.a. Thomas 2005), so droht gerade ein Fachkräftemangel inzwischen
für die indische IT-Unternehmen zum Problem zu werden (Arora u. a. 2001). Abbildung 3.4 (S. 37)
zeigt die dem Umsatzwachstum entsprechend ebenfalls rasant verlaufende Zunahme der Beschäf-
tigten in der indischen IT-Industrie.

Abbildung 3.4: Entwicklung der Beschäftigtenzahlen der indischen IT-Industrie von 2002 – 2009
(Quelle: NASSCOM 2009, Beschäftigte im Hardware-Bereich nicht mitgezählt)

Die Entwicklung der Beschäftigtenzahlen unterstreicht noch einmal die oben genannte Tatsa-
che, dass das Wachstum der indischen IT-Industrie wesentlich vom Exportsektor getragen wird.
Auch wenn der Anteil der Beschäftigten, die für den indischen Markt arbeiten, über die Jah-
re steigt, arbeitet doch der überwiegende Teil der IT-Beschäftigten im Export-Sektor. Auffällig
ist zudem, dass der BPO-Bereich in Bezug auf die Beschäftigtenzahlen sehr großes Gewicht be-
sitzt. Dennoch arbeitet der größte Teil der Beschäftigten im IT- (d.h. Produktentwicklung) und
IT-Dienstleistungsbereich. Insgesamt hat sich die Zahl der in der indischen IT-Industrie beschäftig-
ten Personen von 2002-2009 mehr als vervierfacht.
38 Indien als Offshore-Standort

Unter dem Druck eines derart rasanten Wachstum kommt es in Indien schon seit Mitte der
1990er Jahre zu ersten Anzeichen eines Mangels an IT-Fachkräften, der sich im letzten Jahrzehnt
stetig erhält, wenn nicht sogar ausweitet (Athreye 2005a, Upadhya und Vasavi 2006).
Dabei bezieht sich der Mangel nicht ausschließlich auf die reine Zahl an IT-Fachkräften, son-
dern es wird zudem die Qualifikation der Beschäftigten für die Unternehmen zum Problem. Laut
einer Studie von NASSCOM und McKinsey aus dem Jahre 2005 seien von den indischen Uni-
Absolventen lediglich 25% (der Absolventen technischer Ingenieurswissenschaften), bzw. 10-15%
(aller Fachrichtungen) geeignet, eine Beschäftigung im Exportsektor der indischen IT-Industrie
aufzunehmen (zitiert nach ebd., S. 26). Dabei sind es nicht nur die fachlichen Fertigkeiten, die An-
lass zur Sorge geben. Vielmehr fehlen den Absolventen nach Einschätzung vieler Unternehmen
„Soft Skills“, wie Sprach- und interkulturelle Kenntnisse, um in globalen und multikulturellen
Zusammenhängen arbeiten und kooperieren zu können (ebd., S.25).
Die Folge ist ein stetig wachsender Konkurrenzkampf der Unternehmen um die knappen Ar-
beitskräfte. Augenfälligste Anzeichen dieser Entwicklung sind auf der einen Seite die starken Ge-
haltssteigerungen für IT-Fachkräfte, und auf der anderen Seite die mittlerweile schon legendären
Fluktuationsraten innerhalb der indischen IT-Industrie. Beide Tendenzen stellen auf unterschied-
liche Art eine Gefahr für die weitere Entwicklung der indischen IT-Industrie dar und stehen daher
besonders im Zentrum der öffentlichen und wissenschaftlichen Aufmerksamkeit (z.B. ebd., Arora
u. a. 2001, auch Mayer-Ahuja und Feuerstein 2008).
Steigende Löhne sind eine leicht nachvollziehbare Gefahr für die weitere Entwicklung der in-
dischen IT-Industrie, da sich durch steigende Personalkosten die Kostenvorteile der Verlagerung
nach Indien entsprechend reduzieren. Für die Boomphase der indischen IT-Industrie während der
1990er Jahre berichtet Athreye (2005a) von jährlichen Gehaltssteigerungen von über 30%. Für die
Zeit nach 2000 kommt der indische Branchenverband NASSCOM in einer gemeinsamen Untersu-
chung in Zusammenarbeit mit der Unternehmensberatung Hewitt zu dem Ergebnis, dass sich die
Gehaltssteigerungen zwischen 2002 und 2008 zwischen 10 und 16,5% bewegten (Nasscom/Hewitt
2008). Zu einer ähnlichen Einschätzung gelangt auch Aspray 2006, wobei hier vor allem die Abhän-
gigkeit der Steigerungsraten von der Berufserfahrung betont wird. So scheinen sich die stärksten
Gehaltssteigerungen bei Beschäftigten im mittleren und hohen Management zu ereignen (zwischen
15 und 20% jährlich), wohingegen bei Berufsanfängern die Gehaltsteigerungen „nur“ zwischen 5
und 10% pro Jahr lägen.
Das ist insofern plausibel, als sich die höchsten Gehaltssteigerungen in der indischen IT-Industrie
durch regelmäßige Firmenwechsel realisieren lassen: Aufgrund des großen Bedarfs an Arbeitskräf-
ten versuchen die IT-Unternehmen sich häufig die Beschäftigten gegenseitig abzuwerben, was häu-
fig durch mit dem Angebot starker Gehaltssteigerungen und Beförderungen einhergeht (Upadhya
und Vasavi 2006). An dieser Situation haben auch die in den letzten Jahren öffentlich beschlosse-
nen „Anti-Abwerbe-Abkommen“ zwischen einigen IT-Unternehmen nichts geändert (Lacity, Ru-
dramuniyaiah und Iyer 2008). So können IT-Beschäftigte durch regelmäßige Wechsel ihre Gehälter
in kurzer Zeit erheblich steigern.
Mit den Gehältern steigen auch die Fluktuationsraten. Während des rasanten Wachstums der
indischen IT-Industrie während der 1990er Jahre lag diese Quote bei gut 25%, d.h. jeder vierte Be-
schäftigte eines Unternehmens hat im Laufe eines Jahres die Firma verlassen. Auch in den 2000ern,
als sich das Wachstum etwas verlangsamte, lag die Quote noch bei ca. 10-15% (vgl. Arora u. a. 2001;
Upadhya und Vasavi 2006).
Doch darf das Phänomen der Fluktuation nicht nur – so wie es Manager der in Indien aktiven
IT-Unternehmen gerne darstellen – als Ausdruck einer kurzfristig dekenden, finanziellen Orien-
tierung der Beschäftigten aufgefasst werden. So argumentieren Upadhya und Vasavi (ebd., S. 48ff.),
Der indische Markt für IT-Arbeitskräfte 39

dass die häufigen Unternehmenswechsel der Beschäftigten vor dem Hintergrund der spezifischen
Situation der indischen IT-Industrie durchaus eine rationale Form der Karriereplanung darstellen.
So argumentieren sie, dass für die indischen IT-Beschäftigten die weitere Entwicklung der Branche
sehr schwer abzusehen ist. Die Themen, die die indischen IT-Dienstleister bearbeiten, und auch die
Technologien, mit denen sie arbeiten, wechseln stetig mit den Wünschen der Kunden. Und auch
bei den multinationalen Firmen, die spezielle Produkte in Indien herstellen, ist unklar, wie lange
diese Unternehmen am indischen Standort bleiben.
Vor diesem Hintergrund sei es eher eine riskante Strategie, sich zu sehr auf ein einzelnes Unter-
nehmen und dessen Themenfeld zu spezialisieren. Daher ist es auch langfristig durchaus rational,
wenn die indischen Beschäftigten versuchen, ihre Berufserfahrung und ihre Qualifikationen mög-
lichst breit zu streuen, um für eine möglichst große Zahl an IT-Unternehmen zukünftig attraktiv
zu bleiben. In diese Richtung argumentiert auch ein Manager von ServiceTec:

„Deswegen – und sie auch versuchen was, immer was Neues zu werden. Wenn die
über zwei Jahre nur bei [Kundenname entfernt – PF] arbeiten, und die sehen, dass
in Industrie, die Leute ... z.B. hier können wir nur ein Java-Projekt arbeiten, für zwei
Jahre. In zwei Jahre in andere Industrie – die Leute haben noch zehn Sachen gelernt.
Deswegen die sind auch bisschen unglücklich. Das läuft so schnell und so viele neuen
Sachen in IT-Bereich kommen. Und die möchten mehr lernen und mehr von Projekt
zu Projekt wechseln, damit nach fünf oder zehn Jahren, die haben so viele Fall-zu-Fall-
Erfahrung.“ (SD7)

Für die Unternehmen bedeuten diese hohen Fluktuationsraten, dass das von den Beschäftigten
aufgebaute Erfahrungswissen und die im Laufe der Zeit erworbenen Qualifikationen die Firma ste-
tig wieder verlassen. Für die Projekte stellt das eine Gefahr dar, da Verzögerungen auftreten, wenn
Beschäftigte plötzlich das Team verlassen und durch neue Beschäftigte ersetzt werden müssen, die
zunächst gefunden – angesichts der angespannten Arbeitsmarktlage keine leichte Aufgabe – und
entsprechend eingearbeitet werden müssen, bis sie voll produktiv sind. Gerade in Positionen, wo
persönliche Kontakte zu Kunden oder anderen Kooperationspartnern relevant sind, stellt dies ein
besonderes Problem, dar, da sich Vertrauensbeziehungen schlecht entwickeln können, wenn Kon-
takte ständig wechseln. Letztendlich führen die Fluktuationsraten damit auch zu Mehrkosten in
den Unternehmen, untergraben damit den Kostenvorteil des indischen Standortes und damit die
zukünftige Entwicklung der indischen IT-Industrie (vgl. auch Athreye 2005a).

Es ist daher kein Wunder, dass die Bekämpfung des Arbeitskräftemangels in Indien sowohl bei
Unternehmen und Branchenverbänden, als auch bei politischen Entscheidungsträgern unterschied-
licher Ebenen besonders hohe Priorität genießt.
In der Folge finden sich seit Mitte der 90er Jahre diverse Initiativen, sowohl die Zahl der für
die IT-Industrie geeigneten Uni-Absolventen zu steigern7 , als auch die Inhalte der universitären
Ausbildung an die Bedürfnisse der IT-Industrie anzupassen8 (für einen guten Überblick über diese
Maßnahmen und auch die kritische Debatte um diese, siehe v.a. Upadhya und Vasavi 2006).
7
So wurden staatlicherseits im Zeitraum von 1998-99 drei neue – speziell auf die Ausbildung von IT-Fachkräften aus-
gerichtete – Indian Institutes of Information Technology (IIIT) gegründet und auch der Bereich der privaten Aus-
bildungsinstitute (wie z.B. NIIT und Aptech), die Absolventen nicht IT-spezifischer Studiengänge eine IT-Industrie
geeignete Weiterbildung anbieten, boomt seitdem (vgl. Arora u. a. 2001; Athreye 2005a)
8
Gerade der Branchenverband NASSCOM schaltet sich seitdem zunehmend in die Gestaltung der universitäten Cur-
ricula ein und versucht diese in eine der Industrie dienliche Richtung zu verändern.
40 Indien als Offshore-Standort

3.3 Indischer Arbeitsmarkt und Reorganisationsmodi

Obwohl von unterschiedlichen Seiten und mit unterschiedlichen Maßnahmen versucht wird, das
Arbeitskräfteangebot auf dem indischen Arbeitsmarkt quantitativ und qualitativ zu verbessern
und so die Folgen des Arbeitskräftemangels für die Unternehmen zu mildern, besteht dieser ge-
genwärtig – und voraussichtlich auch in näherer Zukunft – fort. Und so stehen die Unternehmen
vor der Aufgabe, mit dem indischen Arbeitsmarkt umzugehen, sich also organisatorisch auf stei-
gende Gehälter und weiterhin hohe Fluktuationsraten einzustellen.
In der Literatur werden verschiedene organisatorische und strategische Maßnahmen diskutiert,
mit denen IT-Unternehmen in Indien versuchen, dieser Herausforderung zu begegnen, und die
zeigen, wie weitreichend die Situation auf dem Arbeitsmarkt die Form der Arbeitsorganisation
am indischen Standort beeinflußt.

Zum stetigen Anstieg der Löhne tragen die IT-Unternehmen dabei selber durch ihre Praxis,
erfahrene und gut qualifizierte Beschäftigte von Konkurrenten abzuwerben, bei. Auch wenn seit
Jahren öffentlichwirksam sogen. „Anti-Poaching Agreements“ (Abkommen gegen das gegenseitige
Abwerben von Beschäftigten) zwischen Unternehmen geschlossen werden, geht diese Praxis wei-
ter, und das Abwerben von Beschäftigten funktioniert zumeist über das Anbieten von Gehaltsstei-
gerungen beim Firmenwechsel. Die von Managern in Indien häufig zu hörende Klage, Beschäftigte
würden schon „for a few Rupees“ die Firma wechseln, ist daher zu einem nicht unerheblichen Teil
auch ein selbst gemachtes Problem der Industrie.
Demnach laufen die Maßnahmen, die von IT-Unternehmen gegen die rasanten Lohnsteigerun-
gen ergriffen werden, vorwiegend darauf hinaus, die Produktivität der Beschäftigten zu steigern
und somit die steigenden Lohnkosten auszugleichen.
Ein Mittel dazu kann sein, für bestimmte Aufgaben, die keine tiefe IT-spezifische Ausbildung
erfordern, zunehmend auf weniger qualifizierte Beschäftigte zurückzugreifen, die entsprechend
weniger umkämpft sind und daher weniger hohe Gehaltsforderungen stellen können (Athreye
2005a). Dies bedeutet, dass IT-Unternehmen bei der Rekrutierung zunehmend auch Beschäftigte
mit nicht IT-spezifischer Ausbildung berücksichtigen. Schon lange sind in Indien alle Arten von
„Engineering“-Absolventen die primäre Zielgruppe bei der Rekrutierung durch IT-Unternehmen
(vgl. Upadhya und Vasavi 2006; Ilavarasan 2007; Athreye 2005a; Abraham und Sharma 2005)9 .
Da diese aber entsprechend stark umkämpft sind, versuchen einige Unternehmen, mithilfe einer
Art „Babbage-Prinzip“10 , Tätigkeiten, die keine tiefere IT-spezifische Ausbildung erfordern, zu-
nehmend durch Absolventen anderer Studienfächer erledigen zu lassen (Athreye 2005b). Die Ab-
solventen werden zu diesem Zweck mithilfe betriebsinterner Trainingsmaßnahmen entsprechend
geschult (vgl. auch Arora u. a. 2001). Gerade die großen indischen IT-Dienstleister haben in den
letzten Jahrzehnten beachtliche betriebliche Trainingseinrichtungen geschaffen, in denen neu re-
krutierte Beschäftigte gemäß der betrieblichen Bedürfnisse aus- und weitergebildet werden.
9
Genau genommen handelt es sich schon beim Großteil der Engineers auf dem indischen Arbeitsmarkt um IT-ferne
Arbeitskräfte. Denn Studierende des civil- oder mechanical-engineering (Bauingenieurwesen bzw. Maschinenbau)
studieren auch kein IT-spezifisches Fach. Dass dennoch generell Absolventen aller Engineering-Studiengängen in In-
dien zur Kerngruppe der IT-Fachkräfte gezählt werden, liegt daran, dass angenommen wird, dass Studierende dieser
Fachrichtungen wichtige Sekundärqualifikationen mitbringen (z.B. technisches Verständnis, logisches Denken), die
sie für eine Beschäftigung in der IT-Industrie grundsätzlich geeignet machen.
10
„Das Babbage-Prinzip (nach Charles Babbage) besagt, dass die Aufspaltung eines Arbeitsprozesses in unterschiedlich
anspruchsvolle Teilprozesse die Lohnkosten für die Produktion senkt. Babbage formulierte dieses Prinzip erstmals
in seinem 1832 in London erschienenen Werk On the Economy of Machinery and Manufactures. [...] Voraussetzung
ist die unterschiedliche Entlohnung unterschiedlich anspruchsvoller Arbeit (bzgl. Qualifikation, Anstrengung etc.)“
(Wikipedia 2010a).
Indischer Arbeitsmarkt und Reorganisationsmodi 41

Von steigender Bedeutung ist in dieser Hinsicht aber auch der private Trainingsbereich, also jene
Unternehmen und Bildungsinstitutionen, die Weiterbildungsmöglichkeiten für Absolventen ande-
rer Studienfächer anbieten und diesen einen IT-fähigen Abschluß, in Form von speziellen Diplo-
men, verleihen. Grundsätzlich werden diese Arbeitskräfte vom Qualifikationsniveau her nicht so
hoch geschätzt wie die Enginnering-Absolventen, doch für bestimmte Aufgaben lassen sich auch
diese Beschäftigten im Unternehmen einsetzen. Dies schafft die Voraussetzung dafür, die höher
qualifizierten Beschäftigten ausschließlich jene Aufgaben bearbeiten zu lassen, für die ihre Qualifi-
kation unbedingt nötig ist (Arora u. a. 2001; Athreye 2005a). So ziehen die neuen Rekrutierungs-
strategien gleichzeitig neue Formen der Arbeitsteilung und Spezialisierung im Arbeitsprozess nach
sich.
Ein anderes Mittel, die Kostensteigerungen durch steigende Löhne auszugleichen, ist die Steige-
rung der Produktivität der Arbeitsprozesse selbst. So führt z.B. Prasad 1998 das seit 1993 in der
indischen IT-Industrie grassierende „ISO-Fever“11 wesentlich auf den Arbeitskräftemangel der in-
dischen IT-Industrie in den Boomjahren der 1990er zurück. Diese Prozessmodelle – so war die Er-
wartung – sollten die Effizienz der Arbeitsprozesse steigern und somit den Personalbedarf reduzie-
ren (ebd., S. 446). In die gleiche Richtung geht auch die zunehmende Nutzung von Software-Tools
(Athreye 2005a, S. 34). Diese können einerseits helfen, Arbeitsprozesse durch computergestützte
Prozeduren zu effektivieren, andererseits bieten sie ein Automatisierungspotential (wie z.B. bei
automatisierten Testverfahren), welches den Bedarf an Arbeitskraft in der Produktion zusätzlich
reduziert.

Doch die Einführung der standardisierten Prozessmodelle bietet nicht nur die Möglichkeit, den
Personalbedarf zu reduzieren und so Lohnkosten zu sparen, sie bilden auch den zentralen Me-
chanismus, mit dem einige Unternehmen in Indien versuchen, mit den Folgen der hohen Perso-
nalfluktuation umzugehen. Dabei kann zwischen zwei grundsätzlichen Strategierichtungen unter-
schieden werden, die sich keineswegs immer gegenseitig ausschließen, sondern vielmehr teilweise
gut ergänzen können (vgl. auch Mayer-Ahuja und Feuerstein 2008).
Die Einführung standardisierter Prozessmodelle bildet dabei den zentralen Kern der einen Stra-
tegie, die darauf abzielt, die Arbeitsprozesse gegen hohe Fluktuationsraten möglichst weitgehend
zu immunisieren, indem die Arbeitsprozesse möglichst unabhängig von den beteiligten Perso-
nen gemacht werden sollen. Denn mit den Prozessmodellen einher gehen Bemühungen, das Aus-
maß der Dokumentation der Arbeitsschritte zu erhöhen und den Arbeitsprozess zunehmend eng
und detailliert zu überwachen. Die negativen Folgen einer Kündigung für die Unternehmen (in
Form des Verlusts von individuellem und Erfahrungswissen der Beschäftigten) sollen so möglichst
gering gehalten werden (Athreye 2005b, Arora u. a. 2001, Prasad 1998). Hier wird der Arbeits-
kräftemangel also zu einem eigenständigen Motiv für die Industrialisierungsbemühungen der IT-
Unternehmen in Indien: in der Absicht, das Unternehmen und die laufenden Projekte gegen die
hohen Fluktuationsraten zu immunisieren, treiben Unternehmen die Standardisierung und For-
malisierung ihrer Arbeitsprozesse voran.
Doch selbst wenn die Abhängigkeit von einzelnen Beschäftigten durch formalisierte und stan-
dardisierte Prozessmodelle reduziert werden kann – gänzlich abgeschafft werden kann sie nicht
(vgl. zu einer ähnlichen Einschätzung Arora u. a. 2001). Gerade in höheren Managementpositio-
nen und bestimmten technischen Spezialisierungsrichtungen bestehen Abhängigkeiten in hohem
11
Gemeint ist die Zunahme der Aufmerksamkeit, die der Qualitätssicherung bei Softwareentwicklung in Form von
standardisierten Prozessmodellen und Evaluationen geschenkt wird. Dies beinhaltete zunächst vor allem eine Zer-
tifizierung nach dem ISO-Standard 9001, später gesellten sich weitere Zertifizierungen wie CMMI oder auch Six
Sigma dazu.
42 Indien als Offshore-Standort

Maße fort und Unternehmen sind weiter von Fluktuation bedroht. Demnach findet sich neben
dem Versuch, die Arbeitsprozesse gegen Fluktuation zu immunisieren, auch eine Strategie, die
darauf abzielt, Fluktuation zu reduzieren.
Diese Strategie besteht in der Gewährung besonderer Anreize – nicht nur finanzieller Natur –
für die Beschäftigten, in der Firma zu bleiben.
Dazu zählen zunächst finanzielle Anreize, wie z.B. stark ansteigende Gehälter in Abhängigkeit
von Betriebszugehörigkeit, Sonderzulagen oder Aktienateile am Unternehmen (Arora u. a. 2001).
Darüberhinaus ist allerdings auch die Eröffnung attraktiver Karrierewege im Unternehmen ein
wesentlicher Anreiz für die Beschäftigten, im Unternehmen zu bleiben (Athreye 2005a, Arora
u. a. 2001). Der Nachteil ist, dass schnelle Beförderungen und steile Karrieren in der Folge von
den Beschäftigten geradezu „erwartet“ werden und sie bei Ausbleiben einer Beförderung die Firma
auch verlassen. Dadurch werden die Firmen förmlich gezwungen, regelmäßig und in teilweise sehr
kurzen Zeitabständen zu befördern (vgl. ebd., Upadhya und Vasavi 2006, Abraham und Sharma
2005). In den multinationalen Unternehmen, gerade auch im deutschen Unternehmen des Unter-
suchungssamples dieser Studie, stößt diese Form der Beförderungen auf gänzlich andere Praktiken
aus den Heimregionen der Unternehmen und wird von diesen Unternehmen daher nur langsam
adaptiert (vgl. auch Arora u. a. 2001).
Der letzte Anreiz, der an dieser Stelle hervorgehoben werden soll, besteht letztendlich auch im
Angebot interessanter Arbeit. Lacity, Rudramuniyaiah und Iyer (2008) zeigen in ihrer Studie zu
den Fluktuationsraten in der indischen IT-Industrie, dass die Suche nach einer befriedigenden Tä-
tigkeit ein ganz wesentlicher Faktor bei der Entscheidung der Beschäftigten ist, ein Unternehmen
zu verlassen oder in einem zu verweilen. Dies betrifft zum einen natürlich die Art der Tätigkeiten,
welche die Beschäftigten in Indien ausführen sollen. Gerade im Zusammenhang mit verlagerten
Tätigkeiten und Kooperationen in transnatioalen Projektteams bildet zum anderen aber auch die
Möglichkeit, am Standort des Kunden oder des Mutterhauses arbeiten zu können, eine arbeitsin-
haltliche Herausforderung und damit einen guten Anreiz für die Beschäftigten, länger im Unter-
nehmen zu bleiben (vgl. auch Arora u. a. 2001).
Es wurde oben argumentiert, dass sich die beiden Strategierichtungen des Umgangs mit Fluk-
tuation – Immunisierung und Reduzierung – nicht notwendigerweise widersprechen, sondern sich
teilweise auch ergänzen können. So kann ein stark standardisierter Arbeitsprozess, der die Abhän-
gigkeit von den einzelnen Beschäftigten stark reduziert, durchaus mit einem finanziellen Anreiz-
system koexistieren, das ein längeres Verweilen der Beschäftigten im Betrieb durch in Abhängigkeit
von der Betriebszugehörigkeit stark steigende Gehälter fördern soll. Gerade an der Gewährung
interessanter Arbeit zeigen sich jedoch auch die Grenzen der Vereinbarkeit beider Strategierich-
tungen. So resultiert die Standardisierung und Formalisierung der Arbeitsprozesse im Zuge der
Immunisierung gegen Fluktuation ja gerade darin, die Arbeitsaufgaben zu verkleinern und inter-
personell austausch- und wiederholbar zu machen, was häufig mit der Reduzierung der Attrakti-
vität der Arbeitsaufgaben einhergeht. An dieser Stelle besteht also ein Widerspruch zwischen den
beiden Strategierichtungen, und Unternehmen können unterschiedliche Entscheidungen treffen.

Die verschiedenen Ansatzpunkte, mit den hohen Gehaltssteigerungen und Fluktuationsraten

am indischen Standort organisatorisch umzugehen, begründen somit ein weites Spektrum mögli-
cher betrieblicher Strategien. Dementsprechend kann aus der Situation auf dem Arbeitsmarkt auch
keine gleichförmige Wirkung auf die Formen der betrieblichen Arbeitsorganisation und -kontrolle
abgeleitet werden. Vielmehr muss berücksichtigt werden, dass Unternehmen in unterschiedlicher
Weise versuchen können, mit den strukturellen Herausforderungen des indischen Arbeitsmarktes
organisatorisch umzugehen.
Indischer Arbeitsmarkt und Reorganisationsmodi 43

Wie sich bei den im Rahmen dieser Studie untersuchten IT-Unternehmen noch genauer zeigen
wird, sind es die unterschiedlichen Geschäfts- und Verlagerungsmodelle der Unternehmen, die
einen wesentlichen Einfluß darauf haben, wie stark die Unternehmen von den Eigenheiten des
indischen Arbeitsmarktes betroffen sind, und wie sie sich in Bezug auf diese Herausforderungen
verhalten und welcher Strategie des Umgangs sie dabei folgen. Es wird sich zeigen lassen, dass sich
in Abhängigkeit von den zugrundliegenden Verlagerungsmodellen ganz unterschiedliche Formen
herausbilden, mit dem indischen Arbeitsmarkt umzugehen, und dass der indische Arbeitsmarkt,
auf dem beide Unternehmen gleichermaßen operieren, damit unterschiedliche organisatorische
Umgangsformen zulässt.
44 Indien als Offshore-Standort
4 Reorganisationsmodi: Varianten
betrieblicher Arbeitsprozesskontrolle
Die zentrale Hypothese dieser Studie besagt, dass sich in der IT-Industrie im Zuge ihrer Inter-
nationalisierung weniger eindeutige und gleichförmige Industrialisierungstendenzen als vielmehr
unterschiedliche Reorganisationsmodi identifizieren lassen, die auf der einen Seite von unterschied-
lichen Internationalisierungswegen und auf der anderen Seite von den Arbeitsmarktbedingungen
der Offshore-Standorte geprägt sind. Untersucht werden sollen die unterschiedlichen Reorganisa-
tionsmodi in ihrem Einfluß auf die in ihnen jeweils enthaltene Form der Kontrolle von Arbeit.
In den vorausgehenden Kapiteln wurden die beiden in dieser Studie berücksichtigten Interna-
tionalisierungswege (Offshore-Outsourcing und Captive-Offshoring), sowie die besonderen Ar-
beitsmarktbedingungen des indischen IT-Standortes, näher erläutert. Das folgende Kapitel wird
nun bestimmen, mit welchem Analysekonzept und in welchen Dimensionen die Unterschiede der
betrieblichen Kontrolle zwischen den beiden Untersuchungsfällen untersucht werden sollen.

Als Anforderung an das gesuchte Analysekonzept lassen sich zwei zentrale Aspekte formulieren:

– Das Analysekonzept muss erstens in der Lage sein, die Veränderungen in der Form der be-
trieblichen Kontrolle im Zuge der Industrialisierung von IT-Arbeit angemessen fassen zu
können.

– Darüber hinaus muss es das Analyskonzept zweitens ermöglichen, die erwarteten unter-
schiedlichen Reorganisationsmodi als unterschiedliche Ausprägungen und Mischungsverhält-
nisse derselben Dimensionen von Arbeitskontrolle zu fassen und zu interpretieren.

Wie in den folgenden Unterkapiteln argumentiert werden soll, bietet ein von Andrew Friedman
(1977) in der „Labour Process Debate“ vorgeschlagenes Konzept zur Untersuchung betrieblicher
Formen von Arbeitskontrolle genau diese Möglichkeiten und wird daher den folgenden Ausfüh-
rungen zugrunde gelegt.

4.1 IT-Industrialisierung: ein grundlegender Strategiewechsel

Wie bereits in der Einleitung angedeutet, kann die von den Vertretern der Industrialisierungsthese
erwartete Industrialisierung von IT-Arbeit im Zuge ihrer zunehmenden Internationalisierung als
ein wesentlicher Umbruch in der Form der Kontrolle von IT-Arbeit gefasst werden.
Einen gewinnbringenden Zugang zu dem damit angerissenen Problemkomplex betrieblicher
Formen der Kontrolle von Arbeit bietet nach wie vor das von Braverman (1980) unter Bezug auf
Marx als Auftakt der „Labour Process Debate“ herausgearbeitete Transformationsproblem1 .
1
Die „Labour Process Debate“ entfaltete anfänglich vor allem im angelsächsischen Raum Wirkung. Mittlerweile haben
aber die zentralen Einsichten dieser Debatte auch Eingang in weitere Bereiche und auch in die deutsche Debatte
gefunden, so dass das Transformationsproblem mittlerweile quasi arbeitssoziologisches Lehrbuchwissen darstellt
(vgl. auch Deutschmann 2002).

45
46 Reorganisationsmodi

Mit dem Transformationsproblem wird ein Grundproblem des kapitalistischen Arbeitsprozes-

ses angesprochen: Wenn Unternehmen Arbeitskräfte rekrutieren und einstellen, ist keineswegs
sichergestellt, dass deren Gebrauchswert – die von den Beschäftigten zu leistende lebendige Arbeit
– durch das Unternehmen in der gewünschten Intensität und Qualität auch genutzt werden kann.
Das Unternehmen kauft Arbeitskraft, die Arbeit ist zu diesem Zeitpunkt noch reine Potentiali-
tät, das Unternehmen muss die Beschäftigten wirklich arbeiten lassen, um den Gebrauchswert der
Ware Arbeitskraft zu nutzen. Dabei obliegt die Form der Nutzung der gekauften Ware dem Unter-
nehmen, d.h. es wird versuchen, den Gebrauchswert, den es aus der gekauften Ware ziehen kann,
zu maximieren. Konkret heißt das, die Arbeit der Beschäftigten in quantitativer (Arbeitszeit) und
qualitativer Hinsicht (Arbeitsintensität), so weit wie möglich über den Punkt hinaus zu verlän-
gern, an dem der Arbeitende das Äquivalent seiner eigenen Reproduktionskosten geschaffen hat.
Dies tut das Unternehmen, indem es die Umstände der Produktion, die seiner Verfügung unterlie-
gen, v.a. technisch-organisatorisch zu beeinflussen versucht (vgl. u.a. Braverman 1980; Deutschmann
2002; Thompson 1989; Voß und Pongratz 1998). Dem Management erwächst aus diesem Grund-
sachverhalt kapitalistischer Arbeit ein genereller Kontrollimperativ (vgl. Thompson 1989), d.h. auf
die eine oder andere Weise muss das Management die Transformation von Arbeitskraft in lebendi-
ge Arbeit bewerkstelligen.
Entgegen der Annahme Bravermans wird heute davon ausgegangen, dass die Form, in der dieser
Kontrollimperativ vom jeweiligen Management konkret umgesetzt wird, keinesfalls determiniert
ist2 , sondern dass sich in verschiedenen Branchen – mit verschiedenen Arten von Arbeit – und
sogar innerhalb ein und desselben Unternehmens unterschiedliche Formen der Arbeitskontrolle
identifizieren lassen.

Die IT-Industrie mit ihren kreativen und wissensbasierten Tätigkeiten, stand dabei in den letz-
ten Jahren im Zentrum der Debatte über „neue Formen“ von Arbeit, die (je nach Autor) im Über-
gang der Industriegesellschaft zur Wissens- oder Informationsgesellschaft an Bedeutung gewinnen.
Kennzeichen dieser neuen Art von Arbeit sei die Abkehr von Formen technisch-bürokratischer
Kontrolle des Arbeitsprozesses, die als überkommene Formen des tayloristisch-fordistischen In-
dustriezeitalters angesehen wurden. IT-Arbeit hingegen – so wurde generell konstatiert – bedürfe
spezieller, wesentlich anderer Kontrollformen (u.a. Töpsch, Menez und Malanowski 2001; Hei-
denreich und Töpsch 1998; Voß und Pongratz 1998; Willke 1998).
Aufgrund der „Stofflichkeit“ der Arbeit, ihres kreativen und innovativen Charakters, sei es für
Manager von [Link] wesentlich schwerer, klar definierte Arbeitspakete zu schneiden, die in der
Folge dann eng überwacht abgearbeitet werden könnten. Vielmehr zeichneten sich Aufgaben in
der IT-Industrie durch eine hohe Komplexität und damit einhergehend hohe qualifikatorische An-
forderungen aus. Probleme und Schwierigkeiten der Aufgabenbewältigung zeichneten sich meist
erst im Verlauf ab, Lösungen könnten daher schwerlich im voraus verbindlich bereitgestellt wer-
den. Daher – so wurde argumentiert – seien die Beschäftigten gefordert, auf solche Probleme mög-
lichst eigenverantwortlich und schnell zu reagieren und selbständig eine entsprechende Lösung zu
finden (vgl. Voß und Pongratz 1998).
Solch gewünschtes Verhalten muss organisatorisch unterstützt werden, da angenommen wurde,
dass eine „herkömmliche, auf Funktionsspezialisierung und Aufgabenteilung, Kompetenzabgren-
zung und Einzelentscheidung beruhende hierarchische Organisationsform [...] für komplexe Auf-
2
Braverman ging zu Beginn der Labour Process Debate noch von einem quasi naturwüchsigen Zusammenhang zwi-
schen kapitalistischem Arbeitsprozess und tayloristischer Form der Arbeitskontrolle aus. Im Laufe der Debatte
wurde gerade dieser Zusammenhang zunehmend kritisiert und durch eine differenziertere Konzeption ersetzt (für
einen guten Überblick, siehe Thompson 1989).
Managementstrategien 47

gabenstellungen und Entscheidungsmaterien immer weniger geeignet“ sei (Kalkowski und Mickler
2009, S.9). Als dominante Organisationsform habe sich daher bei IT-Firmen3 die Form von Pro-
jektteams durchgesetzt, böten diese doch „grundsätzlich flache Hierarchien und ein[en] locker[en]
Umgangston auch mit Vorgesetzten, Ganzheitlichkeit, kollegiale Zusammenarbeit jenseits büro-
kratischer Vorschriften, Autonomie sowie Lern- und Entwicklungsmöglichkeiten“ (ebd., S.11).
Die organisatorische Form des Projektes unterstütze damit teamförmiges Arbeiten und gewähre
den Beschäftigten hohe Selbstorganisationsmöglichkeiten, um komplexe Probleme zu bearbeiten.
Kurzum, die Kontrolle von IT-Arbeit wurde in der arbeitssoziologischen Forschung geradezu als
Prototyp für Formen „indirekter“ Kontrolle angesehen. Daran änderten auch vereinzelte Studien
nichts, die das Fortbestehen von direkter Kontrolle auch bei IT-Arbeit demonstrierten (vgl. z.B.
Kraft und Dubnoff 1986; Kraft 1979; Barrett 2005; Prasad 1998; Friedman 1990a; Friedman 1992;
Mayer-Ahuja und Wolf 2005).

Mit dem Einsetzen der räumlichen Verlagerung von IT-Arbeit scheint sich nun die Realität in
der IT-Industrie stark zu verändern. Das zugrundliegende Transformationsproblem wird im Zuge
der Internationalisierung, so die Erwartung vieler Autoren, im Sinne einer Industrialisierung von
IT-Arbeit zu lösen versucht – es finde also ein grundsätzlich anderer technisch-organisatorischer
Zugriff auf die Arbeitsleistung der Beschäftigten statt.
So wird erwartet, dass die vormals ganzheitlichen Aufgabenprofile der Entwickler zugunsten
stärker (global) arbeitsteiliger Profile ersetzt würden. Die Folge seien Tätigkeitsprofile für Entwick-
ler, deren Arbeitsaufgaben einerseits kürzer terminiert und andererseits auch weniger komplex
sind, da sie engere und inhaltlich stärker auf Teilfunktionen spezialisiert seien. Mit dieser Frag-
mentierung der Tätigkeitsprofile und der Arbeitsaufgaben gehe dann in der Folge auch eine stär-
kere Durchdringung der Arbeitsprozesse mithilfe von zentralen Informationssystemen einher, die
eine detailliertere Messung der Arbeitsleistung der Beschäftigten und ein engeres Monitoring der
Arbeitsabläufe ermögliche (Kämpf 2008, S.27ff.). Dadurch würden die Beschäftigten einer detail-
lierteren und stärker formalisierten Form der Kontrolle unterworfen. Die aus anderen Branchen
bekannte bürokratische Beherrschung des Arbeitsprozesses in Form von standardisierten Prozess-
modellen mit genau definierten Schritten der Bearbeitung halte demnach auch zunehmend bei
IT-Arbeit Einzug. Schließlich werde damit auch die traditionelle Beschäftigungssicherheit von IT-
Beschäftigten untergraben, indem die Arbeitsprozesse durch die fortschreitende Standardisierung
und Formalisierung von den einzelnen Beschäftigten unabhängiger und die Beschäftigten damit
auch leichter ersetzbar würden. Damit verändere sich die Verhandlungsgrundlage zwischen Be-
schäftigten und Management, weil die neue Ersetzbarkeit vom Management genutzt werden kann,
um Zugeständnisse bei den Beschäftigungsverhältnissen durchzusetzen.

Der von den Vertretern der Industrialisierungsthese behauptete Wandel im organisatorisch-

technischen Zugriff auf die Arbeitsleistung der Beschäftigten (vgl. Voß und Pongratz 1998, S.137)
verläuft damit genau entlang jener Achse, deren Pole Friedman (1977) in seiner – inzwischen als
klassisch zu bezeichnenden – Konzeption als die beiden Strategietypen der „direkten Kontrolle“
und der „verantwortlichen Autonomie“ bezeichnet hat.

3
Natürlich betrifft dieser Trend nicht nur die IT-Industrie, doch wurde die IT-Industrie stets als Trendsetter dieser
Entwicklung angesehen, an deren Erfahrungen sich auch andere Branchen orientieren würden.
48 Reorganisationsmodi

4.2 Managementstrategien zwischen „verantwortlicher Autonomie“

und „direkter Kontrolle“
Die Unterscheidung zwischen den beiden Strategierichtungen geht auf die speziellen Eigenschaften
der Ware Arbeitskraft zurück. Nach Friedman unterscheidet sich die Ware Arbeitskraft von den
anderen vom Management eingekauften Produktionsfaktoren vor allem durch zwei wesentliche
Eigenschaften:

„Zum einen sind die Arbeiter besonders anpassungsfähig: Wenn sie erstmal eingestellt
sind, dann können sie zu Tätigkeiten veranlaßt werden, die über das hinausgehen, was
ursprünglich im Arbeitsvertrag festgelegt worden ist. Zum anderen wird ihr Verhal-
ten letztlich von einem unabhängigen und oftmals eigensinnigen Willen bestimmt.“
(Friedman 1987, S. 100)

Die Beziehung zwischen Kapital und Arbeit ist in dieser Fassung also eine höchst widersprüch-
liche:

„Es besteht immer eine grundsätzliche Spannung zwischen der Notwendigkeit, Ko-
operation oder Zustimmung von denen, die die Arbeit machen, zu erlangen und der
Notwendigkeit, sie zu Dingen zu zwingen, die sie nicht tun wollen und sie auf eine
Art und Weise zu behandeln, die gegen ihre eigenen Interessen verstößt, damit die
Ziele von denen, die den Arbeitsprozess beherrschen, erreicht werden.“ (ebd., S. 108)

Das Ziel des Managements, möglichst effizient das Arbeitsvermögen in Arbeit zu transformie-
ren, kann nach Friedman daher im Extremfall auf zwei Wegen erreicht werden.
Entweder die Anpassungsfähigkeit der Arbeitenden wird genutzt, indem versucht wird, deren
Loyalität und freiwillige Leistungsbereitschaft durch Übertragung von Verantwortung und Selbst-
steuerungsmöglichkeiten zu gewinnen. Diese Strategierichtung beinhaltet die Gewährung von ver-
antwortlicher Autonomie. Ergebnis ist

„the maintenance of managerial authority by getting workers to identify with the com-
petitive aims of the enterprise so that they will act responsibly with a minimum of
supervision“ (Friedman 1977, S. 48).

Unschwer lassen sich die Parallelen zwischen Kontrollstrategien nach dem Muster der „verant-
wortlichen Autonomie“ und dem erkennen, was traditionell über die Form der Kontrolle von
IT-Arbeit vertreten wird (vgl. u.a. Boes 2004; Kämpf 2008).
Die zentralen Veränderungen in der Form der Kontrolle, die von den Vertretern der Industriali-
sierungsthese im Zuge der Internationalisierung der IT-Industrie für die Arbeitsprozesse erwartet
werden, bewegen sich hingegen eher in eine Richtung, die Friedman Strategien der „direkten Kon-
trolle“ nennt.
Strategietypen der direkten Kontrolle finden sich beispielhaft in den tayloristischen Formen der
Arbeitszerlegung und -kontrolle. Diese Strategie richtet sich eher gegen die Eigensinnigkeit der
Arbeitenden und versucht,

„das Maß der Verantwortlichkeit jedes Einzelnen durch strenge Überwachung zu re-
duzieren. Man bestimmt im voraus und bis ins kleinste Detail die spezifischen Aufga-
ben, die einzelne Arbeiter zu erledigen haben“ (Friedman 1987, S. 100).
Betriebliche Kontrolle: zur strategischen Gestaltung von Aktivitätsfeldern 49

Das entscheidende Merkmal, das die beiden Strategierichtungen der „direkten Kontrolle“ und
der „verantwortlichen Autonomie“ unterscheidet, ist also der Handlungs- und Verantwortungs-
spielraum, der den einzelnen Beschäftigten bei der Verrichtung ihrer Arbeitsaufgaben eingeräumt
wird. Wird bei Strategien direkter Kontrolle versucht, den individuellen Handlungsspielraum mög-
lichst gering zu halten, wird das individuelle Handeln im Arbeitsprozeß dabei geradezu als Ri-
siko und unerwünschte Quelle potentieller Störungen betrachtet, so wird bei Strategien der Ge-
währung von verantwortlicher Autonomie versucht, das explizit erwünschte eigenverantwortliche
Handeln in den Dienst des Unternehmens zu stellen, indem mithilfe unterschiedlichster Maßnah-
men an die Loyalität des Einzelnen appelliert wird.
Aufgrund der Bedeutung individueller Handlungsspielräume sollen in dieser Studie Strategien,
die dem Muster der direkten Kontrolle folgen, auch restriktive Kontrollstrategien genannt werden,
weil sie individuelle Handlungs- und Entscheidungsspielräume einschränken. Kontrollstrategien,
die eher dem Muster der Gewährung von verantwortlicher Autonomie folgen, sollen dagegen als
permissive Kontrollstrategien bezeichnet werden, weil sie diese Spielräume erhalten, bzw. danach
trachten, sie zu erweitern.

Für die vorliegende Studie ist diese begriffliche Differenzierung vor allem deshalb von beson-
derer Bedeutung, weil Friedman sie eher als zwei Pole eines Kontinuums, denn als unverbundene
Alternativen zueinander versteht (vgl. Friedman 1990b). So wird eine betriebliche Kontrollstrate-
gie immer Mischungsverhältnisse restriktiv und permissiv wirkender Elemente enthalten und die
strategische Orientierung kann in unterschiedlichen Bereichen, Abteilungen und Beschäftigten-
gruppen des Unternehmens durchaus variieren (vgl. Deutschmann 2002, S. 118). So verstanden,
bilden die beiden Strategietypen eher zwei Richtungen,

„in die sich Manager bewegen können und nicht [...] zwei vordefinierte Strategien,
zwischen denen Manager wählen“ (Friedman 1987, S.101).

Diese Einschränkung ist insofern wichtig, als sie es nicht nur gestattet, den Ausgangs- und
Fluchtpunkt der Veränderungen in Formen der Kontrolle von IT-Arbeit im Zuge ihrer Indus-
trialisierung zu bestimmen, sondern auch unterschiedliche Reorganisationsmodi, wie sie in dieser
Studie im Zentrum der Aufmerksamkeit stehen sollen, als unterschiedliche Positionen innerhalb
dieses – mit den beiden Strategierichtungen als Pole bgrenzten – Kontinuums zu interpretieren.
Ein Wandel der Kontrollformen erscheint so als eine Bewegung zwischen diesen Polen, und die
unterschiedlichen Reorganisationsmodi der IT-Industrie können als eine je spezifische Zunahme
restriktiver Formen der Kontrolle interpretiert werden.

4.3 Betriebliche Kontrolle: zur strategischen Gestaltung von

Aktivitätsfeldern
Um die unterschiedlichen Reorganisationsmodi in der IT-Industrie und deren Folgen für die For-
men der Kontrolle miteinander vergleichen und interpretieren zu können, müssen diese als Kombi-
nation unterschiedlicher Ausprägungen von bestimmten Dimensionen von Kontrolle fassbar sein.
Auch hierbei stellt der Ansatz Friedmans einen nützlichen Untersuchungsrahmen bereit. Der
Grundgedanke der Friedmanschen Konzeption zur Bestimmung der in einem Unternehmen ver-
folgten Kontrollstrategie besteht darin, dass die grundsätzliche Unterscheidung zwischen den Kon-
trollstrategien „verantwortliche Autonomie“ und „direkte Kontrolle“ sich an bestimmten strate-
gischen Aktivitäten des Managements in unterschiedlichen Dimensionen der Arbeitsorganisation
50 Reorganisationsmodi

– sogen. Aktivitätsfeldern – festmachen lasse. Vier zentrale Aktivitätsfelder stellen demnach die
zentralen Dimensionen zur Bestimmung der Form der Arbeitskontrolle dar. Sie dienen auch in
dieser Studie als zentrale Untersuchungsdimensionen:

– Aufgabenorganisation

– Kontrollstruktur

– Kooperationsbeziehungen

– Interne und externe Arbeitsmärkte

In jedem Aktivitätsfeld bündeln sich bestimmte Aktivitäten des Managements. Für welche stra-
tegische Orientierung die eine oder andere Art der Ausführung der Managementaktivitäten schließ-
lich spricht, kann über die Ausprägungen der sogen. strategischen Dimensionen jedes Feldes be-
stimmt werden. Zusammen betrachtet, geben sie Aufschluß über die strategische Orientierung des
Managements in jedem dieser Aktivitätsfelder.
Im folgenden sollen kurz die Aktivitätsfelder, die darin gebündelten Aktivitäten sowie deren
strategische Dimensionen näher beschrieben werden. Eine Übersicht gibt die Tabelle 4.1 (S. 50).

Abbildung 4.1: Managementstrategien, Aktivitätsfelder und strategische Dimensionen (leicht

verändert nach Friedman 1990b, S.189)

4.3.1 Aufgabenorganisation
Das Feld der Aufgabenorganisation beinhaltet die Aktivitäten des Managements, mit denen die
Gesamtaufgabe der Produktion in einzelne Arbeitsaufgaben der Beschäftigten heruntergebrochen
und in einen arbeitsteiligen Ablauf integriert wird.
Genauer berücksichtigt werden dabei die Art und Weise, in der Arbeitsaufträge erteilt werden,
die Arbeitsmethoden, die Zeitplanung der Produktion, die Strukturen der Organisation, sowie die
zur Verfügung stehenden Werkzeuge und Maschinen (Friedman 1987, S. 112).
Mit der „Art der Auftragserteilung“ wird gefasst, wie in einem Unternehmen die Aufgaben
für die Beschäftigten – im Fall dieser Studie also der Softwareentwickler – definiert und verteilt
Strategische Gestaltung von Aktivitätsfeldern 51

werden. Dies kann durchaus variieren. So können sich Unternehmen, bzw. die Ansätze des Ma-
nagements dahingehend unterscheiden, wieviel Mitsprachemöglichkeiten die Beschäftigten bei der
Definition der Arbeitsaufgaben haben, welchen Umfang und Komplexitätsgrad die verteilten Auf-
gaben haben und ob die Arbeitsaufgaben an eine Gruppe von Personen vergeben oder einzeln
zugewiesen werden. Wichtig ist dabei auch, wie weitreichend die Arbeitsaufgaben vorspezifiziert
sind, da dieser Punkt entscheidend darüber bestimmt, inwiefern die Beschäftigten eigene Problem-
lösungskompetenzen einbringen müssen bzw. können.
Die „Arbeitsmethoden“ in der Produktion beziehen sich auf die realen Arbeitsabläufe im Be-
trieb, also auf die Frage wie z.B. im Falle der Softwareentwicklung eine Spezifikation für ein
Softwareprogramm in ein lauffähiges Programm umgesetzt wird. Angesprochen sind damit die
unterschiedlichen im Arbeitsprozess involvierten Rollen und deren Form der Zusammenarbeit.
Interessant sind in dieser Hinsicht aber auch Fragen der Gestaltung der Arbeitsplätze und -zeiten,
soweit sich diese auf die Art der Aufgabenbearbeitung der Entwickler auswirken.
Mit den Aktivitäten hinsichtlich der „Zeitplanung und Organisationsstrukturen“ wird die for-
male Seite der Aufgabenbearbeitung abgedeckt. Hier werden die Strukturen des Unternehmens
und der Teams berücksichtigt: Wie sind die Projekte aufgebaut, wieviele Hierarchiestufen gibt es
und welche Tätigkeitsprofile sind damit verbunden? Selbstverständlich gehört auch die zeitliche
Planung der Arbeitsprozesse in diese Kategorie, im Falle dieser Studie also Fragen, wie z.B. die
einzelnen Phasen der Softwareentwicklung zeitlich geregelt sind. Gerade auch im Hinblick auf die
Untersuchung der Arbeitskontrolle beim indischen IT-Dienstleister sind an diesem Punkt die zeit-
lichen Vereinbarungen, die zwischen Dienstleister und Kunde in Bezug auf die Arbeitsaufgaben
getroffen werden, von entscheidender Bedeutung.
Schließlich hängt die Gestaltung der Arbeitsaufgaben auch an den vorhandenen „Werkzeugen
und Maschinen“. Dieser Aspekt verweist auf die im Arbeitsprozess genutzten technologischen
und maschinellen Grundlagen, hier also die vorfindlichen informationstechnischen Infrastruktu-
ren, wie z.B. die von den Entwicklern zu nutzenden Programmierumgebungen und sonstigen
technischen Hilfsmittel (Zentrale Datenbanken, computergestütztes Wissensmanagement, Kom-
munikationsmedien, etc.).

Alle genannten Aktivitäten dieses Feldes bestimmen demnach auf die eine oder andere Weise
über die Formen der Arbeitsaufgaben der Beschäftigten und die Art und Weise, in der diese von
jenen bearbeitet werden. Um die Aktivitäten im Hinblick auf die verfolgte Strategie des Manage-
ments zu interpretieren, werden die Aktivitäten des Managements auf die Ausprägungen der stra-
tegischen Diemensionen dieses Feldes bezogen. Als strategische Dimensionen des Feldes der Aufga-
benorganisation werden bei Friedman die drei Dimensionen Aufgabenlänge, Aufgabenvielfalt und
die kreativen Anforderungen der Arbeitsaufgaben berücksichtigt (ebd., S.115). „Kreativ“ meint in
diesem Zusammenhang, dass eine Arbeitsaufgabe von den Beschäftigten eigene Problemlösungs-
kompetenzen erfordert, weil die Aufgabenstellung neu ist und/oder (noch) keine Vorgaben für
deren Erledigung existieren, so dass Probleme selbständig gelöst werden müssen.
In diesem begrifflichen Rahmen gefasst, wird erwartet, dass sich Strategien der „direkten Kon-
trolle“ und Strategien, die eher dem Leitbild „der verantwortlichen Autonomie“ folgen, in diesen
strategischen Dimensionen unterschiedlich darstellen. So sollte eine Kontrollstrategie, die eher in
Richtung „direkte Kontrolle“ tendiert, eher routinisierte, wiederkehrende und kurztaktige Ar-
beitsaufgaben präferieren, die den einzelnen Beschäftigten wenig kreative Anforderungen abver-
langen. Eine Strategie der „verantwortlichen Autonomie“ hingegen sollte eher auf die individuel-
len Lösungsfähigkeiten der Beschäftigten abzielen und ihnen daher Zeit und Handlungsspielräume
bei der Bearbeitung einräumen, die sich dann in grob spezifizierten und langfristig terminierten
52 Reorganisationsmodi

Arbeitspaketen niederschlagen sollten, die von hohen kreativen Ansprüchen gekennzeichnet sind.

4.3.2 Kontrollstruktur
Das zweite Aktivitätsfeld – Kontrollstruktur – bezeichnet einen Kernbereich der vom Management
verfolgten Strategien.
Um an dieser Stelle begriffliche Verwirrung zu vermeiden, muss eine Anmerkung zur Verwen-
dung des Kontrollbegriffes bei Friedman gemacht werden. So wird der Begriff in der vorgestell-
ten Konzeption doppelt verwandt: Einerseits soll die Strategie der betrieblichen Kontrolle über
die Analyse von Aktivitätsfeldern bestimmt werden, wobei andererseits die „Kontrollstruktur“
gleichzeitig ein eigenes Aktivitätsfeld bezeichnet. Die Verwirrung resultiert aus einer doppelten
Bedeutung des Begriffs der Kontrolle, der für die Labour Process Theory (LPT) generell typisch
ist. So unterscheidet auch Thompson (1989) zwischen „general“ und „immediate control“ über Ar-
beitsprozesse. Auf der einen Seite bezieht sich der Begriff der Kontrolle auf den generellen Kontrol-
limperativ, der aus den spezifischen Bedingungen des kapitalistischen Arbeitsprozesses entsteht,
und beinhaltet, dass das Management auf die eine oder andere Weise den Arbeitsprozess beherr-
schen und gestalten muss (vgl. auch Voß und Pongratz 1998). Auf der anderen Seite („immediate
control“) soll mit dem Begriff der Kontrollstruktur jedoch auch die konkrete Involviertheit des
Managements in den Arbeitsablauf angesprochen werden. So gefasst, bedeuten auch permissive
Kontrollstrategien eine generelle Kontrolle des Arbeitsprozesses durch das Management, diese ist
lediglich im Arbeitsprozess weniger präsent. Denn die Implementierung dieser Form der Aufga-
benorganisation ist ja ihrerseits Ergebnis gestaltender Maßnahmen des Managements. Das Akti-
vitätsfeld der Kontrollstruktur bezieht sich folglich auf diesen konkreten Aspekt der Kontrolle im
Arbeitsprozess.

Im Feld der Kontrollstruktur werden unterschiedliche Ebenen und Phasen der Kontrolle unter-
schieden.
Die drei Ebenen der Kontrollstruktur sind Anleitung und Anweisung, Überwachung und Eva-
luation von Arbeitsschritten (Friedman 1987, S.116). Auch wenn für gewöhnlich alle 3 Ebenen
vom Management strategisch bearbeitet werden, lassen sich doch auch Unterschiede in der Schwer-
punktsetzung ausmachen. Wenn ein Unternehmen z.B. den Schwerpunkt auf die möglichst detail-
lierte Anleitung und Anweisung der Beschäftigten legt, kann damit ein weniger straffes Überwa-
chungssystem ausgeglichen werden. Umgekehrt kann eine enge Überwachung des Prozesses auch
hohen Aufwand bei der Evaluation ersparen. Dementsprechend können diese drei Ebenen der
Kontrolle auch substitutiv zueinander stehen.
Die Aktivitäten des Managements im Feld der Kontrollstruktur können sich jedoch nicht nur
auf unterschiedliche Ebenen, sondern zudem auf unterschiedliche Phasen des Kontrollzyklus rich-
ten. Unter Kontrollzyklus wird verstanden, dass jeder arbeitsteilige Arbeitsprozess grundsätzlich
aus den (wiederkehrenden) Phasen des Arbeitsbeginns, -prozesses und -ergebnisses besteht, die vom
Management auf den genannten Ebenen jeweils kontrolliert werden können.

Die strategischen Dimensionen des Feldes der Kontrollstruktur bestehen in der Dichte und Ge-
nauigkeit von Anweisung, Überwachung und Beurteilung. Diese Dimension zielt also schwer-
punktmäßig auf die Erfassung des Handlungsspielraums der Beschäftigten ab. Weitere strategische
Dimensionen sind der Formalisierungsgrad der Kontrolle, die Frage, ob vornehmlich Arbeitser-
gebnisse oder -prozesse überwacht werden, sowie die im Betrieb präferierte Anreizstruktur (vgl.
ebd., S.117).
Strategische Gestaltung von Aktivitätsfeldern 53

Für restriktive Kontrollstrategien wird erwartet, dass die Kontrollstruktur möglichst klein-
schrittige und detaillierte Anweisungen und engmaschige Überwachungsmechanismen beinhaltet,
sowie schwerpunktmäßig mit einer präzisen Überwachung der Arbeitsprozesse einhergeht. Die
präferierte Anreizstruktur besteht hier erwartungsgemäß im Bestrafen von Abweichungen vom
vorgegebenen Vorgehen4 .
Permissive Kontrollstrategien werden hingegen eher weniger detaillierte Vorgaben hinsichtlich
der Arbeitsaufgaben und auch eine ebenfalls weniger strikte Überwachung beinhalten, um die
Selbstorganisation und Initiative der Beschäftigten so wenig wie möglich zu hemmen. Statt des-
sen setzen permissive Kontrollstrategien, so die Erwartung, eher auf eine Überwachung der Ar-
beitsergebnisse am Ende der Arbeitsprozesse bzw. einzelner Abschnitte der Arbeitsabläufe. Ein
derartiger Ansatz setzt demnach eher bei den beteiligten Personen an, indem die individuell gezeig-
te Arbeitsleistung über die gelieferten Ergebnisse, z.B. in Form von Zielvereinbarungsgesprächen
und/oder regelmäßig stattfindenden Meilensteinen überwacht und gemessen wird. Um freiwillige
Leistungsbereitschaft und selbstständiges Arbeiten zu befördern, beinhalten die Anreizstrukturen
bei permissiven Kontrollstrategien idealer Weise primär positive Anreize, z.B. in Form von Bonus-
zahlungen bei besonderen Leistungen.

4.3.3 Kooperationsstrukturen
Das Aktivitätsfeld der Kooperationsstrukturen beinhaltet „die Förderung, die Behinderung und das
Organisieren der Kommunikation“ (ebd., S.120) zwischen verschiedenen Gruppen von Beschäf-
tigten.
Das verweist auf die Herstellung von Kern- und Randbelegschaften, die unterschiedlich kon-
trolliert werden, wobei die Existenz der einen Gruppe eine schärfere Kontrolle der anderen erst
ermöglicht. Zu denken ist an Konstellationen, in denen die eher nach verantwortlicher Autono-
mie kontrollierte Kernbelegschaft über die Existenz einer großen Randbelegschaft, die auf den
Kernbereich drängt, unter Druck gesetzt werden kann.
Für Friedman ist dieses Aktivitätsfeld demnach stark an die Aufrechterhaltung von betrieblicher
Herrschaft gekoppelt, und er untersucht es vor allem in Bezug auf möglichen Arbeiterwiderstand.
Dies ist zwar bei den hier untersuchten IT-Firmen – und vermutlich auch generell bei IT-Firmen
und IT-Beschäftigten aufgrund deren traditionell niedrigem gewerkschaftlichen oder sonstwie kol-
lektiven Organisierungsgrad – nicht so relevant, jedoch hat diese Dimension auch für die in dieser
Studie behandelte Fragestellung einigen Erklärungswert.
Dies betrifft etwa das Verhältnis, das die Firma zwischen den räumlich getrennten Teilen des
Projektteams (Onsite/Offshore) zu errichten bemüht ist: Lernen sich die Beschäftigten persönlich
kennen oder sind es eher knapp gehaltene, formalisierte Kontakte? Kommt es zu persönlichem
Austausch und wie nehmen sich die beiden Gruppen gegenseitig wahr? Da es sich bei Offshoring-
Konstellationen meist um Kooperationsstrukturen zwischen Hoch- und Niedriglohnstandorten
handelt, stellen die Standorte jeweils auch eine Gefahr füreinander dar. Bei NovoProd z.B. be-
schweren sich einige indische Beschäftigte, dass die deutschen Beschäftigten unwillig seien, ihre
Arbeit zu dokumentieren und ihr Wissen zu teilen, was zu schlechteren Ergebnissen auf indischer
Seite führe. Gleichzeitig haben die deutschen Beschäftigten Angst, dass bald auch ihr Arbeitsplatz
nach Indien verlagert wird. Da es sich in diesem Fall jedoch wirklich um ein transnationales Pro-
4
Es muss zum besseren Verständnis an dieser Stelle noch einmal erwähnt werden, dass es sich hier um sehr zugespitzte
Annahmen über Zusammenhänge handelt. So kann natürlich auch selbst in sehr eng überwachten Arbeitsformen,
wie der Fließbandarbeit auch mit positiven Leistungsanreizen gearbeitet werden, die dann entsprechend negative
Anreize ergänzen und ausgleichen.
54 Reorganisationsmodi

jektteam handelt, also beide Seite miteinander kooperieren müssen, stellen solche Konkurrenzver-
hältnisse eine Gefahr für das Gelingen der Projekte dar. Das Verhältnis, in das die beiden Standorte
zueinander gesetzt werden, hat demnach großen Einfluss auf die Form der Zusammenarbeit und
die Kooperationsbereitschaft der Beschäftigten. Es darf daher erwartet werden – und die empi-
rischen Ergebnisse stützen diese Vermutung – dass die Gestaltung der Kooperationsstrukturen
zwischen dem deutschen und dem indischen Teil eines Projektteams ein wichtiges Feld für Mana-
gementaktivitäten in unseren beiden Sampleunternehmen darstellt.
Doch auch über die reine Onsite-Offshore-Beziehung hinaus, ist die Art und Weise, in der das
jeweilige Management Kooperationsbeziehungen zwischen den Beschäftigten fördert oder auch
hemmt, von hohem Erkenntniswert.
Wie Kontrolle sich gestaltet, hängt nicht zuletzt davon ab, in welches Verhältnis die verschie-
denen Abteilungen und auch die einzelnen Beschäftigten eines Betriebes zueinander gesetzt wer-
den und wie intensiv die Kooperationsbeziehungen zwischen den Entwicklern eines Teams sind
– teamübergreifend und evtl. auch organisationsübergreifend (zu Beschäftigten bei Kunden- oder
Partnerfirmen).

Die strategischen Dimensionen des Feldes der Kooperationsstrukturen betreffen zum einen die
Intensität der Kommunikation und die Form derselben (technisch, persönlich), und zum anderen
die Art und Weise, in der Beschäftigtengruppen miteinander in Verhältnis gesetzt werden (koope-
rativ oder konkurrenzförmig).
Es wird erwartet, dass restriktive Kontrollstrategien auch aufgrund der typischen Formen der
Aufgabenorganisation weniger intensive Kommunikationsbeziehungen erfordern, als dies bei per-
missiven Strategien der Fall ist. Werden Arbeitspakete detailliert vorgeschrieben und eng über-
wacht, ist das Maß der zur Bearbeitung nötigen Kommunikation eingrenzbar. Zudem würde man
bei restriktiven Kontrollstrategien erwarten, dass die Kommunikation stark formalisiert und –
sofern realisierbar – auch technisch gestützt stattfindet.
Sind Arbeitspakete hingen weit spezifiziert und sind die Beschäftigten aufgerufen, eigene Lösun-
gen zu finden, sollte der Grad der Kommunikation zwischen Beschäftigten im Team oder auch in
anderen Abteilungen zunehmen, von denen Informationen eingezogen werden müssen und deren
Kooperation erwünscht oder nötig ist.
Für die vorliegende Studie sind diese strategischen Dimensionen zentral. Denn der Grad der
Kommunikation und die Form derselben sind, sowohl im Hinblick auf die Beziehung zwischen
einzelnen Abteilungen und Teams an einem Standort, als auch auf die Beziehung zwischen Stand-
orten, eine wichtige Dimension bei der Gestaltung der räumlich verteilter Projektteams. Gilt IT-
Arbeit gemeinhin als schwierig exakt vorzuschreiben und im Ablauf eng zu überwachen, so wer-
den gute Kommunikationsbeziehungen als wesentliche Voraussetzung der Arbeitsverausgabung
angesehen. Gerade diese wird durch die räumliche Verlagerung erschwert. Zum einen natürlich
ganz grundsätzlich durch die große Entfernung zwischen Standorten – zusätzlich erschwert durch
unterschiedliche Zeitzonen, die das gemeinsame „Zeitfenster“ für direkte Kommunikation verklei-
nern – aber zum anderen auch durch die oft beschworenen kulturellen Unterschiede zwischen Be-
schäftigtengruppen an weit entfernten Standorten. Die Steuerung der Kommunikation zwischen
den Standorten genießt demnach bei Verlagerungsprojekten hohe Priorität (vgl. z.B. BITKOM
2005).
Strategische Gestaltung von Aktivitätsfeldern 55

4.3.4 Arbeitsmarktbeziehungen
Das Aktivitätsfeld der internen und externen Arbeitsmarktbeziehungen schließlich betrifft das Ver-
hältnis des Betriebes sowohl zu den externen Arbeitsmärkten (von denen Beschäftigte rekrutiert
und auf die sie wieder entlassen werden), als auch zu den internen Arbeitsmärkten, die Friedman
als „Mechanismen innerhalb der Firma“ bezeichnet, „durch die den Arbeitern Positionen mit un-
terschiedlicher Bezahlung und Status zugewiesen werden“ (Friedman 1987, S. 118).
Die Aktivitäten des Managements lassen sich in diesem Feld in Rekrutierung, Aus- und Weiter-
bildung, Aufstieg und Freisetzung unterteilen (ebd., S. 118).
Erfasst wird also zunächst die Art und Weise, in der Unternehmen ihre Beschäftigten rekrutie-
ren. Hier können große Unterschiede dahingehend bestehen, nach welchen Kriterien die Unter-
nehmen vorgehen und welche Zielgruppe sie anpeilen. Gerade im Hinblick auf die in dieser Studie
untersuchten Betriebe im indischen Bangalore mit seinen umkämpften Arbeitskräften z.B. stellt
sich das Problem, an eine ausreichende Zahl gut qualifizierter Arbeitskräfte zu kommen.
Nach der Rekrutierung müssen Beschäftigte an das Unternehmen heran- und in die Arbeitspro-
zesse eingeführt werden. Dabei sind die Einarbeitungs- und in der Folge die Weiterbildungsak-
tivitäten von besonderer Bedeutung. Wie lange dauert es z.B., bis die neueingestellten Beschäf-
tigten selbständig im Betrieb arbeiten können und wie wird das nötige Wissen vermittelt? Hier
bestehen enge Verbindungen zum Bereich der Aufgabenorganisation, denn enge, klar spezifizierte
Arbeitsaufgaben werden voraussichtlich wesentlich weniger Einarbeitungszeit und qualifikatori-
sche Voraussetzungen erfordern, als weite, mehr den Problemlösungsfähigkeiten der Beschäftigten
überlassene Arbeitspakete.
Ebenfalls wichtig in diesem Feld sind die Karrierewege, die eng mit der Organisationsstruktur
des Betriebes zusammenhängen. Entscheidend sind hier neben der Zahl an Hierarchiestufen auch
die Beförderungsmodalitäten, also wer Einfluß auf etwaige Beförderunge hat und wie über solche
entschieden wird.
Der letzte Punkt betrifft schließlich den Umgang des Unternehmens mit Beschäftigten, die kün-
digen oder entlassen werden. Auch dies ist für die Untersuchung der indischen Betriebe aufgrund
der hohen Fluktuationsraten am indischen Standort enorm wichtig. Zentral sind in dieser Hin-
sicht die Aktivitäten des Unternehmens, um Personalfluktuation zu vermeiden und Beschäftigte
an das Unternehmen zu binden (vgl. dazu auch Mayer-Ahuja und Feuerstein 2008).

Im Feld der internen und externen Arbeitsmarktbeziehungen betreffen die strategischen Dimen-
sionen den Grad der Abhängigkeit des Betriebes von den Beschäftigten (bzw. bestimmten Beschäf-
tigtengruppen) und das Ausmaß, in dem ein Betrieb bestrebt ist, sie an das Unternehmen zu bin-
den.
Die Abhängigkeit verweist auf die mögliche Ersetzbarkeit von Personen (entsprechend deren
Qualifikationen und Erfahrung) und ist damit in hohem Maße von der verfolgten Aufgabenschnei-
dung und den daraus resultierenden Qualifikationsanforderungen, wie z.B. der Relevanz von be-
triebsspezifischem, bzw. Erfahrungswissen, abhängig.
Eine hohe Abhängigkeit der Arbeitsabläufe von bestimmten (wenn nicht allen) Beschäftigten
– wie dies für permissive Kontrollstrategien aufgrund der besonderen Form der Aufgabenschnei-
dung typisch ist – sollte dazu führen, dass die Bindung der Beschäftigten an den Betrieb für das
Management hohe Relevanz besitzt und dass in dieser Hinsicht bestimmte Maßnahmen ergriffen
werden müssen. Diese Maßnahmen können durchaus unterschiedlicher Art sein. Darunter würden
z.B. bestimmte Sicherheitsgarantien, aber auch finanzielle oder symbolische Sonderzuwendungen
fallen. Zentrales Feld für derlei Aktivitäten sind natürlich auch Fragen der Karrierewege und Be-
56 Reorganisationsmodi

förderungen in einem Unternehmen.

Eine Kontrollstrategie der direkten Kontrolle, die auf kleine Arbeitspakete ohne hohe kreati-
ve Anforderungen setzt, wird hingegen in geringerem Maße von bestimmten Beschäftigten oder
-gruppen abhängig sein, eine Strategie der verantwortlichen Autonomie, die aufgrund der expli-
ziten Nutzung individueller Problemlösungskompetenzen der Beschäftigten stark an Individuen
gebunden ist.
So sollten sich in den Dimensionen „Abhängigkeit des Betriebes von Beschäftigten“ und „Ge-
währung von Arbeitsplatzsicherheit“ wichtige Unterschiede zwischen diesen beiden Strategierich-
tungen festmachen lassen.

4.4 Reorganisationsmodi zwischen variierenden

Internationalisierungswegen und indischem Arbeitsmarkt
Mit diesem Kapitel endet der konzeptionelle Teil dieser Arbeit, und die Hypothese dieser Studie
kann nun genauer und exakter reformuliert werden.
In Abgrenzung von den Vertretern der „Industrialisierungsthese“ geht diese Arbeit nicht von
einem linearen und gleichmäßigen Trend der Industrialisierung von IT-Arbeit im Zuge der Inter-
nationalisierung der IT-Industrie aus. Vielmehr wird angenommen, dass sich in der IT-Industrie
unterschiedliche Reorganisationsmodi identifizieren lassen, die in ihrer Gestalt durch das Wechsel-
spiel zwischen den spezifischen Internationalisierungswegen auf der einen und den Arbeitsmärkten
der Zielstandorte auf der anderen Seite beeinflußt werden und unterschiedliche Formen der Ar-
beitsorganisation und -kontrolle beinhalten.
In den folgenden Fallstudien werden zwei sehr unterschiedliche Varianten der Reorganisation
von Arbeit in internationalisierten IT-Unternehmen näher beschrieben. Dabei wird sich zeigen,
dass die Internationalisierung durchaus mit zunehmend restriktiven Formen der betrieblichen
Kontrolle einhergehen kann, wie die Vertreter der Industrialisierungsthese unterstellen. Jedoch
lässt sich anhand der Untersuchung des IT-Dienstleisters ServiceTec zeigen, dass diese „Industria-
lisierung“ der Arbeitsprozesse keineswegs als einfache Reaktion auf die Erfordernisse der globa-
len Produktionsprozesse zurückzuführen ist, sondern ihrerseits Ausdruck eines „Synergieeffekts“
zwischen dem spezifischen Geschäftsmodell von IT-Dienstleistern und eines Umgangs mit den Ei-
genheiten des indischen Arbeitsmarktes ist. Es ist daher kein Zufall, dass die Vorreiter des „Global
Delivery Model“ im Bereich der IT-Dienstleistungen gerade aus Indien stammen.
Der Fall hingegen, an den bei der Rede von IT-Offshoring in der Regel am häufigsten gedacht
wird – die Verlagerungsaktivitäten westlicher IT-Unternehmen an entfernte Standorte – zeigt,
dass international verteilte Software-Entwicklung nicht notwendigerweise „industrialisierte“ Ar-
beitsprozesse beinhalten muss. Vielmehr prägen bei NovoProd nach wie vor viele traditionelle
Formen auch am indischen Entwicklungsstandort die betriebliche Kontrollstrategie. Der Grund
hierfür liegt in dem speziellen Internationalisierungsweg von Standardsoftware-Herstellern, der
nicht nur der Standardisierung und Formalisierung der Arbeitsprozesse Grenzen setzt, sondern
auch Möglichkeiten bietet, den indischen Arbeitsmarkt in einer ganz anderen Weise organisato-
risch zu bearbeiten, als ServiceTec dies vermag.

Mit der Untersuchung eines deutschen Standardsoftware-Herstellers und eines indischen IT-
Dienstleisters konzentriert sich die vorliegende Arbeit auf zwei wesentliche Arten der Verlagerung
von IT-Arbeit aus den Hochlohnregionen der kapitalistischen Zentren in die Niedriglohnregio-
nen der kapitalistischen Semi-Peripherie und damit auf zwei dominante Internationalisierungswe-
Internationalisierungswege und Arbeitsmarkt 57

ge in der IT-Industrie: die Verlagerung mithilfe eines externen Dienstleisters, das sogen. Offshore-
Outsourcing, und die unternehmensinterne Verlagerung an eine eigene Niederlassung, das sogen.
Captive-Offshoring. Es konnte gezeigt werden, dass die für die Industrialisierung von IT-Arbeit
als zentral erachtete Standardisierung und Formalisierung bei diesen beiden Varianten der Verla-
gerung einen unterschiedlichen Fokus aufweist. Steht bei IT-Dienstleistern die Standardisierung
und Formalisierung der Geschäfts- und Arbeitsprozesse im Mittelpunkt, so richten sich die Be-
mühungen von unternehmensintern verlagernden Standardsoftware-Herstellern vielmehr zentral
auf Produkte, also möglichst modulare Produkt- und Prozessarchitekturen. Daraus ergeben sich
erwartungsgemäß unterschiedliche Richtungen bzw. unterschiedliche Schwerpunkte der Reorga-
nisationsbemühungen.

Ist mit den variierenden Internationalisierungswegen in der IT-Industrie auch ein wesentliches
Differenzierungsmerkmal zwischen den verschiedenen Reorganisationsmodi benannt, so bedeutet
das nicht, dass sich die in den indischen Niederlassungen der beiden Unternehmen vorfindbaren
Formen der Arbeitsorganisation und -kontrolle gänzlich durch diesen Einflußfaktor erklären lie-
ßen. Vielmehr, so wird sich in den folgenden Falldarstellungen zeigen, lassen sich die jeweiligen
Reorganisationsmodi von Arbeit nur angemessen verstehen, wenn gleichzeitig auch der Einfluß
des indischen Arbeitsmarktes auf diese berücksichtigt wird.
Mit Indien fokussiert diese Studie auf den weltweit gegenwärtig größten Offshore-Standort für
die Verlagerung von IT-Arbeit. Diese Eigenschaft macht den indischen Standort für die verlagern-
den Unternehmen zunehmend problematisch. Mit den hohen Fluktuationsraten des indischen
Arbeitsmarktes und den damit verknüpften hohen Erwartungen der Beschäftigten hinsichtlich
Karriereverläufen und Gehaltsentwicklung, die durch das arbeitsmarktinduzierte Machtpotential
der Beschäftigten auch durchsetzungsfähig werden, sind zentrale Eigenschaften des indischen Ar-
beitsmarktes benannt, auf die beide Unternehmen sich jeweils organisatorisch einstellen müssen.
In Kapitel 3 wurde gezeigt, dass aus der Situation auf dem Arbeitsmarkt z.T. widersprüchliche
Herausforderungen für die IT-Unternehmen erwachsen, auf die mit unterschiedlichen organisato-
rischen Strategien reagiert werden kann.
Wie sich in den folgenden Falldarstellungen noch genauer zeigen wird, ist sowohl die Art und
Weise in der die Unternehmen jeweils vom indischen Arbeitsmarkt beeinflusst werden, als auch
die Art und Weise, in der versucht wird, mit diesem organisatorisch umzugehen, vom jeweils ver-
folgten Internationalisierungsweg abhängig, da diese unterschiedliche Chancen und Risiken im
Umgang mit dem indischen Arbeitsmarkt begründen.

Analysiert werden sollen die unterschiedlichen Reorganisationsmodi in den Formen der be-
trieblichen Arbeitskontrolle in den Offshore-Standorten. Es konnte gezeigt werden, dass sich die
von den Vertretern der Industrialisierungsthese erwarteten Veränderungen in der Kontrolle von
IT-Arbeit in der Begrifflichkeit Friedmans als ein Strategiewechsel von Strategien der „verantwort-
lichen Autonomie“ hin zu jenen Strategien fassen lässt, die eher dem Muster der „direkten Kon-
trolle“ folgen.
Die Rede von unterschiedlichen Reorganisationsmodi impliziert die Erwartung, dass sich die
Formen der betrieblichen Kontrolle in den beiden Untersuchungsfällen als unterschiedliche Aus-
prägungen derselben Dimensionen der Arbeitskontrolle identifizieren lassen. Als zentrale Dimen-
sionen der Arbeitskontrolle werden in Anlehung an Friedman die Aufgabenschneidung, die Kon-
trollstruktur, die Kooperationsstrukturen und die internen und externen Arbeitsmarktbeziehungen
herangezogen. Als Erwartung kann formuliert werden, dass sich die Reorganisationsmodi der bei-
den untersuchten Unternehmen in den genannten Dimensionen anhand der für jedes Feld definier-
58 Reorganisationsmodi

ten strategischen Dimensionen unterscheiden lassen. Als Ergebnis sind wesentlich unterschiedliche
Formen der betrieblichen Kontrolle feststellbar.
Die Darstellung 4.2 (S. 58) stellt den konzeptionellen Zugriff dieser Studie noch einmal zusam-
menfassend dar, bevor wir uns in den folgenden Kapiteln ausführlich den Formen der betrieblichen
Arbeitskontrolle in den beiden Untersuchungsbetrieben zuwenden.

Unterschiedliche Geschäfts-
und Verlagerungsmodelle
Betriebliche
- Produkte/Leistungen
Reorganisationsmodi:
- Globale Arbeitsteilung
- Art der Standardisierung
- Aufgabenorganisation
- Kontrollstruktur
- Kooperationsstrukturen
- Arbeitsmarktbeziehungen

Indischer
Deutschland Arbeitsmarkt

Indien

Abbildung 4.2: Betriebliche Kontrolle zwischen Geschäfts- und Verlagerungsmodellen und indi-
schem Arbeitsmarkt

Dabei folgt die Gliederung der Fallstudien der vorgenommenen Dimensionierung der betriebli-
chen Kontrollformen.Für die beiden untersuchten Unternehmen werden die Aktivitäten des Ma-
nagements in den vier zentralen Aktivitätsfeldern beschrieben, und anhand der feldspezifischen
strategischen Dimensionen in ihrem Bezug zur im Unternehmen dominierenden Kontrollstra-
tegie analysiert. Jede Fallstudie endet mit einem zusammenfassenden Zwischenfazit, in dem die
Ergebnisse zu den Aktivitätsfeldern verknüpft und im Zusammenhang interpretiert werden.
Entsprechend der zentralen Hypothese dieser Studie wird sich das Augenmerk bei der Beschrei-
bung und Interpretation der Aktivitäten des Managements in jedem Aktivitätsfeld vor allem auf
die Einflüsse richten, die dem Internationalisierungsweg und dem damit zusammenhängenden Ge-
schäftsmodell des Unternehmens bzw. der Situation auf dem indischen Arbeitsmarkt zugeschrie-
ben werden können.
5 „It’s like making a car“ – Kontrolle von
Arbeit beim indischen IT-Dienstleister
ServiceTec
Mit ServiceTec wird im Folgenden ein Fall präsentiert, der sich in der Gestaltung seiner inter-
national verteilten Erbringung von IT-Dienstleistungen durch eine sehr starke Standardisierung
und Formalisierung der Arbeitsprozesse und eine extrem restriktive Form der Arbeitskontrolle
auszeichnet. Damit entspricht der Fall ServiceTec auf den ersten Blick zunächst weitgehend den
Erwartungen der Vertreter der Industrialisierungsthese. Wie ich in der folgenden detaillierten Un-
tersuchung der Kontrollstrategie ServiceTecs jedoch zeigen möchte, ist dieser spezielle Reorgani-
sationsmodus ServiceTecs das Ergebnis eines „Synergieeffekts“: Die vorfindbare Standardisierung
und Formalisierung der Arbeitsprozesse bei ServiceTec ist auf der einen Seite den Notwendigkei-
ten des von IT-Dienstleistern verfolgten Internationalisierungsweges geschuldet, auf der anderen
Seite stellt dieses Vorgehen jedoch auch einen wirksamen organisatorischen Umgang mit den ho-
hen Fluktuationsraten des indischen Arbeitsmarktes dar. Beide Aspekte verstärken sich gegensei-
tig und treiben die Standardisierung und Formalisierung der Arbeitsprozesse voran. Werden die
indischen IT-Dienstleister in der Literatur häufig als Vorreiter der Etablierung globaler Produk-
tionsprozesse im Bereich der IT-Dienstleistungen angesehen und deren „Prozessorientierung“ als
entscheidender Wettbewerbsvorteil hervorgehoben (vgl. z.B. Boes u. a. 2007, Athreye 2005b), so
zeigt sich, dass diese Eigenschaft mehr dem indischen Herkunftsstandort geschuldet ist, als reiner
Ausdruck der fortschreitender Internationalisierung zu sein.
Die Falldarstellung gliedert sich in die folgenden Schritte: nach einem kurzen Kapitel mit nä-
heren Informationen zum Profil des Unternehmens (5.1) soll anhand der Darstellung des von
ServiceTec verfolgten Geschäftsmodells näher beschrieben werden, wie die Standardisierung und
Formalisierung der Arbeitsprozesse bereits durch die globale Arbeitsteilung zwischen den vor Ort
beim Kunden und den in den Offshore-Entwicklungszentren arbeitenden Beschäftigten, sowie die
für IT-Dienstleister typische Form der Kundenbindung gefördert wird (5.2). Die anschließende
detaillierte Untersuchung der betrieblichen Kontrollstrategie bringt diese Einflüsse dann mit de-
nen des indischen Arbeitsmarktes zusammen und zeigt anhand der detaillierten Untersuchung der
vier zentralen Aktivitätsfelder, wie sich diese beiden Einflußfaktoren gegenseitig verstärken und
die Arbeitsprozesse in der Folge stark standardisiert und formalisiert werden (5.3).

5.1 Das Profil von ServiceTec

ServiceTec ist eines der großen indischen IT-Dienstleistungsunternehmen, die in den letzten Jahren
durch enorme Wachstumsraten sowohl der Umsätze als auch der Beschäftigtenzahlen aufgefallen
sind. Der Umsatz ServiceTecs wuchs in den letzten Jahren mit z.T. weit über 30% auf über 4 Mrd.
US-Dollar im Jahr 2008. Die Zahl der weltweit Beschäftigten des Unternehmens wuchs alleine in
den Jahren von 2002 bis 2008 rasant von ungefähr 10.000 auf über 90.000 an1 . Der Großteil der
1
Alle Zahlenangaben sind dem aktuellen Geschäftsbericht des Unternehmens entnommen.

59
60 Fallstudie ServiceTec

Beschäftigten arbeitet in den indischen Entwicklungszentren ServiceTecs.

ServiceTec bietet seinen Kunden die volle Bandbreite an IT-Dienstleistungen: von relativ ein-
fachen Support- und Maintenance-Projekten, über Business Process Management, Beratungs- und
Implementierungsprojekte, Test- und Integrationsarbeiten, bis hin zu komplexeren Forschungs-
und Entwicklungsprojekten zur Herstellung von individuellen Softwareprodukten. Den Schwer-
punkt der Aktivitäten bildet dabei der Bereich der Entwicklung und Wartung von Software, auf
diesen Bereich entfallen knapp 45% des Gesamtumsatzes ServiceTecs.
Historisch ist ServiceTec vor allem durch Kunden in den USA gewachsen. Dominierte in den
Anfängen der Firmengeschichte vor allem das die Entsendung indischer Programmierer in die USA
das Geschäft von ServiceTec, so begann ServiceTec nach der Verschärfung der US-amerikanischen
Visa-Regularien, die vor allem die indischen IT-Fachkräfte traf2 , mit einem groß angelegten Aufbau
von Offshore-Kapazitäten, um zukünftig Arbeiten für amerikanische Kunden von Indien aus zu
erbringen.
Auch gegenwärtig entfällt noch der Großteil des Firmenumsatzes auf Projekte mit amerikani-
sche Kunden. Erklärtes strategisches Ziel der letzten Jahre ist es jedoch, die Abhängigkeit vom
amerikanischen Markt und dessen Konjunkturschwankungen durch Erschließung weiterer Ab-
satzmärkte zu mindern. Diese Bemühungen waren in den letzten Jahren durchaus von Erfolg ge-
krönt – so sank der Anteil der amerikanischen Kunden am Unternehmensumsatz in den letzten
Jahren kontinuierlich: von noch knapp 75% im Jahr 2003 auf knapp 60% im Jahr 2008. Gleich-
zeitig stieg die Bedeutung anderer Regionen – hier vor allem Europa – kontinuierlich an: waren es
2003 noch knapp unter 20%, so lag der Anteil Europas am Gesamtumsatz 2008 bereits bei knapp
unter 30%. Dazu muss jedoch gesagt werden, dass diese positive Entwicklung in Europa gegen-
wärtig hauptsächlich durch Geschäfte in Großbritannien getragen wird. Kontinentaleuropa gilt
(übrigens für alle indischen IT-Dienstleistungsunternehmen; Pohl und Onken 2003, vgl. S20f) bis-
her nach wie vor als schwer zu erschließen, jedoch wird der kontinentaleuropäische – und dort
vor allem auch der deutsche – IT-Markt als der zentrale Wachstumsmarkt der Zukunft gesehen, so
dass strategisch der Ausbau der geschäftlichen Aktivitäten in diesen Regionen für ServiceTec große
Priorität genießt.
Die Kunden von ServiceTec sind regionenübergreifend in erster Linie Großunternehmen aus
den Bereichen Banken und Versicherungen (knapp 38% des Umsatzes), Telekommunikation (ca.
20% des Umsatzes) und der verarbeitenden Industrie (knapp 15% des Umsatzes).
Im Bereich der IT-Dienstleistungen konkurriert ServiceTec nicht nur mit den anderen indischen
IT-Dienstleistern, sondern auch mit den die Branche lange Zeit dominierenden, vorwiegend ameri-
kanischen, globalen IT-Dienstleistungsunternehmen wie z.B. IBM und Accenture, die mittlerweile
ebenfalls Entwicklungszentren in Niedriglohnregionen wie Indien aufgebaut haben, um den Kos-
tenvorteil der indischen Unternehmen zu kontern. Grundsätzlich kann für den IT-Dienstleistungs-
markt konstatiert werden, dass es sich um einen Nachfragemarkt handelt, auf dem, verstärkt durch
die zunehmende internationale Konkurrenz (durch die neuen Anbieter aus Niedriglohnregionen
wie Indien), ein enormer Kostendruck herrscht. Die Reduzierung der Produktionskosten für IT-
Dienstleistungen ist dabei einerseits das Motiv für das Offshore-Outsourcing durch die Anwen-
derunternehmen, treibt diese Entwicklung andererseits aber auch voran, da die Anbieter z.B. aus
Indien damit neue Kostenstandards setzen, denen sich auch westliche IT-Unternehmen wie IBM,
Accenture u.a. stellen müssen (vgl. Boes u. a. 2006, Kämpf 2008).

2
Nach einer Studie der Deutschen Bank gingen 43% der zwischen Oktober 1999 und Februar 2000 gewährten H1B
Visa an indische IT-Fachkräfte (Deutsche Bank Research 2005, S.8)
ServiceTecs globales Geschäftsmodell 61

5.2 ServiceTecs globales Geschäftsmodell

Als Anbieter von Offshore-Outsourcing-Dienstleistungen ist ServiceTec grundsätzlich internatio-
nal – wenn auch anfänglich schwerpunktmäßig auf den amerikanischen Markt – ausgerichtet.
Schon seit Ende des „bodyshopping“ sind bei ServiceTec internationale Leistungserbringungs-
strukturen auffindbar, die mit der Zeit ausgeweitet und weiterentwickelt worden sind.
Das dabei von ServiceTec verfolgte Geschäftsmodell entspricht dem (in der Literatur) indi-
schen IT-Dienstleistern zugeschriebenen „Global-Delivery-Model“ und integriert somit systema-
tisch Aktivitäten im Onsite-, Offshore- und neuerdings auch Nearshore-Bereich. Onsite bezeich-
net dabei den jeweiligen Nahbereich des Kunden, ist also je nach Kunde unterschiedlich, ist jedoch
gemeinhin in den Regionen Nordamerikas und Europas, den Hauptabsatzmärkten ServiceTecs,
angesiedelt. Der Offshore-Bereich bezeichnet primär die großen Entwicklungszentren in Indien.
Zunehmend zählen aber auch weitere Niedriglohnregionen dazu, in denen ServiceTec beginnt,
weitere Entwicklungszentren aufzubauen. Der Nearshore-Bereich ist in ServiceTecs Geschäftsmo-
dell recht neu. Darunter werden eigene Entwicklungskapazitäten in kundennahen Regionen ge-
fasst. In Bezug auf Europa sind dies Standorte in osteuropäischen Ländern, in den USA sind es
zwar Entwicklungszentren in den USA, aber nicht direkt beim Kunden. Diese Zentren sind jedoch
nicht in allen Projekten ServiceTecs involviert, während alle im Rahmen dieser Studie untersuch-
ten Projektteams über ein Onsite- und ein Offshore-Projektteam verfügten.
Jedem dieser Standorte kommt in ServiceTecs Geschäftsmodell ein spezifisches Tätigkeitsprofil
zu: er erfüllt bestimmte Aufgaben in der Projektabwicklung. Ein Vertreter des höheren Manage-
ments von ServiceTec beschreibt die Arbeitsteilung in der Projektabwicklung folgendermaßen:

„I mean, basically, if you look at it in a hunter-farmer model: that BDMs [Business

Development Manager - PF] are the people, who go hunt for the business, Engagement
Managers are the people, who would do try and grow that business and then you have
the delivery organization, who will basically run the business.“ (SI15)3

Die drei wesentlichen Bereiche sind also der Vertriebsbereich (Sales mit den zuständigen Busi-
ness Development Managern, kurz BDM), die Kundenbetreuung (vertreten durch die jeweiligen
Engagement Manager) und der Entwicklungsbereich (Delivery), der die jeweilige Leistung letzt-
endlich erbringt.
Der Vertriebsbereich wird in diesem Fall als eine Art Jäger („hunter“) verstanden. Die zustän-
digen BDM versuchen, potentielle Kunden zu identifizieren und zu kontaktieren. Wenn dieser
Kontakt gelungen ist und es ein erstes Einverständnis von Seiten des Kunden gibt, gibt der zustän-
dige BDM den Kunden an einen sogenannten Engagement Manager im Bereich des Kundenma-
nagements weiter. Dieser ist im folgenden für die Durchführung des Projektes mit dem Kunden
verantwortlich und versucht zudem, den Kunden weiter auszubauen, d.h. weitere Projekte für Ser-
viceTec zu akquirieren, daher auch die Bezeichnung als „farmer“. Die Erbringung der Leistung,
im Sinne der faktischen Programmierung, obliegt dem Delivery-Bereich. Hier werden die je nach
Projekt gewünschten Leistungen erbracht4 .
3
Alle Aussagen werden unter Bezugnahme auf die Aufstellung der geführten Interviews in Tabelle 8.1 (S. 209) im
Anhang zitiert.
4
Bei reinen Beratungsprojekten kann es sein, dass es sich nur um Onsite-Aufgaben handelt. Die meisten Projekte Ser-
viceTecs liegen jedoch, wie oben erwähnt, im Bereich der Entwicklung und Anpassung von Software für Kunden.
Bei diesen Projekten gibt es dann auch die geschilderte Trennung der Aufgaben in Beratung/Planung und Program-
mierung/Codierung.
62 Fallstudie ServiceTec

Regional verteilen sich die Bereiche wie folgt: Die Beschäftigten des Vertriebs und die Kunden-
betreuer sind vollständig Onsite, also in der Region des jeweiligen Kunden angesiedelt. Sie arbeiten
in den zahlreichen Vertriebsbüros, die ServiceTec mittlerweile weltweit aufgebaut hat. Diese Ver-
triebsbüros richten sich ganz nach dem Geschäftsaufkommen, variieren also auch hinsichtlich Grö-
ße und Personalstärke. So war der für Deutschland zuständige Vertriebsleiter in den ersten Jahren
zunächst auf sich allein gestellt und auch später folgte ServiceTec mit seinen Büros in Deutschland
einzelnen Kunden. Die positive Geschäftsentwicklung in Deutschland hat in den letzten Jahren
jedoch die Errichtung eines eigenen zentralen Vertriebsstandortes möglich und nötig gemacht.
Im Delivery-Bereich ist die regionale Verteilung hingegen etwas komplizierter. Zwar befindet
sich der Delivery-Bereich grundsätzlich in den großen Entwicklungszentren (zumeist) Indiens,
jedoch wird ein kleiner Teil des Delivery-Bereichs in der Projektabwicklung auch Onsite beim
Kunden eingesetzt. Mit dieser Aufteilung geht auch eine Arbeitsteilung innerhalb des Delivery-
Bereichs einher. Ein Projektmanager beschreibt die Aufgaben des Onsite-Teils des Projektteams
folgendermaßen:

„In the onsite typically we do the work which requires customer interaction, the re-
quirement analysis. [...] Because this is when you need to interact with the customer.
So the folks, they work as a link between the customer and ServiceTec. So this is whe-
re the criticality of the onsite comes in the picture. They are the link and they are also
the link between the distance. I mean, if I can talk about onsite and offshore – it is a
distance, a person sitting in Germany and sitting in Bangalore.“ (SI6)

Die Beschäftigten beim Kunden bilden also die Schnittstelle zum Offshore-Bereich. Es sind
auch Personen aus dem Delivery-Bereich, führen aber spezielle Tätigkeiten durch, für die der di-
rekte Kontakt zum Kunden unerlässlich ist. Sie agieren vor Ort zusammen mit dem jeweiligen
Engagement Manager, der für den Kunden zuständig ist. Der Engagement Manager ist jedoch
in erster Linie für den geschäftlichen Teil zuständig, die technische Verantwortung liegt beim
Projektmanager des Onsite-Teams aus dem Delivery Bereich, der auch als „Onsite-Coordinator“
bezeichnet wird. Der wesentlich größere Teil des Delivery-Teams befindet sich in den Offshore-
Entwicklungszentren und ist dort für die Erbringung eben solcher Tätigkeiten zuständig, für die
direkter Kundenkontakt nicht nötig ist. Die für das „Global Delivery Model“ typische Trennung
von kundennah und kundenfern zu erbringen Tätigkeiten (siehe Kapitel 2.1 ) verläuft bei Service-
Tec also nicht nur zwischen Vertrieb, bzw. Kundenbetreuung und Entwicklungsbereich, sondern
auch innerhalb des Entwicklungsbereiches selbst.

Die konkrete Form der Arbeitsteilung, sprich die Tätigkeitsprofile Onsite und Offshore sowie
das zahlenmäßige Verhältnis der Mitarbeiter in den beiden Bereichen, unterscheidet sich dabei
zwischen den verschiedenen von ServiceTec durchgeführten Projektarten.
Bei ServiceTec gibt es grob zwei typische Arten von Projekten. Einerseits handelt es sich um
Maintenance-Projekte, also Projekte zur Wartung von beim Kunden bereits genutzten Programmen
oder Systemen, seien sie von ServiceTec selbst entwickelt oder nicht. Andererseits gibt es Entwick-
lungsprojekte zur Erstellung kundenspezifischer Software-Lösungen, meist als Erweiterung oder
Modifikation bestehender IT-Infrastrukturen oder verwandter Standardsoftware.
Maintenance-Projekte, also Projekte, die die Wartung und Aufrechterhaltung bestehender IT-
Infrastrukturen zum Ziel haben, seien dies ganze Systeme, einzelne Applikationen oder Internet-
portale, bilden mit 25% des Gesamtumsatzes neben Entwicklungs- und Implementierungsprojek-
ten einen der größten Geschäftsbereiche ServiceTecs. Ein Projektmanager von ServiceTec differen-
ziert dabei zusätzlich zwischen 3 verschiedenen Arten von Maintenance-Projekten:
ServiceTecs globales Geschäftsmodell 63

„Normally we do three kinds of maintenance. One is the preventive maintenance,

which is like, you go and find out the problem beforehand and attack the problem,
beforehand. And then we do the production support and bug-fixes, where we support
the applications, that are already there in production. And lastly the enhancements
to the existing application, where the business identifies the enhancements to business
process or sometimes the government implants some new rules, which need to be
enhanced in the system.“ (SI3)

Die im Rahmen der vorliegenden Studie untersuchten Projektteams im Maintenance-Bereich

waren alle im Bereich „Production support and bug fixing“ mit leichten Übergängen zum „En-
hancement“ angesiedelt. Sie sind daher gemeint, wenn im Folgenden von Maintenance-Projekten
gesprochen wird.
Maintenance-Projekte sind kontinuierliche Projekte (wenngleich Wartungsverträge natürlich
auch zeitlich beschränkt sein können). Die zu wartende Software befindet sich in Benutzung durch
die Anwender, und ServiceTec hat die Aufgabe, anfallende Probleme oder Fehler zu beseitigen. Der
Arbeitsablauf in einem solchen Projekt kann grob in folgende Phasen aufgeteilt werden:
Angestoßen wird der Prozess durch eine Fehlermeldung der Anwender (meist Mitarbeiter des
Kundenunternehmens). Z.B. sind bestimmte Funktionen einer Applikation fehlerhaft oder un-
vollständig oder erfolgen nicht in der gewünschten Form. Diese vom Kunden kommenden Feh-
lermeldungen erreichen zunächst den sogen. „Onsite-Coordinator“. Hierbei handelt es sich um
den für das Projekt verantwortlichen Projektmanager des Onsite Delivery-Teams. Dem Onsite-
Coordinator und seinem Team obliegt in der anschließenden Phase die Analyse und Klärung des
Problems. Da die Fehlermeldungen der Anwender oft recht unspezifisch und ungenau sind, müs-
sen in den meisten Fällen genauere Informationen zum Defekt recherchiert werden, z.B. wann
genau er auftritt, wie er sich äußert, usw. Dazu gehört auch eine Angabe über das gewünschte
Verhalten der Applikation und die Priorität des Defekts, die letztlich über die zeitlichen Anfor-
derungen der Problemlösung entscheidet. Diese Schritte werden in enger Kooperation mit dem
Kunden durchgeführt.
Eine solcherart genauer spezifizierte Fehlerbeschreibung bildet dann den Auftakt zur eigent-
lichen Behebung des Fehlers, etwa durch Veränderung des Programmcodes der Applikation in
der gewünschten Weise. Damit wechselt die Arbeit dann auch den Standort. In Form eines ge-
nauer spezifizierten Fehlerberichts landet das Problem beim zuständigen Projektmanager in den
Offshore-Entwicklungszentren. Dort kümmert sich dieser zusammen mit dem Offshore-Team um
die entsprechende Veränderung des Programmcodes sowie die sich daran anschließenden Testver-
fahren, um den neuen Programmcode auf seine Fehlerfreiheit und Eignung zu prüfen.
Sodann wird der geänderte Programmcode an das Onsite-Team zurückgegeben. Dieses imple-
mentiert – meist nach einer erneuten kurzen Testphase in den Live-Systemen des Kunden – das
Programm beim Kunden und schließt den Prozess damit ab. In der Realität laufen die Prozesse je-
doch keinesfalls so linear ab, wie es in dieser Darstellung zum besseren Verständnis angenommen
wurde, es kommt zu Rückkopplungsschleifen, wenn Spezifikationen z.B. unklar oder unvollstän-
dig sind, ebenso finden mehrere dieser Abläufe parallel statt.

Der Ablauf eines Entwicklungsprojektes hingegen gestaltet sich etwas anders. Entwicklungspro-
jekte sind Projektgeschäft im engeren Sinne, d.h. sie sind einmalig5 für eine bestimmte Zeit geplant
und enden nach dieser Zeit.
5
Dies gilt, sofern sie nicht mit einem Vertrag über anschließende Wartung gekoppelt sind, die dann häufig langfristige
Zusammenarbeitsverhältnisse schaffen, aus denen weitere Entwicklungsprojekte folgen.
64 Fallstudie ServiceTec

Den Auftakt eines Entwicklungsprojektes bildet der Wunsch eines Kunden nach einem be-
stimmten Programm oder einer sonstigen Applikation. Dieser Wunsch wird vom Onsite-Coordi-
nator und seinem Team in einer ersten Phase des Projekts in Diskussion mit dem Kunden in ein
Pflichtenheft für die Software transformiert. Das Pflichtenheft enthält im besten Fall eine voll-
ständige und bereits grob vorspezifizierte Liste aller vom Kunden gewünschten Funktionalitäten
sowie die geforderten technischen Grundlagen der Applikation (Datenbanken, Programmierspra-
chen, etc.). Das Pflichtenheft bildet also ein erstes grobes Design der zu erstellenden Applikation.
Zusammen mit dem Kunden wird ebenfalls eine erste Version des Projektplans erstellt. Dazu wer-
den die zur Programmierung der Applikation nötigen Arbeitspakete identifiziert, die Zeitrahmen
der Aufgaben abgestimmt und sodann der benötigte Personalschlüssel festgelegt. Dieser vorläu-
fige Projektplan wird vom Kunden abgesegnet und fungiert in der Folge als Grundlage weiterer
Verhandlungen mit dem Kunden, z.B. bei etwaigen Änderungswünschen.
Der vorläufige Projektplan wird zur weiteren Bearbeitung an den im Offshore-Entwicklungs-
zentrum für das Projekt zuständigen Projektleiter weitergereicht, der dort das Team zusammen-
stellt. Einer Phase des detaillierten Designs der Applikation folgt dann die Programmierungs- und
Testphase, die beide dort erledigt werden.
Wie bei Maintenance-Projekten auch, wird das Programm anschließend vom Onsite-Team beim
Kunden übergeben, d.h. implementiert. Während der Entwicklungsphase ist das Onsite-Team mit
der Aufnahme von sogen. „Change-Requests“ des Kunden befasst, also wechselnden Anforderun-
gen des Kunden, die in die entstehende Applikation nachträglich integriert werden müssen.

Ein wichtiger Unterschied zwischen Maintenance- und Entwicklungsprojekten ist zudem die
meist höhere Komplexität des Arbeitsgegenstandes eines Entwicklungsprojektes, die sich auch in
der regionalen Zusammensetzung der Teams widerspiegelt.
Grundsätzlich wird bei ServiceTec versucht, ein Verhältnis von 30 zu 70 zwischen Onsite- und
Offshore-Mitarbeitern des Delivery-Bereichs in den Projekten herzustellen. D.h. 30% der in ei-
nem Projekt beschäftigten Mitarbeiter sollten sich vor Ort beim Kunden befinden, 70% in den
Entwicklungszentren Offshore6 .
Dabei handelt es sich jedoch mehr um einen Richtwert, als um klare Vorgaben. In der Rea-
lität sind große Unterschiede im konkreten Setup der Projektstrukturen auffindbar. Dies zum
einen, weil sich je nach gewünschter Leistung bzw. auch der Komplexität der Projekte ganz un-
terschiedliche Anforderungen an die Verteilung stellen. Bei sehr komplexen, beratungsintensiven
Entwicklungsprojekten kann das Onsite-Team erheblich größer ausfallen, bei klaren, routinemä-
ßigen Projekten jedoch auch wesentlich kleiner. So ist das Onsite-Team in Maintenance-Projekten
gewöhnlich eher kleiner, teilweise – bei längerer Zusammenarbeit mit einem Kunden, wenn sich
eine verlässliche Zusammenarbeit entwickelt hat – kann ganz auf einen Onsite-Teil verzichtet wer-
den.
Bei Entwicklungsprojekten ist der Anteil der Onsite-Mitarbeiter in der Regel etwas größer, wo-
bei es sich keineswegs um ein konstantes Verhältnis handeln muss. So variieren die Teamgrößen
auch im Projektverlauf. Ist der direkte Kontakt zum Kunden vor allem am Anfang und am Ende
eines Projektes wichtig, so kann das Onsite-Team bei geringem Abstimmungsbedarf während der
Bearbeitungsphase auch reduziert werden. Dies wird wiederum auch vom Abstimmungswunsch
6
Wie bereits erwähnt, unterhält ServiceTec mittlerweile auch Nearshore-Entwicklungszentren in anderen Niedrig-
lohnregionen oder auch den USA. Dass dort jedoch der Delivery-Prozess schwerpunktmäßig verankert wird, ist
sehr selten und geht in solchen Fällen auf besondere Umstände zurück, wie z.B. die klare Präferenz der Kunden für
Nearshore-Projekte.
ServiceTecs globales Geschäftsmodell 65

der Kunden beeinflusst, der in seiner Intensität zwischen den Kunden nach Aussagen der inter-
viewten Gesprächspartner stark variiere.
Wichtig bei dieser Arbeitsteilung ist, dass auch die Personen, die gegenwärtig Onsite beim Kun-
den arbeiten, in Indien wohnhaft bleiben und für die Dauer ihrer Aufgaben zum Kunden entsandt
werden. Die im Sales - und Engagement -Bereich tätigen Personen sind hingegen in den Kundenre-
gionen wohnhaft. In Deutschland handelt es sich dabei bislang oft um nach Deutschland gezogene
Inder, jedoch liegt hier der Fokus (primär wegen benötigter deutscher Sprachkenntnisse) auf der
zunehmenden Rekrutierung von deutschen Beschäftigten für diese Bereiche.
ServiceTecs globales Geschäftsmodel beruht also auf einer klaren, regional differenzierten Ar-
beitsteilung. An den unterschiedlichen Standorten (Onsite/Offshore) sind unterschiedliche Arten
von Tätigkeiten konzentriert. Dies ist durchaus eine typische Struktur für Anbieter von Offshore-
Outsourcing-Dienstleistungen.

Ebenso typisch ist die enorme Prozessorientierung ServiceTecs, die in Kapitel 2.1 bereits als
besonderes Merkmal des „Global Delivery Models“ der indischen IT-Dienstleister benannt wur-
de. So sind eine ganze Palette standardisierter und international zertifizierter Prozessmodelle bei
ServiceTec allgegenwärtig:

„Yes, I mean, these are all working standards, like CMM. I think CMM, everybody has
it now. So you have CMM – CMMI, PCMM. So there is a whole bunch of the CMM
stuff we have. Then you have Six Sigma, the European SPiCE system, then you have
EFQM. There is a whole bunch of this.“ (SD6)

ServiceTec ist demnach für eine ganze Reihe international anerkannter Prozessmodelle zertifi-
ziert. Diese Prozessmodelle spielen bei ServiceTec eine vielfältige Rolle.
Auf der einen Seite dienen sie als Qualitätssignal an die Kunden, die eine Implementierung
solcher Prozessstandards durch ihren Auftragnehmer mittlerweile als entscheidende Vorausset-
zung für eine Zusammenarbeit ansehen. Das Outsourcing-Geschäft ist ein kundendominiertes. Da
Kostengesichtspunkte nach wie vor ein wesentlicher Gesichtspunkt bei der Wahl eines Offshore-
Dienstleistungsanbieters sind, sind Kunden sehr an einer möglichst effektiven Durchführung der
ausgelagerten Projekte interessiert. Dies führt einerseits zu einem starken Kostenwettbewerb zwi-
schen den Anbietern von IT-Dienstleistungen, aber andererseits auch zu einem starken Engage-
ment der Kunden bei der Planung und Durchführung der Projekte. So berichten viele Projektma-
nager von ServiceTec, dass Kunden meist versuchten, sich sehr weit in die internen Prozesse bei
ServiceTec einzumischen, und bei der Auftragsvergabe bereits sehr detaillierte Angaben über die
einzelnen Arbeitsschritte und den jeweils veranschlagten Arbeitseinsatz verlangten. Daher sind die
ausgefeilten und allgegenwärtigen Prozessbeschreibungen bei ServiceTec durchaus auch als Ergeb-
nis des starken Kundendrucks zu interpretieren.
Doch Prozessmodelle sind nicht nur Werbung und damit kundengetrieben, sondern sie bilden
nach Angaben des höheren Managements auch die zentrale Grundlage für die global verteilten
Arbeitsprozesse bei ServiceTec. Zu diesem Zweck werden jedoch nicht alle möglichen Prozess-
standards parallel implementiert. Vielmehr werden ausgewählte Prozesse zu einem firmeneigenen
und leider auch streng vertraulichen Prozessmodell verknüpft:

„Now, what has happened is, because the growth of our company, because of the very
dynamic world that we live in, we have finally refined that into a ServiceTec quality
process system, which has all these elements of everything. But customized to that,
66 Fallstudie ServiceTec

so initially a lot of our customers used to ask, ’why, what is this ServiceTec quality,
we know CMM?’ But then we started educating them, saying that ’Look, this CMM
thing and all may work at this other level, but beyond this point where you’re going
so fast, you’re taking on more and more complex projects, this quality standard itself
evolves. So this is our quality standard, this is our process, this is our methodology and
these are the components you see of Six Sigma, these are the components you see, so
we have taken the best in pieces of all of them and put them in our ServiceTec quality
system. But individually, we have certifications for all of them, so, we are a Six Sigma
company, we are a CMM company. [...] All this is there, but the process we follow is
components of that fit together, which we call, we are not very creative in names, so
calling it ServiceTec quality.“ (SD6)

Dieses „ServiceTec Quality Process Model“ ist dabei als ein großer Rahmen zu verstehen, denn
in dieses Prozessmodell gehen sowohl Ablauf- und Verfahrensvorschriften für die im jeweiligen
Projektschritt durchzuführenden Tätigkeiten, als auch Angaben bzgl. der in den einzelnen Ar-
beitsschritten zu erstellenden Dokumente bzw. sonstigen Artefakte ein. Dieses Prozessmodell ist
die Grundlage des Projektmanagements für alle innerhalb von ServiceTec ablaufenden Projekte.
Das Ziel, das damit verfolgt wird, ist eine Standardisierung und Formalisierung der Arbeitspro-
zesse. In diesem Zusammenhang wird bei ServiceTec auch ganz offen und offensiv der Begriff der
IT-Industrialisierung zur Beschreibung dieses Vorgehens gebraucht:

„See, we want to remove this big exotic thing of software from people’s heads. You
know, that you have to have hundred people sitting in your office to design a software
you want for doing analysis, because it’s all about feeling and German software is dif-
ferent [...]. It’s not like that. It’s like making a car! You figure out a process, you figure
out a team and just put it. [...] I think that’s the biggest thing with Indian companies
at the time, not only ServiceTec. They have industrialized it. The word is ‘’Industria-
lisierung’ of the software, they have taken off that entire charm of a bunch of people
doing something creative and making very ... funky systems. [...] They just say ‘look,
insurance is insurance. There is a claim, there is an insurer, there is an act one. Yeah ...
German insurance is a little bit different, we plug it in later. Let’s just do it’“ (SD6)

Die Abgrenzung von IT-Arbeit als kreativer und kunsthandwerklicher Tätigkeit bildet einen
ganz wesentlichen Aspekt des Selbstverständnisses und auch der Geschäftsstrategie von ServiceTec,
wie sich im folgenden Zitat desselben Managers deutlich zeigt:

„A lot of this exoticness about software – I don’t know – you need these big shot
consultants who come in and show you the future about... - and that’s why Germany
is loosing out. It needs to figure out that ’look, software is no big deal’. In Germany, if
you go to any company, probably here it’s a bit different. You talk to a [Name eines
deutschen IT-Dienstleisters - PF] guy tomorrow and say ’I want to meet five or six of
your consultants’. You’ll see them, you’ll see them all ... doctors and everything, they
will be there with a suit and a tie. And they will talk strategy, they will talk vision of
building...“
F: We wouldn’t meet one here?
„I doubt it. If you meet them, they are just acting to impress you. [lacht]“ (SG6)
Betriebliche Kontrollstrategien bei ServiceTec 67

Die - offen formulierte - Absicht hinter dieser stark formalisierten und strukturierten Form
des Projektmanagements bei ServiceTec ist, den Projektverlauf möglichst unabhängig von den im
Projekt beschäftigten Personen zu machen. Dies ist in zweierlei Hinsicht zu verstehen:
Einerseits bilden die strikten Prozesse die Grundlage der Zusammenarbeit der Beschäftigten an
den unterschiedlichen Standorten. Der Projektmanager eines Onsite-Teams beschreibt die Funkti-
on von Prozessbeschreibungen in der direkten Kooperation zum Offshore-Team folgendermaßen:

„There is the guys, the people focus on the job, which is on the hand. [...] See, if they
have to get this done, it doesn’t matter, who that person is, as long as both of them
understand and know, what needs to be done to get the job done.“ (SD4)

So gefasst, schaffen die standardisierten und formalisierten Verfahrensvorschriften, die in dem

Prozessmodell festgeschrieben sind, also die Möglichkeit, Personen eng kooperieren zu lassen, die
häufig nicht die Möglichkeit haben, sich persönlich kennenzulernen, weil sie sich in räumlich weit
entfernten Standorten befinden.
Andererseits wird aber auch ganz konkret Unabhängigkeit von einzelnen Beschäftigten ange-
strebt. Die Prozessbeschreibungen sollen den Projektablauf an diese standardisierten Vorgaben
und auch die jeweils verantwortlichen Beschäftigten an ein bestimmtes Vorgehen binden. So soll
explizit vermieden werden, dass einzelne Beschäftigte einem Projekt „eine persönliche Note“ ge-
ben und damit eine schwer ersetzbare Position im Projekt einnehmen können. Gerade vor dem
Hintergrund der hohen Fluktuationsraten am indischen Standort wird dieses Motiv plausibel, sol-
len die häufigen Wechsel in den Projektteams nicht zu Problemen im Projektverlauf führen. Von
daher sind diese Prozesse so gestaltet, dass, wie sich eine Projektmitarbeiterin in Indien ausdrückt,

„[...] the project should not be dependent on a particular person at any point. [...]
Supposing this person leaves the company, ServiceTec, or leaves this project, then there
is a major problem in the project, like, there is a major lack of knowledge there. We
make sure, that never happens.“ (SI13)

Das geflügelte Wort für dieses Managementziel ist die (von Beschäftigten unterschiedlicher Ebe-
nen bei ServiceTec oft mantra-artig wiederholte) Aussage, dass Projekte stets „process-depending
and not people-depending“ sein sollten.

ServiceTec stellt in Bezug auf die in dieser Studie verfolgte Fragestellung daher einen Fall dar,
in dem die Industrialisierung der Arbeitsprozesse besonders deutlich zu Tage tritt. Wie in den
nächsten Abschnitten zur konkreten Kontrollstrategie, die ServiceTec in seinen Offshore-Ent-
wicklungszentren verfolgt, noch gezeigt werden wird, führt diese intendierte, weitreichende In-
dustrialisierung der Arbeitsprozesse bei ServiceTec auch zu stark repressiven Formen der Ar-
beitsprozesskontrolle. Die folgende Analyse der Kontrollstrategie ServiceTecs in ihren Offshore-
Entwicklungszentren anhand der vier Aktivitätsfelder wird zeigen, wie die strategischen Entschei-
dungen ServiceTecs dabei auf der einen Seite vom skizzierten Geschäftsmodell und auf der anderen
Seite von der Situation auf dem indischen Arbeitsmarkt geprägt sind.
68 Fallstudie ServiceTec

5.3 „Jack of all trades and master of none“ – Betriebliche

Kontrollstrategien bei ServiceTec im Entwicklungszentrum in
Bangalore
Gemäß des Geschäftsmodells und der internationalen Arbeitsteilung von ServiceTec befinden sich
vor allem die Teams des Delivery-Bereiches in den Offshore-Entwicklungszentren. Zwar gibt es
auch zunehmend Bemühungen, Bereiche, die dem Sales und Engagement-Bereich unterstützend
zuarbeiten, Offshore zu lokalisieren, jedoch sind diese Bereiche noch sehr klein und nur vereinzelt
anzutreffen. Von daher konzentriert sich diese Untersuchung ganz auf die Analyse der Kontroll-
strategien im Delivery-Bereich. Der Aufbau der Darstellung folgt der in Kapitel 4.3 vorgenomme-
nen Operationalisierung und Dimensionierung des in dieser Studie verwandten Kontrollbegriffs.

5.3.1 Aufgabenorganisation
Aufgabenschwerpunkt des indischen Entwicklungszentrums
Zur Beschreibung der Arbeitsabläufe in der Softwareentwicklung wird gewöhnlich auf den sogen.
„Software-Lifecycle“ rekurriert. Demnach lassen sich bei der Erstellung von Software nach dem
sogen. „Wasserfallmodell“7 folgende Phasen der „Produktion“ unterscheiden (vgl. Abbildung 5.1):
Einer Phase der Problemidentifizierung und entsprechender Analyse folgt in der Regel eine Phase,
in der ein technisches Design der zu entwickelnden Software entworfen wird. Anschließend folgt
der Prozess der eigentlichen Softwareentwicklung, also die Phase des Kodierens und Testens der
Software. Dieser mündet in die Implementierung der Software. Daran schließt sich evtl. eine Phase
der Wartung an.
Die bei ServiceTec an die Offshore-Entwicklungszentren verlagerten Tätigkeiten im IT-Dienst-
leistungsbereich lassen sich als Tätigkeiten am unteren Ende des Software-Lifecycles beschreiben.
Die frühen Phasen, wie die Identifizierung der Anforderungen an die Software, setzen intensive
Kommunikation mit den Kunden voraus, weshalb hier räumliche Nähe wichtig ist.

„Z.B. Anforderungsspezifikation – wenn man mit dem Kunden direkt arbeiten muss,
um ihn zu fragen: Was sind die Spezifikationen? Dafür braucht man eher Onsite. Te-
lefonisch oder per Mail, Offshore ist das sehr schwierig, hier mit acht Leuten vom
Kunden zu sprechen jeden Tag und dann die Spezifikationen zu verfeinern. Dafür
brauchen wir hier Onsite.“ (SD7)

Ab der Phase des Designs erfolgt in der Regel in Entwicklungsprojekten die Verlagerung. So
werden die Offshore-Entwicklungszentren häufig zum detaillierteren Design, der folgenden Pro-
grammierung und des Testens der Entwicklung genutzt. Die Phase der Implementierung beim
Auftraggeber setzt dann wieder die räumliche Nähe zum Kunden voraus, da auf deren Systeme
zugegriffen werden muss und meist zusätzliches Personal beim Kunden geschult, bzw. angeleitet
werden muss.
7
In der Regel wird zwischen linear und iterativ ablaufenden Prozessen der Softwareentwicklung unterschieden: Linea-
re Modelle sind z.B. das bekannte Wasserfallmodell, iterative Modelle wie z.B. Extreme Programming sind dagegen
eine relativ neue Erscheinung. Entgegen der linearen Modelle, die auf eine klare, zeitlich lineare Abfolge der Ent-
wicklungsschritte aufbauen, steht bei den iterativen oder auch agilen Prozessen eher eine spiralförmige Entwicklung
mit kurzen Feedback- und Respezifizierungsschleifen im Fokus. Diese Prozesse setzen aber erhöhte Kommunikation
mit evtl. Kunden oder Auftraggebern voraus, weshalb sich die Ansicht hartnäckig hält, dass iterative Methoden der
Softwareentwicklung bei Offshoring-Projekten nicht von Vorteil seien. Unabhängig davon, ob es generell möglich
ist oder nicht, stellt das Wasserfall-Modell bei ServiceTec die präferierte Form der Softwareentwicklung dar.
Betriebliche Kontrollstrategien bei ServiceTec 69

Abbildung 5.1: Wasserfall-Modell der Softwareentwicklung (Quelle:

[Link] abgerufen am
22.02.2010)

Die abschließende Phase des Maintenance wiederum ist Gegenstand der Maintenanceprojek-
te, setzt allerdings voraus, dass es sich um zu wartende Systeme oder Applikationen handelt, auf
die auch von außen gut zugegriffen werden kann (vgl. Heeks 1995, S.369ff.; Aspray, Mayadas und
Vardi 2006, S.54ff.; Dossani und Kenney 2004, S.386f.). Diese Verteilung ist natürlich nicht statisch,
sondern stellt sich in Abhängigkeit von der konkreten Art des Projektes leicht unterschiedlich dar
(siehe die Beschreibung der Arbeitsteilung in Maintenance- und Entwicklungsprojekten in Kapitel
5.2). Dennoch bleibt festzuhalten, dass die Tätigkeiten, die Offshore erledigt werden, im wesent-
lichen Programmier-, Test- und Wartungsarbeiten sind, während die kommunikationsintensiven
Tätigkeiten von Anforderungsanalyse und Design vor Ort beim Kunden erbracht werden.

„Der Fokus von den Onsite Teams liegt darauf, die Interaktion mit dem Kunden zu be-
treiben und alle Sachen, die mit dem Kunden direkt besprochen werden müssen, auch
durchzudiskutieren, und außerdem liegt sie ein bißchen auf der sprachlichen Kompo-
nente. Das heißt, wenn ich Dokumentationen habe, die auf Deutsch erstellt werden
müssen - die würde ich dann von den Leuten hier vor Ort machen lassen, weil es dann
auch in engerer Abstimmung mit dem Kunden alles erfolgen kann.“ (SD3)

Mit dieser Arbeitsteilung zwischen Onsite- und Offshore-Teams des Delivery Bereiches bei Ser-
70 Fallstudie ServiceTec

viceTec geht eine Asymmetrie bzgl. planender und ausführender Tätigkeiten einher. Wesentliche
Entscheidungen bzgl. des Projektverlaufs und auch erste richtungsweisende Entscheidungen, z.B.
bzgl. des Designs der zu entwickelnden Software in einem Entwicklungsprojekt, werden onsi-
te von den sich dort befindlichen Personen in Kooperation mit dem Kunden getroffen. Die auf
die Offshore-Entwicklungszentren entfallenden Tätigkeiten sind demnach eher ausführender Art.
Dies beeinflußt auch die Komplexität der Arbeitsaufgaben wesentlich. So lässt sich bei ServiceTec
konstatieren, dass sich die komplexeren Tätigkeiten bei den Teams onsite finden, was sich auch
daran zeigt, dass ServiceTec ausschließlich erfahrene Beschäftigte vor Ort beim Kunden einsetzt:

„Mindestens ein Jahr Projekterfahrung muss man haben, um vor Ort zu kommen.
Das haben wir intern, projektintern die Regelung gemacht. ... Weil die Komplexität
war einfach zu hoch, um das Risiko einzugehen. Wenn wir unerfahrene Entwickler
hier vor Ort bringen würden, und wenn der Kunde dann mit denen unterhaltet und
dann die Erfahrung sammelt: ’Aha, in wessen Händen ist unsere Software eigentlich?’.
Um das zu vermeiden.“ (SD8)

Dabei ist die Hürde mit einem Jahr Betriebszugehörigkeit in diesem Projekt noch niedrig, in
anderen Projekten sind die Anforderungen an die Erfahrung der Beschäftigten wesentlich höher:

„Wir haben Software Engineers ... fast keinen. Weil die haben 3 bis 4 Jahre Erfahrung.
Wir haben nur Programmer Analyst. Und dann wir haben Project Managers. Und
dann auf höhere Ebenen dann Project Managers - Senior Project Manager.“ (SD7)

Nach Aussage dieses Managers werden Personen auf dem Einstiegsniveau (Softwareentwickler)
von ServiceTec also so gut wie gar nicht onsite eingesetzt. Folglich finden sich fast ausschließlich
Personen beim Kunden, die mindestens die zweite Hierarchiestufe erreicht und bereits 3-4 Jahre
Erfahrung innerhalb von ServiceTec gesammelt haben.
Erfahrung bemisst sich aber nicht nur in der reinen Dauer der Zugehörigkeit zum Unternehmen
und der Arbeit in Projekten von ServiceTec. Vielmehr liegen auch die Qualifikationsanforderun-
gen für Beschäftigte der Onsite-Teams höher. Personen, die vor Ort beim Kunden arbeiten wollen,
müssen vorher bestimmte – je nach Projekterfordernissen verschiedene – interne Zertifizierungen
erwerben. Dabei müssen sie technische, aber vor allem auch branchenspezifische Kenntnisse bewei-
sen, die für die Mitarbeiter Onsite von weitaus größerer Wichtigkeit sind als für die Beschäftigten
Offshore, da man Onsite ganz unmittelbar mit dem Kunden bei der Spezifikation der Leistungen
zusammenarbeitet:

„Versicherungskenntnisse zum Beispiel. In diesem Fall haben wir schon versucht, aber
die meisten hatten es sowieso nicht. Und wir hatten dann intern angefangen, Versi-
cherungszertifikation zu machen, abzuschließen, und ... das ist jetzt mittlerweile ein
Kriterium geworden.“ (SD8)

Zudem erfordert eine Onsite-Beschäftigung nach Ansicht des im folgenden zitierten Vertreters
des höheren Managements Führungserfahrung:

„Und ich will eigentlich auch hier Leute haben, die ’ne robuste Berufserfahrung ha-
ben. Weil ob die Leute jetzt ... ’ne Programmer Analyst Rolle haben in diesem Projekt
vielleicht oder nicht - sie werden aber dadurch, dass sie in dieser Kundensituation ste-
hen, auf jeden Fall Führungserfahrung brauchen. Und deswegen will ich da eigentlich
Projektmanager sitzen haben.“ (SD3)
Betriebliche Kontrollstrategien bei ServiceTec 71

Aufgrund dieser (für das „Global Delivery Model“ ServiceTecs spezifischen) Form der Arbeits-
teilung kommt es also bereits zu Ungleichgewichten in Bezug auf die am jeweiligen Standort zu
bearbeitenden Aufgaben. Den Offshore-Entwicklungszentren fallen in diesem Geschäftsmodell
dabei eher die ausführenden und damit auch weniger komplexen Arbeitsaufgaben zu.
Ergibt sich diese Asymmetrie bereits aus dem für IT-Dienstleister typischen Kundenkontakt
und der damit zusammenhängenden Form der globalen Arbeitsteilung, so wird in den Offshore-
Entwicklungszentren ServiceTecs versucht, die Komplexität der vom einzelnen Entwickler zu be-
arbeitenden Arbeitsaufgaben darüber hinaus noch weiter zu reduzieren. Dies beginnt schon bei
der organisatorischen Struktur der Offshore-Teams.

Teamstruktur und Tätigkeitsprofile

Ein Offshore-Projektteam besteht gewöhnlich aus mehreren sogen. „Modulen“ mit bis zu 4 Ent-
wicklern und einem Modulleiter als fachlichem Vorgesetzten. Jedes Modul ist für einen bestimm-
ten entsprechend klar abgegrenzten und spezifizierten Teil der zu erbringenden Leistung (entweder
der Entwicklung oder der Wartung) verantwortlich. Die verschiedenen Module, die in ihrer Zahl
je nach Projektart und -größe variieren, werden von einem Gesamtprojektleiter koordiniert und
kontrolliert.
„A typical project would be headed by a project manager. And then the project would
have different modules. Each module would be headed by a module leader. [...] And
each of these modules would have a set of software engineers. That’s a typical structure
of a project.“ (SI7)
Die Projekte sind zudem auch räumlich modular strukturiert. Normalerweise sitzen der Modul-
leiter und die seinem Modul zugeordneten Entwickler in einem eigenen sogen. „Cubicle-Komplex“
zusammen. Ein solcher Komplex besteht aus jeweils zwei aneinanderliegenden mit Trennwänden
seitlich abgetrennten Würfeln. In dem einem Würfel befinden sich die Arbeitsplätze für das Modul-
Team, im anderen ein Arbeitsplatz für den Module-Lead. Die Gesamtheit der Cubicle-Komplexe –
das gesamte Projektteam – befindet sich meist in unmittelbarer Nachbarschaft zueinander. Der
Projektmanager hat sein Büro in der Nähe der Cubicles, allerdings nicht in diesen selbst. Die
räumliche Organisation der Projektteams unterstützt in seiner Form die Kontroll- und Kommu-
nikationserfordernisse der Arbeitsprozesse, wie sich an späterer Stelle noch genauer zeigen wird.
Zunächst aber führt diese Strukturierung der Teams dazu, dass die einzelnen Entwickler in der
Regel ausschließlich an kleinen Teilen der Applikation arbeiten und Fragen des Zusammenhangs
von einzelnen Teilen und Gesamtapplikation nicht auf der Ebene der Entwickler bearbeitet wer-
den. Innerhalb der Projektteams findet sich daher eine starke Arbeitsteilung, die dazu führt, dass
die Entwickler klar spezifizierte, extrem kurztaktig zugeschnittene und individuell zugewiesene
Arbeitsaufgaben erhalten.

Um die teaminterne Arbeitsteilung zu verstehen, sollen kurz die an der Projektbearbeitung be-
teiligten Rollen und ihre Tätigkeitsprofile näher beschrieben werden8 . Ein Projektmanager erläu-
tert die einzelnen, den Tätigkeitsprofilen hinterlegten Funktionen folgendermaßen:
„If you look at the team primarily here, it would be the IT-team, so the general struc-
ture of a project would be: you’ll have a Project Manager and then you have Program-
mer Analysts and Software Engineers. But the primary responsibility of executing a
8
Die Fokussierung auf die an der Bearbeitung beteiligten Rollen schließt die nähere Spezifizierung der unterschiedlicen
Rollen des höheren Managements aus.
72 Fallstudie ServiceTec

project over time would be for the Project Manager. And the project might be divided
into different modules and different areas, which would be owned by a Programmer
Analyst. And then you’ll have a Software Engineer executing it. This Programmer
Analyst would be responsible partly for the coding part as well and doing report re-
views and Project Manager might have to involve themselves in other reviews like
design reviews and requirement specification reviews etc. as well. But the Project Ma-
nager should analyze all the resource requirements, your project acquisition part, the
critical part and the Project Manager also has to do kind of milestone-reporting ana-
lyses and to see, where the project is going and do a monitoring and control for the
project.“ (SI17)

Die Funktion des Projektmanagers besteht somit bei ServiceTec in erster Linie in der Planung,
Koordination und Kontrolle des Gesamtprojektes. Dazu gehört auch das detaillierte technische
Design der zu erbringenden Leistung und die Erstellung des Projektplans, Aufgaben, für die der
Projektmanager meist mit den jeweiligen Modulleitern sowie der Technologieabteilung von Ser-
viceTec9 eng kooperiert und durch das höhere Management bei Bedarf unterstützt bzw. beaufsich-
tigt wird. Die planenden Tätigkeiten konzentrieren sich also auf dieser Ebene, und strategische
Entscheidungen hinsichtlich des Projektablaufes werden ebenfalls vom Projektmanager getroffen.
Zudem ist der Projektmanager gegenüber dem höheren Management für die Ausführung des Ge-
samtprojektes verantwortlich. Der Projektmanager steht dazu in ständigem Kontakt mit den Mo-
dulleitern und kontrolliert den Status, die Kosten und die Qualität der geleisteten Arbeit. In die
konkrete Durchführung der Projektarbeiten, wie der Programmierung, wird der Projektmanager
hingegen nur einbezogen, wenn es Probleme gibt. Ansonsten ist die Aufsicht über die konkrete
Arbeit der Entwickler Sache des Modulleiters. Allerdings führt der Projektmanager regelmäßige
Design- und Fortschrittskontrollen durch und kontrolliert damit die Arbeit der Modulleiter und
die in den Modulen geleisteten Arbeiten. Der Arbeitstag der Projektmanager ist dementsprechend
auch zum absoluten Großteil von Meetings sowie Planungs- und Koordinierungsaufgaben geprägt.
Einzelarbeit hingegen findet nach Angaben der interviewten Projektmanager nur selten statt.
Die nächste Rolle, die des Modulleiters – häufig auch als Programmanalyst bezeichnet – ist durch
eine gewisse Zwischenstellung zwischen Management und Projektausführung gekennzeichnet. Die
Modulleiter tragen die „bottom line responsibility for the deliverables“ (SI14), wie es ein Modul-
leiter von sich selbst sagt. So fällt die Sicherstellung der Programmierarbeiten in die Zuständigkeit
der Modulleiter. Ein Modul besitzt i.d.R. ein klar umrissenes Themengebiet, meist ist es ein Teil-
bereich einer zu entwickelnden oder zu wartenden Applikation, z.B. eine Teilfunktion oder ein
Unterprogramm. Für die Ausführung der Arbeiten, die diesem Modul zugerechnet werden, ist
der jeweilige Modulleiter dem Projektmanager gegenüber verantwortlich. Der Modulleiter leitet
dabei die Software-Entwickler in seinem Modul fachlich an, d.h. der Modulleiter ist stets die ers-
te Anlaufstelle für die Entwickler bei Problemen mit ihren Arbeitsaufgaben. Der Modulleiter ist
jedoch auch selbst noch in die ausführenden Tätigkeiten einbezogen, indem er einerseits selber
Teilarbeiten des Moduls verrichtet und andererseits die Arbeiten der Softwareentwickler eng kon-
trolliert, d.h. sogen. „Code-Reviews“, das sind persönliche Kontrollen des von den Entwicklern
geschriebenen Programmcodes, durchführt.
9
Die Technologieabteilung ist eine spezielle Einrichtung innerhalb ServiceTecs. In dieser arbeiten Personen, die sich
gezielt für eine technische Karriere innerhalb ServiceTecs entschieden haben und die die verschiedenen Projekte in
technischer Hinsicht als Technologie-Experten beraten und unterstützen. Die technischen Teams sind daher meist
lediglich am Anfang der Projektlaufzeit involviert, wenn das genaue technische Design der zu erbringenden Lösung
spezifiziert wird.
Betriebliche Kontrollstrategien bei ServiceTec 73

Darüber hinaus hat der jeweilige Modulleiter jedoch z.T. auch Projektmanagementfunktionen.
So obliegt ihm z.B. häufig die konkrete Zuweisung der Arbeitsaufgaben an die Softwareentwickler,
wie ein Projektmanager aus seinem Projekt berichtet:

„So, in our case it was the module leads, who were doing the daily assignment, because
we found it more productive, rather than the project manager doing it, we decentra-
lized it to different modules. So if there is a production support request10 , there is a
bunch of production support requests, so the module lead is in a better position to
know, that, who is free, who is not free, who has to be assigned, who has knowled-
ge in which subject area and all those things. And that module lead takes care of the
assignment of only that particular bug fix module. The next module lead has the re-
sponsibility for his one module and finally the project manager normally reviews that
once in a while, say once in a week or once in a fortnight.“ (SI3)

Ein typisches Vorgehen besteht daher in den meisten Modulen darin, dass die Entwickler ihre
Arbeitspakete vom jeweiligen Modulleiter zugewiesen bekommen und dieser auch die folgende
Abarbeitung persönlich begleitet, anleitet und kontrolliert. Ebenso nehmen die Modulleiter an
der konkreten Planung des Projektverlaufes in Zusammenarbeit mit dem verantwortlichen Pro-
jektmanager teil, helfen teilweise beim technischen Design und der Zeitschätzung der definierten
Arbeitsaufgaben.
Wie weit die Modulleiter jeweils in das Management des Projekts involviert sind, hängt dabei
vom persönlichen Managementstil des Projektmanagers ab, wie ein Projektmanager verrät:

„The project manager has the responsibility and it’s up to him – the way he runs his
project. So, there are project managers, who have a higher degree of transparency and
do counsel with their module leads – there are project managers, who don’t have a
higher level of transparency, when it comes to making decisions.“ (SI3)

So bestanden auch in den im Rahmen dieser Studie untersuchten Projekten durchaus Unter-
schiede in dem Grad, zu dem Modulleiter in Managementaufgaben involviert wurden.
Aufgrund dieser Zwischenstellung ist der Arbeitstag eines Modulleiters auch recht gleichmä-
ßig zwischen Einzelarbeit und Koordinationsaufgaben aufgeteilt, ca. 3-4 Stunden des Arbeitstages
entfielen nach Aussagen der Modulleiter auf Einzelarbeit, also auf eigenes Codieren oder Kontrol-
lieren der Arbeiten der Entwickler, der Rest bestehe in Koordinationsaufgaben oder Meetings.
Das Tätigkeitsprofil der Entwickler (Software-Engineers) schließlich markiert die Einstiegsebene
bei ServiceTec. Es beinhaltet im wesentlichen die konkrete Ausführung der Projektarbeiten. Die
Arbeitsinhalte wechseln zwar je nach Projektart und der Phase, in der das Projekt sich jeweils befin-
det (Programmierung oder Testing bspw.), doch stets beinhaltet die Rolle der Software-Entwickler
einen eindeutigen Fokus auf Technologie:

„No, so for example, what we have clearly articulated is that for software engineer kind
of profiles, the focus is on technology. So the first three to five years we believe, the
person has to understand technology very well, because that’s what drives ourselves
and that’s what we need to have as basic forming blocks. After that, a person can
start focusing more on the domain. So, I mean, first three years it’s purely technology,
10
Ein „production support request“ ist ein Arbeitsauftrag in einem Wartungsprojekt, bei dem der Kunde einen Fehler
meldet und damit einen Arbeitsablauf zur Behebung des Fehlers einleitet.
74 Fallstudie ServiceTec

although there are some domain competencies and we try to build regional units of
persons to send. But that’s not the primary responsibility. It’s technology. As you keep
moving senior the focus moves from technology to domain. So initially you’ll see a lot
of people being moved from one unit to another, based on the way that technology
requirements suit the person. So this is not really the domain, which impacts to such
large an extent.“ (SI15)

Die ersten Jahre im Unternehmen sind die Entwickler also primär mit dem Erlernen und der Er-
weiterung ihrer technischen Kompetenzen und Erfahrung beschäftigt. Erst nach und nach und mit
zunehmender Intensität wird versucht, die Entwickler auch auf bestimmte Geschäftsfelder („do-
mains“) und Herkunftsländer („regions“) ihrer Kunden zu spezialisieren. Die letzte Bemerkung
des zitierten Managers deutet bereits an, dass die Rolle des Software-Entwicklers bei Service-Tec
dadurch eine besonders flexible ist. So werden Software-Entwickler je nach Projektbedürfnissen
zwischen verschiedenen Projekten hin und her geschoben. Auf diese Weise reagiert ServiceTec
flexibel auf im Projektverlauf unterschiedliche Personalbedarfe eines Projektes. Werden zu einer
bestimmten Zeit viele Beschäftigte gebraucht, z.B. in intensiven Testphasen, so können schnell
Beschäftigte anderer Abteilungen und Projektteams ausgeliehen werden. Wenn in einer anderen
Phase der Personalbedarf hingegen sinkt, werden Beschäftigte aus den Projektteams freigesetzt
und befinden sich anschließend „auf der Bank“, wie es bei ServiceTec heisst. Wer „auf der Bank“
sitzt, ist keinem konkreten Projekt zugeordnet und widmet sich weiteren Trainingsmaßnahmen,
bis ein neues Projekt Bedarf anmeldet und die Person in diesem Projekt zu arbeiten anfängt. Die
„Bank“ stellt demnach einen flexiblen internen Markt für Arbeitskräfte dar, auf den von den un-
terschiedlichen Projekten zugegriffen werden kann.
Auf der Ebene der Entwickler würde eine fachliche oder länderspezifische Spezialisierung das
stete Ersetzen und Wechseln der Entwickler zwischen den Projektteams eher erschweren als er-
leichtern, wenn Entwickler nicht frei in möglichst vielen Bereichen des Unternehmens eingesetzt
werden könnten. So liegt der Fokus für die Entwickler zunächst rein auf der technologischen Ebe-
ne und auch innerhalb der technologischen Ausbildung wird versucht, technische Spezialisierung
möglichst zu vermeiden.
Daher bekommen die Entwickler bei ServiceTec auch primär relativ gleichförmige Arbeitsauf-
gaben zugeteilt, die nicht nach individuellen Kompetenzen oder Vorerfahrungen variieren.

„Basically all the juniors are doing almost similar kind of work. So there is no selection
as such.“ (SI14)

Wer also eine Zeitlang an einem Java-Projekt gearbeitet hat, wird nicht zwangsläufig beim nächs-
ten Mal wieder in einem Java-Projekt arbeiten, sondern wahrscheinlich eher in einem Projekt, das
C++ oder eine andere Programmiersprache einsetzt.
Die Arbeit der Software-Entwickler ist vorwiegend Einzelarbeit. Zwar kooperieren die Software-
Entwickler bei Problemen oder Unklarheiten direkt miteinander, was durch die Arbeitssituation
innerhalb desselben Cubicles auch unterstützt wird, aber in der Regel besteht der Tag aus Arbeit
an individuell zugewiesenen Aufgaben:

„At the junior level the whole day is almost like working on something that is allocated
to them.“ (SI14)
Betriebliche Kontrollstrategien bei ServiceTec 75

Definition und Zuweisung von Arbeitsaufgaben

Wie sich aus der Schilderung von Teamstruktur und Tätigkeitsprofilen bereits erahnen lässt, ver-
folgt ServiceTec in seinen Arbeitsabläufen einen sehr klaren „top-down“ Ansatz. Die notwendigen
Tätigkeiten werden über die genannten Hierarchiestufen des Projektmanagers, der Modulleiter bis
hin zu den Software-Entwicklern immer weiter heruntergebrochen. Planende Tätigkeiten nehmen
in diesem Prozess von Stufe zu Stufe kontinuierlich ab. Am Ende – auf der Ebene der Softwareent-
wickler – stehen kleinteilige, stark vorspezifizierte Arbeitsaufgaben für die Entwickler, die wenig
kreative Anforderungen beinhalten.
Dazu muss gesagt werden, dass ServiceTec im IT-Dienstleistungsbereich sehr unterschiedliche
Projekte durchführt, deren technische Komplexität stark variiert. So finden sich bei Projekten, die
auf die Entwicklung einer individuellen Softwarelösung zielen, wesentlich komplexere Anforde-
rungen, als bei der Entwicklung einer kleineren Erweiterung für ein bereits bestehendes Produkt
oder der Wartung einer sich in Betrieb befindlichen Applikation. Von daher sind die Anstren-
gungen, die ServiceTec unternehmen muss, um die vom Kunden kommenden Anforderungen in
kurztaktige Arbeitspakete für die Entwickler umzusetzen, unterschiedlich stark. So verlangt z.B.
die Weitergabe von Wartungsaufträgen an die Entwickler weniger Aufwand, da Fehlermeldungen
häufig bereits in ausreichend spezifizierter Form von den Beschäftigten des Kundenunternehmens
kommuniziert werden können. In diesem Fall reduziert sich die Aufgabe des Verteilens der Ar-
beitsaufgaben daher mehr oder weniger auf eine reine Weitergabe der Arbeitsaufgaben11 .
Im Großteil der von ServiceTec durchgeführten Projekte kommen die Arbeitsaufgaben jedoch
lediglich grob vorspezifiziert vom Kunden bzw. dem Onsite Team. Wie bereits beschrieben, ob-
liegt den Onsite-Projektteams die Aufgabe, in Kooperation mit dem Kunden ein erstes grobes
Design der verlangten Leistung herzustellen. Ein solches Design ist bereits mit ersten Aufwands-
schätzungen, d.h. einer groben Zeitplanung und einer Schätzung der benötigen Teamstärke des
Projektteams, verbunden.
In diesen Fällen werden die Vorgaben anschließend vom zuständigen Projektmanager des Off-
shore-Teams in Zusammenarbeit mit technischen Beratern, den Module-Leads und je nach Kom-
plexität des Projektes auch von Angehörigen des höheren Managements in ein sehr detailliertes,
technisches Design der zu erbringenden Lösung und einen feingliederigen Projektplan umgesetzt.
Dieses Vorgehen geht nicht nur auf strategische Überlegungen und Entscheidungen Service-
Tecs zurück, sondern es wird auch unterstützt von der Vorsicht und dem Kontrollbedürfnis der
Kunden. Nach Aussagen von Projektmanagern haben die Kunden von sich aus ein sehr großes
Interesse an möglichst detaillierten Projektplänen mit kleinschrittigen Rückmeldeschleifen. Nach
Angaben von Kundenbetreuern bei ServiceTec erhofften sich die Kunden dadurch die Möglichkeit,
eventuellen Fehlentwicklungen im Projektverlauf früh entgegenwirken zu können. Der Offshore
erstellte feingliederige Projektplan ist daher in den meisten Projekten auch vom Kunden abzu-
zeichnen, bevor das Projekt anschließend in seine Bearbeitungsphase übergeht. Es sind also keines-
falls nur strategische Entscheidungen ServiceTecs, die für die Form der Arbeitsabläufe ausschlag-
gebend sind. Gerade an diesem Punkt wird der Einfluss des Kunden und damit auch die Rolle des
Geschäftsmodells – für das der Bezug auf externe Kunden als Anbieter von Offshore-Outsourcing-
Dienstleistungen konstitutiv ist – für die Form der Aufgabenorganisation bei ServiceTec sehr deut-
lich.
11
So wird diese Allokation von Arbeitsaufgaben in den im Rahmen dieser Studie untersuchten Wartungsprojekten
teilweise auch über rein technische Fehlermeldungssysteme erledigt, in die der Kunde Fehlermeldungen eingibt
und diese anschließend direkt an den für den fehlerhaften Programmteil zuständigen Modulleiter in den Offshore-
Entwicklungszentren geschickt werden, der dann die teaminterne Verteilung übernimmt.
76 Fallstudie ServiceTec

Das Herunterbrechen der Arbeitsaufgaben beruht ganz wesentlich auf den in den indischen
Entwicklungszentren von ServiceTec allgegenwärtigen Prozessmodellen und -vorgaben. Die Pro-
zessorientierung ist daher bei ServiceTec auch das dominierende Merkmal der Arbeitsabläufe. Ser-
viceTec ist für eine ganze Reihe von international anerkannten Prozessstandards zur Softwareent-
wicklung zertifiziert, mit CMMI, PCMM, Six Sigma und ISO 900X seien hier nur die bekanntes-
ten erwähnt. Sind diese Zertifizierungen zwar auch immer demonstrativer Qualitätsausweis, der
in erster Linie an die Kunden gerichtet ist, die auf solche Zertifizierungen als vertrauensbilden-
de Maßnahme großen Wert legen, so sind diese Prozessmodelle jedoch auch in der betrieblichen
Arbeitsrealität von ServiceTec von großer Bedeutung. In der Praxis sind diese unterschiedlichen
Prozessvorgaben – wie im vorigen Abschnitt bereits erwähnt – von ServiceTec zu einem firmenei-
genen „Set“ von angewandten Prozessen verknüpft worden. Das in der Praxis „gelebte“ Modell ist
somit kein reines CMMI-Modell oder folgt nicht ausschließlich Six Sigma, sondern stellt eine Kom-
bination aus unterschiedlichen Elementen der verschiedenen Standards dar. Diese Prozessmodelle
strukturieren die Arbeitsabläufe auf unterschiedlichen Ebenen.
Auf der obersten Ebene werden in diesem Prozessmodell die unterschiedlichen, von Service-
Tec durchgeführten Projektarten spezifiziert. So gibt es jeweils unterschiedliche Prozesse für z.B.
Entwicklungs-, Wartungs- oder Implementierungsprojekte. Jedes dieser verschiedenen Projekte er-
fordert unterschiedliche, vorgegebene Abläufe und Arbeitsschritte. Diese werden in den Prozess-
beschreibungen spezifiziert:

„It varies actually from projects, there is nothing like: these many fixed processes that
need to be followed. It varies based on the kind of project, that you do. It normally
varies based on the services, that you provide and based on the domain area, where
these services are provided. So, it varies. So, there are around 10 to 11 kinds of services,
that ServiceTec provides, so it varies, the process varies for different services.“ (SI3)

Ein anderer Projektmanager ergänzt:

Es hängt davon ab, was für ein Projekt das ist. Es gibt zig Arten von Projekten. Es
gibt Entwicklungsprojekte, Re-Engineering-Projekte, Konfigurations-Projekte, Bera-
tungsprojekte, Wartungsprojekte. Und danach ist auch wichtig, in welcher Phase die-
ses Projekt sich jetzt befindet. Man kann ja im Prinzip immer anfangen. Und danach
gibt es 12 Hauptprozesse – im Wartungsprojekt zum Beispiel. Und unter jedem dann
gibt es wieder Sub-Categories. Insgesamt 1000 Punkte ungefähr. Vielleicht 800, kann
sein, ungefähr. Mir fiel dieses Thema sehr lang aus [lacht].“ (SD8)

So sind die Projektbeschreibungen auf dieser – obersten – Ebene zunächst eine Art Road-Map,
welche die nötigen Arbeitsschritte ausweist, die in einem solchen Projekt gewöhnlich vonnöten
sind und durchgeführt werden sollen. Diese Vorgaben unterstützen damit – das ist die nächste
Ebene – die Projektmanager bei der Erstellung der Projektpläne am Anfang eines Projektes. Ein
Projektmanager beschreibt die Prozessmodelle und deren Nutzung auf dieser Ebene folgenderma-
ßen:

„Ja, das nennt sich Tayloring. Und zum Anfang des Projektes – der Projektleiter muss
mit den Software-Quality-Advisern [im folgenden SQA - PF], intern, bei ServiceTec,
die Prozesse diskutieren. Und zum Beispiel in einem neuen Projekt sind 1000 Schritte
in einem Prozess, 1000. Da muss nicht jeder alles machen. Dann setzt er sich mit dem
SQA einen Tag zusammen, dann sagt er: ’Ja, das brauche ich nicht, das bringt mir
Betriebliche Kontrollstrategien bei ServiceTec 77

hier nichts.’ Und der SQA wird dann halt die Genehmigung geben. Es gibt welche
[Prozessschritte sind gemeint – PF], die mandatory sind, die müssen gemacht werden.
Und wenn diese Sache jetzt einmal fertig ist, dann wird das auch befolgt. ... Und jede
Jahreshälfte ... hat er nochmal einen Termin mit dem SQA, wo er nochmal jetzt die
Punkte anschaut, die zwar taylorable waren, also empfohlen waren vom System, aber
die nicht befolgt wurden – ob das sich doch vielleicht lohnt, das zu befolgen. Und
auch diejenigen, die jetzt er macht – vielleicht macht er überflüssige Sachen, nur um
den Prozess zu erfüllen.“ (SD8)

Den Prozessauftakt bildet also eine Auswahl der im Projekt verfolgten Prozesse in enger Koope-
ration mit den SQA. Dies sind Beschäftigte aus einer speziellen Abteilung, die für die Verwaltung
und Weiterentwicklung der von ServiceTec implementierten Prozesse zuständig sind. Als Qua-
litätsbeauftragte obliegt den SQA auch die weitere Aufsicht über die Projekte in Bezug auf die
Einhaltung der implementierten Prozesse. Die SQA sind dabei nicht in die Projektteams inte-
griert, sondern fungieren eher als externe Gutachter mit einer starken Machtposition gegenüber
den Projektteams, da sie direkt dem Vorstand unterstellt sind und auch an diesen etwaige Verstösse
melden:

„Der Qualitätsberater berichtet direkt an den Vorstand. Und daher hat der sehr viel
zu sagen. Kann sagen: ’Das soll gemacht werden, das muss gemacht werden. Und ich
akzeptiere so, und so nicht. Und wenn Ihr das nicht macht, dann müsst Ihr das halt
eurem Manager erklären, und ich mache dann meinen Bericht an den Vorstand.’ Und
daher ist Software-Qualität dann total unabhängig von Projektplänen. Also keine gu-
ten Freunde vom Projektleiter.“ (SD8)

Bei den aus dem Prozessmodell abgeleiteten und zu implementierenden Prozessen wird dabei
zwischen Pflichtprozessen, solchen, die anzupassen sind, und solchen, die lediglich optional sind,
unterschieden:

„There are certain mandatory components, that are there, which has to be done, un-
less there is an exception, which can be justified. And there are guidelines, which are
optional, which can be modified, and there are some processes, which are mandatory,
but you can modify them.“ (SI3)

Das gibt den Prozessmodellen auf dieser Ebene noch einen relativ flexiblen Charakter, wie ein
Projektmanager feststellt:

„Und dafür ist das System sehr flexibel. Das ist das Gute daran – es muss nicht das,
das und das gemacht werden. Das empfehlt es zwar, aber .... die wichtigsten Sachen
müssen erfüllt werden.“ (SD8)

Dementsprechend ist der Anteil der anpassbaren Prozesse an den Gesamtprozessen auch am
größten.

„It’s a very, very less percentage, around 10 to 15 percent is normally mandatory,

which can not be modified, and around 70 percent is mandatory, but can be modified,
but it is mandatory. It can be modified based on the processes. And around 15 to 20
percent can be optional, which you can follow or don’t follow.“ (SI8)
78 Fallstudie ServiceTec

Bei der Auswahl und der Spezifizierung der nötigen Prozesse wird der Projektmanager durch
ein firmeneigenes Computersystem unterstützt, in das die Prozessbeschreibungen integriert sind.

„Ja, es gibt ein System, nennt sich [Name entfernt - PF]. Und wenn der Projektleiter
einen Projektplan erstellt, kann er zuerst downloaden. Man hat dann gleich von einem
anderen System, wo das Budget notiert wird, bekommt er auch die Ressourcen-Namen
verknüpft in diesem Plan. Gleich hat man die Ressourcen-Pool, die Aktivitäten. Da-
nach kann man dann, und da steht das auch, ob das jetzt mandatory ist oder taylorable
ist oder empfohlen ist. Und ... kann man filtern, und dann mit dem SQA diskutieren.“
(SD8)

Dieses Computersystem verknüpft die Prozessbeschreibungen also bereits mit den verfügbaren
Beschäftigten12 und dem entstehenden Projektplan, d.h. den aus den ausgewählten Prozessen fol-
genden Tätigkeiten, bzw. Arbeitspaketen. So kann in der Planungsphase des Projektes von den
zuständigen Managern ein detaillierter Projektplan unter Berücksichtigung der notwendig zu erle-
digenden Arbeiten und den verfügbaren Beschäftigten leichter zusammengestellt werden.

„When we start the project, we have a huge task of the complete planning for the
project. During that planning we have this task of creating a complete task-list and
then we have the task of arranging for all the resources, that are hardware, software
or even people. So, during that project planning phase we create microsoft project,
wherein we try to divide all the activities and list down all the dependencies to the
minimal level possible.“ (SI19)

Die in der Planungsphase erstellten Projektpläne enthalten somit bereits eine Liste von zu be-
arbeitenden Arbeitspaketen, die aus der Zusammenstellung der für das Projekt nötigen Prozesse
gewonnen wird. Damit schlagen die Prozessbeschreibungen dann auch auf die unterste Ebene, die
konkret von den Entwicklern zu erbringenden Tätigkeiten, durch. Auf dieser Ebene werden die
Prozessvorgaben zudem von weiteren Vorgaben ergänzt.
So sind für die einzelnen Prozessschritte entsprechende Input- und Output-Dokumente defi-
niert, die einen Arbeitsschritt einleiten, bzw. die zum Abschluß eines solchen produziert werden
müssen und damit den Übergang zum nächsten Schritt bilden. Für diese Dokumente gibt es Vor-
lagen, die den jeweilgen Prozessen hinterlegt sind und die von den Mitarbeitern im Laufe der Bear-
beitung der einzelnen Aufgaben ausgefüllt werden müssen. Diese Vorlagen sind zudem häufig mit
Checklisten verbunden, mithilfe derer sichergestellt werden soll, dass alle vom Prozess vorgeschrie-
benen Tätigkeiten auch durchgeführt wurden, bevor der Arbeitsschritt als beendet gekennzeichnet
wird und den nächsten Schritt anstößt.

„And we have systems [...] for every, every aspect of project management, we’ve got
templates, we’ve got guidelines, for everything. From requirement analysis to delivery,
to maintainence to support. So we have a lot of guidelines, a lot of templates, a lot of
processes in place, which have developed over a period of time.“ (SI12)

Eine andere Art von Vorgaben bzgl. der Arbeitsverrichtung stellen auch die sogen. „Coding-
Guidelines“ dar. Diese sind als Normenkataloge zu verstehen, die wesentliche Konventionen für
12
Der Sprachgebrauch, von den Beschäftigten lediglich als „Ressources“ zu sprechen, ist dabei keineswegs nur dem
zitierten Gesprächspartenr eigen sondern typisch für ServiceTec und veranschaulicht sehr schön die Haltung des
Managements gegenüber den Beschäftigten.
Betriebliche Kontrollstrategien bei ServiceTec 79

die Erstellung der Applikation, bzw. zum Bearbeiten eines Programmcodes enthalten. Darunter
fallen beispielsweise Namenskonventionen für die zu benutzenden Variablen und Funktionen so-
wie Vorgaben zur Form und Struktur, in der programmiert wird, also Einrückungen, Kommentar-
formate etc. Bei Wartungsprojekten sind diese Coding-Guidelines häufig vom Kunden vorgegeben,
da die Bearbeitung der zu wartenden Programme zu den bestehenden Systemen und dort verfolg-
ten Standards passen sollen. Bei Entwicklungsprojekten gelten hingegen die eigenen Standards. Es
handelt sich dabei sowohl um branchenweite Standards als auch um firmeninterne Lösungen, die
über die Zeit hinweg evaluiert und weiterentwickelt werden.

Diese Vorgaben bzgl. der Arbeitsschritte sind in ihrer Reichweite bzw. ihrer Wirkung für die
Arbeit der Entwickler nicht zu unterschätzen. Die folgende Aussage eines Managers weist in dras-
tischen Worten auf die Detailtiefe der Prozessvorgaben für jeden einzelnen Arbeitsschritt und die
daraus resultierende Dequalifizierung der Arbeitsaufgaben für die Entwickler hin:

„The entire organization works fully on standards, processes, frameworks. For eve-
rything there’s a standard, everything there’s a document, for everything there’s a
template, everything works on that. So there is, I mean, we have been saying that,
it is becoming too ... - in a sense that: Does a person really need to apply a brain to
do anything? There’s a form for everything. There’s a fixed template for everything.“
(SI15)

Auch ein anderer Projektmanager teilt in seiner Antwort auf die Frage nach einem persönlichen,
individuellen Arbeitsstil der Entwickler diese Einschätzung:

„To answer that question, no, absolutely not, nobody can code in their own style,
we have standard guidelines for that. We have standard practices and guidelines on
how to code a certain piece. In that guideline you will find that, what are the names
for, naming conventions, that have to be used, where you will find, how much is the
indentation or their space required before you start coding any line and you might
even find, what are all the comments that are in that unit to put in the code. So, all
these are shared with the developers at the beginning of the project. That is a part of
the project planning exercise. Eh, does that answer your question?“ (SI19)

Sicherlich mag man dem Management von ServiceTec ein Interesse daran unterstellen, die Wir-
kung der Prozessbeschreibungen und die Kontrolle, die dadurch über den Produktionsprozess
gewonnen wird, zu überzeichnen, doch in diesem Punkt decken sich die Schilderungen des Ar-
beitsablaufs von Seiten der EntwicklerInnen weitgehend mit der Darstellung des Managements.
So ist die folgende Entwicklerin z.B. geradezu amüsiert über die Frage nach einem persönlichen
Arbeitsstsil bei der Programmierung:

[Laughs] Nooo - we do follow some coding standards, so everybody will code with
COBOL according to the standards. [...] There are some company standards, and we
have developed our own coding standards, coding certificate [...] and all this.“ (SI1)

Die Prozessbeschreibungen schlagen also mitsamt der mit ihnen verknüpften Vorlagen und
Programmier-Richtlinien bis auf die Ebene der an die Entwickler verteilten Arbeitsaufgaben durch
und stellen enge Vorgaben dafür dar, wie die Arbeitsaufgaben anschließend bearbeitet werden sol-
len.
80 Fallstudie ServiceTec

Ist in den Prozessbeschreibungen damit also schon die grobe Definition der Arbeitspakete vor-
gesehen, so beruht die Zuweisung der Arbeitsaufgaben an die einzelnen Entwickler im Team den-
noch auf einer persönlichen Zuteilung durch die Projektmanager bzw. Modulleiter:

„These are the parts, which are coming from the guidelines, coding standards, you
have review checklist, you have review process, you have configuration management
process. They are taylored based on the needs of the project, but primarily comes from
the guideline. This would be on the process side. What ... the day-to-day-task would
be actually designing and coding the system. That would be more done by the project
manager, where the project manager will draw out the project plan and define each of
the activities to people there, which module they have to design, which program they
have to design, which program they have to code. For it’s. . . they have to follow the
activities and also keep this process in mind. So whenever they’re coding any program,
which is assigned to them, the requirements are explained to them by the person, who
has sent requirement analysis for the project. [...] Now when they have to do a design,
they have to follow the design template, which comes as an input from the guideline.
They have to follow certain standards, that comes as an input from the guideline. But
the time duration in which they have to complete the design, when to start, when to
complete, who would do the design. All that will come from the project manager.“
(SI17)

In der zitierten Aussage wird der Zusammenhang zwischen der Prozesseite auf der einen und
der persönlichen Zuweisung auf der anderen Seite beschrieben. Die Prozessbeschreibungen und
die darin enthaltenen Vorlagen und Vorgaben enthalten zwar die grundsätzlichen Informationen
für die Bearbeitung der jeweiligen Arbeitsaufgaben. Aber die genaue Zuteilung an die beteiligten
Entwickler, sowie die Planung darüber, was wann und in welchen Zeiträumen erledigt werden soll,
ist Sache der Projektverantwortlichen. D.h. damit auch, dass die Entscheidung über die Länge der
Arbeitspakete letztlich nicht direkt aus den Prozessbeschreibungen abgeleitet wird, sondern eher
den Modulleitern obliegt, die den nötigen Arbeitsaufwand schätzen. Selbstverständlich wird diese
Schätzung durch Firmenstandards unterstützt:

F: So, you never know, how much time a certain task will take?
„We do know the time, that is – it really varies, say for example, there is an enhan-
cement, that I get, which might be something like, it will require a new field on the
screen, because a new kind of tax has come from the government, which needs to be
accommodated. That could be one kind of an enhancement. The other kind of an en-
hancement is, where, eh, the government has imposed a new rule in calculation of the
premium for this insurance client. So, obviously these two enhancements are going to
take different timeframes for executing. So, we do have a guideline for estimation, say-
ing that, if these are the number of business tools that are getting modified, then this
is the effort for this and these are the number of screens that have to be modified, then
this is the effort for this. So, based on that, we come up with an effort for each and eve-
ry enhancement. So, in this enhancement, if there are quarters like, say, 10 percentage
or 20 percentage, and based on the 20 percentage and based on the experience that we
had, or based on the data we had in this project earlier, we split into different software
life cycles. So, really the thing varies between two enhancements. We do know the
timeframe, but it varies between two enhancements and there is no guideline, which
Betriebliche Kontrollstrategien bei ServiceTec 81

says, that this is to be followed. The guideline, which is there, is the common guide-
line, which is there for the entire software industry, which says that: this much has
to be (percentage of the effort) has to be requirements, this much percentage of the
effort has to be design, this much percentage has to be the build. Which again vari-
es on a project to project basis, because there are projects, which are build-intensive,
there are projects, which are design-intensive, so it really again varies based on the pro-
ject. So, on timeframes, generally there are no guidelines during the execution. But the
guidelines can be set up at the project level.“ (SI3)
Die Firmenstandards in Bezug auf die Zeitspannen der Arbeitspakete leiten sich also nach An-
gaben dieses Projektmanagers aus den Erfahrungen der Firma ab. Dazu werden alle Projekte re-
gelmäßig evaluiert und auf die benötigte Zeit der einzelnen Arbeitsschritte hin untersucht und
verglichen. Die daraus gewonnenen Durchschnittswerte bilden dann die Grundlage für die weite-
ren Schätzungen der Arbeitsaufwände für die Aufgaben der Entwickler, wie ein Projektmanager
ausführlich erläutert:
„See, basically this is, this is mainly after that the requirements analysis phase. Ok.
So we do..., what we have done, the requirements detailing, we know all the require-
ments, that are there for the development of any application. And then these requi-
rements come into design. The design is the technical implementation of the require-
ments. On probably converting it into a solution. So, once we have the design with us,
probably you can call it a high-level design, we will know all the components, all the
components and all the, yeah, all the components, that have to be developed for an ap-
plication. Ok, once we know all those components, that have to be developed, we will
also know the dependencies across these components or any external dependencies.
So, now, my estimation model, the standard estimation model, that we have, actually
that estimation model has been developed using the passed data in the industry best
practices. So that estimation model would give me that effort required at each and
every component level. So, now, taking that effort required, we know, that this much
would be the effort, that would be completely required to develop one component.
And after that we have guidelines within the organization on how much out of that
total effort, how much percentage should go into development, how much percentage
should go into testing and all that. So, then we apply that percentage distribution and
come up with the effort required. So, using these techniques and tools, you will get a
meticulous level of effort, effort at the lowest level.“ (SI19)
So sehr daher also die Prozessmodelle auch als strukturierendes Element der Arbeitsorganisa-
tion bei ServiceTec betont werden, so beruht die Definition und Zuweisung der Arbeitsaufgaben
nicht ausschließlich auf ihnen. Sie geben einen Rahmen und definieren Tätigkeiten, die für einen
bestimmten Prozess ausgeführt werden müssen. Die konkrete Gestalt der in diesen Prozessbe-
schreibungen enthaltenen Tätigkeiten wird jedoch zusätzlich noch durch die Feinplanung durch
die Projektverantwortlichen, also den Projektmanager, häufig in Kooperation mit dem Modullei-
ter, beeinflußt. Diese legen die genauen Zeitrahmen der Aufgaben fest, entscheiden, wie die Ar-
beitsaufgaben auf die Entwickler verteilt werden. Somit können die Arbeitsaufgaben der Entwick-
ler nicht ausschließlich als Ausdruck der bei ServiceTec implementierten Prozessmodelle gesehen
werden. Ihre konkrete Gestalt ist auch Ergebnis zusätzlicher Gestaltung durch die Projektleiter.
Die strategische Orientierung ServiceTecs bei der Gestaltung der Arbeitsaufgaben ist dabei ein-
deutig. Es wird versucht, die Arbeitsaufgaben für die Entwickler möglichst eng zu definieren und
82 Fallstudie ServiceTec

die Arbeitspakete damit zeitlich soweit wie möglich herunterzubrechen, wie ein Projektmanager
erläutert:
„Ok, so in a Microsoft-Project13 we create that task-list, in which you might find, that
the tasks are not more than two to four hours or eight hours max. [...] That is the
level of planning, that we do. Yeah, we do plan for the task, that would be probably
two hours, four hours or eight hours at the most. And then using that MSP only we
start locating the tasks to the people.“ (SI19)
Der Grad zu dem die Arbeitspakete für die Entwickler heruntergebrochen werden können, un-
terscheidet sich dabei allerdings zwischen den unterschiedlichen Projektarten. Nach Angaben der
betroffenen Entwickler unterscheiden sich die Arbeitspakete in Entwicklungs- und Wartungspro-
jekten in ihrer Länge deutlich. So können die Zeitrahmen, der an die Entwickler zugewiesenen
Arbeitspakete in Wartungsprojekten noch einmal wesentlich kürzer sein, als die benannten 2-8
Stunden.
„The shortest period - that normally comes in a production support request, where
you get a request in the morning and you have to deliver it in the evening. Such is,
can be the shortest duration. And there are tasks, which are, like, one hour duration,
where you need to do the release audit for this particular project, so it normally takes
one hour, or you do a review, which normally takes one hour.“ (SI3)
Die angegebene Zeitspanne von 2-8 Stunden muss dabei auch in Entwicklungsprojekten eher
als strategische Zielgröße angesehen werden, denn als durchschnittlicher Wert. So ließen sich bei
den untersuchten Projektteams, die mit einer Entwicklungsaufgabe betraut waren, durchaus auch
längere Arbeitspakete finden:
„It’s usually a weekly. In our previous project it used to be, like, one or two days
actually. Like in our previous project it was a lot of maintainace part of it, like, they
have to fix it within one day. So the tasks were allocated to them on a daily basis. So
here we are doing a build project. So build goes for one week, two weeks actually. So
they have their work on it for those two weeks.“ (SI14)
Damit ist jedoch nicht gesagt, dass ein Planungshorizont von 2 Wochen auch bedeutet, dass in
diesen 2 Wochen der Fortschritt der Arbeiten nicht häufig kontrolliert wird. Der Frage der Kon-
trollzyklen und der Häufigkeit der Kontrollen wird sich das nächste Kapitel noch ausführlicher
widmen, aber es kann festgehalten werden, dass auch wenn für Arbeitsaufgaben teilweise mehr
als ein Tag kalkuliert werden, für diese Zeit Zwischenschritte eingeplant werden, mit denen der
Fortschritt kleinschrittig – häufig täglich – erfasst werden kann.
Die Arbeitsaufgaben werden bei ServiceTec jedoch nicht nur möglichst kurztaktig definiert, sie
werden auch rotierend den einzelnen Entwicklern zugewiesen, wie ein Modulleiter erläutert:
„See, the tasks involved in a problem notification solving is ... finding the problem,
finding the solution, testing that solution and testing various parts of the unit testing
and system testing. So we randomly associate different people so that everybody is
capable of doing everything.“
F: So it doesn’t matter at all who is assigned which task?
„Yes, that is more to avoid the dependency on any particular person.“ (SI20)
13
ServiceTec setzt Microsoft Project als Software für das Projktmanagement ein, der Interviewpartner bezieht sich hier
auf einen in MS Project erstellten Projektplan, im folgenden MSP
Betriebliche Kontrollstrategien bei ServiceTec 83

Weiter oben wurde bereits auf die Flexibilität der Rolle des Entwicklers hingewiesen und die
organisatorischen Maßnahmen beschrieben, mit denen versucht wird, eine fachliche, technische
oder regionsabhängige Spezialisierung der Entwickler zu vermeiden. Doch die Entwickler wech-
seln zu diesem Zweck nicht nur regelmäßig die Projektteams und werden abteilungsübergreifend
verschoben, sondern auch während der Zeit in einem Projekt bekommen die Entwickler möglichst
rotierende Arbeitsaufgaben zugewiesen. Durch diese Art der Aufgabenzuteilung soll ebenfalls ei-
ne fachliche und projektspezifische Spezialisierung vermieden werden. Dadurch wird einerseits die
Abhängigkeit der Projekte von einzelnen Personen weiter reduziert und andererseits sollen die
Entwickler dadurch befähigt werden, alle Arten von im Projekt anfallenden Tätigkeiten auszufüh-
ren. Aus diesem Grund werden auch etwaige Vorerfahrungen der Entwickler von den Modullei-
tern bei der Aufgabenverteilung nicht berücksichtigt:

F: You said that you are trying to rotate the tasks, does it happen that some team
members are more experienced and get assigned the more complex tasks?
„No, I don’t see that happening.“ (SI20)

Besonders deutlich wird dieses spezielle Vorgehen in Vergleichen zu den deutschen Counter-
parts beim Kunden, die indische Entwickler anstellen:

„One more difference would be – they [die Beschäftigten beim Kunden – PF] will
stick to that technology probably throughout their lives. But we don’t get a chance to
do that here. We normally become the jack of all trades and master of none.“ (SI20)

In anderen Worten formuliert eine Entwicklerin dieselbe Beobachtung:

„Actually, what I have seen in IT-people at [Deutscher Kundenname - PF] and in IT-
people in India is, that they are specialized in certain fields. But here in India, what
is done, is, that we have to work in all types of things. We are not masters of..., let’s
say..., we are not..., we have to be masters of all the things, actually. But in their cases
I’ve seen, they send people, who are specialized in different tasks. So one kind of task
will be handled by one person only and he’ll keep on handling that task only, he’ll be
perfect in that. In our case, we work in all the jobs.“ (SI21)

Auf der Ebene der Entwickler versucht ServiceTec also, Spezialisierungseffekte gezielt zu verhin-
dern und zu unterlaufen. Dies ermöglicht ServiceTec, die Entwickler intern flexibel einzusetzen
und auch nach Bedarf zwischen verschiedenen Projekten und sogar verschiedenen Business Units
zu verschieben. Ein Delivery Manager formuliert diesen Vorteil der Aufgabenorganisation wie
folgt:

„People have spent enough energy taking the best practices, that they have learned
across and then created these artifacts: For this, follow this particular process. So that’s
what also. . . keys of standardization. When I move, let’s say tomorrow from [Name
der für u.a. Kunden in Deutschland zuständigen Abteilung - PF] to any other group, I
don’t know, no need to figure out what that group is doing. I’ll go there and I get the
same things.“ (SI15)

Dabei ist dieses Rotationssystem für ServiceTec nicht unproblematisch. Zwar will man natürlich
die flexiblen Einsatzmöglichkeiten erhalten, doch gibt es auch eine Grenze für dieses Bemühen. So
84 Fallstudie ServiceTec

stellt das branchenspezifische Wissen der Beschäftigten auch für ServiceTec eine wichtige Ressour-
ce dar. Wenn die Beschäftigten das Geschäftsumfeld des Kunden kennen, so erleichtert dies durch-
aus die Kommunikation mit dem Kunden, da die Entwickler die Anforderungen an die Software
besser verstehen können. Stetige Rotation zwischen verschiedenen Geschäftsfeldern stört jedoch
den Aufbau dieses Branchenwissens empfindlich. Daher wird bei ServiceTec versucht, die Beschäf-
tigten möglichst nicht übermäßig zwischen verschiedenen Branchen zu rotieren, sondern sie in
Projekten für eine bestimmte Branche zu halten. Nach den bei ServiceTec durchgeführten Inter-
views zu schließen, gelingt dies jedoch nicht immer, denn diesem Bemühen werden vom Geschäfts-
aufkommen Grenzen gesetzt. Wenn es in einem Bereich nicht genügend Bedarf an Beschäftigten
gibt, werden diese auf andere Projekte verschoben, wie eine Entwicklerin klarstellt:

„Yeah, we have one option, that we can obviously go to our senior and tell him, we are
interested, this is, what I want. If it’s possible, we are given the opportunity, and if it’s
not, then obviously we have to shift, wherever we are asked to.“ (SI21)

In der Praxis führt dieser Widerspruch zu einer Mischung aus Beschäftigten, die durch verschie-
dene Kundenbranchen gewechselt sind und auch weiter wechseln, und anderen, die sich zuneh-
mend in einer Branche spezialisieren und auch gezielt in diesen Bereichen gehalten werden sollen:

„There is a special team which is working only for Austria, Switzerland and Germany.
Each practice has identified a set of people. And those people are owning that prac-
tice, it will be only those people, who would be working for Austria, Switzerland,
Germany practices and they would not be working for any other practice, as long as
work is there in Austria, Switzerland Germany practice. Let’s say, there is a little bit
of downturn, and those specific skills are not required, then yeah, they can be moved
to another practice and work there. But if there is a work there and there is a requi-
rement there, it would continue working with that practice, they are owned by that
practice, where they are used to work. .... [...] The reason, why we have the same peo-
ple working within the practice, is, because at one level, we understand that. . . , let’s
say in UK, where we are verticalised 14 , we want the people, who are working in the
practices there, to bring in their industry knowledge, you know? Because, let’s say, of
course he is working in financial services with a financial services client, next time we
move him to, say, a pharma client, he would bring less value to the client, which is not
really, what we want. That is why we retain it that way.“ (SI4)

Hier wird also anscheinend versucht, eine Balance zwischen der Rotation und der Reduktion
der Abhängigkeit von einzelnen Beschäftigten auf der einen Seite und der Notwendigkeit, in einem
Geschäftsfeld erfahrene Beschäftigte mit Branchenkenntnissen auszubilden auf der anderen Seite,
zu finden.
Neben dem flexiblen internen Einsatz der Entwickler ermöglicht diese Form der Aufgabenor-
ganisation ServiceTec auch, mit externer Personalfluktuation leichter umzugehen. Die Zeit, die
benötigt wird, um einen aus dem Projektteam scheidenden Entwickler durch einen anderen zu
ersetzen, werde nach Angaben von Beschäftigten auf diese Weise stark verkürzt, da die Einarbei-
tungszeit reduziert werde. Dieser Aspekt wird im späteren Kapitel über die Arbeitsmarktbezie-
hungen noch zu vertiefen sein, jedoch kann an dieser Stelle bereits festgehalten werden, dass sich
14
Gemeint ist eine Aufteilung der Geschäftsbereiche über eine regionale Aufteilung hinaus. In Deutschland ist bisher
noch nicht genug Geschäftsvolumen verfügbar, um zwischen verschiedenen Branchen organisatorisch zu unterschei-
den, dies ist in UK oder den US jedoch anders.
Betriebliche Kontrollstrategien bei ServiceTec 85

hier die für den indischen Standort so charakteristischen Fluktuationsraten entscheidend in der
Firmenstrategie zur Kontrolle der Arbeit niederschlagen und die spezifische Form der Aufgaben-
organisation wesentlich (mit-) geprägt haben.

Dem bisher skizzierten Vorgehen bei der Aufgabenorganisation entspricht auch, dass Mitspra-
chemöglichkeiten bei der Zuteilung der Arbeitsaufgaben für die Softwareentwickler kaum gegeben
sind. Auf die Frage, ob sie ihre Arbeitsaufgaben mitbestimmen könne, antwortet eine Entwickle-
rin leicht verlegen:

„No, we don't do it actually. We don't have the right to do it maybe. [lacht leicht
verlegen].“ (SI1)

Ein Projektmanager wittert hinter dem Wunsch, bei der Aufgabenverteilung mitzubestimmen
gleich das Verlangen nach inhaltlicher Spezialisierung, wenn er auf die Frage, ob die EntwicklerIn-
nen Mitsprachemöglichkeiten bei der Verteilung der Arbeitsaufgaben haben, antwortet:

„No, usually not. They are usually ... they don’t actually. If they want to specialize
we give them, we have certification plans, actually. Like you can study those technical
things and give certifications. That they can pick up. But work-wise eh within project,
they cannot choose what they want to do. Usually they don’t come back to us saying
that they don’t want to do it. It rarely happens.“ (SI14)

Und auch ein Modulleiter unterstreicht diesen Eindruck eher unfreiwillig:

F: Do you discuss the distribution of tasks with your software engineers?

„Yah, we keep asking them also: are you comfortable doing all this, will you be able to
complete in the equivalent time?“
F: And it’s also possible to say: ’No I don’t like the task I want another one?’
„No, this never happened. ... They are comfortable doing it ... mostly.“ (SI22)

Probleme und Widersprüche der Aufgabenorganisation

Betrachtet man die Praxis der Aufgabendefinition und -verteilung bei ServiceTec, so ist es we-
nig überraschend, dass die an Entwickler vergebenen Arbeitsaufgaben meist nur geringe kreative
Anforderungen an diese stellen und dementsprechend auch als monoton und der eigenen Beein-
flussung entzogen wahrgenommen werden. Die folgenden Äußerungen einer Entwicklerin bzgl.
ihrer täglichen Arbeitsaufgaben bestätigen diese These plastisch:

„Boah .... [laughs] Boring ... boring I can say in the end, when there were lots and lots
of reports and ok, I used to say: ‘Ok, this is the same whole thing I have to do.’ Yah,
that time, in the end ... Because I think I coded more than seven reports in a row. So in
the end it was like: Ohhh, one more report to go. And that time it did become a little
monotonous . . . I should say. Not boring, but yah, monotonous is. . . It became quite
monotonous, as in, ok, same whole XML-XSL-testing and all. (SI2)

Ein anderer Entwickler teilt diese Ansicht:

86 Fallstudie ServiceTec

„F: What are the most interesting or most challenging parts of your working tasks?
„Most challenging part of it ... normally associates not with technology, but with un-
derstanding the business aspect behind it. The business is pretty complex when it ...
whichever field you go to, be it banking or be it retail – the business part is the complex
part. Putting the technology behind it, putting the code behind it is – not as thrilled.
So, yes, understanding the business part is the most challenging part of it.“
F: And what are the most boring parts?
„Most boring part is ... screening processes again and again for everthing. At time it
gets boring. Even for a small change you have to do a intensive testing. It becomes
monotonous at those times.“ (SI20)

Dieser Entwickler findet bezeichnenderweise genau jene Tätigkeiten interessant, die er als Ent-
wickler gar nicht bearbeitet. Dass er trotzdem Erfahrung mit dem Geschäftsumfeld der Kunden
hat, und daher weiß, wie spannend es ist, die geschäftlichen Hintergründe hinter der technologi-
schen Umsetzung zu verstehen, liegt daran, dass dieser Entwickler im Zuge einer kurz bevorste-
henden Beförderung bereits erste Aufgaben eines Modulleiters – sozusagen „zum Test“ – übertra-
gen bekommen hat15 und daher gegenüber „reinen“ Entwicklern bereits ein umfassenderes Tätig-
keitsprofil besitzt.
Eine andere Entwicklerin arbeitet in einem Maintenance-Projekt und fühlt sich weniger inhalt-
lich als vielmehr durch den permanenten Zeitdruck herausgefordert:

F: If you look at the working tasks you have to perform on a day, what would you
think, are the most challenging tasks? „Eh, most challenging tasks are, eh, one of them
was like yesterday eh, yesterday’s tasks, when actually you have to solve the issue
immediately, you don’t have any time to think or whatever, you just need to fix it as
soon as possible. And the client is pushing you, that it’s really urgent, because it’s on
the live side and people are visiting it very frequently. In that case you really need to
rush up and if you are not aware of the flow, it’s really difficult to get things solved.
And otherwise, if we have time or we have some daily requests, that are routine level
requests, in that cases, it’s ok.“ F: And the most boring tasks? „Most boring tasks are
while using this content management tool, when we make the changes on the live
servers [lacht] because they are really monotonous and they come every day, because
every day we have a little bit of changing, one or two of the sites.“ (SI21)

Dieselbe Entwicklerin ist es dann auch, die ihre Ansicht über den Arbeitsalltag, den sie als mo-
notone Routine erlebt, auf den Punkt bringt, indem sie in Reaktion auf den Dank für das Interview
antwortet:

„It was a real nice interview [...] It’s really different from the monotonous routine,
that I have over the day.“ (SI21)

Eine andere Programmiererin führt aus, dass sie sich in ihrem Projekt stark unterfordert fühlt.
Ihr obliegt die Wartung einer bestimmten Unterfunktionalität eines Programmes, die Abhängig-
keiten zu den anderen Teilen der Applikation sind ihr im wesentlichen unbekannt:

„Work-wise - yah, I mean it’s really difficult initially to know the entire big system.
You’re given some defect or some ... some work and you’ll not be knowing the whole
15
Zu weiteren Fragen der Beförderungen bei ServiceTec, siehe auch Kapitel 5.3.4
Betriebliche Kontrollstrategien bei ServiceTec 87

module, even if you know some programs. Or what is the impact that it is going to
make, if you’re making ... a small change in some part, how is it gonna impact the
other parts and all. [...] Since it’s a maintenance project you’ll do some enhancements
and you just have to find out where’s the problem and change it and fix it. So it’s not
a very... very big challenge or something [spricht den letzten Satz leiernd].“ (SI1)

Dem von ihr geäußerten Wunsch nach anspruchsvolleren Aufgaben wurde in der letzten Zeit
nicht entsprochen:

„So I’m like ... for the past six months I have been telling that I want something chal-
lenging, I want something different, new, because I am used to - I know the system
now. I can finish it fast and there’s nothing I did, which broke my head.“ (SI1)

Dementsprechend wirkt die Schilderung ihres Arbeitstages auch wie ein Warten auf den Feier-
abend:

„Nowadays average has become there’s one bug a day. So [laughs] I mean - it gets over!
Morning, when I come, I reach by 10 o’clock. Then I check - then I see whether I can
understand the bug or not. Then I start working on it. By five o’clock it gets over.“
(SI1)

Ähnlich wie bei der zeitlichen Länge der Arbeitspakete zu beobachten, unterscheidet sich auch
die Attraktivität der Arbeit zwischen Entwicklungs- und Wartungsprojekten. Dabei spielt eine
große Rolle, dass man sich bei Wartung und Erweiterung einer bestehenden Applikation an der
bestehenden Architektur der Applikation orientieren muss, was die eigenen Gestaltungsmöglich-
keiten einschränkt. Zudem handelt es sich in diesen Projekten meist um weniger komplexe Ar-
beitsgegenstände als bei Entwicklungsprojekten. So berichtet eine Entwicklerin aus einem Main-
tenanceprojekt:

„We had to follow the same pattern [as the rest of the already existing application
- PF], because it was a typical Java project, a web application, where is a three-tier
architecture [dreischichtige Systemarchitektur] and all. Code-wise we couldn’t make
more changes. We didn’t have options.“ (SI2)

Sie wünscht sich daher auch, zukünftig eher in Entwicklungsprojekten eingesetzt zu werden:

„Yes, exactly. I think that's the main difference between a development and a mainte-
nance. Because it was a maintenance I was supposed to follow whatever is been pre-
viously done by my seniors or whatever is been done by the client itself. And I think,
if it’s a development, then a coder can create .... can have his own ideas, can put forth
his own ideas to the manager: ‘Ok, we can do it... we can do it in this way, it might
reduce time, or it might increase the performance.’ But I was unlucky to ..., as in I’ve
never been a part of development projects. Initially, when I was a fresher I was a part
of a development project, but that time I was extremely new. I didn’t know, I couldn’t
put foward my ideas at that time. But once I got to. . . got well-wise with the projects,
I was put into maintenance. So there was not much of creativity to be shown.“ (SI2)
88 Fallstudie ServiceTec

Wie anhand solcher Aussagen von Entwicklern anschaulich gezeigt werden kann, bleiben die Ef-
fekte der Form der Aufgabenorganisation auf die Beschäftigten nicht aus. Die Darstellung der Auf-
gabenorganisation bei ServiceTec wäre allerdings unvollständig, wenn nicht auch erwähnt würde,
dass deren immanente Widersprüche den Führungskräften bei ServiceTec durchaus bewußt sind.
Eine Modulleiterin beschreibt das Dilemma in folgenden Worten:

„Say if you are fixing a particular problem and in the same architecture you can fix it in
more than one way. And it is possible that the way the software engineer has chosen is
more innovative and more performance oriented than the way you are thinking. That
is also a possibility. So if we cut the idea at that instance itself, then we, he will not be
able to put forth his ideas and put forth his way. But if it, if what he has implemented
is not correct or is not performant enough, then you can always ask him to change it.
But if you start telling him from the beginning, he would never be able to analyze the
things on his own and that is growth as well. So we make sure that the person analyzes
things and get the hands on the code and we also see that it is performant enough and
it is, it complies to the architecture and it doesn’t affect other pieces of the code. There
is a balance that has to be brought in place.“ (SI12)

So besteht bei Service also durchaus ein Bewußtsein dafür, dass das Vorgehen, den Beschäftigten
sehr kurze, wenig komplexe und kleinteilig vorspezifizierte Arbeitspakete zuzuweisen, die quali-
fikatorische Entwicklung der Beschäftigten unterminieren kann, was langfristig nicht zum Wohle
der Firma sein könnte. Mit ihrer Forderung nach einer „Balance“ zwischen Selbstorganisation und
Anweisungen durch Vorgesetzte stellt die zitierte Modulleiterin bei ServiceTec jedoch eine Aus-
nahme dar.
Auch ein Vertreter des hohen Managements weiß, dass die Form der Aufgabenorganisation Un-
zufriedenheit auf Seiten der Entwickler auslöst:

„If you say ’No, process is the only way you can achieve your aim and you can’t change
it’, then people will say: Hell with you! I know more then what is there.“ (SI9)

Das Bewußtsein für diesen Widerspruch hat aber auf der operativen Ebene nur geringe Auswir-
kungen. Grundsätzlich gesteht der folgende Interviewpartner den Entwicklern die Möglichkeit
zu, eigene Ideen und Ansätze einzubringen. Jedoch setzt er solche Vorschläge gleich unter Beweis-
pflicht:

„Now when I go there and say I’m doing it my own way, this is better, then they have
to prove it is better. If they prove it is better, it goes as process, others have to follow.
If they can’t – then they have to follow what is there.“ (SI7)

Die Beschäftigten können also an der punktuellen Verbesserung der Prozesse partizipieren, ja
sollen dies sogar. Mit Einflußnahme auf die Art der Ausführung der täglichen Arbeitspakete hat
dieses Verständnis allerdings sehr wenig zu tun. Zudem ist angesichts der knappen Zeitrahmen
der Projekte bei ServiceTec und der Komplexität der Planungen leicht ersichtlich, dass es für die
Entwickler nur sehr schwer möglich sein wird, die Überlegenheit ihres Ansatzes zu beweisen.
Desweiteren wird von Projektmanagern auch nicht bestritten, dass eine Spezialisierung auf be-
stimmte Bereiche und die Erlangung von Erfahrungswissen von Entwicklern in eben jenen Berei-
chen durchaus zu besseren und vor allem schnelleren Ergebnissen führen könnte. Doch zu stark
ist die Angst vor Abhängigkeiten von einzelnen Personen, die die Fähigkeit der Firma limitieren
Betriebliche Kontrollstrategien bei ServiceTec 89

würde, Beschäftigte flexibel zu verteilen und die Firma verlassende Beschäftigte schnellstmöglich
zu ersetzen. So wird dieses Dilemma bei ServiceTec durchaus bewußt durch Verzicht auf Spe-
zialisierung zugunsten einer höheren Unabhängigkeit von einzelnen Personen aufgelöst. Die bei
ServiceTec dominierende Haltung gegenüber Entwicklern drückt sich beispielhaft in folgender
Aussage eines HR-Managers zum Beförderungsprozess bei ServiceTec aus:

„As in moving to senior level, mid management and senior levels, we’d also have ... not
only loading the person with work to see, whether the person is able to cope, but stress
by doing multiple things, larger reporting, you know, unstructured way of work, etc.
and all this stuff. Work in different areas, other than the core track itself. We’ll also
do an interview to see, whether the person can think, not only do, but can also think that
way, independently. [...] It is more than just the execution of routine activities. [...]
Because sometimes, because the person, if he’s doing the same kind of work for two,
three years, can easily take on the next responsibility in terms of executing. But the
thinking may not hold this. So we, when we move people, we not only want doers, we
want thinkers also, as in: it’s a mix of thinkers and doers as they .... go up the hierarchy.
(SI7 – Hervorhebungen durch den Verfasser)

Die demonstrative und überraschend deutliche Entgegensetzung von Ausführung auf den un-
teren Stufen und erst mit Beförderung in höhere Positionen notwendig werdender Fähigkeit zum
eigenständigen Denken spiegelt beispielhaft die bei ServiceTec vorfindbare Form der Aufgabenor-
ganisation wider.

5.3.2 Kontrollstruktur
Die Untersuchung der Aufgabenorganisation bei ServiceTec hat ergeben, dass die allgegenwärti-
gen Prozessbeschreibungen ein ganz zentrales Mittel zur Definition und Zuweisung der Arbeits-
aufgaben an die Entwickler sind. Ebenso konnte gezeigt werden, dass diese Prozessbeschreibungen
bereits ganz wesentliche und detaillierte Vorgaben darüber enthalten, wie die jeweiligen Arbeits-
aufgaben zu bearbeiten sind. Bei diesen formellen Vorgaben handelt es sich demnach um sehr weit-
reichende Instrumente, die Handlungsmöglichkeiten von Entwicklern – bei leichten Unterschie-
den zwischen den verschiedenen Projektarten - stark einschränken. Auch wenn diese Instrumente
von ServiceTec als sehr vertraulich behandelt werden, und die konkreten Prozessbeschreibungen
im Rahmen dieser Studie leider nicht direkt eingesehen werden konnten, so lässt sich aus den
Beschreibungen der betroffenen EntwicklerInnen und der Module Leads doch deutlich ersehen,
dass diese Prozessvorgaben und Templates bis in die Programmierdetails hineinreichen und den
Arbeitsprozess auch auf der individuellen Ebene stark strukturieren.
Die Prozessbeschreibungen stellen bei ServiceTec auch ein zentrales Element der Kontrollstruk-
tur dar, da sie die Art der Bearbeitung durch die Entwickler anleiten und auch als Vorgabe behan-
delt werden, gegen welche die von den Entwicklern geleistete Arbeit überprüft und bewertet wird.
Dabei lassen sich verschiedene Ebenen unterscheiden, auf denen Prozessbeschreibungen auch für
die Kontrollstruktur relevant werden.

Anleitung und Anweisung

Zunächst beinhalten die an die Entwickler verteilten Aufgaben stets nähere Vorgaben hinsichtlich
der in diesem Arbeitsschritt zu erstellenden Dokumente, Code-Artefakte o.ä. Nach Angaben der
Entwickler enthalten diese Vorgaben zumeist neben ausführlichen Informationen zu der Art und
90 Fallstudie ServiceTec

Weise, in der die Arbeitsaufgabe bearbeitet werden soll, zudem Checklisten, mit deren Hilfe die
Entwickler am Ende jedes Arbeisschrittes einen ersten Selbsttest ihrer Arbeit vornehmen sollen
und so feststellen können, ob der ihnen aufgetragene Arbeitsschritt in allen Belangen bearbeitet
und damit beendet ist.
Wenn nach diesem ersten Selbsttest der Entwickler die Arbeitsaufgabe als erledigt gekennzeich-
net hat, folgt ein weiterer Testzyklus, in dem die Entwickler untereinander ihre Arbeiten gegen-
seitig kontrollieren und gegen die Vorlagen und Vorgaben testen. Diese gegenseitigen Testphasen
werden durch spezielle Systeme bei ServiceTec computertechnisch unterstützt. Ein Projektmana-
ger erläutert den Vorgang exemplarisch:
„So what will happen is, they (die Software Entwickler - PF) will complete their task
and depending on the configuration management process. These people would put
that artefact into a certain location and the reviewer, whoever has been assigned to
review the task, that reviewer can be a manager or it can even be a peer review. Ok, so
that peer or manager will pick up that task and in the meanwhile the developer will
move on to another task, while the peer and manager would review his task and give,
log his comments in the system itself. Yeah, we have a very strong system, which sup-
ports the software development lifecycle stages. He would log in the comments into
the system itself and the system would automatically send messages to the developer,
what has to be corrected.“ (SI19)
Das von ServiceTec genutzte System enthält also alle an den Entwicklern zugeordneten Aufga-
ben und ermöglicht es, Teilarbeiten im Laufe ihrer weiteren Bearbeitung zu verfolgen. Wenn daher
im Laufe des Testverfahrens Fehler in einem Teil gefunden werden, können die mit dem Test des
Codes befassten Entwickler entsprechende Kommentare im System hinzufügen und die Korrek-
tur des Fehlers wird automatisch an den verantwortlichen Entwickler zurückgemeldet. Auf diese
Weise werden die Arbeitsaufgaben nicht nur sehr intensiv und formalisiert ständig überwacht, die-
ses System hilft ServiceTec zudem, wichtige Informationen über die Arbeitsleistung der einzelnen
Entwickler zu erheben, um diese entsprechend bewerten zu können. Wir werden auf diesen Punkt
später zurückkommen.
Die Prozessbeschreibungen und die damit einhergehenden engen und detaillierten Vorgaben
sind somit ein ganz wesentliches Instrument der Kontrollstruktur bei ServiceTec, da sie die Ver-
richtung der Arbeit durch die Entwickler anleiten und auf der Ebene der Arbeitsaufgaben auch
eine Referenzfolie bilden, gegen die die einzelnen Arbeiten der Entwickler anschließend auf unter-
schiedlichen Ebenen geprüft werden.

Überwachung des Arbeitsablaufs

Zudem bilden die kleinschrittige Planung und die kurzen Zeitrahmen der Arbeitsaufgaben auch
die Grundlage für eine konstante und enge Überwachung der Arbeitsabläufe. In dieser Hinsicht ist
die Position des Modulleiters von entscheidender Bedeutung. Der Modulleiter ist die entscheiden-
de Brücke zwischen dem Projektleiter und den Entwicklern. Er fungiert einerseits als fachlicher
Vorgesetzter für die Entwickler und hilft bei Problemen auf der operativen Ebene. Andererseits ist
er auch für die konkrete Zuteilung der Arbeitspakete an die Entwickler zuständig und überwacht
den Bearbeitungsprozess. Dies wird durch die räumliche Anordnung der Projektteams vereinfacht.
Der Modulleiter befindet sich gewöhnlich direkt neben dem Cubicle16 des Modulteams. Er ist so-
mit in der Lage, jederzeit zu sehen, woran die Entwickler gerade arbeiten.
16
Zur räumlichen Anordnung der Projektteams, siehe auch Kapitel 5.3.1.
Betriebliche Kontrollstrategien bei ServiceTec 91

Wie bei direkter, persönlicher Kontrolle generell, gibt es in der Wahrnehmung dieser Kontroll-
funktion durchaus Spielräume für den Modulleiter und somit auch Unterschiede in der konkreten
Überwachung der Arbeitsprozesse. So unterscheiden sich die Modulleiter der befragten Projekt-
teams etwa hinsichtlich der Frequenz, in der sie sich über den Status der Aufgabenbearbeitung
informieren und der Arbeitsfortschritt dokumentiert wird. So ist es einigen Module-Leads eigen,
sich täglich von „ihren“ Entwicklern über den Fortschritt ihrer Arbeiten unterrichten zu lassen.
Andere hingegen belassen es bei weniger häufigen Kontrollen oder setzen eher auf informelle un-
regelmäßige Treffen mit den Entwicklern. Für alle Projekte gibt es jedoch mindestens einmal die
Woche ein vorgeschriebenes Statustreffen, auf dem der Modulleiter zusammen mit dem zuständi-
gen Projektmanager den Fortschritt der verteilten Arbeitsaufgaben formell kontrolliert.

Interessant ist, dass (wie auch schon für Aktivitäten im Feld der Aufgabenorganisation konsta-
tiert wurde) der Zyklus, in dem der Fortschritt in den Projekten kontrolliert wird, nicht nur durch
die strategischen Ziele von ServiceTec bestimmt wird. Auch hier wirkt sich der für IT-Dienstleister
typische Kundenbezug auf die organisatorischen Formen bei ServiceTec aus. Die Kunden Service-
Tecs – und unter diesen angeblich die deutschen noch viel mehr als z.B. die amerikanischen – haben
nach Angaben von Projektleitern die Präferenz, sich extrem kurztaktig über den Fortschritt der
Projekte unterrichten zu lassen. Dabei kommt es regelmäßig zu Konflikten zwischen SericeTec
und dem Kunden. Ein Projektleiter berichtet einen solchen Fall aus seinem Projekt:

„We do get reports on a weekly basis. And for one of my new clients, that I have
started, actually they get a status report every day. There is a call of half an hour fixed
every day. And my project manager gets into a call with their project manager and they
discuss what has happened today and what is gonna be done tomorrow. So ... giving a
status update is a part of our whole project management. That never gets missed out.
But the fact that, if my project manager says, that there are 5 people who had done this
particular task, and they have coded some x number of programmes ... Obviously you
are not seeing the program, because it’s not tested and delivered to you. So you have
to have the trust .. that whatever this project manager is saying is .. is true, is not a lie.
I think that’s where the distrust happens. Because, as I said, in software everything is
intangible, you can’t see. I can’t make, you know, half of the code, take a photograph
and send it to you: ’Look, that’s where your equipment stands. It will get completed
in four days. I can’t take a photo of the code and sent it to you, so...’. [...] And a lot
of customers do immediately ask, that, you know: Please, deliver the code! We would
like to review and see how much you’ve done.“ (SI16)

In dieser Schilderung des Projektmanagers zeigt sich sehr deutlich das Problem, das aus dem di-
rekten Kundenkontakt für ServiceTec erwächst. Nach Schilderungen der Personen, die in Deutsch-
land vor Ort bei den Kunden arbeiten, sind es vor allem Ängste vor schlechter Qualität der ge-
lieferten Leistungen speziell auch von indischen IT-Dienstleistern, die beim Kunden dieses starke
Kontrollbedürfnis auslösen. Dies setze sich dann bei der Auftragsvergabe nicht nur in feinmaschige
Projektpläne mit kurzen Entwicklungszyklen um, sondern eben auch in häufige Statusmeldungen
über den Fortgang der Arbeiten bei ServiceTec. Dabei übertreffen viele Kunden anscheinend mit
ihren Wünschen nach Statusmeldungen noch den Grad, zu dem ServiceTec selbst den Fortschritt
der Arbeiten erheben möchte. Hier zeigt sich demnach sehr schön, wie die strategische Orien-
tierung ServiceTecs, vor dem Hintergrund der hohen Fluktuationsraten am indischen Standort
die Arbeitsprozesse möglichst unabhängig von einzelnen Entwicklern zu machen, mit den Erfor-
92 Fallstudie ServiceTec

dernissen des verfolgten Geschäftsmodells in Form des Kundenbezuges zusammenwirkt und sich
beide Aspekte gegenseitig verstärken.

Um solche kurztaktigen Informationen über den Projektverlauf zu gewinnen und den Status des
Projektes stetig abschätzen zu können, wird der Bearbeitungsvorgang durch das gleiche Compu-
tersystem begleitet, das auch zur Verteilung der Arbeitsaufgaben genutzt wird und das weiter oben
in diesem Kapitel bereits im Zusammenhang mit den gegenseitigen Testverfahren der Entwick-
ler erwähnt wurde. Über dieses System – an das alle Entwickler mit ihren Arbeitsplatzrechnern
angeschlossen sind – erhält jeder Entwickler die vom Modulleiter verteilten Arbeitsaufgaben als
eine Task-Liste zugeordnet. Die zugewiesenen Tasks werden bereits mit der vorgesehenen Bear-
beitungszeit übermittelt. Damit ist der Zweck dieses Systems jedoch noch nicht erfüllt. Vielmehr
wird es auch während der Bearbeitungsphase von den Entwicklern zur Erfassung der auf diese
Aufgaben verwandten Arbeitszeit genutzt, d.h. die Entwickler dokumentieren in diesem Tool ih-
ren Arbeitstag. Es ist auf allen Rechnern bei ServiceTec installiert und so für die Entwickler stets
zugänglich. Wann immer die Entwickler eine Aufgaben beginnen und beenden, wird es in diesem
Tool vermerkt, genauso wie Pausen, Projekttreffen uvm. Nach Angabe der Entwickler wird in die-
sem Tool die verwandte Arbeitszeit sehr detailliert, teilweise sogar im Minutenbereich gemessen.
Die Überwachung der Arbeitsprozesse ist also auch auf dieser computergestützten Ebene sehr
eng. Somit besteht unabhängig davon, in welchen Abständen der jeweilige Modulleiter sich for-
mell im direkten Gespräch mit den Entwicklern seines Moduls über den Fortschritt der Arbeiten
erkundigt, stets die Möglichkeit, den Status der Bearbeitung anhand der im System erfassten Ar-
beitszeiten und -aufwände abzuschätzen.
Die Dokumentation der geleisteten Arbeitszeit dient dabei auf der einen Seite zur Abrechnung
von Arbeitsstunden gegenüber dem Kunden. Auf der anderen Seite gehen diese Informationen
jedoch auch in die interne Evaluation der Zeitschätzungen für die anfallenden Arbeitsaufgaben
ein. So dienen sie zur stetigen Weiterentwicklung des Zeitschätzungsmodells, das bei ServiceTec
zur Aufgabendefinition verwandt wird.

„There is a system in ServiceTec, which tracks the work, eh, and the timings for Ser-
viceTec purpose and there is a system with the customer, which again tracks hourly
working hours - that is taken care of by the manager, who communicates with the
customer. So, they have a system, which tracks on an hourly basis, because they are
paying ServiceTec for this many hours.“ (SI13)

Auch an dieser Stelle dient die Form der Kontrollstruktur also gleich mehreren Zwecken. Wie
in der zitierten Aussage zu lesen, ist die exakte Erfassung der von den zugeteilten Entwicklern auf
ihre Arbeitsaufgaben verwandten Arbeitszeit natürlich für den Kunden interessant, v.a. wenn es
sich um ein nach Aufwand vergütetes Projekt handelt17 , weil die geleistete Arbeitszeit maßgeblich
seine Aufwände determiniert.
Auf der anderen Seite ist die Zeit, die die Entwickler für die Bearbeitung ihrer Arbeitsaufga-
ben benötigen, natürlich, wie bereits erwähnt, auch für ServiceTec selbst interessant, da sich hier
evtl. wichtige Abweichungen von den getätigten Zeitschätzungen für spezifische Arbeitsaufgaben,
sowohl positiver als auch negativer Art, finden, die der weiteren Optimierung dieses Zeitschät-
zungssystems dienen können.
17
Diese Form der Projektvergütung stellt bei ServiceTec nach Angaben der Projektmanager die häufigste Form dar,
sehr selten seien hingegen die Projekte, die per Festpreis für die gelieferte Leistung abgerechnet würden.
Betriebliche Kontrollstrategien bei ServiceTec 93

Messung und Bewertung von Arbeitsleistung

Schließlich gehen die Daten der Überwachungssysteme jedoch auch ganz unmittelbar in die Mes-
sung und Beurteilung der Leistung des jeweiligen Entwicklers ein. Diese wird grundsätzlich in
halbjährlich stattfindenden Treffen verhandelt:

„That is the performance management mechanism, which we have. What we say is that
every individual in this organization needs to be appraised by the manager necessarily
twice a year.“ (SI7)

An diesen Terminen wird die Leistung jedes Beschäftigten in einem recht aufwändigen Verfah-
ren bewertet. Grundlage des Bewertungsverfahrens sind Zielvereinbarungen, die für jeden Beschäf-
tigten am Anfang eines Bewertungszyklus in Diskussion mit dem zuständigen Manager festgelegt
werden und deren Erfüllung dann über das halbe Jahr verfolgt und anschließend bewertet wird.
Diese Ziele beinhalten auf der einen Seite sogen. „weiche“ Ziele. Diese beziehen sich auf die
persönliche Entwicklung des Beschäftigten in zentralen Kernkompetenzen. Dazu wurde für jede
Funktion im Unternehmen ein spezifisches Set an Kernkompetenzen bestimmt. Die Zusammen-
setzung dieser Kernkompetenzen und deren Schwerpunkte unterscheiden sich damit zwischen den
verschiedenen Tätigkeitsprofilen und Hierarchiestufen, jedoch enthalten sie stets eine Kombinati-
on fachlicher und sozialer Kompetenzen:

„For every role we identify a set of competencies. These competencies were in two
areas: one was technical and the other was behavioral. For example - this is based on
the job, which a person was supposed to do. For example for a software engineer
the person is supposed to be good in programming, design, you know, supposed to
be good at analytical ability, should be good in coding frameworks, methodologies
etc. Those are some of the technical competencies. Then on the behavioral side, the
person is supposed to be able to perform in a team, has to be a team worker, should be
good at communicating. So those are some other behavioral competencies, which are
identified.“ (SI7)

Zielvereinbarungen hinsichtlich dieser „weichen“ Qualifikation der Beschäftigten können da-

mit z.B. in Abmachungen über anzustrebende Fortschritte in der Kommunikationsfähigkeit oder
bestimmten technischen Qualifikationen bestehen. Solche Ziele beinhalten dann entweder die Teil-
nahme an bestimmten Fortbildungskursen oder firmeninternen Zertifizierungsprogrammen, oder
bestimmte Aufgaben, die on-the job erledigt werden müssen. Ein mögliches Ziel für einen Entwick-
ler kann demnach z.B. darin bestehen, im nächsten halben Jahr in 3 verschiedenen Technologien
gearbeitet zu haben oder eine bestimmte Zahl von Präsentationen im Team gehalten zu haben.
Leider konnten im Rahmen der hier vorliegenden Untersuchung nur wenige Beispiele verein-
barter Ziele erhoben werden, da diese im Unternehmen sowohl von der Seite des Managements,
als auch von Seiten der Beschäftigten als sehr vertraulich behandelt wurden. Klar ist aber, dass
zusätzlich zu diesen eher groben Zielvereinbarungen hinsichtlich der weiteren persönlichen Ent-
wicklung auch noch ein zweiter Block Gegenstand der Zielvereinbarungen ist, der sich auf die
Arbeit des jeweiligen Entwicklers in den nächsten 6 Monaten und deren Qualität bezieht.

„In the beginning of this appraisal cycle, your manager would have set some goals
for you. And there would be tasks set, what is expected from you in this, during this
cycle.“ (SI13)
94 Fallstudie ServiceTec

In Bezug auf die zukünftige Arbeitsleistung werden demnach von Vorgesetzten Erwartungen
formuliert, die sich mit Pünktlichkeit, Qualität, Kundenorientierung, Problemlösungsfähigkeiten
und Teamfähigkeit auf fünf Aspekte der zu leistenden Arbeit beziehen:

„For every grade we have a set of expectations which are very clearly written down.
[...] There are 5 parameters. [...] The 5 parameters would be, one is timeliness, one is
quality of work, one is customer orientation, one is providing optimal solution and
the last is team satisfaction.“ (SI20)

Die Aussagen der Beschäftigten zeigen, dass diese Vorgaben durchaus quantitativ gefasst wer-
den. So wird häufig eine vorgegebene Fehlerrate bei der Programmierung genannt, die nicht über-
schritten werden dürfe, und auch Erwartungen hinsichtlich der Abweichungen von Zeitvorgaben
wurden klar und detailliert festgesetzt. Die Ziele, die sich auf die weitere persönliche Entwicklung
beziehen, waren demhingegen eher lockerer und qualitativer Art. Das drückt sich auch in dem
Grad aus, zu dem die Zielvereinbarungen von den Entwicklern in diesen Verhandlungen beein-
flußt werden können. So berichten Betroffene darüber, dass die Ziele hinsichtlich der zukünftigen
Arbeitsverrichtung in den Gesprächen mit dem Vorgesetzten kaum zu beeinflussen sind, da es sich
dabei um vorgegebene Erwartungen ServiceTecs hinsichtlich der durchschnittlichen Fähigkeiten
der eingesetzten Entwickler handelt. Etwas offener scheint die Situation bei den „weichen“ Zielen
zu sein. So berichten einige Entwickler, dass sie durchaus Wünsche hinsichtlich der weiteren Fort-
bildungskurse und technischen Weiterqualifizierungen äußern durften, die teilweise auch berück-
sichtigt wurden. Ganz grundsätzlich kann aber davon ausgegangen werden, dass die Einflußnahme
der Entwickler auf ihre Zielvereinbarungen eher gering ist.

„Gemessen“ wird die Leistung der Entwickler schließlich in Graden der Erwartungserfüllung
hinsichtlich dieser Zielvorgaben:

„If you have done your task and have done much more than that, then you would be
given good rating. [...] There are ratings given based on, if it is satisfy, satisfy prior,
if it is extraordinary or under expectations or met expectations, beyond expectations.
Based on that the ratings will be given on every task, which you have done during the
cycle.“ (SI13)

Der Bewertungsprozess selbst verläuft in mehreren Schritten. Auf eine Selbstbewertung des Ent-
wicklers folgt die Bewertung durch den direkten Vorgesetzten. Anschließend wird in einem Ge-
spräch über die beiden Bewertungen und eventuelle Unterschiede gesprochen. Sollte sich in diesem
Treffen keine Einigung erzielen lassen, so ein Proektmanager, so könne die Bewertung durch den
nächsthöheren Manager entschieden werden:

„So the process we follow: first, the person would do a self rating. Then the manager
would do a rating. Then a competency rating – identify a set of development plans,
identify areas of improvement. Then send that, the overall evaluation, back to the
appraisee. Then the appraisee and the appraiser, they would have a discussion, and
in which – if the appraisee agrees to what the rating said then he or she closes the
appraisal saying: Yes, I agree to my appraisal. If there’s some kind of disagreement
between the two, then the reviewer, who’s the next level manager, comes in place and
tries to understand what’s the issue and tries to solve it often times.“ (SI7)
Betriebliche Kontrollstrategien bei ServiceTec 95

Auch wenn die Entwickler den Bewertungsprozess bei ServiceTec grundsätzlich als sehr trans-
parent und nachvollziehbar loben, bleibt der Einfluß der Entwickler auf ihre Bewertungen doch
nach eigenen Angaben sehr begrenzt. Auch hier deutet sich ein kleiner Unterschied zwischen den
harten, quantitativen und den weichen, qualitativen Zielen an. Ob sich z.B. ein nicht besuchter
Fortbildungskurs negativ auf die Bewertung auswirkt, kann u.U. mit Blick auf Projekterfordernis-
se noch diskutiert werden. Im Gegensatz dazu wird bei ServiceTec versucht, die im letzten halben
Jahr gezeigte Arbeitsleistung möglichst exakt zu erheben und unmittelbar in die Bewertung einge-
hen zu lassen.
So gehen in diese Bewertung – wie bereits erwähnt – die aus der Arbeitszeiterfassung gewon-
nenen Informationen ein. Sie liefern dem Management wichtige Informationen darüber, ob der
Entwickler in der Lage war, die zeitlichen Vorgaben einzuhalten oder seine Aufgaben schneller
oder langsamer erledigt hat. Ein Vertreter des höheren Managements beschreibt stolz den Umfang
und den Nutzen der gewonnenen Informationen:
„When you are recording on a minute by minute basis of an employee, the process
is nothing but an input for data. So the key thing is, all the input you get. Today in
your university, if you guys have this process, it will tell me what you should do.
But how will the process work if the input data is not there? But imagine, if I would
have got hold of all the data of the past annuals you guys have done officially in your
professional lives and you set it to CMM and all the very powerful tools, you run them
through that tool. I am pretty confident I would actually know what each of you is
good at and whether you work good together in a team or not. Because I have that
input data, I have input of hundreds of thousand of people, man hours, projects, on
and on. [...] So, if you go to my system and press the key saying, you know, I am just
doing some academic discussion and that’s it. As soon as I go back I press again and I
say: cigarette break – so I’ll go down and have a cigarette. And it’s just the key [...], so
please understand, my own productivity is being measured at that level. And I am not
even a technical guy! [...] If you fix the process, if you have the input data correct, I am
quite confident I could do the same for the two of you. If I knew last ten years, every
minute of your activities in your professional life. So processes are just a set of rules,
or rules engines, rather. But it’s the data which goes in which is important.“ (SD6)
Auch wenn dem zitierten Manager unterstellt werden kann, die Reichweite der gewonnenen
Informationen etwas übertrieben darzustellen, wird doch ersichtlich, wie wichtig die aus den Ar-
beitszeiterfassungssystemen gewonen Daten für ServiceTec sind.
Doch es sind nicht nur die Ergebnisse der Arbeitszeitverwaltung, die in diese Bewertungen ein-
gehen; hinzu kommen andere computergestützte Systeme, die u.a. diesem Zweck zuarbeiten. So
werden auch die bereits erwähnten Systeme, die das Testen der von den Entwicklern geschriebe-
nen Programmteile unterstützen, mit einbezogen. Neben der Schnelligkeit der Programmierung
zählt schließlich auch die Qualität der geleisteten Arbeit. Und so können z.B. über die Testsysteme
Informationen darüber gewonnen werden, auf wieviel Zeilen Code der Entwickler wieviele Fehler
gemacht hat und welcher Art diese waren. Für die Ebene der Entwickler stellt diese „Fehlerquote“
einen zentralen Maßstab zur Bewertung der Qualität der Arbeitsleistung dar und beeinflusst damit
auch ganz maßgeblich das Ergebnis der Beurteilung.
Im Gegensatz zu den „weichen“ Zielen, kann nach Angaben der Entwickler die Bewertung in
Bezug auf diese „harten“ Zielvorgaben nur sehr begrenzt diskutiert werden. Von daher ist der
Eindruck der Beeinflußbarkeit, der vom Management stets erweckt wird und der dadurch schein-
bar bestätigt wird, dass die Beschäftigten zunächst sich selbst bewerten und die Gesamtbewertung
96 Fallstudie ServiceTec

schließlich im gemeinsamen Gespräch festgelegt wird, nach Berücksichtigung der Aussagen der
Entwickler eher irreführend. Immerhin entpuppt sich die Bewertung als ein recht rigider Prozess,
in dem die Entwickler von Firmenseite mit fixen Leistungsanforderungen konfrontiert werden.

Gemäß der individuellen Bewertungen werden die Beschäftigten anschließend in vier unter-
schiedliche Leistungsgruppen eingeteilt, wobei die erste Kategorie diejenigen umfasst, die die an
sie gestellten Erwartungen übertroffen haben und die vierte Kategorie jene, die stark hinter den
Erwartungen zurückgeblieben sind. Unabhängig von diesen vier Leistungskategorien werden auch
alle Beschäftigten eines Projektes in ihren Hierarchiestufen nach Leistungen in eine Rangliste ein-
geordnet. Die Rangliste wird anschließend für alle Beschäftigten zugänglich gemacht, so dass alle
sehen können, wo sie leistungsmäßig innerhalb des Teams stehen. Hier deutet sich schon ein Merk-
mal der Gestaltung der internen Kooperationsbeziehungen an, das uns im folgenden Abschnitt
noch näher beschäftigen wird: die Forcierung der innerbetrieblichen Konkurrenz unter den Ent-
wicklern.
Die Einteilung in die vier Leistungskategorien ist anschließend auch Grundlage für Maßnah-
men, mit denen versucht wird, die Leistung von einzelnen, unterdurchschnittlich bewerteten Be-
schäftigte gezielt zu verbessern. Je nach ihren Defiziten in den verschiedenen Bereichen der Be-
wertung werden schlecht (Kategorie 4) bewertete Beschäftigte zu speziellen Fortbildungskursen
herangezogen. Führen auch diese Maßnahmen zu keiner Verbesserung, ergehen auf Basis der Ein-
gruppierung auch Entlassungen:

„These [die Beschäftigten in der vierten Leistungskategorie – PF] are the people, who
are not performing at all. For them, we have planned that we set them for failure. It is
like, we say that: ’We will invest in you, we have performance improvement plan.’ We
give them opportunities, coaching etc. If the person is still not able to perform, then
we have to say: ’Ok, this is probably not the right place for that person.’ Not that he
or she is bad, but maybe not to our standards.“ (SI7)

Andersherum haben die Bewertungen allerdings natürlich auch positive Wirkungen für die gut
bewerteten Beschäftigten. An die zweite Bewertung des Jahres schließt sich ein weiterer Prozess an,
in dem über Gehaltserhöhungen und Beförderungen entschieden wird. In diesen Prozess gehen die
beiden vorhergehenden Bewertungen der Beschäftigten ein.
Grundsätzlich gibt es bei ServiceTec für jede Funktion im Unternehmen ein festgelegtes Ge-
haltsband, das ein bestimmtes Grundgehalt definiert. Dieses Grundgehalt wird anschließend um
variable Bestandteile ergänzt. Dabei variiert der variable Anteil zwischen unterschiedlichen Funk-
tionen im Unternehmen, grundsätzlich wächst er mit dem Aufstieg innerhalb ServiceTecs. So ma-
chen diese variablen Zahlungen auf der untersten Hierarchieebene (der Entwickler) einen geringe-
ren Anteil aus als in den höheren Ebenen der Projektmanager oder gar des höheren Managements.
Der variable Gehaltsbestandteil setzt sich aus den drei Komponenten Unternehmensgewinn, Ge-
winn der Abteilung und individueller Leistung zusammen.

„Today every person in the organization has a variable component in his or her salary,
which could vary from, say, one percent to 35% of the overall gross [Brutto – PF]. If
100 Rupees is a salary – at the lowest levels, it could be that one Rupee is ... are variable
pay. At the highest levels it could be 30 to 31 Ruppes, 35 Rupees out of the hundred is
variable, pay at risk. And what we did, was that, we said that, in India - it still differs
from country to country, when I am talking, I am referring to India model to greatest
Betriebliche Kontrollstrategien bei ServiceTec 97

extent, because that’s where most of the people are. And ... we said the compensation
would be ... incentives would be, eh, at ... based on the, eh, in company performance,
the performance of the unit, which he or she belongs, and the individual’s performan-
ce.“ (SI7)
Sind die Gewinne des Unternehmens und der Business Unit Faktoren, die für jedes Jahr von
der Unternehmensleitung festgesetzt werden, so wird die individuelle Leistung durch genau jenen
oben erwähnten jährlichen Bewertungsprozess bestimmt.
Die Höhe der variablen Zahlungen korreliert dabei positiv mit der Einteilung in Leistungskate-
gorien. Jedoch wird bei ServiceTec darauf geachtet, dass die Beschäftigten in der ersten Kategorie
überproportional entlohnt werden. Dies folgt folgender strategischer Zielsetzung:
„Rather than being the best employer for all employees, we will be a better employer
for better employees. So we started differentiating on performance. We said that: the
best of employees, we would reward them with a much higher level, as compared to
the average employee or the below-average employees.“ (SI7)
Diese überproportionale Steigerung der Gehälter in der höchsten Leistungsklasse verstärkt den
Anreiz für die Beschäftigten, möglichst hoch eingruppiert zu werden und steigert damit auch die
interne Konkurrenz.
„We set people in bands of their standards, that if you don’t perform, you know that,
there will be a relative ranking and your peer could be rated above you. And he or she
could earn a higher salary than what you are earning. And that brings in a sense of
healthy competition amongst the employees as such.“ (SI7)
Diese Konkurrenz wird noch dadurch gesteigert, dass das Zahlenverhältnis der in die vier Ka-
tegorien eingeteilten Beschäftigten vorher nach einem fixen Schlüssel festgelegt wird. Der genaue
Schlüssel ist vertraulich, so dass darüber in den Interviews keine Informationen gewonnen werden
konnten. Sicher ist aber, dass die Verhältnisse vorher festgelegt werden, wie ein Interviewpartner
erläutert:
„So at each band, we say that certain percentage of the people need to be performance
band 1, certain percentage - in case of post-ranking - of performance band two, perfor-
mance band three, and performance band four.“ (SI7)
So wird selbst in Teams, deren Mitglieder sehr ähnliche Leistungen bringen, anhand kleiner Un-
terschiede differenziert. Diese inszenierte Konkurrenz unter den Entwicklern wird im nächsten
Abschnitt noch ausführlicher Thema sein, da sie ein wesentliches Merkmal der Kooperationsbe-
ziehungen bei ServiceTec darstellt.

5.3.3 Kooperationsbeziehungen
Beziehungen innerhalb des indischen Entwicklungszentrums
Das primäre Bezugsfeld der Entwickler in ihrer täglichen Arbeit ist das Modul, in das sie inner-
halb ihres Projektteams eingeteilt wurden. Schon räumlich befinden sich die Entwickler in sehr
engem Kontakt zu den anderen Kollegen des Moduls, Wie erwähnt, arbeiten sie in einem sogen.
„Cubicle“, also einer quadratischen Anordnung von 4 Schreibtischen, die durch Trennwände vom
Rest des Großraumbüros abgetrennt sind. Dabei sind diese Cubicles nicht gerade groß, so dass das
gemeinsame Arbeiten darin mitunter recht konfliktreich sein kann, wie ein Entwickler schildert:
98 Fallstudie ServiceTec

„You have to learn to adjust with your team members and to work in a team environ-
ment. You sit in a cubicle with 4 people around you, so you don’t have your personal
space. Things like that.“
F: Are there conflicts about that, when you work in a cubicle?
Yes, that’s what you have to learn, to avoid those conflicts.
F: What are the conflicts about?
It can be about somebody playing music on a system, it can be as small as that.“ (SI20)

Allerdings führt diese Nähe auch dazu, dass die Entwickler in permanentem Kontakt zueinander
stehen und daher auch bei Problemen oder Unklarheiten in Bezug auf ihre Arbeitsaufgaben mit
den anderen Entwicklern in ihrem Cubicle direkt und unkompliziert kooperieren, d.h. etwaige
Probleme diskutieren und zu lösen versuchen:

F: And would they work in groups?

„Yah, they usually interact among themselves.“ [...]
F: So everybody would have a single task, but they would interact?
„Yah, like some people would be coding, some people would be testing. They will
discuss among themselves if they find any issues. They keep on constantly discussing
those issues.“ (SI14)

Die Kooperation innerhalb der Module scheint dabei allerdings über eine gegenseitige Hilfe-
stellung bei Problemen nicht weit hinauszugehen. Wirklich gemeinsam wird auf der Ebene der
Entwickler selten gearbeitet, wie eine Entwicklerin aus einem Wartungsprojekt überzeugend klar-
stellt:

„No, two people working on the same defect means: one resource is wasted.“ (SI1)

Aus den Ausführungen zur Aufgabenorganisation bei ServiceTec ließ sich bereits ersehen, dass
Arbeit für die Entwickler in erster Linie Arbeit an individuell zugewiesenen Aufgaben ist: Die
Entwickler bekommen vom Modul- oder Projektleiter ihre Arbeitsaufgaben zugewiesen, und die
Aufgaben sind dabei so gestaltet, dass sie von den einzelnen Entwicklern alleine erbracht werden
können:

„At the junior level the whole day is almost like working on something that is allocated
to them.“ (SI14)

Wenn es doch einmal vorkommt, dass zwei Entwickler in ihren Arbeitspaketen eine Überschnei-
dung haben, kommt es eher zu Konflikten, wie ein Befragter aus seinem Projekt berichtet. Inter-
essant ist bei der Schilderung dieses Entwicklers, dass eine solche Situation von ihm als besonders
regelungswürdig wahrgenommen und sogar ein Eingreifen des Modulleiters gefordert wird:

„When 2 people are working on the same thing – at times it happens that both of them
are adamant in their way of working. That’s where the team-work things come in, that
is where the lead has to ... take control, I would say.“ (SI20)

Teamwork in Bezug auf die tägliche Arbeit - in einem über gegenseitige Hilfestellung hinausge-
henden Sinne - findet sich demnach bei den Entwicklern von ServiceTec selten. Vielmehr bestehen
Modulen aus einer Reihe von „individual contributors“ (SI7), also von einzelnen Beschäftigten,
Betriebliche Kontrollstrategien bei ServiceTec 99

die alle ihren klar definierten und begrenzten Teil zur Gesamtleistung beitragen, diesen aber nicht
gemeinsam erbringen.

Diese „Kultur des Individualismus“ (Upadhya und Vasavi 2006) prägt, wie im Abschnitt über die
Kontrollstruktur (Kapitel 5.3.2) gezeigt werden konnte, nicht ausschließlich die Art der Aufgaben-
organisation im Unternehmen, sondern wird durch eine auf Messung und Bewertung individuell
gezeigter Arbeitsleistung abzielende Kontrollstruktur unterstützt. Erklärtes Ziel des Bewertungs-
systems bei ServiceTec ist, die Entwickler um die besten Bewertungen und die damit verbundenen
positiven Sanktionen (Beförderungen, Gehaltssteigerungen) konkurrieren zu lassen. Offensicht-
lichster Ausdruck dieser Strategie sind, wie gezeigt wurde, die halbjährlich firmenintern veröf-
fentlichten „Rankings“, also die Ranglisten der erreichten Bewertungen im Team, wodurch alle
Beschäftigten in eine hierarchische Beziehung gemäß ihrer Arbeitsleistung gebracht werden.
Darüberhinaus finden sich bei ServiceTec eine ganze Reihe von Wettbewerben, in denen auf
individueller Ebene um kleine symbolische Anerkennungen und Titel konkurriert wird, und wo-
mit die Mitarbeiter zu zusätzlichen Leistungen motiviert werden sollen. Der im Folgenden zitierte
Manager hat z.B. mit einem Preis in Form eines Kinotickets für die beste Tagesleistung in Indien
sehr positive Erfahrungen gemacht:

„In India a ’Kinoticket’ is a great motivating tool. Not because it’s a two Euro ’Kino-
ticket’, it is because he feels it as a prize, that I got recognized for something. Right,
I mean, he very well can afford the damn ticket, it’s not like five thousand Rupies or
something, it’s more the ’I am the boss for today, I won something’.“ (SD6)

Dementsprechend entdeckt man bei einem Rundgang durch die Etagen mit den Cubicle-Kom-
plexen bei ServiceTec eine bunte Mischung an kleinen Pokalen und Urkunden. Die Tatsache, dass
diese stets stolz oben auf die Monitore oder Regalbretter gestellt werden,so dass sie über die Trenn-
wände herausragen und somit für die gesamte Etage sichtbar sind, zeigt die Relevanz, die diesen
individuellen – teilweise aber auch auf Teamebene angesiedelten18 – Wettbewerben bei ServiceTec
auch von den Beschäftigten beigemessen wird.
Eine Beschäftigte schildert die Dynamik und die Stimmung, die unter den Entwicklern durch
diese unterschiedlichen Maßnahmen zur Herstellung von Konkurrenzverhältnissen geschaffen wird:

„I have many relatives and friends, who are staying in the US, who are living there in
the US and, so. That sort, I feel, when they say about their work times there and how
get to - that here, there is more competition here and, even if you want to finish your
work in time and go home and spend time with your family and do something else
– but others in the project, who are, like I said [lacht] earlier, who sit in office and
work, work, because they get bored at home and they love to work more and more,
they obviously spoil the total environment and, if a person is working more and your
superior expects the same from you, and that would create a negative, eh, I mean, his
own view of your doing or whatever. [...] And every time, there is a competition,
there are more people getting into IT and everybody is trying to promote, everybody
is, and people are obviously trying, doing much more than what is expected.“ (SI13)

Die Versuche von Seiten ServiceTecs, die Konkurrenz zwischen Entwicklern zu schüren, fällt
dabei durchaus auf fruchtbaren Boden, wie die Aussage der zitierten Entwicklerin andeutet. Ihre
18
So gibt es z.B. auch einen Wettbewerb um das „most spirited team“.
100 Fallstudie ServiceTec

Schilderung der anderen Kollegen, die ihre Zeit im Büro verbringen, weil sie sich zuhause lang-
weilen würden, tauchte in der Tat häufig in den Interviews auf. Bei näherer Betrachtung ist diese
Aussage auch gar nicht so überraschend. Wie im folgenden Abschnitt über die Rekrutierungsstrate-
gie ServiceTecs noch ausgeführt werden wird, rekrutiert ServiceTec auf der Ebene der Entwickler
vor allem sogen. „Fresher“, also junge Leute, die gerade die Universität verlassen haben. Dement-
sprechend jung sind die Entwickler bei ServiceTec. Hinzu kommt, dass das Einzugsgebiet der IT-
Unternehmen in Bangalore nicht auf regionale Arbeitskräfte begrenzt ist. Die großen IT-Städte,
wie Bangalore, Mumbai, Delhi oder auch Hyderabad, sind das Ziel von Uniabsolventen aus ganz
Indien, die in der Hoffnung auf einen Platz in der IT-Industrie in diese Städte ziehen. Viele der
Entwickler, die schließlich bei ServiceTec anfangen, sind demnach nicht nur sehr jung, sondern
zudem häufig von ihrem bisherigen sozialen Umfeld weit entfernt. Von daher ist es nachvollzieh-
bar, wenn diese Beschäftigten aussagen, dass sie nach Feierabend lieber im Büro bei ihren Kollegen
bleiben, als alleine in ihren Wohungen zu sitzen. Dies gilt umso mehr, als die Büros Teil eines
großen Campusgeländes sind, auf dem neben den Bürokomplexen auch sehr viele Freizeiteinrich-
tungen, wie Swimming-Pools, Billardhallen und diverse Restaurants den Beschäftigten zur freien
Verfügung stehen (vgl. auch Kapitel 5.3.4, Mayer-Ahuja 2011, Kap. 6.2.3).

Doch sind die Kollegen im eigenen Modul nicht die einzige Bezugsgruppe der Entwickler.
Schließlich bearbeitet ein Modul stets nur einen Unterbereich des Gesamtprojektes. Dementspre-
chend kommt es auch vor, dass im Modul Probleme oder Unklarheiten auftauchen, die mit ande-
ren Teilfunktionen oder -bereichen des Projektes in Verbindung stehen, und deren Lösung damit
modulübergreifende Kooperation erfordert.
Diese modul- oder in manchen Fällen auch projektübergreifende Kommunikation wird bei Ser-
viceTec durch die Position des Modulleiters kanalisiert, wie ein Modulleiter auf die Frage nach den
vorrangigen Kooperationspartnern seines Teams erläutert:

„It’s mostly with my team members. But at times some problem comes in which goes
across modules. In that case we have to interact with other modules also.“
F: Are you talking to the other module lead then or are your team members talking
directly to the other team?
„No, that communication part is done through me.“ (SI20)

Dementsprechend findet eine modulübergreifende Kooperation zwischen den Entwicklern eben-

falls nur sehr selten statt, die Koordination der Arbeiten in den einzelnen Modulen ist vielmehr
Sache der Modulleiter und der Projektleiter.

Kooperationsbeziehungen zu Onsite-Teams und Kunden

In eine ganz ähnliche Richtung geht auch die Gestaltung der Kooperationsbeziehungen zum On-
site-Bereich. Schließlich befinden sich weitere für das Projekt wichtige Kooperationspartner außer-
halb der indischen Entwicklungszentren vor Ort beim Kunden. Dabei handelt es sich zum einen
natürlich um die Kunden selbst, zum anderen aber auch um die vor Ort beim Kunden arbeitenden
Teams des Delivery-Bereiches von ServiceTec.
Die Gestaltung der Beziehungen des Offshore-Teams zum Kunden schwankt bei ServiceTec zwi-
schen zwei Polen: Auf der einen Seite wird versucht, die Kommunikation möglichst ausschließ-
lich über den Onsite-Coordinator zu führen und den Kontakt zum Kunden in dieser Person zu
bündeln. Dies stellt bei ServiceTec den häufigsten Fall dar. Der Kontakt zum Kunden und die
Betriebliche Kontrollstrategien bei ServiceTec 101

entsprechende Weitervermittlung zum Offshore-Team ist – wie bei der Darstellung des Geschäfts-
modells ServiceTecs gezeigt wurde – auch der Schwerpunkt der Aktivitäten, die vom Projektteam
Onsite durchgeführt werden. In den meisten Projekten kommuniziert daher nur der Onsite Coor-
dinator mit dem Kunden – die Entwickler, Module Leads und Projektmanager in den Offshore-
Entwicklungszentren wenden sich bei Klärungsbedarf zunächst an den Onsite Coordinator, der
dann die entsprechenden Informationen einholt und weitergibt. Auf der anderen Seite kann durch
dieses Vorgehen – gerade bei größeren Projekten – allerdings auch schnell eine Art „Flaschen-
hals“ entstehen, also ein Engpass in der Kommunikationsstruktur, der dann den Informationsfluß
verlangsamt und behindert. Daher gibt es durchaus auch Projekte bei ServiceTec, bei denen die
Offshore-Teams direkt mit dem Kunden kooperieren:

„See, if the offshore people can talk directly to the clients, it makes our life very simple.
If I have a problem today, can I pick up a phone and call my project manager, the
clients’ person, say: ‘Yah, I’m having this problem. What shall we do?’ If I always have
to go through one person, that becomes a bottle-neck. The relationships don’t build,
the work gets suffered. I have a very clear tendency towards having more and more
offshore people talk to the clients, very clear. I mean, that is what we would like to. In
most of our other English-speaking clients we will do that.“ (SI17)

Die zitierte Aussage weist jedoch bereits auf einige Probleme des direkten Kundenkontaktes hin.
Freut sich der oben zitierte Projektmanager darüber, dass durch direkte Kommunikation auch die
Beziehungen zwischen den Entwicklern und den Kunden verbessert wird, so sind diese Beziehun-
gen bei ServiceTec stets unter kritischer Beobachtung, weil eine zu starke Gewöhnung der Kun-
den an einzelne Entwickler letztlich wieder die Personenunabhängigkeit der Projekte gefährdet.
Von daher ist Kundenkontakt bei ServiceTec eine Gratwanderung. Direkter Kontakt beschleunigt
zwar den Informationsfluß und verbessert die Kooperationsbeziehungen mit dem Kunden, stellt
aber gleichzeitig die Fähigkeit in Frage, die Entwickler schnell zu ersetzen und zu verschieben,
wenn der Kunde sich an einzelne Entwickler gewöhnt und auf eine Fortsetzung der Kooperation
mit dieser Person besteht. Dies ist nach Aussagen der Projektmanager der Hauptgrund, warum der
Kundenkontakt in den meisten der im Rahmen dieser Studie untersuchten Projekte schwerpunkt-
mäßig über den Onsite-Coordinator und das Onsite-Team kanalisiert wird.
Ein weiteres Problem, das in der zitierten Aussage anklingt, ist die Sprache. So fühlen sich angeb-
lich viele deutsche Kunden nicht wohl, wenn sie auf Englisch direkt mit den Offshore-Entwicklern
kommunizieren müssen und bestehen auf deutschsprachigen Ansprechpartnern vor Ort. In die-
sen Fällen wird der Kontakt zum Kunden von den Onsite-Personen übernommen, die Deutsch
sprechen. Eine direkte Kommunikation zwischen dem Kunden und den indischen Entwicklungs-
zentren ist dann so gut wie ausgeschlossen, da es Offshore bisher nur sehr wenige Personen mit
deutschen Sprachkompetenzen gibt19 .

Darüberhinaus ist die Form des Kontakts zwischen Kunden und Offshore-Beschäftigten von der
Art des Projektes selber beeinflusst. So berichten Beschäftigte aus Maintenance-Projekten, dass sie
häufig direkt mit den Kunden kommunizieren.

„For a development project, yes. We try to make sure, that there is a single point of
contact, that we minimize the communication gap between the client and the team.“
19
Zum Zeitpunkt der Studie hatte sich ServiceTec gerade dieses Problems angenommen und bot deutsche Sprachkurse
für die Beschäftigten an.
102 Fallstudie ServiceTec

N: And in a maintenance project, that would be different?

„In maintenance project also, if we have a person dedicatedly being located at the cli-
ent’s location, at the client’s office, that probably he would be the single point of
contact. But in a production support project, wherein we are handling around 15 to
20 applications, then we have to support a user base of 300, then we cannot have the
single point of contact.“ (SI19)

In diesen Fällen handelt es sich beim nötigen Kundenkontakt allerdings schwerpunktmäßig um

Berichte über Defekte an laufenden Systemen, die in vielen Fällen durch Computersysteme struk-
turiert und in ihrer Form stark standardisiert und formalisiert werden. Diese Reporting-Systeme
ersetzen in vieler Hinsicht persönliche Kommunikation, warum hier in einigen Fällen ganz auf
einen Onsite-Koordinator und ein größeres Team vor Ort beim Kunden verzichtet werden kann.

Schließlich unterscheiden sich auch die Kunden selbst in ihrem Wunsch und Bedürfnis nach
direkter Kommunikation mit dem Offshore-Team:

„There are clients, where we have faced situations, where they say that we do not
want to talk to the offshore team. We would like our contacts to be limited to the
onsite team. So all communication should come to that. We’ve had clients in Germany,
France, lot of other places. So that becomes another reason, why we do not have too
much of contacts. But again, I mean, it really depends very extremely from client to
client scenario.“ (SI17)

Manche Kunden würden sich nach Angaben von Projektmanagern am liebsten direkt in die
Arbeitsorganisation in den Entwicklungszentren einmischen, wohingegen andere damit zufrieden
sind, onsite auf dieselben Leute zu treffen und mit diesen zu sprechen.
So ist die konkrete Form, die die Kooperation zwischen Kunden und Offshore-Team annimmt,
das Ergebnis eines komplexen Prozesses, in den mehrere Faktoren hineinwirken.

Mit der Beziehung zum Kunden verändert sich auch die Beziehung zu den Onsite-Teilen des
Projektes. Grundsätzlich wird ein ständiges, größeres Onsite-Team in dem Maße überflüssig, in
dem der direkte Kontakt zwischen Offshore-Team und Kunden sich [Link] im Laufe
eines Maintenance-Projektes die anfallenden Kooperationsnotwendigkeiten direkt zwischen den
Offshore-Projektmanagern und den Kunden diskutiert werden können, wird das Onsite-Team per-
sonell verkleinert, was natürlich auch wieder zu Einsparungen führt. Aber selbst wenn während
der Bearbeitungsphase ein Team vor Ort beim Kunden bleibt, verliert dieses Onsite-Team durch
den direkten Kundenkontakt des Offshore-Teams seine vermittelnde Rolle im Projektverlauf, und
daher sinkt auch die Kooperationsintensität zwischen den beiden Teamteilen.
Ganz anders stellt sich die Situation dar, wenn – wie in den meisten Fällen – der Kontakt
zum Kunden ausschließlich oder schwerpunktmäßig über den Onsite-Coordinator und sein Team
läuft. In diesem Falle hat das Onsite-Team eine sehr zentrale und erfolgskritische Funktion im
Projektverlauf. Entsprechend stark wird darauf geachtet, die dadurch entstehende „bottleneck-
Problematik“ nicht noch durch weitere Reglementierungen der Kommunikationsstruktur zu ver-
schärfen. So ist der Kontakt zum Onsite-Koordinator und seinem Team bei ServiceTec sehr dezen-
tral organisiert. Grundsätzlich sollen alle Modulleiter – und nach Rücksprache auch die Entwick-
ler selbst – möglichst direkt mit dem Onsite-Koordinator kommunizieren und ihre Probleme oder
Klärungsbedarfe mit diesem diskutieren.
Betriebliche Kontrollstrategien bei ServiceTec 103

„The onsite coordinator talks to the offshore project manager and talks to the com-
plete team as well at times. Because if the onsite coordinator just talks to the offshore
project managers, that does create a long communication channel and what we foresee,
is, there might be fissure on the information. Some information might be missed. The
onsite coordinator speaks to the complete team as well, whenever required. Whenever
a team member needs a clarification we can approach the onsite coordinator directly.“
(SI17)

5.3.4 Arbeitsmarktbeziehungen
Rekrutierungsbemühungen

Die Arbeitsmarktbeziehungen von ServiceTec sind auf der einen Seite von den hohen Wachs-
tumsplänen des Unternehmens und auf der anderen Seite ganz wesentlich von der starken Kon-
kurrenz auf dem indischen IT-Arbeitsmarkt geprägt.
Betrachtet man die Entwicklung der Beschäftigtenzahlen von ServiceTec in den letzten Jahren,
so lässt sich erahnen, welch große Anstrengungen die Firma unternommen haben muss, um von
10.000 Beschäftigten um die Jahrtausendwende auf über 90.000 Beschäftigte im Jahr 2008 zu wach-
sen. Der absolute Großteil des Beschäftigtenwachstums hat dabei in den Entwicklungszentren in
Indien stattgefunden.
ServiceTec rekrutiert vor allem Software-Entwickler, 70% der Einstellungen entfallen auf diese
Stufe20 . Im Gegensatz zu Beschäftigten, die gezielt für höhere Positionen gesucht werden und bei
denen langjährige Berufserfahrung eine zentrale Voraussetzung für die Einstellung ist, werden auf
der Entwicklerebene primär Berufseinsteiger direkt von der Universität eingestellt.

„We realized that, if we were to grow faster, we had to hire people in, you know: bat-
ches, at entry level. And we had to train them and invest in them and grow them from
within the company, to take on larger responsibilities. So as. . . There was a fundamen-
tal belief in this company, that we would invest and grow people from within and ...
rather not do too much of hiring from outside. We’ll do hiring from outside at higher
levels, but focus on getting people at the entry level.“ (SI7)

Die Einstellungsbemühungen von ServiceTec nehmen dabei die Form von regelrechten Mas-
senrekrutierungen an. Als dominantes Modell hat sich in den letzten Jahren dazu das sogen.
„Campus-Recruitment“ durchgesetzt. „Campus-Recruitments“ bezeichnen spezielle Aktionstage
an indischen Universitäten, an denen das Lehrprogramm unterbrochen wird, um Unternehmen
die Gelegenheit zu geben, sich den angehenden Absolventen zu präsentieren. Im Rahmen dieser
Veranstaltung versucht ServiceTec bereits, Studierende an sich zu binden. Dazu können die Studie-
renden vor Ort einen Einstellungstest ablegen und im Falle des Bestehens ein Bewerbungsgespräch
mit den anwesenden HR-Mitarbeitern führen. Bei Eignung für eine Einstellung bei ServiceTec er-
halten die Studierenden gleich vor Ort eine Zusage von NovoProd, die sie einlösen können, wenn
sie ihr Studium erfolgreich beendet haben. Demenstprechend haben viele Studierende bereits einen
Job sicher, bevor sie die Universität verlassen haben.
Wie für alle IT-Dienstleister in Indien ist die primäre Zielgruppe für Rekrutierungen die Gruppe
der Bachelor-Absolventen verschiedener Studienrichtungen im Bereich des Engineering und dort
20
Die im Zusammenhang mit den Rekrutierungsbemühungen präsentierten Zahlenangaben sind - sofern nicht anders
gekennzeichnet - alle einem Gespräch mit dem Head of Human Ressources (SI7) von ServiceTec entnommen.
104 Fallstudie ServiceTec

vor allem des Bereiches Computer Science oder Technology. Allerdings steht ServiceTec in Indi-
en weder mit seinen ehrgeizigen Wachstumsplänen noch mit seinem Fokus auf diese Zielgruppe
alleine. Alle großen indischen IT-Dienstleister haben in den letzten Jahren ihre Beschäftigtenzah-
len ähnlich explosiv erhöht. Angeheizt wird diese Situation noch durch die vielen nach Indien
drängenden multinationalen IT-Unternehmen, die auch beginnen, dort in großem Maßstab Beleg-
schaften aufzubauen.
Ein paar Zahlen mögen das Arbeitskräfteangebot in Indien und die Konkurrenz um dieses ver-
deutlichen: 235.000 Abgänger von indischen Universitäten im für IT-Firmen interessanten Seg-
ment des Engineering habe es im Jahr 2007 gegeben21 , etwa die Hälfte davon (117.000) spezialisier-
ten sich auf IT. Von diesen 117.000 besuche ein Teil weiter die Universität, um einen höheren Ab-
schluss, wie MBA o.ä. zu erwerben. Zusammen mit Personen, die ihre höheren Abschlüsse in dem
Jahr absolviert haben, stehen der IT-Industrie ungefähr 108.000 Personen als Rekrutierungsmasse
zur Verfügung. Von diesem Pool hatte allein ServiceTec geplant, ca. 25.000 Personen einzustellen.
Da diese Gruppe der Hochschulabsolventen die Zielgruppe von vielen IT-Firmen in Indien (vgl.
z.B. auch Upadhya und Vasavi 2006, Athreye 2005a, Arora u. a. 2001) und entsprechend umkämpft
ist, ist ServiceTec, um seine ehrgeizigen Wachstumsziele zu erreichen, in den letzten Jahren dazu
übergegangen, neben Absolventen IT-spezifischer Studiengänge, auch Absolventen anderer Fach-
richtungen zu rekrutieren:

„So we shifted to that model and at the same point of time we also realized that the
education system in India – there are not enough computer science graduates, who are
graduating out on a year to year basis to meet the kind of growth targets we had set
for ourselves.“ (SI7)

In der Folge hat ServiceTec mittlerweile seine Bemühungen nicht nur auf sämtliche Spielarten
des Engineering, sondern auch auf gänzlich IT-ferne Studienfächer ausgeweitet. So rekrutiert Ser-
viceTec mittlerweile auch Bachelor of Science and Arts:

„So today we hire people from economics, history, literature, music and we ... last
year we piloted the launch and we said that we put them to that 14 weeks training.
And they did really well. So that gives us a belief that probably we can even train
people with non-technology background, non-engineering backgrounds, and convert
them into software engineers.“ (SI7)

Mit dieser Ausweitung hat ServiceTec das mögliche Rekrutierungspotential stark ausgeweitet.
Wie aus dem Zitat des HR-Managers bereits hervorgeht, ist eine der wichtigsten Voraussetzungen,
die dieses Vorgehen ServiceTecs ermöglicht, das ServiceTec-eigene Trainingsprogramm.

Trainingsmaßnahmen

Das firmenspezifische Trainingsprogramm wird nicht nur den IT-fernen Uniabgängern zuteil; eine
festgelegte Phase des Trainings durchlaufen alle auf dem Einstiegslevel rekrutierten Beschäftigten
bei ServiceTec nach ihrer Einstellung. Allerdings richtet sich die Länge der Trainingsmaßnahme
nach der Vorbildung der Beschäftigten, also konkret danach, ob diese ihren Abschluß in einem
21
Auch hier wird wieder auf die Angaben des HR-Managers von ServiceTec rekurriert. Der indische Branchenverband
Nasscom veröffentlicht allerdings sehr ähnliche Zahlenangaben
Betriebliche Kontrollstrategien bei ServiceTec 105

techniknahen oder -fernen Studienfach gemacht haben. Wenn entsprechende technische Vorbil-
dung vorhanden ist, dauert die Maßnahme drei Monate, bei fehlenden technischen Vorkenntnissen
sind es dreieinhalb bis vier Monate.
Der Inhalt dieser Trainingsmaßnahme ist in erster Linie technischer Natur. Die Neueingestellten
bekommen ein intensives Training in von ServiceTec genutzten Technologien und Methodologien.
Das betrifft zwar in weitaus stärkerem Maße die Personen, die aus technik-fernen Studiengängen
zu ServiceTec stoßen, aber auch die Absolventen technischer Studiengänge und sogar Studierende
der Computer Sciences werden in spezifischen Technologien und Methodolgien geschult. Hinter-
grund dafür ist ein aus Sicht von ServiceTec unzureichendes Level der technischen Ausbildung an
den indischen Universitäten (SI7). ServiceTec hat die Erfahrung gemacht, dass die Uniabsolven-
ten nicht mit der für einen Einsatz in der IT-Industrie nötigen Qualifikation die Uni verlassen22 .
Das zentrale Problem war nach Ansicht der HR-Manager, dass an der Uni veraltete Technologi-
en und Methodologien gelehrt würden, die für die Projekte ServiceTecs nur noch von geringem
Nutzen sind23 . Daher hat ServiceTec erhebliche Ressourcen in den Aufbau der eigenen Trainings-
maßnahmen gesteckt, in denen die Beschäftigten weiterqualifiziert werden. Von der Qualität ihrer
Trainingsmaßnahmen ist ServiceTec sehr überzeugt. Angeblich sei ein indischer Uni-Absolvent
(egal welcher Fachrichtung), der anschließend diese Schulung durchlaufen hat, ebenso qualifiziert,
wie ein US-amerikanischer Student, der an einer amerikanischen Uni einen Bachelor in Computer
Science macht, wie der zuständige HR-Manager erläutert:

„So we said we’ll hire people, who had, from all disciplines of engineering, but we
put them to the entry level training program. So once they complete that, they would
be certified as trained software engineers. And we’ll hire an external evaluation au-
dit done of our course. And we certify that anybody, who does 16 years of study in
India, whoever goes through 16 years of education in India, and has those 14 weeks
of training, initial training program – that person is equivalent to a BS [Bachelor of
Computer Science – PF] kind of a qualification in the US.“ (SI7)

Und auch ein Projektmanager bestätigt dies:

„And, when they are brought into the organization, they anyway undergo a very
extensive four months of training, which has been eh, which has been eh, probably
certified by one of the universities in USA as equivalent to the BS-degree in US. So,
everyone goes through that extensive computer science training programme, which
obviously gives them a very good insight of the computer science and on different
languages.“ (SI19)

Die erwähnte Zertifizierung für die internen Trainingsmaßnahmen konnte leider im Rahmen
dieser Studie nicht überprüft werden, jedoch zeigt bereits der Versuch, ein derartig ambitionier-
tes Niveau für die Trainingsmaßnahmen zu erreichen, wie wichtig ServiceTec dieses Thema ist24 .
22
Die HR-Manager von ServiceTec bestätigen damit die Befunde, die auch Unternehmensberatung McKinsey 2005
veröffentlicht hat Farrell, Kaka und Stärze 2005
23
Interessant in dieser Hinsicht ist, dass dieses Problem vom zitierten HR-Manager auf einen Ausverkauf des Lehrper-
sonals an den Universitäten durch die IT-Industrie zurückgeführt wird. Angeblich hätten die qualifiziertesten Leute
die Universitäten zugunsten der IT-Industrie verlassen und die verbleibenden Lehrkräfte würden sich nur in älteren
Technologien auskennen, wodurch diese weiterhin die Lehrpläne dominierten (vgl. SI7). In gewisser Weise schafft
die IT-Industrie sich in diesem Bereich also ihr eigenes Problem.
24
Der Hintergrund ist, dass Personen, die ein H1B Visum in die USA beantragen wollen, mindestens einen Bachelor
oder gleichwertigen Abschluß nachweisen müssen (vgl. Mayer-Ahuja 2011, Kapitel 7.1.2)
106 Fallstudie ServiceTec

Dementsprechend anspruchsvoll ist das Trainingsprogramm auch gestaltet, wie eine Entwicklerin
aus eigener Erfahrung schildert:

„There were some group discussions and there was kind of activities, after that it’s
completely technical training, and every, say, four days, four to five days a subject, and
after two days we’ll have this ... some dozen or twenty-five ... online test. So that carries
some percent of the ... I don’t remember exactly, maybe 20 marks of the hundred for
that subject. And after the course get’s over, after the four or five days of course, we’ll
have a test. This finally, all these quiz marks and the test marks sums up to hundred.
And we had to clear each and every subject. And finally, after that, after all the subjects
get over, we’ll have a project. They’ll make us a group of 8 people, and they’ll ask us
to do some project. They give one week time for that, and we have to develop it and
execute - and make it executable. Then again we’ll have one, around one week time for
the final exams. It [...] will have questions of all, I mean whole our training. [...] That
we have to clear to come and take over a project or the work we start.“
F: Could you describe that exam?
„It’s not that easy. You have to... I mean, every day you have to keep reading. So every
third day you’ll have quiz, or test, or exam. So ... classes and then in the evening, you
have to go through it ... And there were like some model question papers and some
old papers and, they helped, but... It’s not that you can just come and clear it off. It is:
You have to study.“ (SI1)

Für die Dauer der Maßnahme werden die Teilnehmer in einem speziellen Trainingszentrum
einquartiert, wo sie wohnen und arbeiten (vgl. SI7). So stellt das Training eine sehr intensive Lern-
Phase für die Beschäftigten dar. Wer das End-Examen nicht besteht, verläßt an diesem Punkt be-
reits das Unternehmen. Alle anderen werden vom Unternehmen für eine sechsmonatige Verpflich-
tungsphase übernommen. Innerhalb dieser sechs Monate können die Beschäftigten das Unterneh-
men nicht durch Kündigung verlassen. Erst nach diesen sechs Monaten werden sie unbefristet ins
Unternehmen übernommen.

Welche Technologien in dem Training vermittelt werden, welche Methodologien erlernt wer-
den, hängt von dem von ServiceTec erwarteten Projektaufkommen ab. Die Wünsche der Beschäf-
tigten werden dabei nach eigenen Angaben in der Regel nicht berücksichtigt:

„It is, there is no option for us to select, there was no option, because it is completely
based on the requirements of the company, how many new projects they are expecting
on different technologies and how many resources they would require for different
streams, which the company is working on. [...] So, I was trained in Mainframes.“
(SI13)

Eine andere Entwicklerin ergänzt:

F: But there is a certain perception that somebody is especially lucky to be in one

technology and not in the other?
„Yah, means we ... there is a perception! But while choosing, the higher authority
they don’t see all that. They put randomly the batch: ‘Ok, there’s requirement in
mainframes and that batch is coming on that day’, they’ll say ‘Ok, we want it. We
want them to be trained in mainframes.’ So that’s it.“ (SI2)
Betriebliche Kontrollstrategien bei ServiceTec 107

Dabei ist der Schwerpunkt der Trainingsmaßnahme nicht notwendigerweise ausschlaggebend

dafür, welchen Projekten die Absolventen anschließend zugeteilt werden. Wieder folgt die Ver-
teilung der Einsteiger auf die verschiedenen Projekte, Geschäftsbereiche und z.T. sogar Entwick-
lungszentren an verschiedenen Standorten, den zum jeweiligen Zeitpunkt des Einstiegs herrschen-
den Bedürfnissen des Unternehmens. Für die Beschäftigten bringt dieser Zustand einen großen
Unsicherheitsfaktor ins Spiel: Zum Zeitpunkt der Bewerbung ist oft noch unklar, welche Projekte
in der nächsten Zeit Bedarf an Beschäftigten haben. Entschieden wird dies am Ende der Trainings-
maßnahme, wie eine Entwicklerin schildert:

„Once I joined ServiceTec, I got my training and all – in internet streams. Only after
that we kind of come to know: ‘Ok, these kinds of projects will come in.’ As in we had
induction programs, which told us the clients are banks, telekom companies, insurance
companies, health care companies. So that was a basic idea we had got, but not exactly
what kind of work would I be put into or something.“ (SI2)

Bei dieser Verteilung auf die verschiedenen Projekte kommt es nach Angaben der Entwickler
häufiger vor, dass das Training nicht zu den späteren Projekten passe:

F: Would that be a common experience, that your training doesn’t fit into what you
are doing afterwards?
„Yes, it’s very frequent. Because it’s depending on the availability of the project.“ (SI21)

Die Absolventen werden also nach dem Einstiegstraining sehr flexibel und je nach Bedarf des
Unternehmens auf die verschiedenen Projekte verteilt.

Allerdings bezieht sich die Flexibilität des Einsatzes nicht nur darauf, in welches Projekt die
Absolventen gerufen werden, sondern auch der Einsatz in diesen Projekten ist zunächst flexibel.
So werden alle Absolventen des initialen Trainings gleich behandelt, es wird z.B. nicht weiter zwi-
schen Personen mit technologie-naher und -ferner Ausbildung unterschieden. Dies betrifft sowohl
die Art der Projekte, in denen gearbeitet wird, als auch die Aufgaben, die den Entwicklern zugeteilt
werden:

„Finally, once the training is over we’re not like ... nobody is different. Everybody is
the same. What they do is the same and whatever the appraisals or their ratings. So
then it’s not ... Everything’s the same. There’s no difference. [...] I mean, if I’m in
your project, you’ll not be knowing [...] what background I come from. I mean, if
you talk to them personally, you come to know. But based on the work they do – no,
you can’t. Everybody has to do the same work“.

Das Ziel der Rekrutierungs- und (Einstiegs-) Trainingsbemühungen von ServiceTec auf der Ebe-
ne der Entwickler ist also die Herstellung einer großen Menge möglichst homogen qualifizierter
Beschäftigter oder „Ressources“, wie sie im Jargon von ServiceTec stets genannt werden. Das Ziel
sind Beschäftigte auf dem Einstiegslevel, die möglichst breit qualifiziert und damit sehr flexibel
einsetzbar sind.
Wie bereits im Unterkapitel zur Aufgabenorganisation bei ServiceTec geschildert wurde, bleibt
dieser strategische Fokus für die Ebene der Entwickler auch während der Durchführung der Pro-
jekte erhalten. So konnte gezeigt werden, wie durch stete Rotation von Beschäftigten und Arbeits-
aufgaben versucht wird, eine fachliche oder technologische Spezialisierung der Entwickler auf der
108 Fallstudie ServiceTec

Stufe der Entwickler möglichst zu verhindern, und diese Flexibilität des Einsatzes in den ersten
Jahren zu erhalten.
Diese Flexibilität befähigt ServiceTec, auf der einen Seite, mit Schwankungen im Geschäfts-
aufkommen und damit wechselndem Personalbedarf in unterschiedlichen Bereichen, und auf der
anderen Seite, wie im folgenden erläutert werden soll, mit einer Besonderheit des indischen Ar-
beitsmarktes organisatorisch umzugehen: den hohen Fluktuationsraten.

Umgang mit Personalfluktuation

Die schon erwähnte Konkurrenz (Kapitel 3.2) indischer und nach Indien drängender IT-Firmen
um die relativ knapper werdenden25 indischen IT-Fachkräfte erschwert ServiceTec – wie gezeigt
– nicht nur die Rekrutierung von Beschäftigten in einer für die ehrgeizigen Wachstumspläne aus-
reichenden Zahl und Qualität. Die starke Nachfrage nach IT-Fachkräften führt auch dazu, dass
Beschäftigte verschiedene Angebote abwägen und leicht zwischen verschiedenen Firmen wechseln
können.
ServiceTec gibt in seinem Geschäftsbericht für das Jahr 2007/08 eine durchschnittliche Fluk-
tuationsrate von knapp 14% für das Gesamtunternehmen an, womit es unterhalb des Branchen-
schnitts der letzten Jahre (vgl. Arora u. a. 2001, Upadhya und Vasavi 2006) liegt. Auch wenn von
ServiceTec für diese Untersuchung leider keine detaillierteren Informationen über die Fluktuati-
onsraten zur Verfügung gestellt wurden, kann aus den Gesprächen mit den jeweiligen Projektteams
geschlossen werden, dass sich die Fluktuation vor allem auf die Einstiegsebene und die Beschäftig-
ten in den ersten Jahren nach Einstellung konzentriert und auf dieser Ebene daher wesentlich mehr
als 14% beträgt. Dafür werden gleich eine Reihe von Gründen genannt:
Zunächst gibt es viele Beschäftigte auf dem Einstiegslevel, die nach ihrem Bachelor die Universi-
tät verlassen haben, um erste Berufserfahrungen zu sammeln, aber durchaus beabsichtigen, später
noch weiter zu studieren, um z.B. ihren MBA zu erlangen. Diese Beschäftigten verweilen in der
Regel 2-3 Jahre im Unternehmen und nehmen anschließend ihre Studien wieder auf (SI7).
Ein weiterer Grund betrifft speziell die weiblichen Beschäftigten bei ServiceTec, die nach einer
bestimmten Zeit häufig aus dem Unternehmen ausscheiden, weil sie entweder geheiratet haben
und an den Wohn- und Arbeitsort ihres Mannes ziehen26 , oder nach Geburt der ersten Kinder die
Firma verlassen. Nach den Erwartungen von ServiceTec verlassen viele der weiblichen Beschäftig-
ten die Firma nach der neuralgischen Marke von ca. 5 Jahren Betriebszugehörigkeit, weil in diesen
Zeitraum die meisten Hochzeiten, bzw. Geburten fallen:

„Yah, of course, because, see, at the end of three years, that time we see the problem
starts topping up. A lot of ladies start getting married or ... just they could have got
married and they plan a kid or something like that. But three years is when the pro-
blem starts. And after five years, is when the problem really hits, because: a second
kid, or some people have got married at three years, want to have a kid after five years.
So after five years is when it is a real problem for us to keep employees back.“ (SI7)

Somit betrifft auch die speziell „weibliche“ Fluktuation vor allem die unteren Hierarchiestufen,
also die Stufen der Entwickler und der Modulleiter (vgl. auch Mayer-Ahuja 2011, Kapitel 3.2.2 und
25
In absoluten Zahlen steigt die Zahl der IT-Fachkräfte zwar, jedoch steigt die Nachfrage gegenwärtig schneller als das
Angebot, wodurch ein Fachkräftemangel entsteht (vgl. Kapitel 3.2).
26
In dieser Hinsicht erweisen sich die indischen Geschlechterverhältnisse als sehr starr und traditionell, viele interviewte
weibliche Beschäftigte klagten über die Aussicht, nach ihrer Heirat an den Ort ihres Mannes ziehen und dafür ihren
Job bei ServiceTec aufgeben zu müssen.
Betriebliche Kontrollstrategien bei ServiceTec 109

4.2.3).
Und letztlich sind es auch gerade die jungen Uniabsolventen, die von den in Indien aktiven IT-
Unternehmen besonders begehrt sind. Schließlich baut nicht nur ServiceTec seine Belegschaft ge-
zielt auf den unteren Hierarchiestufen aus, sondern grundsätzlich haben alle Unternehmen gerade
auf dieser Ebene im Zuge des weiteren Wachstums großen Bedarf an Arbeitskräften.
Die aufgeführten Gründe führen demnach dazu, dass sich die höchsten Fluktuationsraten auf
dem Einstiegslevel und in den ersten Jahren der Betriebszugehörigkeit zeigen.

Auch wenn ServiceTec mit ca. 14% Fluktuation unterhalb des Branchenschnitts liegt, ist die
Reduzierung und der organisatorische Umgang mit dieser Fluktuation ein dominierendes Thema.
Wie in Kapitel 3.3 argumentiert, lassen sich zwei grobe Strategien identifizieren, mit denen Un-
ternehmen versuchen, mit der Fluktuation umzugehen. Sie können demnach entweder versuchen,
die Fluktuation zu reduzieren, indem auf Wünsche der Beschäftigten eingegangen wird und An-
reize unterschiedlicher Art für die Beschäftigten geschaffen werden, längerfristig in der Firma zu
bleiben. Oder man versucht, durch Standardisierung die Arbeitsprozesse so weit wie möglich ge-
gen Fluktuation zu „immunisieren“, indem die Abhängigkeit der Projekte von den Beschäftigten
reduziert wird. Im selben Kapitel wurde bereits erläutert, dass sich diese Strategien keinesfalls ge-
genseitig ausschließen müssen, sondern vielmehr spezifische Mischungen dieser beiden Strategien
in den untersuchten Unternehmen erwartet werden, die wesentlich vom jeweiligen Geschäftsmo-
dell beeinflußt werden.
So findet sich auch bei ServiceTec eine bestimmte Mischung aus Maßnahmen, mit denen Fluk-
tuation auf der einen Seite gezielt reduziert und auf der anderen Seite „kanalisiert“ werden soll,
indem die Projekte gegen hohe Fluktuation möglichst weit „immunisiert“ werden. Wenden wir
uns im Folgenden zunächst den Maßnahmen zu, mit denen Fluktuation reduziert weden soll.

Das wichtigste Element dieser Bemühungen ist bei ServiceTec das Angebot von klaren und trans-
parenten Karrierewegen innerhalb des Unternehmens. Wie bereits erwähnt, erwächst aus der star-
ken Nachfrage auf dem indischen Arbeitsmarkt für die Beschäftigten die Möglichkeit, bei einem
Unternehmen verwehrte Beförderungen auf dem „Umweg“ eines Firmenwechsels zu erhalten. Da-
her erwarten die Beschäftigten geradezu stetige Beförderungen als Voraussetzung eines Verbleibs
in der Firma. Bleiben diese über einen längeren Zeitraum aus, steigere dies den Hang zum Firmen-
wechsel ganz erheblich (SD8). ServiceTec versucht diesem Problem zu begegnen, indem einerseits
die Entscheidungen darüber, wer wann und warum befördert wird, möglichst offen kommuniziert
werden, wie eine Vertreterin des Managements erläutert:

„We try to be very open about the feedback that we give them. Because if they are
not doing a good job, we ensure that we tell them. Because if we don’t tell them later
on during promotions or we are doing appraisals, we give them a bad score then that
should not come as a surprise. And many times people would leave because of that.
Because they are not satisfied the way they have been, you know, their performance
has been managed.“ (SI5)

Im Abschnitt über die bei ServiceTec vorfindliche Form der Kontrollstruktur (Kapitel 5.3.2)
wurde das Bewertungssystem bereits ausführlich beschrieben. Wie gezeigt, versucht ServiceTec da-
bei mit den Maßstäben der Bewertung sehr offen umzugehen und zudem einem transparenten
Bewertungsprozess zu folgen, der die Entwickler früh einbindet. Nach Aussage der zitierten Ma-
nagerin geht dieses Verfahren also auch wesentlich darauf zurück, dass den Beschäftigten ein klares
110 Fallstudie ServiceTec

Bild ihrer Leistung im Unternehmen vermittelt werden soll, um „unangenehme Überraschungen“

an den neuralgischen Terminen der Beförderungen und Gehaltserhöhungen zu vermeiden, die an-
geblich häufig zu schneller Kündigung durch die Beschäftigten führen. So wird für jede Funktion
im Unternehmen ein klares Profil bestimmt, welche Qualifikationen für diese Funktion vonnöten
sind, und welche Voraussetzungen für eine Beförderung erfüllt sein müssen.
Eine wichtige Voraussetzung für Beförderungen auf den unteren Hierarchiestufen, also im we-
sentlichen von der Position des Entwicklers zu der des Modulleiters27 , ist z.B., dass die Person
die Aufgaben des Modulleiters bereits für ein halbes Jahr ausgeübt haben muss, um auch formell
befördert werden zu können. Zudem müssen für Beförderungen z.B. in eine Führungsposition
entsprechende Kommunikationsfähigkeiten belegt werden. Für die einer Rolle zugeordneten tech-
nischen Anforderungen gibt es ein unternehmensinternes Zertifizierungssystem, das bestimmte
technische Qualifikationen belegen soll. Selbiges gibt es auch zum Erwerb von Kenntnissen in be-
stimmten Branchen. Durch diese klar kommunizierten Anforderungen für eine Beförderung wird
für die Beschäftigten nach eigenen Angaben leicht absehbar, ob demnächst eine Beförderung für
sie in Frage kommt oder nicht.
Dazu trägt natürlich auch bei, dass nur die leistungsmäßig am höchsten bewerteten Beschäftigten
für eine Beförderung in Frage kommen. Wie bereits im Zusammenhang mit der Kontrollstruktur
(siehe Kapitel 5.3.2) geschildert, basiert eine mögliche Beförderung bei ServiceTec grundsätzlich
auf einem halbjährlichen Bewertungszyklus durch die Vorgesetzten und dem nach der Bewertung
stattfindenden Ranking-Prozess der Beschäftigten nach Leistungsgruppen. Daher können die Be-
schäftigten bereits anhand ihrer Bewertungen abschätzen, wie wahrscheinlich eine Beförderung
für sie in der nächsten Zeit sein wird.
Doch es ist nicht nur die Transparenz des Beförderungsprozesses, der helfen soll, die Fluktua-
tionsraten gering zu halten. So war ServiceTec in den letzten Jahren auch in der guten Position,
häufig und – wie sich später im Vergleich zur Produktfirma NovoProd zeigen wird – auch ver-
gleichsweise schnell befördern zu können, weil durch das enorme Wachstum viele Stellen in Ma-
nagementpositionen besetzt werden mussten. Auch wenn das Management bei ServiceTec stets
großen Wert darauf legt, zu betonen, dass ausschließlich nach Leistung und betrieblicher Verfüg-
barkeit von Positionen befördert werde, bildet sich bei den Beschäftigten dadurch doch eine recht
klare Vorstellung heraus, in welchem Zeitraum eine Beförderung erfolgen soll:
„One important level, we have software engineers, like a person joins the company
and gets time for 4 months in the company and then he becomes a software engineer.
The typical career of a software engineer is from about .. up to 2.5, 3 years experience
depending on the performance of a person. [...] He then moves on the next level,
which is known as programmer analyst. The next step is the project manager, it’s
about 5.5 to 6 years experience. Once it goes beyond that, than it is a senior project
manager“ (SI6).
Von daher steht trotz aller gegenläufiger Versuche des Managements für die Beschäftigten auch
eine klare zeitliche Erwartung hinsichtlich ihrer Beförderungen im Raum:
„But it is really not about time-bound promotion that you get. But as you rightly said,
the folks who are doing very good, they do get a promotion every two years or two
and a half years or three years. So people know that it is possible. And everybody
wants to achieve that.“ (SI5)
27
Die Beförderungen von der Stufe der Projektmanager ins höhere Management laufen nur noch über individuelle
Interviews.
Betriebliche Kontrollstrategien bei ServiceTec 111

Dies gilt umso mehr, als eine längere Verweildauer auf einer Stufe bei ServiceTec auch als klarer
Indikator für die Leistung der Entwickler behandelt wird, wie sich in folgender Aussage klar zeigt:

„But then they would be the lowest performers in the organization, so then they work
for four, five years also as software developers.“ (SI5)

Es ist daher auch nicht verwunderlich, dass nach Angaben eines HR-Managers die Fluktuations-
raten bei den unteren Leistungsgruppen sehr viel höher sind, als bei den höheren, da diese absehen
könnten, dass ihr Aufstieg bei ServiceTec länger dauern wird und sich ein Firmenwechsel daher
positiv auswirken könnte:

„Then we see that our attrition rate varies according to performance bands. When we
look at the ’band 1’ or the highest performers, it’s much below the company average.
When you look at the lowest band, ’band 4’, it is probably at 50 to 60 percentage. So
once people are put on those bands, they also realize, that they either have to improve
that grades – they have to actually move out of the comfort zones, start learning, start
performing, or they have to move out. And many times they chose to move out on
their own.“ (SI7)

Der Themenkomplex „Beförderungen“ ist dadurch bei ServiceTec alles andere als konfliktfrei.
Auf der einen Seite versucht ServiceTec, mit der Frage der Beförderungen möglichst offen und für
die Beschäftigten transparent umzugehen, klar zu kommunizieren, was für eine Beförderung nötig
ist. Auf der anderen Seite hängt eine mögliche Beförderung natürlich nicht nur an der individuellen
Leistung sondern auch an der Verfügbarkeit der jeweiligen Position im Unternehmen. Dieser letzte
Punkt war durch das rasante Wachstum von ServiceTec bisher selten ein Problem, könnte aber
bei Einbrüchen der Umsätze und des Geschäftsvolumens zukünftig durchaus zu einem Problem
werden, wenn ServiceTec nicht wie bisher jährlich in großem Maße befördern kann. Dann würde
die nicht erfüllte Erwartungshaltung der Beschäftigten in Bezug auf ihre Karriere evtl. zu einem
stärkeren Anstieg der Fluktuationsraten bei ServiceTec führen, wie der folgende Projektmanager
auf die Frage nach den schnellen Beförderungen bei ServiceTec ausführt:

„Natürlich finde ich das nicht schön. Das ist kein natürlicher Schritt, das ist eigentlich
sehr künstlich geworden, weil das Wachstum so rasant ist. Als ich vor 6 Jahren angefan-
gen habe, waren wir 10.000 Mitarbeiter, heute sind wir 72.000 Mitarbeiter. Und sehr
viele attrition rate, sehr viele wollen zu anderen Firmen gehen. Beförderungen muss es
geben, um die Mitarbeiter noch zu halten. Und insgesamt, das große Fire wird größer
und größer und das ist der Hauptgrund. Wenn es denn ein klassisches Geschäft wie
Maschinenbau gewesen wäre – das kann man auch in Indien sehen, im Maschinenbau
z.B. wird man nicht so schnell befördert.“ (SD8, die kursiv gesetzten Wörter waren
sehr betont gesprochen – PF)

Eng verknüpft mit schnellen und absehbaren Beförderungen ist die Frage des Gehalts und vor
allem der Gehaltssteigerungen. Auch hier wird das System so gestaltet, dass es den längeren Verbleib
im Betrieb unterstützt, bzw. attraktiv macht.
Es ist nach Aussagen von Vertretern des höheren Managements explizit Strategie bei Service-
Tec, nicht die besten Gehälter der Branche zu zahlen. Das Grundgehalt auf der Einstiegsebene
liegt daher nach Angaben von Managern und auch Entwicklern mit ca. 400 € brutto lediglich im
Branchendurchschnitt. Das hat natürlich auf der einen Seite den Grund, dass man einfach nicht so
112 Fallstudie ServiceTec

hohe Kostensteigerungen haben möchte und daher versucht, die Gehaltssteigerungen der letzten
Jahre nicht vollends mitzugehen. Auf der anderen Seite möchte man auch nicht in erster Linie
diejenigen anziehen, die ausschließlich wegen des Geldes kämen, weil diese bei einem besseren
Angebot erwartungsgemäß auch schnell wieder weg seien.
Daraus lässt sich aber nicht folgern, dass bei ServiceTec kein gutes Gehalt erlangt werden kön-
ne. Im Kapitel zur Kontrollstruktur (Kapitel 5.3.2) wurde bereits erläutert, dass alle Gehälter über
das Grundgehalt hinaus variable, leistungsbezogene Anteile besitzen und diese Anteile sich über-
proportional erhöhen, sofern die Entwickler gute Bewertungen erhalten. Dieser Bestandteil sollte
jedoch nicht überschätzt werden, da der Anteil der variablen Gehaltsbestandteile auf der Ebene der
Entwickler noch vergleichsweise gering ist, sich aber mit Aufstieg stetig erhöht. Sollen Beschäftigte
mit variablen Zulagen vor allem zu höherer Arbeitsleistung veranlasst werden, so zielt die Erhö-
hung der Grundgehälter eher darauf ab, Beschäftigte zu einem längeren Verbleib im Unternehmen
zu motivieren. Nach Aussagen der Beschäftigten gehen die häufigen Beförderungen nämlich auch
mit starken Steigerungen des Grundgehalts einher. Gaben Beschäftigte an, auf dem Einstiegsniveau
umgerechnet ca. 400 € zu verdienen, so waren dies für die Rolle eines Projektmanagers – eine Po-
sition, die gut bewertete Beschäftigte nach 5 Jahren erreicht haben können – bereits über 800 €.
Es wird also ein relativ geringes Einstiegsgehalt mit hohen Steigerungsraten für die gut bewerteten
Beschäftigten verknüpft. Auch hier gilt der bereits in Kapitel 5.3.2 zitierte Grundsatz:

„Rather than being the best employer for all employees, we will be a better employer
for better employees.“ (SI7)

Für gut bewertete Beschäftigte bietet sich bei ServiceTec damit also die Möglichkeit, ihr Gehalt
bei entsprechend längerem Verbleib in der Firma stark zu erhöhen.
Eine weitere Maßnahme, mit der Fluktuation bei ServiceTec eingedämmt werden soll, besteht
in befristeten Versetzungen von Beschäftigten aus den indischen Entwicklungszentren an den Ort
des Kunden in den Onsite-Teil des Projektteams. Grundsätzlich werden die Teams vor Ort beim
Kunden regelmäßig durchrotiert, um möglichst vielen Beschäftigten, die Möglichkeit zu geben,
einmal vor Ort beim Kunden zu sein (vorausgesetzt, die Person erfüllt die Anforderungen an das
Tätigkeitsprofil onsite, siehe Kapitel 5.2).
Dieser Aufenthalt ist für die Beschäftigten aus zwei Gründen besonders attraktiv: zum einen ist
eine Beschäftigung vor Ort beim Kunden finanziell sehr interessant. Zwar behalten auch Perso-
nen, die für eine bestimmte Zeit beim Kunden arbeiten, formell ihren indischen Arbeitsvertrag, es
gibt jedoch einen „Onsite-Bonus“, also einen Zuschlag, der das Gehalt auf das Niveau der vor Ort
üblichen Gehälter anhebt. Aufgrund der Lohndifferenz zwischen Indien und Deutschland stellen
diese Anhebungen für die indischen Beschäftigten eine erhebliche Gehaltssteigerung dar. Für die
Beschäftigten bietet ein Aufenthalt beim Kunden demnach nach eigenen Angaben die Möglichkeit,
eine größere Summe zu sparen und damit nach der Rückkehr Investitionen in Indien vorzuneh-
men, z.B. ein eigenes Auto oder eine Wohung zu kaufen:

„We can send people on-site they have a higher potential of saving. Because you get
paid as according the norms of that country and that’s much more than what you
earn here. So we have policies about rotating people from offshore to onsite so that
you give opportunities to all to earn something, to save a little bit more. The aspiration
is still there to go on-site amongst the junior folks in the company.“ (SI5)

Doch auch über den finanziellen Anreiz hinaus, sind die „Onsite-Postings“ für die Beschäftig-
ten attraktiv, bieten sie doch die Möglichkeit, viel über die Region und das Geschäftsumfeld des
Betriebliche Kontrollstrategien bei ServiceTec 113

Kunden zu lernen. Diese Auslands- und Kundenerfahrung – die bei ServiceTec von den Beschäf-
tigten stets „Exposure“ genannt wird – wird von den Beschäftigten als sehr karriereförderlich und
spannend wahrgenommen.
Diese „Onsite-Postings“ werden daher bei ServiceTec sehr gezielt vergeben. Auch wenn das Ma-
nagement stets betont, dass eine Versetzung an den Ort des Kunden grundsätzlich für alle Be-
schäftigten gleichermaßen möglich sein soll und in der Tat die Mitglieder der Onsite-Teams häufig
rotiert werden, stellt die Gewährung einer solchen Versetzung doch immer auch ein strategisches
Mittel dar, um wechselwillige Beschäftigte vielleicht doch in der Firma zu halten, wie folgender
Manager verrät:

„Das ist eine Attraktion. Auf jeden Fall. Insbesondere, wenn jemand ankündigt: ’Ja,
ich will die Firma verlassen’. Dann wird sehr oft gefragt: ’Okay, lohnt es sich, wenn wir
dich nach onsite schicken, bringt das was?’. Und dann manche sagen: ’Ja, das bringt mir
schon was. Weil ich erstens mehr verdiene, und ... Eigentlich erstens mehr Erfahrung
sammle und zweitens auch mehr verdiene’. Das ist sehr beliebt. [...] Ich würde sagen,
für 70% ist es schon eine Attraktion.“ (SD8)

Neben der Etablierung von klaren Karrierewegen und attraktiven Versetzungen an den Ort des
Kunden ist bei ServiceTec auch das Arbeitsumfeld als spezielle Attraktion für die Beschäftigten
zu nennen. Auf die Frage nach den positiven Aspekten einer Beschäftigung bei ServiceTec nann-
ten die meisten der Beschäftigten überraschenderweise das Arbeitsumfeld als einen der ersten und
wichtigsten Punkte, wie auch beispielhaft der folgende Projektmanager:

„Yes, I mean - one thing I liked about ServiceTec is .. I mean .. I feel like I am getting a
very good environment to come here. You must have seen how the city of Bangalore
is outside the ServiceTec world. If I’m coming here, I feel like I’m coming to the new
world. I think that’s probably the inspiration I get.“ (SI6)

Immerhin hat ServiceTec sehr großen Aufwand auf die Gestaltung der Bürogebäude und des Be-
triebsgeländes verwendet. So finden sich auf diesem parkähnlich angelegten Betriebsgelände neben
den sehr modernen und komfortablen Bürogebäuden diverse Freizeitangebote, wie Swimming-
Pool Landschaften, Billardhallen und Golfplätze, die den Beschäftigten nach 17.00 Uhr kostenlos
zur Verfügung stehen. Ebenso gibt es kostenlose Verpflegung in mehreren Kantinen mit abwechs-
lungsreichem und umfassendem Angebot an Speisen und Getränken. Gegenüber den Freizeitange-
boten in Bangalore stellen die Anlagen ein sehr luxuriöses Ambiente dar und veranlassen demnach
viele Beschäftigte, auch den Feierabend auf dem Firmengelände zu verbringen.

„This is more than a place to work. [...] Typically we don’t call it as an office. We
call it a campus, because it’s more than just sheer office buildings. You’ll find the food
courts, you’ll find the endogen’s facilities, the medical centre, the bank, the typical
food provision stores etc. So it’s, like: you can get all your work done over here, staying
here. So you really don’t have to go out to a club or something in the evening and all
that stuff. So that creates an environment, where people can look to come back every
morning, even, whatever traffic condition outside – people love to come back“ (SI7)

Als letzter Punkt soll noch eine weitere Maßnahme zur Reduzierung von Personalfluktuation
erwähnt werden. Sie wirkt vor dem deutschen Erfahrungshintergrund etwas seltsam, demonstriert
aber eindrucksvoll, wie kreativ ServiceTec im Kampf gegen die Fluktuation vorgeht und welch
114 Fallstudie ServiceTec

weitreichende Überlegungen zu diesem Thema angestellt werden. So gewährt ServiceTec sogen.

„Dating Allowances“. Dahinter verbirgt sich eine Kostenerstattung für persönliche Verabredungen
zwischen männlichen und weiblichen Beschäftigten. So können sich Beschäftigte etwa die Kosten
für Kinotickets von der Firma erstatten lassen. Damit sollen strategisch unternehmensinterne Part-
nerschaften gefördert werden, da angenommen wird, dass es sich auf die Beschäftigungsstabilität
positiv auswirkt, wenn beide Partner bei ServiceTec arbeiten. In die gleiche Richtung gehen auch
finanzielle Anreize in Form von Gehaltszuschlägen, wenn Beschäftigte ihre jeweiligen Partner oder
Freunde zu einem Eintritt bei ServiceTec bewegen28 .

Gerade die zuletzt genannten Maßnahmen zur Vermeidung von Fluktuation zeigen sehr deut-
lich die Relevanz, die dieses Thema für ServiceTec besitzt. Umso erstaunlicher ist der Befund, dass
von Seiten des Managements ein wesentlicher Punkt nicht angesprochen wird, mit dem ServiceTec
zu kämpfen hat, und der in den geführten Interviews auch mehrfach auftauchte: Wechsel der Fir-
ma aufgrund von Unzufriedenheit mit dem Inhalt und der Form der Arbeit. In ihrer Studie zu den
Fluktuationsraten in der indischen IT-Industrie kommen Lacity, Rudramuniyaiah und Iyer (2008,
S. 217f.) zu dem Schluß, dass die Suche nach herausfordernden Arbeitsaufgaben bei den von ihnen
interviewten Entwicklern sogar ein stärkeres Motiv ist, die Firma zu verlassen, als der Wunsch
nach einem höheren Gehalt.
Auch Upadhya und Vasavi (2006, S. 52ff.) betonen diesen Aspekt. Demnach haben gerade IT-
Dienstleistungsunternehmen mit bestimmten Einschränkungen der Attraktivität ihrer Arbeits-
aufgaben zu kämpfen, die aus dem Geschäftsmodell folgen. So müssen sie häufig mit relativ al-
ten Technologien arbeiten, weil Kunden diese Technologien noch einsetzen. Bei ServiceTec z.B.
muss ein Großteil der Beschäftigten noch mit Mainframes arbeiten, einer älteren und nach Aus-
sagen der Entwickler auch umständlichen Technologie, die in ihrer Attraktivität längst nicht mit
neueren Technologien mithalten kann. Zudem sind die Arbeiten auf Bereiche beschränkt, die Ge-
genstand von Offshore-Outsourcing sind. Wie beschrieben, sind dies meist unterstützende oder
ergänzende Tätigkeiten für den IT-Betrieb des Kunden. Auch konzentrieren sich in den Offshore-
Entwicklungszentren zumeist die ausführenden und arbeitsintensiven Phasen der Softwareerstel-
lung, die die Attraktivität der Aufgaben zusätzlich drücken. Hinzu kommt die typische Prozessori-
entierung der IT-Dienstleister und die daraus resultierende Form der Projektorganisation. All diese
Aspekte führen nach den Ergebnissen von Upadhya und Vasavi (ebd.) dazu, dass viele Beschäftigte
aus Unzufriedenheit mit ihren Arbeitsaufgaben nach einer gewissen Zeit die IT-Dienstleister auf
der Suche nach attraktiveren Arbeitsaufgaben verlassen und ihr Glück bei anderen Firmen suchen.
Dieses Thema wird bei ServiceTec jedoch kaum in Hinblick auf die Vermeidung von Fluktuati-
on behandelt. Zwar wird die Rotation der Beschäftigten zwischen Projekten und Arbeitsaufgaben
von Seiten des Managements teilweise damit begründet, dass somit auch stetig wechselnde Aufga-
ben für die Entwickler entstünden, die Routine und Monotonie vorbeugen. Jedoch ist dies nach
Darstellung der Entwickler wohl weniger wirkungsmächtig, da die Aufgaben so zugeschnitten
sind, dass sie nach kurzer Einarbeitungszeit beherrscht werden können und sich schnell wieder
Langeweile einstellt (vgl. auch ebd., S. 52).
Die Gestaltung der Arbeitsprozesse folgt vielmehr dem Ziel der Immunisierung der Projekte
gegen die negativen Wirkungen von Fluktuation: Man will die Projekte möglichst unabhängig von
einzelnen Personen machen und die Fluktuation dadurch ihrer Risiken für den Geschäftserfolg so
weit wie möglich berauben. Entscheidendes Mittel dazu ist die Prozessorientierung bei ServiceTec
28
Dieses sogen. „Buddy-Referral“, also das Anwerben von Freunden und Bekannten in die eigene Firma ist durchaus
beliebt. Viele der im Rahmen dieser Studie interviewten Beschäftigten haben genau auf diesem Wege zu ServiceTec
gefunden.
Betriebliche Kontrollstrategien bei ServiceTec 115

mit ihren gezeigten Folgen, der starken Standardisierung und Formalisierung der Arbeitsabläufe,
mit denen die Abhängigkeit der Arbeitsabläufe von den einzelnen Entwicklern drastisch reduziert
wurde.
Zudem wurde bereits in Bezug auf die Aufgabenorganisation geschildert, dass dieses strategische
Bemühen innerhalb der Projektteams organisatorisch noch dadurch unterstützt wird, dass Spe-
zialisierungschancen der Beschäftigten durch stete Rotation der Teams und der Arbeitsaufgaben
gezielt unterlaufen werden sollen und die Qualifizierungsbemühungen eher auf fachliche Breite
statt Tiefe setzen (vgl. Kapitel 5.3.1).
Diese Gestaltung der Arbeitsabläufe wird durch begleitende Maßnahmen ergänzt, um die Unab-
hängigkeit der Projekte von einzelnen Entwicklern sicherzustellen. So gibt es z.B. ein umfassendes
„Backup-System“ für zentrale Rollen in Projekten. Dies bedeutet, dass für jede zentrale Rolle in ei-
nem Projekt eine Vertretung existiert, die permanent über alle Dinge, die die andere Person tut, auf
dem Laufenden gehalten wird und den Fortgang des Projektes genau mitverfolgt. Formell kann die-
se Person währenddessen in einer anderen Funktion tätig sein. Im Notfall kann diese Person dann
schneller die Tätigkeiten übernehmen, als wenn sie erst beim Fortgang des Kollegen eingearbeitet
werden müsste:

„Always there is a backup for everybody in the project. [...] Even our manager would
have a backup, if he told, he has to leave, there would be one person, who will be
knowing his work and who will be, who should be able to take care in his absence.“
(SI13)

Dem „Problem“ individuell gewonnenen Erfahrungswissens – z.B. im Umgang mit Kunden,

bestimmten Technologien usw. – das trotz aller Rotation im Projektverlauf stets auftritt, wird
bei ServiceTec mit dem Aufbau eines systematischen Wissensmanagements begegnet. Dabei wird
versucht, das Erfahrungswissen der Beschäftigten so weit wie möglich zu objektivieren und zu
dokumentieren. So lasse sich die Gefahr, dass eine Person bei Verlassen des Projektes wichtiges
Know-How mitnehme, reduzieren, wie folgender Projektmanager ausführt:

„Ja, weil wir alles dokumentieren. [...] Ich würde sagen: 80% allen Wissens, das jetzt
in den Köpfen ist, wird irgendwann mal irgendwie dokumentiert. Daher bleibt es im
Team – die restlichen 20% sind immer Verlust.“ (SD8)

Die Aussage dieses Interviewpartners, dass 80% des Wissens „irgendwann mal irgendwie“ doku-
mentiert werden, sollte nicht den Eindruck aufkommen lassen, dies sei eine unklare Sache und eher
Wunschtraum des Managers als reale Praxis. Vielmehr ist die vage Äußerung Hinweis auf die Kom-
plexität des Themas. So gibt es bei ServiceTec ganz unterschiedliche Ebenen, auf denen versucht
wird, das individuell gewonnene Wissen der Beschäftigten per Dokumentation zu objektivieren
und übertragbar zu machen.
Die wichtigste Einrichtung bei ServiceTec zu diesem Zweck ist eine Wissensdatenbank, in der
jeder Beschäftigte Einträge erstellen kann, die dann von allen anderen Kollegen gelesen und ggf.
ergänzt werden können. Thematisch sind den Einträgen dabei kaum Grenzen gesetzt; so können
sie Informationen zu bestimmten Kunden oder zu bestimmen Technologien etc. enthalten. Diese
Datenbank folgt damit grob der Idee eines Wikis, mit dem entscheidenden Unterschied, dass die
Aktivitäten der Beschäftigten keinesfalls anonym sind, sondern ganz im Gegenteil gezielt proto-
kolliert und analysiert werden, da das Engagement beim Aufbau und der Pflege der Datenbank
auch gehaltsrelevant ist:
116 Fallstudie ServiceTec

„Und diese Dokumente werden auch .. es werden [...] Dokumente vorbereitet, die
eher in generische Variante vorliegen. Also nicht spezifisch zu einer Person oder zu
einem Modul oder zu einem Programm – und die dann sind ... stehen zur Verfügung
für alle. Wir haben auch eigenes Portal [...]. Und da kann man diese [...] Dokumen-
te dann auch uploaden. Und dann bekommt man sogenannte Currencies und so ...
Punkte halt. Und je öfter das Dokument gelesen wird – das ist eigentlich unterneh-
mensweit – desto mehr die Currencies werden dann teurer. Und dann am Ende des
Quartals kann man die Currencies gegen Geld tauschen. [...] Ja, um halt einen Mo-
tivationsschub zu geben: ’Ihr sollt mehr [Dokumente] schreiben, erstellen, und auch
diejenigen, die das lesen und bewerten, bekommen auch bisschen, ... so dass auch mehr
Leute eigentlich in diesen Lese-Zirkel auch einbezogen werden.“ (SD8)

Mit der Einführung einer eigenen Währung für Dokumentationsleistungen wird also auch ein
finanzieller Anreiz geschaffen, um die Beschäftigten zum freiwilligen Einstellen ihrer persönlichen
Erfahrungen in dieses System zu motivieren. Diese Wissensdatenbank wird von den Beschäftigten
anschließend genutzt, wenn z.B. Probleme mit bestimmten Kunden oder bestimmten Anwendun-
gen auftauchen. In dieser Datenbank lassen sich Aufzeichnungen von anderen Projekten finden,
die evtl. auch das Problem hatten, mit dem das aktuelle Projekt konfrontiert ist, und evtl. eine
Lösung gefunden haben. Über die in der Dokumentation erwähnten Personen können so auch
Ansprechpartner identifiziert werden.
Entsprechende Dokumentationspflichten bestehen auch auf der Ebene des geschriebenen Pro-
grammcodes in Form von Kommentaren, die dem Code zur Erläuterung beigefügt werden müssen,
damit sich ein anderer Entwickler, der evtl. später damit arbeiten muss, schnell im Code zurecht-
findet29 .
Die genannten Maßnahmen illustrieren den großen Aufwand, der bei ServiceTec betrieben
wird, um die Abhängigkeit der Projekte und des Unternehmens von einzelnen Entwicklern zu
minimieren. Diese Bemühungen sind bei ServiceTec sehr weit fortgeschritten, wie sich aus den
Schilderungen der Beschäftigten entnehmen lässt. So berichten sowohl Projektmanager als auch
Beschäftigte, dass es zumeist lediglich ca. 3 Wochen dauere, um einen das Projekt verlassenden
Beschäftigten durch einen Nachrücker zu ersetzen. Gerade der Vergleich zum anderen in dieser
Studie untersuchten Unternehmen NovoProd, in dem diese Zeit gewöhnlich mit sechs bis acht
Monaten angegeben wird, zeigt drastisch, wie weit ServiceTec in seinen Bemühungen, die Ar-
beitsprozesse von den Beschäftigten unabhängig zu machen, fortgeschritten ist.

Der spezifische Umgang ServiceTecs mit den für den indischen Standort typischen hohen Fluk-
tuationsraten besteht also in einer sehr spezifischen Mischung aus Reduzierung und Kanalisierung
von Fluktuation. Auffällig ist dabei, dass sich die Bemühungen, die Fluktuation zu reduzieren we-
sentlich auf den betrieblichen Rahmen richten: Anreize für die Beschäftigten werden v.a. in Bezug
auf Karriereverlauf und Vergütung, attraktive Arbeitsplatzwechsel und das Arbeitsumfeld geschaf-
fen. Der Inhalt der Arbeit, und damit auch die konkrete Form der Aufgabenorganisation bleibt
jedoch von diesem Bemühungen weitgehend unangetastet. Dieser Bereich wird vielmehr von der
strategischen Zielsetzung dominiert, die Abhängigkeit von den Entwicklern im Arbeitsprozess
soweit wie möglich zu reduzieren, und die Projekte damit gegen Personalfluktuation möglichst
weitreichend zu immunisieren.
29
Dies mag auf den ersten Blick banal erscheinen, aber indische Entwickler klagen häufig über fehlende Kommentare
im Programmcode, wenn sie in den Systemen des Kunden arbeiten müssen.
Zusammenfassung und Bewertung der bei ServiceTec verfolgten Kontrollstrategie 117

5.4 Zusammenfassung und Bewertung der bei ServiceTec

verfolgten Kontrollstrategie
Als Anbieter von Offshore-Outsourcing Dienstleistungen verfolgt ServiceTec ein Geschäftsmo-
dell, dass dem der Literatur entnommenen Leitbild des „Global-Delivery-Models“ in fast allen
Punkten entspricht. So findet sich bei ServiceTec die typische Trennung der Arbeitsabläufe in
einen kundennahen „Onsite“-Bereich und einen indischen „Offshore“-Bereich (hier: in Indien).
Mit der räumlichen Trennung geht eine Arbeitsteilung einher, welche die planenden und kon-
zeptionellen, sowie die eher kommunikationsintensiven Tätigkeiten in den Onsite-Teams konzen-
triert, wohingegen die eher arbeitsintensiven und ausführenden Tätigkeiten auf die Teams im in-
dischen Entwicklungszentrum entfallen. Diese Trennung begründet auch einen wesentlichen Un-
terschied in der Komplexität der am jeweiligen Standort ausgeführten Arbeitspakete.
Zudem stellt die für das „Global-Delivery-Model“ für essentiell erachtete Prozessorientierung
auch bei ServiceTec ein zentrales Merkmal der Arbeitsorganisation und -kontrolle dar. Betrachtet
man die strategische Ausrichtung ServiceTecs in Bezug auf die Kontrolle der Arbeitsprozesse im
indischen Entwicklungszentrum, so drängt sich der Begriff der „Software-Factory“ geradezu auf.
Nach eigenen Aussagen versucht ServiceTec die „Industrialisierung“ der Arbeitsprozesse intern
möglichst weitreichend umzusetzen und grenzt sich gezielt von einem Bild der Softwareentwick-
lung als einer kreativen und auf die Selbstorganisationsfähigkeiten der Entwickler angewiesenen
Art von Arbeit ab. Statt dessen wird bei ServiceTec stets die umfassende Durchdringung der Ar-
beitsprozesse mithilfe standardisierter Prozessmodelle betont. Dementsprechend restriktiv sind
auch die im indischen Entwicklungszentrum implementierten Kontrollstrategien.

Wie sich bei der Analyse der Aufgabenorganisation gezeigt hat, prägen die Prozessmodelle ganz
wesentlich die Art und Weise, in der bei ServiceTec versucht wird, die Gesamtleistung in einzelne
Arbeitspakete zu zergliedern. Für jede von ServiceTec angebotene Art von Dienstleistung exis-
tiert eine Prozessbeschreibung, in der die nötigen Arbeitsschritte zur Erbringung jener Leistung
definiert sind. Auf Basis dieser Ablaufvorgaben entwickeln die jeweiligen Projektverantwortlichen
anschließend ihre detaillierten Projektpläne, die bereits die nötigen Arbeitspakete ausweisen, die
anschließend auf die Beschäftigten des Teams – stets nur als „Ressourcen“ bezeichnet – verteilt wer-
den. ServiceTec hat großen Aufwand betrieben, diese Vorgaben, die sich aus den Ablaufbeschrei-
bungen der Prozessmodelle ergeben, durch ein umfangreiches Set an weiteren Normenkatalogen,
wie z.B. Coding-Guidelines und detaillierten Checklisten für jeden Arbeitsschritt zu ergänzen, um
die Komplexität und (damit zusammenhängend) die zeitliche Länge der Arbeitsaufgaben möglichst
weit zu reduzieren.
Das Zusammenspiel dieser Maßnahmen führt dazu, dass sich bei ServiceTec eine extreme Ar-
beitsteilung mit sehr kurztaktigen und stark vorspezifizierten Arbeitsaufgaben findet. Nach An-
gaben der Gesprächspartner werden Arbeitspakete angestrebt, die in einem Zeitrahmen von 2-8
Stunden bearbeitet werden können. Zwar wechseln die Arbeitspakete sowohl im Laufe des Pro-
jektablaufs, als auch dadurch, dass die in einer Phase des Projektes anfallenden Aufgaben rotierend
vergeben werden, jedoch kann diese Abwechslung den monotonen und routinisierten Charakter
der Arbeitsaufgaben nicht überdecken, der von den Beschäftigten ganz eindeutig zum Ausdruck
gebracht wird.
Vielmehr konnte gezeigt werden, dass die stete Rotation der Beschäftigten zwischen Arbeitsauf-
gaben und Projektteams, vor allem der Vermeidung von fachlicher Spezialisierung dient. Strategi-
sches Ziel ServiceTecs ist es, die Projekte stets „process-depending and not people-depending“ zu
halten. Ein Zuschnitt der Arbeitsaufgaben, deren Erledigung keine lange Einarbeitungszeit und
118 Fallstudie ServiceTec

keine tiefen, über die technische Realisierung hinausgehenden, fachlichen Kenntnisse erfordert,
bietet ServiceTec damit die Möglichkeit, die Beschäftigten auf Entwickler-Ebene sehr flexibel ein-
zusetzen. Einerseits kann damit auf unregelmäßiges Geschäftsaufkommen reagiert werden, indem
Projekte personell schnell auf- und abgebaut werden können. Andererseits wird damit auch die
Gefahr, die von den hohen Fluktuationsraten ausgeht, reduziert, indem Beschäftigte, die das Un-
ternehmen verlassen, schnell durch andere Entwickler ersetzt werden können.

So feingliederig die Arbeitsteilung bei ServiceTec ist, so detailliert und eng ist auch die Form der
Kontrollstruktur. Die mit den Prozessvorgaben verknüpften Vorgaben zur Bearbeitung der Ar-
beitspakete fungieren dabei als zentrales Mittel der Anleitung und Anweisung der Entwickler. Bei
Unklarheiten und Problemen stehen mit den jeweiligen Modulleitern darüberhinaus entsprechend
weisungsbefugte und -befähigte Vorgesetzte bereit, die schon aufgrund der räumlichen Anordnung
der Arbeitsplätze in einem gemeinsamen Cubicle stets präsent und ansprechbar sind.
Auch für die Überwachung der Arbeitsabläufe ist die genannte Präsenz der Modulleiter wichtig,
sind sie doch stets in der Lage, etwaige Probleme und Verzögerungen im Ablauf zu erkennen. Al-
lerdings verlässt sich ServiceTec nicht ausschließlich auf diese persönliche Form der Überwachung,
sondern hat zudem ein sehr detailliertes Computersystem implementiert, das neben der computer-
gestützten Zuweisung der Arbeitsaufgaben an die Entwickler auch die Funktion übernimmt, den
Bearbeitungsvorgang für das Management transparent zu machen, weil jeder Beschäftigte – nach
Angaben der Beschäftigten auf Minutenbasis – seinen Arbeitstag und den Fortschritt der Aufga-
benbearbeitung dokumentiert. So besteht auch unabhängig vom direkten Kontakt der Entwickler
zu ihren Modulleitern für die Projektmanager stets die Möglichkeit, sich über den Fortschritt der
Projekte zu informieren. Der Rhythmus, in dem Manager sich über die Fortschritte des Projek-
tablaufes informieren, ist neben den strategischen Erwägungen ServiceTecs auch wieder von den
Anforderungen der Kunden abhängig. Diese unterscheiden sich in der Intensität, mit der sie Fort-
schrittsberichte von ServiceTec einfordern. Häufig ist jedoch der vom Kunden geforderte Takt
noch kürzer, als der von ServiceTec angestrebte. Auch an diesem Punkt wirkt sich also der Kun-
denkontakt wesentlich auf die Form der Arbeitskontrolle aus.
Die enge Überwachung der Arbeitsprozesse auf individueller Ebene ermöglicht es ServiceTec
schließlich auch, die individuell verausgabte Arbeitsleistung sehr detailliert zu „messen“. Zwar be-
ruht der Prozess der Beurteilung von Arbeitsleistung auf Zielvereinbarungsgesprächen zwischen
Management und Beschäftigten, doch zeigt sich bei näherer Betrachtung, dass es in erster Linie
darum geht, die Beschäftigten mit recht fixen Anforderungen von Seiten des Unternehmens hin-
sichtlich der Geschwindigkeit und Qualität der Arbeitsleistung zu konfrontieren. Die implemen-
tierten Systeme zur Messung von Arbeitszeit und zur Behebung von Programmierfehlern stellen
dabei wichtige Instrumente dar, mit denen die individuelle Arbeitsleistung vom Management um-
fangreich erhoben und vor dem Hintergrund der explizierten Anforderungen beurteilt werden
kann.
ServiceTec betont dabei stets die individuellen Anteile der Entwickler am Teamerfolg. Gemäß
der Formel der „individual contributors“ wird versucht, die Beschäftigten leistungsmäßig stark zu
differenzieren. Deutlichster Hinweis darauf ist der Umstand, dass alle Beschäftigten eines Teams
im Anschluß an den individuellen Bewertungsprozess zusätzlich noch einmal „gerankt“ werden,
d.h. in eine hierarchische Reihenfolge in Bezug auf ihre individuelle Arbeitsleistung gebracht wer-
den. Zudem ist die Verteilung der Beschäftigten auf die verfügbaren 4 Leistungsgruppen vorab
festgelegt, wodurch schon vor der Individual-Bewertung feststeht, wieviel Prozent der Beschäf-
tigten in den verschiedenen Leistungsgruppen sein müssen. Auf diese Weise können auch kleine
Differenzen hinsichtlich der Arbeitsleistung sehr gravierende Folgen haben: Da das Ergebnis des
Zusammenfassung und Bewertung 119

Bewertungsprozesses die Höhe des individuell ausgezahlten Gehaltsbonus determiniert und der
Zusammenhang zwischen Zielerreichung und Bonuszahlungen von ServiceTec bewußt überpro-
portional gestaltet wird, ist die Bewertung für Beschäftigte bei ServiceTec auch finanziell von enor-
mer Wichtigkeit. Mit diesem System der Leistungsbewertung wird eine interne Konkurrenz um
die besten Bewertungen geschürt, die noch durch symbolische Wettbewerbe und Titel innerhalb
der Teams verstärkt wird.

Dementsprechend findet sich auf der Ebene der Projektteams auch eher eine Zahl von „indivi-
dual contributors“ als wirklich kooperierende Teams. Arbeit auf der Ebene der Entwickler ist in
erster Linie Arbeit an individuell zugewiesenen Arbeitsaufgaben. Wenn Kooperation mit anderen
Teams oder gar mit Beschäftigten des Kunden nötig ist, so ist ServiceTec bestrebt, diesen Kontakt
– sofern möglich – über die Modul- und Projektleiter zu kanalisieren.

Betrachtet man die Arbeitsmarktbeziehungen ServiceTecs, so fällt auf, welch großen Einfluß
diese auf die von ServiceTec verfolgte Kontrollstrategie haben und wie viele der bereits erwähnten
Aktivitäten zur Arbeitsorganisation und -kontrolle auch strategische Überlegungen zum Umgang
mit der spezifischen Arbeitsmarktsituation reflektieren.
Aufgrund der ehrgeizigen Wachstumspläne und dem daraus folgenden großen Personalbedarf
ist ServiceTec von dem am indischen Standort zunehmend aufscheinenden Fachkräftemangel in
seinen Rekrutierungsbemühungen stark betroffen. Um dennoch in der beabsichtigten Geschwin-
digkeit zu wachsen, ist ServiceTec dazu übergegangen, neben der traditionellen Gruppe der En-
gineering-Absolventen zunehmend auch neue Zielgruppen für die Rekrutierung zu erschließen.
Voraussetzungen dafür schaffen die Trainingseinrichtungen ServiceTecs, in die in den letzten Jah-
ren erhebliche Ressourcen investiert wurden, um das Qualifikationsniveau der neu rekrutierten
Beschäftigten durch eine intensive Einführungsphase sicherzustellen. In gewisser Hinsicht bildet
die Form der Aufgabenorganisation auch die Voraussetzung dafür, dass solcherart geschulte Be-
schäftigte schnell produktiv in den Projekten mitarbeiten können, da längere Einarbeitungszeiten
aufgrund des Charakters der Arbeitsaufgaben nicht nötig sind.
Zudem stellt die strikte Prozessorientierung und die damit einhergehende Standardisierung und
Formalisierung der Arbeitsabläufe die Grundlage für den speziellen Umgang ServiceTecs mit den
für den indischen Standort charakteristischen Fluktuationsraten dar. Mit knapp 14% liegt Ser-
vicetec zwar unterhalb des Branchenschnitts, doch trotzdem ist dieser Aspekt in allen Interviews
präsent und wird sehr ernst genommen.
Es konnte gezeigt werden, dass der Umgang ServiceTecs mit den hohen Fluktuationsraten auf
der einen Seite darin besteht, die Arbeitsprozesse gegen Fluktuation (durch Standardisierung und
Formalisierung der Arbeitsabläufe) möglichst weitgehend zu immunisieren. Unterstützt werden
diese Bemühungen durch Initiativen im Bereich des Wissensmanagements, die darauf abzielen,
(auch unter Angebot finanzieller Anreize) Beschäftigte dazu zu veranlassen, individuelles Erfah-
rungswissen zu dokumentieren und mit ihren Kollegen zu teilen, was wiederrum die Abhängigkeit
der Projekte von den einzelnen Beschäftigten reduziert. Zudem existiert ein ausgefeiltes Backup-
System, das die Übernahme einer Position durch einen Nachfolger noch einmal beschleunigt. Zwar
führt diese Standardisierung und Formalisierung, wie gezeigt werden konnte, zu geringer Jobzu-
friedenheit der Beschäftigten und fördert damit seinerseits die Fluktuation, weil viele Beschäftigte
auf der Suche nach attraktiveren Jobs die Firma verlassen, doch ServiceTec ist gegenwärtig nach
Angaben des höheren Managements noch in der Lage, diese Fluktuation in den Arbeitsprozessen
zu verkraften.
Ein Grund, warum die Fluktuationsrate bei ServiceTec trotz der geringen Jobzufriedenheit der
120 Fallstudie ServiceTec

Beschäftigten mit 14% noch unterhalb des Branchendurchschnitts liegt, könnte sein, dass Service-
Tec zwar im Bereich der Arbeitsorganisation auf eine möglichst weitreichende Immunisierung
gegen Fluktuation setzt, sich im Bereich der betrieblichen Rahmenbedingungen jedoch stark be-
müht, die Beschäftigten durch positive Anreize an die Firma zu binden und damit die Fluktuations-
raten zu reduzieren. Als zentrale Elemente dieses Ansatzes konnten die Gewährung von schnellen
und vor allem berechenbaren Karrierewegen, die damit zusammenhängenden Gehaltssteigerungen
und die attraktive Möglichkeit, für eine Zeit vor Ort beim Kunden zu arbeiten, herausgearbeitet
werden. Auch die luxuriöse Arbeitsumgebung auf dem Unternehmenscampus stellt für die Be-
schäftigten eine Attraktion dar, dauerhaft bei ServiceTec zu bleiben.

Demnach geht bei ServiceTec die Internationalisierung der Leistungserstellungsprozesse mit

stark industrialisierten Arbeitsabläufen einher. Dies betrifft sowohl die standortübergreifende Ko-
operation als auch die Arbeitsabläufe im indischen Entwicklungszentrum. Die Standardisierung
und Formalisierung führt dort zu extrem restriktiven Formen der Arbeitsprozesskontrolle durch
das Management. Als Grund für diese strategische Ausrichtung konnte zum einen das spezifische
Geschäftsmodell ServiceTecs als Anbieter von Offshore-Outsourcing Dienstleistungen herausge-
arbeitet werden. Immerhin wirkt sich die dafür typische Beziehung zu Kunden stark auf die Form
aus, in der ServiceTec seine Arbeitsabläufe intern gestaltet. So konnte die extreme Prozessorientie-
rung und die Notwendigkeit, den Projektablauf stets eng und feingliedrig zu überwachen, wesent-
lich auf Ansprüche der Kundenunternehmen zurückgeführt werden. Zum anderen zeigt sich je-
doch, dass viele Chrarakteristika der Aufgabenorganisation und -kontrolle bei ServiceTec auch Re-
aktionen auf die spezifischen Bedingungen am indischen Standort sind. So schafft die starke Stan-
dardisierung und Formalisierung der Arbeitsprozesse, die das Geschäftsmodell erfordert, gleich-
zeitig die Möglichkeit, auch gegenwärtig noch ehrgeizige Wachstumspläne am indischen Standort
zu realisieren und gleichzeitig mit erhöhten Fluktuationsraten organisatorisch umzugehen.

Die Intensität, mit der bei ServiceTec die „Industrialisierung“ der Leistungserstellungsprozesse
und der internen Arbeitsabläufe betrieben wird, erklärt sich daher daraus, dass in diesem Fall das
Geschäftsmodell eine starke Standardisierung und Formalisierung der Arbeitsprozesse erfordert,
und dieses Vorgehen gleichzeitig eine Möglichkeit bietet, erfolgreich auf dem indischen Arbeits-
markt zu agieren und die hohen Fluktuationsraten organisatorisch zu bearbeiten, sich die beiden
Aspekte also gegenseitig in ihrer Wirkung verstärken. Das Zusammenwirken zwischen verfolgtem
Geschäftsmodell und den spezifischen Bedingungen am indischen Standort ist allerdings nicht im-
mer so harmonisch. Dies wird die folgende Fallstudie des deutschen Standardsoftwareherstellers
NovoProd zeigen.
6 „Struggle for Ownership“ – Arbeit und
Kontrolle bei der deutschen Produktfirma
NovoProd
Steht der Fall ServiceTec für einen Reorganisationsmodus von Arbeit, der eine starke Standardi-
sierung und Formalisierung der Arbeitsprozesse, sowie eine daraus folgende, extrem restriktive
Form der Arbeitskontrolle beinhaltet, so stellt NovoProd einen gänzlich anders gelagerten Fall
dar. Einer zu einem hohen Grad international verteilten Entwicklung von Softwareprodukten
entspricht hier keine vergleichbare Standardisierung und Formalisierung der Arbeitsprozesse, wie
dies bei ServiceTec zu beobachten war. Vielmehr finden sich im indischen Entwicklungszentrum
von NovoProd viele Formen permissiver Kontrolle, die mit IT-Arbeit gewöhnlich assoziiert wer-
den.
Dieser deutliche Unterschied zu ServiceTec – so mein in diesem Abschnitt empirisch zu belegen-
des Argument – ist vor allem dem speziellen Internationalisierungsweg NovoProds als eines großen
Standardsoftwareherstellers geschuldet. Dieser Internationalisierungsweg und das damit verknüpf-
te Geschäftsmodell NovoProds implizieren klare Grenzen einer möglichen Standardisierung und
Formalisierung der Arbeitsprozesse und bewahren damit die Abhängigkeit von den individuellen
Selbstorganisations- und Problemlösungsfähigkeiten der Beschäftigten als einer erfolgskritischen
Ressource. Doch auch am Fall NovoProd lässt sich nachweisen, dass die entstehenden Formen
der Reorganisation von Arbeit im Zuge der Internationalisierung der IT-Industrie nicht allein un-
ter Rückgriff auf die verfolgten Internationalisierungswege der Unternehmen verstanden werden
können. So stellt der organisatorische Umgang mit den hohen Fluktuationsraten des indischen
Arbeitsmarktes und den damit verknüpften Orientierungen der Beschäftigten hinsichtlich Gehalt
und Karriere eine große Herausforderung für NovoProd dar und zwingt zu „indienspezifischen“
Anpassungen der Arbeitsorganisation und -kontrolle.

Auch in dieser Falldarstellung sollen zunächst einige Informationen zum Profil NovoProds ge-
geben werden (6.1), bevor ich mich dem von NovoProd verfolgten Modell der „verteilten Ent-
wicklung“ zuwende und die daraus folgenden Implikationen für die Form der Arbeitsorganisation
und -kontrolle im indischen Entwicklungszentrum von NovoProd diskutiere (6.2). In der Unter-
suchung der Kontrollstrategie steht dann die konkrete Umsetzung des Geschäftsmodells am indi-
schen Standort im Zentrum des Interesses und ich möchte zeigen, wie sich auch bei NovoProd aus
dem Wechselspiel zwischen den Anforderungen des Geschäftsmodells und den Bedingungen am
indischen Arbeitsmarkt ein bestimmter Reorganisationsmodus der Arbeit entsteht, der im Gegen-
satz zu ServiceTec jedoch wesentlich permissivere Kontrollformen beinhaltet (6.3).

6.1 Das Profil von NovoProd

NovoProd ist ein deutsches IT-Unternehmen, das sich auf die Herstellung und Implementierung
von betriebswirtschaftlicher Standardsoftware spezialisiert hat. Primäre Zielgruppe für die von

121
122 Fallstudie NovoProd

NovoProd entwickelten Produkte sind traditionell vor allem Großunternehmen oder -organisa-
tionen.
Im Jahr 2008 hatte NovoProd im Bereich der Softwareentwicklung über 15.000 Beschäftigte, die
an 9 Entwicklungsstandorten weltweit arbeiteten. NovoProd ist damit in hohem Maße internatio-
nal aufgestellt – von den über 15.000 Beschäftigten im Bereich der Softwareentwicklung arbeiteten
2008 nur ca. 40 % im Hauptquartier in Deutschland1 .
Historisch war NovoProd zunächst neben Deutschland ausschließlich mit Entwicklungsstand-
orten in anderen Hochlohnregionen Europas und Nordamerikas vertreten. Erst Ende der 90er
Jahre änderte sich dieses Bild und NovoProd begann gezielt, Offshore-Kapazitäten in Niedriglohn-
regionen aufzubauen. Als erstes Offshore-Entwicklungszentrum wurde Ende der 90er das indische
Entwicklungszentrum in Bangalore gegründet.
Als Gründe für diese Neuausrichtung wurden von den befragten Vertretern des höheren Mana-
gements vor allem zwei Punkte genannt.
Zum einen spielten – wenig überraschend – die Kostengesichtspunkte eine wichtige Rolle. Hatte
NovoProd lange Zeit aufgrund der angebotenen Produktqualität eine dominierende Stellung auf
dem von ihm bedienten Marktsegment, so sind NovoProd mit der Zeit zunehmend Wettbewerber
erwachsen, die auch qualitativ mit ähnlichen Produkten aufwarten und in der Folge zunehmend
Marktanteile erobern konnten. Aus diesem Grund befindet sich NovoProd unter stärker werden-
dem Konkurrenzdruck, der sich intern vor allem als stetiger Druck auf die Kosten der Produkt-
entwicklung auswirkt. Demnach wurde die Verteilung der Arbeiten auf die verschiedenen Ent-
wicklungszentren ab Ende der 90er Jahre auch zunehmend unter der Maßgabe verhandelt, einen
möglichst großen Teil der Arbeit an Niedriglohnregionen ausführen zu lassen.

„Und daran sehen Sie vielleicht auch eine Veränderung der Politik in dem Bereich:
Früher konnten die Geschäftsbereiche den Standort völlig frei aussuchen. Das heißt,
wir [das indische Entwicklungszentrum – PF] mussten von Anfang an darauf achten,
dass wir die gleiche Qualität liefern. Weil die Kollegen haben praktisch für ein Pro-
jekt 20 Head Counts zugebilligt bekommen, und die konnten sie jetzt in irgendeinem
Standort aufbauen. Kosten spielten keine Rolle in dieser Firma, also zumindest nicht
in diesem Bereich [lacht]. Das hat sich natürlich inzwischen verändert, ganz klar. Wir
achten sehr, sehr genau auf die Kosten. Das heißt heute ist dann die Maßgabe erstmal:
’Okay, low-cost Standort.’ Für bestimmte Sachen. Ist nicht immer so, aber für manche
Sachen sagt man: ’Okay, kann man das in einem low-cost Standort machen?’“ (ND1)2

Zum anderen war jedoch auch das verfügbare Arbeitskräfteangebot ein wichtiger Grund für
die Gründung der indischen Niederlassung. Nach Aussagen der befragten Manager sei es für No-
voProd Ende der 90er schwierig geworden, in Deutschland neue Beschäftigte in ausreichender
Zahl und mit adäquater Qualifikation zu rekrutieren. Daher wurde entschieden, den Großteil
des Wachstums in den Offshore-Entwicklungszentren, wie z.B. Indien voranzutreiben, in denen
es leichter gewesen sei, schnell eine größere Zahl von Entwicklern einzustellen.

„Gut, wir hatten da letztlich das beste Gefühl vom Job-Markt her. Die Motivation
war ja ohnehin im Jahr ’99, dass wir hier nicht mehr genug Leute kriegen. Da lief ja
1
Alle Zahlen nach Geschäftsbericht von 2008.
2
Nähere Informationen zu den zitierten Gesprächspartnern bei NovoProd finden sich in Tabelle 8.2 (S. 210) im An-
hang.
Global verteilte Entwicklung bei NovoProd 123

gerade die erste Internet-Welle heiß, und die Startups haben natürlich einen unheim-
lich Zulauf gehabt von intelligenten jungen Menschen. Für ein etabliertes Unterneh-
men, was so ein bisschen als altmodisch galt, war es auch ein bisschen schwierig, gute
Leute hier zu kriegen. Wir haben auf manche Stellenanzeigen hier überhaupt keine
Response mehr bekommen. [...] In Indien war das eben anders. Da konnten wir halt
in bestimmten Bereichen in Indien sehr zügig wachsen.“ (ND1)

Dementsprechend rasant verlief auch das Wachstum des indischen Standortes innerhalb Novo-
Prods. Ende der 90er Jahre gegründet, arbeiteten 2008 bereits mehr als 3000 Personen dort3 . Das
indische Entwicklungszentrum ist damit in kurzer Zeit zum zweitgrößten Standort NovoProds
aufgestiegen.
Die im Rahmen dieser Studie untersuchte Abteilung ist Teil des Forschungs- und Entwicklungs-
bereiches von NovoProd, in ihr wird ein neues Software-Produkt entwickelt.

6.2 Global verteilte Entwicklung bei NovoProd

In seinem globalen Geschäftsmodell versucht NovoProd, sich von einem durch einen Vertreter des
höheren Managements wie folgt definierten „Standardansatz“ des Offshoring abzugrenzen:

„Aber jetzt, um ganz konkret zu werden: im Prinzip der klassische Ansatz dieses Offs-
horings, den jetzt die typischen indischen IT-Firmen auch fahren, [...] ist halt: Man
hat hier einen Projektmanager onsite beim Kunden – also, das kann ja irgendjemand
sein, und das kann auch ein interner Kunde sein - und einen offshore Projektmana-
ger und dann eine große Box darunter mit Leuten. Eigentlich kommunizieren nur 2
Leute miteinander und die anderen nicht. Und dann gibt es da vielleicht noch so ’nen
Delivery-Arm, der das dann wieder zurückliefert, was da gemacht wurde. Das ist, sa-
gen wir mal, so ein Standard-Ansatz.“ (ND1)

Dieser „Standardansatz“, der stark an das im vorigen Kapitel dargestellte „Global Delivery Mo-
del“ des indischen Serviceproviders erinnert, beinhaltet nach Ansicht des zitierten Gesprächspart-
ners demnach verteilte Projektteams, deren Mitglieder jedoch kaum direkt miteinander in Kontakt
stehen, sondern primär über die jeweiligen Projektmanager an den Standorten kommunizieren.
Gegenüber diesem „Standardansatz“ setze NovoProd nach Aussagen desselben Managers strate-
gisch eher auf „verteilte Entwicklung“. Grundlage der „verteilten Entwicklung“ ist eine modulare
Produktarchitektur, die sich in einzelne Komponenten zerlegen lässt. Diese Komponenten wer-
den anschließend an unterschiedlichen Standorten parallel entwickelt. Dabei werde bei NovoProd
darauf geachtet, dass auch die Standorte in Niedriglohnregionen jeweils umfassende Funktionen
wahrnehmen und nicht nur kleine Zuarbeiten zu anderen Modulen leisten, wie ein Manager an-
hand seines vorherigen Projektes erläutert:

„Das Zielmodell, das ich auch in der anderen Abteilung hatte, [...] war ganz klar: Gebt
bitte ein Arbeitsthema als Ganzes nach unten. Ja? [...]. Produktion, Vor-Produktionsplanung
und Detailed Scheduling habe ich damals als Ganzes nach Indien gegeben. Das war ei-
nes der richtig komplizierten Themen, auch so technisch höchst kompliziert. Es geht
um finite Planung - ich weiß nicht, inwieweit Ihnen das was sagt. [...] Und das ist
3
Diese Zahl bezieht sich auf den Zeitpunkt der Untersuchung. Bei Erscheinen dieser Studie wird die Zahl noch einmal
wesentlich höher sein, da der Standort in der Zeit nach der Befragung personell verstärkt wurde.
124 Fallstudie NovoProd

ein wirklich schwieriges Thema gewesen. Das haben wir komplett nach Indien gege-
ben. Und es hat sehr gut funktioniert. Das war - ich hatte 20 Leute, die gesagt haben,
es funktioniert nicht. Nie, so ein kompliziertes Thema, das würden die nie begreifen,
was wir da in den letzten zehn Jahren programmiert haben und in eins runter gegeben.
[...] Wir haben nur einmal am Anfang eine Situation gehabt, wo wir lösen mussten,
aber sonst hat es funktioniert.“ (ND6)

Modulare Strukturen bedeuten dabei keinesfalls, dass die einzelnen Komponenten gänzlich un-
abhängig voneinander wären. Vielmehr bestehen starke Interdependenzen, weil die einzelnen Kom-
ponenten zeitlich parallel entwickelt werden. So gibt es stets Situationen, in denen Änderungen an
einem Modul auch Auswirkungen auf andere Module haben, was bei „verteilter Entwicklung“ stets
hohe Kommunikations- und Kooperationsanforderungen zwischen den Modulen begründet.
Angestrebt wird bei NovoProd in Abgrenzung zum beschriebenen „Standardansatz“ eine Struk-
tur, in der nicht nur die Projektleiter an den unterschiedlichen Standorten, sondern vielmehr die
Entwickler direkt miteinander kommunizieren und kooperieren, der Kontakt also auch auf der
untersten Ebene stattfindet:

„Wir machen’s eigentlich eher tief integriert. Das heißt, wo der Projekt-Lead sitzt,
ist völlig – der kann überall sitzen, und wir fahren eigentlich eine Integration auf
Entwickler-Level, also die Entwickler kennen sich untereinander. Und dann haben
wir eben oft in einem Projekt – von mir aus – 5 in Deutschland, 5 in Indien. Im an-
deren ist einer in Deutschland, 10 in Indien. Dann haben wir auch Projekte, da sind
vielleicht 10 Leute hier und 2 in Indien oder so. Und der Projekt-Lead ist mal in Indien
und mal hier. Also das ist eine ganz andere Art und Weise der Zusammenarbeit. Ich
würde mal sagen, dass ein großer Teil unserer Projekte so gemanaged wird, und nur
ein sehr geringer Anteil eigentlich so ist, dass da nur 2 Leute miteinander kommuni-
zieren.“ (ND1)

Zudem solle vermieden werden, dass eine klare Asymmetrie zwischen den Standorten in Bezug
auf die Zuteilung planender und ausführender Tätigkeiten entsteht, indem die Entwicklungszen-
tren in Niedriglohnregionen die bei NovoProd so genannte „Ownership“ für die von ihnen be-
arbeiteten Komponenten erhalten. Gemeint ist damit, dass die an den verschiedenen Standorten
lokalisierten Module auch von diesen Standorten verantwortet werden.
Die Zielstruktur, die NovoProd in Bezug auf ihr globales Geschäftsmodell anstrebt, ist also ein
Netzwerk aus unterschiedlichen Standorten auf Basis modularer Produkt- und Organisationss-
trukturen. Dabei sollen auch Standorten in Niedriglohnregionen – wie Indien – weitreichende
Befugnisse und Verantwortlichkeiten für die von ihnen bearbeiteten Komponenten übertragen
werden.

Wenden wir uns im Folgenden der bei NovoProd vorfindbaren Realstruktur zu, so finden sich
auf den ersten Blick viele Merkmale der Zielstruktur verwirklicht.
Die im Rahmen dieser Studie untersuchte Abteilung ist Teil der Forschungs- und Entwicklungs-
abteilung NovoProds. Ihr obliegt die Entwicklung eines neuen Software-Produkts, das in verteilter
Entwicklung hergestellt werden soll. Das zu entwickelnde Produkt ist eine webbasierte Applikati-
on, die auf einer bereits existierenden Plattform aufbaut, die der Applikation die nötigen Funktio-
nen zur Verfügung stellt, deren Funktionsumfang jedoch von der Applikation in einer neuartigen
Art und Weise aufbereitet und zur Verfügung gestellt wird.
Global verteilte Entwicklung bei NovoProd 125

In das Entwicklungsnetzwerk sind im wesentlichen drei grosse Einheiten involviert, die sich
auf den deutschen und den indischen Standort verteilen4 . Ein Projektmanager beschreibt deren
Aufgabenprofile in der globalen Arbeitsteilung folgendermaßen:

„Yeah, usually Vision5 tries to give what the customers want. So they give the require-
ments, so to say. And then Plattform tries to see, whether they can do it or not do it
or whatever. And we, in Application, we build ... the entire application on top of this
platform. So the platform is more generic. We do some of the basics and we build the
actual application, and the user interface and everything. So, it’s a combination of all
the three.“ (NI11)

Die erste Einheit ist Vision. Vision ist für die Anforderungsanalyse für das neue Produkt zustän-
dig, erarbeitet somit in enger Kooperation mit zentralen Kundenunternehmen die notwendigen
Merkmale und Funktionen des Programms und erstellt in Usability-Studien auch Richtlinien für
das grafische Design der Applikation. Dieser Teil ist in der Firmenzentrale NovoProds in Deutsch-
land situiert.
Die zweite Einheit – Plattform – entwickelt die dem neuen Produkt zugrundliegende Plattform.
Diese Einheit befindet sich ebenfalls im Hauptquartier in Deutschland6 .
Die dritte Einheit schließlich – Application – die in dieser Studie auch im Fokus steht – entwi-
ckelt die Applikation gemäß der von Vision erarbeiteten Anforderungen und auf Grundlage der
vom Plattformteil bereitgestellten Funktionalitäten. Dieser Teil des Entwicklungsnetzwerkes ist
schwerpunktmäßig im indischen Entwicklungszentrum situiert. Eine derart umfassende Übergabe
von Entwicklungsaufgaben an einen Niedriglohnstandort habe es nach Aussagen von Vertretern
des höheren Managements in der Geschichte NovoProds bisher noch nicht gegeben. Zwar hätten
andere Entwicklungszentren in Niedriglohnstandorten bereits einzelne Module von Applikatio-
nen entwickelt, ein derart zentraler Teil einer neuen Applikation sei allerdings noch nie an einen
Niedriglohnstandort übertragen worden.
Nach dem bisher Gesagten finden sich bei NovoProd also – zumindest formal – jene Struktu-
ren, die als Zielstruktur der globalen Arbeitsteilung skizziert wurden: modulare Produkt- und Or-
ganisationsstrukturen mit weitreichenden Kompetenzen auch der in das Entwicklungsnetzwerk
eingebundenen Niedriglohnstandorte.

Doch gerade der letzte Punkt – der Umfang des Verantwortungsbereiches des indischen Stand-
ortes – stellt einen sensiblen Punkt im globalen Entwicklungsmodell NovoProds dar. Um die Pro-
bleme, die um dieses Thema kreisen, zu verstehen, muss man zunächst etwas tiefer in die Geschich-
te des untersuchten Entwicklungsprojektes einsteigen.
Der Entwicklung des Produkts und damit auch dem Start des untersuchten Projektzusammen-
hanges ging eine Phase der Forschung voraus, in der u.a. notwendige Spezifikationen für das
neue Produkt gesammelt und die technische Realisierbarkeit desselben getestet wurden. Diese For-
schungsphase wurde von sehr erfahrenen Entwicklern NovoProds in Deutschland durchgeführt.
Als schließlich der Entschluß feststand, das Produkt tatsächlich zu entwickeln, und als zusätzlich
4
Es werden einige kleinere Zuarbeiten auch von anderen Standorten, sowohl aus Hoch- als auch Niedriglohnregionen,
bezogen, diese stellen jedoch eher periphere Kooperationspartner dar, so dass sich im Folgenden auf die Zusammen-
arbeit zwischen dem indischen und dem deutschen Standort konzentriert wird.
5
Die Namen der an der Entwicklung beteiligten Organisationseinheiten wurden aus Anonymisierungsgründen geän-
dert – auch in den Zitaten.
6
Auch diese Abteilung hat mittlerweile einen kleinen Ableger in Bangalore, jedoch spielt dieser Teil bei der Entwick-
lung des hier betrachteten Produkts keine Rolle, so dass er im Folgenden auch unberücksichtigt bleibt.
126 Fallstudie NovoProd

beschlossen wurde, das Produkt im Entwicklungszentrum in Indien entwickeln zu lassen, wur-

de dem Team, das die Vorarbeiten in der Forschungsphase durchgeführt hatte, auch die Aufgabe
übertragen, das Entwicklungsteam in Bangalore aufzubauen und anzuleiten. Ein Mitglied des da-
maligen Forschungsteams beschreibt die Situation folgendermaßen:

„Ich habe im April 2004 gewechselt, zu einem damaligen Forschungsprojekt. Da war

ich dann eben für den neuen Bereich zuständig, den ich dann mit einer Gruppe hier
anfangen musste, zu entwickeln. [...] Es ging darum, das eben in einem neuen Se-
tup, mit neuen Zielen für einen neuen Zielmarkt auch aufzuarbeiten. Und man mal
technologisch untersucht, wie man es eben realisieren kann. Das haben wir dann ge-
macht. Ende 2004, Anfang 2005 ist dieses damalige Forschungsprojekt dann aus der
reinen Forschung in eine etwas angewandtere Forschung übergangen, in dem Sinne,
dass man wirklich in eine neue Produktentwicklung gegangen ist, das Ganze dann
auch geteilt hat in einen Plattformteil, der das Backend ausmacht und einen Frontend-
teil, der eben eher das UI und die Benutzeroberfläche ausmacht. [...] Und wie gesagt,
das war dann Anfang 2005, dass ich dann bei diesem Split praktisch gefragt worden
bin und mich dann auch entschieden habe, in diesen Lösungsteil, in diesen UI-Teil,
Benutzeroberflächen-Teil zu gehen, der dann sehr starken Kontakt mit Indien gehabt
hat.“ (ND7)

Als erfahrene Beschäftigte mit der Aufgabe betraut, den indischen Projektzusammenhang auf-
und auszubauen, nahmen die Mitglieder des ehemaligen Forschungsprojektes eine Position als so-
gen. „Brückenköpfe“ innerhalb des Entwicklungsnetzwerkes ein. Als „Brückenköpfe“ waren sie
zwar organisatorisch der in Indien verorteten Abteilung zur Entwicklung des neuen Produktes
(Application) zugeteilt, allerdings räumlich im deutschen Hauptquartier NovoProds situiert. In
der Position der „Brückenköpfe“ bündelten sich zunächst die schwerpunktmäßig kommunikati-
ven und planenden Tätigkeiten für Application.
So kümmerten sich die Brückenköpfe zum einen um die Kommunikation und die Kooperation
mit den beiden anderen an der Entwicklung beteiligten Abteilungen Vision und Plattorm. Koor-
diniert und geplant wird die Gesamtentwicklung des Produkts über ein spezielles Steuerungsgre-
mium, in dem Vertreter aller drei an der Entwicklung beteiligten Bereiche repräsentiert sind. Die
Treffen dieses Steuerungsgremiums sind für die weitere Entwicklung von zentraler Bedeutung:
zu implementierende Funktionen werden hier genauso diskutiert und beschlossen, wie zentra-
le Design- und Konzeptionsfragen. Beschlüsse, die hier getroffen werden, sind anschließend für
die Umsetzung in den Einheiten des Entwicklungsnetzwerkes bindend. Den Treffen dieses Steue-
rungsgremiums, die vorwiegend in Deutschland stattfinden, weil die Mehrheit der Projektteile
dort ansässig ist, wohnten die Brückenköpfe für ihre indischen Counterparts bei, da für sie im
Gegensatz zu ihren indischen KollegInnen keine Zeitverschiebung zu Deutschland existiert und
sie damit ein größeres Zeitfenster für Meetings und Absprachen haben. Zum anderen fielen am
Anfang der Projektlaufzeit auch die Projektmanagementfunktionen für Application den deutschen
Brückenköpfen zu.
Damit war die Arbeitsteilung zwischen den in Deutschland befindlichen „Brückenköpfen“ und
dem in Indien situierten Teil von Application zunächst dem beschriebenen „Standardansatz“ recht
ähnlich: Design- und Architekturentscheidungen im Steuerungsgremium und Projektmanagemen-
taufgaben wurden von den Brückenköpfen in Deutschland erledigt, den indischen Entwicklern
wurde mehr oder weniger ausschließlich die Umsetzung der in Deutschland getroffenen Entschei-
dungen überlassen, wie ein damaliger Brückenkopf klarstellt:
Global verteilte Entwicklung bei NovoProd 127

„Wir sind nach Indien gefahren und haben das Projekt detailliert durchgeplant. Wir
haben work packages definiert, haben die terminiert, dann einen Kapazitätsabgleich
gemacht.“ (ND4)

Der Hauptgrund dafür lag nach Ansicht der beteiligten Brückenköpfe vor allem in dem starken
Erfahrungsgefälle zwischen den deutschen, schon lange bei NovoProd arbeitenden, und den in
Bangalore für dieses Projekt weitgehend neu eingestellten Entwicklern:

„Okay, also die Situation war wie folgt: Das Team in Indien war jung, und war partiell
noch gar nicht eingestellt. Wir hatten alle relativ viel Erfahrung hier in Deutschland,
im deutschen Teil des Teams. Wir haben natürlich gleich die Projektleitung übernom-
men.“ (ND4)

Allerdings entsprach dieses Vorgehen – wie weiter oben bereits erwähnt – nicht dem Ziel von
NovoProd in Bezug auf die Einbindung des indischen Standortes. Dementsprechend sollte diese
klare Arbeitsteilung zwischen planenden und ausführenden Tätigkeiten auch lediglich am Anfang
des Projektes bestehen. Mit der Zeit sollte das indische Entwicklungszentrum selber die Entwick-
lung verantworten oder – wie es bei NovoProd heißt – die „Ownership“ für die neue Applikation
übernehmen. Daher war die Position der Brückenköpfe ursprünglich auch als eine temporäre an-
gelegt: die Brückenköpfe sollten das neue Team in Indien anlernen und dann möglichst schnell
abgezogen werden:

„Ursprünglich war es unser Ziel eigentlich, sich nach einem Jahr oder anderthalb Jah-
ren praktisch überflüssig gemacht zu haben, und dass das Ganze alleine läuft.“ (ND7)

Ein anderer Brückenkopf macht es ganz deutlich:

„Also mein Ziel wäre, dass wir den deutschen Teil unseres Teams komplett wegkriegen
würden.“ (ND4)

Im Zuge dieses Abbauversuches wurde in den letzten Jahren versucht, vermehrt Verantwortung
an das indische Entwicklungszentrum abzugeben:

„Also ich habe ja dann mehrere ganz junge indische Kollegen am Anfang betreut. Und
da habe ich dann sozusagen die Aufgaben, vor allem am Anfang, auch direkt zugeteilt.
Und zwar auch einzeln. Und dann habe ich später meistens, da hat sich dann einer
bei rauskristallisiert, der sehr gut mit Organisieren und Verteilen war. Der hatte einen
ganz guten Überblick und dem habe ich dann auch diese Aufteilung ein bisschen in
die Hand gegeben und gesagt: ’Hier, die folgenden Dinge sind zu machen.’ Habe dann
ein bisschen mit ihm gesprochen: Wie könnte man es machen? Was ist das Wichtigste?
Und dann hat er sozusagen auch intern das ein bisschen geregelt. Er war sozusagen
zwar hierarchisch nicht über den anderen, aber er hat ein bisschen mehr vom Ent-
scheidungskuchen abbekommen. Und ich habe dann aber schon an einigen Stellen,
wo ich gezielt Leute in bestimmte Richtung entwickeln wollte – oder sie hindrängen
wollte, gesagt: ’Das kann der sein, der vielleicht später in dem Bereich der ganzen Kon-
figurationstabellen, die wir haben, mehr machen sollte’ – da habe ich dann jemanden
bestimmt und gesagt: ’Das machst Du jetzt.’“ (ND2)
128 Fallstudie NovoProd

So sei in der Folge das Verhältnis zwischen den deutschen Brückenköpfen und den indischen
Beschäftigten auch weniger hierarchisch geworden, da viele Projektmanagementaufgaben nun von
der indischen Seite wahrgenommen würden, wie folgender Brückenkopf bestätigt:

„Doch, es [das Projektmanagement von Deutschland aus – PF] ist natürlich weniger
geworden. Aber das war auch unser Ziel, dass es weniger wird, dass die Leute selbst-
ständiger arbeiten.“ (ND4)

Doch obwohl sich somit bei NovoProd ganz deutlich die Versuche abzeichnen, dem indischen
Team zunehmend weitreichendere Steuerungsfunktionen über die Entwicklung zu übertragen,
war zum Zeitpunkt der vorliegenden Untersuchung eine vollständige „Ownership“ des indischen
Teils von Application für die Entwicklung der Kernapplikation nicht gegeben, wie sich aus der
Schilderung des Aufgabenprofils eines Brückenkopfes ersehen lässt:

„Ich bin ein sogenannter Brückenkopf. Das heißt, ich bin einem indischen Projekt-
team mit diesem indischen Projektleiter zugeordnet. Ich soll das Projekt gemeinsam
mit ihm leiten. Und die Aufgabenverteilung ist in etwa so: Ich bin für Software-
Architektur, Verhandlungen mit deutschen anderen Entwicklungsgruppen zuständig.
Wir haben unser Vision-Team, die also das Produkt spezifizieren, die sitzen hier in
Deutschland. Und auch die Basis, auf der wir aufbauen, sitzt größtenteils in Deutsch-
land. Und diese technischen Verhandlungen soll alle ich führen, auch dort weitrei-
chend Entscheidungen treffen. Und sein [des indischen Projektleiters – PF] Fokus ist
eher darauf, die Exekution in Bangalore zu treiben. Das heißt, wir besprechen gemein-
sam: Was ist zu tun? Wie wollen wir die Architektur-Aufgaben letztendlich lösen, oder
die Fragestellung, wo Konflikte sind mit anderen Gruppen? Da entscheiden wir dann
gemeinsam. Und dann ist er der, der sozusagen täglich den Fortschritt nachvollzieht
in Indien mit den jüngeren Projektteilnehmern.“ (ND2)

Zum einen sind es also immer noch primär die Brückenköpfe, die an den Treffen des Steue-
rungsgremiums in Deutschland für den Application-Bereich teilnehmen7 , zumal ihre vermittelnde
Funktion zwischen den deutschen und den indischen Teams (nach Ansicht des folgenden Brücken-
kopfes) als erfolgskritisch für eine gelingende Kooperation innerhalb des Entwicklungsnetzwerkes
angesehen wird:

„Und, also, ich denke, man braucht schlicht und einfach ein paar Leute, die mehr oder
minder so halbwegs verstehen, wie beide Seiten ticken. Ich meine, klar, man versteht
immer besser, wie die deutsche Seite tickt, weil man es ja nun mal ist, als wenn man
jetzt einfach nur sagt: Okay, da ist Vision, die schicken ihre Specs rüber und Plattform
schickt auch irgendwelche Specs rüber. Und das indische Team macht dann irgendwas
daraus. Das würde nicht funktionieren. [...] Also wenn man verteilt entwickelt, dann
muss man halt viel miteinander reden und man muss auch Austausch zwischen den
Lokationen haben, so dass man wirklich Leute hat, die sich auskennen.“ (ND5)

Zum anderen stellt sich auch die Übergabe von Projektmanagementfunktionen an den indi-
schen Teil von Application schwieriger dar, als es zunächst vom Management erwartet wurde. So
7
Manchmal werden auch indische Manager oder Beschäftigte per Videotelefonat in diese Treffen eingebunden, aber
meist nehmen nur die Brückenköpfe an diesen Treffen teil.
Global verteilte Entwicklung bei NovoProd 129

unterscheidet sich das Ausmaß, in dem Projektmanagementfunktionen mittlerweile nach Indien

vergeben wurden, innerhalb der Einheit z.T. stark. Application ist intern in verschiedene Teams
unterteilt. Jedes dieser Teams bearbeitet einen Ausschnitt der Gesamtapplikation, zumeist einen
bestimmten Funktionsbereich und hat einen separaten Brückenkopf auf der deutschen Seite, der
speziell für dieses Team zuständig ist. Vergleicht man nun diese Teams untereinander im Hinblick
auf die Übergabe von Steuerungsfunktionen an den indischen Standort, so fallen z.T. große Un-
terschiede auf. Einige indische Teams, wie das des folgenden Brückenkopfes, erledigen die Aufgabe
der Definition und Zuteilung von Arbeitsaufgaben mittlerweile gänzlich selbständig und in Eigen-
verantwortung:

„Das wird komplett in Indien gemacht. Ich mache das gar nicht mehr. Früher habe ich
das sehr genau gemacht. Zwischenzeitlich überhaupt nicht mehr.“ (ND4)

Andere Teams stehen jedoch noch immer unter intensiver Beobachtung und Steuerung von
Deutschland aus. Der Brückenkopf eines solchen Teams antwortet auf die Frage, ob er eine Mög-
lichkeit sehe, verstärkt Projektverantwortlichkeiten nach Indien zu übergeben:

„Nicht in dieser Phase. Wir werden, und das ist mein Ziel, zweite Hälfte nächsten
Jahres ist mein Ziel, das ganze Projekt nach Indien zu vergeben. Wo ich sage, das ist
ein Auftrag, das ist das Problem, make it, kein Thema.“ (ND6)

Grundsätzlich kann daher festgestellt werden, dass das ehrgeizige Ziel, den deutschen Teil der
Einheit möglichst schnell überflüssig zu machen und abzubauen, zum Zeitpunkt der Untersu-
chung beim Großteil der interviewten Brückenköpfe der recht ernüchternden Einsicht Platz ge-
macht hat, dass es dieser deutschen Brückenköpfe zumindest gegenwärtig weiter bedarf und eher
mittelfristig an eine weitreichende Übergabe der Projektverantwortung an den indischen Standort
gedacht werden kann:

„Mittlerweile ist es klar, dass es kurzfristig nicht möglich sein wird, sich überflüssig
zu machen, sondern, dass es eher mittelfristig noch gehen wird. [...] War, wie gesagt,
insgesamt auch von der Organisation her ein bisschen anders geplant, wenn ich das
richtig verstehe.“ (ND7)

Dementsprechend ist die dem indischen Team nur teilweise zugestandene Verantwortung für die
Entwicklung der Applikation innerhalb von Application auch ein sehr umstrittenes und konflikt-
geladenes Thema und führt auf der Seite der indischen Beschäftigten zu Beschwerden und Unmut.

„I mean, still the work is predominantly Germany-centric. [...] Slowly it’s being de-
centralized, but as I said, it’s not really fast enough. But it’s getting decentralized, that
something is moving out of Germany. But people still have a perception that it’s more
Germany-centric.“ (NI7)

So fühlen sich viele Entwickler – wie auch der im Folgenden zitierte – von zentralen Entschei-
dungen über das Produkt ausgeschlossen, da diese innerhalb des Steuerungsgremiums unter den
deutschen Beschäftigten der anderen an der Entwicklung beteiligten Einheiten und den ebenfalls
deutschen Brückenköpfen getroffen würden:
130 Fallstudie NovoProd

„Code is owned by us, you know, because we are developing it. But the whole design
and other processes actually – we don’t have much say in that. Nobody listens to us.
We have to shout. Seeing that, if we are at Germany, we can participate in more and
more meetings and more and more decision meetings. We can influence – and we can
change the product as well. Make other changes. But here, there are not many people
listening to us. [...] Nobody asks!“ (NI9)

Das bedeutet jedoch nicht, dass das indische Entwicklungszentrum gar nicht in diese Entschei-
dungsprozesse involviert ist. Die Verantwortung für die Organisation der Entwicklung – also die
praktische Umsetzung – liegt in der Hand des in Indien situierten Teams von Application, und
entsprechend wird dieses von den Brückenköpfen auch in die Diskussion über die weitere Ent-
wicklung des Produktes einbezogen. Allerdings werden die Beschäftigten im indischen Entwick-
lungszentrum primär in Bezug auf die Realisierbarkeit der im Steuerungsgremium entwickelten
Pläne befragt, wie folgender Projektleiter ausführt:

„Managers from Germany, they participate in a meeting. And then they decide about
something: That this should be there, some high level scoping and all. They will do
some high level scoping for the work. [...] During high level scoping – they do not
finalize in one meeting the high level scoping, but they would – managers would ac-
tually directly talk to developer and they would ask for some effort estimation of the
developer. So as to better match up the scoping. So that it looks realistic.“ (NI22)

Vorschläge von indischer Seite hinsichtlich der Konzeption und Planung werden jedoch in die-
sen Treffen kaum gehört bzw. angenommen.

„Yeah. We have to stick to the decision taken by the steering committee generally. But
if you get a better solution – then you obviously can propose it. But it is generally one
of the things, that are not easy – you are not able to get through.“ (NI23)

Als Hauptgrund dafür, dass dieser Widerspruch zwischen der strategischen Ziel- und der bei
Application gelebten Realstruktur fortbesteht, wird von den deutschen Brückenköpfen weiterhin
vor allem fehlende Erfahrung und fehlendes Wissen der indischen Kollegen in Bezug auf die bei
NovoProd hergestellten Produkte und die Arbeitsabläufe genannt:

„Das ist der Punkt, ich habe einen einzigen, also ich habe zwei Senior Leute in In-
dien. Davon ist der Personalmanager, der logischerweise schon länger dabei ist, der
eine, und dann den zweiten, einen Projektleiter. [...] Aber die Situation ist die, dass
ich zurzeit sonst niemanden da habe, der drüben Senior ist. [...] Das ist ein einfacher
Entwicklungsschritt. Sie müssen die Evolution, die Lernkurve der Leute pushen, pu-
shen, pushen, dass sie hochkommen, und dann können Sie einzelne Tasks wirklich
sauber nach unten geben, würde ich sagen. Das hast du begriffen, das sind Sachen, die
brauchen wir jetzt nicht hier zu machen, auch wenn es technisch kompliziert ist. Es
hängt nicht am Technischen, oder ob es kompliziert ist oder nicht. Das hängt einfach
davon ab - da nehme ich dieselben Maßkriterien wie hier an - wenn derjenige es leisten
kann, dann challenge ich ihn damit und dann gebe ich es ihm.“ (ND6)

Auch ein weiterer Brückenkopf führt auf die Frage, ob er es für möglich halte, auch kurzfristig
mehr Verantwortung an das indische Team zu übergeben, aus:
Global verteilte Entwicklung bei NovoProd 131

„Glaube ich nicht. Also ich habe das Gefühl, dass, zumindest Stand heute, viel zu we-
nig Wissen und Erfahrung in Indien ist, viel zu wenig langfristiges Denken auch. Das
heißt, es ist so, dass ich bei den indischen Kollegen den einen oder anderen sehr, sehr
langfristig denkenden Kollegen sehe. Aber das sind zu wenige, Stand heute. Und die
Frage ist halt: Was ist in fünf Jahren, wenn jetzt von den Leuten, die jetzt in massiven
Zahlen eingestellt worden sind, wenn da jetzt mehrere davon übrig bleiben und nicht
die Firma verlassen haben: wird dann ein starkes Architektur-Gründlichkeitsdenken
dort wirklich Einzug erhalten?“ (ND2)

Der von beiden Interviewpartnern konstatierte Mangel an Wissen und Erfahrung bezieht sich
dabei nicht nur auf die Tatsache, dass das indische Team am Anfang der Entwicklung noch neu war
und sich erst einarbeiten musste. Der zuletzt zitierte Brückenkopf erwähnt vielmehr bereits das
langfristige Denken, das seiner Meinung nach im indischen Teil des Teams fehle. Angesprochen
sind von ihm damit die hohen Fluktuationsraten des indischen Standortes. So war es für Novo-
Prod nicht nur ein Problem, am indischen Standort zu Beginn des Projektes neueingestellte Be-
schäftigte anlernen zu müssen, sondern der stetige Abgang von Beschäftigten macht das Anlernen
neuer Beschäftigter zu einer permanenten Aufgabe und unterminiert damit auch kontinuierlich
den Aufbau von Wissen und Erfahrung. So sind es auch die Teams, die in den letzten Jahren mit
erhöhter Personalfluktuation konfrontiert waren, die nach wie vor unter direkter Kontrolle durch
die deutschen Brückenköpfe stehen, wohingegen jene, deren Besetzung stabiler war, erweiterte
Selbststeuerungsfunktionen aufweisen können8 . Zwar hat NovoProd grundsätzlich mit geringeren
Fluktuationsraten zu kämpfen als z.B. ServiceTec, doch ihre Reduzierung hat auch bei NovoProd
hohes Gewicht. Schließlich hängt die Realisierung der strategischen Zielstruktur ganz wesentlich
vom Aufbau ausreichender Wissens- und Erfahrungsbestände im indischen Entwicklungszentrum
ab:

„So, they [die deutschen Beschäftigten im Hauptquartier NovoProds – PF] become an

expert over a period of time and they become masters in that. And same thing doesn’t
happen in India, because people come, leave, like ... they’ll again come and again leave.
[...] Those guys, Germans, they cannot give very critical work, because they know,
that: ’ok, you don’t have the expertise’. And by the time somebody has this expertise,
he will move out. [...] So that’s why we try to emphasize that: ’ok, you need to spend
some time in NovoProd – three years, four years. And then only you start getting
more important, critical ... That’s why we try to retain people, and put a lot of stress
on that.“ (NI4)

Mit den hohen Fluktuationsraten ist – wie auch bei ServiceTec – eine wichtige Rahmenbedin-
gung der Gestaltung von Arbeitsorganisation im indischen Entwicklungszentrum benannt, und
wir werden später in der Analyse der betrieblichen Kontrollformen noch ausführlich darauf zu-
rückkommen.

Zunächst kann aber in Bezug auf das von NovoProd verfolgte globale Geschäftsmodell festge-
halten werden, dass auch gegenwärtig zwischen der intendierten Zielstruktur und der Realstruktur
ein Widerspruch fortbesteht. Doch obgleich die an den indischen Standort übergebenen Projekt-
managementfunktionen gegenwärtig nicht so weitreichend sind, wie von NovoProd intendiert,
8
Die Gründe dafür, warum bestimmte Teams seit Beginn des Projektes stabiler waren als andere, konnten leider im
Rahmen dieser Studie nicht in Erfahrung gebracht werden.
132 Fallstudie NovoProd

stellt die strategische Zielsetzung, dem indischen Entwicklungszentrum diese langfristig zukom-
men zu lassen, doch ein entscheidendes Merkmal des von NovoProd verfolgten Geschäftssmodells
dar. Es wird sich bei der folgenden Analyse der im indischen Entwicklungszentrum verfolgten
Kontrollstrategie zeigen, dass dieses Geschäftsmodell auch beinhaltet, dass NovoProd wesentlich
stärker auf die Selbststeuerungsfähigkeiten der Beschäftigten setzt und sich dort somit eine deutlich
permissivere Kontrollstrategie identifizieren lässt, als es im Falle von ServiceTec der Fall ist.
Diese strategische Orientierung ist am indischen Standort nicht unproblematisch. Die Situati-
on auf dem indischen Arbeitsmarkt wurde bereits als maßgeblicher Grund identifiziert, warum
NovoProd gegenwärtig seiner Zielstruktur in Bezug auf die Einbindung des indischen Entwick-
lungszentrums hinterherhinkt, da die hohen Fluktuationsraten den Aufbau von Wissens- und Er-
fahrungsbeständen der indischen Beschäftigten untergraben. Scheint das Geschäftsmodell daher
also durch die hohen indischen Personalfluktuationsraten besonders gefährdet zu sein, so wird
sich zeigen lassen, dass es auf der anderen Seite auch Möglichkeiten bietet, diesen in einer ganz
spezifischen Weise gegenüberzutreten und sie organisatorisch zu bearbeiten.
Betriebliche Kontrollstrategien bei NovoProd 133

6.3 Betriebliche Kontrollstrategien bei NovoProd im

Entwicklungszentrum in Bangalore
Im Folgenden soll die im indischen Entwicklungszentrum von NovoProd verfolgte Kontrollstra-
tegie anhand der in Kapitel 4.3 genannten Aktivitätsfelder genauer analysiert werden. Dabei be-
zieht sich die Untersuchung primär auf die am indischen Standort lokalisierte Einheit Application
und ihre deutschen Brückenköpfe. Die beiden anderen an der Entwicklung beteiligten Einheiten
Vision und Plattform weisen keine Offshore-Komponenten auf und werden daher im Folgenden
ausschließlich in ihrer Rolle als Kooperationspartner von Application behandelt.
Wie bei der ersten Fallstudie gliedert sich das Kapitel in die Beschreibung der Aktivitäten des
Managements in den vier Aktivitätsfeldern und eine abschließende, zusammenfassende Darstel-
lung und Bewertung der Kontrollstrategie NovoProds.

6.3.1 Aufgabenorganisation
Aufgabenschwerpunkt und Organisationsstruktur des indischen Entwicklungszentrums

Wie erwähnt, bildet die (von den Brückenköpfen abgesehen) im indischen Entwicklungszentrum
angesiedelte Einheit Application (neben Vison und Plattform) einen von drei Teilen eines Entwick-
lungsnetzwerkes, in dem eine neue betriebswirtschaftliche Standardsoftware entwickelt wird. App-
lication fällt innerhalb dieses Netzwerkes die Erstellung der obersten Ebene des Softwareprodukts
zu.
Das zu entwickelnde Produkt ist eine internetgestützte Applikation, die auf der Basis einer tech-
nischen Plattform läuft. Zur Entwicklung wurde das Produkt in einen Teil, der die Internatapplika-
tion baut (Application), und einen, der für die darunterliegende Plattform zuständig ist (Plattform),
geteilt. Ein dritter Teil (Vision) erarbeitet die Anforderungen an das Produkt und die grafischen
Richtlinien der Realisierung. Der von Application in diesem Netzwerk zu leistende Teil besteht so-
mit in der Entwicklung der Internetapplikation, die im wesentlichen aus einer Benutzeroberfläche
(User Interface – UI) besteht, mit der die Funktionen der darunterliegenden Plattform aufgerufen
werden können. Die Entwicklung der Benutzeroberfläche darf in diesem Zusammenhang aller-
dings nicht in einem grafischen Sinne verstanden werden. Das grafische Design wird von Vision
entworfen und in Form von sogen. „Markups“ als Input an das Entwicklungszentrum in Indien
gegeben. „Markups“ sind nicht funktionsfähige, grafische Vorlagen, meist in Form von Bildern
oder einfachen HTML-Gerüsten, die die wesentlichen Elemente und deren Position vorgeben.
So werden z.B. Vorgaben über die Struktur von Menüs und deren Hierarchien von Vision unter
Usability-Gesichtspunkten entwickelt. Bei Application geht es darauf aufbauend eher darum, die
grafischen Markups in ein funktionsfähiges Programm umzusetzen, im wesentlichen also um die
technische Realisierung der grafischen Elemente und die Konfiguration und Programmierung der
Anbindung der Benutzeroberfläche an die Plattform.

Insgesamt sind bei Application im indischen Entwicklungszentrum ca. 250 Personen beschäftigt.
Die Einheit ist gemäß der unterschiedlichen Funktionsbereiche des Produkts weiter untergliedert.
Das Produkt umfasst 6 größere Funktionsbereiche, um die sich je ein eigenes Team kümmert. Ne-
ben diesen 6 Funktionsbereichen gibt es noch ein paar kleinere unterstützende Bereiche, die sozu-
sagen „quer“ zu den Hauptfunktionsbereichen liegen, d.h. die von diesen Bereichen entwickelten
Komponenten werden von allen Funktionsbereichen gleichermaßen gebraucht und genutzt9 . Je
9
So gibt es z.B. einen Unterbereich, der einen Druckdialog entwickelt, der von allen Funktionsbereichen eingebunden
134 Fallstudie NovoProd

nach Größe der Funktionsbereiche sind diese weiter in verschiedene Gruppen (mit spezifischen
Unterfunktionen) aufgeteilt. Die Größe der Funktionsbereiche streut zwischen 20 und 40 Perso-
nen, wobei die kleineren unterstützenden Bereiche durchaus auch nur aus 2-3 Personen bestehen
können. Die folgenden Funktionen und Rollen sind dabei innerhalb von Application an der Ent-
wicklung beteiligt:
Grundsätzlich wird jeder Funktionsbereich von einem Projektmanager betreut, bei größeren Be-
reichen können dies auch mehrere sein, die dann die Verantwortung für einen kleineren Unterbe-
reich tragen. Zusätzlich gibt es für jeden Bereich einen sogen. Personalmanager. Die Arbeitsteilung
zwischen Projekt- und Personalmanager beinhaltet, dass die Projektmanager für die Entwicklung
der Applikation zuständig sind, also primär einen fachlichen Schwerpunkt haben, wohingegen die
Personalmanager die Personalverantwortung und -entwicklung für ihren Bereich wahrnehmen.
So sind die Personalmanager primär auf den Vorgang der Leistungsbewertung und das Setzen
von Zielvorgaben für die Beschäftigten fokussiert, was uns im nächsten Abschnitt zur Kontroll-
struktur bei NovoProd näher beschäftigen wird.
Die Projektmanager sind hingegen ganz zentral in die Entwicklungsarbeit involviert. So leiten
sie das Offshore-Team fachlich an und sind für die Entwicklungsarbeiten ihres Funktionsbereiches
dem höheren Management gegenüber verantwortlich. Zudem sind sie trotz aller erwähnten Pro-
bleme in Kooperation mit dem jeweiligen Brückenkopf auch in die Diskussionsprozesse des Steue-
rungsgremiums involviert10 . In dieser Funktion diskutiert der Projektmanager zentrale Design-
und Entwicklungsfragen auf der Ebene des Gesamtproduktes und entscheidet mit über die Rich-
tung der weiteren Entwicklung.
Unterhalb der Ebene der Projekt- und Personalmanager gibt es noch zwei Rollen innerhalb der
Projektteams, die des fachlichen Leiters und die des Entwicklers.
Einem fachlichen Leiter obliegt gewöhnlich die fachliche Führung einer kleineren Zahl von Ent-
wicklern, z.B. des Unterbereiches eines größeren Funktionsbereiches der Applikation. Der fachli-
che Leiter hat aber lediglich eine fachliche Vorgesetztenrolle. Es handelt sich bei fachlichen Leitern
um Personen mit ca. 3-5 Jahren Erfahrung innerhalb des Unternehmens, die als fachliche Vorge-
setzte die Entwickler anleiten und bei etwaigen Problemen helfen.
Die Rolle des Entwicklers schließlich stellt die Einstiegsposition bei NovoProd dar. Die meisten
Beschäftigten finden sich daher bei NovoProd auch in dieser Rolle. Die Entwickler tragen primär
die Entwicklungs- und Testarbeiten.

Als Teil eines Entwicklungsnetzwerkes – auch wenn es auf modularen Strukturen aufbaut – sind
die Entwicklungsarbeiten bei Application nicht unabhängig von Vorgängen in anderen Teilen des
Netzwerkes, sondern bedürfen permanenter enger und intensiver Abstimmung. Bei NovoProd
sorgt ein spezielles Steuerungsgremium für diese Koordination (siehe auch Kapitel 6.2).
Das Steuerungsgremium ist damit auch für die innerhalb von Application ablaufenden Arbeitspro-
zesse von großer Bedeutung, da dort die zentralen Planungen und Entscheidungen für die weitere
Entwicklung stattfinden. Die kontinuierlich laufende Entwicklung des Produkts wird dazu in auf-
einanderfolgende Waves eingeteilt. Eine Wave ist ein bestimmter Zeitraum, meist im Umfang von
mehreren Monaten, für den vom Steuerungsgremium bestimmte Ziele definiert werden. In der
Regel handelt es sich dabei um eine feste Zahl von Funktionen der Applikation, die in der dar-
auffolgenden Wave umgesetzt werden sollen. Die Waves unterscheiden sich dabei sowohl in ihrer
Länge als auch in der Art der in ihnen zu erledigenden Aufgaben. So gibt es Waves, die vornehm-
lich der Neuentwicklung einzelner Komponenten dienen, und wiederum andere, bei denen die
werden kann.
10
Mit allen Hindernissen, die im vorigen Kapitel in dieser Hinsicht erwähnt wurden.
Betriebliche Kontrollstrategien bei NovoProd 135

Stabilisierung des erreichten Standes und damit primär Test- und Wartungsaufgaben im Zentrum
stehen.
Den Auftakt jeder Wave bildet eine Diskussion des Steuerungsgremiums über die in der nächs-
ten Wave zu erbringenden Leistungen. Das Steuerungsgremium trifft seine Entscheidungen für
alle Funktionsbereiche der Applikation separat, d.h. jeder Funktionsbereich (auch die unterstüt-
zenden Bereiche) hat für eine Wave gesonderte Aufgaben, die in der folgenden Phase bearbeitet
werden sollen.
An der Diskussion des Steuerungsgremiums ist der jeweilige Brückenkopf (unter jeweils unter-
schiedlich intensiver Mitwirkung des Offshore-Projektmanagers und der fachlichen Leiter, siehe
Kapitel 6.2) mit KollegInnen aus den anderen Bereichen des Entwicklungsnetzwerkes beteiligt. In
dieser Diskussion werden die Ansprüche und Forderungen der drei beteiligten Bereiche aufeinan-
der abgestimmt und auf ihre Realisierbarkeit hin überprüft, wie ein fachlicher Leiter schildert:
„Eh, I mean, we have a development in waves within our product. So currently a new
wave has started. So which means that we will have to plan, what we do ... in the new
wave. A wave could be, say, for two, two and a half months. So now I have to decide
with my Plattform counterparts in Germany and Vision, what are the deliverables,
that we will deliver in this new wave. And then, once we have a common standing
with other stakeholders – then translate this into, eh, how many resources I have in
my team, how are they loaded, what portion of work can be done by X, what is
the portion of work, that can be done by Y? Do I need to decommit certain things,
because I do not have people, you know? So, a new wave of development also means,
that you also have to parallelly maintain or stabilize the things, that you have already
developed so far. So, that means, there has to be a distribution between development
and stabilization. So finally, you have to see, how best you can, you know, map the
required resources and the available resources. And basically feel free to actually say no
to new requirements, just because you don’t have enough people to deliver.“ (NI13)
Sind am Ende dieser Diskussion die Anforderungen für die nächste Entwicklungsphase beschlos-
sen, gelten diese als feste Vorgaben für die einzelnen Funktionsbereiche. Damit sind dann sowohl
die Aufgaben als auch der zeitliche Rahmen der nächsten Wave für die Teams in Indien gesetzt,
wobei der zeitliche Rahmen als externe Anforderung des höheren Managements in die Diskussion
des Steuerungsgremiums eingebracht wird und damit kaum zu beeinflussen ist:
„We [das Steuerungsgremium – PF] decide, that we should have this broader func-
tionality. So, somebody say for example: ’I want activity management, and within
activity management I want these ten functionalities.’ So, this is something, that we
discuss at senior management. Now from our VP or CEO it will come that: ’all those
things, whatever is proposed, we deliver by, say, end of May’. So, this is, when our
take closes. So, the dates are coming from some other side. [...] So, the overall task
definition comes from top – the sub-functionalities.“ (NI6)
Wie bereits erläutert wurde, ist Application in erster Linie mit der technischen Umsetzung der
Benutzeroberfläche der Applikation befasst. Dementsprechend bestehen die vom Steuerungsgre-
mium vorgegebenen Arbeitspakete für die nächste Wave in einer Zahl von zu entwickelnden oder
zu verändernden Teilen der Oberfläche. Wenn das Steuerungsgremium z.B. die Implementierung
einer bestimmten Zahl von Funktionen beschließt, kann bei Application abgesehen werden, wel-
che Teile der Benutzeroberfläche von diesen Änderungen betroffen sein werden. Die Gesamto-
berfläche wird dazu bei Application in sogen. Screens zerlegt. Ein Screen ist ein begrenzter Teil
136 Fallstudie NovoProd

der grafischen Oberfläche, der eine feste, vorher bestimmte Zahl an Funktionalitäten beinhaltet.
Letztendlich besteht die Applikation somit nur aus einer (wachsenden) Zahl von unterschiedlichen
Screens, die zusammen die Gesamtfunktionalität der Applikation zugänglich machen.
Wenn daher die Arbeitsaufgaben für die nächste Wave in den Teams von Application ankom-
men, beinhalten sie eine bestimmte Zahl von zu erstellenden oder zu verändernden Screens, die es
innerhalb des Teams zu verteilen gilt.

Definition und Zuweisung der Arbeitsaufgaben

Im vorigen Abschnitt über das globale Entwicklungsnetzwerk bei NovoProd wurde bereits er-
läutert, dass die von NovoProd strategisch intendierte Form der Zusammenarbeit zwischen den
Standorten bisher, u.a. aufgrund der Personalfluktuation am indischen Standort und das dadurch
in den letzten Jahren aufrecht erhaltene Erfahrungs- und Wissensgefälle zwischen den deutschen
und indischen Teams, nicht realisiert wurde. Auch wurde ausgeführt, dass der Grad, zu dem die
indischen Teams selbst Projektmanagementfunktionen übernehmen, variiert. Wenn daher im Fol-
genden die Form der Aufgabenverteilung innerhalb der indischen Teams beschrieben wird, wird
auf diejenigen Teams Bezug genommen, die das Projektmanagement mittlerweile in Eigenregie
betreiben, da diese Form der Aufgabenorganisation weitestgehend der strategischen Zielstruktur
NovoProds entspricht. Im Anschluß an die Darstellung wird jedoch darauf zurückzukommen sein,
wie sich die Form der Aufgabenverteilung bei den Teams darstellt, die noch stärker aus Deutsch-
land von den jeweiligen Brückenköpfen gesteuert werden.

Bei den Teams, die das Projektmanagement selber von Indien aus erledigen, findet die Verteilung
der vom Steuerungsgremium für die nächste Phase der Entwicklung beschlossenen Arbeitsaufga-
ben zwischen den für den jeweiligen Funktionsbereich Zuständigen statt.

„So, the dates are coming from some other side. Then we say: ’ok, we do these ten
functionalities within our team’. This goes to the project manager. And then they
decide – this is the developers – who will take up what; who will do when, what and
so on. So, the developer is involved right after that. (NI6)

In der Regel macht der jeweilige Projektmanager dazu zunächst einen Vorschlag, wie er gedenkt,
die Aufgaben auf die beteiligten Entwickler aufzuteilen. Dieser Vorschlag wird anschließend im
Team diskutiert und evtl. an die Wünsche und Interessen der Entwickler angepasst.

„No, usually ... in the team meetings, I make a first proposal. And then I pass it on
to the team members, and they can say, if it’s ok with them or if they want a change.
And then we discuss it in a team meeting and make the changes, and then everybody
is told.“ (NI25)

Die Diskussion innerhalb des Teams wird bei NovoProd durchaus ernst genommen. Dabei ist
nicht nur die Verteilung der Arbeitspakete Gegenstand der Diskussion, sondern auch der Zu-
schnitt und die Spezifikationen der Arbeitspakete werden im Team diskutiert, wie sich in folgender
Aussage eines fachlichen Leiters zeigt:

„We encourage people to suggest changes. [...] Because this is research kind of things
still, right? So, there might be ... whatever comes from top, might not be the best. So
you have to also go and take a different approach. So, always try to think differently
as well.“ (NI6)
Betriebliche Kontrollstrategien bei NovoProd 137

Der zitierte Leiter zieht in seiner Aussage einen klaren Zusammenhang zwischen der Art der
(dem indischen Entwicklungszentrum zugewiesenen) Arbeitsaufgaben und der Form der Vertei-
lung innerhalb des Teams. Da es sich um Forschungsarbeit handele, seien die Anregungen und die
individuellen Perspektiven der Entwickler wichtige Ressourcen, die bei der Planung der Entwick-
lung ganz bewußt mit einbezogen werden sollen. Nach Aussagen der Gesprächspartner wird die
Verteilung der Arbeitsaufgaben daher mit den Teammitgliedern diskutiert und nicht einseitig vom
Projektmanager vorgenommen.
Allerdings sollen durch diese offene Art der Aufgabenverteilung nicht nur die Ideen der Ent-
wickler in die Planungen einbezogen werden, es soll diesen auch die Möglichkeit geboten werden,
auf die Art ihrer Arbeitsaufgaben einzuwirken und sich auf bestimmte Aufgaben und damit zu-
sammenhängend auch auf Teile der Applikation, spezielle Funktionen, Technologien o.ä. zu spe-
zialisieren. Ein Personalmanager formuliert diesen Punkt folgendermaßen:

„Weil ich habe natürlich – und auch NovoProd als Firma, denke ich – hat natürlich
auch kein Interesse daran, jetzt jemandem Aufgaben zu geben, die er nicht gerne ma-
chen möchte, also wo er überhaupt gar nicht motiviert ist oder was einfach von der
Persönlichkeit her irgendwie nicht passt. Da sind wir wieder beim Beispiel, was ich
eingangs gebracht habe, dass es einfach Leute gibt, die von der Persönlichkeit eher so
die ... Analytiker, die dann technisch irgendwie an was rumtüfteln und rummachen
und sich da wirklich (in Anführungszeichen) ins Kämmerchen einschließen am liebs-
ten und dann da rauskommen, wenn sie eine Lösung gefunden haben. Und dann gibt’s
halt wirklich diejenigen, die unheimlich Spaß dran haben, was zu präsentieren und
sich auch selbst darzustellen irgendwie. Das hängt einfach davon ab.“ (NI1)

Diese strategische Orientierung wird von einem Entwickler bestätigt:

„So the project manager ensures that: whatever is assigned to you is of your interest. ...
You know? Because I joined in the year 2005 – so I have a certain degree of experience,
that I hold. So, considering the experience that I hold – he knows, that: ’if I assign
this particular person for this particular task, which is not of his interest – it doesn’t
make sense. Because as on this day, after 2 years – he would have some experience.
He would have some expertise in one particular field. So I should ensure that it is, you
know, of his interest, so that he can contribute maximum.’ So it’s that way. My project
manager, he has asked me, saying: ’what do you want to do?’ [...] So those questions
are frequently asked.“ (NI14)

Gerade im Vergleich zu ServiceTec erscheint dieses Vorgehen bemerkenswert. Bei NovoProd

wird nicht versucht, die Beschäftigten möglichst breit zu qualifizieren, um sie flexibel in unter-
schiedlichsten Bereichen einsetzen zu können. Vielmehr sollen sich die Beschäftigten auf einzelne
Bereiche, die sie interessieren, spezialisieren und entsprechend „tiefe“ Erfahrungen in dem Bereich
sammeln:

„Over a period of a few years now we have specialists in most areas. [...] So initially,
they will be given simple tasks. And then you’ll see, how they shape up: how much
interest a person is taking, how much he has learned. Then based on that, he might be
given more complex tasks.“ (NI28)
138 Fallstudie NovoProd

Daher unternimmt man bei NovoProd auch keine Versuche, die Beschäftigten zwischen Teams
oder gar Projekten zu rotieren. Angestrebt ist eher eine Stabilität der Teams, die Spezialisierung
ermöglicht und fördert. In diesem Unterschied spiegelt sich nach Aussage des folgenden Interview-
partners auch ganz grundsätzlich der Unterschied zwischen IT-Dienstleistungsunternehmen und
Produktherstellern:

„At least in NovoProd it’s ... that’s how it works. Because in a product’s team it’s
usually not possible for a person to come for two months’ work and then go on to a
different project. It is true in service industries, eh ... My friends are in service indus-
tries, they keep moving around the projects. They have a domain ... at a large, that, ok,
I am working on insurance domain. But then they keep switching between projects,
ok? But for us, it’s like, we have a domain, we have a product, which is going to come
out in the next two years. And hence, everybody spends time on that product for two
years and so on.“ (NI20)

Die Verteilung der Arbeitsaufgaben wird bei NovoProd unter erhöhten Mitsprachemöglichkei-
ten der Entwickler in einem Teammeeting durchgeführt. Dabei werden die Beschäftigten auf der
einen Seite ermuntert, sich in bestimmten Bereichen zu spezialisieren, und andererseits wird bei
der Verteilung der Arbeitsaufgaben auf diese Spezialisierungen Rücksicht genommen, wie der im
Folgenden zitierte Gesprächspartner noch einmal zusammenfassend bestätigt:

„What we do at the beginning of any development cycle is: usually we list down all
the tasks, that need to be done, and then we identify people, who are good at certain
things. So somebody is good at ... working on some areas. Then we distribute this
task – and this is usually done in a team meeting. So, everybody, all the developers,
everybody is involved in that process.“ (NI28)

Diese Form der Aufgabenverteilung mit ihren erhöhten Mitsprachemöglichkeiten und der ge-
wünschten fachlichen Spezialisierung zielt darauf ab, die Entwickler zunehmend zu befähigen,
die ihnen zugewiesenen Arbeitsaufgaben selbstständig zu erledigen und den Bedarf an detaillierter
Spezifizierung der Arbeitsschritte und konkreter inhaltlicher Anleitung zu reduzieren. Diese stra-
tegische Orientierung NovoProds zeigt sich auch ganz deutlich, wenn die in diesem Verfahren den
Entwicklern zugewiesenen Arbeitsaufgaben näher betrachtet werden.

Charakter der Arbeitsaufgaben

Wie erwähnt, bestehen Arbeitspakete bei Application im wesentlichen aus sogen. Screens, also Aus-
schnitten der Oberfläche, die einen bestimmten Funktionsumfang beinhalten. Für die Entwick-
lung der Benutzeroberflächen können die Entwickler bei NovoProd auf firmeninterne Tools zu-
rückgreifen, die ihnen einen Teil der manuellen Programmierabeit abnehmen, indem sie es erleich-
tern, die einzelnen Elemente – teilweise per drag & drop – zu erstellen und zu konfigurieren:

„Es gibt da mehrere Tools, die wir haben, also mehrere Programmierumgebungen ei-
gentlich im Endeffekt, [...] wo eigentlich dann, sagen wir mal, weitestgehend bestimm-
te UI-Elemente konfiguriert werden, bestimmte Screens, sagen wir mal, bestimmte
Standard-Screens. [...] Und für solche Standardaufgaben oder Standardprozesse gibt es
natürlich auch, sagen wir mal so, Standardelemente, ne? Und wie so ein Screen aussieht
– das kann man konfigurieren mit diesem Tool.“ (NI1)
Betriebliche Kontrollstrategien bei NovoProd 139

Auf den ersten Blick scheinen die dem indischen Entwicklungszentrum zugewiesenen Tätigkei-
ten – z.B. im Vergleich zum Plattform-Teil – damit weniger komplex und anspruchsvoll zu sein.
Doch darf man sich die Arbeit, die im indischen Entwicklungszentrum geleistet wird, keinesfalls
als ein unkompliziertes „Zusammenklicken“ der von der Plattform bereitgestellten Funktionen
vorstellen.
Denn erstens sind diese Tools in ihrem Funktionsumfang nicht umfassend. Sie erleichtern zwar
bestimmte Standardoperationen, im Großteil der Fälle und für spezielle Funktionen ist es aber
nach wie vor nötig, Programmierungen per Hand vorzunehmen. Daher ist ein tiefes technisches
Verständnis der genutzten Technologien und Programmiersprachen für die Entwickler von ent-
scheidender Bedeutung, zumal die zu entwickelnde Applikation technisch sehr anspruchsvoll ist:
„Damit [mit firmeninternen Tools – PF] lässt sich aber ein UI nicht entwickeln in
dem Sinne, dass ich dann nachher alle Funktionen, die ich abbilden möchte, abbilden
kann, und vor allem mit allen Spezialitäten, weil es gibt ja nun wirklich sehr kom-
plizierte Elemente und sehr komplizierte Funktionalität und da muss ich schon pro-
grammieren, und da gibt es dann auch andere Entwicklungsumgebungen, da haben
wir das Eclipse von Java, das ist dann Java-Entwicklung, das ist wirklich hohe Java-
Entwicklung, das heißt, die Leute müssen wirklich eine gute Ausbildung haben in
Java.“ (NI1)
Zweitens ist betriebswirtschaftliches Wissen über die abzubildenden Geschäftsprozesse und de-
ren technischer Realisierung erforderlich. Zwar beinhaltet die von Plattform entwickelte Platt-
form die wesentlichen funktionalen Grundlagen der Applikation, und dementsprechend sind die
Beschäftigten in diesem Teil des Entwicklungsnetzwerkes auch primär mit der „Logik“ der von
der Applikation abzubildenden Geschäftsprozesse und den betriebswirtschaftlichen Grundlagen
befasst. Dies bedeutet jedoch nicht, dass sich die Beschäftigten bei Application ausschließlich auf
technische Fragen der Realisierung konzentrieren könnten, wie der bereits zitierte Development
Manager erläutert:
„Und dann Logik – das ist nämlich, was man auch nicht vergessen darf, das ist auch
Businesslogik, also man kann es nicht ganz trennen, man kann nicht einfach sagen, ok,
die Leute hier konfigurieren nur UIs, das ist eine relativ stupide Arbeit, das könnte
man vielleicht meinen oder diesen Eindruck gewinnen, das ist aber nicht der Fall.“
(NI1)
Der Grund dafür ist der Umstand, dass die Plattform zwar grundsätzlich alle nötigen Funktio-
nen der Applikation enthält, jedoch nicht immer in der nötigen Form. So können z.B. Elemente
unterschiedlicher Funktionen in einer spezifischen Kombination erforderlich sein, die in dieser
Form jedoch nicht von der Plattform bereitgestellt werden. Für solche Fälle wird innerhalb des
Steuerungsgremiums häufig beschlossen, diese Funktionen nicht dadurch bereitzustellen, dass eine
Erweiterung der Plattform entwickelt wird. Statt dessen werden sie von Application realisiert, in-
dem ein separates Objekt zwischen Plattform und UI entwickelt wird, das die nötigen Informatio-
nen aus der Plattform extrahiert und in die vom UI benötigte Form umwandelt und anschließend
an das UI weitergibt. Diese Entwicklung setzt dementsprechend auch Kenntnissse der zugrundlie-
genden Geschäftsprozesse im indischen Teil des Entwicklungsnetzwerkes voraus:
„Also es ist teilweise so, dass man einfach diese darunter liegenden Businesssobjekte,
die den Hauptteil Businesslogik beinhalten, dass man die nicht so ohne weiteres ein-
fach konsumieren kann für ein UI. Und dann muss ich so eine Art Zwischenobjekt
140 Fallstudie NovoProd

bauen, also so eine Art Schicht dazwischen, die mir hilft, meine Prozesse über das UI
besser darzustellen letzten Endes, und das ist auch noch einmal ein Teil von Business-
logik, Ablauflogik, Prozesslogik.“ (NI1)

Drittens sei an dieser Stelle schließlich daran erinnert, dass es sich auch beim indischen Entwick-
lunsgzentrum um einen Teil der Forschungs- und Entwicklungsabteilung handelt. Das entwickelte
Produkt ist ein gänzlich neues im Portfolio von NovoProd. Daher kann im indischen Entwick-
lungszentrum nur begrenzt auf bereits gemachte Erfahrungen zurückgegriffen werden, was die
Entwickler permanent zu Improvisationen zwingt:

„So, we are learning, in fact, my project is considered a research project, so it’s very
new and we encounter problems every single day, every single hour and I think, most
of my tasks have been evolving around problem investigation, rather than constructive
development. So, whenever we encounter a problem, I think, I always learned better,
how to resolve problems being at NovoProd, doing this work.“ (NI21)

Diese Tendenz wird bei Application noch dadurch verstärkt, dass sich bei „verteilter Entwick-
lung“ nicht nur der eigene Teil der Applikation, sondern alle Komponenten in paralleler Weiter-
entwicklung befinden. Trotz der formell klar scheinenden Aufteilung der Entwicklung zwischen
Vision, Plattform und Application bestehen erhebliche Interdependenzen zwischen den Teilen. So
beeinflußen Veränderungen an den grafischen Vorgaben oder den von Vision erarbeiteten Anfor-
derungen des Produktes ganz erheblich die weitere Entwicklung sowohl bei Plattform als auch bei
Application. Ebenso verändern Änderungen an der Architektur der Plattform auch die Art und
Weise, in der diese Funktionen von Application in die Benutzeroberfläche eingebunden werden
können. Durch diese dynamischen Interdependenzen zwischen den Modulen erwachsen also auch
ganz eigene Unwägbarkeiten, die von den Entwicklern bei Application Flexibilität erfordern, mit
der auf externe Störungen der Entwicklungsarbeiten reagiert werden muss:

"There is a lot of the dependencies. And if something goes wrong, your project plan
goes for toss. And it happens very frequently now. So you have to be always involved
in something else, some thing or the other."(NI6)

Die Entwicklung der Oberfläche des Produktes im indischen Teil des Entwicklungsnetzwerkes
ist demnach ein sehr komplexer Vorgang, der sowohl hohe fachliche und qualifikatorische Ansprü-
che an die Entwickler stellt, als auch diverse Unwägbarkeiten des Entwicklungsprozesses aufgrund
der hohen Interdependenzen innerhalb des Entwicklungsnetzwerkes birgt. Ein Personalmanager
charakterisiert die vom indischen Entwicklungsteam wahrgenommenen Aufgaben dementspre-
chend wie folgt:

„Also es ist schon, also man kann es nicht so einfach trennen und sagen, ok, die [deut-
schen Beschäftigten in Vision und Plattform – PF] machen die ganze Businesslogik und
all den fancy stuff und das Interessante – und in Indien, ja, da machen sie sowieso nur
UIs und eigentlich ist das Risiko, da irgendwas falsch zu machen, relativ gering.“ (NI1)

Die spezifische strategische Orientierung NovoProds zeigt sich nun darin, dass auch im indi-
schen Entwicklungszentrum nicht versucht wird, die Komplexität der Arbeitsaufgaben durch ei-
ne erhöhte Arbeitsteilung und Fragmentierung in separate und kurztaktige Arbeitspakete für die
Betriebliche Kontrollstrategien bei NovoProd 141

Entwickler zu reduzieren. Vielmehr werden integrierte Arbeitsaufgaben verteilt. In Kapitel 5.3.1

(S. 68) wurde der Software-Lifecycle erwähnt, der aus den aufeinanderfolgenden Phasen Anforde-
rungsanalyse, Design, technische Umsetzung, Test, und Wartung besteht, und mit dem gewöhnlich
die Phasen der Softwareentwicklung beschrieben werden. War es für ServiceTec typisch, dass die-
se Phasen sowohl regional als auch innerhalb der Teams arbeitsteilig behandelt wurden, und die
Entwickler auch einzelne Phasen des Lifecycles unabhängig von den anderen bearbeiten, so wird
bei NovoProd sichergestellt, dass jeder Entwickler die ihm zugewiesenen Screens durch möglichst
alle Phasen begleitet. Aufgrund der Arbeitsteilung im Entwicklungsnetzwerk sind die Entwickler
bei Application zwar von der grundsätzlichen Anforderungsanalyse, die von Vision erledigt wird,
weitgehend ausgeschlossen, jedoch sollen die restlichen Phasen von jedem Entwickler bearbeitet
werden, wie ein fachlicher Leiter ausführt:

„Ok, and each screen would entail, you know, different tasks: The design, the specifi-
cation, the design and the implementation and the testing. So for each screen all these
tasks would be performed by the developer.“ (NI13)

Die Übertragung eines Screens in die Verantwortung eines Entwicklers bedeutet damit, dass
er für den vollen Prozess der Entwicklung dieses Screens verantwortlich ist. Eine Arbeitsteilung
zwischen den einzelnen Arbeitsschritten findet bei NovoProd nicht statt. Statt dessen sollen die
Entwickler den von ihnen geschriebenen Teil der Applikation als ihren Teil begreifen, den sie
durch den vollen Entwicklungszyklus begleiten und mit dem sie sich auch identifizieren sollen.
Ein Projektmanager formuliert diesen Umstand folgendermaßen:

„I have – I make it a point that I don’t change the code that they have written. [...]
Even if I have to change, I would ... I mean, I’d not change any most of the times. But if
they’re on vacations suddenly, I do not have an option other than to fix something. But
otherwise it’s a feedback that I give – and then I give it in some written format, some
mail or something. And then they change it. [...] So – because codes are something
you’re emotionally att... – if you are a developer, then you get emotionally attached to
the code you have written.“ (NI7)

Und so finden sich auch Statements von Entwicklern, dass sie sich persönlich für „ihre“ Screens
verantwortlich fühlen und sich mit diesen so stark identifizieren, dass sie sogar Überstunden in
Kauf nehmen, um gute Ergebnisse zu erzielen. Ein Entwickler erklärt:

„Some people, they do appreciate working late, but if I don’t, I don’t and nobody
questions me about it, so it works fine for me to leave at five. And, eh, nobody has
the right to ask me to stay late. Eh, in an emergency, yes, when things are really bad
or if something is going wrong, I myself would love to stay back, because, what I am
working on is after all my baby and I would want to see it through.“ (NI21)

Es wird also bei NovoProd nicht versucht, die grundsätzlich als sehr komplex charakterisierten
Arbeitsaufgaben durch eine starke Fragmentierung und Vorspezifikation ihrer Komplexität zu be-
rauben. Vielmehr wird die Komplexität der Entwicklung an die Entwickler weitergegeben, indem
sie neben dem Entwicklungs- auch den Planungsprozess für die ihnen zugewiesenen Screens selber
ausführen und verantworten und somit die genannten Unwägbarkeiten der Entwicklungsprozesse
142 Fallstudie NovoProd

selbstorganisiert bearbeiten sollen. Für die Entwickler bedeutet dies auch erhöhte Kooperations-
anforderungen, da im Laufe der Entwicklung enge Abstimmungen mit anderen Teilen des Ent-
wicklungsnetzwerkes nötig sind, die bei NovoProd auf Entwickler-Ebene stattfinden sollen. Dies
wird im folgenden Abschnitt zu den Kooperationsbeziehungen noch genauer behandelt.
Da Arbeitsaufgaben bei NovoProd grundsätzlich alle Phasen der Entwicklung für einen Screen
beinhalten, bildet ein Screen auch die Untergrenze des Umfangs der verteilten Arbeitsaufgaben:

„One particular screen would be the responsibility of one developer only. So, multiple
people will not work on that screen.“ (NI13)

Es ist jedoch eher selten, dass ein Entwickler lediglich einen Screen während einer Wave zu
bearbeiten hat. Zumeist handelt es sich um mehrere.

„Yes, eh, a typical project plan would include, like I said – we decide on x-number of
screens. These x-screens would be probably ... equally divided among the four devel-
opers, that are there.“ (NI13)

Wie viele Screens ein Entwickler jeweils zur Bearbeitung bekommt, richtet sich dabei sowohl
nach dem Komplexitätsgrad des Screens als auch nach der Erfahrung und der Leistungsfähigkeit
des Entwicklers.

„It depends really on the complexities of the tasks. There are some tasks – there is
this one task, which is very complex, and one person can do it. Or again there are ten
simple tasks, which also can be done by one person.“ (NI28)

Neue Mitglieder des Teams werden in Bezug auf die Aufgabenverteilung etwas anders behandelt
als erfahrenere KollegInnen, wie folgender fachlicher Leiter erläutert:

„Over a period of a few years now we have specialists in most areas. And then we have
these new colleagues, who are joining and they are getting trained. So initially they
will be given simple tasks. Excuse me. And then you’ll see, how they shape up: how
much interest a person is taking, how much he has learned. Then based on that, he
might be given more complex tasks.“ (NI28)

Daher werden bei NovoProd meist zahlenmäßig weniger oder weniger komplexe Screens an die
neuen Entwickler im Team vergeben, während die erfahrenen Entwickler mehr oder komplexere
Screens erhalten.

Die hohe Komplexität der Arbeitsaufgaben erschwert auch die zeitliche Bestimmung der zuge-
wiesenen Arbeitsaufgaben. Die Schätzung der benötigten Zeiträume zur Entwicklung eines Screens
stellt bei NovoProd für die Projektmanager keine triviale Angelegenheit dar. Da es sich um ein neu-
es Produkt und ein neues Setup handelt, gab es am Anfang der Entwicklung keine Erfahrungen,
auf die gebaut werden konnte und auch firmenweit für andere Bereiche entwickelte Richtlinien zur
Terminierung von Arbeitsaufgaben waren nicht anwendbar. Statt dessen wurde und wird im in-
dischen Entwicklungszentrum parallel an eigenen Richtlinien gearbeitet, die sich jedoch nur nach
und nach mit den gemachten Erfahrungen entwickeln:
Betriebliche Kontrollstrategien bei NovoProd 143

„That’s mainly from our experience. In most of NovoProd naturally there are guide-
lines for deciding that. But because this is a new product and we are working on new
technology, we are really deviating from all those guidelines. So, while we are making
this product, we are also ... defining these guidelines, that will be for this kind of task.
From experience we now know, that: if we give this kind of task – with this kind of
experience, it can be done in this much time.“ (NI28)

Dementsprechend verlassen sich die Projektmanager auch in erster Linie auf ihre eigene Erfah-
rung:

„Because I know, the particular task, how much time it takes, because I did the reading,
[...] I do normally myself on project, so I take myself – I do development and do
implement. I know, how much time it takes for me.“ (NI12)

Zum Zeitpunkt der vorliegenden Untersuchung wurden die Screens bei der Vergabe grob in drei
Komplexitätsstufen eingeteilt, für die sich jeweils ein grober Zeitrahmen als realisitisch erwiesen
hat:

„And we categorize, ok, this is a simple screen, this is a complex screen and this is
the medium complex screen, ok? So, based on the fields and complexity, because I
know the set of ... how it exactly will go actually. Simple screens is this one, so, the
moment, they look at backend and frontend, I can say, that it’s a simple screen and is it
a complex or medium. So it just varies, simple, medium, complex, ok? And for simple
two days, medium three days and complex ten days. Again the time basis, we know,
already we know, ok, if we, because it’s a research project, initially we don’t know,
how many time this takes. But as an experience, I know, how much time this kind
of thing will take actually. That’s an assumption actually. So, we go by assumption
initially and then after first phase we know, that what exactly it takes the time. Now,
we had estimate real, ok, simple, medium, complex, divide that actually and give the
screens.“ (NI12)

Doch auch wenn mit der Zeit die Erfahrung innerhalb von Application wächst, wie der zitierte
Gesprächspartner ausführt, und die Zeitschätzungen damit zunehmend sicherer werden, bleibt
eine gewisse Unsicherheit in der zeitlichen Planung stets bestehen.
So findet erstens durch die hohen Interdependenzen zwischen den Teilen des Entwicklungsnetz-
werkes eine gegenseitige Beeinflussung der Entwicklung statt. Daher können die zeitlichen Pla-
nungen bei Application auch durch Probleme in anderen Teams beeinflußt und verzögert werden.
Gibt es z.B. ein Problem in der Plattform für eine bestimmte Funktionalität, so ist der Entwickler
der Oberfläche für diese Funktionalität auch nicht in der Lage, seinen Screen zu beenden. Dies
führt einerseits permanent zu internen Konflikten über etwaige Verschiebungen der Deadlines,
und andererseits auch ganz unmittelbar zu Unregelmäßigkeiten in der individuellen Arbeitszeit,
wie folgender Entwickler berichtet:

„We are in the topmost layer of the application – there are two more layers. So, usually,
when this happens ... you are supposed to wait for the others to finish their work. And
you are also supposed to wait for other errors to be solved before you can do ... But
your deadlines don’t move. [...] Then you raise an issue with them, and then you wait
for them to be solved ... and this dependency might ... create some problem. So, if I
144 Fallstudie NovoProd

wait for half a day, because I was waiting for someone else’s issue ... and then towards
evening this issue is solved. Then I have a chance to do it today or do it tomorrow.
And that depends on, how close to the deadline we are at. And, if it can wait until to-
morrow, then yeah, it’s fine – but otherwise your day extends. So, there are situations,
wherein we have a lot of problems with other stacks, and then ... our working hours
go beyond eight hours.“ (NI11)

Durch die hohen Abhängigkeiten innerhalb des Netzwerkes ist die zeitliche Planung der Ar-
beitsaufgaben also immer ein wenig in Bewegung und feste Planungen und Termine können durch
auftretende Probleme in anderen Bereichen plötzlich wieder in Frage gestellt werden. Dies führt
gerade gegen Ende der Waves häufig zu Problemen, denn auch wenn die Arbeitspakete nicht im-
mer definitiv terminiert werden können, bilden die Waves doch klare und vor allem zeitlich fixe
Termine für die Entwicklung.
Zweitens hat NovoProd es in den Teams auch mit unterschiedlich erfahrenen Entwicklern zu
tun. Aufgrund ihrer gewollten Spezialisierung bestehen demnach große Unterschiede zwischen
den Zeiten, die ein erfahrener und ein unerfahrener Entwickler für die Entwicklung eines Screens
benötigt. Dieser Umstand wird bei der zeitlichen Bemessung der Arbeitsaufgaben zwar berück-
sichtigt, kann jedoch nicht genau bemessen werden:

„I may code faster because of my experience, but the fresher takes twice the time, trice
the time. So, according to this, I distribute the task.“ (NI12)

Ein fachlicher Leiter wird noch deutlicher:

„So, for an experienced person, I would say: ’this task can be done in one day’; for the
less experienced person I would say: ’this task can be done in three days’. If he does it
in three days, he is meeting expectations. No one will expect him to do it in one day,
because we know, he is new.“ (NI28)

Drittens ist schließlich auch die Komplexität eines Screens im voraus nicht immer exakt ein-
zuschätzen. Die Screens werden nicht detailliert vorspezifiziert, sondern das genaue Design eines
Screens bildet einen wichtigen Teil der Aufgabe eines Entwicklers. Dementsprechend zeigen sich
manche Probleme auch erst während der Bearbeitung und verändern damit den zu kalkulierenden
Arbeitsaufwand teilweise erheblich, wenn sich vermeintlich leichte Screens aufgrund unvorherge-
sehener technischer Komplikationen in komplexe verwandeln, wie ein fachlicher Leiter aus eigener
Erfahrung schildert:

„When we started off, it was expected, that the Plattform is sufficient to realize the
screens, but on the way we found, it’s not. Because the capabilities or the technical
restrictions are so many, that you cannot actually achieve everything. What happens,
if a screen has to correspond to multiple functions? So, this is correctly not possible.
So, you need a controller in between, which will then talk to multiple functions, but
for the screen, you are only talking to one controller, so. These kinds of technical
limitations were bypassed or worked around. [...] Earlier it was thought, that it would
be enough to develop a screen, it would take two days. But only now we are able, you
know, fine-tune. Now we can say with a degree of certainty, that this is the time, that
a person would need to develop that screen.“ (NI13)
Betriebliche Kontrollstrategien bei NovoProd 145

Der folgende Projektmanager findet daher klare Worte für die Charakterisierung der Zeitschät-
zungen bei NovoProd. Angesichts der Komplexität der Tätigkeiten, den möglichen externen Schocks
und technischen Störungen, müssten umfangreiche Puffer-Zeiten eingeplant werden, welche die
Zeitschätzungen weiter erschwerten:

„It cannot be very hard – as somebody can go on leave or vacation, something hap-
pens. So everything has to be taken into consideration, buffer times need to be taken
in consideration. We need, say, 20% percentage – actually, I’ll not say 20 percentage,
I’ll say 25 or 30 percentage, because at times, the technology itself is not supporting,
at times something is down. Network is down or some other cross feature is not sup-
porting. So we have to take into the consideration all that. And actually, it’s not ... it
cannot be calculated with numbers. It’s just by experience.“ (NI22)

Dementsprechend grob ist auch die zeitliche Planung bei Application, wie folgender Gesprächs-
partner aus seinem Team berichtet:

„So then, as a project manager, I would have to plan for how much time he would
require to specify a screen. Then how much time will be required to design it, on paper
and in the system, and then how much time will be required to actually implement it.
[...] Ok, so my project plan would be, supposed, it’s a three months wave – it would
be, that, ok, first month, I only do specification and design. And I say, I implement
only in the next two months. I wouldn’t, I mean – I wouldn’t put in my project plan,
saying that this [betont] screen will be done by this [betont] day, but it would be more
or less that, by the first week of May, I would have the specification and, eh, design
ready for all my screens.“ (NI13)

Aufgrund der beschriebenen Probleme, die Zeiträume zur Bearbeitung der Screens genau zu be-
stimmen und aufgrund des komplexen Charakters der Entwicklung, finden sich bei NovoProd
keine eng getakteten Arbeitsaufgaben, wie es für ServiceTec typisch ist. Je nach den Anforderun-
gen einer Wave variieren die Zeiträume, die den Entwicklern zur Bearbeitung ihrer Aufgaben
zugestanden werden, zwischen mehreren Tagen und mehreren Monaten.
Die kürzeren Arbeitsaufgaben finden sich dabei meist in Waves, in denen stark auf die Stabilisie-
rung des erreichten Standes der Entwicklung Wert gelegt wird und es daher um die Korrektur von
Programmierfehlern geht. Dabei korrigieren alle Entwickler die Fehler in „ihren“ Screens, d.h. de-
nen, die sie auch selber entwickelt haben. Auch in solchen Phasen bleiben die Screens also bei den
für sie verantwortlichen Entwicklern.
In Waves hingegen, in denen neue Funktionalitäten implementiert werden, wird meist für die
gesamte Wave geplant, d.h. die Gesamtzahl der nötigen Screens wird am Anfang der Entwicklungs-
phase zwischen den beteiligten Entwicklern aufgeteilt. Je nach Zeitschätzung für die Screens und
der Erfahrung der Entwickler erhalten diese unterschiedlich viele Screens für die folgende Wave zu-
gewiesen. Je nach Komplexität werden dabei für die Screens mehrere Tagen oder mehrere Wochen
angesetzt.
Dabei fällt jedoch die Länge der Arbeitsaufgaben nicht mit der Länge der Kontrollzyklen zusam-
men, wie im nächsten Abschnitt noch genauer diskutiert wird. Dennoch stützen, neben den bereits
beschriebenen Formen der Aufgabenverteilung, auch die langen Bearbeitungszeiten die These, dass
NovoProd versucht, eher die Selbstorganisationsfähigkeit der Entwickler bei der Aufgabenbearbei-
tung zu nutzen, als sich auf enge Vorgaben und klar spezifizierte Arbeitspakete zu verlassen. Das
zeigt sich auch in der Aussage eines Managers:
146 Fallstudie NovoProd

„We never – I mean, we do not assign tasks, which are at least an hour kind of work.
Like – for today, this is the task; tomorrow, this is the task, you know. This is the
target for the developing phase, right? So, the target is, that in next three months, this
is, what we need to deliver. This is the task assigned to the group. Now the person is
to decide now – he has to ensure, that this is delivered. We check weekly, where they
stand. We have our weekly milestones. So you know, the progress is good enough.
Otherwise somebody comes after three months and says, ’I could not deliver’ – then
you cannot do anything, right? So, we check weekly, but the task always... We – I
mean, we do not go into this minor – minor details, like, half an hour, two hours or
four hours. This is taken by the individual. His ownership – the topic, he has or she
has to ensure, that it’s delivered and so on.“ (NI6)

Fasst man das bisher über die strategische Ausrichtung NovoProds im Bereich der Aufgabenor-
ganisation Ausgeführte zusammen, so lässt sich feststellen, dass NovoProd einen eher permissiven
Zugriff auf die Aufgabenorganisation verfolgt.
Zwar sind die Entwickler im indischen Entwicklungszentrum durch die Arbeitsteilung im Ent-
wicklungsnetzwerk und die zentrale Funktion des Steuerungsgremiums von strategischen Ent-
scheidungen über die weitere Entwicklung weitgehend abgeschnitten, doch auch die Realisierung
der Applikation birgt, wie gezeigt werden konnte, sehr komlexe Aufgaben, die im indischen Ent-
wicklungszentrum bearbeitet werden müssen.
NovoProd setzt dazu strategisch auf die Selbstorganisationsfähigkeiten der Beschäftigten. Indi-
katoren für dieses Vorgehen sind die langen Zeiträume, die den Beschäftigten zur Bearbeitung von
komplexen (grundsätzlich durch die Integration von Spezifikation, Design und Implementierung
geprägten) Arbeitsaufgaben zugestanden werden. Hinzu kommt die Praxis, die Arbeitspakete nicht
zentral zuzuweisen, sondern im Rahmen einer Teamdiskussion zu verteilen, dabei gezielt die in-
dividuellen Interessen der Entwickler zu berücksichtigen und sie zu vertiefter Spezialisierung zu
animieren. Wie ein roter Faden zieht sich die Wertschätzung von individueller Erfahrung, sowohl
hinsichtlich der genutzten Technologien und des Produkts, als auch hinsichtlich des organisatori-
schen Umfeldes durch die Interviews.

Probleme der Aufgabenorganisation

Allerdings müssen an dieser Stelle auch die Probleme dieses Vorgehens bei NovoProd benannt
werden. Denn die Implementierung der beschriebenen permissiven Strategien im Bereich der Auf-
gabenorganisation ist keinesfalls voraussetzungslos. Wie gezeigt wurde, verlässt sich NovoProd in
wichtigen Punkten auf die individuelle Erfahrung ihrer Beschäftigten. Allerdings ist die individu-
elle Erfahrung der EntwicklerInnen im indischen Entwicklungszentrum eine kritische Ressource.
Denn die für Bangalore typischen hohen Fluktuationsraten betreffen auch NovoProd. Für die letz-
ten Jahre hat NovoProd zwar mit Raten von knapp 9% einen für die indische IT-Industrie stark
unterdurchschnittlichen Wert vorzuweisen, aber wie bei ServiceTec, fällt die Fluktuation auf den
Einstiegsebenen wesentlich höher aus als der Durchschnittswert, der über alle Hierarchiestufen
gebildet wird, suggeriert. Zusätzlich konzentriert sich die Fluktuation in einigen Teams von No-
voProd, so dass es hinsichtlich der gewünschten Stabilität der Teams große Unterschiede innerhalb
von Application gibt. Im Rahmen dieser Studie wurden Beschäftigte in Teams interviewt, die in
den letzten Jahren mit stark erhöhten Fluktuationsraten zu kämpfen hatten und die daher zum
Zeitpunkt der Untersuchung zu großen Teilen aus frisch eingestellten Personen mit begrenztem
Erfahrungsschatz bestanden. Zudem fanden sich jedoch auch Teams, deren Mitglieder teilweise
Betriebliche Kontrollstrategien bei NovoProd 147

seit Beginn der Entwicklung mit dabei sind und daher schon auf mehrjährige Erfahrungen inner-
halb von NovoProd zurückgreifen können11 . Da die individuelle Erfahrung der Entwickler bei
NovoProd eine große Rolle bei der Aufgabenorganisation spielt, kam es nach Aussagen der Ma-
nager gerade in den Teams, die mit erhöhter Fluktuation zu kämpfen hatten, zu Problemen mit
der geschilderten Praxis der Aufgabenorganisation, die sich in großen Verzögerungen des Ablau-
fes niederschlugen. Als Resultat wurden diese Projekte wieder unter engere Führung durch die
Brückenköpfe gestellt, die Projektmanagementfunktionen (wieder) auf sich konzentrierten:

„There is some success, then there are some failures, it depends upon who is leading
the team here and how is his experience, how confident he is. Some projects, it was
working here like with me, they are not performing good – it [das Projektmanagement
– PF] went back to Germany.“ (NI12)

So unterscheidet sich die Praxis der Aufgabenorganisation in den Teams, die mit wenig indivi-
dueller Erfahrung umgehen müssen, auch von der Praxis in den bisher geschilderten, stabileren
Teams. Ein Entwickler formuliert diesen Umstand, auf den Unterschied zwischen der deutschen
Firmenzentrale und dem indischen Entwicklungszentrum angesprochen, folgendermaßen:

„So, they [die deutschen Beschäftigten im Hauptquartier NovoProds – PF] become an

expert over a period of time and they become masters in that. And same thing doesn’t
happen in India, because people come, leave, like ... they’ll again come and again leave.
This is, like, both ways. Those guys, Germans, they cannot give very critical work,
because they know, that: ’ok, you don’t have the expertise’.“ (NI4)

So finden sich im indischen Entwicklungszentrum neben den Teams, in denen die Entwickler
die bisher beschriebenen großen Spielräume bei der Erledigung ihrer Arbeitsaufgaben genießen,
auch Teams, in denen die Arbeitsaufgaben nach wie vor von den deutschen Brückenköpfen defi-
niert und zugewiesen werden und in denen den Beschäftigten auf der indischen Seite wesentlich
weniger Möglichkeiten offen stehen, auf ihre Arbeitsaufgaben Einfluß zu nehmen, wie ein Mana-
ger für seinen Bereich feststellt:

„The fundamentals for us – it is: you have to follow the process12 . That’s what is being
told. And here, the questioning of the process comes into picture. ’Is this a value-add.
Can I do something better than this? Why can’t I do it this way? Should I...?’ And they
expect, like: a command – execution.“ (NI24)

Der für dieses Team zuständige Brückenkopf ergänzt:

„Ja, tatsächlich. Der Takt ist kürzer in Indien. [...] Das liegt an der Projektleitung und
am Management. Wir machen in Indien eine Planung, dass wir, oder der zuständige
Projektleiter schickt Emails und sagt: ’Aufgaben für diese Woche sind’.“ (ND4)

Dieses andere Vorgehen hat Konsequenzen für die Beschäftigten in den indischen Teams. Die
Verteilung der Arbeitsaufgaben von Deutschland aus berücksichtigt in der Regel weniger indivi-
duelle Interessen und nutzt eher den Vorteil, dass die neuen Beschäftigten sich noch nicht inhaltlich
spezialisiert haben und dementsprechend noch flexibel einzusetzen sind:
11
Im Abschnitt zu den Arbeitsmarktbeziehungen ( Kapitel 6.3.4) wird noch näher darauf einzugehen sein, warum
NovoProd mit niedrigeren Fluktuationsraten konfrontiert ist und wie sie mit diesen umgehen.
12
Mit Prozessen sind in diesem Zusammenhang keine formalen Prozessbeschreibungen gemeint, sondern vielmehr
direkte Anweisungen für das weitere Vorgehen, die von den Brückenköpfen ergehen.
148 Fallstudie NovoProd

„But with these freshers, the advantage I see is: you can move them around. With
experience, there comes certain rigidity and ... Like, you don’t want to do certain task
or you do want to. But with a fresher, you have this flexibility.“ (NI7)

Grundsätzlich ändert sich die Form der Arbeitsaufgaben zwar nicht, denn auch in diesen Teams
handelt es sich um zeitlich recht umfangreiche Aufgaben, die in der Entwicklung unterschiedlicher
Mengen von Screens bestehen. Jedoch sind die deutschen Brückenköpfe sowie die Projektmanager
und fachlichen Leiter im indischen Entwicklungszentrum in diesen Teams wesentlich stärker in die
Bearbeitung der Arbeitsaufgaben involviert, indem sie die Screens für die Entwickler vorspezifizie-
ren und bestimmte Aufgaben übernehmen, die sonst von den Entwicklern selbst wahrgenommen
werden sollen, wie z.B. das detaillierte technische Design eines Screens zu erstellen. Daher entste-
hen bei diesen Teams auch wesentlich höhere Anforderungen an die Kontrollstruktur, genauer:
an die Art und Weise, in der die Entwickler in diesen Teams angeleitet und bei der Bearbeitung
überwacht werden.

„Of course, you have to give a lot of direction as well and, eh ... When there are multi-
ple things to be done, then you have to prioritise the work for them, otherwise ... they
don’t focus out. Compared to people, who are experienced – you can’t leave them on
their own.“ (NI11)

Der unterschiedliche Umgang mit den Teams wird in Bezug auf die Kontrollstruktur noch aus-
führlich Thema sein. An dieser Stelle soll daher nur festgestellt werden, dass der erhöhte Aufwand
in Bezug auf Anleitung und detaillierte Spezifizierung der Arbeitsaufgaben diese vereinfacht und
damit auch die Attraktivität der Arbeit für die Beschäftigten in den indischen Teams reduziert.
Viele Entwickler aus Teams, die das Projektmanagement mittlerweile in Eigenregie betreiben und
die (aufgrund der Stabilität der Teams) auch viel Einfluß auf ihre Arbeitsaufgaben haben, betonen
in den Interviews den herausfordernden und interessanten Charakter ihrer Arbeitsaufgaben. Fol-
gender Entwickler wurde zu den Unterschieden zwischen den Arbeitsaufgaben bei NovoProd und
seiner vorherigen Firma, eines indischen IT-Denstleisters, befragt:

„Actually, I get to do something new – and this is the major change. New ... and I have
my ideas as well, which I can implement in some way or the other. Even if it’s small
modules, not the whole concept of that particular product or module. But my part, I
can do it my way. [...] Here I can play with..., just I am creating my development. I
can change the design of my code sometimes and then I have done some performance
tuning as well. So I found, where are the performance leakages and then again I change
my code. So some new things, I am able to do again. Then integration is also, it’s ve-
ry exciting. When things integrate – and especially, when two such things integrate,
which are in geographically different locations, at different locations. So, at that time
it’s very interesting because communication has to be very clear, regarding the interfa-
ces and all, right from the starting. But later on, what happens is: a little bit here and
there it happens, and then, you have to access during the time of integration – so that
things join very easily. And then, when people start using it, we get the issues, those
issues are good learning, integration issues.“ (NI9)

Und auch der folgende Gesprächspartner hebt vor allem die große Verantwortung für seine
Arbeitsaufgaben bei NovoProd hervor:
Betriebliche Kontrollstrategien bei NovoProd 149

„We have the ownership of our work. In other companies we don’t have ownership
for the work we are doing. It’s basically, somebody is forcing. So here, whatever we do
comes basically from the senior level management in India assigned. And also, it’s not
like they are the owner of those tasks. They assign the tasks – now, we are ... and we
are responsible. So the feeling of ownership is there – I mean, that’s why I like it. The
work culture is good.“ (NI22)

Bei den Entwicklern in den Teams, die noch – oder teilweise auch wieder – „an der kurzen
Leine“ gehalten werden, finden sich hingegen häufig Aussagen wie die des folgenden Entwicklers,
die eher den stark vereinfachten Charakter der in diesen Teams verteilten Arbeitsaufgaben vor
Augen führen:

„So, at times people feel demotivated, ok? The reason being, as I told, lot of the things
are modelling, ok? So, things are, ... things are easy in a sense, at times. So, at times it
gets really frustrating for the colleagues as well.“ (NI21)

Diese Unterschiede in der Attraktivität der Arbeitsaufgaben werden später noch im Zusammen-
hang mit den Gründen diskutiert, aus denen Beschäftigte zu NovoProd wechseln und die Firma
wieder verlassen (Kapitel 6.3.4). Doch zunächst wird die von NovoProd im indischen Entwick-
lungszentrum etablierte Kontrollstruktur betrachtet.

6.3.2 Kontrollstruktur
Die Analyse der Aufgabenorganisation bei NovoProd hat gezeigt, dass der Charakter der von App-
lication bearbeiteten Arbeitsaufgaben deren detaillierte Planung und zeitliche Terminierung durch
den Projektmanager stark erschwert. Zudem versucht NovoProd strategisch, möglichst integrierte
Arbeitspakete an die Entwickler zu geben, die dementsprechend auch zeitlich umfangreich bemes-
sen sind, und von den Entwicklern – je nach individueller Erfahrung – möglichst eigenverantwort-
lich bearbeitet werden sollen.

Anleitung und Anweisung

Diese Art der Aufgabenorganisation geht bei Application einher mit einer Form der Kontrollstruk-
tur, die strategisch auf detailierte und formelle Vorgaben der Arbeitsschritte verzichtet und statt
dessen darauf setzt, dass die Entwickler möglichst selbständig versuchen sollen, die Bearbeitung
ihrer Arbeitsaufgaben zu planen und etwaige Probleme zu lösen, wenngleich diese Zielstruktur
auch hier nicht in allen Teams gleichermaßen umgesetzt werden konnte.
Diese strategische Ausrichtung NovoProds hat firmengeschichtlich Kontinuität. So sei Novo-
Prod nach Aussagen von Vertretern des Qualitätsmanagements nie eine sonderlich „process-driven
company“ (NI 18,19) gewesen. Vielmehr hätte man sich seit jeher stark auf die Beschäftigten und
deren Expertise verlassen:

„Wir sind zwar ein großes Unternehmen, aber Projektsteuerung gab es hier ja auch
nicht. Irgendwelche Leute waren für irgendwas verantwortlich, wer viele kannte, war
gut vernetzt und hat viel erfahren. Und so Entwicklungspläne wurden in der Kaffee-
Ecke besprochen.[...] Dann gab es halt Code-Ownership, bestimmte Leute haben halt
Code-Strecken geowned und nur die durften auch darin arbeiten und so. Und so war
das praktisch aufgeteilt.“ (ND1)
150 Fallstudie NovoProd

In der Folge hätten einzelne Teams bei NovoProd häufig auch ganz eigene „implicit processes“
(NI19) entwickelt, mit denen sie ihre Arbeit strukturierten und durchführten:

„Small groups have evolved their own processes for their own groups.“ (NI18)

Doch im Zuge der Internationalisierung der Produktentwicklung haben Standardisierungs- und

Formalisierungstendenzen auch bei NovoProd zunehmend Einzug gehalten, wie der folgende Ge-
sprächspartner schildert:

„Aber in dem Moment, wo man halt global entwickeln will, funktioniert das halt
nicht mehr. Und da haben wir auch erst dann gelernt, okay, vielleicht ist es doch ganz
sinnvoll, wir haben eine vernünftige Spezifikation für unsere Software. [...] Das man
auch mal eine gewisse Disziplin hat, wie man so was dann steuert, das ist schon wich-
tig.“ (ND1)

Und so werden auch bei NovoProd in den letzten Jahren zunehmend standardisierte Prozessbe-
schreibungen eingeführt, die den Ablauf der Entwicklung strukturieren sollen:

„We can not afford that you will just do your own thing. We could say this 20 years
back maybe, but we can’t say this anymore. It is so complex. Everything that we do
has to be a well defined process, there has to be - how do you govern the process? These
things must become normal, as the usual way of working in NovoProd.“ (NI19)

Der Grund dafür liegt nach Angaben einer Qualitätsbeauftragten vor allem darin, dass informel-
le Steuerungsformen bei einer großen Zahl von beteiligten Personen, die zudem an unterschiedli-
chen Standorten sitzen, nicht mehr funktionieren. Vielmehr sei ein gewisses Maß an Standardisie-
rung nötig, um die Abstimmung der beteiligten Personen zu erleichtern:

„It’s about – you have a small team, you have six people, let’s say, in a company – you
are all sitting here. It doesn’t take me long to say: ’Hey, just tell me what it is and be
done with it’. Yeah, it’s a good process – it works! I could get up, scream at you – I
ask you, what is this. It’s fine – it works well, it works very effectively. – Scale it to 60
people. You can still shout – if 60 people shout, you can imagine, what chaos it is. 600,
6000, across locations? So you have to put some basic standardization in place, right?
It may be – it can be a format, it can be a tool update ... something. You have to bring
in those workflows that are required.“ (NI19)

In Folge der zunehmenden Standardisierung und Formalisierung sei nach Angaben eines Quali-
tätsbeauftragten bei NovoProd daher auch das Interesse an formalen Prozessmodellen stark gestie-
gen. Dabei spielt die externe Zertifizierung jedoch keine besonders große Rolle (siehe auch Kapitel
2.2). Offiziell zertifiziert ist NovoProd lediglich nach ISO 9001. NovoProd strebt es nach Aussagen
der interviewten Qualitätsbeauftragten auch gar nicht an, sich für andere Modelle extern zertifi-
zieren zu lassen. Vielmehr wird versucht, aus den verschiedenen Modellen Elemente zu finden, die
für die eigene Organisation nützlich sein können (NI 19). Diese gesammelten Prozessbeschreibun-
gen werden innerhalb von NovoProd unter einem eigenen Namen, der "NPL"(NovoProd Process
Library13 ) zusammengefasst und firmenweit von einer eigenen Abteilung verwaltet. Die NPL ist
13
Name selbstverständlich verändert.
Betriebliche Kontrollstrategien bei NovoProd 151

damit vor allem eine Sammlung von Best-Practices und Versatzstücken aus anderen Prozessmodel-
len, wie CMMI oder auch Six Sigma, die je nach Eignung integriert werden.
Die in der NPL zusammengefassten Prozesse beinhalten Vorgaben darüber, wie bestimmte Ent-
wicklungsschritte ausgeführt werden sollen, d.h. welche Schritte in welcher Reihenfolge mit wel-
chen beteiligten Rollen durchlaufen werden müssen. Gleichzeitig werden in diesen Prozessmodel-
len jedoch auch Metriken gebildet, mit denen die Ausführung der Prozesse gemessen werden kann.

„Beides eigentlich, also es sind sowohl Prozesse, die dann eben einen Entwicklungs-
prozess oder andere Prozesse eben durchziehen und wer, wann, wie informiert wer-
den muss, wo und wie Spezifikationen geschrieben werden, wie Dinge geratet werden,
welche Dinge eben für ’change request’-Prozesse gemacht werden etc. Aber umgekehrt
eben auch formale Dinge, die einfach als Festgrößen abgenommen werden und über
die Zeit aufgetragen werden und eben geschaut wird, wie man sich dabei entwickelt.“
(ND7)

Grundsätzlich befindet sich NovoProd jedoch noch in einem Experimentierstadium, was die
zu implementierenden Prozesse angeht. Der NPL befand sich zum Untersuchungszeitpunkt noch
im Aufbau, und viele Prozesse wurden noch in Pilotprojekten getestet und auf ihre Eignung hin
untersucht. So berichtet die Qualitätsbeauftragte, dass z.B. die Nutzung von Six Sigma in den Pro-
jekten zum Untersuchungszeitpunkt getestet wurde, aber noch nicht verpflichtend implementiert
sei. Vielmehr müssten sich Projekte, die Six Sigma gern probeweise implementieren möchten, ge-
zielt darum bewerben und etwaige Mehrkosten würden auch auf die Projekte gebucht (NI19).

Die Internationalisierung der Produktentwicklung wird also auch bei NovoProd von einer zu-
nehmenden Standardisierung und Formalisierung begleitet. Doch diese Standardisierung und For-
malisierung folgt bei NovoProd im Vergleich zu ServiceTec einer ganz anderen strategischen Ziel-
setzung. Im Gegensatz zu ServiceTec sollen die Prozessbeschreibungen bei NovoProd nicht pri-
mär die Abhängigkeit von einzelnen Personen reduzieren, indem die Arbeitsverrichtung der Be-
schäftigten zentral und formal angeleitet und vorgeschrieben wird und Handlungsspielräume der
Beschäftigten bei der Bearbeitung eingeschränkt werden. Vielmehr ist den meisten Gesprächspart-
nern auch im höheren Management von NovoProd eine deutliche Skepsis gegenüber einer Anlei-
tung und Anweisung der Beschäftigten mittels standardisierter Prozessvorgaben anzumerken. Der
folgende Brückenkopf fasst die vielfach geäußerten Zweifel zusammen:

„Auf der einen Seite stellt man fest, dass es sinnvoll ist, solche Dinge [formale Prozesse
– PF] zu etablieren, gerade eben in einer größer werdenden Organisation, gerade in
einer verteilt arbeitenden Organisation. Auf der anderen Seite erkennt man eben auch
sehr stark immer wieder, wie die Dinge an dem eigentlichen Kern dessen, was man da-
mit erreichen wollte, vorbeigehen, oder Dinge sich ausnutzen lassen, oder eben formal
erfüllt werden, aber inhaltlich nicht erfüllt werden. Und es ist sehr schwierig, teilweise
dann, sowohl auf der deutschen Seite als auf der indischen Seite eben, mit den Leuten
zu reden und ihnen klar zu machen, dass an der Stelle das so nicht gelebt werden darf,
weil ansonsten das Ding insgesamt nicht funktionieren wird. Und es eben unheimlich
schwierig ist und teilweise, meines Erachtens, konzeptionell einfach nicht möglich ist,
das eigentliche Ziel der realen Welt sinnvoll zurück abzubilden auf den KPI [Key Per-
formance Indicator – PF] oder den Prozess selber. Also wenn ich die entsprechenden
Verbesserungen in dem Prozess oder in den Messgrößen kennen würde, mit denen
152 Fallstudie NovoProd

man das besser erfassen würde, dann würde ich das vorschlagen. Das ist nicht das Pro-
blem. Das würde mir auch kein Mensch übelnehmen, im Gegenteil, wahrscheinlich
würden mir die Füße dafür geküsst werden. Aber es ist halt sehr schwierig, sinnvollere
Dinge zu finden. Und umgekehrt, je mehr man eben aufsattelt, desto größer wird das
Bürokratiemonster, was dadurch natürlich entsteht. Insofern ist da natürlich auch eine
gewisse Grenze gegeben, was man eben formalisieren kann.“ (ND7)

Die Skepsis dieses Brückenkopfes bezieht sich damit vor allem darauf, dass ein formalisiertes
Prozessmodell oder daraus abgeleitete Kennziffern immer Abstraktionen vom konkreten Projekt-
verlauf sind und die Kenngrößen und Vorgaben der Modelle nicht notwendigerweise mit den rea-
len Notwendigkeiten des Projektes übereinstimmen müssen. Ganz deutlich zeigt sich in diesem
Statement auch die Befürchtung, zuviel formelle Vorgaben, zuviel bürokratische Steuerung – das
„Bürokratiemonster“ – könne die Entwicklung eher gefährden und hemmen als fördern. Dabei
spielt auch wieder die Art der bei NovoProd geleisteten Arbeit eine zentrale Rolle, wie folgende
Aussage der Qualitätsbeauftragten zeigt:

„You know, like I told you, this is a research group and we are proving, we are trying
to prove some very new technologies to the world! So, there is a lot of this R&D
mind-set, that is there. That, you know, we’ll be creative, I’ll keep trying, third time
something works. So, in that situation, you cannot put a high overhead of process,
because the challenge there is to make it work first, yeah? I don’t want to be a burden.
So we do try to put some bare minimum checks and balances, that is required. But not
– if you ask me, are you 100% compliant? No, we are not!“ (NI19 – Hervorhebung des
Autors)

Die Tatsache, dass im Entwicklungszentrum in Indien ein neues Produkt entwickelt wird, dass
es sich damit also bei der geleisteten Arbeit auch um Forschungsarbeit handelt, hat also nach Aus-
sage der Qualitätsbeauftragten auch Konsequenzen für die Gestaltung der Kontrollstruktur. Wie
bereits im Abschnitt zur Aufgabenorganisation ausführlich ausgeführt, birgt die Entwicklung des
neuen Produkts viele Unwägbarkeiten für das Projektmanagement bei NovoProd. So entstehen
viele Probleme im Arbeitsablauf oft erst während der Entwicklung und durch die Interaktion
zwischen den verschiedenen Teilen des Entwicklungsnetzwerkes. Die zeitliche Planung und die
klare Definition der Arbeitsaufgaben wird dadurch deutlich erschwert und nötigt Entwickler wie
Projektmanager stetig zu Improvisation und eigenverantwortlicher Problemlösung. Auf diese An-
forderungen können standardisierte Prozessmodelle auch keine eindeutige Antwort geben. Daher
sind die Prozesse bei NovoProd auch lediglich als ein grober Rahmen konzipiert, der von einzel-
nen Abteilungen und Teams flexibel an lokale Gegebenheiten angepasst und dadurch firmenweit
unterschiedlich „gelebt“ wird. So hat auch das indische Entwicklungszentrum Prozesse der NPL
für seine eigenen Ziele etwas modifiziert:

„The approach we took here, was slightly different. There is a standard, that was there
across NovoProd. There is something called NPL. We didn’t take it as it is – we tailored
it slightly within our group. Because it works differently in our development and then
we said: ’Ok, we see that some teams say: ’This is not, what fits me, may be I use this
tool, blablabla.’ We have those little tailorings added now.“ (NI19)

Zentrales Merkmal der Prozessorientierung bei NovoProd ist dabei, dass die implementierten
Prozessmodelle ganz explizit nicht dazu führen sollen, dass die Entwickler von den Prozessbe-
Betriebliche Kontrollstrategien bei NovoProd 153

schreibungen gegängelt werden, indem diese Prozesse bis ins Detail die Arbeitsverrichtung vor-
schreiben und anweisen:

„I would say, you have to take a part in between. There are still work frameworks, that
you can put in place – and some place, where you have to let it to the creativity. [...]
So, I would say, there should be – any organization, if they think correctly, should be
able to put some broad framework, in which people can operate. But within that –
yes, you should give flexibility, you should not bring in the bureaucracy angle. Keep
that to the minimum!“ (NI19)

Die Kreativität der Entwickler und deren eigenverantwortliches, problemlösendes Handeln ge-
nießt als wichtige Ressource bei NovoProd trotz des geschilderten Standardisierungsdruckes nach
wie vor große Wertschätzung und wird für den Erfolg der Entwicklung auch als kritisch angese-
hen. Obwohl in den letzten Jahren also unbestreitbar der Umfang der formalen Vorschriften und
Regelungen bei NovoProd zugenommen hat, ist der Arbeitsprozeß gegenwärtig noch wesentlich
vom „alten“, in der Firmentradition stehenden Vorgehen dominiert, wie die beiden Qualitätsbe-
auftragten gleichermaßen konstatieren:

„In NovoProd it still works a lot through personal contacts and networks. [...] I told
you in the beginning, I love NovoProd as a company, I really like it. This is the culture
of NovoProd. But of course as a professional, as a quality professional - it is...“
[„...a nightmare“, ergänzt der Interviewer und alle lachen] (NI18)

Auch die folgende Aussage der anderen Qualitätsbeauftragten stützt diese These:

„NovoProd is a more people-driven company, I would say. They still like to catch the
experts and get things threshed out. We still work in that mode, too. Of course, there
are guidelines, but I wouldn’t say, we are 100 percent – everything is available. It’s a
whole load of information – but here, it’s a highly people oriented company, very
networking kind of. So, you know me as an expert, so we just take the code to him,
and he’ll just go over it. We still follow that – though we are such a huge company,
those practices still exist. Initially, when I came, I was equally surprised that – ’I go to
him every time’. [...] But now I am beginning to realize, that the people networking
is of more highly importance than anything else actually here.“(NI19)

Die beiden zitierten Aussagen reissen schon Zusammenhänge zwischen dieser Form der Kon-
trollstruktur und anderen Aktivitätsfeldern (wie Arbeitsmarktbeziehungen) an, die später disku-
tiert werden. An dieser Stelle ist jedoch zunächst festzuhalten, dass formelle und detaillierte For-
men der Anweisung und Anleitung des Arbeitsprozesses mittels standardisierter Prozessmodelle,
wie sie bei ServiceTec prägend waren, bei NovoProd für die Charakterisierung der Kontrollstruk-
tur nicht zentral sind. Vielmehr sollen die Entwickler ihren Arbeitsprozess möglichst selbständig
organisieren und planen. Dazu werden ihnen, wie der Abschnitt über Aufgabenorganisation ge-
zeigt hat, möglichst integrierte und langfristige Arbeitsaufgaben zugeteilt und diese nicht kleintei-
lig heruntergebrochen.

Zentrale Elemente der Anweisung und Anleitung im Arbeitsprozess sind bei NovoProd auf der
einen Seite die Vorgaben und Standards, die sich aus der Gesamtarchitektur und dem Design des zu
154 Fallstudie NovoProd

entwickelnden Produkts ergeben, und auf der anderen Seite die jeweiligen fachlichen Vorgesetzten,
die den Arbeitsprozess begleiten und Hilfestellung bei Fragen und Problemen leisten.
Da es sich bei dem zu entwickelnden Produkt um eine Applikation handelt, die bestehende
Funktionen einer zugrundeliegenden Plattform einbindet, sind die Funktionen der Plattform für
die Entwicklung der UI’s insofern externe Vorgaben, als sie nur in einer bestimmten Weise ein-
gebunden werden können. Hinzu kommen vom Solution Management definierte Standards hin-
sichtlich der grafischen Umsetzung der UI’s. Diese beinhalten Vorgaben zu Design und Usability
der Applikation.
Diese Standards werden in umfangreichen sogen. „Cookbooks“ und „Style-Guides“ zusammen-
gestellt und den Entwicklern zur Verfügung gestellt. Sie gelten weltweit für alle an der Entwick-
lung beteiligten Teams und sind für die Entwickler bei Application daher nicht zu verändern. Sie
fungieren damit als die Arbeit der Entwickler anleitende „Frameworks“ der Entwicklung. Aller-
dings enthalten sie in erster Linie Vorgaben über das Ergebnis der Entwicklung, also darüber, wie
die zu entwickelnden Screens am Ende aussehen und mit der Plattform kommunizieren sollen. Für
dieses Ergebnis werden auch Checklisten mitgeliefert, anhand derer die Entwickler den von ihnen
erstellten Code auf seine Standardkonformität hin überprüfen können.

„So, you always have a guideline and you have a checklist. So, when you start your
work, you are sure, that you have read the guideline and you follow it. And if you fail
there, then in, the checklist will anyway point it out – and then you have to rework.
So, there is a guideline, there is a checklist and in between you do your work.“ (NI11)

Nach Angaben der Gesprächspartner leiden diese Standards mittlerweile an einem übermäßi-
gem Umfang, was ihre Wirksamkeit im Arbeitsprozess eher schwächt als stärkt. Ein Entwickler
beschreibt die Situation wie folgt:

„Also es gibt zum Beispiel einen Standard, das ist der sogenannte Style-Guide, der be-
schreibt, der beschäftigt sich damit, wie ein UI aussehen muss. Das ist ein Dokument,
das hat, ich weiß es nicht, ungefähr 1000 Seiten. Und von diesen Dingern gibt’s ein
paar, die für uns mehr oder weniger relevant sind. Also es ist sehr, sehr schwierig für
die Entwickler, alle Standards zu kennen und zu befolgen, weil es einfach so unglaub-
lich viele sind.“ (ND4)

Die bei NovoProd definierten Standards in Hinblick auf die technischen Spezifikationen der
Applikation haben nach Angaben des Entwicklers mit der Zeit ein Ausmaß erreicht, das es für
die einzelnen Entwickler unmöglich macht, sie alle in ihrer Arbeit zu vergegenwärtigen und zu
befolgen. Da es sich allerdings in dieser Form lediglich um ex-post Standards handelt, ist dies für
die Entwickler nicht besonders problematisch, da die Standards auch nur bei Bedarf befolgt werden
können. D.h. wenn ein Entwickler mit einem bestimmten Problem konfrontiert ist, kann er sich
die zu diesem Problem gehörigen Vorgaben punktuell aneignen.

Diese Form der Produktstandardisierung betrifft daher auch nur indirekt den Arbeitsprozess,
sondern eher die Arbeitsgrundlage, auf der die Entwickler operieren. Konkrete Anweisungen hi-
nischtlich des Vorgehens bei der Entwicklung lassen sich aus diesen Standards nicht gewinnen:

„We know the guidelines. So there is no point in instructing something, and ... There
is no instruction based manual that we have been given [schmunzelnd]. It’s, like, ’you
know what to do, so – go for it. Let’s see!“ (NI14)
Betriebliche Kontrollstrategien bei NovoProd 155

Die Relevanz der Guidelines und Standards für die Arbeitsverrichtung der Entwickler wird zu-
dem noch dadurch geschwächt, dass diese selber im Laufe der Entwicklung erst entwickelt wurden
und sich ebenso in ständiger Weiterentwicklung und Veränderung befinden, wie die Applikati-
on, auf die sie bezogen sind. Demnach sind die Standards auch noch nicht für alle Gegebenheiten
ausreichend spezifiziert, wie ein Projektmanager erwähnt:

„I mean, right now, there are lots of problems in compliance. But then, we have some
things planned to see, that we can correct all these things. So, we have some code
inspections and things like that, which are planned. Where there are experts, who will
go through all these things and try to find out. But it’s not done on a full flatted scale
now, because again, as I said: these [guidelines – PF] are evolving.“ (NI11)

Demnach sind die technischen Spezifikationen der Applikationen nicht nur von einem mittler-
weile unhandlichen Umfang, sondern zudem (da es sich um ein neues Produkt handelt) von vor-
läufigem Charakter. So müssen Entwickler bei ihrer Arbeit permanent improvisieren. Wenn z.B.
bestimmte Funktionen der Plattform verändert werden, ändert sich auch die Schnittstelle zum UI,
so dass die bestehenden Standards nicht mehr zutreffend sind. Für die Entwickler bedeutet dies,
dass an diesem Punkt die Anbindung des UI’s an die darunterliegende Plattform hergestellt werden
muss, auch ohne dass auf fertige Vorgaben rekurriert werden kann.

„And process is an evolving thing. And everyday it’s happening – every time it’s chan-
ging.“ (NI24)

Diese Situation gepaart mit einem stetigen Zeitdruck bei nahenden Deadlines führt zu einem
recht pragmatischen Umgang der Entwickler mit den vorfindlichen Guidelines, wie er sich in der
Aussage eines Entwicklers ausdrückt:

„There is naming convention! But in the, like – if you’re doing development, fast track
development. And if you’re lost in the development – then at times it’s not easy to just
look back with all the commitment. NovoProd has – in fact, Java has its own naming
convention guidelines; NovoProd has the naming convention guidelines for example.
But most of the times, I mean – when you’re starting fresh, probably it’s easy. But
when you’re doing some fast track development, that you have to finish something
today or tomorrow, then you tend to ignore those things and you tend to concentrate
on getting things done.“ (NI7)

Die Standards und Vorgaben hinsichtlich der Architektur und des Designs der Applikation ge-
ben den Entwicklern also nur einen groben Orientierungsrahmen bei der Bearbeitung ihrer Ar-
beitsaufgaben, indem Eckpunkte des zu entwickelnden Screens definiert werden, und dies auch nur
eingeschränkt, da sich die Vorgaben teilweise im Laufe der Entwicklung verändern und weiterent-
wickeln.

Der Prozess der Anweisung und Anleitung der Entwickler im Arbeitsprozess ist bei NovoProd
daher noch stark mit persönlichen Formen der Kontrolle verbunden. Diese funktioniert primär
über die jeweiligen Vorgesetzten, die als fachliche Autorität bei Fragen und Problemen mit den
zugewiesenen Arbeitsaufgaben helfen, Lösungen zu finden. In den meisten Fällen handelt es sich
dabei um den für das jeweilige Team zuständigen Projektmanager, in größeren Teams kann auch
ein fachlicher Leiter diese Funktion für eine kleine Gruppe (3-4 Entwickler) innerhalb des Teams
übernehmen, wie ein fachlicher Leiter ausführt:
156 Fallstudie NovoProd

„Usually, if a colleague has a problem, then he just talks to one of us, who is more
experienced in this product. We will solve it. And then, if I now still don’t know, I
look at the document. So, that’s mainly, what a project manager, an architect does. He
is supposed to be the expert in that topic. So, you are really the first point of contact,
if somebody has a technical problem or a functional problem.“ (NI28)

Das strategische Ziel dabei ist, dass die Entwickler ihre Arbeit möglichst selber organisieren und
planen, der fachliche Leiter sich also zurückhält und nur bei Problemen oder sonstigen Fragen der
Entwickler eingreift und Hilfestellung bietet. Dies beruht auch auf dem Charakter der zu bearbei-
tenden Aufgaben, die ein Komplexitätsniveau aufweisen, das es schwierig macht, klare Vorgaben
für deren Bearbeitung zu geben:

„Dazu ist dann die Tätigkeit doch zu anspruchsvoll hier, als dass man wirklich so ge-
naue Anweisungen geben könnte.“ (ND7)

Jedoch lassen sich auch hier innerhalb von Application – wie schon für den Bereich der Aufga-
benorganisation konstatiert – z.T. erhebliche Unterschiede feststellen, inwiefern es den Projekt-
managern gelingt, diese Zielstruktur zu realisieren.
Denn die Fähigkeit, die Arbeitsaufgaben selbständig und weitestgehend in Eigenverantwortung
zu bearbeiten, hängt gerade angesichts der nur in beschränktem Maße anwendbaren formalen Vor-
gaben ganz wesentlich von der Erfahrung der Entwickler mit dem zu entwickelnden Produkt und
dem organisatorischen Umfeld bei NovoProd ab.

„And then for me, when I joined the project, I didn’t know, what to do, how to do. So,
the leads helped me out, they told me, this is, how it is to be done, For my first screen,
my senior wrote a lot of code for me, he showed me, that, ok, this is the way, it’s to
be done. So, for the first screen I faced a lot of problems, because it was new for me
and I didn’t understand any, I didn’t have any clue as to what was happening, but once
I did one controller, slowly and slowly I got hold of it and he used to frame me very
well, that, ok, this is how it happens, this is how you should work. [...] So, sooner
or later I could get a reasonable grasp of it and today I can independently propose the
design at least and that’s something good. [lacht] I don’t need so much of dependence
on others, so I can propose it.“ (NI10)

So lässt sich für die untersuchten Teams konstatieren, dass die Beschäftigten in den Teams mit
höherer Personalfluktuation und einer entsprechend größeren Zahl an noch relativ unerfahrenen
KollegInnen, nicht nur kleinteiligere Arbeitsaufgaben erhalten, sondern dass diese Arbeitsaufgaben
von den Leads und Project Managern auch wesentlich stärker vorspezifiziert werden müssen. So
berichtet ein Gesprächspartner aus seinem Team, dass die Mitglieder des Teams „ständig in [sein
– PF] Büro gerannt“ kämen, und ihn fragen würden, wie sie ein Problem lösen sollten, weil sie
nicht wüssten, wie vorzugehen sei (NI 26). Der Manager müsse in diesem Falle sehr viel Hilfestel-
lung geben und Zusammenhänge der Applikation erklären, bis die Entwickler selber eine Lösung
entwickeln könnten. In den Teams allerdings, die über die letzten Jahre relativ stabil waren und
deren Beschäftigte daher viel Erfahrung im Umgang mit der Applikation besitzen, reduziert sich
die Funktion der Anleitung und Anweisung meist darauf, bei gravierenden Problemen einzugrei-
fen und Hilfestellung zu geben. Der Großteil der Entwickler in diesen Teams plant und organisiert
seine Arbeitsaufgaben mittlerweile weitgehend selbst.
Betriebliche Kontrollstrategien bei NovoProd 157

Überwachung der Arbeitsabläufe

Auch wenn NovoProd – sofern das Team erfahren genug ist – versucht, auf detailliertes Anleiten
und Anweisen der Entwickler zu verzichten und statt dessen die Bearbeitung der Arbeitsaufgaben
in die Verantwortung der Beschäftigten legt, bedeutet dies nicht, dass der Fortschritt der Arbeit
nicht gewissenhaft überwacht würde. Denn obwohl die Einschätzung des zeitlichen Umfangs der
Arbeitsaufgaben – wie im Kapitel über die Aufgabenorganisation gezeigt – nicht einfach ist, gibt
es gegenüber dem Steuerungsgremium doch ganz klare zeitliche Deadlinies für die Gesamtent-
wicklung, die einzuhalten sind. So werden vom Steuerungsgremium für alle an der Entwicklung
beteiligten Teams die aufeinanderfolgenden Waves der Entwicklung definiert. Der Endpunkt einer
Wave stellen daher auch für Application eine klare Vorgabe dar, die nur sehr schwer aufzuschie-
ben ist. Sind daher die Arbeitsaufgaben der Entwickler innerhalb jeder Wave zeitlich auch recht
grob spezifiziert, so bilden die Enden der Waves feste Termine, zu denen die jeweilis geplanten
Arbeiten erledigt sein müssen. Eine gewissenhafte Überwachung der Arbeitsabläufe ist daher für
die Projektmanager wichtig, um den Stand der Entwicklung jederzeit einschätzen zu können:

„Exactly. It’s up to them. It’s their task, they have to deliver either way. But we do
track it very closely, because you cannot accept any delays. Because this is revenue for
the company.“ (NI6)

Für die Überwachung der Arbeitsabläufe sind die fachlichen Vorgesetzten in den Teams ver-
antwortlich, also je nach Teamgröße die Projektmanager oder fachlichen Leiter. Formell wird der
Fortschritt der Arbeiten in allen Teams einmal pro Woche in einem Teamtreffen, dem sogen. „Sta-
tusmeeting“ von den Projektmanagern erhoben. Die Ergebnisse dieser Statusmeetings werden auch
an das Steuerungsgremium kommuniziert und dort auf übergeordneter Ebene für alle beteiligten
Teams verfolgt. In den Statusmeetings stellen alle Entwickler vor, was sie in der letzten Woche
gemacht haben, und sprechen auch etwaige Probleme oder offene Fragen an, die anschließend im
Team diskutiert werden. Auf diese Weise wird der Stand der Projektarbeiten auch für alle beteilig-
ten Entwickler im Team transparent gemacht. Einmal die Woche wird der Stand der Projektarbei-
ten damit auf jeden Fall erfasst.

„We have a weekly status meeting. [...] So we know at the end, where do we stand.
[...] We define the weekly targets first of all. So, if we have to deliver ten by end of,
say May – then you have to deliver first two by this month, three by next week and ...
So, calendar week targets, we will have. And then you track against the calendar week
target, whether you have achieved it or not.“ (NI6)

In der Praxis sind die Kontrollzyklen jedoch teilweise wesentlich kurztaktiger. Die Projektma-
nager und fachlichen Leiter sind in ihrer Anleitungsfunktion sowieso ständig in engem Kontakt
mit den Entwicklern und haben so die Möglichkeit, sich informell ein Bild vom Fortgang der Ar-
beiten zu machen. Wie häufig sich die fachlichen Vogesetzten des Status der Entwicklungsarbeiten
vergewissern, hängt dabei wieder entscheidend von der Zusammensetzung des Projektteams ab.
Genau wie die Intensität der Anleitung und Anweisung durch den Vorgesetzten bei neuen und un-
erfahrenen Beschäftigten höher ist, ist auch die Überwachung durch den Vorgesetzten bei diesen
Beschäftigten zunächst intensiver. Sobald die neuen Entwickler jedoch erfahrener werden, wird
die Überwachung stetig reduziert, wie ein fachlicher Leiter ausführt:

„The first thing would be: how responsible your manager thinks you are. So, no one
really likes to be treated as, eh, I mean, if my manager, eh, always suspects me, and
158 Fallstudie NovoProd

every day asks me: ’are you doing your job, are you doing your job?’ That’s not so-
mething, anybody likes. So, this does not happen here. I have worked in three teams
with three managers. I worked with two Indian managers and one German manager.
And the experience always has been, that: they will give you a task usually. And the
first time, they give you a task, they will review it closely. If it’s the first time, they
gave you a task. But once, you do the task properly – after that no one really bothers
you every day. So, somehow it’s up to you also: you have to build that trust.“ (NI28)

Zwar wird bei NovoProd strategisch beabsichtigt, den Verlauf der Projekte in wöchentlichen
Treffen zu erheben und die Entwickler möglichst nicht mit kurztaktigen Statusmeldungen zu be-
helligen, die die individuell auf die Arbeitsaufgaben verausgabte Arbeitszeit wird dennoch auf Ta-
gesebene erfasst. Diese Erhebung hat aber nicht den formalisierten und feingliederigen Charakter
des Vorgehens bei ServiceTec (vgl. 5.3.2). Wurde bei ServiceTec versucht, durch den Einsatz weit-
reichender computergestützter Systeme die Arbeitsverausgabung der Beschäftigten teilweise im
Minutenbereich zu messen, wird bei NovoProd die Verausgabung der Arbeitszeit in „Entwickler-
tagen“ gemessen. Die Entwickler erfassen ihren Arbeitsaufwand selbst und buchen diesen auf die
Projekte, in denen sie eingesetzt sind, wie ein Manager erläutert:

„Es gibt natürlich schon ein sehr gutes Projektmanagement. Nur, die Kollegen erfas-
sen natürlich dann selbst, wie viel Zeit sie mit welchen Projekttätigkeiten verbracht
haben. Das wird praktisch auf einer Tagesbasis erfasst. Selbst ich erfasse das. Das ist
auch wichtig insgesamt fürs Controlling. [...] Und das wird dann schon auf diesem
Level auch erfasst. Und die Kollegen, die Entwickler, die haben dann auch bestimmte
Projektschlüssel und sagen: okay, ich habe jetzt einen Tag auf dem Projekt gearbeitet
und den nächsten Tag auf einem anderen Projekt. Sonst können wir ja auch gar nicht
nachhalten, wie viel Arbeitszeit ist eigentlich in welches Projekt geflossen. Es gibt ja
auch viele Kollegen, die auf mehreren Projekten gleichzeitig arbeiten.“ (ND1)

Eine über die Anrechung der Arbeitsaufwände auf die Projekte hinausgehende Arbeitszeiterfas-
sung gibt es bei NovoProd jedoch nicht. Es gibt zwar ein System, das registriert, wer wann die
Büros betritt und verlässt, dieses wird jedoch nicht in Bezug auf die Arbeitszeit der Beschäftigten
ausgewertet, wie ein Manager betont:

„Deshalb haben wir auch keine Arbeitszeiterfassung, weder dort noch hier. Sie gehen
hier zwar durch die Drehtür, die Drehtür erfasst auch wer rein gekommen ist, aber
mehr aus Sicherheitsgründen, dass wenn jetzt hier irgendwie ein Flugzeug drauf stürzt,
weiß man, wer ist tot. [...] Es ist mehr der Aspekt, es wird nicht ausgewertet, also: wie
lang war der eigentlich in dem Gebäude, oder wann ist der dann da rüber gegangen.
Die Drehtür ist mehr ein Sicherheitsaspekt als eine Arbeitszeitkontrolle. [...] Das ist
übrigens ungewöhnlich in Indien, dass wir die Arbeitszeit nicht erfassen. Weil wir
auch in Indien die Erfahrung gemacht haben, dass die Kollegen das auch schätzen, dass
es keine strikte Kontrolle gibt.“ (ND1)

Die Einschätzung des Standortleiters, dass die fehlende Arbeitszeitkontrolle von den Beschäf-
tigten sehr geschätzt würde, wird durch Äußerungen der Entwickler bestätigt. Solange man seine
Arbeitsaufgaben erledige, sei es möglich, die Arbeitszeiten gemäß individueller Interessen zu ge-
stalten. Vertraglich sind bei NovoProd 40 Std. Arbeitszeit pro Woche vereinbart, und mit diesem
Vertrag sind auch alle evtl. anfallenden Überstunden abgegolten. Angst, dass die Beschäftigten zu
Betriebliche Kontrollstrategien bei NovoProd 159

wenig arbeiten, muss NovoProd trotz des fehlenden Erfassungssystems nicht haben, wie der bereits
zitierte Standortleiter ausführt:

„Der Gruppendruck ist sowieso viel besser. Wenn das Team eine Aufgabe zu schaffen
hat, dass geht Ihnen ja sicherlich nicht anders, wenn Sie da irgendwo forschen und da
ist jetzt noch was fertig zu kriegen, wenn dann 3 Leute da sitzen, geht der vierte nicht
in den Baggersee. [...] Und das funktioniert viel, viel besser. Wir zahlen vernünftig,
dann sind eben solche Sachen abgegolten.“ (ND1)

Zu dieser Einschätzung passt, dass gerade bei nahenden Deadlines die Arbeitszeiten aller Ent-
wickler nach eigenen Angaben deutlich über die vertraglich vereinbarten 40 Std. hinausgehen. Die
flexible Regelung der Arbeitszeiten bei NovoProd mache es jedoch möglich, dass die dabei anfallen-
den Überstunden von den Beschäftigten in ruhigeren Phasen auch wieder „abgebummelt“ werden
können, indem sie früher die Firma verlassen. Jedenfalls wird die Möglichkeit der persönlichen Ge-
staltung der Arbeitszeiten von vielen Beschäftigten als ein sehr positiver Aspekt der Beschäftigung
bei NovoProd hervorgehoben (vgl. Mayer-Ahuja 2011, auch Kapitel 6.3.4).

Bei den beiden bisher behandelten Aspekten der Kontrollstruktur, der Anleitung und Anwei-
sung, genauso wie bei der Überwachung der Arbeitsabläufe, zeigt sich also, dass NovoProd ver-
sucht, den Beschäftigten möglichst viel Verantwortung und Einflußmöglichkeiten auf ihre Ar-
beitsverausgabung zuzugestehen. So sollen diese ihre Arbeitsaufgaben möglichst selbstorganisiert
bearbeiten und auch ihre Arbeitszeiten können sie selber in Länge und Lage beeinflußen, natür-
lich immer vorausgesetzt, sie sind in der Lage, ihre Arbeitsaufgaben in der vorgegebenen Zeit zu
erledigen. Dementsprechend lässt sich für die Aktivitäten des Managements im Bereich der Kon-
trollstruktur bisher ein wenig detailliertes und formalisiertes Vorgehen konstatieren.

Messung und Bewertung von Arbeitsleistung

Dies gilt auch für den letzten Aspekt der Kontrollstruktur, die Beurteilung und Belohnung der
Arbeitsleistung der Entwickler. Grundsätzlich wird bei NovoProd die Leistung der Entwickler
einmal pro Jahr in einem direkten Gespräch mit dem für einen Funktionsbereich der Applikation
zuständigen Personalmanager erhoben und bewertet. Grundlage dieses Beurteilungsprozesses sind
(wie bei ServiceTec) Zielvereinbarungen, die jeder Entwickler individuell am Anfang des einjäh-
rigen Turnus mit dem Personalmanager aushandelt. Nach 6 Monaten findet ein sogen. „Review-
Treffen“ statt, auf dem die am Anfang des Jahres vereinbarten Ziele noch einmal diskutiert werden
und bei etwaigen Veränderungen auch angepasst werden können. Die Bewertung der Arbeitsleis-
tung erfolgt jedoch erst am Ende des zwölfmonatigen Zyklus.

Die für die Entwickler festgelegten Ziele beinhalten bestimmte Erwartungen hinsichtlich der
im nächsten Bewertungszeitraum zu erledigenden Arbeitsaufgaben, aber auch einen persönlichen
Entwicklungsplan, der eher „weiche“ Ziele hinsichtlich der persönlichen und qualifikatorischen
Entwicklung der Entwickler formuliert.
Die Ziele hinsichtlich der zu erledigenden Arbeitsaufgaben werden bei NovoProd top-down ge-
neriert. Aus den vom Steuerungsgremium für die nächsten Waves geplanten Zielen werden vom je-
weiligen Personalmanager zunächst Teamziele für jeden Funktionsbereich und daran anschließend
individuelle Ziele für die einzelnen Mitglieder des Teams abgeleitet, wie ein Manager ausführt:

„Da gibt’s schon konkrete Richtlinien, da gibt’s auch einen konkreten Prozess, wie
das Ganze aussieht, wie das Ganze durchgeführt wird. Am Anfang des Jahres in der
160 Fallstudie NovoProd

Regel Zielvereinbarungsgespräche: die Ziele werden definiert, eben top-down runter-

gebrochen. Ich bin dann letzten Endes derjenige, der dann aus den Bereichszielen die
Teamziele ableitet. Aus den Teamzielen dann letzten Endes die individuellen Ziele ab-
leitet.“ (NI1)

Durch die Abhängigkeit von den zentral vom Steuerungsgremium für das nächste Jahr beschlos-
senen Entwicklungsplänen hängen diese arbeitsinhaltlichen Ziele stark von der jeweiligen Phase
der Entwicklung ab. So berichten die Entwickler, dass zu Beginn der Produkt-Entwicklung, als
primär Design- und Architekturaufgaben die Arbeitsaufgaben bestimmten, diese arbeitsinhaltli-
chen Ziele von Lern- und Forschungszielen dominiert wurden, die wesentlich qualitativer Natur
waren:

„I think 2005 was a very short time for them – like, only six months in that time they
were in the organization. So at that time, it was a very high level goal. I didn’t have
to give any detail. Because it was more, like, a training and learning and doing certain
tasks.“ (NI24)

Ziele konnten zu dieser Zeit durchaus beinhalten, eine „innovative idea“ in einer bestimmten
Hinsicht zu entwickeln (NI8) oder sich bestimmte technische Grundlagen zu erarbeiten (NI25).
In späteren Phasen, in denen die technische Realisierung der Applikation im Zentrum stand,
waren die Ziele entsprechend enger mit der technischen Umsetzung verknüpft. So wird in dieser
Phase z.B. eine Erwartung an die produzierten Screens der Entwickler als Ziel formuliert, die sich
auf die benötigte Zeit und Qualität bezieht, wie ein Gesprächspartner berichtet:

„As I told you: in the development it’s more of delivering and other things. [...] For
example: we have to finish all the development tasks on time and quality. [...] This is
a kind of example of a goal. [...] So it’s basically that qualitative stuff. Also, we clearly
define the ... ’what is the achievement?’ thing, ’how it will be measured’.“ (NI25)

Diese Anforderungen unterscheiden sich nicht zwischen den beteiligten Entwicklern, sondern
es handelt sich dabei um vom Steuerungsgremium bestimmte Qualitätsanforderungen für die nächs-
te Wave, denen alle Entwickler in der betreffenden Phase genügen müssen. Daher unterscheiden
sich auch die arbeitsinhaltlichen Ziele der Entwickler nicht wesentlich voneinander:

„If everybody is a developer, then the kind of goals they need to achieve is common
for everyone, more or less.“ (NI25)

Neben diesen arbeitsinhaltlichen Zielen gibt es für jeden Entwickler jedoch auch noch einen
Bereich, der die Weiterentwicklung der persönlichen Qualifikationen und Kompetenzen betrifft.
Hier werden z.B. Trainingsmaßnahmen zu bestimmten betriebswirtschaftlichen oder technischen
Themen verabredet, die im nächsten Jahr besucht werden sollen. Darunter fallen aber auch be-
stimmte „soft skills“. So berichten manche Entwickler, dass sie als Vorbereitung auf eine Beförde-
rung bereits einzelne Tätigkeiten eines fachlichen Leiters übernehmen sollen, wie z.B. dem Steue-
rungsgremium bestimmte Berichte vorzutragen, bestimmte Sitzungen bei Teamtreffen zu leiten,
o.ä. Ziele in diesem Bereich sind nach Lage des erhobenen Materials sehr unterschiedlich und an-
scheinand auch sehr stark von der jeweiligen Persönlichkeit und der individuellen Qualifikation
abhängig.
Betriebliche Kontrollstrategien bei NovoProd 161

Betrachtet man den Prozess der Zielvereinbarung, so fällt auf, dass bei NovoProd sehr viel Wert
darauf gelegt wird, dass die Beschäftigten selber eine aktive Rolle bei der Definition der Zielvor-
gaben für das nächste Jahr spielen sollen, wie es sich auch in der Aussage eines Personalmanagers
ausdrückt:

„Ich bin dann letzten Endes derjenige, der dann aus den Bereichszielen die Teamziele
ableitet. Aus den Teamzielen dann letzten Endes die individuellen Ziele ableitet. [...]
Und ich möchte natürlich auch von jedem einzelnen dann, wenn wir uns zum Ziel-
vereinbarungsgespräch treffen, dass er sich Gedanken macht, was Ziele für ihn sein
könnten, wenn er sich die Teamziele anschaut, inwieweit er sich da einbringen kann
und wiederfinden kann. Wie er praktisch contributen kann, um die Ziele zu errei-
chen.“ (NI1)

Zu diesem Zweck werden die vom Steuerungsgremium für den Gesamtbereich definierten und
die für das Team vom Personalmanager daraus abgeleiteten Ziele vor den individuellen Zielverein-
barungsgesprächen im Team kommuniziert. Die Entwickler sind dann aufgerufen, sich zunächst
selber zu überlegen, welche Ziele sie in der nächsten Phase erreichen wollen und welche Teile der
Teamaufgabe sie übernehmen möchten. Auf diese Weise soll den Entwicklern die Möglichkeit ge-
geben werden, sich zu spezialisieren und Aufgaben zu wählen, die sie persönlich interessieren. In
dem Zielvereinbarungsgespräch macht der jeweilige Personalmanager dann einen Vorschlag, wie
er gedenkt, die individuellen Ziele zu definieren. Anschließend wird darüber diskutiert:

„And then we sit together ... you know, give the objectives already ahead of time to the
developer – so that he can look at it. And then also ... add, modify, change – whatever
he wants to do it. Delete is not an option [lacht]. Add or modify – and then we sit in
the meeting to discuss about the subjectives – with the measurements and the criteria,
how it is going to be measured. [...] He also knows the overall company goals, and
then his personal plan and the objectives. If it doesn’t match or he wants to make
some modifications, then ... eh, we can discuss it in the meeting. And then he submits
it. Then I approve that.“ (NI24)

Nach Aussagen eines Personalmanagers könne in diesen Gesprächen häufig eine zufriedenstel-
lende Lösung gefunden werden, wenngleich die vorliegenden Teamaufgaben auch eine klare Gren-
ze der Beeinflussung bilden, weil sie erfüllt werden müssen:

„Und dann gibt’s einfach schon Möglichkeiten, wenn man zusammensitzt und sagt:
’Was hast du dir jetzt für Gedanken gemacht?’ In ganz, ganz vielen Fällen gibt’s fast ei-
ne komplette Übereinstimmung, zu 90 % oder sogar fast zu 100 %. In manchen Fällen,
da gibt’s dann gewisse Abweichungen, [...] und dann hängt es einfach schlicht und er-
greifend davon ab, [...] was sind denn jetzt letzten Endes die Ziele, was muss denn jetzt
letzten Endes erreicht oder gemacht werden? Was wollen wir denn zusammen errei-
chen als Ziel? Und da muss eben der eine oder andere halt auch mal eine Aufgabe unter
Umständen übernehmen und sich da einarbeiten, was in der Regel aber auch kein Pro-
blem ist. [...] Also es ist nicht so, dass es so läuft, dass ich die Ziele alle definiere, und
dann ist es Prinzip nur noch ein Zuhören mehr oder weniger. Sondern [...] es ist schon
erstmal, dass ich zuhöre. Ich höre mir an, was hat der Kollege sich für Gedanken ge-
macht? Wo sieht er sich in der Verwirklichung der Ziele, in der Erreichung der Ziele?
Und dann wird eben drüber gesprochen. Und wenn es eine Übereinstimmung gibt,
162 Fallstudie NovoProd

wunderbar - ist das Gespräch entsprechend kurz. Wenn es keine Übereinstimmung

gibt, gut, dann wird eben diskutiert, was es sonst für Möglichkeiten gibt, Alternati-
ven. In der Regel - zumindest bis zum heutigen Tage - haben wir es eigentlich immer
geschafft, auf einen gemeinsamen Nenner zu kommen, und die Ziele dann festzulegen.
So dass alle glücklich waren - oder zumindest zufrieden.“ (NI1)

„Gemessen“ wird die Erreichung der Zielvorgaben schließlich am Ende des Jahres auch bei No-
voProd in 5 Graden der Erwartungserfüllung für jedes definierte Ziel: „meets expectation, exceeds
expectations, consistently exceeds, partially meets or does not meet“ (NI 24). Dabei werden die
Ziele, die sich auf die persönliche Entwicklung beziehen, nicht in die Bewertung der Arbeitsleis-
tung miteinbezogen:

„Development plan is not really taken into the rating. Because those are the training
needs and [...] it’s not, how the person performs.“ (NI25)

Dementsprechend werden evtl. nicht eingehaltene Absprachen hinsichtlich der Weiterentwick-

lung von Qualifikationen nicht in die Leistungsbeurteilung einbezogen, sondern eher für die Pla-
nung der nächsten Phase berücksichtigt.
Das „Rating“, also die Bewertung der Zielerreichung bezieht sich demnach bei NovoProd in
erster Linie auf den Grad der Erreichung der arbeitsinhaltlichen Ziele. Zur Bewertung der Zieler-
reichung sitzen Projekt-, Personalmanager und der jeweilige Entwickler zusammen und diskutie-
ren. Wie auch bei ServiceTec tragen die Entwickler zunächst eine Eigenbewertung in das Treffen,
die dort mit der Bewertung durch den Projekt- und den Personalmanager konfrontiert wird. Zur
Messung der Zielerreichung wird bei NovoProd nicht in dem Maße auf statistische und quantitati-
ve Meßgrößen rekurriert, wie es bei ServiceTec der Fall war – solche Systeme sind bei NovoProd
gar nicht implementiert. Vielmehr sind die arbeitsinhaltlichen Ziele mit relativ groben Vorgaben
hinterlegt, denen die programmierten Programmteile entsprechen müssen, wie ein Entwickler an
einem Beispiel erläutert:

„For example, let’s say that this person is working in my team, okay. He needs to do a
specific objective of ... let’s say: a screen called task control. Okay? He needs to make
sure that this task control is completed for the base called the ’Release Candidate 1’
and all this ... volume readiness – with, eh, you know, the ... At the end of that – via
any specific way. But he should not have, eh, the Prio one, Prio two and Prio three
errors. And, eh, it should work in all these scenarios – A, B, C, D. And this is the time
line – this is the measurement, how I have got to do.“ (NI24)

Die Leistung dieses Entwicklers wird also daran „gemessen“, dass ein bestimmter von ihm ver-
antworteter Teil der Applikation zu einem bestimmten Zeitpunkt, bei Fertigstellung einer ersten
Version der Applikation (Release Candidate 1) vorliegen und bestimmte Fehler (nach Kategori-
en eingeteilt) nicht mehr aufweisen soll. Ferner werden bestimmte Anwendungsbeispiele definiert
(die „scenarios“), denen der Programmcode zu dem Zeitpunkt genügen soll.
Der Abgleich mit den damit formulierten Erwartungen hinsichtlich Zeit und Qualität führt
dann zur Einschätzung der Zielerreichung durch das Management. Dazu wird zunächst jedes defi-
nierte Ziel in den 5 Graden der Zielerreichung eingeschätzt und anschließend ein Durchschnitts-
wert gebildet, der dann die Gesamtbewertung des jeweiligen Entwicklers darstellt.
Betriebliche Kontrollstrategien bei NovoProd 163

Dabei muss bei NovoProd jedoch berücksichtigt werden, dass das Funktionieren eines Teils der
Applikation häufig daran gebunden ist, dass auch der Rest der Applikation lauffähig ist. Dement-
sprechend sind die Ziele der Entwickler auch nicht klar voneinander zu trennen, d.h. die Erfüllung
der individuellen Ziele beruht zum großen Teil auch auf der Erfüllung der Teamziele:

„I measure at the individual level. But we also have the team thing – so we know there
is not a big gap. Yeah. What the team achieved, we also look at it, and then also look at
where the individual has performed really, and how he has contributed. Because there
shouldn’t be a mismatch – somebody has done very good and team has not delivered
the whole thing. Then it doesn’t really match. So we [...] keep the whole picture in
mind. Because there could be many things, which are beyond the person’s control,
developer’s control.“ (NI25)

Der individuelle Anteil an der Erfüllung oder Nicht-Erfüllung der Teamziele ist daher auch
von den Personalmanagern nicht immer trennscharf einzuschätzen. So ist die individuelle Nicht-
Erreichung von bestimmten Zielen häufig auch von externen Faktoren abhängig. Grundsätzlich
kann daher für den Prozess der Beurteilung und Bewertung der Arbeitsleistung bei NovoProd kon-
statiert werden, dass eine Kultur von „individual contributors“ (wie bei ServiceTec) bei NovoProd
nicht anzutreffen ist. Die persönlichen Ziele werden demnach wesentlich stärker als Teil eines ge-
meinsamen Zieles der Teams kommuniziert und (wie die folgende Aussage eines Entwicklers zeigt)
auch von den Betroffenen als solche begriffen:

„Aber gleichzeitig habe ich die meisten Sachen eh immer als gemeinsames Ziel ver-
standen. [...] Ich habe das weniger als Aufgabe, wie einen Vertrag, den man erfüllen
muss, gesehen, sondern eher als gemeinsames Zielausmachen: Wo will man hin? Das
versucht man halt, bestmöglich zu erreichen. Dies ist möglichst offen in der Art und
Weise, was jetzt eben geklappt hat und was nicht geklappt hat. Und bisher hatte ich
auch immer das Glück, dass ich mit meinen Vorgesetzten eben nie Probleme hatte, in
der Beurteilung, woran es jetzt lag, wenn diese Sachen nicht erreicht worden sind, oder
dass es eben teilweise wirklich externe Faktoren sind, die man nicht beeinflussen kann.
Umgekehrt eben auch die Sachen, die eben geklappt haben, entsprechend gewürdigt
wurden.“ (ND7)

Es liegt wahrscheinlich an dieser engen Kopplung von Individual- und Teamzielen, dass sich in
den untersuchten Teams auch selten große Schwankungen hinsichtlich der Zielerreichung finden,
wie ein Personalmanager für sein Team beispielhaft beschreibt:

„We ... Normally, I think, the spread is mostly of people, who really meet the expec-
tations, or people who exceed the expectations.“ (NI25)

Entgegen der Praxis ServiceTecs versucht NovoProd auch nicht, die Leistungsdifferenzen in-
nerhalb der Teams stark zu betonen. Das zeigt sich zum einen darin, dass jeder Entwickler im
Anschluß an das jährliche Treffen mit dem Projekt- und Personalmanager zwar sein persönliches
Rating erhält, dieses Rating jedoch vertraulich zwischen Management und Entwickler behandelt
wird und auch kein Ranking über das gesamte Team angestellt wird, wie es bei ServiceTec der
Fall war. Zum anderen operiert NovoProd auch nicht mit statistischen Vorgaben hinsichtlich der
Eingruppierung von Entwicklern in die fünft Leistungsklassen, wie es bei ServiceTec – und nach
Mukherjee (2008) auch generell bei den indischen Servicefirmen – der Fall ist, wie ein Personalma-
nager erläutert:
164 Fallstudie NovoProd

„No, there is a trend what HR talks about is, you know ... In a team – if you have to
raise the par ... for everybody, then you would naturally have some people who are
exceeding expectations, some people meeting expectations, some people don’t meet
the expectations or ... partly meeting expectations. There is something like that. And
they look at: Okay – in a team of a certain size, I think, they would expect that some of
them are like this, some of them are this. They expect, most of them will be meetings
expectations – maybe about 60% or so are meeting. On that level. And 20% who
exceeds – and then 10% consistently exceeds. And then 5% and 2% – something like
that. They have some numbers. This is the general pattern, but we don’t go exactly
with that.“ (NI24)

Bei NovoProd steht hingegen der Teamgedanke wesentlich stärker im Vordergrund. Dafür spricht
auch, dass die jährlichen Ratings primär dem Zweck dienen, den Entwicklern eine Rückmeldung
zu geben, wie die individuelle Leistung vom Management beurteilt wird, wie der folgende Perso-
nalmanager klarstellt:

„First, we also look at the people, who have performed really well. That’s first thing –
overall. And there is a percentage derived out of it, which determines the bonus, paid
out to people. That’s just a by-product. The main focus is to give a holistic feedback of
all the performance and then the rate, eh ... Where they really stand, actually.“ (NI25
– Hervorhebung des Autors)

Gehaltsrelevant sind diese Ratings eher nicht, wie sich bereits in der Formulierung des Perso-
nalmanagers ausdrückt, der die daran geknüpften Bonuszahlungen lediglich als „by-product“ der
individuellen Zielerreichung bezeichnet. Für jeden Beschäftigten bei NovoProd gibt es je nach
individueller Qualifikation und Erfahrungsstufe ein fixes Grundgehalt. An dieses Grundgehalt
sind jährliche, leistungsbezogene Bonuszahlungen geknüpft, die in ihrer Höhe je nach Funktion
im Unternehmen variieren. Für die Entwickler beträgt der variable, leistungsbezogene Anteil am
Grundgehalt nach Aussage der HR-Beauftragten für Application ca. 9% des Jahresgehalts (ND 3).
In der Praxis bedeutet das für die Entwickler, dass der jährliche Bonus bei 100% Zielerreichung
etwas mehr als ein dreizehntes Monatsgehalt umfasst:

„100 percent bonus do almost a little more than your monthly salary, on an average.“
(NI21)

Wenn ein Entwickler mehr als 100% Zielerfüllung erreicht hat, bekommt er demgemäß auch
einen größeren Bonus:

„So, there is an amount, which is promised in the beginning of the year, and if we meet
100 percent of the goals assigned to us, we get this amount. If we meet less, it’s that
percentage, if we meet more, it’s that much more. So if in our team the calculation
went like, if I reach 112 percent of what I have set up to achieve, then I get 124 percent
of the bonus, whatever was added above 100, doubles. So I get 124 percent of the
amount promised.“ (NI21)

Selbst wenn von NovoProd dabei ein überproportionaler Zusammenhang zwischen Zielerrei-
chung und Bonuszahlung hergestellt wird (12% über 100% Zielerreichung ergeben 24% mehr Bo-
nus), bleiben die Unterschiede zwischen den Leistungsgruppen damit in Bezug auf das Gesamtge-
halt übersichtlich. So werden Entwickler, die ihre Ziele überfüllen, in der Regel mit ca. 105-120%
Betriebliche Kontrollstrategien bei NovoProd 165

Bonus veranschlagt (NI 25). Demnach bekommen besonders „gute“ Beschäftigte nur 20% mehr Bo-
nuszahlung als der Durchschnitt. Legt man ein durchschnittliches Monatsgehalt von knapp 45.000
Rupien brutto zugrunde14 und geht man ferner davon aus, dass der Bonus grob diesem Monatsge-
halt entspricht, so erhielten Entwickler, die ihre Ziele übererreichen, gerade einmal 9.000 Rupien
(knapp 140 Euro) mehr im Jahr als die Kollegen, die „nur“ 100% Zielerreichung aufweisen können.
Dies entspricht durchaus dem strategischen Vorgehen NovoProds, die Gehaltsschwankungen
innerhalb der Teams möglichst zu begrenzen:

„We tend to keep the differences minimal. Still there will be differences. But I say,
totally it’s very minimum.“ (NI25)

Auch hierbei steht wieder der Teamgedanke im Vordergrund. Interne Konkurrenz zwischen
den Entwicklern um die Höhe der Gehälter soll eher vermieden werden:

„I am not giving the exact details of it, but the most important consideration, that we
give, is the internal parity. So, [...] we try to ensure, that it should not be a case, where
you take one person and other ten people are disappointed because of that. So, that
is number one consideration. In NovoProd [...] it is sort of more or less balanced.“
(NI15 – Hervorhebung des Autors)

Die Gehälter werden noch im Abschnitt über die Arbeitsmarktbeziehungen NovoProds Thema
sein. An dieser Stelle ist festzuhalten, dass die Bewertung der individuellen Leistung sich bei No-
voProd nicht in stark streuende Gehälter übersetzt. Der damit verknüpfte Versuch, einen Team-
gedanken zu institutionalisieren und dementsprechend Leistungsmessung nicht übermäßig zu in-
dividualisieren, verweist bereits auf die Form der Kooperationsbeziehungen bei NovoProd.

6.3.3 Kooperationsbeziehungen
Kooperationsbeziehungen innerhalb von Application
Der Blick auf die Kontrollstruktur ergab, dass den Beschäftigten bei NovoProd durch ein wenig
formalisiertes und detailliertes System der Anleitung und Anweisung große Handlungsspielräu-
me für die Planung und Durchführung ihrer Arbeitsaufgaben zugestanden werden und dass das
System der Leistungsbewertung vergleichsweise wenig individualisiert ist. Versuche, den Erfolg
eines Teams individuell runterzubrechen und die Leistung jedes einzelnen Entwicklers möglichst
exakt zu messen, sind bei NovoProd wenig entwickelt. Als Grund für dieses Vorgehen konnte vor
allem die Art der bei NovoProd zu bearbeitenden Aufgaben identifiziert werden, die es auf der
einen Seite aufgrund ihres komplexen Charakters erschweren, a priori enge und detaillierte Vor-
gaben hinsichtlich des Vorgehens der Arbeitsverrichtung zu definieren und die es auf der anderen
Seite aufgrund der Interdependenzen der einzelnen Komponenten der Applikation auch erschwe-
ren, die Gründe für Fehlschläge oder Erfolge einzelnen Personen eindeutig zuzuschreiben. Zudem
wurde gezeigt, dass es strategisch auch gar nicht beabsichtigt ist, die Leistungsdifferenzen innerhalb
der Teams stark zu betonen oder gar zu nutzen, um interne Konkurrenzverhältnisse zwischen den
Entwicklern zu inszenieren oder zu verschärfen. Vielmehr wird bei NovoProd darauf geachtet, das
interne Gleichgewicht („internal parity“) innerhalb der Teams zu wahren.
Der Hintergrund dafür scheint nach Lage der Interviews die Befürchtung zu sein, dass inter-
ne Konkurrenzverhältnisse die Kooperation und Kommunikation der Entwickler untereinander
14
Dieser Wert ergibt sich als grober Durchschnittswert aus den Angaben der Entwickler.
166 Fallstudie NovoProd

erschweren könnten. Wie in Abschnitt 6.2 (S. 123) ausgeführt, versucht NovoProd, sich gezielt
von einer Art des Offshoring abzugrenzen, das die Kommunikation der beteiligten Akteure stark
kanalisiert und den Kontakt in den jeweiligen Projektmanagern bündelt. Vielmehr findet die in-
terne Kommunikation innerhalb des Entwicklungsnetzwerkes bei NovoProd auf allen Ebenen der
beteiligten Teams statt. Berücksichtigt man zudem die Ausführungen zum komplexen und interde-
pendeten Charakter der verteilten Entwicklung, so ergeben sich für die Entwickler bei Application
extrem hohe Kommunikations- und Kooperationserfordernisse, sowohl innerhalb des Teams, als
auch (innerhalb des gesamten Entwicklungsnetzwerkes) zu den anderen beteiligten Einheiten Vi-
sion und Platform.
Zwar wurde ausgeführt, dass die in Application verteilten Arbeitsaufgaben im wesentlichen in
einer bestimmten Zahl von Screens bestehen, die individuell zugewiesen werden. Daraus aber ab-
zuleiten, dass die von den Entwicklern geleistete Arbeit im wesentlichen in Einzelarbeit bestünde,
wäre verfehlt. Zwar arbeiten alle Entwickler in erster Linie an ihren „eigenen“ Screens, jedoch ist
diese Bearbeitung in einen breiten Zusammenhang von Teamaktivitäten eingebettet. Denn auch
wenn jeder Screen in der Verantwortung eines Entwicklers liegt, beteiligen sich die anderen Team-
mitglieder an der Bearbeitung. Auf den wöchentlichen Teammeetings, die auch der Statuserhebung
dienen (vgl. Kapitel 6.3.2), berichten in der Regel alle Entwickler des Teams vom Fortschritt der
Bearbeitung ihrer Screens und können in diesem Zusammenhang auch offene Fragen und Probleme
bei der Entwicklung ansprechen, die anschließend innerhalb des Teams diskutiert werden. Dieser
Austausch der Entwickler dient nicht nur dem naheliegenden Zweck, sich gegenseitig bei Proble-
men zu helfen – dies findet ohnehin alltäglich auf informeller Ebnene statt – sondern zudem dem
Zweck, dass alle Teile des Teams auch über die anderen Screens und damit zusammenhängende
Probleme informiert werden und so auch ein besseres Bild des „großen Zusammenhangs“ gewin-
nen sollen. Ein Qualitätsbeauftragter erläutert anhand eines Teams, dass aus mehreren kleineren
Teamteilen besteht:

„We have weekly synchronization meetings. [...] So, we all get in touch in such regular
synchronization meetings. We share our issues, our learning amongst others. Such a
forum also help us in probably learning from what issues the other team has got or
what sort of an solution they have invented – which we can probably directly use in
our teams and so on. So, such forums also are useful and they work pretty well.“ (NI5)

Wie sich aus der zitierten Aussage entnehmen lässt, betreffen viele Probleme, die bei einem
Screen auftreten, ebenso andere Screens oder auch andere Funktionsbereiche, z.B. wenn es um
grundsätzliche Funktionen der Technologieplattform und deren Einbindung in die Benutzero-
berfläche geht. Daher beteiligen sich in den Teamdiskussionen grundsätzlich alle Entwickler eines
Teams, um bei Problemen eine Lösung zu finden, wie ein Entwickler ausführt:

„And each time actually, new components are coming from technology teams. So [...]
we should have the flexibility to decide also, because these new components are co-
ming in, we may use the new components, because the old components had some
other issues as well and some limitations. So, we decide it from our side.“ (NI9)

Doch es sind nicht nur äußere Einflüsse, die innerhalb des Teams diskutiert werden. Wie in
Abschnitt 6.3.1 erwähnt, bearbeitet Application nicht nur die Benutzeroberfläche der Applikation,
sondern auch eine Zwischenebene, die zwischen Plattform und Benutzeroberfläche geschaltet wird
und bestimmte, von der Plattform nicht generisch bereitgestellte Funktionen und Informationen
liefert. Diese Komponenten können von allen Teams innerhalb von Application genutzt und auch
Betriebliche Kontrollstrategien bei NovoProd 167

gemeinsam in Bezug auf die nötigen Funktionen diskutiert und verändert werden, wie der bereits
zitierte Entwickler weiter ausführt:
„We have some components, [...] which we have developed for our internal uses,
which are common to us, and then, if there is some new enhancement or some change
in that, all of us decide on that: ’ok, we’ll include something in this or something in
that. [...] We discuss that smaller change also, so, it’s a very informal.“ (NI9)
Es zeigt sich also, dass in Application zwar individuelle Arbeitspakete an die Entwickler vergeben
werden, diese jedoch so stark zusammenhängen, dass für die Entwickler damit die Notwendigkeit
besteht, sich stetig in ihrem je individuellen Vorgehen mit den anderen Mitgliedern des Teams
abzustimmen und z.T. auch auf ein gemeinsames Vorgehen zu einigen.

Zudem ist das ganze Team gefragt, wenn zu Beginn einer Wave die Anforderungen an die Appli-
kation von Vision kommuniziert werden. Zwar findet die Diskussion über die Ziele der jeweiligen
Wave innerhalb des Steuerungsgremiums statt, von dem die indischen Beschäftigten weitgehend
ausgeschlossen sind. Trotzdem werden die indischen Teams im Anschluß an die Diskussion um ei-
ne Einschätzung gebeten, ob die geplanten Ziele auch realistisch sind. Dazu sitzen zu Beginn jeder
Wave die indischen Teams zusammen, um die geplanten Ziele des Steuerungsgremiums zu disku-
tieren und zu entscheiden, ob sie die geplanten Aufgaben in der vorgegebenen Zeit auch umsetzen
können.
So zerfällt die Arbeitszeit der Entwickler bei NovoProd auch recht gleichmäßig in Einzel- und
Teamarbeit, wobei das Verhältnis stetig variiert und sich auch je nach Projektphase unterschied-
lich darstellt. So bestehen zu Beginn einer Wave, wenn zentrale Entscheidungen bzgl. des weiteren
Vorgehens getroffen werden müssen, höhere Kommunikations- und Kooperationsnotwendigkei-
ten als am Ende der Wave, wenn es für die Entwickler nur noch darum geht, die anliegenden
Arbeitsaufgaben rechtzeitig fertigzustellen.

Kooperationsbeziehungen zu den anderen Teams des Entwicklungsnetzwerkes

Die Kooperations- und Kommunikationsanforderungen an die Entwickler hören jedoch nicht an
den Teamgrenzen auf. Die Entwicklung der Screens begründet auch starke Abhängigkeiten von den
beiden anderen an der Entwicklung der Gesamtapplikation beteiligten Einheiten Plattform und Vi-
sion. Gemäß der Zielstruktur NovoProds findet der daraus resultierende Kontakt auf allen Ebenen
der an der Entwicklung beteiligten Teams statt. So sind zum einen die Projektmanager aller drei
Einheiten, die für eine bestimmte Funktionalität zuständig sind, in ständigem Kontakt. Doch auch
unterhalb der Projektmanagerebene ist zwischen den Entwicklern ein reger Austausch nötig. Für
die indischen Entwickler bedeutet dies, dass sie sich z.B. an andere Beschäftigte bei Vision wen-
den, um Unklarheiten bzgl. der Anforderungen zu klären oder sich Details bzgl. der grafischen
Vorgaben geben zu lassen. Zu Platform bestehen noch wesentlich engere Kontakte, da dieses Team
die wesentlichen Funktionalitäten bereitstellt und so zentraler Ansprechpartner bei Unklarheiten
oder Informationsbedarf bzgl. der Basisfunktionalitäten ist. Nach Aussagen der Entwickler fin-
den solche Klärungsgespräche zwischen verschiedenen Einheiten teilweise mehrmals täglich statt.
Diese hohe Intensität der Kommunikation ist nach Angaben des folgenden Projektmanagers auch
der Grund, warum die Kommunikation bei NovoProd nicht durch die jeweiligen Projektmanager
kanalisiert wird:
„Sehen sie, wir sind ein Projektteam im Rahmen einer großen Projektteamstruktur.
Wir arbeiten nicht allein. Wir arbeiten in einem großen Verbund. [...] Also unser
168 Fallstudie NovoProd

Projekt besteht aus sechs, aus neun Leuten. Und unsere Counterparts in Platform sind
zwischen 30 und 40. Dann gibt es Vision. Da sind nochmal fünf oder sechs Leute. [...]
Und die müssen sich alle untereinander unterhalten. Das kann, es geht praktisch nicht,
dass die Kommunikation nur über die jeweiligen Projektleiter geht. [...] Sonst werde
ich ganz schnell zum Flaschenhals, und ich kann die Menge an Kommunikation nicht
bewältigen, die dann stattfindet. Darum haben wir verhältnismäßig früh angefangen,
die ‚peer contacts‘ aufzubauen, also die indischen Kollegen mit direkten Namen von
ihren ’counterparts’ zu versorgen, damit sie kommunizieren. In der Literatur lernt
man, dass das Kommunikationsmodell über die Manager läuft. Das ignorieren wir
einfach. Die, ja, so ist es bei NovoProd in Indien klassisch nicht. Und wir versuchen,
die Leute möglichst direkt auch miteinander sprechen zu lassen.“ (ND4)
Um diese Kooperation auch über die unterschiedlichen Standorte hinweg zu gewährleisten und
die Kommunikation zu vereinfachen, hat NovoProd zu Beginn der Entwicklung viel Wert darauf
gelegt, dass sich die beteiligten Entwickler aller Einheiten persönlich kennenlernen. Daher wa-
ren erhöhte Reiseaktivitäten in allen Einheiten zu verzeichnen. Die Beschäftigten besuchten sich
gegenseitig, meist zu dem Zweck, dass die erfahrenen deutschen Kollegen erste Schulungen und
Trainings für die neuen indischen Entwickler durchführten. Diese Trainings fanden sowohl in
Deutschland als auch in Indien statt. Nach Aussagen der beteiligten Akteure waren diese persönli-
chen Treffen von entscheidender Bedeutung, um die stete Kommunikation zwischen den Einhei-
ten zu gewährleisten (vgl. NI1).
Denn gerade zu Beginn der Entwicklung bestanden durchaus Spannungen zwischen den deut-
schen und den indischen Beschäftigten, was auf der einen Seite an dem für die meisten Beteiligten
gänzlich neuen globalen Setup lag, auf der anderen Seite aber auch auf Befürchtungen der deut-
schen Beschäftigten beruhte, dass ihre Jobs langfristig genau von jenen übernommen würden, die
sie anleiten sollten. Gerade in der Zeit, als das neue Produkt ins Entwicklungsstadium kam, bau-
te NovoProd den indischen Standort aggressiv aus, und es war nicht klar, ob diese Expansion in
Indien nicht auf Kosten „deutscher“ Arbeitsplätze gehen würde.
„Ich habe das in meinem allerersten Bereich, wo ich hier angefangen habe, erlebt. Da
kam dann irgendwann mal der Chef rein und sagte: ’Unsere Gruppe wird abgebaut
und wird in Indien neu aufgebaut.’ Und dann hat er aber gesagt: ’Ja, das ist aber ein
längerer Zeitraum. Wir machen so weiter wie bisher.’ Und dann hieß es, also länge-
rer Zeitraum hieß ein bis zwei Jahre. So lange hat sich es letztendlich hingezogen.
Und dann war es aber zu dem Zeitpunkt so, dass auch gerade interne Wechsel relativ
schwierig waren. Das heißt, es gab keine klare Perspektive, was soll danach passieren.
Das heißt, es hieß schon: ’Klar, wir schmeißen keinen raus. Wir finden irgendwas für
euch.’ [...] Aber da war die Stimmung dann schon erst mal im Keller. [...] Da geht na-
türlich die Perspektive weg. Und das war eine Zeit lang auch schlecht gehandled, weil
halt die Manager entschieden haben: ’Wir verlegen das nach Indien’. Aber sie haben
nicht gesagt, was sie konkret mit den deutschen Mitarbeitern danach machen wollen.“
(ND2)
Um diese Spannungen, die die effektive Kommunikation zwischen den Einheiten erschwerten,
aufzulösen, war der direkte Kontakt nach Aussage des folgenden Gesprächspartner sehr wichtig.
Er diente dazu, „das Eis zu brechen“:
„Um dann noch mal auf den Punkt zurückzukommen: Was für mich frappierend oder
ziemlich auffällig war, war eigentlich die ersten Monate, als wir mit dem indischen
Betriebliche Kontrollstrategien bei NovoProd 169

Team so angefangen haben, so zarte Verbindungen zu knüpfen, die ersten Meetings,

wo man dann auch vorgestellt hat, was sind die Ziele, was ist die Vision, was soll
eigentlich gemacht werden - das war schon komisch irgendwie vom Gefühl her. Al-
so irgendwie hat man einfach gemerkt, dass - ja wie soll ich es beschreiben -, dass da
einfach so eine unsichtbare Maurer dazwischen ist. Deswegen habe ich auch vorhin
gesagt, es war wichtig, dass die Kollegen hergekommen sind, um wirklich das Eis zu
brechen, dass man sich mal sieht, dass man miteinander spricht, dass man auch nicht
in einem formalen Meeting miteinander kommuniziert. [...] Weil am Anfang waren
die Meetings derart, dass dann eigentlich aus Deutschland im Endeffekt alles Mögliche
präsentiert worden ist, und es wurde im Prinzip halt, wie soll ich sagen, konsumiert
auf der anderen Seite. Das Feedback war doch sehr verhalten, also ein bisschen vor-
sichtig, würde ich sagen. Und das hat sich dann aber schlagartig geändert und auch
wirklich aus meiner Sicht und auch aus der Sicht von anderen Kollegen, die das bestä-
tigt haben, doch sehr verbessert, als wir dann wirklich gesagt haben: gut, wir müssen
dahin, wir müssen die Leute kennen lernen, wir müssen auch dafür sorgen, dass da
ein gewisser Austausch stattfindet, dass die Leute auch nach Deutschland kommen,
auch hier mal mit einer anderen Abteilung zusammenarbeiten, um die Kommunika-
tion wirklich zu etablieren und zu kultivieren. Also dass man einfach dann wirklich
auch sich dran gewöhnt auf allen Seiten, dass man grad in so nem Umfeld, wo man
verteilt entwickelt, dass da Kommunikation wirklich das A und O ist. Und da reicht
die Kommunikation per Email oder wirklich anonym - weil es ist trotzdem noch re-
lativ anonym, auch wenn ich die Leute sehe am Anfang über Videoconferencing, das
ist trotzdem aus meiner Sicht noch relativ anonym, weil eben diese unsichtbare [...]
Hemmschwelle noch so ein bisschen da ist. Man ist da einfach vorsichtig. Das war
einfach so ein Gefühl am Anfang.“ (NI1)

Auch wenn im Laufe der Zeit klar wurde, dass der Aufbau des indischen Entwicklungszen-
trums (zumindest bis zum Zeitpunkt der Untersuchung) keine Entlassungen in Deutschland nach
sich ziehen würde, und sich die Befürchtungen der deutschen Beschäftigten damit zunächst als ge-
genstandslos erwiesen hatten, bleibt nichtsdestotrotz die standortübergreifende Kommunikation
und Kooperation ein Dauerthema innerhalb von NovoProd und wird von fast allen Beschäftig-
ten von Application als wichtigstes Feld für zukünftige Verbesserungen in der globalen Struktur
NovoProds genannt.

„Also aus meiner Sicht ist der allerwichtigste Aspekt überhaupt, dass man sich massiv
über Kommunikation Gedanken machen muss. Das ist das allerallerwichtigste. [...]
Es gibt keine Faustregel. Es kommt definitiv auf die Projektphase an, wie viel man
kommuniziert, wie oft man kommuniziert. Es kommt auf Sommer- und Winterzeit
an, wie oft man kommunizieren kann. In Indien gibt es keine Sommer- und Winter-
zeit, das verschiebt das Zeitfenster. [...] Also das ist wirklich, Kommunikation ist für
mich das A&O. Wenn man das hinbekommen will, muss man reisen. Man muss vor
Ort sein. Es geht nicht ohne. Man muss unstrukturierte Zeit mit den Leuten verbrin-
gen und verteilte Projekte.... Wir hatten durch diese - diese Sachen, die unerlässlich
sind, sind einfach sehr, sehr teuer. Man muss viel reisen, man muss da sein, man muss
Zeit mit den Leuten verbringen, man muss die Leute herholen, damit sie die anderen
kennenlernen. Wir hatten zum Glück die Möglichkeiten dafür. Aber wer versucht, ein
verteiltes IT-Projekt mit engen Schnittstellen aufzubauen, das verteilt ist, ohne dabei
170 Fallstudie NovoProd

genügend Reisemittel zur Verfügung zu stellen, der kriegt ernsthafte Schwierigkeiten.“

(ND4)

Zwar wurde zu Beginn der Entwicklung versucht, alle Entwickler zusammenzubringen und
persönliche Kontakte zu etablieren, doch dieser persönliche Kontakt zwischen den Beschäftigten
konnte nicht über die Zeit in allen Bereichen aufrechterhalten werden. Viele Beschäftigte, die zu
Beginn im indischen Entwicklungszentrum beschäftigt waren, haben in der Zwischenzeit das Un-
ternehmen bereits wieder verlassen oder das Team gewechselt, so dass innerhalb von Application
stetiger Bedarf besteht, Gelegenheiten zu schaffen, an denen sich die Beschäftigten persönlich ken-
nenlernen können. Jedoch entsteht genau an diesem Punkt in den letzten Jahren ein Problem bei
NovoProd, da das Reisebudget für die Entwicklung des neuen Produkts stark gekürzt wurde (ND
4) und die Frequenz, in der Beschäftigte an die anderen Standorte reisen können, damit deutlich
abgenommen hat:

„Wir drehen eigentlich kontinuierlich am Geldbudget für die Reisebudgets nach unten.
[...] Es ist nicht mehr so wie 1996, dass ich beliebig oft mit Business Class geflogen bin,
wie immer ich wollte. So war es letztendlich 1996. Es ist einfach heute so, dass Sie ein
Reisebudget haben und dass der Manager in dem Fall wirklich in der Regel abzeichnet,
ob Sie den Flug machen oder nicht. Und der muss da gucken, dass er das Reisebudget
einhält.“ (ND6)

In der Folge führt dies dazu, dass zum Zeitpunkt der Untersuchung nicht mehr alle indischen
Kollegen ihre deutschen „Counterparts“ persönlich kennengelernt haben. In der Regel bekommen
nur Beschäftigte, die schon länger in den Projekten sind und auch eine zentrale Rolle in diesen
spielen, weil sie aufgrund ihrer erhöhten Erfahrung auch verantwortungsvollere Arbeitsaufgaben
zugewiesen bekommen haben, weiterhin die Genehmigung, an andere Standorte zu reisen, wie
folgender Entwickler erklärt:

„Usually only the key people are sent, because it is expensive to travel and, you know,
stay there for some time and things like that, so it’s just about the key people, who go
there, gain the knowledge, come back and share it with other people here. So, we are a
team of 35, I would say, about 11 or 12 of us only, maybe 14 have got this opportunity
till now. [...] In NovoProd usually the perception is, that every developer also gets a
chance to go to Germany at least once, at least once is the perception, but when that at
least once comes it’s totally up to your manager or to the requirements of your team.“
(NI21)

Diese Einschränkungen in den Reiseaktivitäten werden damit auch zu einem Problem für die
standortübergreifenden Kooperationsbeziehungen. Dieses Problem stellt sich besonders stark für
die indischen Beschäftigten, da sie die oberste Ebene des Produkts entwickeln, daher sehr stark
von den beiden anderen Abteilungen abhängig sind und erhöhten Informationsbedarf gegenüber
deutschen Kollegen haben.

„Also jetzt ist es inzwischen ein bisschen dramatischer, also dramatisch ist auch falsch,
aber es ist halt reduziert worden. [...] Aber gerade in Indien ist es, denke ich mal, sehr
wichtig, dass man sich auch persönlich kennt. Das hilft halt enorm. Und das kann
man halt nicht alles über Telefon, e-Mail, Messenger, was weiß ich, erreichen. Also es
ist schon deutlich wichtiger, dass man auch mal mit den Leuten drüben war.“ (ND5)
Betriebliche Kontrollstrategien bei NovoProd 171

Das Hauptproblem für die indischen Beschäftigten ist nach Aussagen der Gesprächspartner,
dass die für ein bestimmtes Problem zuständigen deutschen Kollegen nicht leicht zu identifizieren
seien, und es daher häufig unklar sei, wer in einer bestimmten Situation anzusprechen ist und wer
bei Problemen helfen kann. Zwar gibt es formale Verantwortlichkeiten und diese werden auch in
Indien kommuniziert, doch nach Aussage des folgenden Gesprächspartners sind diese formalen
Zuständigkeiten keineswegs ausreichend:

„Ja, aber das reicht nicht. Also wenn man die offiziellen Verantwortlichkeiten sieht,
ist es bei weitem nicht detailliert genug, dass man herausfinden könnte, wer eine Frage
beantworten könnte. Stellen Sie sich vor, Sie rufen bei VW an und Sie sagen: ’Ich hab
ein Problem mit der Aufhängung meiner Zündkerze’. Ich glaube, das würde eine ganze
Weile dauern bis man den Ingenieur finden würde, der dafür verantwortlich wäre. Das
ist bei uns ähnlich.“ (ND4)

Selbst wenn der betreffende Ansprechpartner schließlich identifiziert wurde, leide der nötige
Informationsfluß stark, wenn die beiden Gesprächspartner sich nicht persönlich kennen, wie ein
deutscher Brückenkopf unumwunden zugibt:

„Weil dann wird es halt einfach schwieriger. Das beobachten wir immer wieder, die
indischen Kollegen, die gute Arbeit leisten, haben es einfach schwieriger, wenn der
deutsche Kollege sie nicht, nicht Angesicht zu Angesicht sieht, weil es einfach weiter
weg ist. Das ist halt nur irgendeine Stimme aus dem Telefon. [...] Der Kontakt bzw.
die Bereitschaft von dem deutschen Kollegen, dem indischen Kollegen – also das ist
jetzt nicht nur Indien, das ist überall, weltweit – in einem anderen Land zu helfen, ist
natürlich eher gegeben, wenn er den auch mal gesehen hat, wenn er auch mal vielleicht
persönlich mit ihm geredet hat. Diese weichen Faktoren, die man, wenn man in einem
Besprechungszimmer gemeinsam sitzt, dass man vielleicht beim Rausgehen nochmal
fragt: ’Wie geht’s denn Deiner Frau? Was machen...’ – was weiß ich – ’was macht der
Hund?’ Irgend sowas. Diese Sachen sind natürlich bei diesen Telefongesprächen we-
sentlich schwieriger, weil häufig sind es dann auch nicht Eins-zu-Eins-Gespräche [...]
und dann geht dieser persönliche Aspekt ganz weg und es dauert dann einfach länger,
den Respekt und im gewissen Sinne auch die Freundschaft oder das Wohlwollen des
anderen zu erhalten.“ (ND2)

Diese durch die eingeschränkten Reisemittel in der letzten Zeit bei Application auftretenden Pro-
bleme der direkten Kommunikation und Kooperation stellen auch einen weiteren Grund für die
bereits in Abschnitt 6.2 erwähnte Persistenz der Brückenköpfe innerhalb des globalen Entwick-
lungsnetzwerkes dar. Diese fungieren nicht nur – sofern nötig – mit ihrer Erfahrung als fachliche
Anleiter der indischen Teams, sondern besitzen auch ihre persönlichen Netzwerke innerhalb des
deutschen Standortes, die sie nutzen können, um die Kommunikation zwischen den deutschen
und indischen Entwicklern zu unterstützen. So können sich die indischen Entwickler an die deut-
schen Brückenköpfe wenden, um zu erfahren, wen sie mit ihrem Problem am besten ansprechen,
und wenn es Schwierigkeiten in der Zusammenarbeit gibt, kann der betreffende Brückenkopf ver-
suchen, diese in einem persönliche Gespräch mit dem deutschen Kollegen zu thematisieren und
evtl. zu lösen.
So haben die deutschen Brückenköpfe in den standortübergreifenden Kommunikations- und
Kooperationsbeziehungen eine ganz wichtige Funktion. Sind sie auch grundsätzlich bemüht, nicht
zum „Flaschenhals“ zu werden, an dem intensive und möglichst multilaterale Kommunikation
172 Fallstudie NovoProd

zwischen den beteiligten Akteuren scheitert, werden sie doch als Vermittler durch die Fluktuation
in den indischen Teams und den dadurch verursachten Verlust der persönlichen Netzwerke perma-
nent benötigt. So findet sich also auch im Bereich der Kooperationsstrukturen eine konfliktreiche
Situation, in der die strategische Zielstruktur der Kooperationsbeziehungen bisher nicht vollstän-
dig realisiert werden konnte. Ein Grund dafür liegt wiederrum in den Arbeitsmarktbeziehungen
NovoProds.

6.3.4 Arbeitsmarktbeziehungen
Wie erwähnt, beruht das Verlagerungsmodell NovoProds stark auf den individuellen Selbstorgani-
sationsfähigkeiten und der Erfahrung der Beschäftigten an den Offshore-Standorten, was die Form
der Aufgabenorganisation und der standortübergreifenden Kooperationsbeziehungen betrifft. Zu-
dem handelt es sich bei der Entwicklung des neuen Softwareproduktes – auch wenn nur ein Teil
der Applikation im indischen Entwicklungszentrum hergestellt wird – um eine sehr komplexe
und damit auch anspruchsvolle Arbeit, die erhöhte Qualifikationsanforderungen an die Entwick-
ler stellt.
Der indische Standort kann demnach nur in das standortübergreifende Entwicklungsnetzwerk
integriert werden, wenn ausreichend gut qualifizierte Beschäftigte am indischen Arbeitsmarkt re-
krutiert und möglichst lange im Unternehmen gehalten werden können. Denn nur in stabilen
Teamzusammensetzungen können sich die Beschäftigten tief in ihre Arbeitsaufgaben und die da-
mit zusammenhängenden Problemstellungen einarbeiten und gleichzeitig auch die notwendigen
persönlichen Netzwerke zu anderen Beschäftigten – auch an anderen Standorten – knüpfen. Der
boomende indische IT-Standort mit seinen aus der stetig steigenden Nachfrage nach IT-Fachkräften
folgenden Fluktuationsraten, stellt NovoProd deshalb vor große Herausforderungen.

Rekrutierungsbemühungen
Zum Zeitpunkt der Untersuchung schien NovoProd die Rekrutierung einer ausreichenden Zahl
von gut ausgebildeten Beschäftigten noch gut zu gelingen, wie folgender Manager berichtet:

„In Indien war das eben anders. Da konnten wir in bestimmten Bereichen in Indien
sehr zügig wachsen. Es ist auch heute noch so. Wenn sie heute einen Bereich aufbauen
wollen, 100 Leute. Da hatten wir grad in Indien wieder einen Bereich – oder meinen
Bereich. Den haben wir jetzt gerade vor anderthalb Jahren aufgebaut. Wenn man jetzt
250 Leute aufbauen muss, dann kann man höchstens 50 vielleicht aus bestehenden
Teams raus ziehen. Danach fangen alle anderen natürlich an zu schreien. Das ist ja auch
klar, das nimmt die besten Leute weg. Das heißt 200 mussten wir auch neu einstellen
und zwar in 3 Monaten.“ [F: Und in Indien geht das?] „Ja, in Indien geht das.“ (ND1)

Das liegt sicherlich auch daran, dass das indische Entwicklungszentrum in den letzten Jahren
eher moderat gewachsen ist und daher im Vergleich zu anderen in Indien aktiven IT-Unternehmen
(vor allem der stark expandierenden indischen IT-Dienstleistungsunternehmen) nur wenige neue
Beschäftigte eingestellt werden mussten. Zum Zeitpunkt der Untersuchung wurden die Wachs-
tumspläne für das indische Entwicklungszentrum jedoch erweitert, so dass sich die HR-Abteilung
wesentlich stärker um Rekrutierung kümmern muss:

„Wir sind ja nicht so stark gewachsen. Ich mein, wenn man dann von 100 auf 200
wächst, praktisch in nem ganzen Jahr 100 Leute braucht, also in nem Monat gerade
Betriebliche Kontrollstrategien bei NovoProd 173

mal 10, dann ist es relativ einfach das auch zu handlen [englische Aussprache – PF].
Die kriegt man auch aus dem Arbeitsmarkt ohne Probleme. Ich hab noch viel Zeit
investiert in die Auswahl und so. Wir sind jetzt im vergangenen Jahr von 1500 auf 2500
Leute gewachsen. Wenn sie 1000 Leute wachsen wollen in nem Jahr, dann müssen sie
natürlich auch ganz andere Prozesse haben, dann ist es nicht mehr ganz so einfach.“
(ND1)

Doch auch wenn der Bedarf an Arbeitskräften durch die ehrgeizigeren Wachstumsziele gestiegen
ist, bietet der indische Arbeitsmarkt NovoProd in Bezug auf die Rekrutierung nach Angaben des
zuständigen HR-Managers nach wie vor sehr gute Bedingungen. In den zweieinhalb Jahren, seit
er die Rekrutierungsbemühungen NovoProds am indischen Standort leitet, hat er nach eigenen
Angaben 3300 Jobangebote an Bewerber ausgesprochen, für die 225.000 Bewerbungen eingegangen
wären (vgl. NI16). Nach einer ersten Sichtung der Bewerbungen reduziert sich die Zahl der für
geeignet erachteten Bewerber zwar, jedoch blieben nach Aussagen eines anderen Mitarbeiters der
HR-Abteilung trotzdem noch für jede ausgeschriebene Stelle durchschnittlich knapp 100 Bewerber
übrig, die in die engere Auswahl kämen und in einem Interview begutachtet würden (vgl. NI15).
Aufgrund des (im Vergleich zu den indischen IT-Dienstleistern, die teilweise fünfstellige Zah-
len von Beschäftigten pro Jahr eingestellt haben) geringeren Personalbedarfs finden bei NovoProd
auch keine Massenrekrutierungen – z.B. in Form von Campus Hirings – statt, wie sie am Beispiel
von ServiceTec ausführlicher erläutert wurden (vgl. 5.3.4). Vielmehr wird bei NovoProd weiterhin
sehr selektiv für bestimmte (neu einzurichtende – oder wieder zu besetzende) Positionen rekru-
tiert, wie ein Mitarbeiter der HR-Abteilung ausführt

„So most of the recruitments, because it is not mass recruitment and it is non-campus
recruitment. [...] So, if we hire somebody, we are particularly in terms of the role, that
we are able to offer that person. So, in most cases it works out like that. So, we have a
manager sitting out for the same position, who sort of explains the role to the person
and ensures, that that person’s competence is mapped that particular role, then only
we take a decision, but having the case of mass recruiting or campus recruiting, then
it would have been very difficult, because then we first recruit the people and then
put them in the roles. Right now most of the recruitment happens against a particular
role, so it’s not so difficult as such. Yeah, we look for people with a good experience, if
we are looking for marketing the product or if we are looking for support or sales, or
we are looking for development, [...] whatever we are looking for, we are pretty clear
and we accordingly hire people, who face that particular job.“ (NI15)

Die große Nachfrage nach den von NovoProd ausgeschriebenen Stellen ermöglicht es dem Un-
ternehmen, in Bezug auf Einstellungsvoraussetzungen sehr anspruchsvoll zu sein. Das zeigt sich
zum einen darin, dass NovoProd grundsätzlich nur Bewerber akzeptiert, die von den „Top 100“
Lehrinstitutionen Indiens kommen.

„There will be about 3.000 to 3.500 colleges in this country. [...] We look at the top
100. So we have narrowed down to a list of 100 colleges that we want to target.“ (NI16)

Zudem werden bei NovoProd – wieder im Gegensatz zu den Initiativen der indischen IT-Dienst-
leister, IT-ferne Studienrichtungen als Rekrutierungsmasse zu erschließen – bisher ausschließlich
Absolventen von IT-affinen Engineering-Studiengängen rekrutiert, die zwischen den in Indien ak-
tiven IT-Unternehmen am stärksten umkämpft sind.
174 Fallstudie NovoProd

„So, most of the people working here, be engineers. So, either they will be computer
engineers or software engineers, or they will be engineers from different streams, who
have adopted themselves as software professionals.“ (NI15)

Ein weiterer guter Indikator für die hohen Qualifikationsansprüche ist auch die Tatsache, dass
NovoProd keine Berufsanfänger einstellt. Nach Aussagen eines HR-Mitarbeiters sind 2 Jahre Be-
rufserfahrung Pflicht, um von NovoProd akzeptiert zu werden. Dies sei auch der entscheidende
Grund, warum NovoProd sich nicht an „Campus-Recruitments“ beteilige:

„Because the type of work, that we do, going to campus was not a part of our strategy.
[...] So typically we take people with more than two years of experience.“ (NI15)

Die bei NovoProd interviewten Gesprächspartner haben daher fast alle die ersten Jahre ihrer
Karriere in anderen IT-Unternehmen verbracht. Zum absoluten Großteil handelte es sich dabei um
indische IT-Dienstleister, in denen sie direkt nach ihrem Uni-Abschluß angefangen und die sie dann
nach ein paar Jahren wieder verlassen haben, um eine Beschäftigung bei NovoProd anzutreten.

Trainingsmaßnahmen

Ein Grund für die Rekrutierung von berufserfahreneren Beschäftigten ist, dass NovoProd sich
von Anfang an auf technische Kenntnisse seiner Mitarbeiter verlassen möchte. Die ersten Jahre
verbringen Beschäftigte bei indischen IT-Dienstleistern – wie am Beispiel von ServiceTec gezeigt
werden konnte – in erster Linie im Bereich der technischen Umsetzung, häufig mit wechselnden
Gegenständen und unterschiedlichen Technologien. Daher haben die bei NovoProd eingestellten
Beschäftigten eine breite technische Ausbildung und auch erste Programmiererfahrungen gesam-
melt, auf die NovoProd aufbauen kann.
Dementsprechend kurz kann NovoProd das initiale technische Training nach der Einstellung
halten. Zwar gibt es bestimmte Technologien, die aufgrund des Produktcharakters speziell bei No-
voProd eine große Bedeutung haben, und auch einige Methoden sind firmenspezifisch und müs-
sen daher zu Beginn einer Beschäftigung bei NovoProd von allen Beschäftigten neu gelernt wer-
den. Diese Technologien und Methoden lassen sich jedoch mit technischem Grundwissen zügig
lernen. Von den 2,5 bis 3 Monaten, die jeder Beschäftigte nach der Einstellung in einem intia-
len Einführungsprogramm verbringt, entfällt daher nur ein kleiner Teil auf die Vermittlung der
technischen Grundlagen. Vielmehr bemüht sich NovoProd in dem Einführungskurs, den neuen
Beschäftigten die spezifische Unternehmensstruktur und -kultur näherzubringen – eine Schwer-
punktsetzung, die gerade auch vor dem Hintergrund der an die indischen Beschäftigten gestellten
Kommunikations- und Kooperationsanforderungen nachvollziehbar ist.
Ein noch wichtigerer Indikator für die geringe Relevanz der technischen Schulungen nach der
Einstellung ist allerdings die bei Application feststellbare Praxis, die initialen Trainings stark zu
verkürzen. So berichten Gesprächspartner, dass in ihrem Falle das initiale Training von knapp drei
Monaten auf drei bis vier Wochen reduziert wurde.

„Generally, when somebody joins NovoProd, they undergo a training – by default.

[...] But now, what we have done is – we have cut short that training. [...] They go
through basic things like intercultural training, then ... induction program for five
days and plus – maybe overview of NovoProd, technology and what NovoProd do.
[...] Three weeks. In some cases maybe four. Three to four weeks.“ (NI4)
Betriebliche Kontrollstrategien bei NovoProd 175

Statt in zentralen Einführungsprogrammen werden bei Application die neuen Beschäftigten eher
„on-the-job“ im betreffenden Projektteam angelernt. Diese Schulung findet dann meist parallel zur
Arbeit in Form von kurzen sogen. „Knowledge-Transfer Sessions“ statt, die von anderen Kollegen
durchgeführt werden. Unter „Knowledge-Transfer Sessions“ sind weitgehend informelle eins zu
eins Treffen zwischen dem neuen und einem in einem speziellen Feld sehr erfahrenen Kollegen
zu verstehen, die meist in Form von kleinen Präsentationen abgehalten werden (vgl. NI 4). Inhalt
ist weniger technisches Grundlagenwissen; vielmehr führen die erfahreneren Kollegen die neuen
Teammitglieder in die für das Produkt spezifische Anwendung bestimmter Technologien, die De-
tails der Produktarchitektur und das technische Design ein.
Der Grund für dieses Vorgehen liegt zum einen, wie erwähnt, darin, dass mit der Einstellung
von berufserfahrenen Bewerbern bereits solide technische Grundkenntnisse vorausgesetzt werden
können, zum anderen aber auch in der Art des bei NovoProd benötigten Wissens. Zwar ist das
Wissen um bestimmte Programmiersprachen und technische Konzepte auch für die Arbeit bei
NovoProd unerlässlich – schließlich wird letzten Endes ein Softwareprodukt entwickelt. Jedoch
ist dies nach Aussagen der Gesprächspartner für die Arbeit innerhalb von Application nur ein klei-
ner Teil des erforderlichen Wissens. Wesentlich entscheidender – und erfolgskritischer – sei das
Wissen um die Geschichte, die spezifische technische Architektur und das Design des zu entwi-
ckelnden Produkts. Dieses Wissen sei aufgrund des innovativen Charakters des zu entwickelnden
Produkts jedoch nicht in Form von zentralisierten Einführungskursen zu vermitteln, da entspre-
chende Dokumentationen nicht im voraus verfügbar seien, sondern eher parallel zur Entwicklung
selbst erarbeitet werden, wie ein fachlicher Leiter ausführt:

„Because ours is a new product – so everything is built from scratch. So, when we
started off, there was no training material as such. Because we are building something
from scratch, there can’t be training material. So, what has happened is: over a period
of time, we have learned by ourselves all the stuff.“ (NI28)

Die Aussage des zitierten Gesprächspartners verweist auf den bereits ausführlich behandelten
Charakter der Arbeit bei NovoProd. Es geht bei NovoProd nicht nur um die technische Umset-
zung vorgegebener Spezifikationen, sondern die Arbeitsaufgaben der Entwickler enthalten auch
ganz wesentlich Design- und Planungsaufgaben. Zudem handelt es sich um die Entwicklung eines
neuen Produktes, daher liegen gerade zu Beginn der Entwicklung noch keine Dokumente oder
ähnliches vor, an denen sich Trainingsmaßnahmen orientieren könnten. Dementsprechend ist bei
NovoProd auch das persönliche Erfahrungswissen von größerer Bedeutung für die Beschäftigten
als das Wissen um die technischen Grundlagen, wie der folgende Interviewpartner bestätigt:

„Man merkt einfach, man kann ja viel in training, trainings, eh, investieren, und die
Leute zu dem Training schicken und hierhin schicken und extra einen Trainer aus
Deutschland und so weiter und so fort, aber das ersetzt niemals Erfahrung, das ersetzt
niemals Erfahrung. Die Leute müssen Erfahrung machen, eh, und das ist was, wo
man merkt, da fehlts noch. Das kommt jetzt mit der Zeit, und das hilft auch, dass
wir hier eben sehr viele Teams vorfinden, wo die Leute schon Erfahrung haben, und
wir uns dann einfach mit denen zusammensetzen können, die reviewen unser coding,
eh, geben Hilfestellung, Ratschläge und so weiter, das hilft enorm, aber Erfahrung ist
was, was jetzt momentan noch fehlt, das stimmt, dass ein neues Team halt aufgebaut
worden ist. Ich hatte ein paar erfahrene Leute bekommen, die intern gewechselt sind
von anderen Teams, eh, macht sich schon bemerkbar, wenn jemand schon einfach ein
176 Fallstudie NovoProd

paar Jahre im Unternehmen ist, selbst wenn er mit der Technologie jetzt unmittelbar
nichts zu tun hatte.“ (NI1)

Dieses Erfahrungswissen könne demnach nicht zentral vermittelt, sondern müsse über „learning
on-the-job“ angeeignet werden. Das ist nach Aussage der im Folgenden zitierten HR-Managerin
auch der Grund, warum NovoProd eher auf arbeitsbegleitende Einführungen durch die unmittel-
baren Kollegen als auf zentralisierte Schulungsmaßnahmen zu Beginn der Beschäftigung setzt:

„Aber auf der inhaltlichen Seite ist es schwer, die Leute weiter zu entwickeln, denn ich
kann Leuten, die an einem Standardprodukt arbeiten, wenn die auch von der Uni kom-
men, die können die ganzen Module lernen, es gibt Kurse zur Programmierung. Auch
da gibt’s... Wir haben ein innovatives Produkt: Da gibt es gar nichts, was ich trainieren
kann bei Innovationen, sondern ich bin eigentlich gezwungen, Dinge auszuprobieren.
Ich kann mir dann bei „User Interface Design“ schon Hilfe holen von zentralen Or-
ganisationen. Da gibt es Kurse, die heißen „Design Innovation“, wo Stabsabteilungen
sagen, wie man eigentlich vorgehen sollte, um Screens zu designen. Aber letzten Endes
ist das learning by doing.“ (ND3 – Hervorhebung des Verfassers)

Zwar kann bei NovoProd so die Zeit des initialen Trainings reduziert werden, weil zum einen
technische Kenntnisse durch Einstellung berufserfahrener Personen vorausgesetzt werden können
und zum anderen die wichtigen Trainings eher parallel zum Arbeitsablauf „on-the-job“ erfolgen,
doch dies bedeutet keinesfalls, dass die Beschäftigten schnell in die Projekte zu integrieren seien. Bis
sie zum eigenständigen Arbeiten innerhalb des Teams befähigt sind, dauert es – wieder im Vergleich
zu ServiceTec – eine eher lange Zeit. So berichten Projektmanager, dass Beschäftigte, die neu in
das Projektteam kommen, zwischen 3 und 6 Monate brauchen, bis sie die nötige Selbständigkeit
erreicht hätten, um ihre Arbeitsaufgaben weitgehend eigenverantwortlich zu erledigen (vgl. u.a.
NI5, NI24).
Dieser lange Zeitraum erklärt sich einerseits aus der Komplexität des Produktes und des damit
zusammenhängenden technischen Designs, andererseits aber auch daraus, dass für ein eigenstän-
diges Arbeiten bei NovoProd nicht nur individuelle Kenntnisse und Erfahrungen wichtig sind,
sondern auch die Etablierung von sozialen Netzwerken – gerade zu Beschäftigten an anderen
Standorten – die Arbeitsproduktivität und die Fähigkeit, die eigenen Arbeitspakete erfolgreich
zu bearbeiten, maßgeblich beeinflußt (vgl. 6.3.3). Die Etablierung dieser (persönlichen) Kontakte
braucht Zeit, auch dies trägt zu der langen Einarbeitungszeit bei, gerade wenn (wie gegenwärtig bei
NovoProd zu beobachten) der direkte persönliche Kontakt zu den Kollegen an anderen Standorten
durch die Reduzierung des Reisebudgets erschwert wird.

Umgang mit Personalfluktuation

Grundsätzlich kann daher konstatiert werden, dass (aufgrund des für die Arbeit bei NovoProd
nötigen spezifischen Wissens und der sozialen Netzwerke) einzelne Beschäftigte nur unter großem
Zeit- und Ressourceneinsatz ersetzbar sind. Verlässt ein Entwickler ein Projektteam, so bedeutet
dies ein großes Problem, wie ein Qualitätsbeauftragte verdeutlicht:

„We are a bit more resource intense, you know. Because along with the person, he
carries with him a lot of skill sets – skill sets of course, we can train the other person,
yes. But he ... would carry a lot of information about the project and also his relati-
onships, right? Because he would have already built a lot of rapport with the German
Betriebliche Kontrollstrategien bei NovoProd 177

counterparts, eh. If this is the issue, whom to contact? And that is something, which
he must have learned after several librations. So that’s the real key, which is very dif-
ficult. So we get a new person, probably we can train him. But then, to really work
within the team and really get to understand the team dynamics, understand, whom
to approach what, and what to do in this sort of a situation, that’s – that’s the thing,
which will probably take time. [...] Even if we bring a new person on board, he will
be technically well-equipped, fine! But for each and every small issue, the manager has
to really step in. Because you’ll say: ’Oooh, with this issue, I’ll probably contact this
person and get the work done from him’. That’s where the manager will be pushed in
to the greatest extent, so he wouldn’t get enough time for himself – but that’s the real
issue.“ (NI5)

Aus dieser Abhängigkeit NovoProds von den individuellen Wissens- und Erfahrungsbeständen
seiner Beschäftigten und deren damit einhergehender schwieriger Ersetzbarkeit, erklärt sich auch,
dass die Vermeidung von Fluktuation bei NovoProd größte Priorität genießt. Es konnte bereits
in den vorhergehenden Abschnitten gezeigt werden, dass die strategische Zielstruktur NovoProds
bisher nur in jenen Teams weitgehend umgesetzt werden konnte, in denen die Zusammensetzung
über die Zeit stabil geblieben ist. In den Teams hingegen, die mit verstärkter Personalfluktuation
zu kämpfen hatten, muss auf wesentlich restriktivere Elemente der Arbeitskontrolle zurückgegrif-
fen werden, als eigentlich beabsichtigt ist. So müssen Arbeitsaufgaben vom jeweiligen Vorgesetzten
aufwändiger spezifiziert und definiert und ihre Bearbeitung engmaschiger überwacht und angewie-
sen werden. Zudem müssen die deutschen Brückenköpfe in diesen Teams stärker Vermittlungsauf-
gaben übernehmen, weil sich die persönlichen Kontakte zu deutschen Counterparts nur langsam
entwickeln.
Betrachtet man die von der Firma bereitgestellten Angaben zu den aktuellen Fluktuationsraten,
so fällt auf, dass NovoProd im Vergleich zu ServiceTec noch immer eher moderat von Fluktuation
betroffen zu sein scheint. Der interviewte HR-Mitarbeiter gibt für das gesamte indische Entwick-
lungszentrum eine durchschnittliche aktuelle Fluktuationsrate von knapp 9 % an. In der in dieser
Studie untersuchten Abteilung Application ist diese Rate noch geringer und wird von ihm mit ca.
7,5% veranschlagt (NI15).

Der Befund, dass NovoProd als Hersteller von Standardprodukten mit weniger Fluktuation
konfrontiert ist, überrascht vor dem Hintergrund anderer Studien zunächst nicht. So argumen-
tieren z.B. Upadhya und Vasavi (2006), dass einer der wichtigsten Günde, warum Beschäftigte
„ihre“ Firma verlassen, die Suche nach anspruchsvolleren Tätigkeiten ist. Lacity, Rudramuniyaiah
und Iyer (2008) schreiben sogar, dass die Suche nach anspruchsvoller Arbeit der wichtigste Grund
für Personalfluktuation in Indien ist. Die multinationalen Standardsoftware-Hersteller stehen da-
bei in dem Ruf, in ihren indischen Entwicklungszentren im Vergleich zu den meist indischen
IT-Dienstleistungsunternehmen die anspruchsvollste und befriedigendste Arbeit anzubieten und
zudem meist großes Renomee für ihre weltweit bekannten Marken zu besitzen (vgl. Upadhya und
Vasavi 2006, S. 50ff.), weshalb Beschäftigte seltener diese Unternehmen verlassen würden.
Diese Befunde werden durch das bei NovoProd erhobene Material bestätigt. Nach den Grün-
den gefragt, warum sie von ihrer vorherigen Firma zu NovoProd gewechselt sind, geben viele
Interviewpartner an, gezielt nach einem Produkthersteller gesucht zu haben (z.B. NI3, NI6, NI14,
NI24, NI28). Als Grund für diese Präferenz wird meist einer oder mehrere der vier folgenden
Aspekte angeführt:
178 Fallstudie NovoProd

Erstens geht die Tatsache, dass NovoProd Produkte herstellt und keine Services für externe
Kunden anbietet, für die Beschäftigten mit der Erwartung (und in der Mehrzahl der Fälle auch
mit der realen Erfahrung) einher, dass die Arbeitszeiten in Produktfirmen moderater sind, weil
man sich nicht über Zeitzonen hinweg an die Arbeitszeiten von Kunden anpassen müsse. In einer
Produktfirma würden eigene Planungen gemacht, und man müsse sich nicht den Forderungen
der Kunden beugen, die meist einen starken Zeit- und Arbeitsdruck aufbauen würden, wie der
folgende Entwickler, der von ServiceTec zu NovoProd gewechselt ist, berichtet:

„Main difference, I would say, is – it’s like, NovoProd being a product company, its
pressure is relatively less than we had at ServiceTec. And, it actually results in a better
work balance at NovoProd as compared to ServiceTec. [...] It’s like, I have a little
more time for myself and friends than I had in ServiceTec. [...] Actually, yeah – the
work pressure, which makes you work late or ... Because in a product company you
have your own deadlines. In a service company you have deadlines, set by the client.“
(NI23)

Tatsächlich wird NovoProd von vielen der interviewten Gesprächspartner eine gute und eher
gleichmäßige Verteilung der Arbeitszeiten attestiert, wie beispielhaft der folgende Entwickler aus-
führt:

„I think, [...] in service industries it gets too hectic at one point in time, that is, when
you are trying to deliver a product or an application. And then the remaining point
of time, it’s like, you are sitting idle, this is – I think, that balanced work is somehow
missing in service based companies.“ (NI3)

Zweitens wird von den Gesprächspartnern in Bezug auf eine Beschäftigung bei einer Produktfir-
ma positiv hervorgehoben, dass hier an einer „globalen Lösung“ gearbeitet wird, die anschließend
von vielen Leuten oder Unternehmen genutzt wird. Dies steht in deutlichem Kontrast zu dem den
Sericefirmen zugeschriebenen eher partikularen Fokus, der sich nur auf einzelne Kunden richte:

„And also, I think, the approach, that the product based companies follow, I think,
is somewhat different than a service based companies, because, I mean, in a product
based, you want to make a product that is applicable to everyone. But in service based
you are told only for that person – and there is a difference. [...] When you want to do
something, you want to do something that helps everyone to find a global solution.
And then want to give the same kind of solution to different people in different ways.
And this is more appealing to me.“ (NI3)

Der dritte Grund, eine Anstellung bei NovoProd anzustreben, ist der Markenname von Novo-
Prod. IT-Dienstleister arbeiten meist im Hintergrund großer Kundenunternehmen und erledigen
unterstützende Aufträge für diese. Zwar gibt es auch renommierte Dienstleistungsunternehmen,
jedoch sind diese eher für ihre Beratungsleistung bekannt, wie z.B. IBM oder Accenture. Produkt-
firmen hingegen, gerade jene großen multinationalen Standardsoftwarehersteller wie NovoProd,
sind meist berühmt für einzelne Produkte und werden mit diesen auch assoziiert. Man denke z.B.
an die allgegenwärtige Bürosoftware von Microsoft. Teil eines solchen Unternehmens zu sein, wird
von den Beschäftigten schon als Vorteil empfunden, der sich angeblich auch sehr gut im eigenen
Lebenslauf ausnehme, wie der beispielhaft im Folgenden zitierte Projektmanager erklärt:
Betriebliche Kontrollstrategien bei NovoProd 179

„NovoProd was a better company at that [time]. Since also they have a brand value.
And my former company was still a small company. Even though it went public, it was
still a small company. And then I got an offer from NovoProd, which, I thought, pro-
bably makes much more bra ... it also adds brand value to the overall ... your bio-data
– it looks good [lachend]. And also [...] I thought, NovoProd product development
would also add much more value, it gives much more exposure to me.“ (NI7)

Der wichtigste – vierte – Grund für eine Beschäftigung bei NovoProd scheint nach Lage der
Interviews jedoch – und damit werden die Ergebnisse von Upadhya und Vasavi (2006) und Laci-
ty, Rudramuniyaiah und Iyer (2008) bestätigt – die Qualität der angebotenen Arbeit zu sein. Die
Beschäftigten erwarten, in der Produktentwicklung mit den neuesten Technologien und Metho-
dologien arbeiten zu können, wohingegen Angestellt von Dienstleistungsunternehmen häufig mit
älteren Technologien umgehen müssen, weil die Kunden alte Systeme wie z.B. Mainframes oder
Cobol-Programme benutzen.

„Why do they join? They join, because people would like to work in a product com-
pany. There are multiple reasons. First of all, the kind of work that you do in a service
company – if you are working in a mainframe, Cobol – it’s not interesting! I mean,
this doesn’t help much after two years, three years in your career. So they look for a
shift.“ (NI6)

Darüberhinaus wird der langfristige Ansatz von Produktfirmen geschätzt, der es ermögliche,
sich vertieft mit bestimmten Problemlösungen zu beschäftigen und spezialisiertes Wissen aufzu-
bauen. Als Entwickler von betriebswirtschaftlicher Standardsoftware bietet NovoProd Beschäftig-
ten zudem die Möglichkeit, über den rein technischen Bereich hinaus wertvolle fachliche Kenntnis-
se zu gewinnen, die als besonders wichtig für ihre weitere Karriere gelten, wie folgender Manager
erläutert:

„Was ich auch in den Interviews mit den Kollegen, die ich hier eingestellt habe, oft-
mals festgestellt hab, dass die einfach nach einer gewissen Zeit auch an einem Produkt
einfach arbeiten wollen. Dass sie nicht einfach irgendwie was implementieren wol-
len, oder irgendwie jetzt auf Kundenanforderungen hin eine Spezialentwicklung ma-
chen wollen, sondern dass sie wirklich auch mal für einen langen Zeitraum einfach am
Produkt mitarbeiten wollen. Und auch wirklich neueste Technologien kennen lernen
wollen, auch Zeit haben wollen, sich da einzuarbeiten, auch Wissen haben wollen, was
Geschäftsprozesse anbelangt.“ (NI1)

So ist NovoProd also aufgrund ihres Verlagerungsmodells, der Art der angebotenen Arbeit und
ihres Firmennamens ein sehr attraktiver Arbeitgeber. Dies erklärt die starke Nachfrage nach den
von NovoProd ausgeschriebenen Stellen, und es sind diese Eigenschaften, die NovoProd in dem
Bemühen betont, die Beschäftigen langfristig im Unternehmen und damit die Fluktuationsraten
niedrig zu halten.

War es für ServiceTec charakterisitisch, der Fluktuation vor allem mit positiven Anreizen in den
Bereichen Karriere, Gehalt, Postings oder Arbeitsumfeld zu begegnen, versucht NovoProd gezielt
über den arbeitsinhaltlichen und -organisatorischen Bereich, Beschäftigte von einem Jobwechsel
abzuhalten. Ein für Application verantwortlicher Vertreter des höheren Managements bringt im
Folgenden die bereits ausführlich geschilderte Form der standortübergreifenden, internationalen
180 Fallstudie NovoProd

Kooperationsstrukturen bei NovoProd explizit in einen engen Zusammenhang mit den Bemühun-
gen, die Fluktuationsraten zu senken:
„Wir machen’s eher tief integriert [...] und wir fahren eigentlich eine Integration auf
Entwickler-Level, also die Entwickler kennen sich untereinander. [...] Also das ist ei-
ne ganz andere Art und Weise der Zusammenarbeit. Ich würd mal sagen, dass ein
großer Teil unserer Projekte so gemanaged wird und nur ein geringer Teil so ist, dass
da nur 2 Leute miteinander kommunizieren. Das geht natürlich, bei so einem Ding
[„Standardansatz des Offshoring“ – PF, vgl. auch Abschnitt 6.2, S. 124] brauch ich
das nicht. Die kommen nie raus, die sitzen da und machen nur Spezifikationen. Aber
die Frage ist natürlich: Ist das langfristig ein Modell, das funktioniert, weil die Job-
Zufriedenheit ist schon auch gering. Alle wollen gern die Position haben, und wenn
man dann hier nicht durchstößt, dann gehen die Leute. Und zwar sehr schnell. Das
jetzt nur als Grundzusammenhang zu dem Thema.“ (ND1)
Der vom Gesprächspartner erläuterte „Grundzusammenhang“ zwischen Fluktuation und Ar-
beitsorganisation enthält bereits den Kern der strategischen Bemühungen NovoProds zur Vermei-
dung von Fluktuation. Anstatt die Arbeitsprozesse gegen Fluktuation zu immunisieren und sie da-
mit von den einzelnen Beschäftigten so unabhängig wie möglich zu machen, steht bei NovoProd
eher die Erhöhung der Job-Zufriedenheit der Entwickler im Vordergrund, die bei der strategi-
schen Planung der Aufgabenorganisation im indischen Entwicklungszentrum mitreflektiert wird.
Dieses Vorgehen scheint erfolgreich zu sein: Dass NovoProd bei der Organisation der Arbeitspro-
zesse großen Wert auf Selbstorganisationsfähigkeiten legt und Angestellten für die Bearbeitung
ihrer Arbeitsaufgaben soviel freie Hand gibt wie möglich, wird von den Beschäftigten sehr positiv
aufgenommen, wie beispielhaft folgender Personalmanager bemerkt:
„Because, as I told you: the thing was the kind of independence and the kind of respon-
sibility that was given to people in NovoProd. [...] And that’s the one reason which
made me ... stay in NovoProd for such a long time. So I still don’t think this kind of
culture exists outside.“ (NI25)
Ein Entwickler bestätigt diese Annahme:
„The first thing was, that every individual is given a lot of responsibility for what they
do. That’s one thing, that I always looked for, because I feel, if somebody is holding me
by the finger and telling me, to do this, do that, do this, do that, according to his own
requirements, I feel my ability of creativity and innovation is contained. So, that is
something, that’s an environment again, that I prefer not working under, eh, so which
is, why I feel, NovoProd is far better than any other organization, that I have heard
of at least, because an individual is given total responsibility for his work piece and
he does, what he feels with it and he is answerable also for anything, that goes wrong
with it, which is fair enough.“ (NI21)
So finden sich unter den bei NovoProd interviewten Gesprächpartnern viele, die durchaus eine
langfristige Perspektive im Unternehmen sehen und dies explizit auf die Zufriedenheit mit ihren
Arbeitspaketen zurückführen:
„I have seen that, at least in NovoProd, people tend to fall in love with the work,
because of the lot of challenges in the work. Not directly related only to technology,
but also functional and understanding the needs of the customer.“ (NI25)
Betriebliche Kontrollstrategien bei NovoProd 181

Ein anderer Gesprächspartner, antwortet auf die Frage, ob er sich in 5 Jahren immer noch bei
NovoProd sehe:

„100%. [...] No, seriously! I mean, it’s like, I am appreciating my work currently, I am
enjoying it. I have this job satisfaction. That is enough for me.“ (NI14)

NovoProd setzt also strategisch auf eher arbeitsinhaltliche und -organisatorische Anreize, um
die Beschäftigten im Unternehmen zu halten und scheint angesichts der vergleichsweise niedrigen
Fluktuationsraten mit diesem Ansatz in Indien bisher auch erfolgreich zu sein. Dies bedeutet je-
doch nicht, dass der indische Arbeitsmarkt für NovoProd damit keine Herausforderung mehr sei
oder sich die Fluktuation ausschließlich über arbeitsinhaltliche Anreize kontrollieren liesse.

Die Fluktuation bleibt schon deshalb ein Dauerthema, weil 9% (bzw. 7,5% bei Application)
Fluktuation für NovoProd aufgrund der starken Abhängigkeit der Arbeitsprozesse von den indi-
viduellen Wissens- und Erfahrungsbeständen der Beschäftigten immer noch eine „bösartig hohe
Zahl“ (ND6) ist. Der Einfluß der Fluktuation auf die strategische Zielstruktur NovoProds, vor al-
lem im Bereich der Aufgabenorganisation und Kooperationsbeziehungen, wurde bereits erwähnt.
Auch die Tatsache, dass einige Teams mit sehr viel höheren Fluktuationsraten zu kämpfen haben,
verstärkt die Gefahr, die von diesen – für indische Verhältnisse moderaten – Fluktuationsraten für
NovoProd ausgeht. Zudem muss auch für NovoProd berücksichtigt werden, dass sich die Fluk-
tuation schwerpunktmäßig auf die Gruppe der Beschäftigten konzentriert, die bis zu 3 Jahre im
Unternehmen sind, so dass für die Stufe der Entwickler erwartet werden kann, dass die Raten noch
einmal deutlich über den 9, bzw. 7,5% liegen (ND6).
Desweiteren kommt zum Tragen, dass die Suche nach anspruchsvoller Arbeit zwar ein wichti-
ger – möglicherweise der wichtigste – Grund ist, aus dem indische IT-Beschäftigte häufig die Un-
ternehmen wechseln, aber keinesfalls der einzige. Wie in Kapitel 3 argumentiert wurde, befähigt
der indische Arbeitsmarkt die Beschäftigten, anspruchsvolle Arbeit und günstige Beschäftigungs-
verhältnisse (in Form von schnellen Karrieren und hohen Gehältern) zu fordern. Und gerade diese
beiden Bereiche sind bei NovoProd durchaus problematisch.
In seiner deutschen Firmenzentrale setzt NovoProd traditionell auf flache Hierarchien, Beför-
derungen sind dementsprechend selten. Viele deutsche Beschäftigte bei NovoProd dauerhaft Ent-
wickler und sehen darin auch kein Problem, weil ihre Erfahrung im Unternehmen und in ihrem
Fachbereich sich zwar nicht in neuen Titeln, wohl aber in der Art der ihnen anvertrauten Arbeiten
widerspiegelt, was für sie wesentlich wichtiger ist als die genaue Jobbezeichnung, wie ein Manager
ausführt:

„Wir haben in Deutschland trotzdem den Entwickler, und Entwickler wird eigent-
lich ziemlich lange getragen. Weil letzten Endes, sagen wir mal, ein Entwickler, der
jetzt erfahrener ist, der kriegt automatisch einfach mehr verantwortliche Tätigkeiten,
die dann in Richtung Architektur gehen, die dann in Richtung Projektmanagement
gehen. Der hat eigentlich automatisch, mehr oder weniger nach einer gewissen Zeit –
vorausgesetzt die Fähigkeiten sind eben da – hat der automatisch diese Verantwortlich-
keiten. [...] Es ist eben nur, es hängt nur nicht an einer bestimmten Position eben.“
(NI1)

Dabei setzt NovoProd in Deutschland darauf, dass die Beschäftigten in erster Linie arbeitsinhalt-
lich motiviert sind und daher nichts anderes sein wollen als Entwickler, also gerade nicht anstreben,
Manager mit Personalverantwortung zu werden:
182 Fallstudie NovoProd

„Ich habe viele Kollegen, die sind seit 14 Jahren Entwickler. [...] So und da gibt’s ein
paar Development Architekten, die sehen diese Auszeichnung, dass sie Development
Architect sind, als: ich möchte nie Manager sein. Für die kommt Manager ganz weit
hinter Architekt, sag ich jetzt mal ganz einfach, weil die haben nämlich keine Ahnung
- die Manager. Das ist die Übersetzung von Manager bei den Kollegen. Und da haben
sie auch nicht ganz unrecht, fachlich gesehen.“ (NI6)

NovoProd versucht nun, diesen Umgang mit Befördeungen auch im indischen Entwicklungs-
zentrum zu praktizieren, weil befürchtet wird, dass grundsätzlich unterschiedliche Vorgehenswei-
sen in Bezug auf Titel und die Taktung der Beförderungen zu Verwerfungen innerhalb der Pro-
jektteams führen könnten, was die Kooperation zwischen den beteiligten Standorten erschweren
könnte:

„Wir versuchen, sehr transparent die gleichen Wertmaßstäbe anzulegen. [...] Sie müs-
sen, wenn Sie eine globale Firma haben, versuchen, einen globalen Level zu haben,
weil sonst kriegen Sie eine Diskrepanz in die Firma, die nicht funktioniert. Sonst
kommt irgendwann die Situation: ich bin aber deutscher Projektleiter. Und ich glaube,
das widerspricht dann all dem, was wir persönlich hören wollen. Das hatte ich mal -
dann kriegen wir eine Farbe rein, die nicht gut ist.“ (NI6 – Hervorhebung durch den
Gesprächspartner)

Nun sind aber solch langsame Karrieren – hier als zeitliche Taktung der formellen Beförde-
rungen verstanden – am indischen Standort nicht einfach durchzusetzen. Die arbeitsinhaltliche
Motivation mag auch bei den indischen Beschäftigten sehr wichtig sein, doch sie sind auch an for-
mellen Beförderungen interessiert, und wissen, dass sie diese durch einen Wechsel der Firma häufig
bekommen können. Diese Erwartung ist nach Aussagen der interviewten Projektmanager in den
indischen Teams durchaus präsent, wie der folgende Gesprächspartner kurz und bündig auf den
Punkt bringt:

„If you don’t promote them – they will leave and go.“ (NI27)

Daher steht NovoProd in Bezug auf ihre Beförderungspolitik im indischen Entwicklungszen-

trum unter starkem Druck. Die Erwartungen der Beschäftigten in Bezug auf Häufigkeit und Ge-
schwindigkeit von Beförderungen werden vor allem von den (die indische IT-Industrie dominie-
renden) IT-Dienstleistungsunternehmen geprägt, doch NovoProd kann diesen Erwartungen als
Produktfirma nicht gerecht werden, wie ein Personalmanager erklärt:

„Most of the companies follow the same principle. I mean, people forget, that we are in
a product company and not in a services company. Because in services company, you
move from project to project, right? So, if the number of projects grows, then there can
be more project managers, right? If the project is big, then I can have couple of module
leads or small leads, right? But in product, I know, that my module within Application
will be 30 people only. Right? So, I cannot make all of them lead. Yeah. And then,
what happens, because of this reason, there is a lot of attrition, which happens. Say,
if a person doesn’t get promoted after three years or three and a half years – then he
tends to leave. Right? Because somebody is giving him a lead position somewhere. He
will surely get, because there is a lot of demand in India. So he’ll surely get a better pay
and that lead position somewhere else – so he will move out.“ (NI4)
Betriebliche Kontrollstrategien bei NovoProd 183

Der hier angesprochene „Vorteil“ der IT-Dienstleistungsunternehmen konnte bei ServiceTec gut
verdeutlicht werden. Das Wachstum des Unternehmens beruht vor allem auf der zunehmenden
Zahl der Kundenprojekte, und es ging mit einer ebenfalls rapide steigenden Zahl von nötigen Füh-
rungspositionen (Projekt- und Modulleiter) einher. So stellte es bei ServiceTec kein Problem dar,
einen einigermaßen regelmäßigen Beförderungszeitraum von ca. 3 Jahren einzuhalten. Bei No-
voProd ist die Situation jedoch anders. Die Größe der an der Entwicklung beteiligten Abteilung
bis zur Fertigstellung des neuen Produkts weitgehend unverändert. Dies bedeutet, dass im Laufe
der Entwicklung bei NovoProd nur wenige Führungspositionen neu zu besetzen sind, auf die Be-
schäftigte befördert werden könnten. Daher kann NovoProd mit den kurzen Zeiträumen und den
Häufigkeiten der Beförderungen vor allem der IT-Dienstleister nicht mithalten:

„Ein Inder, der bei NovoProd ist, [...] der muss [...] nach drei Jahren sagen können,
dass er Manager ist. [...] Das ist erst mal ein Faktum. Und NovoProd tickt genau so
nicht.“ (NI6)

Auch eine Mitarbeiterin der HR-Abteilung konstatiert, „dass NovoProd nicht soweit wie z.B.
indische Firmen [ist], was die Titel anbelangt.“ (NI 3). Wenn daher Beschäftigte von NovoProd
in ihren Freundeskreisen ihre Karrieren vergleichen, bleiben sie gegenüber ihren Freunden, die in
anderen Unternehmen arbeiten und häufiger befördert werden, schnell zurück. Der daraus entste-
hende Gruppendruck führt auch bei dem im Folgenden zitierten Entwickler zu Unzufriedenheit:

„Because I have my friends in different service companies. So it does also have to do

with peer pressure. I mean, when you say that every two years or three years, they’re
getting promoted. And then you feel: ’what are you doing here?’ Yeah, I mean: Work
is fine, but then, as I said – there is, like, different aspects.“ (NI7)

Nach Lage der Interviews gibt es bisher noch keine kohärente Strategie bei NovoProd, mit die-
sem Problem organisatorisch umzugehen. Vielmehr changieren die von den verantwortlichen Per-
sonalmanagern ergriffenen Maßnahmen zwischen verschiedenen Ansätzen.

So wird zunächst versucht, die Beschäftigten im indischen Entwicklungszentrum an die in Deutsch-

land übliche Vorgehensweise zu gewöhnen. Indem man ihnen diese vorlebt, hofft man die Beför-
derungswünsche zu dämpfen, ohne Unzufriedenheit zu erzeugen:

„Das ist aber eine Wertevorstellung, die wir in NovoProd über die 70er, 80er und
90er Jahre gepflegt haben, die auch eine gewisse Kultur in unser Arbeitsschema reinge-
bracht hat, die wir nicht exportieren können. Ganz schwer. Sie können das den Leuten
vorleben, die Leute können bemerken, dass sie noch so sehr Development Manager
sein können, dass es ziemlich egal ist, was sie sagen, solange der Architekt da hinten
nicht genickt hat. [...] Dann merken sie sich vielleicht, dass letztendlich die fachliche
Kompetenz das meist entscheidende ist hier bei NovoProd – in der Entwicklung zu-
mindest – in diesem Inner Circle.“ (NI6)

Ferner finden sich aber auch Ansätze, die darauf abzielen, schnelle Beförderungen zu „simulie-
ren“.Entgegen der vom Management formulierten Strategie, als globales Unternehmen auch global
einheitliche Strukturen und Hierarchiestufen zu etablieren, werden im indischen Entwicklungs-
zentrum doch einige Titel vergeben, die es so im deutschen Hauptquartier nicht gibt, wie z.B.
184 Fallstudie NovoProd

einen „Junior“- oder „Platinum“- Developer (zusätzlich zum mittlerweile auch im deutschen Mut-
terhaus eingeführten „Senior“-Developer; NI 7), als weitere Ausdifferenzierungen der Entwick-
lerebene. Auch die in Indien vorfindliche Position des fachlichen Leiters gibt es in der deutschen
Firmenzentrale so nicht (NI 1). Mit diesen neuen Titeln gehen praktisch keine Unterschiede in
der Verantwortung oder Funktion im Projektablauf einher (die Ausnahme ist der fachliche Leiter,
der ein leicht anderes Rollenprofil aufweist als ein „einfacher“ Entwickler). Sie bieten NovoProd
aber die Möglichkeit, formal häufiger befördern zu können und damit das Bedürfnis nach neuen
Titeln bei den indischen Beschäftigten zu befriedigen. In dieselbe Richtung gehen auch Versuche,
Beförderungswünschen durch kleine Belohnungen, Pokale oder ähnliche Elemente symbolischer
Anerkennung zu begegnen:

„Also es gibt wohl irgendwelche „Trophies“ und dann Dinge in Richtung „Employee
of the Month“. Das sind jetzt nicht die Titel, aber wirklich so, dass das die Mitarbeiter,
dass ihnen gezeigt wird, ok, sie sind wichtig. Es gibt Pokale, die dann auch wieder den
Rang zeigen. Das heißt, man ist zwar noch nicht formal auf der Management-Stufe,
aber man hat drei Pokale vor sich stehen und dadurch zeigt man eigentlich, dass man
wichtig ist, oder sehr gute Arbeit leistet.“ (ND3)

Zudem kann trotz aller Beteuerung von „globalen Standards“ konstatiert werden, dass Novo-
Prod beim Takt der Beförderungen in Indien Kompromisse eingeht und – sofern Positionen vor-
handen sind – wesentlich schneller befördert, als es im deutschen Mutterhaus üblich ist, so dass
Beschäftigte mit wesentlich weniger Erfahrung in höhere Positionen aufsteigen als ihre deutschen
Counterparts. Obwohl NovoProd nach Aussagen des höheren Managements durch ihre „globa-
len Standards“ gerade diese Ungleichheiten innerhalb der Projektteams zu vermeiden sucht, wird
dieses Thema damit zwischen dem deutschen und dem indischen Teamteil relevant und sorgt für
Unzufriedenheit bei den Beschäftigten beider Seiten.
Auf der deutschen Seite fühlen sich Beschäftigte übergangen, wenn ein deutscher Entwickler mit
teilweise über 10 Jahren Berufserfahrung einem indischen Projektmanager mit 4 Jahren Berufser-
fahrung gegenübertritt:

„Wir haben einfach das Problem, dass wir in Indien eine Schattenwirtschaft aufbauen.
Da sind die - also eigentlich erwarten wir globale Standards. Aber bei uns in Deutsch-
land, würde ich behaupten, hat ein Senior-Developer einfach mehr Erfahrung und
mehr Wissen angesammelt als in Indien. Kann ja, geht ja auch nicht anders, wenn ich
in Indien in anderthalb Jahren zum Senior-Developer werde, kann ich gar nicht das
Wissen angesammelt haben, was dann einen Schiefstand darstellt, deswegen Schatten-
wirtschaft. Und natürlich bei den deutschen Developern, ja, Unmut auslösen kann.
Wenn die sagen: Ok, ich bin noch Developer und hier, die Leute in Indien sind schon
Manager oder sind auf einer Projektmanager-Ebene.“ (NI3)

Auch wenn diese Haltung in den Interviews an einzelnen Punkten durchschien, ist Neid auf
die indischen Beförderungen bei den deutschen Beschäftigten jedoch nicht dominant. Vielmehr
scheinen die deutschen Beschäftigten ihre indischen Counterparts nicht wirklich ernst zu nehmen,
weil Titeln generell weniger Relevanz zugestehen und auch die indischen Beschäftigten in erster
Linie nach ihrer Berufserfahrung beurteilen, wie die bereits zitierte HR-Beschäftigte vermutet:

„Also es sind einfach andere Bedingungen, und ich denke, dass das Verständnis größ-
tenteils schon da ist. Also auf der emotionalen Ebene sagt man dann: Ok, das ärgert
Betriebliche Kontrollstrategien bei NovoProd 185

mich jetzt, weil ich eben diesen Titel habe. Aber einerseits sind wir in Deutschland
nicht so titelversessen, das heißt, es ist eigentlich auch in Ordnung, wenn ich Devel-
oper bleibe. Da bricht jetzt nicht meine Familie zusammen oder ich werde ausgesto-
ßen. Auf der anderen Seite denke ich auch, kann man das akzeptieren, dass der andere
... Also man sieht es dann, was vielleicht nicht immer gut ist, wirklich als Schatten-
system an, dass man sagt, dass sich ein Deutscher - und das sind jetzt wirklich nur
Vermutungen - dass sich ein deutscher Entwickler sagt: Ok, eigentlich bin ich auf der
Ebene, auf der indische Manager sind, und damit kann ich leben, und das ist einfach
die Bezeichnung.“ (ND3)

Mit dieser Vermutung liegt die HR-Beschäftigte nach Lage der Interviews durchaus richtig, wie
sich in der folgenden Aussage eines Personalmanagers im indischen Entwicklungszentrum deutlich
zeigt:

„Das [sein indischer Counterpart – PF] ist ein Projektmanager light. Also, das war
zumindest meine Erfahrung. Es mag sich jetzt auch mittlerweile ein bisschen geän-
dert haben. Aber, eh, als ich angefangen habe, muss ich für mich persönlich sagen, war
die Erfahrung immer eigentlich: das war ein Projektmanager light – mit der Konse-
quenz, dass die Leute in Deutschland auch nicht so, so ernst genommen werden als
Projektmanager. ... Ist auch klar, eh, wenn man sich die Situation ... Ein Projektmana-
ger in Deutschland hat, ich weiß nicht: 10, 11, 12 Jahre Erfahrung, Berufs-, NovoProd-
Erfahrung, vielleicht sogar 15 Jahre Gesamtberufserfahrung. Auf jeden Fall also Leu-
te, die wirklich wissen, wie man Projekte leitet und die das öfters unter Beweis stellen
mussten, die einfach die Erfahrung haben. Und jetzt kommt hier ein Projektmanager
mit vier Jahren Berufserfahrung. [...] Ich würde es auch nicht ernst nehmen, oder sa-
gen wir mal so: Ich würde mit Sicherheit erst mal offen sein, weil ich von vornherein
nicht jemand bin, der irgendwie Vorurteile da hat oder voreingenommen ist. Aber
ich würde dann dem Ganzen schon kritisch gegenübergestellt sein und würde mir das
auch anschauen. Und würde gucken: Ist es wirklich ein Projektmanager?“ (NI1)

Diese Nicht-Anerkennung der „indischen“ Jobbezeichnungen und Titel durch die deutschen
Beschäftigten wird für die indischen Beschäftigten zum Problem, weil sie sich von ihren deutschen
Counterparts nicht ernst genommen fühlen. Daher beklagen sie häufig die fehlende Anerkennung
und den fehlenden Respekt für ihre Position.
Die Bemühungen NovoProds, dem Wunsch der indischen Beschäftigten nach schnellen Beför-
derungen nachzukommen, war daher zum Zeitpunkt der Untersuchung ein konfliktreiches und
daher auch auf Managementebene stark diskutiertes Thema. Daher erfordert es viel Fingerspitzen-
gefühl der jeweiligen Vorgesetzten, mit den Karriereerwartungen von Beschäftigten angemessen
umzugehen. Die folgende Passage zeigt, welche Kreativität von den Managern in dieser Hinsicht
gefordert ist:

„I mean our team is a mix of girls and guys. So there are five ladies right now in the
team. And three of them are on maternity leave. So that will be, like, a little long
– spanning from three months to nine months. [...] So, these people won’t ask for
promotion, because they are on maternity leave. So they won’t be working for quite
some time this year. [...] Then one of them has been promoted, which has not been
announced as yet. So that takes care of this guy for next two years – at least two years.
[...] So, one guy wanted to work from Germany for a year. So he spoke to VP [Vice
186 Fallstudie NovoProd

President – PF], and VP spoke to his VP, and they got that approved. So, even if
you don’t give a promotion, he is there for two years. Because he was in Germany
for one year. He got, what he wanted. Right? So, without giving him promotion,
you can keep him happy for two years. [...] Ok, one guy wants – I want to maintain
somebody, right? So, if a guy joins my team – I’ll make him his mentor! He is happy
for six months, yeah? Some guy wants to travel abroad, so I’ll speak to my VP, if he
can travel there for two to three weeks. One trip, and he is happy for six months or
one year. These are small things, which we have to take care – and these things work.“
(NI4)

Die zitierte Aussage eines Personalmanager zeigt deutlich, wie unterschiedlichste Anreize ge-
nutzt werden, um die Beschäftigten für ausbleibende Beförderungen zu entschädigen. Wenn sol-
che Entschädigungen nicht verfügbar sind, besteht häufig nur noch die Möglichkeit, Beschäftigte
hinzuhalten:

Other thing is: you have to ... develop these guys through mentoring, coaching, train.
To tell them, that to grow, you need to develop yourself. You need to shoulder extra
responsibility. Right? For the two years, you have been working on something. That
doesn’t give you a lead position. I need to see, that you go out of your way to do
something more than what has been given to you. So convince him that you have not
done enough. ’You have done 100 percent of your work – no doubt. You have been
good in that, right? But you need to go beyond that to deserve the next position! Tell
me, how many people love you: two of your colleagues and two in Germany. Right,
because you have been working just with these two guys and these two guys – four,
that’s all. Have you interacted with the VP directly or VP of some other area directly?
Have you escalated a problem some time? Or have you dealt with escalation some
time? So, these are things, you need to ... move to the next level!’ So, if you talk with
them, you give them practical examples. You sit with them, try to explain your own
position, their position. That they need to do extra to win that position ... So you can
bargain for another year with these guys. [...] I mean, the thing is: I have been through
all of this. So I know, how people behave and what they expect – and how you can set
their expectations right.“ (NI4 – Hervorhebung des Verfassers)

Die Reduzierung von Fluktuation aufgrund enttäuschter Karriereerwartungen der Beschäftig-

ten stellt also für NovoProd nach wie vor ein großes Problem dar, und die zitierte Aussage des
Personalmanagers zeigt, wie bei NovoProd mit ganz unterschiedlichen Ansätzen versucht wird,
dieses Problem anzugehen und die Beschäftigten dadurch in der Firma zu halten.

Ein ganz ähnliches Problem stellt sich für NovoProd in Bezug auf die Entwicklung der Gehälter
im indischen Entwicklungszentrum (siehe Kapitel 3). Auf den ersten Blick scheint der Bereich der
Gehälter bei NovoProd kein Problem zu sein, das Beschäftigte aus dem Unternehmen treibt. Alle
Gesprächspartner, die vorher bei einer indischen Dienstleistungsfirma gearbeitet haben, berichten
von erheblichen Gehaltssteigerungen durch den Eintritt bei NovoProd. Die Rede ist von 25-30%
Zuwachs gegenüber ihrem vorherigen Gehalt.
Die von der HR-Abteilung genannten und durch die Befragung der Entwickler bestätigten Zah-
len zeigen, dass das Grundgehalt auf der Einstiegsebene bei NovoProd mit 42.000 - 52.000 Rupien
( 620-770 Euro) Bruttogehalt über 50% über dem bei ServiceTec liegt. Warum stellt die Gehalts-
entwicklung für NovoProd dann dennoch ein Problem dar?
Betriebliche Kontrollstrategien bei NovoProd 187

Ein wichtiger für finanzielle Unzufriedenheit von Beschäftigten liegt darin, dass NovoProd auf-
grund seines Verlagerungsmodells nur in sehr seltenen Fällen Onsite-Postings vorsieht. Beschäftig-
te im indischen Entwicklungszentrum sind dort eingestellt und sollen auch primär dort arbeiten.
Eine regelmäßige Rotation an Hochlohnstandorte, wie sie bei IT-Dienstleistungsunternehmen auf-
grund des speziellen Kundenkontaktes möglich sind, gibt es bei NovoProd daher nicht. Schließlich
wäre jeder Wechsel eines Beschäftigten aus dem indischen ins deutsche Entwicklungszentrum mit
erheblichen Kostensteigerungen verbunden, da dieser dann zu deutschen Konditionen beschäftigt
werden müsste. So finden sich bei NovoProd zwar viele Beschäftigte, die zum Zweck eines be-
stimmten Trainings oder zum Kennenlernen der deutschen Kollegen eine Zeit lang im deutschen
Entwicklungszentrum gewesen sind, doch dabei handelt es sich vorwiegend um zeitlich auf 3-4
Wochen befristete Aufenthalte. Eine längerfristige Beschäftigung im deutschen Entwicklungzen-
trum oder dem eines anderen Hochlohnstandortes, die finanziell lukrativ wäre, ist hingegen sehr
selten.
Zudem konnte im Abschnitt zur Kontrollstruktur bei NovoProd (Kapitel 6.3.2) gezeigt wer-
den, dass die variable leistungsbezogene Vergütung sich kaum monetär auswirkt. Berücksichtigt
man nun außerdem das Problem der langsamen Beförderungen bei NovoProd, so lässt sich abse-
hen, dass die Gehälter der Entwickler meist relativ langsam wachsen und sich zudem nicht stark
voneinander unterscheiden. Denn wie im deutschen Hauptquartier arbeitet NovoProd auch im
indischen Entwicklungszentrum mit (für jede Position) festgelegten Gehaltsbändern. Bei der Ein-
stellung werden Entwickler (dies ist die Haupteintrittsposition bei NovoProd) in Abhängigkeit
von ihrer relevanten Berufserfahrung in ein Gehaltsband eingeteilt, das ihr Grundgehalt bestimmt.
In den Gehaltsverhandlungen kann der zuständige Manager zwar ein wenig über den festgelegten
Betrag hinausgehen, wenn ihm der Bewerber sehr wichtig ist, doch dies wird von der Personalab-
teilung nicht geschätzt, wie der im Folgenden zitierte HR-Vertreter klarstellt:

„There is no range, it’s a fixed amount. So if you fall in the band of two to two and half
years [Berufserfahrung – PF], this is exactly the salary, you get.“ (NI15)

Auch die Schilderung des folgenden Entwicklers bestätigt diese Praxis:

„I have friends, who have interviewed with NovoProd and some turned it down, be-
cause they felt, that there was no negotiation possible. It’s just your experience and
your previous organization, your previous academic record, that decides.“ (NI21)

Hintergrund ist auch in diesem Fall die „internal parity“, die zwischen den Beschäftigten bei
NovoProd hergestellt und aufrechterhalten werden soll (vgl. Kapitel 6.3.2), weil befürchtet wird,
dass starke Gehaltsunterschiede das Klima in den Projektteams negativ beeinflussen könnten.

„But otherwise, we are very, very strict. Because otherwise, what will happen, is, to get
people from the market, we offer them higher salaries and then it will create inference
in the team, that we certainly don’t want. That is something, which used to happen in
my previous organization. People used to be very unhappy, whenever a new person
used to join us, because the new person would have high salaries.“ (NI15)

Von daher verzichten Beschäftigte durch ihren Einstieg bei NovoProd auf nicht unerhebliche
Gehaltsbestandteile, die bei anderen Unternehmen einen wesentlichen finanziellen Anreiz darstel-
len. Die Frage, ob eine Beschäftigung bei NovoProd nun finanziell lukrativer ist als z.B. bei einem
IT-Dienstleister, ist aus den genannten Gründen nicht klar zu beantworten und wird auch von
188 Fallstudie NovoProd

den Beschäftigten sehr unterschiedlich eingeschätzt. Einige halten die Verdienstmöglichkeiten bei
den Dienstleistungsunternehmen für höher, andere hingegen denken, dass das Grundgehalt bei
NovoProd den Ausschlag dafür gibt, dass hier besser verdient würde.
Zwar finden sich in den Interviews keine Klagen über die Höhe der aktuellen Gehälter. Aller-
dings wird kritisch angemerkt, dass die Entwicklung der Gehälter bei NovoProd Grund zur Sorge
gibt, weil sich außerhalb NovoProds die Gehälter und Gehaltserwartungen von Beschäftigten äu-
ßerst rasant steigern. Zwar wurden im indischen Entwicklungszentrum (analog zu den Jobtiteln)
die Gehaltsbänder für die einzelnen Jobtitel stärker differenziert als dies im deutschen Mutterhaus
der Fall ist, um damit häufigere Gehaltserhöhungen möglich zu machen (vgl. NI15). Trotzdem
wird z.B. von folgenden Gesprächspartner die Ansicht geäußert, dass NovoProd langsam den An-
schluß an die Gehaltsentwicklung der Branche verliere:

„NovoProd used to be a good pay-master. Not a good, but among the top pay masters
... till about two, three years back. But I think, we are now not keeping pace with the
others. So we must be, say, 80 percent of... I mean [...] somebody, who is equivalent
to me outside NovoProd might be getting, say, around 20 percent more than me or
something like that.“ (NI13)

Derselbe Befragte führt diese Entwicklung auf die Entscheidungsstrukturen bei NovoProd zu-
rück:

„I mean, historical reasons are, that NovoProd is ... hikes are decided in Germany. I
think, the HR here ..., hm, there is a use case, saying: ’ok, this is the market standard
and this is, what we should pay’. And then NovoProd – the HR that decides – also
takes into account, what has been NovoProd’s performance over the year and what
are the pay hikes there and all that. So I think it’s a combination of factors basically.“
(NI13)

Diese Aussage wird von der HR-Beauftragten im deutschen Hauptquartier bestätigt (ND3). Tat-
sächlich werden die jährlich möglichen Gehaltserhöhungen zentral für alle an der Entwicklung be-
teiligten Projektteams im deutschen Hauptquartier festgelegt. Dazu wird für jeden Standort eine
Summe bestimmt, um die die Gesamtgehaltssume im Jahr wachsen darf. An diese Vorgaben müs-
sen sich die Personalmanager bei NovoProd anschließend halten. Die erwähnte HR-Beauftragte
bestätigt auch, dass in diese Festlegungen neben Studien zu standortspezifischen Gehaltsstandards
auch Daten zur wirtschaftlichen Entwicklung des Gesamtunternehmens eingehen. Da NovoProd
mit zunehmender Konkurrenz auf dem bedienten Marktsegment konfrontiert sei und daher bei
der Entwicklung unter starkem Kostendruck stehe, sei die für Gehaltserhöhungen zugestandene
Summe in den letzten Jahren nicht mehr so hoch gewesen, wie in den Jahren zuvor.
Dies macht die Gehaltsfestsetzung im indischen Entwicklungszentrum für NovoProd zuneh-
mend schwieriger. Denn der Grundsatz der „internal parity“ bezieht sich nicht nur auf die Gleich-
behandlung aller Beschäftigten einer Stufe. Vielmehr darf auch die Gehaltsentwicklung inner- und
außerhalb des Unternehmens nicht zu stark auseinanderfallen, wenn die „internal parity“ zwischen
erfahrenen und neueingestellten Beschäftigten nicht verletzt werden soll.

„Und was man natürlich auch nicht vergessen darf, ist: Wenn ich heute fünf Entwickler
einstelle zu einer bestimmten Basis oder zu einem bestimmten Gehalt eben, [...] das
ist natürlich noch mal ganz anders, wenn ich, sagen wir mal, in ein, zwei Jahren dann
wieder fünf Entwickler einstelle. [...] Ich muss im Prinzip also nur aufpassen, dass die
Betriebliche Kontrollstrategien bei NovoProd 189

fünf neuen Entwickler, die ich ein Jahr später einstelle, dass die vom Gehalt her die
Entwickler von damals nicht überholen.“ (NI1)

Entsprechend kann man die Gehaltssteigerungen, die außerhalb NovoProds üblich sind, nicht
mitvollziehen – und Fluktuation nicht durch monetäre Anreize bekämpfen. Um dieses Problem
zu umgehen, werden teilweise intern Gehaltserhöhungen vorgenommen, wie ein Personalmanager
berichtet:

„Da mussten wir eine Anpassung machen vor ein paar Jahren.[...] für die, die im
Unternehmen waren: Die haben quasi noch mal etwas obendrauf gekriegt, weil das
Wachstum der Gehälter am Markt einfach so rapide war, dass unser internes Wachs-
tum da ein bisschen hinterher gehinkt ist, und man eben dann diesen Ausgleich vor-
nehmen musste, weil sonst hätte man die Konsequenz gehabt, dass die Leute schlicht
und ergreifend wegen Geld gehen. Nur mal, um eine Zahl zu nennen: ein Entwick-
ler verdient [...] sagen wir mal: 500 000 Rupees. [...] Das wäre sein Jahresgehalt. [...]
Und ich kriege draußen, sagen wir mal, statt meinen [...] 500 000 kriege ich eben 600
000. Und so signifikant sind unter Umständen die Unterschiede, je nach dem, wie sich
der Markt entwickelt hat. Klar, dann gehe ich. Und das ist auch das Druckmittel, was
die Leute dann hier auch haben [...] und wo man auch ab und zu mal drauf reagieren
muss. Und eben aus dem Grund wurde diese Anpassung damals, diese außergewöhn-
liche Anpassung auch vorgenommen.“ (NI1)

Die Schilderung des Managers zeigt sehr schön die Zwangslage, die hier für NovoProd entsteht.
Die hohe Abhängigkeit von den Beschäftigten und deren daraus folgende Machtposition führt
dazu, dass die Gehälter am indischen Standort außerplanmäßig erhöht werden mussten, um keine
Beschäftigten aus finanziellen Gründen an die Konkurrenz zu verlieren – und gleichzeitig werden
die Gehaltsbudgets von der Zentrale limitiert.
Der Bereich der Gehälter stellt also genauso wie der der Beförderungen für NovoProd eine große
Herausforderung dar. Zwar werden die gegenwärtig bei NovoProd gezahlten Gehälter von den Be-
schäftigten noch als wettbewerbsfähig angesehen und größere Beschwerden bzgl. der finanziellen
Situation wurden in keinem Interview erwähnt. Wie sich diese Situation jedoch in Zukunft ent-
wickelt, ist offen, und es gibt einige Anzeichen, dass sich hier Probleme ergeben könnten, die
finanziellen Erwartungen der Beschäftigten weiterhin zu erfüllen.

Betrachtet man abschließend das in Kapitel 3.3 (S. 40) beschriebene Spannungsfeld von Reduzie-
rung von bzw. Immunisierung gegen Fluktuation, so lässt sich zusammenfassen, dass sich die bei
NovoProd ergriffenen Maßnahmen vor allem darauf richten, Fluktuation zu reduzieren. Eine Im-
munisierung der Arbeitsabläufe gegen Fluktuation, die im wesentlichen darin bestehen würde, die
Arbeitsabläufe stark zu standardisieren und zu formalisieren und damit die Abhängigkeit von indi-
viduellen Wissens- und Erfahrungsbeständen zu reduzieren, stünde immerhin in einem schroffen
Gegensatz zur strategischen Zielstruktur des von NovoProd angestrebten Verlagerungsmodells.
Bei den Maßnahmen zur Reduzierung von Fluktuation setzt NovoProd strategisch vor allem
auf arbeitsinhaltliche und -organisatorische Anreize, wohingegen die Bereiche der betrieblichen
Karrieren und Gehälter für NovoProd eher Schwierigkeiten bergen. Zwar zeigen die (für den in-
dischen Standort vergleichsweise niedrigen) Fluktuationsraten von 9%, bzw. 7,5% bei Application,
dass diese Strategie bisher erfolgreich ist, jedoch bergen die eher auf Beschäftigungsverhältnisse
190 Fallstudie NovoProd

bezogenen Aspekte der Beförderungen und Gehälter durchaus Probleme, die mittelfristig zu ei-
nem Anstieg der Fluktuationsraten führen könnten. Erste Anzeichen lassen sich in den Interviews
finden.
So gibt ein HR-Manager (NI16) an, dass sich die Fluktuationsraten bei NovoProd in den ersten
Monaten des Jahres 2007 erhöht haben. Er beziffert diesen Anstieg auf 25-30% gegenüber den
Vorjahren.

„Last four, five years it’s [die Fluktuationsraten – PF] been much lower than the mar-
ket. This year the indication is not so good. The kind of indication, that we got for the
first three months is a lot worse than what we have seen in the past, from our internal
benchmark. [...] It’s a terrible amount of pressure on that issue at this point in time.
[...] I think, we’ll internally have to look at some things: 25, 30 percent worse than
last year.“ (NI16)

Erschwerend kommt hinzu, dass die von NovoProd beabsichtigte Zielstruktur bisher nur in je-
nen Bereichen weitgehend umgesetzt werden konnte, die in der Zusammensetzung stabil waren,
wohingegen in den Teams, die stärker von Fluktuation betroffen waren, wesentlich restriktive-
re Maßnahmen der Arbeitsorganisation und -kontrolle implementiert werden mussten. In den
Teams, die restriktiver behandelt werden, sind auch die arbeitsinhaltlichen Anreize nicht so ausge-
prägt wie in den stabilen Teams, was die Beschäftigten wiederum weniger stark an das Unterneh-
men bindet (u.a. NI9, NI15, NI22). Es zeigen sich hier also dynamische Wechselwirkungen – eine
Art Teufelskreis – wie der folgende Gesprächspartner formuliert:

„Those guys, Germans, they cannot give very critical work, because they know, that:
’ok, you don’t have the expertise’. And by the time somebody has this expertise, he
will move out. And we also keep complaining, that we don’t get critical work or im-
portant work. So that’s why we try to emphasize that: ’ok, you need to spend some
time in NovoProd – three years, four years. And then only you start getting more im-
portant, critical... That’s why we try to retain people, and put a lot of stress on that.“
(NI4)

Zum Zeitpunkt der Untersuchung war also in Bezug auf die Arbeitsmarktbeziehungen Novo-
Prods noch vieles in Bewegung. Ähnlich wie für die anderen Aktivitätsfelder, kann daher konsta-
tiert werden, dass NovoProd angesichts der indischen Verhältnisse vor großen Herausforderungen
steht, die beabsichtigte Zielstruktur für ihre global verteilte Entwicklung zu realisieren.

6.4 Zusammenfassung und Bewertung der bei NovoProd

verfolgten Kontrollstrategie
NovoProd versucht, das indische Entwicklungszentrum als zentralen Teil seines globalen Entwick-
lungsnetzwerkes zu etablieren. Dafür spricht nicht nur die in den letzten Jahren zunehmende
Personalstärke, die den indischen Standort mittlerweile zum zweitgrößten NovoProds weltweit
macht. Darüber hinaus zeigt auch die Tatsache, dass in der untersuchten Einheit Application ein
zentraler Teil des neuen Produkts hergestellt wird, die strategische Zielsetzung NovoProds, den
indischen Standort keinesfalls als „verlängerte Werkbank“ für rein ausführende, arbeitsintensive
Tätigkeiten zu nutzen. Vielmehr sollen die indischen Beschäftigten einen wichtigen, innovativen
Beitrag bei der Entwicklung eines neuen Produktes leisten. Demensprechend verfolgt NovoProd
Zusammenfassung und Bewertung 191

auch die Absicht, den indischen Standort und die dort lokalisierten Projektteams mit weitreichen-
den Verantwortlichkeiten hinsichtlich ihrer Aufgabenstellungen auszustatten – der bei NovoProd
sogen. „Ownership“ für ihren Produktteil.
Zwar lässt sich im Setup des globalen Entwicklungsnetzwerkes nach wie vor eine gewisse Asym-
metrie feststellen, was die Verteilung von planenden und ausführenden Tätigkeiten angeht, und
auch die technologische Komplexität des in Application zu bearbeitenden Moduls des Produkts ist
etwas geringer einzuschätzen als bei Tätigkeiten der im deutschen Hauptquartier situierten Ein-
heit Plattform. Dennoch weisen auch die Application zugewiesenen und von ihnen verantworteten
Aufgaben ein hohes Maß an Komplexität auf, was sowohl die qualifikatorischen Anforderungen
an die beteiligten Entwickler, als auch die Interdependenzen zu den anderen an der Entwicklung
beteiligten Einheiten Vision und Plattform betrifft.

Betrachtet man die Aktivitäten des Managements im indischen Entwicklungszentrum, so fällt

auf, dass NovoProd strategisch dort primär auf permissive Kontrollstrategien setzt. Zwar ging
selbst bei NovoProd die zunehmende Internationalisierung der Produktentwicklung mit einer
Tendenz zur Standardisierung und Formalisierung einher, um die global verteilt stattfindende Pro-
duktion und die damit notwendige, standortübergreifende Kommunikation und Kooperation der
beteiligten Akteure zu strukturieren. Anders als bei ServiceTec, richtet sich diese Standardisierung
und Formalisierung jedoch nicht zentral auf die zunehmende bürokratische Durchdringung des
Arbeitsprozesses, sondern beinhaltet hauptsächlich Standards und formelle Vorgaben hinsichtlich
der Produktarchitektur und des -designs. Um die verteilte, parallele Entwicklung des Produkts zu
gewährleisten, sind zwischen den einzelnen (an verschiedenen Standorten konzentrierten) Modu-
len klar definierte Schnittstellen erforderlich, die für die beteiligten Entwickler Rahmenparameter
bei der Arbeit an ihrem jeweiligen Modul darstellen. Innerhalb der Module stellen die Selbstor-
ganisationsfähigkeiten der Beschäftigten jedoch, wie am Beispiel von Application gezeigt werden
konnte, eine ganz zentrale Ressource für die Organisation der Arbeitsabläufe dar.
Dies zeigt sich im Charakter der den Entwicklern zugewiesenen Arbeitspakete. Es konnte ge-
zeigt werden, dass es sich im wesentlichen um integrierte Arbeitsaufgaben handelt, die jeweils alle
Phasen des Software-Lifecycles (wenn auch nur für einen Teil des Produkts) enthalten. Dement-
sprechend sind die von den Entwicklern zu erledigenden Aufgaben zeitlich umfangreich bemessen
und changieren innerhalb jeder Wave stark zwischen eher planend-konzeptionellen und eher aus-
führenden Tätigkeiten. Zudem treten aufgrund des stark interdependenten Charakters der Module
im Zuge der parallel ablaufenden Entwicklung des Gesamtproduktes permanent Störungen und
Komplikationen im Bearbeitungsvorgang auf, was von den Beschäftigten eine flexible und kreative
Herangehensweise erfordert.
Gerade dieser Charakter der im indischen Entwicklungszentrum geleisteten Arbeit ist nach An-
sicht vieler Gesprächspartner auch der Grund, warum eine weitreichende Standardisierung und
Formalisierung der Arbeitsprozesse bei NovoProd nicht gewünscht, sondern vielmehr geradezu
als Gefahr – als „Bürokratiemonster“ – angesehen wird. Dementsprechend konnte in Bezug auf die
bei NovoProd vorfindliche Form der Kontrollstruktur konstatiert werden, dass formalisierte Vor-
gaben in Form von Prozessbeschreibungen und Guidlines eher eine untergeordnete Rolle spielen.
Vielmehr werden die Beschäftigten, sofern sie selber nicht die nötige Erfahrung besitzen, um ihre
Aufgaben eigenständig zu planen und zu bearbeiten, oder bei Problemen und Unklarheiten, von
erfahreneren Kollegen persönlich angeleitet. Die Aufgaben für die Entwickler werden zu Beginn
jeder Wave wenig detailliert vorspezifiziert, und nur im Notfall werden vom jeweiligen fachlichen
Vorgesetzten detailliertere Vorgaben gemacht.
192 Fallstudie NovoProd

Um dennoch den Arbeitsprozess überblicken und in Problemfällen schnell eingreifen zu kön-

nen, wird der Fortschritt der Entwicklung formell in wöchentlichen Sitzungen und informell
durch die stetige Präsenz der fachlichen Vorgesetzten am Arbeitsplatz eng überwacht. Der Fokus
ist dabei in erster Linie auf das Arbeitsergebnis gerichtet, nicht auf den Prozess der Bearbeitung. So
werden für die zu entwickelnden Screens klare Anforderungen (in Form von sogen. „Use-Cases“,
also definierten Einsatz-Szenarien mit spezifischen Funktionsanforderungen) formuliert, denen
diese am Ende entsprechen müssen. Das jeweilige Vorgehen soll aber den Entwicklern selbst über-
lassen bleiben.
Zudem ist bei NovoProd die Bewertung von Arbeitsleistung wesentlich weniger individuali-
siert, als dies bei ServiceTec der Fall war. Zwar gibt es auch individuelle Zielvereinbarungen, diese
sind aber weniger formalisiert und detailliert, und bei der Bewertung der individuellen Zielerrei-
chung wird der kooperative Charakter der Aufgabenbearbeitung berücksichtigt. Die individuellen
Leistungsbewertungen werden vertraulich behandelt und setzen sich kaum in Gehaltsunterschiede
zwischen den Teammitgliedern um. Vielmehr wird bei NovoProd die „internal parity“ betont und
versucht, keine Unstimmigkeiten durch Ungleichbehandlung innerhalb der Teams zu erzeugen,
weil befürchtet wird, dass dies die Kooperation sowohl innerhalb der Teams, als auch standort-
übergreifend gefährden könnte.

Der in dieser Form der Leistungsbeurteilung schon anklingende Versuch, den Teamgedanken
zu betonen, ist auch kennzeichnend für NovoProds Gestaltung der internen Kooperations- und
Kommunikationsbeziehungen. Sowohl am jeweiligen Standort, als auch standortübergreifend sol-
len die Beschäftigten innerhalb des Entwicklungsnetzwerkes möglichst eng, direkt und multila-
teral miteinander kooperieren. Die Kommunikation wird nicht in bestimmten Positionen kon-
zentriert und damit kanalisiert, sondern alle Entwickler sind aufgerufen, ihre deutschen bzw. in-
dischen Counterparts möglichst direkt zu kontaktieren und sich die jeweils benötigte Informa-
tion und/oder Unterstützung zu holen. Als Grund wird von den Gesprächspartnern auch der
stark interdependente Charakter der Arbeit angeführt, der starke Kommunikationsnotwendigkei-
ten schaffe, die nicht in einzelnen Personen zu bündeln seien.
Um multilaterale Kooperation zu ermöglichen und zu fördern, versucht NovoProd gezielt, al-
le Beschäftigten – auch standortübergreifend – miteinander in Kontakt zu bringen und somit die
Etablierung von persönlichen Netzwerken zu erleichtern. Formalisierte Kommunikationskanäle
und -formen sind daher bei NovoProd nicht geschätzt. Vielmehr wird nach wie vor der direkte,
persönliche Kontakt der Beschäftigten als wichtige Voraussetzung einer gelingenden standortüber-
greifenden Kooperation angesehen.

Allerdings stößt NovoProd bei der Umsetzung der skizzierten Zielstruktur am indischen Stand-
ort auf größere Schwierigkeiten. So benötigt NovoProd eine sehr stabile Teamzusammensetzung,
damit sich die Beschäftigten einerseits tief in ihre Arbeitsaufgaben einarbeiten und das nötige Er-
fahrungswissen aufbauen und andererseits die wichtigen persönlichen Kontakte zu ihren deut-
schen Counterparts knüpfen können. Gerade diese Stabilität der Teamzusammensetzung herzu-
stellen, ist allerdings im indischen Bangalore (anders als im deutschen Mutterhaus) eine heraus-
fordernde Aufgabe. Zwar genießt NovoProd als multinationaler Produkt-Hersteller – hinsichtlich
der Qualität der Arbeit, des Markennamens und des damit zusammenhängenden Prestiges – großes
Ansehen, was dazu führt, dass zum Zeitpunkt der Untersuchung Rekrutierungen – auch aufgrund
der vergleichsweise moderaten Wachstumspläne – am indischen Arbeitsmarkt nach wie vor un-
problematisch waren. Beschäftigte jedoch längerfristig im Unternehmen zu halten, ist auch für
NovoProd alles andere als einfach.
Zusammenfassung und Bewertung 193

Im Gegensatz zu ServiceTec setzt NovoProd dabei vor allem auf (aus dem spezifischen Verlage-
rungsmodell folgende) arbeitsinhaltliche und -organisatorische Anreize. So wissen es die indischen
Beschäftigten sehr zu schätzen, dass ihnen bei NovoProd zur Bearbeitung ihrer Arbeitsaufgaben
große Handlungs- und Verantwortungsspielräume eingeräumt werden. Doch obwohl diese bei No-
voProd sehr präsente arbeitsinhaltliche Motivation grundsätzlich dazu führt, dass die Beschäftigten
aufgrund ihrer Job-Zufriedenheit längerfristig im Unternehmen verbleiben (wollen), bestehen sie
auf guten Karrierechancen, sowohl hinsichtlich Beförderungen und schnellem Aufstieg, als auch
hinsichtlich guter Gehälter und entsprechender Erhöhungen.
Ein globales Entwicklungsnetzwerk mit entsprechend enger Kooperation zwischen den einge-
bundenen Standorten macht es nun erforderlich, auch über die Standorte hinweg die „internal
parity“ nicht zu stark zu verletzen. Die hohen Erwartungen der indischen Beschäftigten werden
daher bei NovoProd stets in ein Verhältnis zu anderen Standorten gesetzt, an denen andere Be-
dingungen gelten. So erfolgen Beförderungen bei NovoProd im indischen Entwicklungszentrum
zwar wesentlich schneller, als dies im deutschen Hauptquartier der Fall ist, und auch die Zahl der
Jobtitel ist inoffiziell etwas höher, doch an die (den indischen Standort dominierenden) Standards
der indischen IT-Dienstleister reicht NovoProd damit nicht heran.
Auch über die Höhe der jährlich möglichen Gehaltssteigerungen wird bei NovoProd zentral
unter Berücksichtigung aller beteiligten Entwicklungsstandorte entschieden. Dabei findet die spe-
zifische Situation in Indien besondere Berücksichtigung, doch trotzdem bleiben die Gehälter bei
NovoProd zunehmend hinter dem Branchendurchschnitt zurück.
Daher ist die gegenwärtige Situation bei NovoProd mit Fluktuationsraten, die mit knapp 7,5%
bei Application deutlich unter dem Branchenschnitt liegen, zwar noch vergleichsweise gut, jedoch
zeigen sich erste Anzeichen dafür, dass sich die Situation zukünftig zuspitzen könnte.
Angesichts der Form der Arbeitsorganisation im indischen Entwicklungszentrum wäre eine sol-
che Entwicklung für NovoProd sehr kritisch, weil durch die hohe Relevanz von individuellem
Erfahrungswissen eine starke Abhängigkeit der Arbeitsprozesse von den Beschäftigten besteht.
Daher ist der effektive Ablauf der Arbeitsprozesse durch erhöhte Fluktuation gefährdet.
Schon gegenwärtig zeigt sich in den Teams, die in letzter Zeit mit erhöhter Personalfluktuation
zu kämpfen hatten, wie stark sich dies auf die Form der Arbeitskontrolle am indischen Stand-
ort auswirkt: entgegen der strategischen Absicht, muss NovoProd in jenen Teams auf wesentlich
restriktivere Formen der Arbeitskontrolle zurückgreifen und hat große Schwierigkeiten, die be-
absichtigte Zielstruktur zu realisieren. Die in diesen Teams angewandten Elemente einer eher re-
striktiv wirkenden Form der Kontrolle sind dementsprechend jedoch nicht Ausdruck eines die
Internationalisierung quasi automatisch begleitenden Industrialisierungsdrucks, sondern vielmehr
Folge spezifischer Bedingungen am indischen Standort, mit denen die von NovoProd verfolgte
Kontrollstrategie teilweise in Konflikt gerät.
194 Fallstudie NovoProd
7 Zusammenführung und Ausblick: Die
heterogene Reorganisation von IT-Arbeit
im Zuge ihrer Internationalisierung
Die vorliegende Studie hatte ihren Ausgangspunkt in der Frage nach veränderten Formen der
Arbeitsorganisation und -kontrolle von IT-Arbeit im Zuge ihrer zunehmenden Internationalisie-
rung. Im Gegensatz zu den Vertretern der „Industrialisierungsthese“ ging die vorliegende Arbeit
nicht davon aus, dass die Reorganisation der Arbeitsprozesse in international operierenden IT-
Unternehmen mit dem Begriff der „Industrialisierung“ angemessen beschrieben werden kann.
Vielmehr wurde argumentiert, dass sich statt klarer Industrialisierungstendenzen in der IT-In-
dustrie vielmehr unterschiedliche Reorganisationsmodi identifizieren lassen, innerhalb derer die
weitreichende Standardisierung und Formalisierung der Arbeitsprozesse eine Möglichkeit darstellt,
mit den Herausforderungen global verteilter Arbeitsprozesse umzugehen. Diese unterschiedlichen
Reorganisationsmodi, so das Argument weiter, beruhen auf den von den Unternehmen jeweils ver-
folgten Internationalisierungswegen und dem Zusammenspiel dieser Internationalisierungswege
mit zentralen Bedingungen der Standorte.

In einem ersten Schritt zur Begründung dieser These wurde unter Berücksichtigung der je spezi-
fischen Form der Internationalisierung eines IT-Dienstleistungsunternehmens und eines Standard-
software-Herstellers argumentiert, dass sich die Unterschiede zwischen der jeweiligen Form der
Internationalisierung (Captive Offshoring vs. Offshore-Outsourcing), die sich auf die spezifischen
Geschäftsmodelle zurückführen lassen, auf die Form und die Reichweite der von den jeweiligen
Unternehmen betriebenen Standardisierungsbemühungen auswirken. Mit Prozess- und Produkt-
standardisierung konnte dabei ein grundlegender Unterschied in den Standardisierungsbemühun-
gen der beiden untersuchten Unternehmen charakterisiert werden.

In einem zweiten Schritt wurde der in dieser Studie im Zentrum stehende IT-Standort Indien
in Bezug auf seinen Einfluß auf die (Re-)Organisationsmodi von Arbeit untersucht. Als zentraler
Aspekt wurden die hohen Fluktuationsraten in der indischen IT-Industrie hervorgehoben, die aus
deren explosionsartigem Wachstum in den letzten Jahren und einem damit einhergehenden Fach-
kräftemangel auf dem indischen Arbeitsmarkt folgen. Es wurde argumentiert, dass obwohl der
indische Arbeitsmarkt für beide im Rahmen dieser Studie untersuchte Fälle gleichermaßen eine
Herausforderung darstellt, die Wirkung der Arbeitsmarktsituation auf die Reorganisationsmodi
nicht eindeutig ist. Vielmehr wurde gezeigt, dass der indische IT-Arbeitsmarkt unterschiedliche
Strategien des Umgangs ermöglicht, die in der begrifflichen Entgegensetzung von Immunisierung
gegen und Reduzierung von Fluktuation idealtypisch gefasst wurden.

In den beiden präsentierten Fallstudien schließlich wurden die beiden Faktoren zusammenge-
bracht und empirisch belegt, wie sich aus dem Zusammenspiel von variierenden Internationalisie-
rungswegen und indischem Arbeitsmarkt ein je spezifischer (Re-)Organisationsmodus von Arbeit
in den indischen Entwicklungszentren beider Unternehmen herausbildet. Das Hauptaugenmerk

195
196 Zusammenführung und Ausblick

der Fallstudien lag auf der Frage, inwiefern die Arbeitsprozesse in den beiden berücksichtigten
Konstellationen jeweils „industrialisiert“ sind. Industrialisierte Arbeitsprozesse wurden dabei als
Formen der Arbeitskontrolle interpretiert, die mit Friedman als Formen der „direkten“ Kontrol-
le gefasst werden können. Ein an Friedman angelehntes Analysemodell bot die Möglichkeit, die
vorfindlichen Formen der Arbeitskontrolle anhand der Aktivitäten des Managements in vier zen-
tralen Aktivitätsfeldern zu beschreiben und anhand ihrer strategischen Dimensionen in Bezug auf
ihren Grad an Restriktivität zu vergleichen. Es konnten dabei in allen untersuchten Aktivitätsfel-
dern wesentliche Unterschiede zwischen den beiden Fällen herausgearbeitet werden.
Der Fall ServiceTec entspricht dabei weitgehend den Erwartungen der Vertreter der Industria-
liserungsthese. Ganz explizit wird hier vom Management die weitgehende Standardisierung und
Formalisierung der Arbeitsprozesse angestrebt und vorangetrieben. Für die Entwickler bedeutet
dies, dass sie bei ServiceTec mit sehr kurztaktigen und hochgradig vorspezifizierten Arbeitsaufga-
ben konfrontiert sind, die ihnen nur in sehr geringem Maße Selbstorganisations- und Problemlö-
sungsfähigkeiten abverlagen. Zudem sind ihre Möglichkeiten, die Art und Weise der Bearbeitung
ihrer Arbeitsaufgaben mitzubestimmen, durch eine ausgefeilte und detaillierte Kontrollstruktur
stark eingeschränkt. Die bei ServiceTec präferierte Bezeichnung der Entwickler als „Ressources“
versinnbildlicht die Rolle, die den Entwicklern bei ServiceTec zugewiesen wird: die Beschäftigten
sollen möglichst flexibel und in jeder Position gleichermaßen einsetzbar sein. Um diesen Zustand
zu erreichen, durchlaufen alle Beschäftigten gleichermaßen das firmeneigene, intensive Trainings-
programm. Im Anschluß werden sie je nach Geschäftsaufkommen innerhalb der Firma eingesetzt
und zudem stetig rotiert, um Spezialisierungseffekte auf bestimmte Kunden, Technologien oder
auch Kundenregionen zu verhindern und damit die Flexibilität des Personaleinsatzes aufrecht zu
erhalten.
Bei NovoProd hingegen wird auch im indischen Entwicklungszentrum stark auf die Selbstorga-
nisationsfähigkeiten der Beschäftigten gebaut. Strategisches Ziel ist hier, die Beschäftigten soweit
wie möglich zu befähigen, ihre – häufig lediglich grob vorspezifizierten und zeitlich langfristig be-
messenen – Arbeitsaufgaben eigenständig zu erledigen und etwaige Probleme auch selbständig zu
lösen, ohne umfangreiche Anweisungen oder Vorgaben hinsichtlich der Bearbeitung zu benötigen.
Ganz explizit findet sich hier die Absicht, Beschäftigte fachlich zu spezialisieren und tief einzuar-
beiten, um die individuelle Leistungsfähigkeit bei bestimmten Tätigkeiten zu steigern. Zwar wird
auch bei NovoProd zugestanden, dass eine gewisse Standardisierung nötig ist, um die global ver-
teilte Produktentwicklung zu koordinieren. Diese Standardisierung bezieht sich jedoch primär auf
die Architektur und das Design des Produkts und die dazu nötigen Komponenten. So gibt es kla-
re Vorgaben hinsichtlich des grafischen Designs und der Schnittstellen zwischen den einzelnen
Modulen, die für die Entwickler im indischen Entwicklungszentrum nur unter besonderen Um-
ständen zu verändern sind. Die Standardisierungsbemühungen von NovoProd richten sich nicht
darauf, die Handlungs- und Verantwortungsspielräume sowie die Abhängigkeit der Arbeitsabläufe
von den Beschäftigten möglichst weitreichend zu reduzieren. Der Devise ServiceTecs, dass Pro-
jekte stets „process-depending and not people-depending“ sein sollten, stellt NovoProd vielmehr
explizit einen „people-centric approach“ entgegen.
Deutlichster Ausdruck dieses Ansatzes ist die Relevanz, die bei NovoProd dem direkten und
persönlichen Kontakt aller Beschäftigten untereinander beigemessen wird. So ist die Kommunika-
tion und Kooperation innerhalb des Teams nicht nur für die Bearbeitung auch der individuellen
Arbeitsaufgaben unerlässlich, sondern die Relevanz des direkten Kontakts wird auch im Rahmen
der standortübergreifenden Kooperation vom Managament bei NovoProd stark betont. Nach An-
gaben der Gesprächspartner sei die Kooperations- und Kommunikationsintensität zwischen den
an der Entwicklung beteiligten Teilen des Entwicklungsnetzwerkes derart stark, dass eine Kana-
 197

lisierung der Kommunikation über bestimmte Personen eher hinderlich als förderlich wäre. So
ist die gegenwärtig noch bestehende Aufgabe der Brückenköpfe, im Falle von noch nicht einge-
spielten persönlichen Kontakten zwischen den beteiligten Teamteilen als Informationsverteiler zu
fungieren, auch lediglich als Notlösung zu verstehen, die langfristig abgeschafft werden soll.
ServiceTec hingegen versucht, die Rolle des Entwicklers eher als „individual contributor“ denn
als Teamplayer zu gestalten. Diese Absicht zeigt sich bereits in der Art der Aufgabenzuweisung, die
ausschließlich Einzelarbeit an individuell zugeteilten Arbeitspaketen vorsieht. Auch darüber hin-
aus wird versucht, die Kommunikation und Kooperation über die unmittelbaren Ansprechpartner
des Moduls hinaus möglichst zu kanalisieren. So kommunizieren die Beschäftigten im indischen
Entwicklungszentrum meist nur über die jeweiligen Modulleiter mit anderen Teams oder mit den
Beschäftigten beim Kunden. Der deutlichste Indikator für die geringere Relevanz, die bei Service-
Tec der teamförmigen Kooperation der Entwickler untereinander beigemessen wird, ist jedoch
das System der Leistungsmessung und -beurteilung. Im Gegensatz zu NovoProd wird bei Service-
Tec die Bewertung individueller Arbeitsleistung stark betont und gezielt versucht, die Entwickler
miteinander um die besten Bewertungen konkurrieren zu lassen.
Schließlich konnten auch wesentliche Unterschiede in den Arbeitsmarktbeziehungen von Ser-
viceTec und NovoProd nachgewiesen werden. Obwohl beide Unternehmen in Indien aktiv und
damit grundsätzlich mit den gleichen Bedingungen konfrontiert sind, konnte dennoch gezeigt
werden, dass sich die Strategien NovoProds und ServiceTecs geradezu komplementär zueinander
verhalten: ServiceTec fokussiert in seinen Rekrutierungsbemühungen vor allem auf die Stufe der
Berufseinsteiger und rekrutiert daher gezielt Absolventen direkt von den Universitäten in Form
von sogen. „Campus-Placements“. Aufgrund des starken Wachstums der letzten Jahre nehmen
diese Einstellungen bei ServiceTec die Form von regelrechten Massenrekrutierungen an. Da das
Angebot an fachlich auf IT spezialisierten Uniabsolventen zunehmend knapper, umkämpfter und
damit auch teurer wird, ist ServiceTec in den letzten Jahren dazu übergegangen, auch Absolventen
nicht IT-naher Studiengänge als Zielgruppe zu erschließen. Ein ambitioniertes firmeninternes Ein-
stiegstraining bietet ServiceTec dabei die Möglichkeit, eine große Zahl neu rekrutierter Beschäftig-
ter in kurzer Zeit mit den notwendigen Qualifikationen auszustatten. Demgegenüber rekrutiert
NovoProd gar nicht auf der Ebene der Berufseinsteiger, sondern konzentriert sich auf die Ein-
stellung berufserfahrener Beschäftigter, die ihre ersten Jahre meist bei indischen IT-Dienstleistern
verbracht haben. Die qualifikatorischen Anforderungen an die Beschäftigten sind bei NovoProd
im Vergleich zu ServiceTec höher. So rekrutiert NovoProd bisher ausschließlich Absolventen IT-
naher Studiengänge der 100 renommiertesten Lehrinstitutionen Indiens. Die geringere Zahl be-
nötigter Arbeitskräfte ermöglicht es NovoProd gegenwärtig noch, auf Massenrekrutierungen zu
verzichten, und gezielt für offene Stellen zu rekrutieren.
Der interne Personaleinsatz ist bei ServiceTec strategisch darauf ausgerichtet, die Beschäftigten
nach der Einstellung möglichst lange flexibel einsetzbar zu halten. Konkret ist damit der Versuch
gemeint, die Beschäftigten, nachdem sie das firmeninterne Training relativ homogen geschult ver-
lassen haben, auch in den ersten Jahren des Einsatzes im Projektgeschäft möglichst gleichmäßig
weiterzuentwickeln. Vermieden werden sollen explizit Spezialisierungseffekte bei den Beschäftig-
ten in Bezug auf bestimmte Technologien, Kundenbranchen oder -regionen. Auf diese Weise kön-
nen Beschäftigte auf der Ebene der Entwickler ohne längere Einarbeitungszeiten zwischen Projek-
ten versetzt werden, und die Projekte daher auch flexibel je nach Personalbedarf skaliert werden.
NovoProd versucht hingegen, die Beschäftigten in bestimmten Tätigkeitsfeldern zu spezialisieren
und die Projektteams möglichst stabil zu halten, damit die Entwickler wichtiges Erfahrungswissen
und die notwendigen persönlichen Netzwerke innerhalb des Unternehmens aufbauen können.
Aus diesen jeweils verfolgten Ansätzen folgt damit auch, dass die Abhängigkeit von den Beschäf-
198 Zusammenführung und Ausblick

tigten auf der Ebene der Entwickler bei ServiceTec und NovoProd höchst unterschiedlich ist. Ser-
viceTec betreibt große Anstrengungen, die Abhängigkeit der Projekte von einzelnen Beschäftigten
möglichst weitreichend zu reduzieren. Dies dient einerseits dem flexiblen Einsatz der Beschäftig-
ten in Projekten mit wechselndem Personalbedarf, andererseits aber auch einer Immunisierung der
Arbeitsprozesse gegen die am indischen Standort herrschenden hohen Fluktuationsraten. So kann
ServiceTec nach eigenen Angaben den Ausfall eines Teammitglieds in ca. 3 Wochen personell aus-
gleichen. NovoProd hingegen treffen Kündigungen von Teammitgliedern wesentlich härter. Auf
der einen Seite sind die Einarbeitungszeiten bei NovoProd mit von den Gesprächspartnern ge-
schätzten 3-6 Monaten wesentlich länger und auf der anderen Seite gibt es bei NovoProd auch
keine „Bank“1 , wie sie bei ServiceTec existiert. So müssen für Personen, die die Firma verlassen,
häufig neue Beschäftigte extern rekrutiert werden, was der Einarbeitungszeit häufig noch weitere
Monate für die Rekrutierung hinzufügt. Dementsprechend stellen die hohen Fluktuationsraten
für NovoProd eine größere Gefahr dar, und es konnte gezeigt werden, wie die Personalfluktuation
bei NovoProd dazu führte, dass zentrale Elemente der organisatorischen Zielstruktur in einigen
Teams bisher nicht verwirklicht werden konnten.

Fasst man die in den einzelnen Aktivitätsfeldern konstatierbaren Unterschiede zwischen Ser-
viceTec und NovoProd zusammen, so lässt sich also konstatieren, dass ServiceTec in seinem in-
dischen Entwicklungszentrum stark auf restriktive Formen der Arbeitsprozesskontrolle setzt. Bei
NovoProd ließen sich hingegen wesentliche Elemente von permissiven Formen der Kontrolle iden-
tifizieren, wenngleich auch NovoProd gezwungen ist, in einigen Teams wesentlich restriktiver vor-
zugehen, als es die strategische Zielstruktur vorgab.

Aus den präsentierten Ergebnissen lassen sich zwei zentrale Befunde herausheben, die für die
Debatte über die Veränderungen der Arbeitssituation von Beschäftigten im Zuge der zunehmen-
den Internationalisierung der IT-Industrie von besonderem Interesse sind.

1
Damit ist das Vorgehen ServiceTecs gemeint, Beschäftigte, die zu einem Zeitpunkt keinem Projekt zugeordnet sind,
bis zur Zuweisung in ein Projektteam mit grundlegenden Weiterqualifizierungsarbeiten zu betrauen. Als Sprachge-
brauch hat sich für diese Übergangsphase bei ServiceTec eingebürgert, dass sich diese Beschäftigten in der Zeit auf
der „Bank“ befänden. Die Bank ist daher ein firmeninterner Arbeitsmarkt, auf den Beschäftigte je nach Projekterfor-
dernissen flexibel freigesetzt und von dem sie ebenso auch wieder in die Projektteams aufgenommen werden können
(vgl. Kapitel 5.3.4).
Zur Entwicklung von IT-Arbeit 199

7.1 Zwischen „Wissensarbeit“ und „Industrialisierung“ – Zur

Entwicklung von IT-Arbeit im Zuge ihrer Internationalisierung
Die Ergebnisse dieser Studie bestätigen, dass in der IT-Industrie große Veränderungen in der Or-
ganisation der Arbeitsprozesse im Zuge ihrer zunehmenden Internationalisierung stattfinden. Die
Untersuchung der Formen der Arbeitsorganisation und -kontrolle bei ServiceTec hat gezeigt, dass
die Internationalisierung durchaus mit einer weitreichenden „Industrialisierung“ der Arbeitspro-
zesse einhergehen kann, wie die Vertreter der „Industrialisierungsthese“ betonen. Die Formen der
Arbeitskontrolle bei ServiceTec stellen gegenüber dem, was traditionell über die Form der Kon-
trolle von IT-Arbeit in der Literatur geschrieben wird, ein gänzlich neues Vorgehen dar. In Form
seines „Global Delivery Model“ hat ServiceTec einen Ansatz gefunden, die globalen Arbeitspro-
zesse mithilfe standardisierter und formalisierter Prozessbeschreibungen zu durchdringen und die
Beschäftigten damit extrem restriktiven Formen der direkten Kontrolle zu unterwerfen. Entgegen
den Ansichten jener Autoren, denen die Selbstorganisationsfähigkeiten und die hohen Autonomie-
spielräume der Beschäftigten als zentrales Kennzeichen der Kontrolle von IT-Arbeit (als Inbegriff
neuer Arbeitsformen) gelten (Willke 1998; Heidenreich und Töpsch 1998; Töpsch, Menez und
Malanowski 2001; Voß und Pongratz 1998), zeigt der Fall ServiceTec, dass auch hochqualifizier-
te IT-Arbeit sehr wohl direkt und bürokratisch kontrolliert werden kann. Haben schon einige
frühere Studien darauf aufmerksam gemacht, dass die Annahmen in Bezug auf die Kontrolle von
IT-Arbeit etwas einseitig sind und Formen direkter Kontrolle durchaus auch im Bereich hochqua-
lifizierter „Wissensarbeit“ angewandt werden können (u.a. Barrett 2005; Mayer-Ahuja und Wolf
2005; auch schon Kraft und Dubnoff 1986), so überrascht doch das Maß, in dem es ServiceTec
gelungen ist, den Arbeitsprozess der direkten Kontrolle durch das Management zu unterwerfen
und die Beschäftigten in ihren Handlungs- und Verantwortungsspielräumen zu beschneiden. Die
Rede von der „fabrikmäßigen“ Produktion von IT-Dienstleistungen, in der Managementliteratur
seit einiger Zeit geradezu ein Ideal der zukünftigen Organisation von Arbeit im IT-Bereich, findet
in ServiceTec ein eindrucksvolles Beispiel.

Bestätigt die vorliegende Studie damit also, dass die Internationalisierung der IT-Arbeit durchaus
mit einer zunehmenden Industrialisierung der Arbeitsprozesse einhergehen kann, so widerlegt sie
gleichzeitig die Prognose, dass dies der Fall sein muss, bzw. langristig notwendig sein wird. Nun
liegt der Neuigkeitswert der präsentierten Fallstudie bei NovoProd keineswegs primär darin, ge-
zeigt zu haben, dass auch in international verteilt operierenden IT-Unternehmen die Arbeitspro-
zesse nach wie vor auf individuellen Kompetenzen und selbstorganisierten Abläufen beruhen kön-
nen. Schon Kämpf (2008, S. 373) kommt in seiner Studie zu dem Ergebnis, dass

„[...] auf der einen Seite oftmals noch keine stabilen und systematisierten Formen der
Arbeitsteilung gefunden [wurden] und ganzheitliche Rollenprofile [...] nach wie vor
die Arbeit vieler IT-Beschäftigter [bestimmen]; auf der anderen Seite [...] auch die
Standardisierung und Homogenisierung von Prozessen in den Unternehmen teilweise
nicht weit fortgeschritten [ist].“

Die neue Erkenntnis, die aus der Fallstudie von NovoProd gezogen werden kann, ist, dass es sich
dabei keinesfalls um „verschwindende“ Formen der Kontrolle handeln muss. So behandelte Kämpf
diese, noch auf die Selbstorganisationsfähigkeiten der Beschäftigten abzielenden Formen der Ar-
beitsorganisation und -kontrolle eher als Überbleibsel füherer Phasen der IT-Industrie (vgl. Kapitel
1.2). Dieser Einschätzung muss vor dem Hintergrund der Ergebnisse dieser Studie widersprochen
200 Zusammenführung und Ausblick

werden. Die präsentierte Fallstudie bei NovoProd zeigt deutlich, dass die Selbstorganisationsfähig-
keiten und die kreativen Problemlösungsfähigkeiten der Beschäftigten auch in international ver-
teilt operierenden IT-Unternehmen nach wie vor eine wichtige Ressource für die Organisation der
Arbeitsprozesse darstellen. So konnte gezeigt werden, dass NovoProd vor allem damit zu kämp-
fen hat, dass die Arbeitsprozesse gegenwärtig wesentlich restriktiver kontrolliert werden müssen,
als es beabsichtigt ist, weil die für den indischen Standort typischen Fluktuationsraten die Grund-
lagen der auf die Selbstorganisationsfähigkeiten der Beschäftigten gerichteten Kontrollstrategien
unterlaufen. Die konstatierte permissive Kontrollstrategie NovoProds in seinem indischen Ent-
wicklungszentrum kann daher keinesfalls als eine Art „Übergangsphänomen“ gedeutet werden,
das wahscheinlich in naher Zukunft durch eine „nachholende Industrialisierung“ ersetzt wird. Zu
gravierend sind bei NovoProd die Bedenken, dass ein „Bürokratiemonster“ die Flexibilität und
Kreativität der Entwickler behindern und daher im Entwicklungsprozess ein Hindernis für alle
Beteiligten werden könnte.
Es darf zwar nicht verschwiegen werden, dass auch bei NovoProd die Internationalisierung mit
einer gewissen Form der Standardisierung der Arbeitsabläufe einhergeht. Wie aus dem präsentier-
ten Material hervorgeht, richtet sich diese Standardisierung als „Produktstandardisierung“ jedoch
nur indirekt auf die Standardisierung der Arbeitsprozesse. Die Aufteilung des Gesamtprodukts in
einzelne Module mit jeweils festgelegten Zuständigkeiten unterschiedlicher Standorte führt in der
Folge durchaus zu einer stärkeren Arbeitsteilung, und der Einflußbereich der Entwickler ist da-
mit bei „verteilter Entwicklung“ gegenüber einer Entwicklung, die vollständig an einem Standort
in einem Team entwickelt wird, geringer. Allerdings bedeuten modulare Produktionsstrukturen
nicht, dass auch die in diesen Modulen ablaufenden Arbeitsprozesse stark standardisiert werden
(vgl. auch Flecker u. a. 2007, S.47ff.). Bei NovoProd sind zwar die Abhängigkeiten zwischen den
einzelnen Modulen klar spezifiziert und standardisiert, die jeweils in den Modulen stattfindenden
Arbeitsprozesse sollen jedoch permissiv kontrolliert werden.

Die vorliegende Studie fügt der laufenden Debatte über die Veränderungen der Organisation
und Kontrolle von Arbeit im Zuge der Internationalisierung der IT-Industrie eine wichtige Dif-
ferenzierung hinzu. Ist es also falsch, weiterhin davon auszugehen, dass IT-Arbeit aufgrund ihres
kreativen und wissensbasierten Charakters ausschließlich permissiv kontrolliert werden kann und
lassen sich demnach auch wichtige Befunde für eine Zunahme restriktiver Kontrollformen in der
IT-Industrie finden, so ist die Annahme, dass die Internationalisierung notwendigerweise mit re-
striktiven Kontrollstrategien einhergeht, als genauso einseitig zu verwerfen. Vielmehr verweisen
die hier präsentierten Ergebnisse auf den konflikthaften und kontingenten Charakter der Reorga-
nisationsbemühungen in international operierenden IT-Unternehmen. Auch im Zuge der Interna-
tionalisierung der IT-Industrie bleibt die Form der Kontrolle des Arbeitsprozesses ein „umkämpf-
tes Terrain“ (Edwards 1981). Eine Standardisierung und Formalisierung der Arbeitsprozesse kann
dabei, anders als von den Vertretern der Industrialisierungsthese unterstellt, keinesfalls als Univer-
sallösung zur Bearbeitung des sich in neuer Form stellenden Transformationsproblems angesehen
werden, sondern muss vielmehr als eine Möglichkeit gelten, mit den organisatorischen Herausfor-
derungen global verteilter Arbeitsprozesse umzugehen, deren Erfolg und Angemessenheit jedoch
an bestimmte Voraussetzungen und Bedingungen gebunden ist.
Darin, nähere Erkenntisse über die Einflußfaktoren zu Tage gefördert zu haben, die sich auf die
Form der Reorganisationsbemühungen und die daraus folgenden Formen der Arbeitsprozesskon-
trolle in international operierenden IT-Unternehmen auswirken, darin liegt die zweite Leistung
dieser Studie.
Betriebliche Reorganisationsmodi zwischen globalen Geschäftsmodellen und den
201
Arbeitsmärkten der Standorte

7.2 Betriebliche Reorganisationsmodi zwischen globalen

Geschäftsmodellen und den Arbeitsmärkten der Standorte
Anhand der beiden untersuchten Unternehmen konnte gezeigt werden, dass die zunehmende In-
ternationalisierung der Arbeit in der IT-Industrie mit einer weitgehenden Industrialisierung der
Arbeit einher gehen kann, aber nicht muss. So konnten anstatt einer eindeutigen Industrialisie-
rungstendenz vielmehr unterschiedliche Reorganisationsmodi bei beiden untersuchten Unterneh-
men festgestellt werden, die sich auch in unterschiedlich restriktiven Formen der Arbeitskontrolle
niederschlagen.
Die Ergebnisse dieser Studie zeigen jedoch nicht nur die Unterschiedlichkeit der von den Unter-
nehmen verfolgten Kontrollstrategien, sondern erlauben es darüber hinaus auch, Faktoren zu be-
stimmen, welche die jeweils verfolgten Kontrollstrategien beeinflußen. Mit den Internationalisie-
rungsvarianten (Captive-Offshoring/Offshore-Outsourcing) und der Situation auf dem indischen
Arbeitsmarkt wurden zwei zentrale Einflußfaktoren auf die jeweils verfolgten Reorganisationss-
trategien herausgearbeitet.

Als wesentliches Differenzierungsmerkmal der beiden Fälle wurde das jeweils verfolgte Ge-
schäftsmodell des Unternehmens und die damit zusammenhängende Form der Internationalisie-
rung von Arbeit berücksichtigt. Dieser Faktor erwies sich als entscheidend für die Frage, inwieweit
das Unternehmen bestrebt ist, die Arbeitsprozesse zu standardisieren und zu formalisieren.
So ließ sich am Beispiel von ServiceTec zeigen, dass die Art der von ServiceTec erbrachten Leis-
tungen und die für IT-Dienstleister typische Form der Kundenbindung ganz wesentliche Auswir-
kungen auf die Organisation und Kontrolle der Arbeit haben und die „Industrialisierung“ der
Arbeitsprozesse in diesem Fall stark begünstigen.
Viele der von ServiceTec erbrachten Leistungen betreffen Tätigkeiten am unteren Ende des
„Software-Lifecycles“, wie die Programmierung und das Testen von Erweiterungen oder kunden-
spezifische Anpassungen von Standardsoftware-Produkten, bzw. die Pflege und Wartung von be-
reits im Betrieb befindlichen Systemen und Applikationen. Diese Tätigkeiten werden aus den Ar-
beitsprozessen der Kundenunternehmen herausgelöst und sind entsprechend häufig bereits von
Kundenseite stark spezifiziert und formalisiert. Zudem sind solche Tätigkeiten – wie im Falle von
Wartungsprojekten – häufig wiederkehrender Natur. Es konnte am Beispiel von ServiceTec gezeigt
werden, dass diese Tätigkeiten intern relativ leicht in kurztaktige Arbeitspakete für die Entwick-
ler heruntergebrochen und prozessförmig organisiert werden können. So gab die vom Kunden
kommende Fehlermeldung in den Wartungsprojekten bei ServiceTec häufig bereits die Form der
Arbeitspakte vor: jeder Beschäftigte erhält eine Fehlermeldung zur Bearbeitung. Die Zuweisung
individuell zu bearbeitender Arbeitsaufgaben wird in diesem Fall also bereits durch die Form, in
der die Arbeitsaufträge vom Kunden an den Dienstleister kommuniziert werden, beeinflußt. Doch
auch in den Fällen, in denen es nicht um reine Wartungsaufgaben geht, beziehen sich die Tätigkei-
ten häufig auf weniger komplexe Erweiterungen bestehender Systeme. Damit wird das bestehende
System bei den Kunden zu einer ersten Einschränkung für die Arbeit der Entwickler auf der Seite
des Dienstleisters, denn es kann von diesen nicht, bzw. nur in Ausnahmefällen beeinflußt werden.
Die Konventionen auf Seite der Kunden werden damit zu einem Rahmen, in dem sich die Ent-
wickler in ihrer Arbeit halten müssen, und die dadurch schon eine gewisse Standardisierung für
die Arbeitsprozesse des Dienstleisters bedingen.
Stärker noch als die Art der an IT-Dienstleister ausgelagerten Tätigkeiten prägt der spezifische
Kundenkontakt die Form der Arbeitsprozesse in jenen Unternehmen. Der Einfluß des Kunden-
kontaktes erstreckt sich dabei auf unterschiedliche Ebenen.
202 Zusammenführung und Ausblick

Zunächst zieht der Kundenkontakt eine typische Form der Arbeitsteilung nach sich. Für IT-
Dienstleister besteht die Notwendigkeit auf der einen Seite in engem Kontakt zu ihren Kunden
zu stehen, auf der anderen Seite aber auch Offshore-Entwicklungszentren in die Arbeitsprozesse
einzubeziehen, um die Kostenvorteile des Offshore-Outsourcings zu realisieren. Aus diesen Anfor-
derungen folgt die mittlerweile als typisch anzusehende Arbeitsteilung zwischen einer kundenna-
hen Vertriebsniederlassung („Frontend“) und Entwicklungszentren in Niedriglohnregionen („Ba-
ckend“). Wie sich zeigen ließ, ging diese interne Arbeitsteilung bei ServiceTec mit einer asymmetri-
schen Verteilung von planenden bzw. konzeptionellen und ausführenden Tätigkeiten einher. Die
Tätigkeiten, für die direkter und unmittelbarer Kontakt zum Kunden nötig ist, konzentrieren sich
in den Onsite-Niederlassungen. Kernstück dieser kundennahen Tätigkeiten waren bei ServiceTec
die Verhandlungen über die Anforderungen an die Leistungen und die Planung der Leistungser-
bringung, wozu vor allem ein erstes technisches Design und ein mit dem Kunden abzustimmender
Projektplan gehört. Sowohl das Design als auch der Projektplan beeinflußen maßgeblich den wei-
teren Verlauf des Projekts und stellen für die Entwickler in den Offshore-Entwicklungszentren
weitgehende Richtlinien für ihre Arbeit dar, auf die sie aus den Offshore-Entwicklungszentren
jedoch nur geringfügig einwirken können.
Zudem begnügen sich die meisten Kunden ServiceTecs nicht damit, die Anforderungen, das
technische Design und evtl. die Projektpläne gemeinsam mit dem Dienstleister zu erstellen, son-
dern versuchen darüber hinaus auch, direkt in die Organisation der Projektarbeiten einzugreifen.
Einerseits, indem anerkannte Zertifizierungen für die Auftragsabwicklung (ISO9001, CMMI, Six
Sigma o.ä.) verlangt werden, und andererseits, indem über vertragliche Vereinbarungen Bearbei-
tungszeiträume und regelmäßige Fortschrittsberichte eingefordert werden.
Die Untersuchung ServiceTecs hat demonstriert, wie weitreichend die Standardisierungswir-
kungen der implementierten Prozessmodelle sind. ServiceTec legt sehr großen Wert auf die um-
fassende Implementierung einer ganzen Reihe von international anerkannten Prozessmodellen.
Gerade als indischer Anbieter von Offshore-Dienstleistungen hat ServiceTec noch mit großen
Vorbehalten der Kunden zu kämpfen, die indischen IT-Dienstleistern keine hohe Qualität der Leis-
tungserstellung zutrauen. So ist die Intensität, mit der bei ServiceTec die Prozessorientierung des
eigenen Geschäftsmodells betont wird, nicht nur – wie später noch argumentiert wird – aber auch
auf die spezielle Kundenbindung zurückzuführen.
Eine ebenso entscheidende Rolle spielen die Kunden auch in Bezug auf die Überwachung der
Arbeitsprozesse. So waren die Forderungen der Kunden nach Meldungen über Stand und Verlauf
der Projektarbeiten in vielen Fällen bei ServiceTec wesentlich kurztaktiger als ServiceTec es von
sich aus angestrebt hätte. In Wartungsprojekten richten sich die vorgegebenen Zeiten, in denen
Fehler behoben sein müssen, häufig nach einer schematischen Klassifizierung eines Fehlers, der
vertraglich ausgehandelte Bearbeitungszeiträume hinterlegt sind. Ein Verstoß gegen diese zeitli-
chen Vorgaben kann Grundlage für Strafzahlungen an den Kunden. Die zeitlichen Vorgaben für
die Entwickler sind daher bei IT-Dienstleistern extrem starr und können auf der Teamebene in den
Offshore-Entwicklungszentren von den Entwicklern nicht beeinflußt werden.
Das von ServiceTec verfolgte Geschäftsmodell und die damit implizierte Form der Internatio-
nalisierung von Arbeit beinhalten also bereits wesentliche Treiber einer Standardisierung und For-
malisierung der Arbeitsprozesse und grenzen die Handlungs- und Gestaltungsspielräume der Ent-
wickler in den Offshore-Entwicklungszentren stark ein.
NovoProd hingegen, als Hersteller von Standardsoftware-Produkten, verfolgt einen ganz ande-
ren Ansatz. Hier wird ein neues Software-Produkt in „verteilter Entwicklung“ hergestellt. Die
Internationalisierung von Arbeit findet in diesem Fall innerhalb des Unternehmens statt (Capti-
ve Offshoring), beinhaltet also keine „Auslagerung“ und eine damit zusammenhängende externe
Reorganisationsmodi zwischen Geschäftsmodell und Standort 203

Kundenbindung. Das indische Entwicklungszentrum soll vielmehr einen wichtigen Teil zur Ent-
wicklung eines neuen Softwareprodukts beitragen. Gegenüber ServiceTec konnte bei NovoProd
gezeigt werden, dass das von NovoProd verfolgte Geschäfts- und Verlagerungsmodell Eigenschaf-
ten aufweist, die eher permissive Formen der Arbeitskontrolle im indischen Entwicklungszentrum
begünstigen.
Zunächst handelt es sich bei dem Arbeitsgegenstand um eine Produktinnovation NovoProds.
Zwar wird auf bereits vorher genutzte Technologien zurückgegriffen, die Form, in der diese Tech-
nologien eingesetzt werden, ist jedoch gänzlich neu im Produktportfolio NovoProds. Es gibt daher
keine umfassenden formalen Vorgaben darüber, wie das neue Produkt zu entwickeln ist. Zudem
entwickeln alle an der Entwicklung beteiligten Einheiten NovoProds ihren Teil parallel. Aus die-
sem Setup folgen erhebliche Unwägbarkeiten bei der Planung der Entwicklungsarbeiten. So kön-
nen im indischen Entwicklungszentrum nicht alle nötigen Arbeitsschritte zur Entwicklung der
Screens vom Management klar und verbindlich im Voraus spezifiziert werden, da die dort ablau-
fenden Arbeiten höchst anfällig für „externe Störungen“ durch die anderen beteiligten Teams sind.
Diese Interdependenz der Arbeitsprozesse erschwert auch die zeitliche Strukturierung der Arbei-
ten. Zwar werden durch das Steuerungsgremium die Waves der Entwicklung festgelegt, doch dabei
handelt es sich eher um Zeiträume von mehreren Monaten, innerhalb derer die zeitliche Planung
relativ flexibel gehandhabt werden muss, um auf unvorhersehbare Ereignisse reagieren zu können.
Die Untersuchung hat gezeigt, dass diese Gründe wesentlich dazu beitragen, dass NovoProd bei der
Aufgabenorganisation darauf setzt, dass die Entwickler möglichst selbst ihre Aufgabenbearbeitung
organisieren und auf die Unwägbarkeiten selbstständig und problemlösend reagieren. Grundlage
dafür ist auch die intensive Kooperation innerhalb des Teams - die Beschäftigten erhalten zwar auch
individuelle Arbeitspakete, jedoch sind diese häufig nur gemeinsam zu bearbeiten und auftretende
Probleme erfordern ein gemeinsames Vorgehen.
Die Interdependenz der „verteilten Entwicklung“ führt darüber hinaus auch zu hohen Abstim-
mungsbedarfen zwischen den beteiligten Einheiten. Zwar ist das Produkt in verschiedene Module
zerlegt und die Trennung ist auch eindeutig gezogen, jedoch können Änderungen an bestimmten
Teilen eines Moduls Änderungen in anderen nach sich ziehen. Wenn demnach z.B. in der Plattform
bestimmte Variablen verändert werden, muss auch der Entwickler bei Application diese Änderun-
gen berücksichtigen. Es kann zwar konstatiert werden, dass NovoProd versucht, die Schnittstellen
der Module möglichst zu standardisieren, jedoch treten im Laufe des Projektes auch an diesen
Punkten Änderungen auf. Und auch wenn die Schnittstellen fix sind, besteht trotzdem erhöhter
Informationsbedarf zwischen den Einheiten, um die Module optimal aufeinander abzustimmen.
So ist die Kommunikationsintensität zwischen Vision, Platform und Application nach Aussagen der
verantwortlichen Projektmanager so hoch, dass eine Kanalisierung und Formalisierung der Kom-
munikation zwischen den Einheiten bei NovoProd wenn überhaupt möglich, dann eher hinderlich
für die Effizienz der Arbeitsprozesse wäre. Auch hier verläßt sich NovoProd darauf, dass die inten-
sive Kooperation und Kommunikation zwischen den beteiligten Einheiten am besten multilateral
auf der Ebene der beteiligten Entwickler geregelt werden kann. Dementsprechend groß ist auch
die Relevanz persönlicher Kontakte und Netzwerke zwischen den Beschäftigten bei NovoProd.

Viele der in den Fallstudien herausgearbeiteten Unterschiede in der Form der Arbeitsprozess-
kontrolle können demnach auf die jeweils verfolgten Geschäftsmodelle der beiden Unternehmen
zurückgeführt werden. Gleichzeitig zeigte sich jedoch auch, dass die Kontrollstrategien der beiden
Unternehmen in ihren indischen Entwicklungszentren nicht ohne Berücksichtigung des lokalen
Arbeitsmarktes verstanden werden können. Besonders deutlich konnte dies bei NovoProd gezeigt
werden. Die Probleme NovoProds, ihre strategische Zielstruktur im indischen Entwicklungszen-
204 Zusammenführung und Ausblick

trum zu implementieren, konnten auf die hohen Fluktuationsraten am indischen Standort zurück-
geführt werden. Die dadurch verursachten häufigen Wechsel in der Zusammensetzung der Projekt-
teams verhinderten entscheidend den Aufbau des bei NovoProd wichtigen Erfahrungswissens im
Umgang mit den eingesetzten Technologien und Methodologien und den Besonderheiten des Pro-
dukts. Zudem dauert es sehr lange, die für die enge Kooperation nötigen persönlichen Netzwerke
zu den anderen Einheiten NovoProds zu knüpfen, und die Kommunikations- und Kooperationsbe-
ziehungen leiden dementsprechend, wenn Personen häufig das Unternehmen verlassen und ersetzt
werden müssen. Da sich die Fluktuation bei NovoProd in den untersuchten Teams in der letzten
Zeit sehr unterschiedlich entwickelt hatte, konnten die Konsequenzen hoher Fluktuationsraten
auf die Form der Arbeitsorganisation und -kontrolle studiert werden. NovoProd ist in den stär-
ker von Fluktuation betroffenen Teams gezwungen, wesentlich restriktivere Kontrollformen zu
implementieren, als es eigentlich der Firmenstrategie entspricht. Im Falle von NovoProd besteht
also ein Konflikt zwischen der Kontrollstrategie und den implementierten, real vorfindlichen For-
men der Arbeitsprozesskontrolle. Jedoch ist das Vorherrschen von restriktiven Kontrollformen in
den genannten Teams kein Anzeichen einer grundsätzlich beabsichtigen „Industrialisierung“ der
Arbeitsprozesse als Geschäftsstrategie. Vielmehr lassen sie sich erst verstehen, wenn berücksich-
tigt wird, welche Voraussetzungen die Kontrollstrategie NovoProds hat, und inwiefern diese am
indischen Standort erfüllt bzw. teilweise nicht erfüllt werden.
Bei ServiceTec ließen sich die beiden Einflußfaktoren wesentlich weniger eindeutig auseinan-
derhalten. Doch auch bei ServiceTec spielt der lokale Arbeitsmarkt eine wichtige Rolle für die
Organisationform der Arbeitsprozesse. Als indisches Unternehmen hat ServiceTec jedoch eine et-
was andere Beziehung zum indischen Arbeitsmarkt als NovoProd. So ist ServiceTec einerseits von
jeher mit dem indischen Arbeitsmarkt konfrontiert gewesen und das Geschäftsmodell Service-
Tecs hat sich unter dem Einfluß der indischen Arbeitsmarktverhältnisse entwickelt. Andererseits
hat ServiceTec als indisches IT-Dienstleistungsunternehmen den indischen IT-Arbeitsmarkt auch
ganz wesentlich mitgestaltet. Die indische IT-Industrie ist gegenwärtig von IT-Dienstleistungs-
unternehmen dominiert. Der enorme Personalbedarf der indischen IT-Dienstleister führt dazu,
dass ein absoluter Großteil der Beschäftigten den Berufseinstieg in eben jenen Unternehmen er-
lebt und die ersten Erfahrungen mit der IT-Industrie bei diesen Beschäftigten daher auch durch
genau jene Formen der Arbeitsorganisation und -kontrolle geprägt werden2 . Ein Großteil der Jobs
der indischen IT-Industrie befindet sich in den (meist indischen) IT-Dienstleistungsunternehmen.
Es ist von daher kein Wunder, wenn sich die Beschäftigten auch in ihrer Karriereplanung wesent-
lich an den Anforderungsprofilen dieser Arbeitgeber orientieren (vgl. auch Upadhya und Vasavi
2006). Für ServiceTec ist daher die Situation auf dem indischen Arbeitsmarkt nicht in derselben
Weise ein externer Einflußfaktor wie für NovoProd.
Das ist auch der Grund, warum bei ServiceTec die Bemühungen, organisatorisch mit dem Ar-
beitsmarkt umzugehen, geradezu „Hand in Hand“ gingen mit den Anforderungen an die Ar-
beitsprozesse, die auf das Geschäftsmodell zurückgeführt werden können. In der Folge verstärkt
sich dadurch die empirisch konstatierte Tendenz der Standardisierung und Formalisierung der Ar-
beitsprozesse bei NovoProd ganz erheblich. So kann diese Strategie nicht ausschließlich als Ant-
wort auf externe Kundenbindung verstanden werden, sondern gleichzeitig als Ausdruck eines spe-
zifischen Zugriffs auf den indischen Arbeitsmarkt. Wie sich an den zitierten Aussagen der Ge-
sprächspartner bei ServiceTec ausführlich belegen ließ, spielt die Standardisierung der Arbeitspro-
zesse bei ServiceTec immer in mehrerlei Hinsicht eine Rolle: einmal als Qualitätsausweis dem Kun-

2
Für eine ausführlichere Erörterung des Einflußes der indischen IT-Unternehmen auf die politische und wirtschaftli-
che Struktur der indischen IT-Industrie, siehe auch Mayer-Ahuja 2011
Reorganisationsmodi zwischen Geschäftsmodell und Standort 205

den gegenüber, darüberhinaus aber auch gleichzeitig immer als Möglichkeit, die Arbeitsprozesse
gegen Personalfluktuation zu immunisieren und das beabsichtigete Wachstum des Unternehmens
durch die Möglichkeit von Massenrekrutierungen und schneller Einarbeitungszeit zu gewährleis-
ten. So muss auch für ServiceTec konstatiert werden, dass die real vorfindliche Form der Arbeitsor-
ganisation und -kontrolle das Ergebnis eines Zusammenspiels von Geschäftsmodell und indischem
Arbeitsmarkt ist, auch wenn das Zusammenwirken nicht ähnlich konflikthaft aufscheint wie bei
NovoProd.
Der interessante Punkt bei der Untersuchung des Arbeitsmarkteinflusses auf die Form der Ar-
beitsorganisation und -kontrolle der beiden untersuchten Fallunternehmen ist, dass beide Unter-
nehmen einen je spezifischen Umgang mit den Anforderungen des Arbeitsmarktes gefunden ha-
ben. Obwohl beide Unternehmen auf dem selben Arbeitsmarkt aktiv sind, erfahren sie aufgrund
ihres spezifischen Geschäftsmodells eine jeweils spezifische Mischung aus Möglichkeiten und Risi-
ken. Die beiden untersuchten Unternehmen verhielten sich dabei geradezu komplementär zuein-
ander.
ServiceTec positioniert sich vor allem im Bereich der Berufseinsteiger, rekrutiert eine große Zahl
von Uniabsolventen, schult diese intensiv und setzt sie anschließend flexibel je nach Bedarf im
Unternehmen ein. Die Standardisierung der Arbeitsprozesse ist in diesem Zusammenhang Vor-
aussetzung und Folge eines solchen Vorgehens: einerseits dürfen die Tätigkeitsprofile der Entwick-
ler nicht derart beschaffen sein, dass sie viel Erfahrung und vertiefte Kenntnisse in bestimmten
Technologien, Geschäftsbereichen o.ä. erfordern, damit die Neueingestellten möglichst schnell
produktiv mitarbeiten können. Die „industrialisierten“ Arbeitsprozesse sind in dieser Hinsicht
also die Voraussetzung für die Rekrutierungsstrategie. Gleichzeitig führen derart beschaffene Tä-
tigkeitsprofile anderseits auch dazu, dass die Jobzufriedenheit der Beschäftigten gering ist und sie
deshalb schnell an Wechsel der Tätigkeiten innerhalb wie außerhalb des Unternehmens denken.
Die dadurch ausgelöste Fluktuation, entweder als Rotation innerhalb des Unternehmens oder
durch den Wechsel zu einer anderen Firma, bildet wiederum den Grund für weitere Standardisie-
rungsbestrebungen im Unternehmen. In dieser Hinsicht ist die Fluktuation auf dem Arbeitsmarkt
der Grund für Standardisierungsbemühungen, um die Arbeitsprozesse von einzelnen Beschäftig-
ten unabhängig zu machen. Das Geschäftsmodell, das seinerseits bereits die Standardisierung der
Arbeitsprozesse begünstigt, ermöglicht also ServiceTec auf der einen Seite, eine solche Rekrutie-
rungsstrategie zu verfolgen und damit auch die ehrgeizigen Wachstumspläne der letzten Jahre zu
realisieren. Auf der anderen Seite wirkt die dadurch geschaffene Fluktuation gleichzeitig auch als
äußerer Faktor auf ServiceTec und zwingt zu organisatorischen Maßnahmen, damit umzugehen.
NovoProd hingegen fokussiert auf den Bereich der bereits berufserfahrenen Beschäftigten auf
dem indischen Arbeitsmarkt, die ihre ersten Jahre meist in den indischen IT-Dienstleistungsunter-
nehmen verbracht haben. Der geringere Personalbedarf aufgrund des langsamen Aufbaus des indi-
schen Standortes und des spezifischen Geschäftsmodells, das wesentlich weniger personalintensiv
ist als das der IT-Dienstleister, befähigt NovoProd dazu, gezielt jene Beschäftigten auszuwählen,
die aufgrund der Art und Qualität der Arbeit eine Beschäftigung bei NovoProd anstreben und
damit die Bereitschaft mitbringen, sich auch über längere Zeit intensiv in bestimmte Tätigkeiten
zu vertiefen und einzuarbeiten - eine Bereitschaft auf der die strategische Zielstruktur NovoProds
beruht. Das Geschäftsmodell NovoPords bietet diesen Beschäftigten auch die Möglichkeiten, sich
intensiv in bestimmte fachliche Spezialbereiche einzuarbeiten und in größerem Maße Verantwor-
tung für ihre Tätigkeiten zu übernehmen.
Die Rekrutierungsstrategien ServiceTecs und NovoProds koexistieren also in ihrer Unterschied-
lichkeit, indem sie andere Personengruppen auf dem Arbeitsmarkt adressieren. Die Strategie Ser-
viceTecs fungiert dabei geradezu als Voraussetzung des Vorgehens NovoProds, indem in den indi-
206 Zusammenführung und Ausblick

schen IT-Dienstleistern die Beschäftigten ihre ersten Erfahrungen mit der IT-Branche machen und
gleichzeitig die technischen Qualifikationen erweitern, die NovoProd in seiner Strategie für eine
Beschäftigung voraussetzt.
Ähnlich komplementär sind auch die Strategien im Umgang mit Personalfluktuation. Es ist
dabei wenig überraschend, dass ServiceTec angesichts der Rekrutierungsstrategie und den damit
korrespondierenden Tätigkeitsprofilen grundsätzlich mit höheren Fluktuationsraten konfrontiert
ist als NovoProd. Allerdings befähigt die Form der Arbeitsorganisation ServiceTec auch, diese
Fluktuation organisatorisch zu kanalisieren, weil die Arbeitsprozesse auch von höheren Fluktua-
tionsraten nicht gefährdet werden, wenngleich dies nicht bedeutet, dass ServiceTec sich nicht auch
bemühen würde, die Fluktuationsraten zu senken. Für NovoProds Strategie hingegen stellen Fluk-
tuationsraten ein gravierendes Problem bei der Herstellung ihrer organisatorischen Zielstruktur
dar. Da die Zielstruktur der Möglichkeit Grenzen setzt, die Arbeitsprozesse durch Standardisie-
rung und Formalisierung gegen Fluktuation zu immunisieren, genießen hier Maßnahmen zur Re-
duzierung der Personalfluktuation höchste Priorität.
In ihrem Bemühen, die Flukuationsraten im Unternehmen zu senken, betonen beide Unter-
nehmen die jeweiligen Vorzüge, die sich aus ihrem verfolgten Geschäftsmodell ergeben: ServiceTec
kann seinen Beschäftigten aufgrund des rasanten Wachstums und der spezischen Natur der Pro-
jektorganisation im IT-Dienstleitungsgeschäft schnelle Aufstiegsmöglichkeiten und damit auch at-
traktive und „planbare“ Karrierewege bieten. Zudem stellt die im Geschäftsmodell angelegte Mög-
lichkeit eines „Onsite-Postings“ zum Kunden eine Attraktivität für die Beschäftigten dar. Dieser
Bereich ist für NovoProd eher problematisch. Das Geschäftsmodell NovoProds beruht darauf, dass
Beschäftigte in Niedriglohnregionen auch dort bleiben, weil ein Posting in eine Hochlohnregion
den Kostenvorteil des globalen Setups schmälern würde und ein Onsite-Team, wie bei ServiceTec,
nicht nötig ist3 . Gleichzeitig ist das indische Entwicklungszentrum auch Teil des Gesamtunter-
nehmens, und der Möglichkeit, die Beschäftigten dort gänzlich anders zu behandeln als in den
anderen Standorten, sind Grenzen gesetzt, wenn z.B. über mögliche Beförderungen und Gehalts-
steigerungen im deutschen Mutterhaus entschieden wird. Die Rede von der „internal parity“ bei
NovoProd verweist genau auf diesen Umstand, der in der Folge dazu führte, dass NovoProd in
den Bereichen Gehaltsentwicklung und Karriereverläufe droht, den Anschluß an die Standards des
indischen Standortes zu verlieren.
NovoProd legt zum Zweck der Fluktuationsreduzierung den Schwerpunkt eher auf die arbeits-
inhaltlichen Anreize für die Beschäftigten, indem attraktive Arbeit in neuen und anspruchsvollen
Technologien und große Verantwortungsspielräume für die Beschäftigten angeboten werden. In
diesem Bereich sind ServiceTec hingegen enge Grenzen gesetzt, bedeutet Arbeit bei einem Dienst-
leister doch, dass häufig mit veralteten Technologien der Kunden gearbeitet werden muss und die
von Kunden an Dienstleister ausgelagerten Tätigkeiten oft in ihrer Komplexität und ihrem An-
spruch begrenzt sind.
So wie sich bereits im Hinblick auf die Rekrutierungsstrategien beider Unternehmen konsta-
tieren ließ, fokussieren beide Unternehmen auf unterschiedliche Zielgruppen auf dem indischen
Arbeitsmarkt. Dementsprechend unterscheiden sich auch die Bemühungen, für diese Zielgruppe
attraktiv zu sein und diese Zielgruppe auch im Unternehmen zu halten. Daher sind sowohl Ser-
viceTec als auch NovoProd, auch wenn sie beide in Indien operieren und damit auf den gleichen
Arbeitsmarkt angewiesen sind, mit unterschiedlichen Herausforderungen konfrontiert, da sie den
indischen Arbeitsmarkt in einer jeweils eigenen Weise adressieren und organisatorisch zu bearbei-
3
Eine Ausnahme bilden die „Brückenköpfe“ - eine Funktion, für die Beschäftigte im indischen Entwicklungszentrum
mangels Erfahrung und persönlicher Netzwerke am deutschen Standort nur selten geeignet sind
Reorganisationsmodi zwischen Geschäftsmodell und Standort 207

ten versuchen.

Die Ergebnisse dieser Studie verweisen damit auf ein sehr komplexes Wechselspiel zwischen den
von Unternehmen verfolgten Internationalisierungsstrategien (und den damit zusammenhängen-
den Geschäftsmodellen) und den Arbeitsmarkt-Bedingungen am jeweiligen Standort, das die For-
men der Arbeitsorganisation und -kontrolle im Zuge der Internationalisierung der IT-Industrie
wesentlich beeinflußt.
208 Zusammenführung und Ausblick

7.3 Zur zukünftigen Untersuchung betrieblicher

Reorganisationsmodi im Zuge der Internationalisierung der
IT-Industrie
Der Reichweite der vorliegenden Studie sind aufgrund des gewählten Designs Grenzen gesetzt. So
beschränkte sie sich mit einem deutschen Produkthersteller und einem indischen IT-Dienstleister
zwar auf zwei typische, nichtsdestotrotz aber nur auf zwei Fälle. Ebenso wurde mit Indien zwar
der gegenwärtig wichtigste Offshore-Standort, aber eben nur ein Standort in die Untersuchung
einbezogen. Die Ergebnisse dieser Studie verweisen ganz zentral auf den kontingenten Charakter
der Entwicklung der Formen von Arbeitsorganisation und -kontrolle im Zuge ihrer Internatio-
nalisierung, indem sie mit den variierenden Internationalisierungswegen und den Arbeitsmärkten
der Ziel-Standorte zwei Faktoren herausgearbeitet hat, die in ihrem Wechselspiel die betrieblichen
Reorganisationsmodi von Arbeit wesentlich beeinflußen. Damit rufen die Ergebnisse zur Vorsicht
auf, aus den präsentierten Fällen stark verallgemeinernde Aussagen zu ziehen. Immerhin war die
Studie angetreten, die in der Debatte prominente „Industrialisierungsthese“, die eine eher einheit-
liche Veränderungsdynamik der Gesamtbranche prognostiziert, zu kritisieren. Dementsprechend
ist nicht beabsichtigt, aus den beiden ausführlich erläuterten (Re-)Organisationsmodi bei Service-
Tec und NovoProd repräsentative Aussagen zu Formen der Arbeitsorganisation und -kontrolle in
international operierenden IT-Unternehmen abzuleiten. So wenig von der Form der Arbeitsor-
ganisation und -kontrolle von ServiceTec generell auf die Reorganisation von Arbeit im Bereich
der IT-Dienstleistungen geschlossen werden darf, so wenig gilt dies auch für NovoProd und den
Bereich der Standardsoftware-Entwickler.
Ebenso wurden mit den verfolgten Geschäftsmodellen und den Arbeitsmärkten vor Ort zwar
zwei Faktoren herausgearbeitet, die in Bezug auf die betrieblichen Reorganisationsmodi von be-
sonderer Bedeutung sind, jedoch kann kaum behauptet werden, mit diesen beiden Faktoren die
Varianz betrieblicher Kontrollstrategien im Zuge der Internationalisierung der IT-Industrie um-
fassend erklären zu können.
Vielmehr sollten die präsentierten Ergebnisse dieser Studie als Plädoyer für weitere – und diffe-
renzierte – Forschung in diesem Bereich verstanden werden. Die Vertreter der „Industrialiserungs-
these“ weisen zurecht darauf hin, dass die Formen der Organisation und Kontrolle von Arbeit
im Zuge der Internationaliserung der IT-Industrie in Bewegung geraten und dass es Anzeichen
dafür gibt, dass sich die traditionell eher permissiven Formen der Kontrolle von IT-Arbeit in ei-
nigen Bereichen in Richtung zunehmend restriktiver Kontrollformen verändern. Daher bildet die
zunehmende Internationalisierung der IT-Industrie einen spannenden und wichtigen Forschungs-
gegenstand. Falsch wäre aber, aus diesen Anzeichen einen branchenweiten „Metatrend“ abzuleiten.
Schon der begrenzte Zugriff der vorliegenden Studie zeigt, dass die Etablierung globaler Produk-
tionsstrukturen ganz unterschiedliche Strategien im Hinblick auf die Organisation und Kontrolle
von Arbeit beinhalten kann.
Diese Studie zu zwei Einflußfaktoren auf die betrieblichen Reorganisationsmodi von Arbeit
im Zuge der Internationalisierung der IT-Industrie sollte daher als Auftakt zu einer Forschung ver-
standen werden, die sich der entstehenden „neuen Geographie“ der IT-Industrie empirisch differen-
ziert annähert und die Folgen der Internationalisierung für die Beschäftigten untersucht. Zukünf-
tige Forschung wird nicht nur weitere Standorte in die Untersuchung mit einbeziehen müssen,
sondern zudem weitere Faktoren zu identifizieren haben, die sich auf die betrieblichen Reorgani-
sationsmodi von Arbeit auswirken, um der Komplexität der Entwicklung gerecht zu werden.
8 Anhang

8.1 Interviews bei ServiceTec

Nummer Standort Geschlecht Funktion

1 SI w Entwicklerin
2 SI w Entwicklerin
3 SI m Projektmanager
4 SI m höheres Management
5 SI w höheres Management
6 SI m Senior Projektmanager
7 SI m Personalabteilung
8 SI 3xm Vertreter des Gebäudemanagements
9 SI m höheres Management
10 SI w Personalabteilung (Cultural Trainings)
11 SI m höheres Management
12 SI w Modulleiterin
13 SI w Entwicklerin
14 SI m Modulleiter
15 SI m höheres Management
16 SI m höheres Management
17 SI m Senior Projektmanager
18 SI w Kundenbetreuerin
19 SI m Projektmanager
20 SI m Entwickler
21 SI w Entwicklerin
22 SI w Modulleiterin
1 SD m Kundenbetreuer
2 SD m Senior Software Architekt
3 SD m Kundenbetreuer
4 SD m Kundenbetreuer
5 SD w Senior Kundenbetreuerin
6 SD m Business Development Manager
7 SD m höheres Management

209
210 Anhang

Nummer Standort Geschlecht Funktion

8 SD m Senior Projektmanager
9 SD w Personalabteilung

Tabelle 8.1: Interviews bei ServiceTec in Deutschland (SD) und Indien (SI)

8.2 Interviews bei NovoProd

Nummer Standort Geschlecht Funktion

1 NI m Personalmanager
2 NI m Entwickler
3 NI w Entwicklerin
4 NI m Personalmanager
5 NI m Qualitätsbeauftragter
6 NI m Personalmanager
7 NI m Projektmanager
8 NI m Entwickler
9 NI m Entwickler
10 NI m Entwickler
11 NI m Projektmanager
12 NI m Entwickler
13 NI m fachlicher Leiter
14 NI m Entwickler
15 NI m Personalabteilung
16 NI m Personalabteilung
17 NI w Projektmanagerin
18 NI m Qualitätsbeauftragter
19 NI w Qualitätsbeauftragte
20 NI m Projektmanager
21 NI m Entwickler
22 NI m fachlicher Leiter
23 NI m Entwickler
24 NI m Personalmanager
25 NI m Personalmanager
26 NI m höheres Management
27 NI m Projektmanager
28 NI m fachlicher Leiter
29 NI m Vertreter des Gebäudemanagements
Interviews bei NovoProd 211

Nummer Standort Geschlecht Funktion

1 ND m höheres Management
2 ND m Entwickler
3 ND w Personalabteilung
4 ND m Entwickler
5 ND m Software-Architekt
6 ND m höheres Management
7 ND m Software-Architekt
8 ND m fachlicher Leiter
9 ND m Personalabteilung

Tabelle 8.2: Interviews bei NovoProd in Deutschland (ND) und Indien (NI)
212 Anhang
Literatur
Abraham, Vinoj und R. K. Sharma (2005): “New Technology and the emerging labour market: a
study of Indian IT industry”, in: The Indian Journal of Labour Economics 48.4, S. 789–802.
Adler, P. S. (2006): “Beyond Hacker Idiocy: A New Community in Software Development”, in:
The Firm as a Collaborative Community: Reconstructing Trust in the Knowledge Economy, hrsg.
von C. Heckscher und P. S. Adler, New York, S. 198–259.
Alvesson, Mats (2004): Knowledge Work and Knowledge Intensive Firms, Oxford.
Arora, Ashish (2006): The Indian Software Industry and its Prospects, abgerufen am 15.11.2007,
Working Paper 2006-23, H. John Heinz III School of Public Policy & Management, URL:
[Link]
Arora, Ashish u. a. (2001): “The Indian software service industry”, in: Research Policy 30, S. 1267–
1287.
Aspray, William, Frank Mayadas und Moshe Y. Vardi (2006): Globalization and Offshoring of Soft-
ware, abgerufen am 5.1.2009, URL: [Link]
[Link].
Athreye, Suma S. (2005a): “The Indian Software Industry”, in: From Underdogs to Tigers, hrsg. von
Ashish Arora und Alfonso Gambardella, Oxford, S. 7–40.
— (2005b): “The Indian software industry and its evolving service capability”, in: Industrial and
corporate change 14.3, S. 393–418.
Barrett, Rowena (2005): “Managing the software development labour process: direct control, time
and technical autonomy”, in: Management, Labour Process and Software Development - Reality
bytes, hrsg. von Rowena Barrett, New York, S. 76–99.
BITKOM (2005): Leitfaden Offshoring, abgerufen am 14.01.2009, URL: [Link]
g/files/documents/BITKOM_Leitfaden_Offshoring_31.[Link].
Boes, Andreas (2004): “Offshoring in der IT-Industrie. Strategien der Internationalisierung und
Auslagerung im Bereich Software und IT-Dienstleistungen”, in: Herausforderung Offshoring,
hrsg. von Andreas Boes und Michael Schwemmle, Düsseldorf, S. 9–140.
Boes, Andreas und Andrea Baukrowitz (2002): Arbeitsbeziehungen in der IT-Industrie, Berlin.
Boes, Andreas, Tobias Kämpf und Katrin Trinks (2005): “Eine neue Phase in der IT-Industrie:
Industrialisierung, Internationalisierung und Innovation”, in: FIfF-Kommunikation 4, S. 46–
50.
Boes, Andreas und Michael Schwemmle, Hrsg. (2004): Herausforderung Offshoring - Internationa-
lisierung und Auslagerung von IT-Dienstleistungen, Düsseldorf.
Boes, Andreas und Katrin Trinks (2006): "Theoretisch bin ich frei!", Berlin.
Boes, Andreas u. a. (2006): Entwicklungsszenarien der Internationalisierung im Feld Software und
IT-Dienstleistungen, abgerufen am 20.11.2010, Arbeitspapier 2 des Projektes Export-IT, URL:
[Link]
Boes, Andreas u. a. (2007): „The world is flat“ - Nachhaltige Internationalisierung als Antwort auf die
Herausforderungen einer globalen Dienstleistungswirtschaft, abgerufen am 22.02.2010, Arbeits-
papier 3 des Projekts Export IT, URL: [Link]
papier3_final.pdf.

213
214 Literatur

Borrus, Michael und John Zysman (1997): Wintelism and the Changing Terms of Global Competi-
tion. Prototype of the Future?, abgerufen am 29.11.2010, BRIE Working Paper 96B, Berkeley,
URL: [Link]
Braverman, Harry (1980): Die Arbeit im modernen Produktionsprozess, New York.
Brenner, Walter u. a. (2007): IT-Industrialisierung: Was ist das?, abgerufen am 17.12.2008, Compu-
terwoche, URL: [Link]
Castells, Manuel (1996): The Information Age: Economy, Society and Ciulture. Vol. I: The Rise of the
Network Society, Oxford.
Crozier, Michel und Erhard Friedberg (1979): Macht und Organisation – Die Zwänge kollektiven
Handelns, Königstein.
Deutsche Bank Research (2005): Outsourcing nach Indien: Der Tiger auf dem Sprung, abgerufen am
29.11.2010, URL: [Link]
[Link].
Deutschmann, Christoph (2002): Postindustrielle Industriesoziologie, Weinheim und München.
Dossani, Rafiq (2007): “Entrepreneurship. The true story behind Indian IT”, in: Making IT - The
rise of Asia in high tech, hrsg. von Henry S. Rowen, Marguerite Gong Hancock und William F.
Miller, Stanford (California), S. 221–266.
Dossani, Rafiq und Martin Kenney (2004): “Moving Tata Consultancy Services into the “Global
Top 10””, in: Journal of Strategic Management Education 1.2, S. 383–402.
Edwards, Richard (1981): Herrschaft im modernen Produktionsprozeß, New York.
Farrell, Diana, Noshir Kaka und Sascha Stärze (2005): Ensuring Indias offshoring future, abgerufen
am 29.11.2010, McKinsey Quarterly Special Edition, URL: [Link]
[Link]/Operations/Outsourcing/Ensuring_Indias_offshoring_future_1660?gp=1.
Farrell, Diana u. a. (2005): The Emerging Global Labor Market: Part I—The Demand for Offshore
Talent in Services, abgerufen am 29.11.2010, McKinsey Global Institute (MGI), URL: http:
//[Link]/mgi/reports/pdfs/emerginggloballabormarket/Part1/MGI_dem
and_executivesummary.pdf.
Flecker, Jörg (2006): “Verlagerung von Arbeit und die Umstrukturierung der globalen Informa-
tionswirtschaft”, in: Informatisierung der Arbeit - Gesellschaft im Umbruch, hrsg. von Andrea
Baukrowitz u. a., Berlin, S. 335–345.
Flecker, Jörg und Ursula Holtgrewe (2008): “Überbetriebliche Arbeitsteilung: Auslagerung von
Unternehmensfunktionen und die Folgen für Arbeit und Beschäftigung”, in: Wirtschaft und
Gesellschaft 3, S. 307–336.
Flecker, Jörg und Pamela Meil (2010): “Organisational restructuring and emerging service value
chains: implications for work and employment”, in: Work, Employment & Society 24.4, S. 680–
698.
Flecker, Jörg u. a. (2007): Restructuring across value chains and changes in work and employment,
abgerufen am 29.11.2010, WP 10 des WORKS-Projekts, URL: [Link]
be/documents/[Link].
Forrester Research (2004): “Offshore-Trend schafft neue Konkurrenz. Exklusive Studie von For-
rester Research und Computerwoche”, in: Computerwoche 23, S. 32–33.
Fortanier, Fabienne und Rob van Tulder (2009): “Internationalization trajectories–a cross-country
comparison: Are large Chinese and Indian companies different?”, in: Industrial and Corporate
Change 18.2, S. 223–247.
Friedman, Andrew L. (1977): “Responsible Autonomy versus direct control over the labour pro-
cess”, in: Capital & Class 3, S. 43–57.
Literatur 215

— (1987): “Managementstrategien und Technologie: Auf dem Weg zu einer komplexen Theorie
des Arbeitsprozesses”, in: Managementstrategien und Kontrolle - Eine Einführung in die Labour
Process Debate, hrsg. von Rüdiger Hildebrandt Eckart; Seltz, Berlin, S. 99–131.
— (1990a): “Four phases of information technology : Implications for forecasting IT work”, in:
Futures 22.8, S. 787–800.
— (1990b): “Managerial Strategies, Activities, Techniques and Technology: Towards a Complex
Theory of the Labour Process”, in: Labour Process Theory, hrsg. von David Knights und Hugh
Willmott, S. 177–209.
— (1992): “Understanding the employment position of computer programmers: a managerial
strategies approach”, in: Social dynamics of the IT field - The case of Denmark, hrsg. von Finn
Borum, Berlin/New York, S. 237–259.
Hackmann, Joachim (2010): “Global Sourcing”, in: Computerwoche 36, S. 12–16.
Heeks, Richard (1995): “Global Software Outsourcing to India by Multinational Corporations”,
in: Global Information Technology and Systems management: Key Issues and Trends, hrsg. von
Prashant Palvia, Shailendra Palvia und Edward Mozley Roche, Nashua (NH), S. 365–392.
Heidenreich, Martin (2003): “Die Debatte um die Wissensgesellschaft”, in: Wissenschaft in der Wis-
sensgesellschaft, hrsg. von Stefan Böschen und Ingo Schulz-Schaeffer, Opladen, S. 25–55.
Heidenreich, Martin und Karin Töpsch (1998): “Die Organisation von Arbeit in der Wissensge-
sellschaft”, in: Industrielle Beziehungen 5.1, S. 13–45.
Herbsleb, James u. a. (1997): “Software Quality and the Capability Maturity Model”, in: Commu-
nications of the ACM 40.6, S. 30–40.
Herbsleb, James D. und Deependra Moitra (2001): “Global Software Development”, in: IEEE Soft-
ware 18.2, S. 16–20.
Ilavarasan, P. Vigneswara (2007): “Software Workforce”, in: Alternative Economic Survey 2006-07:
Pampering Corporates, Pauperizing Masses, hrsg. von Alternative Survey Group, Delhi, S. 253–
260.
Janßen, Rainer (2005): “Die Psychologie des Entwicklers”, in: Informatik Spektrum 4, S. 284–286.
Kalkowski, Peter und Otfried Mickler (2005): Projektorganisation in der IT- und Medienbranche,
Düsseldorf.
— (2009): Antinomien des Projektmanagements. Eine Arbeitsform zwischen Direktive und Frei-
raum, Berlin.
Kotthoff, Hermann (1997): Führungskräfte im Wandel der Firmenkultur. Quasi-Unternehmer oder
Arbeitnehmer?, Berlin.
Kraft, Philip, Hrsg. (1979): Case Studies on the Labor Process, New York.
Kraft, Philip und Steven Dubnoff (1986): “Job Content, Fragmentation, and Control in Computer
Software Work.”, in: Industrial Relations 25.2, S. 184–196.
Kunda, Gideon (1992): Engineering Culture, Philadelphia.
Kämpf, Tobias (2008): Die neue Unsicherheit. Folgen der Globalisierung für hochqualifizierte Arbeit-
nehmer, Frankfurt/New York.
Lacity, Mary, Prasad Rudramuniyaiah und Vidya Iyer (2008): “Understanding turnover among
Indian IS professionals”, in: Offshore Outsourcing of IT Work, hrsg. von Mary C. Lacity und
Joseph W. Rottman, Barsingstoke, S. 209–244.
Lema, Rasmus und Bjarke Hesbjerg (2003): The Virtual Extension, Roskilde University.
Lüthje, Boy (2006): “Wintelismus zum ’China-Preis’ – Wohin treibt das Produktionsmodell der
IT-Industrie”, in: Informatisierung der Arbeit – Gesellschaft im Umbruch, hrsg. von Andrea
Baukrowitz u. a., Berlin, S. 346–357.
Mayer-Ahuja, Nicole (2011): Grenzen der Homogenisierung, Frankfurt a.M.
216 Literatur

Mayer-Ahuja, Nicole und Patrick Feuerstein (2008): “Everywhere is bescoming the same? Labour
utilisation, regulation and the tensions inherent in transnational IT production”, in: Work,
Organisation, Labour & Globalisation 2.2, S. 162–178.
Mayer-Ahuja, Nicole und Harald Wolf (2005): “Arbeit am Netz: Formen der Selbst- und Fremd-
bindung bei Internetdienstleistern”, in: Entfesselte Arbeit – neue Bindungen, hrsg. von Nicole
Mayer-Ahuja und Harald Wolf, Berlin, S. 61–109.
McKinlay, Alan und Chris Smith, Hrsg. (2009): Creative Labour – Working in the creative indus-
tries, Basingstoke, Hampshire [u.a.]
Meyer, Bertrand (2006): “The Unspoken Revolution in Software Engineering”, in: Computer 39.1,
S. 121–124.
Mukherjee, Sanjukta (2008): “Producing the Knowledge Professional: Gendered Geographies of
Alienation in India’s New High-tech Workplace”, in: In an Outpost of the Global Information
Economy: Work and Workers in India, hrsg. von Carol Upadhya und A. R. Vasavi, Delhi [u.a.],
S. 50–75.
NASSCOM (2007): Indian IT-Industry - Factsheet, abgerufen am 29.9.2009, URL: [Link]
[Link]/Nasscom/templates/[Link]?id=2374.
— (2009): Indian IT-BPO Industry 2009: NASSCOM Analysis, abgerufen am 05.07.2010, URL:
[Link]
— (2010): Industry Trends, abgerufen am 03.03.2010, URL: [Link]
templates/[Link]?id=56966.
Nasscom/Hewitt (2008): Nasscom-Hewitt Total Rewards Study 2007-2008, abgerufen am 29.9.2009,
URL: [Link]/upload/57714/Nasscom_Hewitt_Total_RewardsPresentation_
[Link].
Nath, Pradosh und Amitava Hazra (2002): “Configuration of Indian Software Industry”, in: Eco-
nomic and Political Weekly, Ausgabe vom 23.02.2002, S. 737–742.
Niosi, Jorge und F. Ted Tschang (2009): “The strategies of Chinese and Indian software multinatio-
nals: implications for internationalization theory”, in: Industrial and Corporate Change 18.2,
S. 269–294.
Oecking, Christian, Ralph Jahnke und Harald Kiehle (2009): “Einleitung”, in: Industrialisierung
im Outsourcing, hrsg. von Christian Oecking u. a., BITKOM, S. 1–8.
Parthasarathy Balaji; Aoyama, Yuko (2006): “From software services to R&D services: local entre-
preneurship in the software industry in Bangalore, India”, in: Environment and Planning A
38, S. 1269–1285.
Pohl, Dr. Andreas und Bela R. Onken (2003): Outsourcing und Offshoring mit indischen IT-Unter-
nehmen, abgerufen am 29.11.2010, Deloitte & Touche, URL: [Link]
net/support/[Link]/Studie%20Outsourcing%20und%20Offshoring%20mit%2
0indischen%[Link].
Prasad, Monica (1998): “International Capital on ‘Silicon Plateau’: Work and Control in India’s
Computer Industry.”, in: Social Forces 77.2, S. 429–452.
Radhakrishnan, K. G. (2003): “India’s Software Industry: a Structural Break-Up”, in: Journal of
Indian School of Political Economy 15.3, S. 689–703.
Sahay, Sundeep (2003): “Global software alliances: the challenge of ’standardization’”, in: Scandi-
navian Journal of Information Systems 15, S. 3–21.
Sahay, Sundeep, Brian Nicholson und S. Krishna (2003): Global IT Outsourcing, Cambridge Uni-
versity Press.
Singh, Surjit (2005): “India and the Knowledge Economy: Overview and Global Context”, in: The
Indian Journal of Labour Economics 48.4, S. 803–820.
Literatur 217

Smith, Chris (2006): “The Double Indeterminacy of Labour Power: Labour Effort and Labour
Mobility”, in: Work, Employment and Society 20.2, S. 389–402.
Smith, Chris und Alan McKinlay (2009): “Creative Labour: Content, Contract, and Control”, in:
Creative Labour - working in the creative industries, hrsg. von Alan McKinlay und Chris Smith,
Basingstoke, Hampshire [u.a.], S. 29–50.
Stamm, Andreas (2005): “Perspektiven für Entwicklungsländer? Die Internationalisierung des Dienst-
leistungsmarktes”, in: Bangalore statt Böblingen? Offshoring und Internationalisierung im IT-
Sektor, hrsg. von Andreas Boes und Michael Schwemmle, Hamburg, S. 66–75.
Taubner, Dirk (2001): Industrialisierung hat Konsequenzen, abgerufen am 29.11.2010, Computer-
woche, URL: [Link]
Taylor, Phil (2010): “The Globalization of Service Work: Analysing the Transnational Call Center
Value Chain”, in: Working Life: renewing labour process analysis, hrsg. von Paul Thompson
und Chris Smith, Basingstoke, Hampshire [u.a.], S. 244–268.
Thomas, Jayan Jose (2005): “Labour in the New Economy: An Indian Perspective”, in: The Indian
Journal of Labour Economics 48.4, S. 821–835.
Thompson, Paul (1989): The Nature of Work - An Introduction to Debates on the Labour Process,
London.
Thompson, Paul und David McHugh (2002): Work Organisations, New York.
Töpsch, Karin, Raphael Menez und Norbert Malanowski (2001): “Ist Wissensarbeit regulierbar?
Arbeitsregulation und Arbeitsbeziehungen am Beispiel der IT-Branche”, in: Industrielle Bezie-
hungen 3, S. 306–332.
Upadhya, Carol (2009): “Controlling offshore knowledge workers: Power and agency in India’s
software outsourcing industry”, in: New Technology, Work and Employment 24, S. 1–18.
Upadhya, Carol und A. R. Vasavi (2006): Work, Culture and Sociality in the Indian IT Industry: a
Sociological Study, abgerufen am 22.01.2009, URL: [Link]
[Link].
Voß, Günther und Hans J. Pongratz (1998): “Der Arbeitskraftunternehmer. Eine neue Grundform
der Ware Arbeitskraft”, in: Kölner Zeitschrift für Soziologie 1, S. 131–158.
Walter, Sven Markus, Tilo Böhmann und Helmut Krcmar (2007): “Industrialisierung der IT –
Grundlagen, Merkmale und Ausprägungen eines Trends”, in: HMD - Praxis der Wirtschaftsin-
formatik 256, S. 6–16.
Wikipedia (2010a): Babbage-Prinzip, abgerufen am 26.10.2010, URL: [Link]
g/wiki/Babbage-Prinzip.
— (2010b): Capability Maturity Model Integration, abgerufen am 08.12.2010, URL: [Link]
[Link]/wiki/CMMI.
Willke, Helmut (1998): “Organisierte Wissensarbeit”, in: Zeitschrift für Soziologie 3, S. 161–177.