In der Versicherung beginnt alles mit der Police. Sie hält fest, was gedeckt ist, zu welchen Bedingungen, zu welchem Preis und bis wann - und jeder nachgelagerte Prozess, von den Schäden bis zur Abrechnung, greift auf das zurück, was das Policensystem darüber weiß. Deshalb ist die Bestandsverwaltung kein Modul neben dem Geschäft, sondern dessen Fundament, und die Qualität dieses Systems wirkt unmittelbar darauf, wie schnell Sie ein neues Produkt starten und was der Betrieb Ihres Bestands kostet.
Aus unserer Erfahrung liegt das Schwierige an einem solchen Projekt nicht darin, die erste Police auszustellen, sondern darin, ein System zu entwerfen, das Dutzende Produkte, Jahre von Tarifänderungen und Versionen von Bedingungen trägt, ohne jedes Mal neu geschrieben zu werden. Wir haben hier kein Vorzeigeprojekt, das wir als Referenz zeigen könnten, also sagen wir es offen: Das ist eine Kompetenz von uns. Wir bauen Individualsoftware und arbeiten auf Plattformen wie Salesforce und Creatio, und für ein Versicherungsprojekt stellen wir die Menschen, die dieses System gemeinsam mit Ihrem Team entwerfen und schreiben.
Warum ist die Bestandsverwaltung der Kern eines Versicherungssystems?
Weil nur dort der vollständige, aktuelle Stand des Versicherungsschutzes tatsächlich lebt. Ist das Policensystem starr, bedeutet jedes neue Produkt Monate an Programmierung, und jede Tarifänderung läuft über die IT statt über das Produktteam. Die Time to Market wächst, und die Kosten für den Betrieb des Bestands summieren sich Jahr für Jahr.
Ein gut gebautes Bestandsverwaltungssystem dreht das um. Produkte werden konfiguriert statt programmiert, eine Änderung der Bedingungen zerstört keine bestehenden Verträge, und der Rest der Organisation erhält eine einzige, verlässliche Quelle der Wahrheit darüber, was der Kunde tatsächlich gekauft hat. Es ist das Fundament, auf dem Schäden, Kundenservice, Abrechnung und das aufsichtsrechtliche Reporting aufsetzen.
Was ist eine Policy Engine und wie entwerfen wir das Datenmodell?
Die Policy Engine ist das Herz des Systems: der Teil, der versteht, was eine Police ist, und sie über ihre gesamte Laufzeit konsistent hält. Wir entwerfen sie um drei Säulen herum:
- das Policendatenmodell - versicherte Person, versichertes Objekt, Risiken, Summen, Prämie, Zeiträume und die Verknüpfungen zwischen den Positionen,
- Produktregeln - was gedeckt werden darf, welche Abhängigkeiten und Validierungen gelten, wann eine Variante zulässig ist,
- Versionierung - jede Änderung von Bedingungen und Tarifen zeitlich erfasst, damit eine vor zwei Jahren ausgestellte Police weiterhin nach den damals gültigen Regeln tarifiert wird.
Diese Versionierung ist entscheidend und wird am häufigsten unterschätzt. Ohne sie können Sie nicht zugleich das Produkt weiterentwickeln und Verträge nach älteren Bedingungen ehrlich bedienen. Deshalb behandeln wir Zeit vom ersten Tag an als Dimension des Datenmodells, statt sie später anzuflanschen.
Wie funktioniert der Produkt- und Tarifkonfigurator?
Das Ziel ist einfach, aber anspruchsvoll: ein neues Produkt oder eine Tarifänderung ohne Codeänderung. Wir bauen einen Konfigurator, in dem das Produktteam Deckungsbausteine, Varianten, Abhängigkeiten und Tariftabellen definiert und das System daraus ein funktionierendes Angebot zusammensetzt. Ein Entwickler wird gebraucht, um die Engine zu erweitern, nicht um jeden Satz anzupassen.
In der Praxis heißt das, Produktlogik von der Anwendungsmechanik zu trennen. Parameter, Schwellenwerte und Faktoren leben in Konfiguration und Tabellen statt in Bedingungen, die über den Code verstreut sind. Dadurch wird die Aktualisierung einer Preisliste oder der Start einer Saisonvariante zu einer Geschäftsaufgabe, die in Tagen ausgeliefert wird, nicht in Quartalen.
Wie modellieren wir den Policenlebenszyklus von der Ausstellung bis zum Ablauf?
Eine Police ist keine Momentaufnahme, sondern eine Historie. Das Policensystem muss den gesamten Weg abbilden, dazu gehören:
- Ausstellung - vom Antrag über die Risikoprüfung bis zur Erzeugung des Dokuments und zur Aktivierung des Schutzes,
- Nachträge - unterjährige Änderungen, mit neu berechneter Prämie und vollständig erhaltener Historie,
- Erneuerungen - automatisch oder durch den Vermittler begleitet, mit Datenübernahme und Anwendung des aktuellen Tarifs,
- Ablauf, Kündigung und Stornierungen - mit korrekter Abrechnung des Zeitraums und etwaiger Rückerstattungen.
Jedes dieser Ereignisse verändert den Zustand der Police und muss eine Spur hinterlassen, die sich rekonstruieren lässt. Wir entwerfen diesen Lebenszyklus als Folge von Versionen eines einzigen Objekts, nicht als separate kleine Tabellen, die bei jedem neuen Bedarf angeklebt werden - denn genau hier türmt sich technische Schuld am schnellsten auf.
Wie bauen Sie eine Prämienberechnung als API?
Wir lösen die Prämienberechnung als eigenen Service mit eigener API heraus, statt sie in die Verkaufsmaske zu verdrahten. Diese Architekturentscheidung zahlt sich vielfach aus: Dieselbe Logik rufen der Rechner auf der Website, die Vermittler-App, der Erneuerungsprozess und eine Partnerintegration auf, und das Ergebnis ist immer identisch.
Die Engine nimmt Risikodaten entgegen, greift auf die passende Tarifversion zu und liefert eine Prämie samt Aufschlüsselung zurück, die Sie dem Kunden zeigen und später prüfen können. Die Trennung von Berechnung und Oberfläche erlaubt es, Preisregeln isoliert zu testen und Tarife auszutauschen, ohne den Rest des Systems anzufassen - unbezahlbar bei jeder Kampagne und jeder regulatorischen Änderung.
Wie gehen wir mit Dokumentenerzeugung und Archivierung um?
Eine Police ist auch ein Dokument, das der Kunde erhält und das eine Aufsichtsbehörde prüfen kann. Wir bauen eine Schicht, die Dokumente aus konsistenten Vorlagen erzeugt (die Police, eine Bescheinigung, einen Nachtrag, eine Zahlungsaufforderung) und jedes davon an eine konkrete Policenversion bindet, sodass Sie jederzeit rekonstruieren können, was der Kunde wann erhalten hat. Dokumente gehen in ein Archiv mit Zugriffskontrolle und regulatorisch getriebenen Aufbewahrungsfristen, und der gesamte Ablauf wird für die Revision protokolliert.
Wie integrieren wir das Policensystem mit Kernsystem, CRM und dem Ökosystem?
Ein Bestandsverwaltungssystem lebt nicht im luftleeren Raum. Wir verbinden es mit der übrigen IT-Landschaft, denn die Police speist fast jeden anderen Prozess mit Daten:
- Kernsystem und Finanzen - Prämienbuchung, Abrechnung, Reserven,
- das CRM (z. B. Salesforce, Creatio) - Kundensicht, Vertrieb und Service,
- Schäden - die auf Umfang und Bedingungen der Police zurückgreifen,
- Kanäle und Partner - Portale, Vermittler-Apps, Vergleichsportale, API-Integrationen.
Wir entwerfen diese Verbindungen entlang klarer API- und Event-Verträge, damit eine Änderung in einem System die anderen nicht umwirft. Wenn eine CRM-Plattform das Herz der Kundenbetreuung ist, verankern wir die Vertriebs- und Serviceprozesse dort und lassen die Policenlogik, wo sie hingehört: in der Policy Engine.
Welche Kompetenzen stellen wir für ein Bestandsverwaltungsprojekt?
Das ist der Kern: Auch ohne abgeschlossenes Projekt in diesem Feld stellen wir die Menschen, die das System bauen. Wir schneiden das Team auf den konkreten Umfang zu, nicht „für alle Fälle”:
- einen Solution Architect, der Produktmodellierung und Versionierung versteht,
- Backend-Entwickler, die Policy Engine, Berechnung und APIs bauen,
- Plattformspezialisten (Salesforce, Creatio), wenn der Service auf einem CRM läuft,
- Integrationsingenieure und QA, die das System an das Kernsystem anbinden und die Preisregeln korrekt halten.
Wir stützen uns dabei auf echte Erfahrung aus Individualsoftware- und Plattformprojekten, und wir prüfen die Kompetenzen vor dem Start. Als Nearshore-Partner aus Polen steigen wir in Ihren Rhythmus aus Code Reviews und Meetings ein, ohne lange Anlaufzeit.
Wie machen wir das bei RITS?
Meistens führen wir das als Individualsoftware-Projekt unter Leitung unseres Teams, und wo Kompetenzen schnell aufgefüllt werden müssen, als Team-Verstärkung oder dediziertes Team. Wir beginnen beim Datenmodell und der Versionierung, lösen die Berechnung als API heraus und geben das Produkt über einen Konfigurator an das Business. Wichtig: Wir versprechen keine erfundenen Projekte. Wir bringen Kompetenz in Individualsoftware und Plattformen ein, und die Belege wachsen gemeinsam mit dem Projekt. Die Unterschiede zwischen den Kooperationsmodellen haben wir in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Wo beginnen Sie den Aufbau einer Bestandsverwaltung?
Beginnen Sie mit einem Produkt und seinem vollständigen Lebenszyklus, vom Antrag bis zur Erneuerung, statt den ganzen Bestand auf einmal nachbauen zu wollen. Das erzwingt das richtige Datenmodell, zeigt, wo Sie wirklich einen Konfigurator brauchen, und gibt dem Team ein funktionierendes Skelett, an das weitere Produkte andocken. Klären Sie außerdem sofort zwei Dinge: dass Tarife in Tabellen leben und dass die Prämienberechnung eine eigene API ist.
Sie bauen oder erneuern eine Bestandsverwaltung? Sprechen wir darüber - wir stellen Team und Architektur passend zu Ihrem Produktportfolio zusammen.