Wann lohnt sich Software-Outsourcing nicht? Klare Grenzen für Legacy-Projekte

Outsourcing klingt nach der bequemen Lösung. Sie geben die Wartung ab, ein externes Team übernimmt, Sie kümmern sich um Ihr Geschäft. Bei Legacy-Software stimmt das nur teilweise. Die Outsourcing-Nachteile zeigen sich gerade dann, wenn ein System über Jahre gewachsen ist, kaum dokumentiert wurde und niemand mehr genau weiß, warum bestimmte Funktionen so gebaut sind, wie sie gebaut sind. Dieser Artikel zeigt, wo die roten Linien liegen und wann Outsourcing bei Legacy-Projekten mehr Probleme schafft, als es löst.

Wann Outsourcing bei Legacy-Software funktioniert

Bei klar abgegrenzten Aufgaben funktioniert Outsourcing gut. Ein Sicherheitspatch, ein PHP-Upgrade, eine einzelne Funktion, die erweitert werden soll: Das lässt sich an ein externes Team übergeben, solange der Auftrag klar beschrieben ist und das Team sich einarbeiten kann. Die generellen Vor- und Nachteile dieses Modells haben wir in unserem Artikel zu Outsourcing in der Softwareentwicklung zusammengefasst.

Bei gewachsenen Legacy-Systemen kommt aber ein zusätzlicher Faktor hinzu: das Wissen über das System selbst, das sich über Jahre im Kopf einzelner Mitarbeiter angesammelt hat. Und genau da beginnen die eigentlichen Outsourcing-Nachteile.

Wo Outsourcing an seine Grenzen stößt

Fehlende Dokumentation macht die Übergabe zum Blindflug

Viele Legacy-Systeme wurden über Jahre erweitert, ohne dass jemand mitgeschrieben hat, warum eine Entscheidung getroffen wurde. Warum diese eine Tabelle doppelt geführt wird. Warum der Import-Prozess an einer bestimmten Stelle pausiert. Ein externes Team, das neu einsteigt, sieht nur den Code. Es sieht nicht die Kundenreklamation aus dem Jahr 2016, die zu dieser Lösung geführt hat.

Ohne Dokumentation bedeutet jede Änderung ein Risiko. Das externe Team arbeitet vorsichtig, testet viel, fragt viel nach. Das kostet Zeit und damit Geld, und zwar deutlich mehr, als ein Angebot auf den ersten Blick vermuten lässt.

Unklare Anforderungen führen zu falschen Annahmen

Bei einem Neubau lässt sich vorab ein Lastenheft schreiben. Bei einem gewachsenen System mit hunderten Sonderfällen ist das kaum möglich. Ein externer Dienstleister trifft deshalb Annahmen. Manche davon sind richtig. Manche nicht.

Das Ergebnis: Eine Anpassung funktioniert technisch einwandfrei, bricht aber einen Sonderfall, den intern jeder kannte, aber niemand aufgeschrieben hatte. Solche Fehler zeigen sich oft erst im laufenden Betrieb, wenn Kunden sich melden.

Kritisches Domänenwissen lässt sich nicht einfach übertragen

Manche Logik in Legacy-Systemen bildet keine allgemeine Programmierregel ab, sondern eine sehr spezifische Geschäftsregel Ihres Unternehmens: eine Preisberechnung mit historisch gewachsenen Ausnahmen, eine Freigabelogik, die auf eine alte Vertriebsstruktur zurückgeht. Dieses Wissen sitzt selten in einem Handbuch. Es sitzt bei den Menschen, die es seit Jahren mit dem System zu tun haben.

Ein externes Team kann Code lesen. Es kann keine Entscheidung nachvollziehen, die vor zehn Jahren in einem Meeting getroffen und nie dokumentiert wurde. Diese Lücke lässt sich nicht durch mehr Stunden schließen, sondern nur durch echten Wissenstransfer von den Menschen, die das System verstehen.

Was passiert, wenn Sie trotzdem outsourcen

Wenn eines oder mehrere dieser drei Probleme zutreffen und trotzdem ausgelagert wird, zeigt sich das meist in drei Phasen. Zuerst dauert die Einarbeitung länger als geplant, weil das externe Team Fragen stellen muss, die eigentlich beim internen Kickoff hätten geklärt werden müssen. Danach häufen sich kleine Fehler, weil Annahmen falsch waren und niemand sie vorher korrigieren konnte. Am Ende steht häufig ein Projekt, das teurer wird als die interne Lösung, die man ursprünglich vermeiden wollte.

Das bedeutet nicht, dass Outsourcing grundsätzlich falsch ist. Es bedeutet, dass die Vorbereitung entscheidet, ob es funktioniert oder nicht.

In der Praxis sieht das oft so aus: Ein Angebot liegt bei einem festen Stundenkontingent, weil die Aufgabe klar umrissen schien. Nach den ersten Wochen zeigt sich, dass die Hälfte der Stunden für Recherche draufgeht, nicht für die eigentliche Arbeit. Das Kontingent ist aufgebraucht, bevor die ursprüngliche Aufgabe fertig ist. Ein Nachtrag wird nötig, die Kosten steigen, und der Zeitplan verschiebt sich um Wochen. Das ist kein Ausnahmefall, sondern die logische Folge, wenn Wissen fehlt, das eigentlich am Anfang hätte geklärt werden müssen.

Woran Sie die Grenze frühzeitig erkennen

Ein paar einfache Fragen zeigen schon vor der Beauftragung, ob ein Legacy-Projekt outsourcing-tauglich ist. Gibt es eine aktuelle technische Beschreibung des Systems, oder existiert nur Code ohne Erklärung? Kann jemand im Unternehmen innerhalb eines Tages eine fachliche Rückfrage beantworten? Wurden die letzten drei größeren Änderungen am System dokumentiert, oder weiß nur noch eine Person, was damals gemacht wurde?

Wenn Sie diese Fragen nicht klar beantworten können, ist das kein Grund, Outsourcing komplett auszuschließen. Es ist ein Signal, zuerst die Grundlage zu schaffen, bevor Sie einen Auftrag vergeben.

Was Sie stattdessen tun können

Bevor Sie ein Legacy-Projekt auslagern, lohnt sich eine ehrliche Bestandsaufnahme. Wer im Unternehmen kennt das System wirklich? Gibt es überhaupt jemanden, der Fragen beantworten kann, wenn das externe Team welche hat? Wenn die Antwort Nein lautet, ist eine reine Übergabe an einen externen Dienstleister riskant, egal wie erfahren das Team ist.

Sinnvoller ist häufig eine Übergangsphase, in der internes Wissen gezielt an das externe Team weitergegeben wird, bevor die eigentliche Arbeit beginnt. Wie ein solcher Übergang bei der Legacy-Wartung in der Praxis abläuft, beschreiben wir in unserem Artikel zur Übergabe bei Legacy-Software-Wartung.

In manchen Fällen ist auch ein hybrides Modell die bessere Lösung: ein kleiner interner Kern, der das Domänenwissen hält, ergänzt durch ein externes Team für die operative Wartung. Wann Inhouse, wann Outsourcing und wann eine Kombination aus beidem sinnvoll ist, haben wir in unserem Vergleich Inhouse oder Outsourcing bei Legacy-Wartung genauer aufgeschlüsselt.

Und wenn intern schlicht niemand mehr da ist, der das System kennt, weil der zuständige Entwickler das Unternehmen längst verlassen hat, ist das ein eigenes Problem, das zuerst gelöst werden muss. Wie Unternehmen in dieser Situation vorgehen, zeigt unser Artikel zum Entwickler-Engpass bei Legacy-Projekten.

Fazit: Outsourcing ist kein Ersatz für fehlendes Wissen

Outsourcing löst ein Kapazitätsproblem. Es löst kein Wissensproblem. Wenn Dokumentation fehlt, Anforderungen unklar sind oder kritisches Domänenwissen nur bei wenigen Menschen liegt, braucht es zuerst einen strukturierten Übergang, bevor ein externes Team sinnvoll arbeiten kann.

Wer das übergeht, zahlt am Ende drauf, nicht weil der Dienstleister schlecht war, sondern weil die Grundlage gefehlt hat.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihr System an und sagen Ihnen ehrlich, ob und wie Outsourcing für Ihre Situation funktioniert.