36

STRATEGIE Alternative zum Offshoring

Alternative zum Offshoring Software-Entwicklung in Deutschland – nah am Kunden. Die deutlich niedrigeren Lohnkosten reizen. Viele Unternehmen lagern Software-Entwicklung in Niedriglohnländer aus. Ihre Hoffnung war und ist, dass die Einsparungen den Mehraufwand für fachliche Abstimmung und Projektmanagement übertreffen. Die Bilanz dieser Zusammenarbeit fällt – freundlich formuliert – ernüchternd aus. Denn: Eine Vielzahl der SoftwareProjekte erweist sich als nicht „offshore-fähig“. Die Ursache sind Anforderungen auf Kundenseite, die sich im Projektverlauf verändern oder erst konkretisieren. Dieses „Moving-Target-Phänomen“ in Entwicklungsvorhaben fordert agile Methoden, die jedoch dem Charakter von Offshore-Projekten widerstreben. Die SoftwareIndustrie in Deutschland sollte die günstige Konstellation nutzen. Denn wenn agile Methoden mit agilen Software-Engineering-Methoden und -Umgebungen konsequent kombiniert werden, schrumpft der Kostenvorteil bei einer Verlagerung ins Ausland. Von Inge Hanschke

P

roduktionsverlagerung? Nein! Die Anzahl der Produktionsverlagerungen ist um rund 40 Prozent zurückgegangen. Auf jeden dritten Verlagerer kommt ein Rückverlagerer. So lautet in Kürze das Ergebnis der Studie „Produktionsverlagerungen in Zeiten der Krise“ [1], die das Fraunhofer Institut für System- und Innovationsforschung gemeinsam mit VDI im November vergangenen Jahres vorstellte. Neben höheren Transport- und Logistikkosten wurden als Grund für die Rückverlagerungen vormals ausgelagerter Produktionskapazitäten zuvorderst Qualitätsprobleme am ausländischen Standort angeführt. „Made in Germany schlägt Low Cost“ heißt es bei der Studienpräsentation kurz und knapp. Das Fazit lässt sich – mit einer gewissen Überzeichnung – problemlos auf die Software-Industrie übertragen. Denn auch hier erlagen in jüngerer Vergangenheit viele Unternehmen den Verlockungen niedriger Lohnkosten. Auf dem Gebiet der Anwendungslösung ließen beziehungsweise lassen sie Entwicklungsvorhaben off- oder nearshore programmieren. Sie sind überzeugt, dass Reibungsverluste aufgrund kultureller Unterschiede, von Verständigungsproblemen und nicht zuletzt erheblichen Zeitaufschlägen von den Kostenvorteilen übertroffen werden. Die Praxiserfahrungen bestätigen diese Annahme nicht. Eine aktuelle Umfrage [2] unter CIOs in Deutschland über die Zufriedenheit mit IT-Dienstleistern ermittelte signifikante Unterschiede für die Leistungsbezüge aus dem Inland (onshore), dem nahe gelegenen Ausland (nearshore) oder einem entferntem Standort (farshore). Überspitzt formuliert fällt mit der Ferne die Bewertung in Sachen Produkt- und Servicequalität, Termintreue sowie Kommunikation/Koordination zusehends negativer aus. Als Ursache für das schlechtere Abschneiden der OffshoreAnbieter führt die Untersuchung insbesondere gravierende

Kommunikations- und Koordinationsprobleme an, die sowohl den kulturellen Barrieren als auch der räumlichen Distanz zwischen Kunden und Anbietern geschuldet sind. Im Punkt „Zufriedenheit mit den Kosten“ lassen sich dagegen keine einschneidenden Unterschiede feststellen. Mit anderen Worten: Der ursächliche Anreiz für die Auslagerung verliert in der Praxis an Schärfe. Das Ergebnis mag bei vordergründiger Einschätzung überraschen. Schließlich sind gerade Techniken und Verfahren der IT nicht ortsgebunden. Nüchtern betrachtet muss allerdings eine Vielzahl von Entwicklungsvorhaben als nicht „offshore-fähig“ eingeordnet werden. Ein Offshore-Projekt ist eine Black Box: Ich stecke meine Anforderungen in eine Box hinein und erhalte nach einer gewissen Zeit das Ergebnis. Das klingt einfach und überzeugend. Es hat allerdings den Haken, dass ein solches Vorgehen nicht mit der Lebenserfahrung in der professionellen Software-Erstellung im Einklang steht. Denn viele, wenn nicht die meisten SoftwareProjekte, starten mit unsicheren und unvollständigen Vorgaben. Gerade für geschäftsspezifische, fachlich anspruchsvolle Fragestellungen lässt sich die Zieldefinition nicht eindeutig formulieren. Firmenpolitik und Gesetzgebung können im Verlauf der Realisierung die „nicht-funktionalen“ Rahmenbedingungen neu justieren. Auch kann die Beschäftigung mit dem ersten Lösungsentwurf bei den Fachanwendern einen Denkprozess über den Nutzen der ursprünglichen Vorgaben und Annahmen anstoßen. Neue Technologien und Produkt-Releases üben zusätzlichen Änderungsdruck aus. Meist „klären“ sich die tatsächlichen Anforderungen erst im Verlauf des Projekts, wenn der Kunde anhand lauffähiger Zwischenstände die entstehende Lösung immer besser „begreift“. WuM 05 . 2010

37

Dieses „Moving Target“-Phänomen verlangt beinahe zwangsläufig nach einem iterativen Vorgehen in der Software-Entwicklung. Dies hilft, die Komplexität in Projektvorhaben zu beherrschen und gleichzeitig die gebotene Offenheit für Änderungen zu gewährleisten. Voraussetzung ist eine intensive Kommunikation zwischen den Projektbeteiligten, um das Feedback der Anwender kontinuierlich einfließen zu lassen. Exakt dieser Anspruch findet sich in den grundlegenden Prinzipien agiler Vorgehensweisen und Methoden [3] wieder. Unter anderem wird die Zusammenarbeit mit dem Kunden als bedeutender als Verträge bewertet. Die Reaktion auf Veränderungen ist hier wichtiger als das starre Festhalten an einem Plan. Und der Punkt funktionierende Software wird höher geschätzt als eine umfassende Dokumentation.

» Die Prinzipien der agilen Vorgehensweise stehen in deutlichem Kontrast zu den genannten Eigenarten von Offshore-Projekten. « Die Prinzipien der agilen Vorgehensweisen stehen damit in deutlichem Kontrast zu den genannten Eigenarten von OffshoreProjekten. Allein die räumliche und zeitliche „Ferne“ unterbindet den Kommunikationsprozess, den ein solches Vorgehen benötigt. Eine Zielpräzisierung innerhalb der einzelnen Teilaufgaben (Inkremente) ist kurzfristig kaum möglich. Als Ergebnis WuM 05 . 2010

hält der Auftrageber deshalb am Ende eine Lösung in Händen, die zwar den eingangs formulierten Anforderungen entspricht, meist jedoch nur dem Qualitätsniveau „Kann man mit leben“ (Kasten) genügt. Die Aussagen in der eingangs erwähnten Studie unterstreichen diese grundlegende Schwäche von OffshoreProjekten nachdrücklich. Die agilen Vorgehensmethoden und -prozesse helfen nicht allein, das „Moving Target“-Phänomen zu lösen. Eine passende Sofwareengineering-Methode und -Umgebung sind notwendig. Diese müssen die kurzen zwei- bis sechswöchigen Iterationszyklen und die Produkt-Backlog-Verwaltung gut unterstützen und Software-Entwickler durch weitgehende Generierung und Automatisierung von deren fehleranfälligen Routineaufgaben entlasten. Nur so können die Vorteile der agilen Vorgehensweisen gehoben werden und gleichzeitig kann die Entwicklung effizient und damit kostengünstig erfolgen. Ein wichtiger Aspekt ist hierbei die modellbasierte SoftwareEntwicklung. Ein kontinuierlicher Abgleich zwischen Software und den Anforderungen der Kunden erfolgt im Rahmen der Generierung. Grundlage sind hierbei Modelle, die in passender Abstraktion insbesondere fachliche Aspekte beschreiben. Ohne viel Programmierung kann man aus diesen Modellen eine lauffähige Anwendung und insbesondere GUI-Masken generieren. Die GUI kann sogar interaktiv mit dem Anwender auf der Basis eines initialen Entwurfs weiterentwickelt werden. Der Anwender kann bereits zu einem frühen Zeitpunkt sein Feedback geben und seine Wünsche einsteuern. Missverständnisse werden so frühzeitig ausgeräumt. Darüber hinaus erhält der Anwender über die Modelle eine abstrakte Allgemeinsicht der Lösung, deren Modelle getreu dem agilen Vorgehen iterativ verfeinert und konkretisiert werden. Der Entwickler generiert aus den

38

STRATEGIE Alternative zum Offshoring

Modellen Source-Code und ergänzt diesen um die konkrete Geschäftslogik. Da die generierten Anwendungen stets konform zu den fachlichen und technischen (Referenz-)Architekturen bleiben, ist keine manuelle Nachdokumentation notwendig. Die klare Trennung von fachlichen und technischen Aspekten in den unterschiedlichen Abstraktionsebenen der Modelle, aber auch das Wissen um Zusammenspiel der Komponenten und Architekturen [4] sichert die notwendige Flexibilität, um jederzeit und auf jeder Abstraktionsebene Änderungen und Anpassungen vornehmen zu können. Kurz: Agilität in Kombination mit entsprechenden SoftwareEngineering-Methoden und -Werkzeugen führt zu besserer Software und senkt Aufwand und Zeit, die Software zu entwickeln. Beim modellbasierten Vorgehen wachsen Entwurfsphase und Realisierung enger zusammen und führen schneller zu angemessenen Lösungen. Für den Anwender heißt es nun abzuwägen, was ihm „seine“ Software Wert ist. Die Verlagerung von Entwicklungsaufträgen nach Near- und Offshore hat sicherlich ihren Reiz, wenn umfangreiche Vorhaben überschaubarer Komplexität mit eindeutigen Anforderungen anstehen. In solchen Fällen ist der Preis eines Entwicklers die entscheidende Stellschraube. In Projektvorhaben, die einen hohen Innovationsanteil besitzen und ein hohes fachliches Spezialwissen erwarten, üben die Kosten eines „unbekannten“ Entwicklers in der Black Box nur bescheidenen Einfluss aus. Das weitaus wichtigere Erfolgskriterium ist die Nähe der Beteiligten. Denn nur wenn sich Entwicklungsteam und Fachbereich im Wortsinne auch in die Augen

schauen, bildet sich auch bei nicht eindeutigen Vorgaben der zu entwickelnden Software eine vernünftige Lösung. Und die Kombination agiler Vorgehensmodelle und Software-EngineeringMethoden und -Werkzeuge garantiert, dass auch in Deutschland Software von hoher Qualität zu konkurrenzfähigen Konditionen entwickelt werden kann.

Links und Literatur [1] Studie: Produktionsverlagerung in der Krise, Fraunhofer Institut für System- und Innovationsforschung/VDI, November 2009; http://www.vdi. de/uploads/media/Studie_Produktionsverlagerung.pdf. [2] Softwareentwicklung offshore – Warum so viele Projekte scheitern, Prof. Dr. Peter Buxmann, TU Darmstadt Fachgebiet, Information Systems/ Wirtschaftsinformatik, Vortrag anlässlich Jour fix/Finance Lab Frankfurt, Mai 2010; http://www.efinancelab.de/events/jours-fixes/efl-jours-fixes2010/buxmann-030510/. [3] Manifest der agilen Softwareentwicklung, diverse Autoren, November 2007; http://agilemanifesto.org/. [4] Strategisches Management der IT-Landschaft: Ein praktischer Leitfaden für das Enterprise Architecture Management, Inge Hanschke, Hanser Fachbuchverlag, 2. Auflage Juli/2010.

Die Autorin Inge Hanschke ist Geschäftsführerin bei der iteratec GmbH. Die Diplom-Informatikerin ist bei dem Unterhachinger Software- und Beratungshaus für die Angebotsbereiche IT-Managementberatung und Technologieberatung zuständig.