Best Practise Aufgabenauswahl für eine erfolgreiche Verlagerung

Unternehmen tendieren dazu, gerade diese Aufgaben ins Ausland zu verlagern und die neuen, aufregenden oder komplexen Aufgaben im eigenen Haus zu belassen. Manchmal wird dies zunächst gelingen. In vielen Situationen hat das jedoch dazu geführt, dass die Fluktuation innerhalb des Projektteams des Dienstleisters in die Höhe ging. Neben den damit verbundenen Kosten ergibt sich auch eine niedrigere Produktivität und die Time-to-Market Ziele müssen stets sehr eng beobachtet werden. Einfach gesagt: Wenn die eigenen Entwickler Aufgaben nicht attraktiv finden, wird dies auch für das ausländische Team zutreffen.

Häufig wird das Kerngeschäft (z.B. Frameworks, Basis-Technologien) im eigenen Hause behalten. Dies hat sich im Allgemeinen als sinnvoll gezeigt. Es ist jedoch auch zu beachten, dass immer mehr ausländische Software Dienstleister Spezialgebiete bzw. -wissen aufgebaut haben und somit in diesen Bereichen extrem stark entwickelte Nischenanbieter geworden sind. Es gibt Unternehmen, die mit diesem Dienstleister effektiv zusammenarbeiten und dadurch ihre eigenen Kernkomponenten schneller weiterentwickeln und verbessern.

Gerade kundenspezifische und differenzierende Themen (wie z.B. Branding oder Front-end Implementierungen) werden im eigenen Hause behalten, während Back-end Funktionen verlagert werden. Dies zeigt überdurchschnittliche Erfolgsraten bei verlagerten Entwicklungsprojekten. Gerade die Vermittlung und Abstimmung von kundenseitigen Spezial-Anforderungen ist nicht immer einfach. Hier empfiehlt sich lediglich die Implementierung zu verlagern, sofern ein starker Produkt Owner das Anforderungsmanagement übernimmt.

Eine andere Metrik, die zur Bestimmung von verlagerungsfähigen Aufgaben benutzt wird, ist der Grad der Schnittstellen zu anderen Funktionen, Anwendungen oder Prozessen. Ähnlich wie bei den „kundenseitigen“ Aufgaben werden auch hier überdurchschnittliche Erfolgsraten erzielt. Aber es sollte stets darauf geachtet werden, dass die Entscheidung nicht ausschließlich auf dieser Metrik basiert, da diese Metrik stark von der Architektur und dem Scope der Verlagerung abhängig ist.

In diesem Modell werden die lokalen Entwickler für die Neuentwicklung von Software eingesetzt und das ausländische Team übernimmt anschließend die Wartung und den Support der Software. Es ist überraschend, aber es zeigt sich, dass dieses Modell nur geringe Vorteile liefert. Neben dem Know How Transfer hat sich herausgestellt, dass gerade Wartungs- und Support Aufgaben erhöhte Kundeninteraktionen erfordern und eine Art „Tiger-Team“ Lösung erfordern, um schnell und tief in die Software einzuwirken. Dies ist häufig schwierig mit einem ausländischen Dienstleister zu realisieren. Sofern es sich jedoch um planbare Wartungsreleases handelt, haben sich andererseits sehr hohe Erfolgsaussichten einer langjährig angelegten Verlagerung gezeigt.

Dies ist eine sehr gute Metrik und zeigt überdurchschnittlichen Erfolg. Hierbei ist es in den meisten Fällen ein wesentlicher Erfolgsfaktor, gerade den Übergang zwischen beiden Funktionen (und Teams) erfolgreich zu gestalten.

Die Frage kann durch die folgenden 4 Prozessschritte nachvollziehbar beantwortet werden:

Der Prozess beginnt mit der Definition der quantifizierbaren Ziele (=Metrik), die durch eine Verlagerung erreicht werden sollen. Beispiele für Leistungsziele können sein: Time-To-Market, Änderungsdynamik, Verfügbarkeit von Ressourcen in Hinblick auf Anzahl & Termin, Kostenoptimierung, ROI, Konzentration auf Kernkomponenten, etc.

Anschließend sollten möglichst alle Kandidaten (Funktionen/Komponenten, Projekte, Produkte, Teams, etc.) für eine Verlagerung identifiziert werden. Für jeden Kandidaten ist die „Null-Linie“ der Leistungsmetriken anzusetzen. Gleichzeitig werden potentiellen Punkte, die den Kandidaten hindern, die definierten langfristigen Ziele tatsächlich zu erreichen, aufgelistet.

Hierbei werden in der Regel viele Aspekte, die eigentlich durch eine Verlagerung gelöst werden sollten, aufgedeckt, die jedoch fundamentale interne Team Probleme betreffen. Wenn eine Verlagerung ins Ausland die Erreichung der Ziele nicht wirklich unterstützt, sollte dieser Kandidat von der Liste gestrichen werden!

Genauso wird es einige Kandidaten geben, die bereits relativ sehr gut funktionieren. Wenn also eine Verlagerung nicht eine wirklich deutliche Verbesserung auf die Performance hat, sollte dieser Kandidat ebenfalls nicht betrachtet werden.

Für jeden Kandidaten auf der Liste, führe eine Beurteilung hinsichtlich der folgenden Kriterien durch (zum Beispiel mittels Scorecard-Technik, via  Ziele, Kennzahl, Vorgabe und mögliche Maßnahmen):

• Risiko
• Kundenmeinung
• Kundeninteraktion
• MA-Support
• Auswirkungen auf Mitarbeiter
• Komplexität
• Wechselwirkungen
• Level des benötigten Geschäftsverständnis
• Reife und Vorbereitung

Ist die Beurteilung abgeschlossen, sollten alternative Lösungen zu der beabsichtigten Verlagerung ins Ausland zu Vergleichszwecken betrachtet werden. Alternativen können sein: eigene Mitarbeiter einstellen, Beauftragung eines lokalen Partner, etc. Sofern sich zeigt, dass die Verlagerung ins Ausland die beste Lösung ist, ist der Kandidat für eine Verlagerung zu wählen.