Wann lohnt sich die Ablösung des alten Systems — und wann reicht eine Modernisierung?

Viele Unternehmen — besonders in der Versicherungsbranche — haben ein System, von dem alle wissen, dass es veraltet ist, und arbeiten trotzdem seit Jahren damit weiter. Die Oberfläche wirkt alt, die Daten leben verstreut in verschiedenen Systemen, neue Funktionen lassen sich immer schwerer und langsamer einbauen — aber die Ablösung des Systems erscheint als beängstigendes, riskantes und teures Projekt, weshalb sie lieber aufgeschoben wird.

Dieses Aufschieben ist verständlich, hat aber seinen Preis. Ein veraltetes, unterentwickeltes Vertriebsportal verlangsamt die Vertriebsprozesse, verschlechtert die Kundenerfahrung, und jede neue Funktion oder Integration lässt sich immer schwerer daran anbinden. Die Frage ist mit der Zeit nicht mehr, ob eine Veränderung nötig ist, sondern wann und wie man sie am besten angeht.

Dieses Problem beschränkt sich nicht auf die Versicherungsbranche, auch wenn es dort oft am deutlichsten sichtbar ist — wegen der langen Produktlebenszyklen und des regulatorischen Umfelds schleppen viele Versicherer jahrzehntealte Systeme im Hintergrund mit. Dasselbe Muster zeigt sich in jeder Branche, in der ein Unternehmen schnell gewachsen ist, während die IT-Basis mit diesem Wachstum nicht Schritt gehalten hat.

Warum wird diese Entscheidung so oft aufgeschoben?

Die meisten Geschäftsführerinnen und Geschäftsführer wissen genau, dass das System veraltet ist — trotzdem verschiebt sich die Entscheidung Jahr für Jahr weiter. Dafür gibt es mehrere Gründe. Erstens ruft der Gedanke an eine Ablösung sofort das Bild eines großen, riskanten, monate- oder jahrelangen Projekts hervor, für das sich schwer der richtige Zeitpunkt finden lässt — es gibt immer eine wichtigere, dringendere Aufgabe. Zweitens funktioniert das alte System trotz all seiner Mängel noch — diese Art von "Was nicht ganz kaputt ist, muss man nicht anfassen"-Denken hält an vielen Stellen den Status quo aufrecht. Drittens fehlt oft die interne Kapazität oder das Fachwissen, um gründlich einzuschätzen, welche Richtung überhaupt die richtige wäre — Ablösung, Modernisierung, oder nur die Behebung ein oder zwei kritischer Schwachstellen.

Währenddessen wird das System mit jedem Jahr schwerer zu warten. Entwicklerinnen und Entwickler, die die alte Technologie kennen, sind am Markt immer schwerer zu finden. Der Einbau neuer Funktionen frisst immer mehr Arbeitsstunden, weil die alte Architektur nicht für solche Erweiterungen konzipiert wurde. Und mit jeder aufgeschobenen Entscheidung wächst das Risiko, dass ein unerwarteter Fehler oder eine regulatorische Änderung den Schritt erzwingt — im ungünstigsten Moment, unvorbereitet.

Ablösung oder Modernisierung?

Nicht bei jedem Legacy-System ist die vollständige Ablösung der einzige Weg. Manchmal liefert die schrittweise Modernisierung eines bestehenden Systems — die Erneuerung der Oberfläche, die Ordnung der Datenstruktur, das Hinzufügen neuer Funktionen auf der bestehenden Basis — genau das gewünschte Ergebnis, mit deutlich geringerem Risiko und kürzerer Durchlaufzeit als der komplette Neuaufbau eines Systems.

Keine der beiden Lösungen ist grundsätzlich besser als die andere — die richtige Antwort hängt immer vom Zustand des jeweiligen Systems und den Zielen des Unternehmens ab. In anderen Fällen wiederum schränkt die bestehende Architektur die Weiterentwicklung so stark ein, dass langfristig ein auf neuer Basis aufgebautes System die kosteneffizientere Lösung ist — auch wenn das auf den ersten Blick wie die größere Investition aussieht. Wenn jede neue Funktion wegen der Grenzen der alten Struktur unverhältnismäßig viel Arbeit erfordert, oder wenn die technologische Basis des Systems nicht mehr unterstützt wird, kann das Flicken langfristig teurer sein als ein gut geplanter Neuaufbau.

Die richtige Antwort hängt immer von der jeweiligen Situation ab, und das lässt sich ohne eine gründliche Analyse nicht entscheiden. Deshalb beginnt jedes solche Projekt mit einer Discovery- und Anforderungsanalyse-Phase, deren Ziel nicht ist, das größtmögliche Projekt vorzuschlagen, sondern die kosteneffizienteste Lösung zu finden, die das Problem tatsächlich löst.

Eine konkrete Referenz

Bei einer ungarischen Versicherungsgesellschaft haben wir ein veraltetes, unterentwickeltes Vertriebsportal modernisiert: mit einer zeitgemäßen Benutzeroberfläche, neuen Funktionen und einer besser geordneten Datenverwaltung, die die Vertriebsprozesse direkt unterstützt. Das Projekt dauerte etwa ein Jahr — der genaue Zeitrahmen variiert je nach Umfang und Komplexität.

Bei jedem Schritt des Projekts haben wir einen konsultativen Ansatz verfolgt: Wir haben nicht geschaut, was technologisch die spannendste Lösung wäre, sondern welcher Weg am zuverlässigsten und kosteneffizientesten zum gewünschten Ergebnis führt. Diese Art von Modernisierungsarbeit ist derzeit ein aktiv wachsender Bereich unseres Angebots — wir bauen unsere Erfahrung auf diesem Gebiet laufend aus, und das Vertriebsportal-Projekt ist dabei unser Ausgangspunkt und unsere Vorzeigereferenz.

Was kostet das Aufschieben wirklich?

Die Kosten des Aufschiebens tauchen selten als eine einzelne Zeile im Budget auf, deshalb werden sie leicht unterschätzt. Tatsächlich zeigen sie sich an mehreren Stellen: Entwicklerinnen, Entwickler und Betriebsteams verbringen immer mehr Zeit damit, innerhalb der Grenzen des alten Systems nach Lösungen zu suchen; die Einführung neuer Funktionen oder regulatorischer Anpassungen dauert immer länger, weil das System nicht für solche Änderungen ausgelegt wurde; und die sich verschlechternde Kundenerfahrung — ein langsames, umständliches Portal — kann sich langfristig auch auf die Vertriebsergebnisse auswirken.

In der Versicherungsbranche kommt dazu häufig noch eine weitere Ebene: Das regulatorische Umfeld verändert sich laufend, und ein unflexibles, veraltetes System kann sich nur schwer an neue Compliance-Anforderungen anpassen. Je länger sich die Modernisierung verzögert, desto wahrscheinlicher wird es, dass eine regulatorische Frist den Schritt erzwingt — meist zu schlechteren Bedingungen, als wenn das Unternehmen das Projekt aus eigenem Antrieb und gut vorbereitet angeht.

Auf welche Anzeichen solltest du achten?

Ein paar wiederkehrende Anzeichen, die darauf hindeuten, dass es Zeit ist, sich mit dem Thema zu befassen: Kunden oder interne Mitarbeitende beschweren sich regelmäßig über die Langsamkeit oder Umständlichkeit des Systems; der Einbau einer neuen Funktion dauert Wochen oder Monate, was früher in wenigen Tagen erledigt gewesen wäre; es wird immer schwerer, Entwicklerinnen oder Entwickler zu finden, die die alte Technologie hinter dem System kennen; oder die Daten leben so verstreut, dass schon ein einfacher Report eine manuelle Datensammlung aus mehreren Systemen erfordert.

Wenn mehrere dieser Punkte vertraut klingen, lohnt es sich, so früh wie möglich — noch unter ruhigen Bedingungen — mit der Analyse zu beginnen. Nicht erst dann, wenn ein unerwarteter Fehler oder eine regulatorische Frist das Unternehmen bereits in eine Zwangslage bringt.

Wie ist ein solches Projekt aufgebaut?

Der Prozess beginnt immer mit Discovery und Anforderungsanalyse, gefolgt von der Lösungsplanung — dabei schlagen wir konsultativ das vor, was das gewünschte Ergebnis am kosteneffizientesten erreicht. Danach folgen die Entwicklung (üblicherweise Angular-Frontend, Java-Backend, wobei sich die Technologie flexibel an das jeweilige Projekt anpasst), das Testing und schließlich die Übergabe und Dokumentation.

Was solltest du von einer Discovery-Phase erwarten?

Eine gut aufgebaute Discovery-Phase untersucht nicht nur die technologische Ebene, sondern auch, wie das System im Arbeitsalltag tatsächlich genutzt wird, wo die häufigsten manuellen Workarounds entstehen und welche Funktionen tatsächlich geschäftlichen Wert schaffen. Genau diese gründliche Analyse unterscheidet einen konsultativen Ansatz von einer Entwicklerin oder einem Entwickler, die oder der einfach umsetzt, was zuerst verlangt wird — ohne zu hinterfragen, ob das wirklich der beste Weg ist.

Am Ende der Discovery-Phase steht ein klarer Vorschlag: Wo liegt die genaue Ursache des Problems, welche Lösungsrichtungen kommen infrage, und welche davon bringt das beste Verhältnis zwischen eingesetzten Ressourcen und erzieltem Geschäftsergebnis? Dieser Vorschlag ist die Grundlage für die weitere Planung — die Geschäftsführung startet damit nicht in ein vages "IT-Projekt", sondern trifft eine konkrete, begründete Geschäftsentscheidung.

Häufig gestellte Fragen

Wie lange dauert ein solches Projekt?

Das hängt stark vom Umfang und der Komplexität ab — eine vollständige Portal-Modernisierung kann bis zu einem Jahr dauern, während eine engere, gezieltere Entwicklung deutlich schneller umsetzbar ist.

Ist dieser Service auch außerhalb der Versicherungsbranche relevant?

Ja — auch wenn die Versicherungsbranche bislang unsere stärkste Referenz ist, tritt das Problem veralteter, unterentwickelter Systeme branchenunabhängig genauso auf, und unser Ansatz lässt sich ebenso auf andere Branchen anwenden.

Was, wenn wir nicht entscheiden können, ob wir eine Ablösung oder eine Modernisierung brauchen?

Genau das ist der Zweck der Discovery-Phase — man muss nicht im Voraus entscheiden, welche Richtung die richtige ist, denn das ist das Ergebnis der Analyse, nicht ihre Voraussetzung.

Was passiert, wenn die Discovery-Phase zeigt, dass ein kleinerer Eingriff schon ausreicht?

Das ist das beste Ergebnis für das Unternehmen, und genau das ist der Kern des konsultativen Ansatzes: Wir schlagen nicht das größte Projekt vor, sondern das, was sich am meisten lohnt. Wenn eine gezieltere, kleiner angelegte Entwicklung das Problem löst, schlagen wir genau das vor — statt eines größeren, unbegründeten Projekts.

Welche Risiken hat ein Modernisierungsprojekt, und wie werden sie gehandhabt?

Das größte Risiko besteht typischerweise darin, dass der laufende Betrieb während der Modernisierung ohne Unterbrechung weitergeht. Deshalb werden solche Projekte üblicherweise in Phasen aufgebaut, bei denen jeder Schritt testbar und rückgängig zu machen ist, bevor die nächste Phase startet — so sinkt das Risiko schrittweise, in überschaubaren Etappen, statt durch einen einzigen großen, unumkehrbaren Wechsel. Dieser phasenweise Ansatz ermöglicht es der Geschäftsführung außerdem, nach jeder Phase die Projektrichtung neu zu bewerten und den Plan bei Bedarf anzupassen, bevor die nächste, in der Regel größere Investitionsphase beginnt.

Warum lohnt es sich, rechtzeitig statt aus Zwang zu starten?

Es gibt einen bedeutenden Unterschied, ob ein Unternehmen aus eigenem Entschluss, gut vorbereitet ein Modernisierungsprojekt startet, oder ob es durch einen äußeren Zwang — einen schwerwiegenden Fehler, eine regulatorische Frist, einen verlorenen Kunden — dazu gezwungen wird. Im ersten Fall bleibt Zeit, die Situation gründlich zu analysieren, mehrere Lösungen abzuwägen und den kosteneffizientesten Weg zu wählen. Im zweiten Fall verengt sich die Zeit für die Entscheidungsfindung, die Auswahlmöglichkeiten schrumpfen, und es entstehen meist teurere, hastigere Lösungen.

Das ist eines der stärksten Argumente dafür, die Frage der Modernisierung nicht erst dann zu untersuchen, wenn bereits eine offensichtliche Krise besteht, sondern deutlich früher, wenn noch unter ruhigen Bedingungen eine fundierte Entscheidung getroffen werden kann.

Zusammenfassung

Wenn es in deinem Unternehmen auch ein System gibt, von dem du ahnst, dass es Zeit wäre, sich damit zu befassen, du dir aber nicht sicher bist, ob Ablösung oder Modernisierung der richtige Weg ist — lohnt es sich, mit einem Discovery-Gespräch zu beginnen, bevor ein unerwartetes Problem die Entscheidung erzwingt.

Eine gründliche Analyse verpflichtet das Unternehmen zu keiner bestimmten Richtung — sie liefert lediglich ein klares Bild davon, wo das System heute steht und welche Wege offenstehen, damit die Entscheidung am Ende auf Fakten beruht, nicht auf Vermutungen.