6 Tipps gegen Offshore-Probleme

1. Oktober 2013 von Nicolas A. Zeitler 0

Foto: iStockphoto

Foto: iStockphoto

Vom Auslagern der Software-Wartung an einen Offshore-Dienstleister erwarten IT-Chefs sich Ersparnisse, oft handeln sie sich damit stattdessen Ärger und Probleme ein. Von „menschlichem Elend“ spricht Wirtschaftsinformatiker Oliver Krancher von der Universität Bern: Dass das Outsourcing speziell von Software-Wartungsprojekten oft nicht das gewünschte Ergebnis bringt, liegt aus seiner Sicht zu einem großen Teil am gescheiterten Wissenstransfer vom Auftraggeber zum Dienstleister. Ein individuelles Lernproblem also. Nicht verwunderlich, denn „Software-Wartung ist eine kognitiv sehr schwierige Aufgabe“, sagt der 31-Jährige. Für seine Doktorarbeit hat Krancher die vergangenen drei Jahre untersucht, wie Unternehmen das Problem angehen können. Das Beratungsunternehmen McKinsey hat ihm dafür den mit 7500  Euro dotierten Business Technology Award verliehen. Weil seine Arbeit „sowohl Wissenschaftlern als auch Praktikern neue Impulse“ liefere, so die Jury.

Schlechter Wissenstransfer lässt Kosten ausufern

Als Krancher während seines Studiums für einen IT-Dienstleister arbeitete, erfuhr er aus nächster Nähe, wie ein Offshoring-Projekt aus dem Ruder laufen kann. „Es traten viele Probleme beim Wissenstransfer auf, die Planung wurde um mehrere Monate überschritten.“ Kosten schnellten in die Höhe. „Und wir wussten nicht, was wir hätten anders machen können“, sagt Krancher. Grund genug, zu dem Thema zu forschen. „Denn das ist ja ein ökonomisch bedeutsames Problem.“ Unterstützt vom Schweizerischen Nationalfonds begleitete Krancher bei einer Schweizer Bank Projekte, bei denen Software-Wartung an einen Offshore-Dienstleister ausgelagert wurde. In diesen Projekten untersuchten er und seine Betreuer, die Professoren Jens Dibbern und Sandra Slaughter, mit Hilfe von Theorien aus der Lernforschung, wie nötiges Wissen den Mitarbeitern des Dienstleisters am besten vermittelt werden sollte.

 

Aus Oliver Kranchers Arbeit lassen sich sechs Ratschläge für IT-Outsourcing-Projekte ableiten:

1. Dokumentation nicht überschätzen

2. Im Business Case nachträgliche Spezifizierungen nicht vergessen

3. Dienstleister-Mitarbeiter auswählen

4. Nicht in jedem Fall auf Erfahrung der Mitarbeiter bauen

5. Auf stabile Teams pochen

6. Eigene Erwartungen herunterschrauben

Dieser Beitrag ist Teil unseres Themenschwerpunkts Outsourcing. Alle Beiträge des Schwerpunkts finden Sie in unserem Special.

Wirtschaftsinformatiker Oliver Krancher hat den Business Technology Award von McKinsey gewonnen. Foto: McKinsey

Wirtschaftsinformatiker Oliver Krancher hat den Business Technology Award von McKinsey gewonnen. Foto: McKinsey

1. Rolle der Dokumentation nicht überschätzen: „Für Praktiker geht es beim Wissenstransfer vor allem um Informationsbereitstellung. Sie denken oft, es kommt vor allem auf eine gute Dokumentation an“, hat Oliver Krancher beobachtet. Der Wissenschaftler widerspricht: Eine Dokumentation allein genügt zur Wissenvermittlung nur beim Outsourcing wenig komplexer und wenig spezifischer Aufgaben, zum Beispiel zur Wartung eines Standard-SAP-Systems ohne Anpassungen. Sobald es sich aber um Aufgaben „ab einer moderaten Komplexität“ handelt, so Krancher, sind zusätzliche Methoden zur Wissensvermittlung gefordert. Das bedeutet, der Bearbeiter hat gleichzeitig vieles zu beachten, etwa wenn eine Änderung im Code einer Software Auswirkungen an mehreren anderen Stellen hat. In komplexen Projekten muss die Dokumentation laut Krancher ergänzt werden durch das Lernen an realistischen Aufgaben. Mitarbeiter des Dienstleisters eignen sich Wissen an, indem sie die bisher für bestimmte Aufgaben Zuständigen bei ihrer Arbeit beobachten – sogenanntes Job Shadowing – und selbst realistische Wartungsaufgaben lösen. Softwarefehler oder Change Requests eignen sich dafür laut Krancher gut. Zusatznutzen: Beim Training mit realen Aufgaben wird auch gleich Arbeit erledigt.

2. In den Business Case Aufwände für Lernen oder nachträgliche Spezifizierungen einrechnen: Zeigt sich, dass der Dienstleister die Software wegen schlechten Wissenstransfers zu Beginn unbefriedigend wartet, müssen Aufgaben nachträglich deutlicher spezifiziert werden. Beim Auftraggeber steigt außerdem der Aufwand für Kontrolle und Koordination. „Dadurch entstehen unerwartete Mehrkosten“, sagt Krancher. Er weist allerdings auch darauf hin, dass die von ihm vorgeschlagenen Lernprozesse aufwändig sind – und ebenfalls im Business Case berücksichtigt werden müssten. Folge: Unternehmen müssen in vielen Fällen die Kosteneinsparungen, die sie sich vom Offshoring erwarten, niedriger ansetzen.

Outsourcing-Mitarbeiter in Schlüsselpositionen nach Arbeitsproben auswählen

3. Mitarbeiter beim Dienstleister auswählen: Dieser Hinweis gilt für Outsourcing-Projekte, bei denen eine wenig kundenspezifische, aber komplexe Software zu warten ist. Erfahrung aus dem Bearbeiten ähnlicher Aufgaben brauchen die Mitarbeiter des Outsourcing-Dienstleisters dafür. Ein erfahrener Programmierer wird aber laut Krancher dank seines Wissens aus vorherigen Projekten mit wenig Training in der Lage sein, die Aufgabe zu lösen. Um sicherzugehen, dass der Anbieter erfahrene Mitarbeiter bereitstellt, sollte der Kunde auf Arbeitsproben pochen, „zumindest bei der Auswahl der Schlüsselpersonen“, sagt Oliver Krancher. Der Kunde könne versuchen, diese Möglichkeit schon bei der Vertragsgestaltung mit dem Dienstleister zu fixieren. Was den erfahrenen Programmierern noch zum Lösen der Aufgaben fehlt, lasse sich ihnen anhand realistischer Wartungsaufgaben mit leichter Unterstützung problemlos vermitteln.

Lesen Sie auf der nächsten Seite: Wann Outsourcing nicht sinnvoll ist

4. Erfahrene Programmierer sind keine Erfolgsgarantie: Diese Aussage gilt laut Oliver Krancher vor allem bei der Wartung zwar wenig komplexer, dafür aber sehr kundenspezifischer Software. Hier profitiert auch ein langjähriger Programmierer wenig von seiner Erfahrung – da er die Anforderungen des neuen Kunden und seine bestehenden Softwaresysteme in der Regel nicht kennt. Der Lernaufwand ist in diesem Fall besonders hoch. Krancher schlägt ebenfalls Training anhand realistischer Wartungsaufgaben vor, allerdings mit hoher Unterstützung durch den Auftraggeber und zunächst anhand einfacher Aufgaben, um kognitive Überlastung bei den Service-Mitarbeitern zu vermeiden.

5. Sicherstellen, dass der hohe Trainingsaufwand sich lohnt: Diesen Rat legt Krancher Outsourcing-Entscheidern ebenfalls für die im vorherigen Absatz geschilderte Konstellation ans Herz. Der hohe Schulungsaufwand für Dienstleister-Mitarbeiter führt Outsourcing ad absurdum, wenn die Projektmitarbeiter ständig wechseln. Gerade von indischen IT-Dienstleistern seien sehr hohe Wechselraten bekannt, so Krancher. Hier könnten Auftraggeber bei der Vertragsgestaltung Anreize dafür schaffen, dass sich der Dienstleister um stabile Teams bemüht.

Erwartungen an Outsourcing realistisch einschätzen

6. Eigene Erwartungen herunterschrauben oder doch nicht outsourcen: Ist die zu wartende Software sowohl sehr komplex als auch in hohem Grade kundenspezifisch, etwa ein SAP-System mit sehr vielen Anpassungen, summieren sich alle vorher genannten Anforderungen: Gefordert sind Mitarbeiter mit Erfahrung, die zugleich viel Training mit hoher Unterstützung benötigen. „Die bisherige Forschung sieht in diesem Fall ein hohes Risiko des Scheiterns, meiner Ansicht nach kann ein Outsourcing der Wartung aber auch in dem Fall Erfolg haben – unter der Maßgabe: Expect less“, sagt Oliver Krancher. Dazu gehöre nicht nur, die angepeilten Einsparungen im Business Case niedriger anzusetzen, sondern auch, weiter ein Kernteam im eigenen Haus zu behalten, das mit dem Dienstleister zusammenarbeitet.

Lesen Sie auf der nächsten Seite: Outsourcing-Tool als Hilfe für Manager in Entwicklung

Oliver Krancher will seine Forschungsarbeit zu Outsourcing fortsetzen – in Zusammenarbeit mit Anwenderunternehmen ebenso wie mit IT-Dienstleistern. Außerdem plant er, die Ergebnisse seiner bisherigen Arbeit in ein Tool zu gießen. Das Tool soll Managern dabei helfen, wirksame und realistische Wissentransferpläne zu erstellen, die zu den Eigenheiten ihrer Projekte passen. Bis die Forschungsarbeit an dem Tool abgeschlossen ist, dürfte es nach Aussage von Oliver Krancher aber noch bis 2015 dauern.

Tags: ,

Leave a Reply