Die Produktivität der Offshore-Entwicklung beziehungsweise -Wartung übertrifft die der Onshore-Modelle beträchtlich: Liegen Letztere im Branchendurchschnitt bei 500 Euro pro Function Point, so erreichen ausgelagerte Dienstleistungen häufig Bestwerte von 180 Euro. (Eine Erläuterung zum Thema Fuction Points bietet der "Stichwort"-Kasten.)
Doch diese Vorteile entstehen keineswegs automatisch. Vielmehr müssen sie vertraglich abgesichert werden. Von entscheidender Bedeutung sind neben der Wahl des geeigneten Partnes vor allem ein flexibles Preismodell und sinnvolle Service-Level-Agreements (SLAs).
Kontrolle über die Kosten
Wichtiges Erfolgskriterium für jede Outsourcing-Transaktion ist ein abgesicherter Business-Case. Das "klassische" Outsourcing leitet meist aus den Ist-Kosten einen klaren Zielkostenkanal als "Deckel" für die Kostenentwicklung künftiger Jahre ab. Das ist bei der Offshore-Auslagerung der Anwendungsentwicklung jedoch schwierig. Derartige Leistungen sind nicht statisch, sondern ergeben sich oft kurzfristig aus neuen oder veränderten Geschäftsanforderungen.
Außerdem verleitet ein Festpreis für Wartung oder Entwicklung den Provider dazu, seinen Aufwand möglichst gering zu halten. Das resultiert oft in schlechterer Qualität, im "Abspecken" von Anforderungen und in einem reduzierten Funktionsumfang. Hinsichtlich der Wartung sinkt der tatsächliche Aufwand nach der Einführung einer Software rapide. Damit liegt er möglicherweise deutlich unter dem kalkulierten Betrag, und der Kunde zahlt zu viel.
Aus diesen Gründen werden die Offshoring-Leistungen häufig nach Aufwand bezahlt. Doch das kann zu ausufernden Entwicklungs- oder Wartungskosten führen, weil der Dienstleister an einem hohen Umsatz interessiert ist und nur geringen Kostendruck verspürt. Die Einhaltung der Budgetwerte ist unzureichend abgesichert, der Anreiz für Einsparungen gering.
Das Hauptproblem beider Preismodelle liegt darin, dass sich die Vergütung nicht an der Produktivität des Providers orientiert. Zielführender wäre es, den Leistungs-Output zu messen und zu vergüten, am besten durch Preismodelle, die auf Function Points basieren: Bezahlt wird dabei nach Umfang und Größe der implementierten Funktionalität - mit Hilfe der Kennzahl "Implementierungskosten pro Function Point in Euro". In Verträgen mit längeren Laufzeiten lassen sich auch jährliche Produktivitätssteigerungen festschreiben.
Für den Kunden ebenfalls attraktiv ist ein "Function-Point-Deckel". In diesem Modell rechnet der Dienstleister nach Aufwand ab - mit einem definierten Stundensatz. Aber der Vertrag schreibt eine Mindestproduktivität fest, beispielsweise maximal 190 Euro pro Function Point. Überschreitet der Auftragnehmer diesen Wert, so erhält er für die zusätzlich eingesetzten Stunden keine Vergütung. Unterschreitet er ihn, muss er die Einsparungen an den Kunden weitergeben.
Als Ansporn für Einsparungen kann auch ein Bonus an den Provider gezahlt werden. Die Function-Point-Modelle sind flexibel, weil sie sich auf bekannte und neue Anforderungen gleichermaßen anwenden lassen. Sie ersparen beiden Vertragsseiten das Feilschen um die etwaige Anpassung eines starren Festpreisdeckels. Zudem sind sie Benchmark-fähig, denn Marktvergleiche für Anwendungsentwicklung oder Wartung basieren fast immer auf Function-Point-Metriken.
Der Aufwand für das Zählen der Function Points wird oft überschätzt und bleibt bei pragmatischer Anwendung der Methode moderat. Zu Beginn des Offshoring-Projekts lassen sich die Function Points über das "Backfiring"-Verfahren aus der Anzahl der "Lines of Code" rückrechnen. Umrechnungsfaktoren für verschiedene Entwicklungssprachen sind verfügbar.
Wer auf ein Function-Point-basierendes Preismodell verzichten will, kann mit dem Provider auch ein "Win-and-Risk-Sharing-Modell" vereinbaren. Hier erfolgt die Verrechnung aufwandbezogen nach einem definierten Tagesatz. Braucht der Dienstleister mehr Tage als budgetiert, so gewährt er dem Kunden jedoch einen Rabatt, beispielsweise 30 Prozent des vereinbarten Tagessatzes. Schafft er es, unter Budget zu bleiben, so erhält er hingegen für jeden eingesparten Tag 30 Prozent des Tagessatzes als Bonuszahlung.
Neben den finanziellen Anreizen für Einsparungen hat dieses Modell den Vorteil, dass der Kunde am Ende der Vertragslaufzeit die benötigten Wartungstage genau kennt. Falls sie unter der ursprünglichen Kalkulation liegen, was häufig der Fall ist, kann er den Vertrag entsprechend anpassen. Damit eignet sich diese Methode besonders für das Wartungs-Offshoring.
Kontrolle der Qualität
Niedrige Kosten nutzen wenig, wenn die Qualität nicht stimmt. Hinsichtlich der Anwendungsentwicklung lässt sich die Qualität vor allem an den Fehlern im ausgelieferten Sourcecode messen. Allerdings funktioniert auch dies nur, wenn der Umfang der ausgelieferten Softwarekomponente als Bezugsgröße bekannt ist. Dann lässt sich die Qualität einer Applikation anhand der Fehler pro Function Point definieren. Für den Fall, dass sie unter einen bestimmten Wert sinkt, sind Pönale vereinbar. Festgelegt werden sollten auch Grenzwerte für die zeitliche Liefertreue und die Geschwindigkeit der Fehlerbehebung.
In Bezug auf Wartungsleistungen ist unter anderem zu regeln, zu welchen Zeiten Fehler angenommen werden, weil viele Offshore-Anbieter in anderen Zeitzonen arbeiten. Oft haben sie jedoch Brückenköpfe im Heimatland des Auftraggebers. Über eine sinnvolle Arbeitsteilung zwischen Brückenkopf und Offshore-Entwicklungscenter lässt sich auch eine Sieben-mal-24-Stunden-Wartung bewerkstelligen. Der Leistungsschein für die Wartung muss auch die Reaktions-, Wiederherstell- und Fehlerbeseitigungszeiten regeln. Da der Provider bei Fehlern im Produktivsystem schnell zu reagieren hat, sind diese Zeiten deutlich kürzlich zu wählen als die für Entwicklungsleistungen.
Um mit dem Offshoring Erfolg zu haben, sind organisatorische Veränderungen unerlässlich. Gute Offshoring-Provider bringen hierfür geeignete Verfahren mit. Allerdings muss der Auftraggeber auch bereit sein, seine Prozesse und Verfahren an die des Providers anzupassen.
Insgesamt erfordert die Auslagerung von Entwicklungs- und Wartungsressourcen professionelle und formalisierte Prozesse. Beispielsweise sind Anforderungspezifikation, Dokumentation und Abnahmeverfahren im Detail zu regeln. Sauber geklärt werden muss auch die Arbeitsteilung zwischen Kunden, Brückenkopf und Offshore-Organisation. Schlüsseltätigkeiten wie Anforderungsaufnahme, Projekt-Management, Controlling und Akzeptanztests lassen sich nicht auslagern und werden häufig onsite über den Brückenkopf abgebildet.
Hinsichtlich der Zertifizierung sind beispielsweise indische Programmierer den europäischen IT-Organisationen oft weit voraus. Es ist sinnvoll, beim Auswahlprozess zu fragen, ob die jeweilige Delivery-Unit ein solches Zertifikat erworben hat. Wichtige Qualitätszertifikate sind CMM Levelx, CMMI Levelx und gegebenenfalls ISO900x.
Voraussetzungen der Infrastruktur
Die Infrastrukturvoraussetzungen werden in der Anwendungsentwicklung und -wartung oft sträflich vernachlässigt. Zu fragen ist beispielsweise: Garantiert der Auftragnehmer die WAN-Anbindung an die Offshore-Entwicklungscenter? Und wo ist der Leistungsübergabepunkt? Ein häufiges Problem betrifft instabile Leistungen und zu geringe Bandbreiten - auch im relativ hoch entwickelten Indien.
Ebenfalls zu klären: Wo stehen die Test- und Entwicklungs-Server? Wer hat Zugriff? Wie sind die Servicezeiten und Service-Levels der Maschinen?
Strittige Punkte könnten auch das Verfahren zur Softwareauslieferung sowie die dazu notwendigen Tools und Infrastrukturvoraussetzungen sein.
Welcher Partner trägt die Kosten für Lizenzen, WAN-Anbindung, Entwicklungs-Server etc.?
Auch der Betrieb der Test- und Entwicklungs-Server muss mit Service-Levels abgesichert werden. Dazu gehören Betriebs- und Servicezeiten, Verfügbarkeit sowie maximale Ausfalldauer und -häufigkeit. Für die WAN-Anbindung an das Offshore-Entwicklungscenter ist meist eine redundante Auslegung der Leitungen erforderlich.
Ein Notfallkonzept sollte festlegen, auf welche Weise die Daten gesichert werden. Außerdem definiert es, wie schnell der Betrieb wieder aufgenommen wird, wenn im Ernstfall das Entwicklungscenter ausfällt.
Darüber hinaus sind juristische und datenschutzrechtliche Aspekte zu beachten. Es gibt Mustervorlagen von EU-Gremien, die man als Anlage an den Rahmenvertrag aufnehmen kann, beispielsweise Standardvertragsklauseln für die Übermittlung personenbezogener Daten an Auftragsverarbeiter in Drittländern nach 95/46/EG.
Auf jeden Fall sollten die Kunden Rahmenvertrag, Leistungsscheine, Preismodelle und sonstige Regelungen aktiv mitgestalten. Am besten fährt, wer dem Provider fertige Vorlagen vorgibt. Vertragsvorschläge des Auftragnehmers enthalten meist Formulierungen, die den Provider einseitig begünstigen. Dass die Mehrzahl der Unternehmen ihre Vereinbarungen dennoch darauf aufbaut, liegt daran, dass der Auftragnehmer mehr Erfahrungen mit Outsourcing-Verträgen hat. Deshalb ist der Kunde allzu schnell bereit, dessen Vorschlägen zuzustimmen. (qua)