Softwareentwicklung: 7 Erfolgsfaktoren für Nearshoring

 

 

Nearshoring in der IT-Anwendungsentwicklung ist heutzutage nicht mehr wegzudenken. Das spektrum reicht von einzelnen Personen, die beauftragt werden, um Softwarefehler zu beheben, bis hin zur verlängerten Werkbank, bei der ganze Software-Entwicklungsteams die Produktentwicklung übernehmen. Die potenziellen Vorteile gegenüber eigenen Softwareentwicklern klingen dabei aus Sicht des Auftraggebers reizvoll:

 

• Budget-Einsparungen durch niedrigere Lohnkosten;

• schnelle Skalierung durch höhere Verfügbarkeit von IT–Talenten;

• effektive Teamarbeit durch ähnliche Kultur und Zeitzonen möglich.

Nur: Wie schaffen es Unternehmen, ein oder gar mehrere Entwicklerteams im nahen Ausland aufzubauen? Wie sichert ein Unternehmen dieses Vorhaben ab, damit der Erfolg kein Zufall ist? Um die Ziele stetig zu verfolgen, die Erwartungshaltungen zu managen und auf Störungen reagieren zu können, ist ProjektmanagementProjektmanagement eine sehr gute Basis – reicht jedoch nicht aus. Alles zu Projektmanagement auf CIO.de

 

Bei der Umsetzung wird schließlich kein Produkt gebaut, welches in der Cloud läuft. Stattdessen ist es ein Zusammenarbeitsmodell, bei der sich Menschen und keine Computer auf beiden Seiten wohl fühlen und langfristig miteinander arbeiten sollen. Die sieben wichtigsten Erfolgsfaktoren dazu werden nach einer kurzen Begriffsdefinition vorgestellt.

 

Das Wort Outsourcing ist eine sprachliche Konstruktion aus den beiden Worten Out(side) und (re)sourcing und meint organisatorische Verlagerung von Leistungserstellungen. Das kann durchaus im eigenen Land passieren.

 

 

Offshoring hingegen beschreibt die geographische Verlagerung ins Asland. Unternehmen die Offshoring betreiben, können dies mit Partnern im nahen Ausland machen (Nearshoring) oder mit Partnern die sehr entfernt sind (Farshoring). Aus europäischer Sicht meint das Wort Nearshoring die Verlagerung in nahegelegene Länder wie zum Beispiel von Deutschland nach Rumänien.

 

 

Wenn eine für die Umsetzung verantwortliche Person den Auftrag erhält, Nearshoring einzuführen, aber die Gründe nicht versteht und keine persönlichen Vorteile darin sieht, dann ist bereits das Pilotprojekt zum Scheitern verurteilt. Die vorgeschobenen Gründe gegen eine Einführung können dabei bereits vor Projektbeginn vielfältig sein:

• fehlende Deutschkenntnisse bei den Entwicklern;

• keine Kontrolle, dass die Entwickler ihre Arbeit machen;

• instabile politische Situation;

• rechtliche Anforderungen können nicht erfüllt werden;

• steigende Preise und Vendor-Lock-in-Effekt.

Bei allen Veränderungsprozessen stellen sich Mitarbeiter die folgende Frage: “Warum müssen wir das machen und was habe ich persönlich davon?”

Lesetipp: Die 7 Phasen eines Veränderungsprozesses

Hier liegt der erste Erfolgsfaktor, als Sponsor oder Auftraggeber die passende Antwort zu geben, um Motivation zu erzeugen. Diese Antwort besteht aus 2 Teilen:

 

1. Das Gefühl der Dringlichkeit erzeugen: Entweder das Unternehmen befindet sich in einer Degenerationsphase oder Krise. Dann kann die schwierige Situation mit Zahlen, Daten, Fakten belegt werden. Oder es geht dem Unternehmen finanziell gut, es soll jedoch mehr Wachstum angestrebt werden. In dem Fall kann die Argumentation gemäß dem Zitat von Giuseppe Tomasi di Lampedusa: “Wenn wir wollen, dass alles bleibt wie es ist, dann ist nötig, dass alles sich verändert”, als Zielbild nützlich sein, um Mitarbeiter aus der Komfortzone zu bewegen.

Für weitere spannende Strategien, News und Hintergründe, abonnieren sie hier unsere Newsletter.

2. Die persönlichen Vorteile herausstellen: Nearshoring kann die Karriere fördern. Wer in seinem Lebenslauf nach der erfolgreichen Einführung zum Beispiel “Verantwortung für internationale Teams” stehen hat und Business Englisch auf verhandlungssicherer Ebene beherrscht, dem stehen danach neue Türen in der Geschäftswelt offen. Sie können mehr Verantwortung und Gehalt verlangen.

Grundsätzlich geht es als CIO oder Auftraggeber dieses Vorhabens darum, den Umsetzungsverantwortlichen zu zeigen, dass ihr persönlicher Gewinn bei dem Vorhaben größer ist als der Verlust durch das Outsourcing.

 

Je nach gewünschter Verantwortungsübernahme zwischen Kunde und Lieferant sind unterschiedliche Vertragsmodelle möglich. Die gängigen Nearshore-Modelle sind:

• Festpreis: Der Kunde erstellt eine vollständige Anforderungsbeschreibung. Der Dienstleister liefert die Software zu einem definierten Endtermin.

• Time & Material: Die Mitarbeiter werden auf Basis ihrer tatsächlich gearbeiteten Stunden abgerechnet.

• Agiler Vertrag: Es wird ein Festpreis vereinbart, jedoch können neue Kundenwünsche gegen noch nicht entwickelte Funktionen gleicher Größe getauscht werden.

• Open Book Policy: Der Dienstleister gewährt dem Kunden Einblicke in seine Kostenstruktur. Je nach unternehmerischem Handeln werden die Preise angepasst.

Im Vergleich dieser Modelle ist das Time & Material Modell am flexibelsten, hat den geringsten Formalismus und kann am schnellsten umgesetzt werden. Ist jedoch das Budget begrenzt, dann hat der agileagile Vertrag für beide Vertragsparteien die meisten Vorteile, da die Kosten gedeckelt sind und dennoch zum späten Projektzeitpunkt Änderungen erfolgen können. Alles zu Agile auf CIO.de

Die Open Book Policy inklusive Preisanpassungen dagegen kann zu Beginn einer Partnerschaft nicht empfohlen werden. Ein starkes Wachstum beim Nearshorer-Partner zieht höhere Allgemeinkosten und damit Preiseänderungen nach sich.

 

 

Verglichen mit einem Standard-IT-Projekt sollen bei einem Nearshore-Projekt zusätzlich zur entstehenden Software auch effektive Kommunikationsstrukturen und Mitarbeiterzufriedenheit entstehen. Daher ist es von besonderer Bedeutung, dass glasklar dokumentiert wird, wer für was verantwortlich ist.

Wird nicht klar beschrieben, wer für eine Aufgabe grundsätzlich verantwortlich ist, können zwei Dinge passieren: Aufgaben bleiben unbearbeitet, da beide Seiten denken, der jeweils Andere würde diese erledigen. Oder das Nearshore-Team übernimmt im guten Gewissen Aufgaben des Auftraggeber-Teams. Bei Letzterem kann bei den Mitarbeitern Angst vor Macht- oder Jobverlust entstehen, was zur möglichen Projekt-Sabotage führen kann.

Um Klarheit bei der Kommunikation zu bekommen, eignen sich Werkzeuge zur grafischen Modellierung der Ablauforganisation. Bewährt hat sich dabei der Standard BPMN (Business Process Model & Notation). Dies lässt sich noch sinnvoll mit einer RACI-Matrix ergänzen, die Aufgaben und Verantwortlichkeiten nach Rollen abgegrenzt aufzeigt.

 

Beim Aufbau ganzer Nearshore-Teams kommt der Teamleitung im Ausland eine besondere Bedeutung zu. Sie wählt ihre Teammitglieder aus und ist damit verantwortlich, ein umsetzungsstarkes Team zu formen.

Schwache Führungskräfte haben meist Schwierigkeiten, starke Mitarbeiter zu erkennen und zu rekrutieren. Um diese Schlüsselrolle bestmöglich auszufüllen, benötigt der Team-Lead Führungsmethoden und Facherfahrung. Falls es in der Kundenorganisation Berührungsängste mit Englisch als offizieller Projektsprache gibt, ist es zudem sinnvoll, dass die Person grundlegend Deutsch sprechen kann, um Widerstände abzubauen.

 

 

 

Bei Nearshore-Projekten existieren auf beiden Seiten Ängste:

• die Mitarbeiter des Kunden haben Angst vor Job-Verlust und der Kultur des anderen;

• die Mitarbeiter des Nearshore-Partners haben Angst, den Anforderungen nicht gewachsen zu sein.

Nimmt man das nicht ernst, kann es die Transitionsdauer wesentlich verlängern und damit den Projekterfolg auf Grund der hohen Transistionskosten gefährden.

Ein Erfolgsfaktor, um dem zu entgegnen sind kontinuierliche Vor-Ort Besuche der Mitarbeiter beim Nearshore-Partner im Ausland und der Nearshore-Mitarbeiter beim Kunden. Gemeinsame Abendessen und Teambuilding-Maßnahmen führen zum Abbau von Ängsten und steigern die Produktivität.

 

Wie misst ein Unternehmen, ob der Nearshore-Partner der Richtige ist, um nach dem Pilotprojekt weitere Aufträge zu erteilen? Ein direkter Vergleich zum Mitbewerber ist schwer möglich, da nur er am Pilotprojekt beteiligt war. Ein Erfolgsfaktor ist, sich im Vorfeld Gedanken zu machen, was genau bei dem Pilotprojekt getestet werden soll und diese Ziele zu dokumentieren. Messbare Kriterien innerhalb der Teams sind zum Beispiel:

• Dauer bei der Rekrutierung (Skalierung);

• Entwicklungsgeschwindigkeit (Produktivität);

• Technische Exzellenz (Wartbarkeit des Source Code);

• Austausch der Mitarbeiter (Fluktuation).

Darüber hinaus ist es auch wertvoll, das Management zu beobachten. Augenmerk sollte darauf liegen, wie es führt und mit Krisensituationen umgeht. Dies hat Einfluss auf die Fluktuation und den Erfolg der späteren Projekte. Diese Fragen helfen bei der Einschätzung:

• Wie werden die Nearshore-Teams geführt? Wird wertschätzend miteinander umgegangen?

• Wie geht der Partner mit Schwierigkeiten im Projektverlauf um? Formal? Pragmatisch? Fair?

• Verlaufen Eskalationen professionell und fair?

Die in vielen Jahresumfragen unter Mitarebeiterinnen und Mitarbeitern am schlechtesten bewertete Frage lautet: “Gibt mir meine Führungskraft ausreichend Anerkennung und Wertschätzung?”. Formal liegt die Führung des Nearshore-Teams beim Nearshore-Anbieter, so dass er in erster Linie für die Mitarbeiterzufriedenheit verantwortlich ist.

Da die Mitarbeiter im Ausland jedoch konstant für einen Kunden arbeiten, ist der wesentlich größere Einfluss im gemeinsamen Projektteam anzusehen. Ein Erfolgsfaktor ist, dass es von Kundenseite kontinuierlich Anerkennung und Wertschätzung gibt und dies auch von den Team-Leads der Neashore-Teams gefordert wird. Diese kostenlose Maßnahme ist ein Erfolgsfaktor für Stabilität und geringe Fluktuation im Team.

 

Die in diesem Artikel genannten teils weichen, aber dennoch erfolgskritischen Faktoren benötigen bei der Einführung von Nearshoring genau so viel Aufmerksamkeit, wie Verträge, Zeit- und Budgetpläne. Ansonsten ist ein Scheitern des Vorhabens vorprogrammiert. (bw, jd)

Wollen Sie weitere hilfreiche “Best Practices” für Ihr Berufleben erhalten, abonnieren Sie diese einfach per Newsletter.