Internes Entwicklungsteam aufbauen

Parallel zu den genannten Personalfragen sind folgende zwei Stränge zu verfolgen:

• Der Aufbau eines Entwicklerteams aus Mitarbeitern als Schnittstelle zum Offshoring-Partner und

• die Auswahl des Partners selbst.

Das Entwicklerteam muss über ausreichend Know-how in der Softwareentwicklung, besonders über Vorgehensmodelle und über die Analyse sowie Aufbereitung von Anforderungen verfügen. Zudem sind sehr gute Sprachkenntnisse sowohl in Deutsch (Kommunikation mit der Fachabteilung) als auch in Englisch (Kommunikation mit dem Offshore-Partner) unabdingbar. Wünschenswert ist zudem Praxiserfahrung in interkultureller Zusammenarbeit und eine Bereitschaft zu regelmäßigen Reisen zum Standort des Offshoring-Anbieters.

Praxiserfahrung in interkultureller Zusammenarbeit ist ein im Offshoring häufig unterschätzter, aber wesentlicher Punkt. Fehler, die hier gemacht werden, sind nur schwer zu revidieren und haben nachhaltig negativen Einfluss auf die Arbeitsatmosphäre. Ein Entwicklungsteam in Indien reagiert vollkommen anders als eines in der Slowakei. Ein Beispiel: In traditionell geprägten asiatischen Kulturen ist es nicht üblich, über Hierarchiestufen hinweg Entwicklungsfehler zu diskutieren. In allen Fällen gilt: Es ist wichtig, das Entwicklungsteam persönlich kennenzulernen und über die Sitten und Gebräuche der anderen Kultur Bescheid zu wissen. Diese Faktoren wirken sich positiv auf die Zusammenarbeit und Ergebnisse aus. Die Kooperation ausschließlich auf Dokumente zur Anforderungsspezifikation sowie Telefonkonferenzen mit schwer verständlichem Englisch zu reduzieren, ist riskant und eher nachteilig.

Auswahl des Offshore-Unternehmens

Der nächste Schritt vor der eigentlichen Auslagerung ist die Auswahl eines geeigneten Offshore-Unternehmens. Geeignet heißt, ob der Offshoring-Partner zu den Vorstellungen über die Unternehmenskultur, über die Softwarearchitektur und über den Entwicklungsprozess passt. Folgende Fragen muss das Auswahlverfahren lösen:

• Besitzt das Offshore-Unternehmen das technische Know-how, um bestehende Entwicklungsprojekte weiterzuführen und neue in die Anwendungslandschaft zu integrieren?

• Wie sieht es mit dem Ressourcen-Management des Anbieters aus?

• Wie rasch ist die Firma in der Lage, auf neue Projekte durch ein größeres Team mit qualifiziertem Personal zu reagieren?

• Welches Wissen hat die Firma zum Beispiel in leichtgewichtiger, agiler Softwareentwicklung?

• Welche Modelle der Auftragsbearbeitung sind möglich: Festpreis oder nur nach Aufwand?

• Welche Referenzen können für alle Qualifikationen genannt werden?

Nicht zuletzt ist unter den bisher genannten Kriterien für die Qualifikation des Offshore-Unternehmens auch das Preis-Leistungs-Verhältnis im Vergleich zu Konkurrenten unter die Lupe zu nehmen. Auf werbewirksame Zertifizierungen wie CMMI allein sollte man sich nicht verlassen. Das direkte Gespräch mit dem Anbieter, aber auch der Kontakt zu jemandem, der Erfahrung mit dem Provider hat und ungeschminkt über seine Projekterfahrungen berichten kann, ist weit wertvoller.

Ist die Auswahl getroffen, gilt es, einen Rahmenvertrag zu formulieren und zu schließen. Er muss die allgemeingültigen Vertragsbestandteile enthalten, die allen Entwicklungsprojekten gemeinsam sind. Der Vorteil: Diese Vertragsbestandteile müssen dann nicht in jedem Projektvertrag eigens wieder aufgenommen werden, sondern lassen sich einfach referenzieren. Zu den Vertragsklauseln sollte zum Beispiel folgendes gehören:

• Regeln für die Codequalität,

• Gewährleistung,

• Konformität zur Standardarchitektur,

• Abstimmung bei der Auswahl von Programmierbibliotheken,

• Kontinuität des Personals,

• das jedem Projekt zugrunde liegende Preismodell und

• ein Passus zum Schutz geistigen Eigentums.

Zu beachten ist weiterhin, dass der Vertrag auch internationalisiert werden muss. Das bedeutet nicht nur eine Übersetzung in die jeweilige Landessprache, sondern auch, dass das Offshoring-Unternehmen akzeptieren muss, wenn der Vertrag nach deutschem Recht abgefasst ist. Alternativ kann man auch unterschiedliche Verträge aufsetzen, die dem jeweiligen Landesrecht unterworfen sind.

Vorgehensmodell festlegen

Traditionell wird offshore eher konservativ, dokumentengetrieben auf Basis von Lasten- und Pflichtenheften gearbeitet. In diesem Fall ist die Preisfindung für ein Projekt mit einem Festpreisangebot vergleichsweise leicht. Komplizierter wird es, wenn agil entwickelt werden soll. Es besteht kein Zweifel, dass dies möglich ist. Allerdings stellt sich die Frage, wer den Preis für Missverständnisse zahlen soll. Daher möchten Offshore-Dienstleister das geschäftliche Risiko bei dieser Entwicklungsmethode in der Regel durch einen Projektvertrag auf Basis von Time & Material (T&M) absichern. In diesem Fall ist ein erfahrenes, internes Projekt-Management gefragt, das sowohl die Kosten und die Qualität als auch den Zeitplan im Griff hat und rechtzeitig gegensteuert, wenn das Projekt mit dem T&A-Verfahren aus dem Ruder läuft.

Geistiges Eigentum schützen

Die Diskussion über Vertragsklauseln zum Schutz des geistigen Eigentums im Offshoring wirkt akademisch. Sie sollten auf jeden Fall von einem IT-Juristen mit Kenntnissen im internationalen Recht verfasst werden, sind aber keine Gewähr. Geistiges Eigentum lässt sich in der Softwareentwicklung durch Vertragsklauseln nicht ohne Weiteres wirksam schützen. Jedes kompetente Entwicklungsteam ist mit der Software in kürzester Zeit so gut vertraut, dass es in der Lage ist, sie in einer anderen Softwarelösung zu adaptieren. Der Ursprung der Software kann dann nicht mehr eindeutig nachgewiesen werden. Der Schutz ist selbst dann nicht zuverlässig gewährleistet, wenn dem Offshore-Unternehmen Teile der Anwendung nur als Binärcode zur Verfügung gestellt werden. Beispielsweise kann bei Programmiersprachen wie Java normalerweise der Binärcode leicht wieder entschlüsselt werden, so dass ein Sourcecode vorliegt. Auch die Einführung von Werkzeugen zur Verschlüsselung des Codes - sogenannte Obfuscators - ist nicht der Weisheit letzter Schluss, weil sie unter Umständen die Entwicklung behindern.

Anwendungsarchitektur definieren

Die bessere Strategie zum Schutz geistigen Eigentums ist es, die Kernkompetenzen des eigenen Unternehmens bei der Entwicklung nicht offenzulegen, sondern im Offshore möglichst nur die Teile zu entwickeln, die technischer Natur sind. Im Prinzip reden wir wieder über die gute Praxis, Geschäftslogik und technische Implementierung nach einem Designmuster zu trennen. Je sauberer die Anwendungsarchitektur nach diesem Muster aufgebaut ist, desto leichter ist eine Trennung von unternehmenskritischen und unkritischen Teilen möglich. Wird zudem nach einem Komponentenmodell wie zum Beispiel OSGi oder auf Basis von Standard-Frameworks wie JavaServer Faces gearbeitet, lassen sich Komponenten vergleichsweise leicht integrieren und testen. Im Prinzip ist das Verfahren ein alter Hut und auch in anderen Industriezweigen erprobt, beispielsweise der Automobilindustrie. Dort müssen Zulieferer schon lange nach einer bestimmten Spezifikation arbeiten und fertige Komponenten auf der Basis einer Schnittstelle mit bestimmten Qualitätsanforderungen liefern.

Qualitätssicherung in Eigenregie

Qualitätssicherung ist ein weiterer wichtiger Baustein für erfolgreiches Offshoring. Wer sich verleiten lässt, mit der Entwicklung auch die Qualitätssicherung außer Haus zu geben, wird Schiffbruch erleiden. Die Qualitätssicherung sollte unbedingt autark von der Entwicklung betrieben werden, da ansonsten eine unabhängige Instanz zur Beurteilung der gelieferten Qualität fehlt. Wichtig ist, die Bedingungen schon im Rahmenvertrag festzulegen, damit nicht bei jedem Projekt erneut über Entwicklungstest, statische Codeanalyse, Lasttest und Testabdeckung diskutiert werden muss. Empfehlenswert ist, dem Dienstleister grundsätzlich Entwicklertests vorzuschreiben, die von der internen Qualitätssicherung reproduziert werden können. (pg)