Ist Offshoring von IT-Projekten nach Indien sinnvoll?
Mit großem Interesse habe ich die Artikel in der Computerwoche (beispielsweise Ausgabe Nr. 36 vom 06.09.2010) zum Thema Offshoring verfolgt. Meine Meinung hierzu ist, dass dieses Thema aufgrund des demographischen Wandels in den nächsten Jahren immer bedeutsamer werden wird, es sei denn die Softwarehersteller schaffen (endlich) intelligentere Systeme bzw. Frameworks, mit denen die Entwickler sich mehr um die Fachlichkeit kümmern können, als sich mit technischen Problemen herumschlagen zu müssen. Wir von exensio setzten hier beispielsweise gerne bei der Entwicklung von Web Applikationen das Grails-Framework ein, wenn wir auf JEE - sofern es keine zwingende Kundenanforderung hierfür gibt - verzichten können.
Aber nun zurück. Das Offshoring-Thema wird gerne vom Einkauf verfolgt, da man sich eine dramatische Kostenreduzierung erhofft. Hierbei wird jedoch oft vergessen, dass für einen Projekterfolg mit einem Offshoring-Dienstleister einiges zu beachten ist. Da man jedoch davon ausgeht, dass alles vergleichbar mit einem deutschen Dienstleister abläuft, scheitern sehr viele Projekte dieser Art. Und wer will schon gerne über gescheiterte Projekte berichten.
Folgende Punkte sind meines Erachtens zu beachten:
- Erhöhter Kommunikations- und Spezifikationsaufwand
Es wird meistens vergessen, dass bei Offshoring-Projekten ein erheblicher Mehraufwand für die Kommunikation und Spezifikation betrieben werden muss. Es wird leider nicht über den Tellerrand geschaut: Was in der Spezifikation steht, wird umgesetzt, auch wenn es keinen Sinn macht. Dies ist besonders kritisch bei der Entwicklung von Individual-Software, da jeder weiß, dass Papier sehr geduldig ist. Bei technischen Aufgabestellungen (beispielsweise Datenbank auf UTF-8 umstellen) ist ein Offshoring-Projekt viel leichter zu realisieren. Auch gilt zu bedenken, dass es viel einfacher ist komplexe Zusammenhänge in der Muttersprache zu formulieren. - Team-Skalierbarkeit
Dies wird immer gerne als positives Beispiel für einen Offshore-Dienstleiter genommen, da bei den heimischen Dienstleistern angeblich meistens Ressourcenknappheit herrscht. Scheint ein Projekt sich zu verzögern, so wird dann seitens des Offshore-Dienstleisters verkauft, dass dies kein Problem darstellt. Man könne ja das Team von anfänglich 15 Entwicklern schnell auf 50 oder auch 100 Mitarbeiter erweitern. Meiner Erfahrung nach ist die hieraus resultierende Software später leider nicht mehr vernünftig wartbar. Alles Weitere lässt sich bei Tom De Marco nachlesen. - Verschiedene Zeitzonen
Dies ist meiner Erfahrung nach kein Problem. Ich konnte beispielsweise auch noch spät abends einen Entwickler in Indien erreichen. - Ingenieurmäßiger Ansatz
Dieser Punkt stellt für mich das größte Problem dar. Wir Deutschen sind für unsere Präzision bekannt. Bei der Softwarequalität müssen auf jeden Fall Abstriche in Kauf genommen werden. Leider führt dies auch zu langfristig höheren Wartungskosten. Im schlimmsten Fall wird das gesamte Projekt langfristig viel teurer, als wenn es in Deutschland entwickelt worden wäre. - Hierarchische Arbeitsstrukturen im Vergleich zu eigenverantwortlichem Arbeiten
Es gibt ganz eindeutig kulturelle Unterschiede. Ich werde nie folgende Szene vergessen, als ich selbst in Indien vor Ort war: Ein Entwickler musste den Projektleiter fragen, ob er sich ein Fachbuch aus dem verschlossenen Regal (Schlüssel hatte der Projektleiter) nehmen darf. Hieraus resultiert wieder, wie eingangs bereits erwähnt, ein höherer Spezifikationsaufwand. - Kostenersparnis
Das erste Angebot ist natürlich viel billiger als das eines deutschen Mittbewerbers. Leider wird dann jedoch meistens für die spätere Wartung des Systems vergleichbare Preise verlangt. Entscheidet sich der Kunde, das System wieder in eigener Regie warten zu wollen, so muss er meistens feststellen, dass die Software nicht sauber entwickelt wurde und durch ihn nicht wartbar ist. - Projekt-/Architekturcontrolling
Für einen Projekterfolg ist es sehr wichtig das Projekt aus Projekt- sowie Architektursicht genau zu steuern. Hierbei ist es wichtig früh genug Mängel in der Umsetzung der Spezifikation aufzudecken. Eigentlich wäre hier ein agiler Ansatz richtig. In 2-wöchigen Sprints wäre schnell ersichtlich, wo es hapert. Hierzu gibt es jedoch unterschiedliche Auffassungen, viele meinen, dass das Wasserfall Modell hier besser passen würde, da die meisten Offshore-Dienstleister erst noch Erfahrungen mit Scrum und XP sammeln müssen. Hierbei kann auch ein Dienstleister wie die exensio GmbH unterstützen.