Ein neues System ist noch kein Erfolg, wenn das Geschäftsproblem dahinter ungelöst bleibt. Erfolgreiche Modernisierung braucht klare Ziele, realistische Planung und regelmäßige Überprüfung. Die folgenden zehn Beispiele zeigen typische Wege zum Scheitern und was du besser machen kannst. Zuerst klären wir, woran Erfolg überhaupt zu erkennen ist.
Erfolg lässt sich ganz einfach messen: Wir sind jetzt modern. Modern zu sein, ist aber kein Geschäftsergebnis. Eine neue Plattform zeigt allein auch nicht, ob Durchlaufzeiten, Störungen oder Betriebskosten besser werden. Lege vor der Technologieentscheidung fest, welches Problem du lösen willst. Bestimme außerdem, wer den Nutzen verantwortet und woran ihr eine Verbesserung erkennt. Erfasse den Ausgangszustand. Vereinbare realistische Zielwerte und einen Zeitpunkt, zu dem ihr sie prüft. So ersetzt die Zahl migrierter Anwendungen nicht den tatsächlichen Nutzen. Unser Artikel Von der Idee zum klaren Projektziel zeigt, wie du Ziele konkretisieren kannst.
Wenn schon modernisieren, dann alles auf einmal. Abhängigkeiten lösen sich bekanntlich, sobald man sie migriert. Ein Big Bang stellt das Gesamtsystem auf einmal um. Dadurch bündelt er technische, fachliche und organisatorische Risiken in einem einzigen Umschaltmoment. Teile die Arbeit in überprüfbare Schritte, wenn das fachlich und technisch sinnvoll ist. Starte mit einem begrenzten Bereich. Nutze dessen Ergebnisse für den nächsten Schritt. Ein Big Bang kann wegen eines Support-Endes, einer Vertragsfrist oder zwingender Schnittstellenänderungen nötig sein. Auch in diesem Fall helfen frühe Probeläufe und klare Abnahmekriterien.
Der Vertrag ist unterschrieben, also kann der Dienstleister ab jetzt auch die Verantwortung übernehmen. Die Umsetzung lässt sich vergeben. Die Folgen einer Fehlentscheidung bleiben aber beim Unternehmen. Lege intern fest, wer Geschäftsziele, Architektur und Prioritäten verantwortet. Triff zentrale Entscheidungen gemeinsam mit dem Partner. Lass Annahmen, Optionen und Auswirkungen dokumentieren. Plane Wissenstransfer und Betrieb von Beginn an ein. Ein externer Partner kann das Team gezielt verstärken. Das Unternehmen sollte das neue System aber auch ohne ihn erklären können.
Sechs Monate ohne Demo sind kein fehlender Fortschritt, sondern ein sorgfältig gehüteter Überraschungseffekt. Ohne regelmäßig prüfbare Ergebnisse können falsche Annahmen, Integrationsprobleme und Kostenrisiken bis kurz vor dem Go-live unbemerkt bleiben. Vereinbare kurze Review-Zyklen mit lauffähigen, integrierten Ergebnissen. Prüfe dabei auch offene Risiken, Abhängigkeiten und Entscheidungen. Zeige Zwischenstände den Fachbereichen und halte fest, was sich geändert hat. Ein Status in Prozent ist kein Ersatz für lauffähige Software. Personen außerhalb des Teams sollten die Ergebnisse sinnvoll ausprobieren können.
Anwenderfeedback holen wir am besten erst, wenn wirklich nichts mehr geändert werden kann. Dann kann man es immerhin ordentlich protokollieren. Personen, die tägliche Abläufe kennen, entdecken oft Ausnahmen, manuelle Zwischenschritte und ungeschriebene Regeln. In Anforderungen fehlen diese Details häufig. Beziehe repräsentative Nutzer und Fachbereiche früh ein. Gehe kritische Abläufe gemeinsam mit ihnen durch. Teste deine Annahmen an echten Fällen. Plane ihre Zeit ein. Beteiligung ist kein Feierabend-Hobby. Unser Beitrag zum Stakeholder-Management zeigt, wie du Stakeholder früh einbindest und ihre Erwartungen klärst.
Jede Sonderregel aus dem Altsystem ist unverzichtbare Geschäftslogik. Am besten kopieren wir sie bytegenau in den neuen Stack. Dann bleibt wenigstens alles beim Alten. Manche Regeln sind tatsächlich geschäftlich oder regulatorisch notwendig. Andere sind Workarounds für längst verschwundene Grenzen. Prüfe vor dem Nachbau, welches Verhalten wirklich gebraucht wird. Sichere kritische Geschäftsregeln mit Tests. Entscheide bewusst, was vereinfacht oder entfällt. Wenn du dieselben Entscheidungen ungeprüft übernimmst, bleiben enge Kopplung und fehlende Tests bestehen. Eine neue Technologie ändert daran nichts. Technische Schulden und verlorenes Wissen können im Betrieb zum Geschäftsrisiko werden. Mehr dazu liest du in unserem Beitrag zu den versteckten Kosten alter Software.
Das Altsystem macht genau, was im Lastenheft von 2009 steht, nicht mehr und nicht weniger. In gewachsenen Anwendungen stecken wichtige Regeln oft in Hintergrundjobs, Datenbank-Triggern, Exporten oder Excel-Dateien. Andere stehen in den Köpfen derjenigen, die beim Workshop zufällig Urlaub haben. Analysiere kritische Datenflüsse, Schnittstellen, Sonderfälle und manuelle Schritte, bevor du belastbar schätzt. Beziehe außerdem die Personen ein, die den Betrieb tatsächlich kennen. Starte mit einer begrenzten Analysephase. Sobald neue Abhängigkeiten sichtbar werden, überprüfe Zeit- und Budgetannahmen. Bei Jahrzehnten gewachsener Fachlogik ist eine erste Schätzung eine Hypothese, kein Lieferversprechen. Unsere Kundenreferenz Moderne Software für etablierte Messsysteme ist ein Praxisbeispiel zur Ablösung einer historisch gewachsenen Anwendung mit komplexem Anforderungsprofil.
Sicherheitsanforderungen prüfen wir kurz vor dem Go-live. Dann müssen wir die Architektur wenigstens nur noch einmal neu bauen. Sicherheits- und Compliance-Anforderungen können Datenmodell, Identitäten, Protokollierung, Hosting und Freigaben beeinflussen. Dazu gehören geltende Schutz- und Nachweispflichten. Kläre früh, welche Vorgaben für Produkt, Branche und Daten gelten. Prüfe sie im Projektverlauf erneut. Hole die zuständigen Personen rechtzeitig dazu. Überziehe aber nicht jede Anwendung vorsorglich mit denselben Kontrollen.
Datenmigration ist nur ein Knopfdruck zwischen Deploy und Applaus. Den Ablaufplan schreiben wir, wenn der Knopf schon funktioniert. In der Realität hängen Umschaltung und Rückfall von Datenvolumen, Schreibzugriffen, Schnittstellen und zulässiger Ausfallzeit ab. Plane Datenbereinigung, Übertragung, fachliche Abgleiche, Pilotierung, Zuständigkeiten und Entscheidungspunkte vorab. Übe den Übergang mit realistischen Daten. Nach neuen Schreibvorgängen ist ein Rollback nicht automatisch sicher. Lege vorher fest, wie ihr Änderungen abgleicht oder im Fehlerfall behandelt.
Der Build ist grün und die Demo läuft. Die Software ist also sicher, schnell und wartbar. Drei Qualitätsziele zum Preis eines erfolgreichen Compiles. Lege vor der Umsetzung fest, welche Qualitätsmerkmale wichtig sind. Bestimme auch, wie ihr sie prüft. Dazu zählen zum Beispiel Antwortzeiten kritischer Vorgänge, Wiederherstellbarkeit, Wartbarkeit und Testbarkeit. Verknüpfe diese Erwartungen früh mit passenden Tests und nachvollziehbarer Betriebsdokumentation. So werden sie am Ende nicht zur Wunschliste. Qualitätsziele brauchen realistische Grenzwerte und einen Blick auf Aufwand und Lieferumfang. Unser Beitrag zu nicht-funktionalen Anforderungen zeigt, wie du solche Kriterien formulierst.
Ein Modernisierungsprojekt wird nicht dadurch erfolgreich, dass es .NET, Azure oder eine Cloud-Plattform verwendet. Entscheidend ist, ob das Projekt ein klar benanntes Geschäftsproblem löst und Risiken in beherrschbaren Schritten senkt. Nach dem Go-live sollte sich das neue System außerdem leichter ändern und betreiben lassen. Ein vollständiger Ersatz kann in einzelnen Situationen sinnvoll sein, ist aber kein Qualitätsmerkmal an sich.
Wenn du morgen starten willst, wähle einen kritischen Ablauf. Notiere den aktuellen Aufwand und die größten Risiken. Benenne eine Person, die fachlichen Nutzen und technische Entscheidungen zusammenhält. So kannst du einen ersten begrenzten Schritt umsetzen. Prüfe sein Ergebnis, bevor du die nächste Investition tätigst.
Wie verhindert ihr, dass eure Modernisierung alte Probleme nur in einen neuen Stack verschiebt? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.
Weitere Artikel zu ähnlichen Themen.
