5.2 ServiceTecs globales Geschäftsmodell
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 innerhalb 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:
„You have to learn to adjust with your team members and to work in a team environment. You sit in a cubicle with 4 people around you, so you
Betriebliche Kontrollstrategien bei ServiceTec 137
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 gegensei-tige Hilfestellung bei Problemen nicht weit hinauszugehen. Wirklich gemeinsam wird auf der Ebene der Entwickler selten gearbeitet, wie eine Entwicklerin aus einem Wartungsprojekt überzeugend klarstellt:
„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 Pro-jektleiter 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 Überschneidung haben, kommt es eher zu Konflikten, wie ein Befragter aus seinem Projekt berichtet. Interessant 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 Hilfe-stellung hinausgehenden 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, die alle ihren klar defi-nierten 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 Aufgabenorganisation im Unternehmen, sondern wird durch eine auf Messung und Bewertung individuell gezeigter Arbeitsleistung ab-zielende Kontrollstruktur unterstützt. Erklärtes Ziel des Bewertungssystems bei ServiceTec ist, die Entwickler um die besten Bewertungen und die damit verbun-denen positiven Sanktionen (Beförderungen, Gehaltssteigerungen) konkurrieren zu lassen. Offensichtlichster Ausdruck dieser Strategie sind, wie gezeigt wurde, die halbjährlich firmenintern veröffentlichten „Rankings“, also die Ranglisten der erreichten Bewertungen im Team, wodurch alle Beschäftigten in eine hierar-chische Beziehung gemäß ihrer Arbeitsleistung gebracht werden.
Darüber hinaus finden sich bei ServiceTec eine ganze Reihe von Wettbewerben, in denen auf individueller Ebene um kleine symbolische Anerkennungen und Titel konkurriert wird, und womit 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 ‘Kinoticket’, 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 Rupees 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-Komplexen 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 Trennwände herausragen und
Betriebliche Kontrollstrategien bei ServiceTec 139
somit für die gesamte Etage sichtbar sind, zeigt die Relevanz, die diesen individu-ellen – 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 Schilderung der anderen Kollegen, die ihre Zeit im Büro verbringen, weil sie sich zuhause langweilen würden, tauchte in der Tat häu-fig in den Interviews auf. Bei näherer Betrachtung ist diese Aussage auch gar nicht so überraschend. Wie im folgenden Abschnitt über die Rekrutierungsstrategie ServiceTecs noch ausgeführt werden wird, rekrutiert ServiceTec auf der Ebene der Entwickler vor allem sogen. „Fresher“, also junge Leute, die gerade die Univer-sität verlassen haben. Dementsprechend 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 dem-nach nicht nur sehr jung, sondern zudem häufig von ihrem bisherigen sozialen Umfeld weit entfernt. Von daher ist es nachvollziehbar, wenn diese Beschäftigten aussagen, dass sie nach Feierabend lieber im Büro bei ihren Kollegen bleiben, als
18 So gibt es z.B. auch einen Wettbewerb um das „most spirited team“.
alleine in ihren Wohnungen 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 Freizeiteinrichtungen, 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 Ge-samtprojektes. Dementsprechend kommt es auch vor, dass im Modul Probleme oder Unklarheiten auftauchen, die mit anderen 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 Kommuni-kation wird bei ServiceTec 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 ebenfalls 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 Kooperationsbezie-hungen zum Onsite-Bereich. Schließlich befinden sich weitere für das Projekt wichtige Kooperationspartner außerhalb 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 zwischen zwei Polen: Auf der einen Seite wird versucht, die Kom-munikation möglichst ausschließlich über den Onsite-Coordinator zu führen
Betriebliche Kontrollstrategien bei ServiceTec 141
und den Kontakt zum Kunden in dieser Person zu bündeln. Dies stellt bei Ser-viceTec den häufigsten Fall dar. Der Kontakt zum Kunden und die 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 kom-muniziert daher nur der Onsite Coordinator mit dem Kunden – die Entwickler, Module Leads und Projektmanager in den Offshore-Entwicklungszentren wen-den sich bei Klärungsbedarf zunächst an wen-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 „Flaschenhals“ entstehen, also ein Engpass in der Kommunikati-onsstruktur, der dann den Informationsfluss 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 Kun-denkontaktes 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 Beziehungen bei ServiceTec stets unter kritischer Beobachtung, weil eine zu starke Gewöhnung der Kunden 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 Informationsfluss 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 Haupt-grund, warum der Kundenkontakt in den meisten der im Rahmen dieser Studie untersuchten Projekte schwerpunktmäß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 angeblich 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 diesen Fällen wird der Kontakt zum Kunden von den Onsite-Personen übernommen, die Deutsch sprechen. Eine direkte Kommunikation zwischen dem Kunden und den indischen Entwicklungszentren ist dann so gut wie ausgeschlossen, da es Offshore bisher nur sehr wenige Personen mit deutschen Sprachkompetenzen gibt19.
Darüber hinaus ist die Form des Kontakts zwischen Kunden und Offshore-Be-schäftigten von der Art des Projektes selber beeinflusst. So berichten Beschäftigte aus Maintenance-Projekten, dass sie häufig direkt mit den Kunden kommunizie-ren.
„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.“
N: And in a maintenance project, that would be different?
„In maintenance project also, if we have a person dedicatedly being located at the client’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 schwer-punktmäßig um Berichte über Defekte an laufenden Systemen, die in vielen Fällen durch Computersysteme strukturiert und in ihrer Form stark standardi-siert und formalistandardi-siert werden. Diese Reporting-Systeme ersetzen in vieler Hin-sicht 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.
19Zum Zeitpunkt der Studie hatte sich ServiceTec gerade dieses Problems angenommen und bot deutsche Sprachkurse für die Beschäftigten an.
Betriebliche Kontrollstrategien bei ServiceTec 143
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, wo-hingegen 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 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 intensiviert.Wenn im Laufe eines Maintenance-Projektes die anfallenden Kooperationsnotwendigkeiten direkt zwischen den Offshore-Projektmanagern und den Kunden diskutiert werden können, wird das Onsite-Team personell verkleinert, was natürlich auch wieder zu Einsparungen führt.
Aber selbst wenn während der Bearbeitungsphase ein Team vor Ort beim Kun-den bleibt, verliert dieses Onsite-Team durch Kun-den direkten KunKun-denkontakt 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 verschärfen. So ist der Kontakt zum Onsite-Koordinator und seinem Team bei ServiceTec sehr dezentral organisiert. Grundsätzlich sollen alle Modulleiter – und nach Rücksprache auch die Entwickler selbst – möglichst direkt mit dem Onsite-Koordinator kommunizieren und ihre Probleme oder Klärungsbedarfe mit diesem diskutieren.
„The onsite coordinator talks to the offshore project manager and talks to the complete team as well at times. Because if the onsite coordinator just talks to the offshore project managers, that does create a long com-munication channel and what we foresee, is, there might be fissure on
the information. Some information might be missed. The onsite coordina-tor 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