Liebesgrüße vom russischen Bären

Fachbeitrag aus der IT Management 03/04 1994: 

Weltraumfahrt und Software-Entwicklung sind zwei Themenkomplexe, die auf den ersten Blick nur wenig miteinander zu tun haben. Das russische Weltraumprogramm ist weitgehend zum Stillstand gekommen. Aber das vorläufige Ende einer ehemals führenden Spitzentechnologie hat enorme Potenziale hochqualifizierte Software-Ingenieure freigesetzt.

Die Projekterfahrung mit russischen Software-Ingenieuren aus Jekaterinburg (ehemals Swerdlowsk) im Ural ist beispielhaft für die Vergabe von Programmieraufträgen jenseits des ehemaligen Eisernen Vorhangs.

1. Geschäftsziele

Eine kritische Analyse der IV-Aktivitäten (IV = Informations-Verarbeitung) ladet beinahe immer bei einem wesentlichen Punkt: Kosten und Produktivität der Software-Entwicklung (sofern überhaupt noch Eigenentwicklung betrieben wird). Verbesserungen zu diesem Punkt sind zwar nicht einfach zu finden. Ein Lösungsansatz könnte sein, die Software-Entwicklung zu verlagern. Damit ist die Erreichung der folgenden Geschäftsziele verbunden:

• Kostensenkung bei der Software-Entwicklung,
• Zeitgewinn bei der Entwicklungsdauer und
• Erarbeitung neuer Lösungen.

Darüber hinaus gibt es indirekte Beweggründe, die zum Verlagern („Outsourcen“) der Software-Entwicklung führen können:

• Konzentration auf das Kerngeschäft (wozu nicht die Software-Entwicklung gehört),
• Einkauf von Dienstleistungen bei Drittanbietern,
• Alternativen zu den eigenen Software-Entwicklern,
• Unabhängigkeit von der eigenen IV-Abteilung.

Die Existenz derartiger Geschäftsziele ist ziemlich klar und unumstritten. Diskussionen gibt es über den Weg, wie diese Ziele zu erreichen sind.

Drei Alternativen stehen zur Verfügung:

• Optimierung der vorhandenen Software-Entwicklung,
• „verlängerte Werkbank“ durch Outsourcing bestimmter Tätigkeiten im Prozess der Software-Entwicklung,
• Outsourcing der gesamten Software-Entwicklung.

Bild: Bei dem Gedanken an die Entwicklung von Software in Russland werden nicht wenige Entscheider kalte Füße bekommen. Zu Unrecht, wie erfolgreich durchgeführte Projekte zeigen.

Das in diesen Artikel zugrundeliegende Praxisbeispiel beschäftigt sich mit Alternative 2: Aufbau einer „verlängerten Werkbank“ zur Unterstützung der vorhandenen Entwickler bei einer Münchner Versicherung. Das Ziel besteht darin, die Einführung einer unternehmensweiten Client/Server-Architektur zu beschleunigen und dabei Erfahrungen mit neuen Formen der Software-Entwicklung zu sammeln.

Eine Entscheidung, bestimmte Softwarelösungen extern entwickeln zu lassen, ist schnell gefallen. Die Frage, mit welchem Partner das geschehen soll, ist schon schwieriger zu beantworten. Angebote gibt es aus aller Herren Ländern, aber die Wahl fällt immer öfter auf Partner im Osten, wobei Tschechien und Russland einen besonders guten Ruf genießen. Um die Qualität zu testen, empfiehlt es sich, ein Pilotprojekt – mit geringem Umfang – an zwei oder mehrere Partner in Auftrag zu geben. In unserem Beispiel zeigte sich folgendes Ergebnis: Nur die russischen Entwickler konnten die gestellte Aufgabe lösen, termin- und kostengetreu sowie inhaltlich fehlerfrei. Deshalb wurden dort weitere Projekte in Auftrag gegeben.

2. Geschäftsprozesse

Eine solche strategische Entscheidung hat Einfluss auf den Geschäftsprozess der Software-Entwicklung. Dabei geht es um die grundsätzliche Frage, welche Teile des fünfstufigen Entwicklungsprozesses (Analyse, Design, Realisierung, Test, Wartung) überhaupt ausgelagert werden können und welche Aufgaben im eigenen Haus bleiben müssen. Die Antwort in diesem konkreten Fall gilt aber auch generell:

• Die Analysephase bleibt im eigenen Haus.
• Die Designphase wurde an eine Münchner Consulting-Firma ausgelagert, die auch die Kontakte zum russischen Partner herstellte und als Projektleiter fungierte.
• Die Realisierung und der Test wurden nach Russland ausgelagert.
• Die Abnahme und die Wartung erfolgte wieder im eigenen Haus.

Hinter dieser Vorgehensweise standen folgende Überlegungen: Eine externe Programmierung bedarf einer exakten Vorgabe. Wegen der weiten Entfernung sind Abstimmungsgespräche aus wirtschaftlichen Gründen nicht möglich. Als Kommunikationsmittel stehen nur Telefon, Fax und Modem zur Verfügung. Die Ergebnisse der Analysephase sind selten so aussagekräftig, dass ohne persönliche Kommunikation ein Programmdesign gemacht werden könnte. Deshalb die Entscheidung, Analyse und Design in München – aber mit externer Unterstützung – zu erledigen und erst die exakten Programmvorgaben an den russischen Partner weiterzugeben. Ebenso werden Testdaten und sonstige allgemein zu benutzende Programmteile per Modemleitung übertragen, so dass die Entwicklungs- und die Testphase völlig selbstständig auch in fernen Regionen wie in Jekaterinburg durchgeführt werden können. Einzelne Rückfragen sind dabei ohne weiteres beantwortbar. Die fertigen Programme werden wieder per Modemleitung übertragen und einer Abnahmeprüfung unterzogen. Diese Methode hat sich bewährt, und die Ergebnisse entsprachen voll den Erwartungen.

Das Sprachproblem wurde durch Übersetzungen ins Englische gelöst. In der Zwischenzeit steht auch ein elektronisches Übersetzungsprogramm (Kaufpreis etwa 400 Mark) eines Softwarehauses aus Moskau zur Verfügung, so dass manuelle Übersetzungen in Zukunft weitgehend entfallen können.

Die Kommunikation und Datenübertragung erwies sich als überraschend stabil und leistungsfähig. Die dafür anfallenden Kosten dürfen in der Gesamtkalkulation allerdings nicht übersehen werden, da sie sich doch im Monat bei 500 Mark eingependelt haben.

Die Qualifikation der externen Entwickler was schlicht gesagt hervorragend. Die Einarbeitungszeit in eine neue Problematik was kurz, die Auffassungsgabe ausgeprägt und die Qualität der Ergebnisse hoch. Wie bereits erwähnt: Der zweite externe Partner ist bei den gleichen Vorgaben einfach gescheitert. Daraus lässt sich schließen, dass sowohl die Ausbildung als auch die Motivation der russischen Partner mindestens dem deutschen Standard entsprechen.

Aus bisher Gesagten lässt sich folgendes lernen: Brainware aus dem Osten: Ja, aber nur bei gut organisierter Vorgehensweise. Und das kostet – leider – Geld. Deshalb ist es erforderlich, sich einer Kostenberatung zu widmen.

3. Kosten-Nutzen-Analyse

Ein wesentlicher Beweggrund für eine Software-Entwicklung in Drittländern sind natürlich die Kosten, denn externe Entwickler gibt es auch in Deutschland genügend. Doch die reinen Kosten pro Monat für einen Entwicklersprechen für das Verlagern in Drittländer:

Für einen Entwickler in Jekaterinburg müssen derzeit zwischen 2500 und 3000 Mark pro Monat kalkuliert werden. Diese Kosten sind als Absolutbetrag deutlich günstiger als zum Beispiel in Ungarn oder Tschechien und sind ausschlaggebend für eine Entscheidung zugunsten Russlands.

Dazu kommen Kommunikations- und eventuell Übersetzungs- sowie Reisekosten. Diese drei Positionen sind projektabhängig zu kalkulieren, so kann der Reiseaufwand auch völlig entfallen. Doch aus Management-Sicht liegen die zur Kostenberechnung relevanten Themen bei der Vorgehensweise und bei der Software-Architektur. Dazu gibt es folgende Überlegungen:

Vorgehensweise

Die Vorgehensweise beeinflusst die Kosten ganz entscheidend: Wenn von einem fünfstufigen Lifecycle nur zwei Stufen ausgelagert werde, müssen die restlichen drei Stufen mit deutschen Kosten berechnet werden. Bei Auslagerung von vier Stufen entstehet eine wesentliche Kostenreduzierung.

Doch wer hat den Mut, Design- und Wartungsphase auszulagern? Denn, wie vorhin schon erwähnt: Ohne persönliche Kommunikation ist es für einen externen Entwickler sehr schwierig, aus fachlichen Anforderungen ein passendes Programmdesign zu erstellen, Aus Kostengründen lohnt sich eine Auslagerung nur dann, wenn die Designphase kurz und die Programmierphase lang ist.

Ein Beispiel soll diese Überlegungen verdeutlichen: Eine Woche Design kostet in Deutschland rund 6000 Mark. Wenn daraus für einen russischen Programmierer zwei Monate Arbeit resultieren, sind dies Kosten in Höhe von 5000 Mark.

Wenn der russische Partner auch noch die Designphase übernehmen könnte, lassen sich die Designkosten in wesentlichen auch noch einsparen. Das Verhältnis Designkosten zu Programmierkosten sollte so sein, dass in einer Woche Design der Input für eine monatelange Programmierphase erstellt werden kann.

Software-Architektur

Damit sind wir beim nächsten kritischen Punkt: der Software-Architektur. Bei Modernen Client/Server-Anwendungen verschieben sich die Aufwendungen für die einzelnen Phasen der Lifecycles. Die Designphase wird länger dauern, und die Programmierphase wird deutlich kürzer.

Derartige Programme werden zukünftig aber dominieren, und das Erstellen großer, monolithischer Programmkomplexe wird zunehmend in den Hintergrund rücken.

Organisatorische Voraussetzungen

Wer seine Software-Entwicklung auslagern möchte, sollte sich auch über organisatorische Konsequenzen Gedanken machen. Wesentlich ist, dass es Mitarbeiter mit der Fähigkeit gibt, eine exakte fachliche Analyse vorzunehmen und auch die Ergebnisse ebenso umfassend wie lückenlos zu dokumentieren. Die anschließende Designphase kann ebenfalls nur von geeigneten Mitarbeitern durchgeführt werden, die in der Lage sind, einen externen Programmierer die passenden Vorlagen zu liefern. Aus Sicht des Software-Lifecycles sind also die Phasen Analyse und Design das Kernthema und sollten im Rahmen eines Core-Managements organisatorisch im Unternehmen verankert werden.

Kalkulationsschema

Das folgende Beispiel soll ein Kalkulationsschema verdeutlichen, das die wesentlichen Positionen umfasst. Die Höhe der einzelnen Positionen ist hier nur beispielhaft und hängt natürlich vom Einzelprojekt ab.

Externe Kosten:
Designphase	pro Tag ca. 1200 Mark
Projektleitung	abhängig vom Aufwand
Übersetzungskosten	je Zeile bis zu 3 Mark
Kommunikationskosten (Tel., Fax, Modem)	je 4,42 Sekunden 0,23 Mark
Programmierer- und Testkosten	pro Monat und Mitarbeiter:  2500 bis 3000 Mark
Einfuhrumsatzsteuer	gesetzliche Werte

Technologie

Das externe technologische Know-how konzentriert sich oft auf IBM- und SNI-Mainframes mit den dazugehörenden Programmiersprachen wie COBOL oder Assembler. Deutlich weniger Know-how gibt es in diesen Drittlohnländern in der PC-Welt, da die hier vorherrschende Vielfalt von Entwicklungsumgebungen und Entwicklungswerkzeugen nicht mehr zu beherrschen ist, Aber die Erfahrung hat gezeigt, dass eine schnelle Einarbeitung in eine neue Entwicklungsumgebung offensichtlich problemlos möglich ist.

Zukünftige Investoren sollten sich aber darüber im Klaren sein, dass eine Nachrüstung mit modernen wesentlichen Softwareprodukten in der Regel unvermeidlich sein wird und die entsprechenden Anschaffungskoten mit einplanen. Schon aus diesem Grunde empfiehlt sich eine langfristig angelegte Auslagerungsstrategie, die neben vertrauensbildenden Maßnahmen auch die optimale technische Ausstattung umfassen sollte.

Fazit

Diese Überlegungen zeigen deutlich die Problematik der Ausgangsfrage „Brainware aus dem Osten?“. Die Antwort ist eigentlich ganz einfach: Nur wenn in längeren Phasen selbstständig programmiert werden kann, lohnt sich eine Auslagerung. Deutlich besser wird die Situation in dem Moment, in dem auch die Designphase verlagert werden kann.

In den anderen Fällen, wo Design- und Programmierphase ähnlich lange sind, ist die Frage einer Auslagerung aus wirtschaftlichen Gründen ernsthaft in Frage zu stellen. Da dies bei den meisten Client/Server-Anwendungen der Fall ist, sollte alternativ über eine starke Integration der Design- und Programmierphase nachgedacht werden – ebenfalls über eine optimale Programmierumgebung mit 4GLs und Template-Programmierung. Und wer dann noch sämtliche Kosten gegenüberstellt und auch noch die Wartungsphase in die Überlegungen einbezieht, wird trotz der geringen monatlichen Kosten eines russischen Entwicklers folgendes Fazit ziehen:

• Brainware aus dem Osten dann, wenn klare Vorgaben vorliegen und eine selbstständige Durchführung einer relativ langen Programmier- und Testphase gewährleistet ist.
• Brainware aus dem Osten nicht, wenn Client/Server-Dialog-Anwendungen eher in Form eines Prototypings im häufigen Dialog mit dem Anwender erstellt werden und spontan auf Änderungswünsche reagiert werden soll.

Gefragt sind also intelligente Lösungen, die auf die Voraussetzungen Rücksicht nehmen und die beide Alternativen in Betracht ziehen:

• Brainware aus dem Osten und
• Brainware aus Deutschland!

Von Richard Nußdorfer, Fachbeitrag IT Management 03/04 1994

Happy Bithday it management!