Application-Portfolio-Management: KI verändert Make-or-Buy

Viele Banken und Versicherungen folgen einer bewährten Logik: Kernsysteme sichern das transaktionale Kerngeschäft, während für weitere Funktionen eine beachtliche Menge an Standardsoftware oder SaaS-Lösungen (Umsysteme) zum Einsatz kommen. Das schafft Komplexität und treibt den Aufwand für Betrieb und Wartung an. Gleichzeitig erhöhen Fachkräftemangel, regulatorische Anforderungen und die Abhängigkeit von Software- und Cloud-Anbietern den Druck, Make-or-Buy-Entscheidungen differenzierter zu treffen. 

Generative KI kann Entwicklung, Testing, Dokumentation und die Erstellung von Software beschleunigen. Daraus folgt jedoch nicht, dass Eigenentwicklung automatisch günstiger wird. Entscheidend sind die Gesamtkosten über den gesamten Lebenszyklus: von Architektur, Integration und Testing über Security und regulatorische Nachweise bis zu Betrieb, Weiterentwicklung und kontrolliertem Rückbau der Applikation. Daraus ergeben sich folgende drei Hypothesen: 

Hypothese 1: Die Grenzkosten der Individualisierung sinken 
KI macht es einfacher, klar abgrenzbare fachliche Anforderungen umzusetzen. Damit können Funktionen wirtschaftlich interessant werden, die bisher wegen Entwicklungsaufwand oder Time-to-Market kaum für eine individuelle Umsetzung infrage kamen. Besonders attraktiv ist dies bei Funktionen mit hohem Differenzierungswert, kontrollierbaren Schnittstellen und überschaubarem Betriebsrisiko – etwa bei spezifischen Kredit- oder Leistungsprozessen, digitalen Kundenservices oder der intelligenten Orchestrierung bestehender Anwendungen. 

Die schnellere Entwicklungsgeschwindigkeit erhöht zugleich die Anforderungen an Steuerung und Qualität. Security, Architektur, Testing, Compliance, Betrieb und Weiterentwicklung verschwinden mit KI nicht. Institute benötigen klare Leitplanken für KI-generierten Code, eingesetzte Modelle, Datenzugriffe, Freigaben, Vulnerability Management und die langfristige Wartbarkeit. 

Hypothese 2: Auch «Buy» wird intelligenter 
Gleichzeitig integrieren Anbieter von Standardsoftware KI zunehmend direkt in ihre Produkte und Entwicklungsplattformen. Dadurch werden Standardlösungen flexibler und stärker individualisierbar. Wo Prozesse kaum Differenzierungspotenzial bieten, bleibt «Buy» deshalb attraktiv. Entscheidend ist, ob eine Lösung ihre Aufgabe wirtschaftlich, sicher und zuverlässig erfüllt und zugleich genügend Transparenz, Portabilität und Exit-Fähigkeit bietet. Die Grenze zwischen Make und Buy wird dadurch weniger scharf, die Qualität und die breite Abstützung von Sourcing-Entscheidungen dafür umso wichtiger. 

Hypothese 3: Aus Make-or-Buy wird Make, Buy und Compose 
Der grösste Handlungsspielraum entsteht dort, wo Banken und Versicherungen ihre Architektur so gestalten, dass sie Standardkomponenten und individuelle Services flexibel kombinieren können. Stabile Kernsysteme bleiben das Fundament für Transaktionen, Policen, Vertragsverwaltung und einen robusten Betrieb. Über APIs, Integrationsschichten und Orchestrierung lassen sich neue Services anbinden, gezielt selbst entwickeln oder bei Bedarf effizient austauschen. 

Gleichzeitig braucht es klare Verantwortlichkeiten für Komponenten, Daten, Schnittstellen und Modelle sowie eine durchgängige Governance vom Design bis zum Betrieb. Wie Inventx die Zukunft der IT-Architektur von Banken und Versicherungen sieht, ist im gleichnamigen Booklet nachzulesen. 

Was bedeutet das für die IT-Roadmap? 
Für CIOs und IT-Verantwortliche in Banken und Versicherungen rücken fünf Entscheidungen in den Vordergrund: 

1. Aktives Portfolio-Management? 
   Bewusstes Steuern und Konsolidieren der Applikationslandschaft, um Redundanzen zu reduzieren, Komplexität zu senken und die Kosten nachhaltig zu optimieren. 
2. Was standardisieren wir konsequent? 
   Funktionen ohne strategischen Differenzierungswert gehören möglichst in standardisierte Plattformen oder SaaS-Lösungen. 
3. Welche Fähigkeiten wollen wir selbst kontrollieren? 
   Eigenentwicklung ist dort sinnvoll, wo sie Kundennutzen, Geschwindigkeit oder strategische Differenzierung schafft – intern oder gemeinsam mit spezialisierten Partnern (Community-Effekte). 
4. Sind Architektur und Governance bereit? 
   Schnittstellen, Datenzugriffe, Security, Qualitätskontrollen, Betriebsmodelle und Verantwortlichkeiten müssen mit der höheren Entwicklungsgeschwindigkeit Schritt halten. 
5. Wie messen wir den wirtschaftlichen Nutzen? 
   Entscheidungen sollten auf Lebenszykluskosten, Time-to-Market, Risikoprofil und Exit-Fähigkeit basieren – nicht allein auf den Entwicklungskosten. 

KI beendet Make-or-Buy nicht, sie verändert die Entscheidungslogik. Erfolgreich werden jene Institute sein, die Standardisierung, gezielte Individualisierung und modulare Architektur zu einem beherrschbaren Betriebsmodell verbinden.