englisch

Erfahrungsbericht : R u m ä n i e n

\\ | German Office | Offshoring / Nearshoring | Produkte | Künstliche Intelligenz | Referenzen     Unverbindline Anfrage .

Referenzen in Deutschland: Altana AMB Generali Barmer Bayer Degussa Deutsche Gasrusswerke Gothaer Versicherungen Hollister Inc. Kächele-Kama Latex Linde Engineering NEC Sancura BKK Takasago West-LB ... weitere/

Unser deutsches Office ist seit 2001 Microsoft Certified Partner und verwendet für unsere Entwicklungsprojekte die neuesten Microsoft Technologien.     Unverbindline Anfrage .

Offshore- und Nearshore-Projekte erfolgreich managen

Bisher war das Thema Offshoring / Nearshoring in der Notes-Gemeinde nicht sehr weit verbreitet. Während alle Offshoring-Kennzahlen in anderen IT-Entwicklungs-Bereichen wie Web- oder Datenbank-Anwendungen weltweit seit vielen Jahren stark steigende Tendenzen aufweisen, scheut man sich im Domino-Umfeld nach wie vor, diese Alternative zur Kenntnis zu nehmen.
Dies geschieht jedoch sehr zu unrecht. Mittlerweile haben auch viele Notes-Anwendungen einen Komplexitätsgrad und ein Aufwandsvolumen erreicht, welche durchaus den Einsatz von ausgelagerten Entwicklungs-Teams interessant erscheinen lassen. Doch um aus potentiellen Kosteneinsparungen auch reale werden zu lassen, bedarf es weit mehr als ein paar preiswerter Entwickler in Osteuropa oder Indien, denen man eine Anforderungs-Spezifikation über den Zaun werfen kann. Wenn Offshore- bzw. Nearshore-Projekte nicht entsprechend vorbereitet und unter Beachtung klarer Spielregeln durchgeführt werden, enden sie oft in einem Desaster.

Auf der Basis vieler Nearshoring-Projekte, () lassen sich die wichtigsten dieser Erfolgsfaktoren beschreiben:

Klare Zuständigkeiten
Wer ein Projekt an einen Offshoring-Partner vergeben möchte, muß mit diesem gemeinsam die geteilten Kompetenzen und Zuständigkeiten festlegen. Das klingt in der Theorie recht einfach und ist bei vielen Projektphasen auch klar abzugrenzen. Ein neuralgischer Punkt ist jedoch häufig die Implementierungs-Phase am Projektende beim Auftraggeber vor Ort. Die entwickelte Anwendung wird zu einem Zeitpunkt an den Auftraggeber “übergeben“, nicht selten in Form einer elektronischen Lieferung oder eines Downloads. Doch wer ist für die Installation und v.a. die Konfiguration der Anwendung vor Ort zuständig? Wurde vertraglich vereinbart, daß der Offshore-Dienstleister auch Support während der Abnahme-Phase beim Kunden leistet? Die schönste Entwicklung kann nicht vom Auftraggeber gewürdigt werden, wenn dieser die Anwendung nicht zum Laufen bekommen kann und bei Fehlermeldungen zunächst mit dem Dienstleister darüber streiten muß, wer den entstehenden Support-Aufwand trägt. Hier empfiehlt es sich, eine lokale Präsenz des Offshore-Dienstleisters für die Implementierung vertraglich zu vereinbaren und auch ein entsprechendes Support-Kontingent z.B. für die Abnahme-Prozedur vorzusehen. Klare Zuständigkeiten sind natürlich in jedem Projekt wünschenswert. Doch während in Onshore-Projekten ungeklärte Kompetenzen schnell in einem Vier-Augen-Gespräch erörtert werden können, werden sie in Offshore-Projekten oft erst viel später im Projektverlauf sichtbar und müssen dann per Mail, Telefon oder Chat nachträglich und umständlich definiert werden.

Geänderte Prozesse
Mit der klaren Aufteilung der Zuständigkeiten geht auch eine Veränderung der Prozesse einher, um ein Offshore-Projekt sinnvoll durchführen zu können. So muß z.B. der Prozeß der Anforderungs- und Spezifikations-Definition sehr sauber definiert sein. Es ist bei einem Offshore-Projekt deutlich schwieriger und teurer als bei einem Onshore-Projekt, nachträgliche Anforderungen in die laufende Entwicklung einzuwerfen (feature creap) oder Änderungen an der Detail-Spezifikation vorzunehmen. Während bei einem onshore durchgeführten Projekt alle Beteiligten häufig nur durch eine Bürowand voneinander getrennt sind und Informationen daher gerne auf Zuruf ausgetauscht werden oder einige zentrale Funktionalitäten in einem kurzfristig organisierten Meeting “mal eben“ über den Haufen geworfen werden, erfordert ein Offshore-Projekt schon ein deutlich disziplinierteres Vorgehen. Disziplin ist auch der Begriff der Wahl, wenn es um die Prüfung von gelieferten Ergebnissen des Entwicklungs-Partners an den Auftraggeber geht. Es macht wenig Sinn, wenn dieser unstrukturierte Tests durchführt und meterlange Fehlerprotokolle produziert, da die Offshore-Entwickler sich nicht einfach zur kurzen Durchsicht neben die Tester setzen können. Ein Testprozeß kann nur dann vernünftig funktionieren, wenn beiden Seiten klar ist, auf welcher Grundlage Tests durchgeführt werden (z.B. Use Cases oder Feinkonzept) und wenn die Ergebnisse so protokolliert werden, daß ein Offshore-Mitarbeiter eine Chance hat, den Fehler in seiner Umgebung zu reproduzieren und seine Rückmeldung in transparenter Form dem Fehler zuzuordnen.

Einhalten von Standards
So klar wir uns alle darüber sein dürften, daß Standards immer wichtig sind (egal ob Offshore oder Onshore), so häufig werden sie in der Praxis nicht oder nur unzureichend umgesetzt. Doch diese Schludrigkeit ist in Offshore-Projekten wesentlich gefährlicher und teurer. Bevor also ein Offshore-Projekt beginnt, sollte eindeutig festgelegt sein, nach welchen Standards z.B. die Dokumentation von Anforderungen und die Beschreibung der Feinspezifikation erfolgt. Professionelle Offshore-Anbieter haben i.d.R. ihre eignen Standards dafür oder verwenden Standards, die international anerkannt sind. Allerdings sollte beiden Seiten klar sein, welche Standards das jeweils sind. Ein weiterer Bereich, in dem ein Mindestmaß an Standardisierung erforderlich ist, ist das Projektmanagement. Auch wenn das Offshore-Projekt nicht unbedingt nach PIM- oder Prince2-Richtlinien durchgeführt werden muß, sollten beide Seiten darauf achten, daß z.B. der Projektplan regelmäßig aktualisiert wird, der aktuelle Status regelmäßig kommuniziert wird, auftretende Probleme sofort mitgeteilt werden (risk management) oder vereinbarte Kommunikationswege eingehalten werden, um ein völliges Kreuz und Quer zu vermeiden.

Kommunkation
Womit wir auch schon beim nächsten Aspekt wären. Offshore- bzw. Nearshore-Projekte definieren sich im Vergleich zu Onshore-Projekten primär durch die räumliche Distanz. Damit ist es naheliegend, daß effiziente Kommunikation für den Erfolg unabdingbar ist. Auch in Offshore-Projekten gilt: Nichts ersetzt die persönliche Kommunikation und insofern sollten der Projektleiter oder ggf. andere Mitarbeiter des Offshore-Partners zu wichtigen Terminen vor Ort sein können. Derartige Gelegenheiten sind z.B. die Anforderungsanalyse, wichtige Review-Meetings oder Abnahme-Tests. Erfahrungsgemäß finden auch bei einem Offshore-Projekt ca. 10% der Aufwände beim Auftraggeber vor Ort statt. Natürlich gibt es auch zahlreiche Projektbeispiele, in denen darauf gänzlich verzichtet wird, allerdings ist die Failure-Quote bei solchen Projekten unverhältnismäßig hoch. Darüber hinaus macht es Sinn, ein Application Sharing Tool wie z.B. Sametime und ein Chat System zu implementieren, das den schnellen Informationsaustausch beider Seiten erlaubt und dem Offshore-Partner auch die Möglichkeit bietet, sich auf die IT-Umgebung des Auftraggebers aufzuschalten. Speziell letztere Option erspart in der Praxis oft stundenlanges Mailen, Telefonieren und Aufregen. Ein letzter aber sicherlich zentraler Punkt ist die Sprache. Besonders vorteilhaft ist, wenn der Offshore-Projektleiter deutsch spricht. Unabhängig davon sollte jedoch im Zusammenhang mit der Kompetenz-Matrix festgelegt werden, welche Personen miteinander in welcher Sprache sprechen. Es hilft nicht viel, wenn zwar der deutsche Auftraggeber und der Offshore-Projektleiter in fließendem Deutsch oder Englisch kommunizieren können, die Verständigung auf technischer Ebene – die auf jeden Fall als ein möglicher Kommunikationsstrang in Betracht gezogen werden sollte – aber in keiner Sprache möglich ist, die von beiden Seiten ausreichend beherrscht wird.