Versicherungs-IT: Die größte Schwachstelle ist nicht technologisch

Versicherungsunternehmen kämpfen nicht primär mit schlechter Softwareentwicklung. Sie kämpfen mit einem strukturellen Problem in der Steuerung von Anforderungen, Prioritäten und Wissen -das sich mit jedem Sprint verschärft und durch klassische AI-Coding-Tools nicht lösbar ist.

‍

Zuletzt aktualisiert: Mai 2026 · Lesezeit: ca. 5 Minuten

‍

Warum Anforderungen in der Versicherungs-IT systematisch scheitern

In großen Versicherungsorganisationen sollen Fachbereiche Anforderungen formulieren, Business Cases priorisieren und Abnahmekriterien definieren. Häufig ohne methodisches Produktmanagement-Wissen und ohne technisches Verständnis der bestehenden Systemlandschaft.

Die Folgen sind in vielen Unternehmen ähnlich:

• Anforderungen sind unvollständig, widersprüchlich oder fachlich nicht relevant
• Entscheidungen basieren auf Annahmen statt auf validierten Nutzer- oder Geschäftsdaten
• Priorisierung erfolgt nach Jahresbudget oder politischem Einfluss — nicht nach Business Impact oder Risiko
• PI-Plannings eskalieren, weil Abhängigkeiten, technische Risiken und Unklarheiten zu spät sichtbar werden
• Sprint-Ziele werden regelmäßig verfehlt
• Teams implementieren häufig das Falsche, obwohl offiziell geliefert wird

Das Resultat ist systematisches Rework. Laut McKinsey geht 30–45 % aller Entwicklungsarbeit in Enterprise-Projekten auf Rework zurück, verursacht durch unklare Anforderungen. Nicht durch schlechte Entwickler. Durch fehlende Steuerung.

Das Kernproblem: so wächst die Komplexität mit jedem Sprint

Mit jedem zusätzlichen Feature steigt die strukturelle Komplexität der IT-Landschaft.

Neue Tarife, regulatorische Anpassungen und zusätzliche Schnittstellen erweitern bestehende Kernsysteme kontinuierlich. Viele Versicherer arbeiten auf historisch gewachsenen Plattformen, die teilweise seit Jahrzehnten erweitert werden.

Dadurch verschiebt sich der Fokus der IT zunehmend: weniger Innovation, mehr Wartung, mehr Abstimmung, mehr technische Schulden. Ein erheblicher Teil der Entwicklungskapazität fließt nicht mehr in neue Kundenerlebnisse, sondern in die Verwaltung bestehender Komplexität.

Dabei misst kaum eine Organisation systematisch, ob umgesetzte Features überhaupt genutzt werden oder einen wirtschaftlichen Mehrwert erzeugen. Softwareentwicklung wird damit vom strategischen Wettbewerbsvorteil zum Kostenapparat.

Warum Regulatorik Innovation verdrängt

Versicherer stehen unter permanentem regulatorischem Druck. DORA, DSGVO, IDD und Solvency II erzeugen laufend neue Anpassungen in Bestandssystemen, Prozessen und Datenflüssen. Diese Projekte sind nicht optional.

Das führt zu einer strukturellen Verschiebung: Regulatorische Projekte dominieren die Roadmap. Technische Wartung bindet zusätzliche Kapazitäten. Echte Produktinnovation wird nach hinten verschoben.

Was gebaut wird, orientiert sich dadurch häufig stärker an regulatorischem Zwang als an tatsächlichem Kundennutzen. Das Standish Group CHAOS Report zeigt: weniger als 35 % aller Enterprise-Softwareprojekte werden in Zeit, Budget und vereinbartem Umfang abgeschlossen, der häufigste Grund sind unklare Anforderungen zu Projektbeginn.

Wissensverlust in der Versicherungs-IT: das unterschätzte Regulierungsrisiko

Noch kritischer wird die Situation durch fehlende Wissenssicherung. In vielen Versicherungsunternehmen existiert entscheidendes Fachwissen ausschließlich in den Köpfen einzelner Experten. Die Folgen sind strukturell:

• Dokumentation wird als lästige Pflicht wahrgenommen und bleibt unvollständig oder veraltet
• Kritisches Wissen über Tariflogiken, Schadenprozesse und Bestandssysteme bleibt in wenigen Köpfen
• Es entstehen Kopfmonopole die Organisation wird abhängig von Mitarbeitern, die nicht ersetzbar sind
• Onboarding neuer Mitarbeiter dauert Monate, weil das System nur wenige wirklich verstehen
• Mit jeder Kündigung, jedem Rollenwechsel und jeder Verrentung wächst das operative Risiko

Wenn nur noch einzelne Mitarbeiter verstehen, wie bestimmte Kernsysteme funktionieren, verliert das Unternehmen langfristig die Kontrolle über seine eigene digitale Wertschöpfung. Unter DORA ist das kein weiches HR-Thema mehr es ist ein Regulierungsrisiko.

Die Folge: dauerhaft überlastete IT-Kapazitäten

IT-Kapazitäten sind dauerhaft überlastet, obwohl Budgets steigen. Statt echten Kundennutzen zu schaffen, verbringen Teams immer mehr Zeit mit internen Abhängigkeiten, Rework, Abstimmungen, Wartung und regulatorischen Anpassungen.

Das Resultat: sinkende Delivery-Geschwindigkeit, geringe Planungssicherheit, hohe Mitarbeiterbelastung und digitale Produkte, deren tatsächlicher Geschäftswert oft unbekannt bleibt

Warum klassische AI-Coding-Tools das Problem nicht lösen

Viele Unternehmen setzen aktuell auf AI-Coding-Tools, um ihre Entwicklungsgeschwindigkeit zu erhöhen.

Das Problem: Diese Tools optimieren die Implementierung, nicht die Qualität der Anforderungen, Prioritäten oder Entscheidungsprozesse.

Schnellerer Code löst kein Steuerungsproblem.

Wenn Anforderungen unklar sind, Prioritäten falsch gesetzt werden oder Wissen nicht dokumentiert ist, beschleunigt KI lediglich die Umsetzung struktureller Fehler.

Was Versicherer stattdessen brauchen

Mehr Budget löst ein Steuerungsproblem nicht. Mehr Entwickler auch nicht.

Was fehlt, ist Steuerbarkeit: Anforderungen, die vor dem ersten Sprint vollständig und validiert sind. Priorisierung, die auf Business Impact basiert und nicht auf Budgetzyklen. Wissen, das im System bleibt - nicht in Köpfen, die das Unternehmen verlassen können.

Das Resultat fehlender Steuerung ist immer dasselbe: sinkende Delivery-Geschwindigkeit, geringe Planungssicherheit, hohe Mitarbeiterbelastung. Und digitale Produkte, deren tatsächlicher Geschäftswert unbekannt bleibt.

NanoVerse AI setzt genau hier an: eine KI-gestützte Plattform, die Anforderungserhebung, Validierung und Wissenssicherung strukturiert, bevor entwickelt wird. Versicherungsunternehmen brauchen heute nicht einfach mehr Softwareentwicklung. Sie brauchen mehr Kontrolle über ihre eigene digitale Wertschöpfung.

Jetzt kostenlose Demo buchen

‍

FAQ: Die häufigsten Fragen

Was ist der Unterschied zwischen einem Anforderungsproblem und einem Entwicklungsproblem in der Versicherungs-IT?

‍Ein Anforderungsproblem entsteht vor der Implementierung, durch unklare, widersprüchliche oder nicht priorisierte Anforderungen aus Fachbereichen wie Aktuariat, Schaden oder Vertrieb. Studien zeigen, dass über 70% des Reworks in Enterprise-Projekten auf Anforderungsfehler zurückgehen, nicht auf Entwicklungsfehler. In der Versicherungsbranche verstärkt die Systemkomplexität diesen Effekt erheblich.

Warum lösen AI-Coding-Tools das Strukturproblem nicht?

‍AI-Coding-Tools automatisieren die Implementierung von Anforderungen, nicht deren Qualität oder Priorisierung. Ein Tool, das schneller schlechten Code schreibt, beschleunigt das Problem. Anforderungssteuerung, Priorisierung nach Business Impact und Wissensresilienz sind Governance-Probleme, keine Technologieprobleme.

Ab welcher Unternehmensgröße wird dieses Problem in der Versicherungsbranche relevant?

‍Strukturelle Anforderungs- und Wissensprobleme entstehen typischerweise ab 50–100 Personen in Softwareorganisationen. In der Branche tritt das Problem oft früher auf, weil Fachdomänen (Aktuariat, Schaden, Leben, Komposit) isoliert arbeiten und Wissen selten domänenübergreifend dokumentiert wird.

Wie misst man, ob umgesetzte Features einen Geschäftswert erzeugen?

Der Messprozess beginnt vor der Implementierung. Eine Definition of Ready (DoR) stellt sicher, dass Abnahmekriterien und erwarteter Geschäftseffekt definiert sind, bevor entwickelt wird. Value Scoring erzwingt eine klare Aussage: Wie viele Schaden-Bearbeitungen werden schneller? Um wie viel sinkt die Fehlerquote? Feature-Usage-Tracking nach Rollout beantwortet die eigentliche Frage: Nutzen Sachbearbeiter den neuen Prozess oder arbeiten sie weiter mit dem alten Workaround?

Die meisten Versicherungsunternehmen machen keines dieser drei Dinge systematisch. Ein erheblicher Teil der Entwicklungskapazität fließt so in Features ohne nachweisbaren Geschäftswert.

‍