OFFSHORE-ZUSAMMENARBEITERFOLGREICH ETABLIERT:EIN PRAXISREPORT ÜBEREIN MIGRATIONSPROJEKTIM MASCHINENBAUDer Artikel beschäftigt sich mit den Erfahrungen, die in einem international ausge-richteten Software-Entwicklungsprojekt unter Einbindung von indischen Offshore-Ressourcen gesammelt wurden. Das Thema des Projekts ist die Migration einerAltanwendung auf moderne Technologien inklusive der Neuentwicklung einerzukunftsfähigen Architektur. Die Fachdomäne des Kunden ist der klassischeMaschinenbau, seine Produkte sind komplexe Strömungsmaschinen. Zweck derApplikation ist es, Konstruktionszeichnungen der Maschinen vollautomatisch zugenerieren. Ausgehend von den Herausforderungen im Kontext der Offshore-Zusammenarbeit werden die gewählten Offshore-Ansätze und die Erfahrungen ausdiesem Projekt beschrieben und diskutiert.

m e h r z u m t h e m a :www.zuehlke.com

50 51

Klaus-Peter Wichmann

(E-Mail: wkl@zuehlke.com) ist Senior

Projektmanager und Berater bei der

Zühlke Engineering AG in der Schweiz.

Sein fachlicher Schwerpunkt liegt im

Bereich der globalen Softwareentwicklung.

In diesem Kontext berät er Unternehmen,

leitet Offshore-Projekte und ist als Trainer

tätig.

Der Auftraggeber des Projekts ist im Ma-schinenbau tätig und stellt im KundenauftragStrömungsmaschinen her. Ein Auftrag umfasstdabei die Konstruktion und die Herstellungder Maschine sowie die Inbetriebnahme vorOrt. Dabei erfolgt die Maschinenkonstruktionauf Basis einer hohen Produktstandardi-sierung. Alle Bauteile sind aufeinander abge-stimmt und können unter Beachtung der tech-nischen Regeln zu einer komplexen Maschinezusammengestellt werden.

Die Auslegung – also die Auswahl derBauteile und die Berechnung der Bauteil-maße – wird durch eine bestehende Appli-kation unterstützt. Nach der automati-schen Auswahl und Auslegung der Bauteileübernimmt eine zweite Applikation – imFolgenden „Zeichnungsgenerator” genannt– die vollautomatische Generierung derKonstruktionszeichnungen. Abbildung 1zeigt beispielhaft ein fiktives Bauteil mitseinen generischen Parametern.

Diese Altapplikationen sind am Endeihres Lebenszyklus angelangt und dieWartung ist sehr aufwändig und teuergeworden. Daher wurde der Entschlussgefasst, sie von Grund auf neu zu entwi-ckeln. In einem ersten Schritt soll zunächstder Zeichnungsgenerator ersetzt und in diebestehende Werkzeugkette migriert wer-den. Vom Auftraggeber gab es dann nocheine Randbedingung für das Projekt: Wennimmer möglich sollten Offshore-Ressour-cen eines indischen Vertragspartners in dieEntwicklung mit eingebunden werden.

der au torf achar t i ke l

Abb. 1: Fiktives Beispiel für eines der 300 Bauteile mit generischen Parametern.

3 / 2 0 0 8

AusgangslageEine Analyse zur Ausgangslage im Off-shore-Kontext ergab das im Folgenden dar-gestellte Bild.

Unzureichende Dokumentationdes AltsystemsDas Altsystem war nur rudimentär bzw.ungenügend dokumentiert. In bestimmtenBereichen fehlte die Dokumentation voll-ständig, in anderen Bereichen war sie nichtmehr auf dem neuesten Stand.

Engpass bei den Fachexpertender ProblemdomäneDie Verfügbarkeit der Fachexperten – alsoder Maschinenbau-Ingenieure des Kunden– war ein wichtiger Erfolgsfaktor imProjekt, auch gerade wegen der unzurei-chenden Dokumentation des Altsystems.Bei diesem Personenkreis lag jedoch einpersoneller Engpass vor. Einerseits gab esnur sehr wenige Mitarbeiter, die über dasnotwendige Fachwissen verfügten, auf deranderen Seite bestand das personelleRisiko, dass sie zur Unterstützung der eige-nen Auftragsabwicklung abgezogen wer-den könnten.

Wenig Erfahrung im Erstellender SpezifikationenDie Fachexperten verfügten über wenigErfahrung, Spezifikationen mit der not-wendigen Qualität und Eindeutigkeit fürdie Offshore-Zusammenarbeit zu schrei-ben. Für lokal durchgeführte Projekte magdies in dem einen oder anderen Fall ja nochgenügen, bei Offshore-Projekten handelt essich jedoch um eine Schlüsselfähigkeit.

Hohe Anforderungen an dieRichtigkeit der KonstruktionsdatenDa die Fertigung zwar nicht ausschließlich,aber zum Teil direkt ab den generiertenZeichnungen erfolgt, gab es hohe An-forderungen an die Richtigkeit der Datenin den Zeichnungen. Im ungünstigsten Fallwerden die Fertigungsfehler erst bei derMontage entdeckt. Die Kosten zur Behe-bung könnten dann sehr hoch ausfallen.

Viele zu beherrschende DetailsFür den Zeichnungsgenerator wird dieErstellung einer Bauteilbibliothek mit ca.300 Elementen benötigt. Jedes Element hatdurchschnittlich 25 Parameter. Insgesamtliegen also ca. 7.500 Parameter vor. DieApplikation kennt weiter die Businesslogik

zur Erstellung von 5 Zeichnungstypen.Diese Logik umfasst neben der Bauteil-bibliothek umfangreiche Regeln für dieVermaßung der Konturen, wie zum BeispielLängen- oder Winkelmaße.

Wie wurde dasProjekt gestartet?Nach der Analyse der Ausgangslage be-schäftigten wir uns mit den konzeptionel-len Fragen zur Zusammenarbeit und damit,wie das Projekt am besten gestartet werdensollte. Die im Folgenden geschilderten fünfAktivitäten bekamen eine hohe Prioritätund wurden früh im Projekt umgesetzt.

Schlüsselrollen besetzenDa das Kernkerngeschäft des Unterneh-mens im Bereich Maschinenbau liegt undweniger im Software-Engineering, wurdenExperten von Zühlke für die Schlüssel-rollen ins Projekt geholt. Dazu gehören derProjektmanager, der Softwarearchitekt mitSchwerpunkt in der Computergrafik sowieder Testmanager. Dieses Kernteam erhieltden Auftrag, das allgemeine Vorgehen, dieEntwicklungsprozesse und die technischenKonzepte zu definieren.

Know-how-Transfer insOffshore-Team sicherstellenKurz nach Projektstart wurde ein Mitar-beiter des Offshore-Partners zur Ausbil-dung vor Ort beim Auftraggeber eingela-den. Dieser Mitarbeiter sollte später inIndien die Rolle des Team-Leaders über-nehmen und Hauptansprechpartner für

f achar t i ke l

■ Der Interaktionsbedarf mit denFachexperten vor Ort ist gering.

■ Die Anforderungen an die Kompo-nente sind bekannt und spezifiziert.

■ Das Verhältnis Aufwand zu Nutzenfür die Erstellung der Spezifikation istwirtschaftlich gerechtfertigt.

■ Die Komponente gehört nicht zurKernkompetenz des Kunden (Ge-heimhaltung, Schutz vor Industrie-spionage).

■ Die Komponente weist eine geringeKomplexität auf.

■ Es bestehen nur geringe Abhängig-keiten zu anderen Applikationen.

Kasten 1: Kriterien zur Einstufung derKomponenten auf ihre Offshore-Tauglichkeit.

den Projektleiter sein. Er begleitete dasProjekt vor Ort für ca. sechs Monate undlernte in dieser Zeit das Fachgebiet, dieAnforderungen, die Architektur und dieEntwicklungskultur gut kennen. Ein ersterWissenstransfer war somit organisiert.

Geeignete Komponenten fürsOffshoring auswählenAuf Basis eines ersten, stabilen Archi-tekturentwurfes wurde dann eine Analyseder Softwarekomponenten auf ihre Eig-nung für die Offshore-Entwicklung durch-geführt. Die angewandten Kriterien für die-se Einstufung sind im Kasten 1 dargestellt.Wichtigstes Kriterium war der „Inter-aktionsbedarf mit den Fachexperten”. Beieinem mittleren bis hohen Bedarf, sollte dieEntwicklung aus wirtschaftlichen Gründenbesser vor Ort erfolgen.

Dem Offshore-Team wurden nach dieserAnalyse die Implementierung und dasTesten der Bauteilbibliothek zugeordnet.Als weitere Aufgabe wurde dem Offshore-Team die Durchführung der Systemtestszugewiesen. Beide Aufgaben umfassten ca.50 % des gesamten Entwicklungsauf-wands.

Das lokale Team war dann verantwort-lich für die Entwicklung der Schnittstellezum Altsystem, für die Entwicklung desDatenmodells der Maschine und für dieBasismechanismen. Warum wurden diesedrei Komponenten lokal entwickelt? DasDatenmodell repräsentiert die Kernkompe-tenz des Kunden und stellt damit ein schüt-zenswertes Gut dar. Für die Implemen-tierung der Schnittstelle zum Altsystemsind wegen der fehlenden Dokumentationviele Interaktionen mit den Fachexpertennötig. Die Basismechanismen sollten vorOrt implementiert werden, um eine flexibleund zukunftsorientierte Architektur sicher-zustellen.

Die Arbeitsteilung zwischen den verteil-ten Teams ist in Tabelle 1 dargestellt.

Entwicklungsprozess definierenWie sah der Prozess vor Ort aus? Die loka-len Entwicklungen erfolgten nach demRational Unified Process. Es wurde iterativin enger Zusammenarbeit mit den Fach-experten entwickelt. Eine Iteration dauertevier Wochen und wurde jeweils mit eineminternen Release abgeschlossen. DieFreigabe der einzelnen Entwicklungs-phasen durch den Auftraggeber erfolgtenach dem im Unternehmen vorhandenen

Quality-Gate Process.Bevor die Zusammenarbeit mit dem Off-

shore-Team beginnen konnte, wurde nochder Offshore-Entwicklungsprozess festge-legt und in Form eines Kooperationsplansdokumentiert. Beim Offshore-Prozess wur-de anders als beim lokalen Prozess vorge-gangen. Grundlage des Prozesses warenArbeitspakete, die beim Offshore-Team inAuftrag gegeben wurden. Alle Tätigkeitendes Offshore-Teams wurden über formali-sierte Aufträge gesteuert. Die einzelnenSchritte bestanden aus:

■ Erstellen der Spezifikation vor Ortinklusive Review und Freigabe

■ Implementierung, Test und Testreport-Erstellung durch das Offshore-Team

■ Abnahmetest der Lieferung vor Ort■ Start der Nachbearbeitung im Fehler-

fall

Der grobe Arbeitsablauf zwischen demlokalen und dem Offshore-Team ist in demAktivitätsdiagramm in Abbildung 2 zusehen.

Großen Wert legten wir auf eine guteSpezifikation. Testfälle und Testdaten wur-den vom lokalen Team definiert und warenBestandteil der Spezifikation.

Mit dem Offshore-Team wurde dann alswichtiges Ziel vereinbart, möglichst wenigeNachbearbeitungen anzustreben, da dieseunnötigen Aufwand auf beiden Seiten erzeu-gen. Der Offshore-Prozess wurde in einemKooperationsplan dokumentiert und mit demOffshore-Team besprochen. Das Inhalts-verzeichnis dieses Plans zeigt Kasten 2.Den kontinuierlichenKommunikationsfluss sicherstellenAus Erfahrungsberichten von Offshore-Projekten wussten wir, dass ein kontinuier-licher Kommunikationsfluss und persönli-che Treffen zu den Erfolgsfaktoren imOffshoring gehören. Aus diesem Grundeplanten wir die ständige Anwesenheit min-destens eines indischen Mitarbeiters vorOrt. Seine Hauptaufgabe war es, als Kom-munikationsschnittstelle zum Offshore-Team zu wirken. Er war Ansprechpartnerfür beide Teams für unklare, technischeAnforderungen und sorgte dafür, dassAnfragen unverzüglich geklärt wurden.

Die zweite wichtige Maßnahme war es,ein- bis zweimal pro Woche Telefonkon-ferenzen mit dem Offshore-Team durchzu-führen. Ein solches Ferntreffen dauerte inder Anfangsphase zwischen 30 und 60Minuten, in der Routinephase ging der

52 53

f achar t i ke l

Disziplin Lokales Team Offshore Team

Anforderungen Lokal

Offshore-Spezifikationen Lokal

Analyse & Design Lokal

Implementierung und Test- Basismodule- Referenzimplementierung Lokal

Implementierung und Test- auf Basis der Referenzimplementierung Offshore

Systemtest Offshore

Deployment Lokal

Konfigurations- und

Änderungsmanagement Lokal

Projektmanagement Lokal Offshore

Environment Lokal

Abb. 2: Der Offshore-Arbeitsablauf in einer groben Übersicht.

Tabelle 1: Arbeitsteilung zwischen dem lokalen und dem Offshore-Team.

3 / 2 0 0 8

Bedarf auf 15 bis 30 Minuten zurück.Technisch wurde die Kommunikation

durch gemeinsam genutzte Werkzeuge unter-stützt. Eingesetzt wurden eine Projekt-datenbank (Repository), ein Wiki, einFehlerverwaltungswerkzeug sowie ein Werk-zeug zur Verwaltung der Arbeitspakete.

Erfahrungen aus dem ProjektIn dem Projekt ist es gelungen, eine gutfunktionierende Zusammenarbeit mit demindischen Partner zu etablieren. AlleLieferungen erfolgten im geplanten Zeit-rahmen und mit der notwendigen hohenQualität im Hinblick auf die Richtigkeitder Zeichnungen. Das Offshore-Team zeig-te sich als sehr engagiert, die Arbeits-atmosphäre war entspannt und angenehm.Im Laufe der jetzt einjährigen Kooperationkonnten wir die folgenden Erfahrungenmachen und Erkenntnisse gewinnen.

Bedeutung der SpezifikationenEin entscheidender Erfolgsfaktor in demProjekt war die Erstellung der Spezifikationfür die Offshore-Implementierungen. Wirhaben insbesondere davon profitiert, dasswir die Testfälle und Überprüfungspunktegleich am Anfang eines jeden Arbeitspaketsmitgeliefert hatten. Auf der einen Seitekonnten wir so gezielt die Testtiefe beein-flussen. Ein vereinfachtes Beispiel dazu:Falls der Radius REG in Abbildung 1 auchden Wert 0 annehmen kann, wurde hierfürein zusätzlicher Testfall definiert. Anhandder gelieferten Testprotokolle konnten wir

dann schnell sehen, ob die Implementierungauch den Sonderfall REG=0 berücksichtigthatte. Auf der anderen Seite unterstützengute Testdaten ein unabhängiges Arbeitendes Partners, denn es gibt weniger Bedarfan Rückfragen.

Hohe Prozesstreue beim Offshore-PartnerUm die eingangs erwähnte sehr hoheAnzahl an Details in den Griff zu bekom-men, war es wichtig, alle Unstimmigkeitenund Abweichungen umgehend erfassen undadressieren zu können. Neben einer werk-zeuggestützten Verwaltung dieser Detailswar die hohe Prozesstreue beim Partnerwichtig. Diese Prozesstreue stellte sich nichtper se ein, sondern wurde gezielt durchBeobachtungen und Rückmeldungen aufge-baut. Dazu gehörten besonders am Anfanghäufige Überprüfungen, inwieweit die defi-nierten Arbeitsschritte auch eingehaltenwurden. Abweichungen wurden dannumgehend bei der nächsten regelmäßigenTelefonkonferenz besprochen. Währendanfangs alle Vorgaben kommentarlos vomOffshore-Team akzeptiert und umgesetztwurden, lernte dieses im Laufe der Zeit,auch Prozessverbesserungen vorzuschlagen.An dieser Stelle treffen zwei Kulturen auf-einander: Die indische ist stark hierarchieo-rientiert und dem Vorgesetzten wird ehernicht widersprochen, unsere Kultur dagegenerwartet von den Mitarbeitern eine kritischeund offene Haltung mit dem Zweck,Verbesserungen zu erzielen.

Engpass bei den Fachexperten gemeistertEines der größten Projektrisiken bestanddarin, dass die Fachexperten nicht genü-gend Zeit für das Projekt hätten aufwendenkönnen. Da der Projekterfolg direkt von

f achar t i ke l

1) Einführung2) Projektziele3) Meetings auf Managementebene4) Meetings auf Projektebene5) Eskalationspfad6) Kommunikationsinfrastruktur7) Gemeinsam genutzte Werkzeuge8) Infrastruktur in Indien9) Softwarelizenzen in Indien

10) Kommunikationsmittel 11) Offshore-Prozess12) Zusammenarbeitsmodell13) Detaillierter Arbeitsablauf14) Berichtwesen15) Qualitätsmanagement16) Konfigurationsmanagement

Kasten 2: Inhaltsverzeichnis desKooperationsplanes.

dieser Verfügbarkeit abhing, reichten wirdieses Risiko bereits früh an den Len-kungsausschuss weiter. Wir erhielten da-raufhin gute Unterstützung vom Manage-ment bei der Ressourcenplanung.

In einer weiteren Maßnahme reduziertenwir nach ersten Erfahrungen den Aufwandfür die Spezifikationen soweit wie möglich.Auf Abfragen ohne wesentlichen Infor-mationsgehalt wurde verzichtet. Zusätzlichwurde die Spezifikationsvorlage stärkerformalisiert. Pseudocode oder mathemati-sche Ausdrücke wurden gegenüber Prosa-formulierungen bevorzugt. Die Fachex-perten konnten dann mit der Delegationvon Routinetätigkeiten weiter entlastetwerden. Als dritten Punkt erkannten wirspäter, dass auch das Offshore-Team in derLage war, Testdaten selber zu erzeugen.

Ein großer Vorteil war es, dass wir dieAbnahmetests für die Lieferungen auchdelegieren konnten. Anfangs gingen wirdavon aus, dass die Abnahme nur durch dieFachexperten erfolgen könnte und müsste.Da wir für jedes Offshore-Arbeitspaketaber Testfälle hatten, wurde dieser Test vonunserem indischen Kollegen im lokalenTeam durchgeführt. Die guten Erfahrungenbestätigten diesen Ansatz.

Der Anteil der internen Projektmitar-beiter lag damit bei nur 19 %, alle anderenTätigkeiten wurden von externen Mitarbei-tern wahrgenommen. Zühlke als inländi-scher Berater stellte davon 25 % und derOffshore-Partner 56 %. Das ist ein Vorteil,wenn die internen Mitarbeiter ein knappesGut darstellen und dringend für das eigeneProduktgeschäft benötigt werden. Abbil-dung 3 zeigt die prozentuale Verteilungzwischen externen und internen Mitar-beitern.

Abb. 3: Prozentuale Verteilung der internen und externen Ressourcen.

Offshore-Prozess als Prototyp füreinen firmenweiten StandardprozessDie Zusammenarbeit mit dem Offshore-Partner funktionierte in diesem Projekt rei-bungslos, die Qualität der Ergebnisse istgut. Das in dem Projekt entwickelte Pro-zessmodell hat sich bewährt. Es kann somitfür zukünftige Projekte übernommen wer-den und sich zu einem firmenweitenStandard entwickeln.

Gute Unterstützung der Offshore-Strategie des UnternehmensEine der Projektvorgaben bestand darin,Offshore-Ressourcen wo immer möglicheinzusetzen. Das Unternehmen möchte denUmfang der Offshore-Kooperation mitdem Vertragspartner weiter steigern undprofitabel betreiben. Mit einem Anteil von56 % an Offshore-Mitarbeitern im Projektund den guten Ergebnissen wurde dieseVorgabe sicher erfüllt und hat zum überge-ordneten Unternehmensziel beigetragen.

Ausbau der Fähigkeiten der FachexpertenIm Projektverlauf wurde die Bedeutungeiner guten Spezifikation immer klarer.Gute Spezifikationen zahlen sich darin aus,dass es weniger Bedarf an Abklärungengibt, und entlasten so das lokale Teamerheblich. Es gibt weniger Missverständ-nisse und damit weniger Nachbearbeitun-gen. Die Fachexperten haben Erfahrungenin diesem Bereich sammeln können undihre Fähigkeiten gut ausgebaut. Das ist einegute Voraussetzung für weitere Offshore-Projekte. Die Lerneffekte ergaben sich ein-erseits durch das Schreiben selber und

54 55

Lieferung des Partners als unvollständigoder fehlerhaft erkannt wird. Jede Nach-bearbeitung muss dabei wieder formal inAuftrag gegeben werden und alle Prozess-schritte sind noch einmal zu durchlaufen.Abbildung 4 zeigt die Anzahl der notwen-digen Nachbearbeitungen über die einzel-nen Arbeitspakete. Die ersten vier Paketeverlangten mindestens eine Nachbear-beitung, danach wurden nur vereinzeltebenötigt. Die vielen Nachbearbeitungen amAnfang der Zusammenarbeit sind inOrdnung, da dies zur Lernphase gehörte.

KundennutzenDer Kunde konnte in diesem Projekt an denfolgenden Stellen profitieren.

Gute Qualität Dank intensiven TestensDie Offshore-Zusammenarbeit hat es unsermöglicht, die vielen und notwendigenTests in Auftrag geben zu können. InterneMitarbeiter hätten aus Zeitgründen sichernur einen Bruchteil dieser Tests selberdurchführen können.

Wiederverwendung der Softwarelösungenin zukünftigen ProjektenDie Anforderung, eine erweiterbare undportierbare Architektur zu entwerfen, wur-de von den Architekten erreicht. DieLösungen können für andere Aufgaben-stellungen wiederverwendet werden. Heutewerden zweidimensionale Zeichnungenerstellt, die Architektur erlaubt es aberauch, zum Beispiel dreidimensionale Mo-delle zu generieren. Dies ist eine zukünftigeHerausforderung für den Kunden.

Routineentwicklungen – bestensgeeignet fürs OffshoringIn dem Projekt gibt es viele Wiederho-lungen bei der Implementierung. So enthältdie Bauteilbibliothek 300 Elemente, damitliegen etwa 299 Wiederholungen vor. UnserAnsatz besteht darin, dass das lokale Teamzunächst eine stabile Referenzimplemen-tierung erstellt und diese vor Ort verifiziert.Danach erfolgt der Wissenstransfer insOffshore-Team; die nachfolgenden Ent-wicklungen werden dann vom Offshore-Team unter Einhaltung der nun gegebenenLeitplanken getätigt.

Dies ist ein Ansatz zur Minimierung derOffshore-Entwicklungsrisiken. Das lokaleTeam übernimmt die Verantwortung fürdie Architektur und damit für eine flexibleund wieder verwendbare Lösung. DasOffshore-Team übernimmt die Verantwor-tung, die routinemäßige Entwicklung mitguter Qualität durchzuführen.

Die Aufgabenteilung zwischen dem loka-len und dem Offshore-Team hat in demProjekt gut funktioniert. Positiv überraschtwaren wir von der Disziplin der indischenMitarbeiter, insbesondere von ihrer Geduldbei der Überprüfung der vielen Verifika-tionspunkte.

Nur wenig NachbearbeitungenEin wichtiges Ziel bei der Offshore-Zu-sammenarbeit bestand darin, die Anzahlder Nachbearbeitungen minimal zu halten.Eine hohe Anzahl war eine unsererBefürchtungen zu Beginn des Projekts, diesich jedoch nicht eingestellt hat. EineNachbearbeitung wird notwendig, falls die

f achar t i ke l

Abb. 4: Anzahl der Nachbearbeitungen je Arbeitspaket.

3 / 2 0 0 8

durch die wiederkehrenden, intensivenReviews der Spezifikationen.

FazitIn dem hier beschriebenen verteilten Off-shore-Entwicklungsprojekt trugen vorallem drei Faktoren zum Gelingen bei:

■ An erster Stelle ist die Bereitstellungeiner guten Spezifikation inklusive derTestfälle zu nennen.

■ Die Aufrechterhaltung eines kontinu-ierlichen Kommunikationsflusses zwi-schen dem lokalen und dem Offshore-Team war der zweite Erfolgsfaktor.Dazu gehörten die ständige Präsenzeines indischen Mitarbeiters vor Ortsowie regelmäßige Telefonkonferenzen.

■ Der dritte Erfolgsfaktor ist aus unsererSicht die Einführung eines geeignetenund disziplinierten Offshore-Pro-zesses.

Das Projekt zeichnete sich durch seine vielenWiederholungen bei der Entwicklung derKomponenten aus. Der gewählte Offshore-Ansatz für die Zusammenarbeit undAufgabenteilung hat sich in der Praxisbewährt. Es ist ein Vorgehen mit minimalenOffshore-Entwicklungsrisiken und damitauch geeignet für Organisationen, die erstnoch im Aufbau einer Offshore-Kooperationsind. Unser Offshore-Ansatz sieht vor, dieVerantwortung für die Prozesse, für dieArchitektur und für die Teststrategie beimlokalen Team zu belassen. Wahrgenommenwerden diese Funktionen durch Schlüssel-rollen, die über die entsprechendeErfahrungen auf diesen Gebieten verfügen.Das lokale Team entwickelt prototypisch fürjeden Wiederholungstyp eine Referenzimple-mentierung und verifiziert den Ansatz. Nachdem Wissenstransfer erfolgt die Entwicklungaller weiteren Komponenten von diesem Typdurch das Offshore-Team.

Nach Ansicht des Autors ist dies ein aus-gleichender Offshore-Ansatz, der alle dreiSeiten – Kunde, inländische Mitarbeiterund Offshore-Mitarbeiter – integrierendberücksichtigt: Der Kunde konnte dasProjekt mit nur einer kleinen, internenMannschaft steuern und führen. Durch denMix aus inländischen Beratern undOffshore-Mitarbeitern konnte er seineOffshore-Strategie umsetzen. Für die inlän-dischen Mitarbeiter ist die Zusammen-arbeit eine Bereicherung, da sie neueErfahrungen in der internationalen Zusam-menarbeit und der Teamarbeit sammelnkonnten. Arbeitsplatzängste sollten bei die-ser Art Aufgabenteilung relativiert werden.Und schließlich war das indische Team inein interessantes und innovatives Projekteingebunden, einige Offshore-Mitarbeiterkonnten darüber hinaus Erfahrungen aneinem westlichen Standort sammeln. ■

f achar t i ke l