Ein Plädoyer gegen Outsourcing

cats-phone[1]

Nachdem ich immer und immer wieder mit Argumenten für Outsourcing – oder auch “Near-/Off-Shore Development” oder wie man es auch immer nennen schönreden möchte – überschwemmt werde, möchte ich nun ein für alle mal klarstellen: Outsourcing ist eine schlechte Idee.

In meiner Heimat, der Software-Entwicklung, bedeutet Outsourcing, dass die Entwicklung (oder ein Teil davon) an einen meist geografisch deutlich entfernten und preislich (zumindest auf den ersten Blick) äußerst begünstigten Ort ausgelagert wird. Nicht zu selten kann es sich dabei um eine (Tochter-)Firma in einer indischen (in Bangalore haben IBM, HP, Accenture etc. Niederlassungen), kanadischen, irischen oder einer auch (nah-)östlichen Stadt handeln. So kann man sich Software in vermeintlich lukrativen, weil anfangs deutlich kostengünstigeren, (Sub-)Unternehmen erstellen lassen.

Warum überhaupt?

Nicht selten wird outgesourced, da das Know-How im eigenen Unternehmen fehlt und ebenso die Zeit, dieses aufzubauen. So werden als Quick’n’Dirty-Alternativen Dienstleister engagiert, die das Gewünschte anbieten und mit einem Stundensatz bestechten, der bei vielleicht nur einem Drittel von dem in Österreich/Deutschland liegt. Auf dem Prinzip der Auslagerung basiert ja eigentlich die gesamte IT-Branche, da Aufträge an andere vergeben werden und gern für ein fertiges Produkt inkl. Gewährleistung gezahlt wird – ein sowieso vollkommen veralteter Gedanke, Software als in sich abgeschlossenes Werk zu betrachten. Denn Software lebt! Wird Software nicht mehr weiterentwickelt, stirbt sie fast augenblicklich.

Häufig wird Outsourcing so eingesetzt, dass billige “Fachkräfte” eingekauft werden, um einen Engpass im Unternehmen auszugleichen. So wird ein Teil der Entwicklung dann vielleicht nach Bangalore ausgelagert, aber das Management bleibt in Wien. Dabei werden aber oft einige Kosten nicht mitgerechnet, wie der Mehraufwand in der Qualitätssicherung, der Kommunikation oder der (Wieder-)Eingliederung des Know-Hows in das Unternehmen. Kurzfristig lassen sich sehr wohl Kosten reduzieren, aber langfristig halst man sich ein teures Problem auf, das man vermeiden hätte könnten.

Die Lüge

Was häufig bei Outsourcing zugunsten der hübsch niedrigen Zahlen für den Entwicklerstundensatz vergessen wird, ist:

  • Persönliche Kommunikation kann NICHT ersetzt werden.
    Im Sinne von Scrum sitzt das Entwickler-Team möglichst im selben Zimmer.
  • Kulturelle Unterschiede zwischen Entwicklern unterschiedlicher Länder.
    Das bedeutet vor allem Arbeitsmoral und Loyalität.
  • Verständigungsprobleme aufgrund unterschiedlicher Sprachen.
  • Der immer unterschätzte Koordinationsaufwand.
    Wenn wir Entwickler schon schwer verstehen, was das Marketing will, obwohl wir beim selben Meetingraum sitzen…
  • Know-How-Verlust.
  • Höherer Planungsaufwand.
    Auch nach Fertigstellung des Projektes zur Reintegration ins auftraggebende Unternehmen.
  • Enorme Qualitätssicherungskosten.
    Zumindest das Userinterface muss erneut wieder von einem deutschen Native Speaker überprüft werden. Rechtschreib- und Grammatikfehler werden nicht erkannt.
  • Verlust des informellen Informationsaustausches.
    Plauderei beim Mittagessen etc.
  • Schlechtes Image.
    Die Zeiten, als Outsourcing noch als gute Möglichkeit gewertet wurde, sind definitiv vorbei.
  • Verlagerung der Wirtschaftsleistung weg ins Ausland.
    Besonders gefällt mir die Beschreibung bei der Vergabe des Negativpreises des Unwort des Jahres (und das war schon 1996!):
    Imponierwort, das der Auslagerung/Vernichtung von Arbeitsplätzen einen seriösen Anstrich zu geben versucht”

Outsourcing macht meines Erachtens nur Sinn, wenn:
– es sich nicht um das Kerngeschäft des Unternehmens handelt,
– es ein in sich abgeschlossenes englischsprachiges Projekt handelt (und alle “Externen” auch gut Englisch können),
– nicht agil entwickelt wird (allerdings sowieso eine Todsünde – Ich schlafe ja bekanntlich mit dem Agilen Manifest unter dem Kopfkissen. Und das ruhig und sehr zufrieden).

Machen wir es richtig!

Die Alternative zu Outsourcing liegt somit auf der Hand: Aufbau eines qualifizierten (agilen) Teams als eigene Abteilung oder Subunternehmen in unmittelbarer Nähre zum Produktmanagement statt Ausgliederung. Sollen einzelne Mitarbeiter (kurzfristig) ersetzt werden, dann können das gern externe sein, die sich aber möglichst stark ins Team integrieren (Anwesenheit). Outsourcing sollte nur im äußersten Notfall in Erwägung gezogen werden, und am besten nicht mal dann. Lieber qualifizierte Software-Entwickler einladen und Know-How im eigenen Unternehmen aufbauen. Versteht mich nicht falsch, ich bin nicht eine, die glaubt, dass ihre Mitarbeier nur dann arbeiten, wenn ich sie sehe. In einem gut eingespielten Team kann Homeoffice durchaus üblich sein… aber das zu erörtern sprengt nun hier wohl den Rahmen.

Ich liebe und lebe agile Software-Entwicklung und arbeite gern eng mit meinen Mitarbeitern, Kollegen und Kunden zusammen. Als Scrum-Master kenne ich die Vorteile von Transparenz, Kommunikation und Innovation und bringe diese täglich zum Einsatz.

Naja. Und falls jemand diesbezüglich eine Beratungsleitung von mir in Anspruch nehmen möchte… Nun ja, ihr wisst ja, wo ihr mich findet. ;)

Update: Ein weiterer Artikel im Standard gegen Outsourcing in öffentlichen Vergabeverfahren http://mobil.derstandard.at/1397520665108/Sozialpartner-Oeffentliche-Auftraege-nicht-an-Billigstbieter

cat-content-540x304[1]

Buchbesprechung: Soft Skills für Softwareentwickler

Nach meinen letzten Besprechungen zu den Büchern “Agile Softwareentwicklung” und “Scrum” habe ich eine weitere Rezension für die Wirtschaftsinformatik geschrieben. Dazwischen habe ich übrigens auch eine nicht besonders löbliche über “IT-Management” verfasst, hier aber nicht gepostet, da ich das Buch sowieso als eine Themenverfehlung empfand.

Wer übrigens für mein Buch über E-Voting eine Rezension schreiben will, bekommt es gratis (materieller Wert von €68!) bei der Wirtschaftsinformatik.

Hier meine letzte Buchbesprechung:

» Zur Bestellung
Soft Skills für Softwareentwickler
von Uwe Vigenschow, Björn Schneider

dpunkt
ISBN 978-3-89864-433-4

36.00 €

Rezensent: Barbara Ondrisek, Wien

Unterschiede zwischen Softwareentwicklern und dem Fachbereich, Kunden und dem Management sind oft Auslöser für Probleme in Projekten. Eine Verbesserung der Soft Skills und Kommunikationstechniken führen nachhaltig zu größerem Projekterfolg.

IT ist für Nicht-ITler nur Mittel zum Zweck und wird nur gesehen, wenn etwas nicht funktioniert. Missverständnisse zwischen Entwicklern und Nicht-Entwicklern aus den Fachbereichen und dem Management sind vorprogrammiert, obwohl letztere maßgeblich am Erfolg der Entwickler (die sie aber nicht verstehen) abhängig sind.
Oft gelten gängige Klischees: Entwickler können nicht zuhören und der Fachbereich kennt sich (technisch) nicht aus. Werden Verantwortungsbereiche überschritten, reagieren die Teilnehmer oft ablehnend oder aggressiv. Um die Differenzen zu verringern und das Projektziel nicht aus den Augen zu verlieren, helfen eigene Fragetechniken, Kommunikationsmodelle und konstruktives Konfliktmanagement. Eine Verbesserung der Soft Skills aller Teilnehmer führt zudem zu einer höheren individuellen Leistungsfähigkeit.

Moderne agile Projektmodelle helfen Konflikte früher sichtbar zu machen. Ganzheitliches Projektmanagement durch Projektumfeldanalyse identifiziert Stakeholder und deren Ziele, wobei deren Beziehungen unterschieden und berücksichtigt werden müssen. Der Projekterfolg lässt sich zudem durch Projektmarketing und Verbesserung der Softwarequalität verstärken.

Die Effizienz der Kommunikation ist ein wesentlicher Erfolgsfaktor. Informationsverluste können mit Einsatz verschiedener Kommunikationstechniken minimiert werden. Es werden verschiedene Fragetechniken erläutert, z.B. die auf NLP basierende 6-Stufen-Fragetechnik, mit der Details aufgefasst werden können, die sonst verloren gingen. Andere Techniken wie positive Verstärkung, Ich-Botschaften, aktives Zuhören oder Auf die Meta-Ebene gehen werden erklärt.

Unterschiedliche Kommunikationstypen werden identifiziert und Erklärungsmöglichkeiten und Anregungen für die Zusammenarbeit mit schwierigen Mitarbeitern gegeben. Konflikte müssen zunächst verstanden werden, um auch konstruktiv genutzt zu werden.

Das Buch ist in 5 Abschnitte gegliedert: Projektarchitektur und Kommunikationsschnittstellen, Fragetechniken, erfolgreich Kommunizieren, Kommunikationstypen und Konfliktmanagement. Im Anhang werden Übungen vorgestellt und theoretische Grundlagen erklärt.
Das Buch ist eine Sammlung von hilfreichen Kommunikationstechniken und Modellen, die das Zusammenspiel aller an einem Softwareprojekt Beteiligten erleichtern soll.