„So wie die alte Software.“ Fünf Worte, die nach klaren Anforderungen klingen. In der Praxis sind sie der Beginn eines Projekts, das fast immer teurer und langwieriger wird als geplant. Wer Legacy Software ablösen will, stößt nach dutzenden solcher Projekte auf dieselbe Erkenntnis: Diese fünf Worte sind keine Anforderungsspezifikation. Sie sind eine Falle.

Die unsichtbare Komplexität

Bestandssoftware, die über Jahre oder Jahrzehnte gewachsen ist, enthält weit mehr Funktionalität, als auf den ersten Blick sichtbar ist. Das liegt in der Natur gewachsener Systeme.

Da ist der Jahresreport, an den gerade niemand denkt, weil er nur einmal im Jahr läuft. Die 47 Sonderfälle, die über die Jahre eingebaut wurden, ohne dass sie je dokumentiert wurden. Die Schnittstelle zu einem Drittsystem, die ein Kollege vor fünf Jahren eingerichtet hat und die seitdem „einfach läuft“. Die Berechtigungslogik, die so komplex ist, dass niemand mehr erklären kann, warum bestimmte Nutzergruppen bestimmte Funktionen sehen und andere nicht.

All das ist funktionale Komplexität, die im Alltagsbetrieb unsichtbar bleibt. Sie taucht nicht in der Benutzeroberfläche auf, nicht in der Schulungsunterlage und meistens nicht in der Dokumentation. Sie wird erst sichtbar, wenn jemand versucht, das System nachzubauen, und feststellt, dass die sichtbaren 70% der Funktionalität vielleicht 40% des tatsächlichen Aufwands ausmachen.

Für die Projektplanung bedeutet das: Eine Aufwandsschätzung, die auf dem basiert, was Nutzer sehen und beschreiben können, unterschätzt den tatsächlichen Umfang systematisch. Die unsichtbare Komplexität taucht erst während der Umsetzung auf, in Form von Rückfragen, Nachspezifikationen und Korrekturen.

Die falsche Frage: „Genau das Gleiche nochmal“

Die zweite Falle liegt in der Annahme, dass die alte Software den heutigen Bedarf korrekt abbildet. In den meisten Fällen tut sie das nicht.

Hat sich die Welt in den letzten 10 Jahren nicht verändert? Neue Prozesse, neue gesetzliche Vorgaben, neue Anforderungen aus dem Markt? Funktionen, die vor 10 Jahren wichtig waren, werden heute möglicherweise gar nicht mehr genutzt. Und Funktionen, die heute gebraucht werden, existieren in der alten Software nicht, weil sie nie eingeplant waren.

„So wie bisher“ ist oft nicht die durchdachte Anforderung, als die sie erscheint. Es ist die bequemste Antwort, weil sie niemandem abverlangt, wirklich nachzudenken. Es ist einfacher zu sagen „mach es wie vorher“ als sich hinzusetzen und zu analysieren, was heute tatsächlich gebraucht wird.

Das Ergebnis: Eine neue Software, die alte Probleme originalgetreu reproduziert. Inklusive der Workarounds, die Nutzer über die Jahre entwickelt haben, weil die Software ihren eigentlichen Bedarf nicht abgedeckt hat.

Was stattdessen funktioniert

Ablöseprojekte, die gut laufen, behandeln die alte Software als Informationsquelle, nicht als Blaupause. Der Unterschied liegt im Vorgehen.

Anforderungen neu definieren, nicht kopieren: Statt die alte Software Feature für Feature nachzubauen, wird gefragt: Was brauchen die Nutzer heute? Welche Geschäftsprozesse soll die Software unterstützen? Welche Probleme soll sie lösen? Die alte Software liefert dabei wertvolle Hinweise, welche Funktionen tatsächlich genutzt werden. Aber sie definiert nicht, was die neue Software können muss.

Funktionsnutzung analysieren: Welche Funktionen werden täglich genutzt? Welche monatlich? Welche seit drei Jahren nicht mehr? Diese Analyse liefert ein realistisches Bild des tatsächlichen Bedarfs. In fast jedem Ablöseprojekt stellt sich heraus, dass 30 bis 40% der Funktionen der alten Software nicht mehr oder kaum noch genutzt werden. Diese Funktionen nicht nachzubauen, spart erheblichen Aufwand, ohne dass jemand etwas vermisst.

Unsichtbare Komplexität aktiv suchen: Vor dem Projektstart gezielt nach den Dingen fragen, die nicht offensichtlich sind: Welche Reports gibt es? Welche Schnittstellen? Welche Sonderfälle? Welche zeitgesteuerten Prozesse? Welche Berechtigungsregeln? Diese Erhebung kostet Zeit am Anfang, spart aber ein Vielfaches an Überraschungen während der Umsetzung.

Die Ablösung als Chance nutzen: Ein Ablöseprojekt ist der ideale Zeitpunkt, um Prozesse zu hinterfragen. Nicht nur die Software wechselt, auch die Abläufe können verbessert werden. Unternehmen, die diese Chance nutzen, bekommen am Ende nicht nur eine neue Software, sondern auch bessere Prozesse.

Warum „schnell ablösen“ selten funktioniert

In vielen Ablöseprojekten herrscht Zeitdruck. Die alte Software wird abgekündigt, der Support läuft aus, die Technologie ist veraltet. Die Versuchung ist groß, die Analysephase abzukürzen: „Wir wissen doch, was die Software macht. Einfach nachbauen.“

Diese Abkürzung rächt sich fast immer. Die ersten Monate laufen scheinbar gut. Dann tauchen die Sonderfälle auf, die niemand dokumentiert hatte. Die Buchhaltung meldet sich, weil der Jahresabschluss-Report fehlt. Die Fachabteilung stellt fest, dass eine Funktion, die als unwichtig eingestuft wurde, doch geschäftskritisch ist.

Jede dieser Nachforderungen kostet mehr, als eine gründliche Analyse am Anfang gekostet hätte. Nicht weil die Analyse teuer ist, sondern weil Änderungen während der Umsetzung um ein Vielfaches aufwändiger sind als Klärungen vor dem Start.

Realistische Erwartungen setzen

Ein Ablöseprojekt ist kein einfacher Technologietausch. Es ist ein Neubauprojekt mit dem zusätzlichen Anspruch, die Erfahrungen aus dem Altsystem zu berücksichtigen. Das macht es nicht einfacher als ein Neuprojekt, sondern in manchen Aspekten komplexer, weil die Erwartungshaltung durch die bestehende Software geprägt ist.

Realistische Erwartungen sehen so aus. Die neue Software wird in der ersten Version nicht alles können, was die alte konnte. Das ist kein Scheitern, das ist der normale Verlauf. Die alte Software hatte Jahre, um zu dem zu werden, was sie ist. Die neue Software deckt in der ersten Version die 80 Prozent ab, die 95 Prozent des Geschäftswerts ausmachen. Die restlichen Funktionen folgen iterativ, priorisiert nach tatsächlichem Bedarf.

Fazit

„So wie die alte Software“ klingt nach einer einfachen Anforderung. In der Praxis unterschätzt sie die unsichtbare Komplexität gewachsener Systeme und verhindert, dass die Ablösung als Chance für Verbesserungen genutzt wird. Ablöseprojekte gelingen, wenn Anforderungen neu gedacht werden, statt alte Funktionslisten zu kopieren. Die alte Software ist eine wertvolle Informationsquelle. Aber sie ist keine Blaupause für die Zukunft.