In einer Bestandsverwaltungssoftware wie in|sure PSLife werden neue Features und Funktionen normalerweise so konzipiert, dass sie im System optimal funktionieren. Das ist logisch, denn das Ziel besteht darin, das Produkt bestmöglich weiterzuentwickeln. Dabei geht man in der Regel davon aus, dass alle relevanten Daten zu jeder Zeit vollständig zur Verfügung stehen. Eine besondere Herausforderung stellen daher migrierte Lebensversicherungsbestände dar. Vielfältige, nicht immer vorhersehbare Gründe können dazu führen, dass es Lücken in den Bestandsdaten gibt und eben nicht wie angenommen alle Daten ständig zur Verfügung stehen. Oder es wird anhand des Ist-Zustands des Systems bewusst auf gewisse Daten verzichtet, um die migrierte Datenmenge nicht zu gross werden zu lassen. Was aber, wenn ursprünglich nicht benötigte und deshalb nicht migrierte Daten später doch gebraucht werden?
Neue Anforderungen an etablierte Funktionen
Neue Anforderungen an die Datenmenge stellen zum Beispiel Verträge, die zum Zeitpunkt der Migration einen besonderen Status haben. Im stetigen Wachsen des Systems stand in|sure PSLife in den vergangenen beiden Releases vor gleich zwei solcher Herausforderungen. Erstens durch beitragsfrei migrierte Verträge: Das System benötigt hierbei zwei Vertragsstände statt wie üblich nur einen, damit der Vertrag im Zielsystem nach der Migration voll funktionsfähig ist. Zweitens durch rückwirkende Leistungspflicht durch Berufsunfähigkeit: Hierbei ist das Problem, dass die Klärung der Leistungspflicht sich häufig über einen langen Zeitraum zieht und es dazu kommen kann, dass der Vertrag rückwirkend leistungspflichtig werden muss. Es müssen dann Änderungen vorgenommen werden, die zeitlich betrachtet noch im Altsystem liegen. In beiden Szenarien tritt ein, dass normalerweise nicht benötigte Daten plötzlich doch relevant werden.
Beitragsfreie Migration: fehlende Vertragsstände
Zum Migrationszeitpunkt beitragsfreie Verträge sind keine Seltenheit. Daher werden sie planmässig mit zwei Vertragsständen migriert statt nur mit einem: dem beitragsfreien Stand zum Migrationszeitpunkt und einem sogenannten „Schattenvertragsstand“, dem Vertragsstand unmittelbar vor der Beitragsfreistellung. Das System kann damit wie gewohnt auf die Leistungen und Beiträge vor der Migration zugreifen und so den beitragspflichtigen Vertragsstand bei Wiederinkraftsetzung im Zielsystem berechnen. Doch manchmal gibt es diesen Schattenvertragsstand nicht und es fehlen Daten dafür. Wie kommen also die Daten in die Bearbeitung?
Rückwirkende Berufsunfähigkeit: fehlende Historie
Bei der rückwirkenden Berufsunfähigkeit wurden die Verträge zwar einwandfrei und vollständig migriert. Aber Berufsunfähigkeit wird oftmals langwierig diskutiert und schliesslich vor Gericht entschieden. Ein nicht leistungspflichtig migrierter Vertrag muss nach solch einem langwierigen Entscheidungsprozess weit in der Vergangenheit rückwirkend leistungspflichtig werden. Leistungen müssen dann nachgezahlt und gegebenenfalls noch Beiträge verrechnet werden. Der Zeitpunkt dafür liegt aber zeitlich vor der Migration, mit anderen Worten im Altsystem.
Neue Bearbeitungen für neue Fälle
Sowohl für rückwirkende Leistungspflicht durch Berufsunfähigkeit als auch für Wiederinkraftsetzung beitragsfreier Verträge gibt es in PSLife bereits etablierte Bearbeitungen mit komplexen Algorithmen, die bei den Versicherungshäusern produktiv im Einsatz sind. Doch die neuen Fälle bedürfen einer anderen Herangehensweise, da Werte fehlen, mit denen die „normale“ Bearbeitung sonst automatisch rechnet. Die alte Bearbeitung wird so wie sie ist gebraucht und benutzt, daher wäre es ungünstig, diese bewährten Abläufe zu ändern. Also: Neue Bearbeitungen für neue Fälle! Für beide Varianten wurde je eine neue Bearbeitung implementiert, die im Kern das gleiche tut, wie die bestehende. Der Unterschied: Es gibt nun die Möglichkeit, Vorgabedaten manuell einzutragen, die sonst automatisch zur Berechnung herangezogen würden. Die dafür benötigten Daten können aus dem Archiv des Altsystems entnommen werden. Auf technischem Weg ist kein Zugriff möglich, da das Archiv nicht mit dem Zielsystem PSLife kommunizieren kann. Ein automatisiertes Auslesen ist folglich keine Option. Jedoch kann die Sachbearbeitung manuell die benötigten Daten einsehen und eingeben. Mit einer neuen Bearbeitung können diese Daten im Gegensatz zur alten Version direkt eingegeben werden. Anschliessend kann derselbe Algorithmus angewandt werden und den richtigen Vertragsstand berechnen.
Beide Varianten sind Beispiele dafür, dass vor der Entwicklung in der Theorie nicht immer mit allen tatsächlichen Anforderungen gerechnet werden kann. Vorgehensweisen, die für bestehende Funktionen optimal sind, müssen es nicht für neue Anforderungen sein. Die gleiche Differenz kann auftreten, wenn völlig neu konzipierte Funktionen mit Vorhandenem interagieren müssen. Dynamische Anforderungen bedürfen also dynamischen Vorgehens. Dabei gilt es stets abzuwägen: Wie kann mit geringem Aufwand gewährleistet werden, dass die optimale Balance gefunden wird, sodass sowohl neue als auch alte Features bestmöglich funktionieren? In beiden beschriebenen Szenarien wurden die bestehenden, bewährten Bearbeitungen so belassen. Stattdessen wurden neue Bearbeitungen erstellt, die die neuen Anforderungen auf eine simple Art erfüllen, ohne dem laufenden Betrieb in die Quere zu kommen oder unnötige Komplexität zu erschaffen. Für die alte und neue Variante konnte damit eine simple Lösung gefunden werden, die beiden Bereichen am besten gerecht wird.
Sie möchten mehr über unsere Software in|sure PSLife erfahren? Dann kontaktieren Sie gerne unseren Experten Oliver Schippa, Business Developer bei adesso insurance solutions.
