Ersetzen statt modernisieren: Wann Standardsoftware oder SaaS die bessere Option ist
Die dritte Option neben Weiterbetrieb und Modernisierung: Wann Standardsoftware oder eine SaaS-Lösung ein gewachsenes System ersetzen sollte, welche Kriterien entscheiden und wo der Ersatz nur die Abhängigkeit verschiebt. Entscheidungshilfe für CTOs und Geschäftsführung.
Die Entscheidungsmatrix für ein gewachsenes System kennt drei Optionen: weiterbetreiben und absichern, schrittweise modernisieren, ersetzen. Zu den ersten beiden gibt es auf dieser Website eigene Artikel. Die dritte kommt bisher zu kurz. Ersetzen kann auch eine Neuentwicklung heißen. Dieser Artikel behandelt den Ersatz durch Standardsoftware oder SaaS. Dass die Option bisher fehlte, liegt auch an mir. Ich berate zu Modernisierung, und ein Berater neigt zu der Option, die er am besten kennt. In einem Teil der Fälle ist der Ersatz durch Standardsoftware oder eine SaaS-Lösung trotzdem die bessere Entscheidung. Dieser Artikel beschreibt, woran Sie diese Fälle erkennen und wo der Ersatz teurer wird als gedacht.
Wann der Ersatz die naheliegende Option ist
Standardsoftware passt, wenn der Prozess dahinter kein Unterscheidungsmerkmal Ihres Geschäfts ist. Buchhaltung, Personalverwaltung, Dokumentenablage, Ticketbearbeitung und große Teile des Kundenkontakts laufen in den meisten Unternehmen nach denselben Regeln. Ein eigenes System für diese Prozesse zu pflegen bindet Kapazität, die am Kerngeschäft fehlt.
Dazu kommen vier Anzeichen, die in Gesprächen immer wieder auftauchen. Der Fachbereich würde seinen Prozess an eine Software anpassen, wenn sie dafür stabil läuft. Der Markt für diese Softwarekategorie ist reif, mit mehreren Anbietern und Referenzen aus Ihrer Branche. Regulatorische Änderungen wie die E-Rechnung oder neue Meldeformate liefert der Anbieter als Update. Und die Regeln im Altsystem sind bei genauer Betrachtung Standardregeln mit ein paar historischen Sonderfällen.
Besonders die regulatorische Pflege ist in Finanzunternehmen ein starkes Argument. Wer Meldewesen oder Zahlungsverkehr selbst entwickelt, trägt jede Änderung der Aufsicht allein. Ein Anbieter verteilt diese Kosten auf alle Kunden.
Wo der Ersatz teurer wird als gedacht
Konfiguration innerhalb der Parameter, die das Produkt vorsieht, ist unkritisch. Die Entscheidung kippt, sobald Fachlogik als Erweiterung oder Eigencode in das Produkt gebaut wird, um altes Verhalten nachzubilden. Jede solche Anpassung baut das Altsystem im Produkt nach, diesmal in einer Umgebung, die Sie nicht kontrollieren. Nach meiner Erfahrung hat ein solches Projekt nach wenigen Jahren dieselben Eigenschaften wie das abgelöste System. Niemand kennt die Anpassungen, Updates des Herstellers werden zum Risiko, und der Anbieter rechnet jede Änderung einzeln ab.
Sechs Posten werden bei der Ersatzentscheidung regelmäßig unterschätzt.
- Datenmigration. Ihre Daten müssen in das Datenmodell des Anbieters passen. Historie, Sonderfälle und Nachweispflichten machen daraus ein eigenes Teilprojekt. Die Muster dafür beschreibt der Artikel zur Datenmigration bei der Ablösung eines Kernsystems.
- Schnittstellen. Das Standardprodukt muss mit den verbleibenden Systemen reden. Jede Schnittstelle, die heute direkt in die Datenbank greift, wird neu gebaut.
- Prozessumstellung. Der Fachbereich arbeitet anders als bisher. Schulung, Doppelarbeit in der Übergangszeit und ein Produktivitätseinbruch in den ersten Monaten sind real und stehen selten im Angebot.
- Vertragsbindung. Laufzeiten, Preisanpassungsklauseln und Kosten je Nutzer verändern die Rechnung über fünf Jahre deutlich. Lassen Sie das Preismodell mit Ihrem erwarteten Wachstum durchrechnen.
- Verschobene Abhängigkeit. Heute hängen Sie an Ihrem eigenen Altsystem und kontrollieren den Code. Nach dem Ersatz hängen Sie am Anbieter und kontrollieren den Vertrag. Das ist nur dann ein Fortschritt, wenn der Vertrag Datenexport, Übergangsunterstützung und Kündigungsrechte regelt. In Finanzunternehmen verlangt die DORA-Verordnung für kritische oder wichtige Funktionen eine dokumentierte und getestete Exit-Strategie.
- Besonderheiten bei SaaS. Der Anbieter bestimmt, wann Updates kommen. Die Verfügbarkeit hängt an seinem Betrieb und an Ihrer Netzanbindung. Der Datenstandort muss zu Datenschutz und Aufsicht passen. In Finanzunternehmen ist ein SaaS-Vertrag eine IKT-Dienstleistung im Sinne der DORA-Verordnung. Er gehört ins Informationsregister, und für kritische oder wichtige Funktionen schreibt Artikel 30 Vertragsinhalte wie Kündigungsrechte, Datenzugang und Mitwirkung an Tests vor.
Die Prüfkriterien im Vergleich
| Kriterium | Spricht für Ersatz | Spricht für Modernisieren |
|---|---|---|
| Unterscheidungsmerkmal | Der Prozess ist in der Branche Standard | Der Prozess ist Teil des Geschäftsmodells oder des Preisvorteils |
| Anpassungsbedarf | Der Fachbereich kann sich an das Produkt anpassen | Das Produkt müsste stark angepasst werden |
| Datenmodell | Die eigenen Daten passen ohne große Verluste in das Zielmodell | Historie, Sonderfälle und Verknüpfungen lassen sich nicht abbilden |
| Schnittstellen | Wenige, dokumentiert, über Standardformate | Viele Direktzugriffe auf die Datenbank, Partner außerhalb Ihrer Kontrolle |
| Regulatorische Pflege | Der Anbieter liefert Änderungen für alle Kunden | Die Anforderungen sind hausspezifisch |
| Team und Wissen | Kapazität für Eigenentwicklung fehlt, das Wissen über das Altsystem ist weg | Das Team kennt die Fachlogik und kann sie schrittweise übertragen |
| Abhängigkeit | Reifer Markt, ein Wechsel zwischen Anbietern ist üblich | Ein Anbieter dominiert, der Export ist eingeschränkt |
| Zeitdruck | Das Supportende steht an, das Produkt ist kurzfristig einführbar | Eine abgegrenzte Pilotablösung ist schneller als die Einführung |
Diese acht Fragen klären Sie mit Fachbereich und Geschäftsführung, bevor Sie einen Anbieter einladen.
Die Kombination: Standard außen, Eigenentwicklung im Kern
In den meisten Projekten, die ich begleitet habe, ist die Antwort keine der drei Optionen allein. Ein Kernsystem enthält Funktionen, die das Geschäft tragen, und Funktionen, die nur historisch dort gelandet sind. Vertragsverwaltung, Preisfindung oder Risikobewertung bleiben Eigenentwicklung. Dokumentenablage, Kundenkommunikation oder Buchhaltung wandern in ein Produkt.
Technisch ist das derselbe Weg wie bei der schrittweisen Modernisierung. Das Strangler-Fig-Pattern löst eine Funktion aus dem Altsystem heraus. Ob dahinter ein eigener Dienst oder ein eingekauftes Produkt steht, ist für das Muster unerheblich. Die Schnittstelle dazwischen entscheidet, ob der Anbieter austauschbar bleibt. Eine API-First-Strategie mit einer eigenen Schicht vor dem Produkt hält die Fachlogik bei Ihnen und macht den Anbieter austauschbar.
So wird die Entscheidung belastbar
Rechnen Sie den Ersatz in der Business-Case-Tabelle über denselben Zeitraum wie die anderen Optionen. Die Tabelle sieht für den Ersatz drei Positionen vor. Einführung, Anpassung und Migration sind der Einmalaufwand. Lizenzen und Zielbetrieb sind die laufenden Kosten. Übergang, Schulung und Vertragsablösung bilden den Übergangsaufwand. Wie die Rechnung aufgebaut ist, beschreibt der Artikel zu den Kosten einer Legacy-Modernisierung.
Vor der Unterschrift hat sich ein Proof of Concept mit dem Anbieter bewährt. Dafür wählen Sie die fünf schwierigsten Vorgänge aus Ihrem Tagesgeschäft und eine Stichprobe Ihrer echten Daten. Der Anbieter zeigt, wie diese Vorgänge im Produkt laufen und wie die Daten hineinkommen. Verlangen Sie im selben Schritt einen vollständigen Export in einem dokumentierten Format. Ein Anbieter, der das nicht leisten will, hat Ihre Exit-Frage bereits beantwortet.
Sprechen Sie außerdem mit zwei Referenzkunden ähnlicher Größe über das, was nach der Einführung kam: Updatezyklen, Preisentwicklung, Reaktionszeiten im Support und der Umgang mit Sonderwünschen.
Nächster Schritt
Wenn die Abwägung zwischen Weiterbetrieb und Migration noch offen ist, hilft der Artikel .NET Framework weiterbetreiben oder migrieren?. Für einen unabhängigen Vergleich aller drei Optionen mit Zahlen und Pilotplan ist die Beratung zur Legacy-Modernisierung der passende Rahmen. Ein Architektur-Review klärt vorab, welche Funktionen den Kern bilden und welche sich für ein Produkt eignen.