Ihr ERP-, Core- oder SaaS-Modernisierungsprogramm läuft bereits. Budget ist gebunden, ein Implementierungspartner arbeitet, Migrationen sind geplant. Gleichzeitig verändert agentische AI die Architektur- und Kostenannahmen, auf denen die Entscheidung vor ein oder zwei Jahren beruhte.

Sollten Sie das Programm jetzt stoppen? In den meisten Fällen ist „AI ist neu“ dafür kein ausreichender Grund. Die bessere Frage lautet: Ist das Zielbild noch richtig, aber der verbleibende Scope falsch priorisiert? Dann ist ein Re-Scope oft sinnvoller als ein pauschaler Stopp. Wenn dagegen die Zielarchitektur selbst nicht mehr tragfähig ist oder eine schwer reversible Abhängigkeit entsteht, muss auch ein Stop oder grundlegender Pivot prüfbar bleiben.

Management-Zusammenfassung

McKinsey diskutiert am 2. Oktober 2026 für Versicherungs-Kernsysteme ausdrücklich die Entscheidung „pause, pivot or accelerate“. Die Gesprächspartner argumentieren, dass moderne, offene Kerne weiterhin wichtig bleiben, AI aber Migrationsarbeit, Preismodelle und die Priorität von API-, Daten- und Orchestrierungsfähigkeiten verändert.[^1] BCG beschreibt am selben Tag breiter, dass AI die Economics von Legacy-Migration, ERP-Transformation und Tech Sourcing verändert und neue Kosten ebenso wie Produktivität erzeugt.[^2] Für den CIO folgt daraus kein genereller „AI-Neustart“. Entscheiden Sie entlang von drei Gates: Zielarchitektur, verbleibende Economics und Reversibilität.

Gate 1: Ist die Zielarchitektur noch richtig?

Beginnen Sie nicht mit dem bereits ausgegebenen Geld. Beginnen Sie mit dem Zielbild.

McKinseys Diskussion ist auf Versicherungen fokussiert, benennt aber eine übertragbare Architekturfrage: Ein modernes Core-System bleibt als verlässliches System of Record wichtig; zugleich gewinnen offene APIs, zugängliche Daten und die Fähigkeit an Bedeutung, zusätzliche AI-/Agentenfunktionen oberhalb des Kerns anzubinden.[^1]

Für ein laufendes Programm heißt das: Ein neues AI-Tool allein ist kein Grund, die Kernmodernisierung zu verwerfen. Prüfen Sie vielmehr, ob die Zielarchitektur offen genug für neue Interaktions- und Automatisierungsschichten ist.

Warnsignale sind beispielsweise:

  • wesentliche Daten bleiben für neue Anwendungen schwer zugänglich,
  • notwendige APIs oder Integrationspunkte fehlen im Zielbild,
  • wichtige Erweiterungen erzeugen irreversible proprietäre Abhängigkeiten,
  • der zukünftige Betrieb erfordert Customizing, das spätere Änderungen unverhältnismäßig erschwert.

Wenn die Architektur grundsätzlich stimmt, spricht das eher für Weiterführen oder Re-Scope als für einen Stopp.

Gate 2: Hat AI die Economics des verbleibenden Scopes verändert?

BCG nennt Legacy-Migration und ERP-Transformation ausdrücklich als Bereiche, in denen AI die Produktivität interner Technologiearbeit erhöhen kann.[^2] McKinseys Gesprächspartner nennen unter anderem Mapping, Testgenerierung und Konfiguration als Tätigkeiten, deren Aufwand sich verändern kann.[^1]

Das ist kein belastbarer pauschaler Einsparprozentsatz. Aber es ist ein Grund, den noch nicht erbrachten Scope neu zu kalkulieren.

Die entscheidende Frage lautet nicht: „Wie viel haben wir schon investiert?“

Sondern: „Welche noch offenen Leistungen würden wir heute – mit dem aktuellen technologischen Stand – genauso beauftragen, spezifizieren und bepreisen?“

Prüfen Sie dafür insbesondere:

  • verbleibende Migrations- und Testpakete,
  • manuelle Mapping- und Dokumentationsleistungen,
  • geplante Oberflächen- und Customizing-Arbeiten,
  • Datenmodell, API-Abdeckung und Integrationsscope,
  • laufende AI-/Cloud-/Orchestrierungskosten nach Go-live,
  • Governance- und Betriebsaufwand.

Ein Re-Scope kann bedeuten, weniger Budget in kurzlebige Oberflächenparität und mehr in Datenzugang, API-Abdeckung, Testbarkeit und reversible Integrationen zu stecken. Diese Priorisierung ist eine Managementableitung aus den Quellen, kein allgemeiner Marktstandard.

Gate 3: Wie reversibel ist die nächste Entscheidung?

Der dritte Punkt wird in Transformationen häufig unterschätzt. Ein laufendes Programm kann technisch funktionieren und wirtschaftlich vertretbar sein, aber trotzdem eine schlechte nächste Entscheidung enthalten, wenn sie kaum rückgängig zu machen ist.

Prüfen Sie vor dem nächsten großen Commitment:

  • Können Anbieter oder Komponenten später gewechselt werden?
  • Sind Daten, Schnittstellen und Dokumentation tatsächlich unter Ihrer Kontrolle?
  • Ist der nächste Meilenstein modular abnehmbar?
  • Entsteht eine Abhängigkeit, die erst Jahre später sichtbar wird?
  • Sind Exit-, Übergabe- und Änderungsrechte vertraglich ausreichend klar?

Je geringer die Reversibilität, desto höher sollte die Begründungsschwelle sein.

Das CIO-Entscheidungsraster

| Situation | Zielarchitektur | Economics des Restscopes | Reversibilität | Entscheidungstendenz | |---|---|---|---|---| | A | weiterhin tragfähig | Restscope weiterhin plausibel | ausreichend offen | weiterführen | | B | tragfähig | AI verändert Aufwand oder Prioritäten deutlich | Anpassung möglich | neu zuschneiden | | C | teilweise tragfähig | Business Case nur nach Scope-Änderung sinnvoll | mittlere Bindung | Re-Scope + neuen Gate-Termin setzen | | D | Zielarchitektur nicht mehr tragfähig | Restinvestition schafft wenig zusätzlichen Wert | hohe Lock-in-Gefahr | Stop/Pivot ernsthaft prüfen |

Das Raster ist bewusst keine automatische Entscheidung. Es zwingt nur dazu, drei unterschiedliche Fragen nicht zu vermischen.

Wann ist „weiter wie geplant“ tatsächlich vernünftig?

Weiterführen ist kein Zeichen mangelnder AI-Ambition. Es kann die beste Entscheidung sein, wenn die Modernisierung weiterhin die notwendige Daten- und Integrationsgrundlage schafft, der verbleibende Scope wirtschaftlich plausibel ist und die Architektur spätere AI-Komponenten nicht blockiert.

Ein häufiger Fehler wäre, ein funktionierendes Fundament zu destabilisieren, nur weil neue AI-Funktionen versprechen, einzelne Arbeitsschritte schneller zu machen.

Besonders bei regulierten oder geschäftskritischen Systemen bleibt die Trennung zwischen stabilem System of Record und schnelleren Innovationsschichten wichtig. McKinseys Beitrag formuliert diesen Punkt ausdrücklich für Versicherungen; die konkrete Ausgestaltung muss in anderen Branchen separat geprüft werden.[^1]

Wann ist ein Re-Scope besser als ein Neustart?

Re-Scope ist sinnvoll, wenn das Zielbild bestehen bleibt, aber der Weg dorthin angepasst werden sollte.

Typische Entscheidungen können sein:

  • verbleibende Test- oder Migrationspakete neu kalkulieren,
  • API- und Datenabdeckung höher priorisieren,
  • Customizing reduzieren,
  • AI-unterstützte Delivery als neue Liefermethode mit dem Implementierungspartner verhandeln,
  • spätere Verbrauchs- und Governancekosten explizit in den Business Case aufnehmen,
  • Meilensteine so schneiden, dass neue Technologieentscheidungen später möglich bleiben.

Wichtig: Produktivitätsgewinne des Suppliers werden nicht automatisch zu Ihren Einsparungen. Wenn ein Dienstleister schneller liefert, muss geklärt werden, ob und wie sich dies in Preis, Scope, Qualität oder zusätzlichem Output niederschlägt.

Wann muss Stop oder Pivot eine reale Option sein?

Ein Stop ist teuer. Übergaben, Vertragsfolgen, bereits aufgebaute Teams und verzögerter Nutzen können erhebliche Konsequenzen haben. Deshalb darf „AI verändert alles“ keine Abkürzung zu einem Projektabbruch sein.

Stop oder grundlegender Pivot gehören aber auf den Tisch, wenn mindestens einer dieser Punkte strukturell ist:

  • Das Zielsystem kann die künftig benötigten Daten-/API-Anforderungen nicht sinnvoll unterstützen.
  • Der Business Case fällt auch nach realistischer Neuplanung des Restscopes auseinander.
  • Ein weiterer Meilenstein erzeugt eine schwer reversible Abhängigkeit ohne ausreichenden strategischen Gegenwert.
  • Die ursprüngliche Problemdefinition ist nicht mehr gültig.

In diesen Fällen wäre „wir haben bereits viel investiert“ kein ausreichendes Gegenargument. Bereits ausgegebene Mittel sollten nicht die Qualität der nächsten Investitionsentscheidung bestimmen.

Welche Zahlen gehören in den nächsten Lenkungskreis?

Für den nächsten Gate-Termin sollte die Entscheidungsunterlage mindestens vier Sichtweisen nebeneinander zeigen:

Restbudget: Was ist bereits ausgegeben, vertraglich gebunden und noch frei entscheidbar?

Restscope: Welche Leistungen und Deliverables sind tatsächlich noch offen?

Zielbeitrag: Welche dieser Leistungen bleiben für das künftige Betriebs- und Architekturmodell notwendig?

Änderungskosten: Was kostet Re-Scope, Stop oder Übergang – finanziell, zeitlich und operativ?

Erst diese vier Größen machen „weiter“, „ändern“ und „stoppen“ vergleichbar.

Was bedeutet das für die Supplier-Steuerung?

AI kann die Delivery Economics des Implementierungspartners verändern. Das macht den laufenden Vertrag nicht automatisch falsch. Aber es schafft einen sachlichen Anlass, noch offene Leistungsbausteine neu zu prüfen.

Die Verhandlung sollte nicht bei „AI spart Ihnen Stunden, also senken Sie den Preis“ beginnen. Besser ist:

  • Welche Arbeitsschritte verändern sich konkret?
  • Welche neue Tool- oder Governancekosten entstehen?
  • Welche Qualitäts- und Abnahmekriterien bleiben gleich?
  • Welche Leistung kann schneller, günstiger oder mit höherem Scope geliefert werden?
  • Welche Annahmen aus dem ursprünglichen Angebot gelten nicht mehr?

So bleibt der Fokus auf dem zukünftigen Leistungswert statt auf pauschalen AI-Rabatten.

Fazit: Nicht die Vergangenheit entscheiden lassen, sondern den Rest des Programms

Ein laufendes Modernisierungsprogramm sollte wegen agentischer AI weder reflexartig gestoppt noch unverändert fortgeschrieben werden.

Die bessere CIO-Entscheidung prüft drei Dinge separat: Ist die Zielarchitektur weiterhin richtig? Sind die Economics des noch offenen Scopes aktualisiert? Bleibt die nächste Investition ausreichend reversibel?

Wenn alle drei Antworten tragfähig sind, ist Weiterführen rational. Wenn das Ziel stimmt, aber der Weg nicht mehr, ist Re-Scope meist die präzisere Entscheidung. Wenn Zielarchitektur oder Business Case strukturell nicht mehr tragen, muss auch Stop oder Pivot möglich sein.

Diese Verbindung aus Projektstatus, Restbudget, Supplier-Leistung, Architekturannahmen und Entscheidung ist eine typische Project-Intelligence-Frage.

Nächster Schritt: Legen Sie für das nächste Steering Committee nicht nur einen Statusbericht vor, sondern eine Entscheidungsvorlage mit Restbudget, Restscope, Zielbeitrag und Änderungskosten. Wenn Sie diese Informationen projekt- und supplierübergreifend auf einer gemeinsamen Ebene steuern wollen, können Sie die Anforderungen in einer Ramp7-Demo besprechen.