Anwendung und Wertschöpfung gemeinsam untersuchen
Zu klären ist, welche Geschäftsprozesse die Software trägt, wie häufig sie verändert wird und wo Störungen entstehen. Eine stabile Abrechnung mit seltenen Änderungen hat andere Bedürfnisse als ein Produktbereich mit vielen neuen Funktionen. Technische Schulden sind daher nicht nur nach Codeästhetik zu bewerten. Fachwissen, Datenqualität und verfügbare Personen beeinflussen das Risiko ebenso.
Nicht jede Modernisierung bedeutet Neuschreiben
Mögliche Schritte reichen von besserer Testabdeckung über aktualisierte Laufzeiten bis zur Entkopplung einzelner Funktionen. Bei einem schrittweisen Ersatz werden neue Aufgaben nach und nach außerhalb des Altsystems umgesetzt. Dafür müssen Datenverantwortung und Übergänge klar bleiben. Zwei teilweise führende Systeme ohne abgestimmte Regeln können schwieriger sein als das ursprüngliche System.
Verhalten und Rückweg absichern
Vor einer Umstellung sollten wichtige Ergebnisse reproduzierbar sein. Vergleichsläufe zeigen Unterschiede in Berechnung, Rundung oder Datenübernahme. Eine Rückkehr ist nur möglich, wenn zwischenzeitliche Änderungen berücksichtigt werden. Ein Backup allein löst das nicht, wenn andere Systeme bereits mit neuen Daten weitergearbeitet haben.
Beispiel: Ein Bestellprozess wächst aus dem Kernsystem heraus
Zuerst wird die Bestandsauskunft über eine stabile Schnittstelle verfügbar. Neue Kundenfunktionen entstehen daneben. Erst wenn Datenflüsse, Tests und Betrieb verlässlich sind, wird eine begrenzte Schreibfunktion übernommen. Der Nutzen wird pro Schritt messbar, ohne das gesamte Projekt an einen einzigen großen Umschalttag zu binden.
Womit Sie sinnvoll beginnen können
- Den wirtschaftlich wichtigsten Engpass statt das älteste Modul auswählen.
- Führende Datenquelle und Verantwortlichkeiten je Übergangsphase festlegen.
- Vergleichsläufe und Wiederanlauf vor der Produktivumstellung erproben.