Der zentrale Produktserver in der IT-Anwendungslandschaft für Versicherungen.

Thema: Auswahl des passenden Produktmanagementsystems

Das Versicherungsprodukt als solches ist jeweils das Hauptelement der drei Kernprozesse Angebot, Antrag und Vertrag. Versicherer sollten ihre Anwendungslandschaften daher idealerweise im Rahmen der Digitalisierung an den sich daraus ergebenden Anforderungen ausrichten. Dies geschieht am bestem durch die Einrichtung eines sogenannten Produktservers als zentrale Komponente der Anwendungslandschaft. In diesem Produktserver ist das gesamte Produktwissen einmalig abgebildet; sämtliche relevanten Systeme können mittels Services darauf zugreifen. Im Idealfall können mit diesem Ansatz Produktanpassungen ohne Änderungen in der Anwendungssoftware umgesetzt werden.

Unter den heutigen Marktbedingungen ist es für Versicherungsunternehmen wichtiger denn je, ihre Produkte schnell und flexibel ändern zu können, um Markt- und Kostenvorteile gegenüber dem Wettbewerb zu realisieren. Dies gilt sowohl für die Vertragsverwaltung als auch für die Vertriebskanäle, die sehr heterogen sein können. Entsprechend divers kann sich auch die Anwendungslandschaft darstellen, so dass unter Umständen IT-technische Restriktionen die fachliche Produktgestaltung behindern und mehrfache Abbildung und Tests ein und desselben Produkts erforderlich sind.

Die Umstellung der Architektur auf einen zentralen Prodktserver erfolgt entweder durch die Einführung eines neuen Standard-Bestandsführungssystems mit integriertem Produktmanagementsystem oder durch die Integration des Letzteren in die bestehende Systemlandschaft als Einzelkomponente. Dies ist in der Regel abhängig von der Gesamt-IT-Strategie des jeweiligen Hauses.

In jedem Fall ist die Einführung einer produktorientierten Architektur aufwändig und erfordert eine langfristige strategische Entscheidung. Entsprechend fundiert und nachvollziehbar sollte man bei der Auswahl eines der am Markt erhältlichen Produktmanagementsysteme vorgehen. Schließlich muss dieses die Anforderungen an den Produktserver möglichst umfassend erfüllen können. Dies gilt in gleicher Weise für die (in der Praxis eher unüblichere) Entwicklung einer Produktkomponente in Eigenregie.

Entscheidet sich ein Versicherer dafür, eine neue Standardsoftware für die Bestandsverwaltung einzuführen, sollte das Thema „Abbildung Produktwissen“ daher einen hohen Stellenwert innerhalb des Auswahlverfahrens erhalten. Denn ist das System erst einmal eingeführt, hängt der weitere Erfolg stark von dem integrierten Produktmanagementsystem ab. Ein weniger geeignetes System kann z.B. bei der Bereitstellung der Produktinformationen in den Vertriebskanälen langfristig zu hohen unnötigen Aufwänden führen und die Time-to-Market von Produkt-Neuentwicklungen verlängern.

Grundsätzlich ist darauf zu achten, dass das Produktmanagementsystem allen Herausforderungen gewachsen ist, die im sparten- und systemübergreifenden Einsatz auftreten können. Die sich daraus ergebenden Anforderungen sind umfangreich und anspruchsvoll, jedoch keineswegs unerfüllbar.  Dies wird von – zugegeben z.Zt. nur wenigen – produktiven Installationen bewiesen, in denen die facharchitekturelle Vorgabe des Geschäftsobjektes Produkt konsequent zu Ende gedacht und umgesetzt wurde.

Ein optimales Referenzszenario lässt sich wie folgt skizzieren:

• Die Produktmodelle (Laufzeitmodule) können alle Berechnungen durchführen, die für die Geschäftsvorfälle von Neu- und Änderungsgeschäft in der Vertragsverwaltung notwendig sind. Dies betrifft auch die Tarifkalkulation und Plausibilisierung in den Vertriebssystemen verbunden mit der Generierung einer ersten Version des Vertragsdatensatzes im Rahmen des Datenmodells des Bestandführungssystems.
• Entsprechend wird eine elektronische Antragsüberleitung und –verarbeitung aus den Vertriebssystemen heraus und damit die ‚dunkle‘ Vertragsanlage der erzeugten Anträge und gegebenenfalls die Aussteuerung zur Sachbearbeitung mit Anstoß von Terminen im Bestandsführungssystem auf Grundlage der Services aus den Produktmodellen durchgeführt.
• Das Neueinrichten und Verwalten von Tarifversionen und Generationen über lange Zeiträume ist ohne Probleme möglich.
• Die so entstandenen Vertragsgrundmodelle (Kermodelle) mit ihrer Rechenlogik eignen sich auch für die Verwendung bei allen weiteren Einsatzszenarien innerhalb der Anwendungslandschaft, insbesondere für Angebots-/Antragsprozesse. Zu diesem Zweck sind sie um die individuellen Anforderungen der einzelnen Vertriebskanäle (Vertriebssystem des fest angestellten Außendienstes, Maklerplattformen, Internettarifrechner für Endkunden etc.) erweiterbar, beispielsweise um eine Vielzahl neuer oder abgeänderter Plausibilitäten, reduzierte bzw. vereinfachte Eingabe der Tarifierungsdaten, Oberflächensteuerung sowie bei Bedarf auch Beeinflussung des Workflows aus produkttechnischer Sicht.
• Produktvarianten, beispielsweise in Form einer eingeschränkten Auswahl von Sparten und Produktbausteinen innerhalb eines großen Bündelproduktes in der Kompositversicherung, lassen sich schnell erstellen und produktiv einsetzen.
• Für einen solchen umfassenden Einsatz muss die Architektur der Produktmodelle so gestaltbar sein, dass die Komplexität über mehrere Vertriebskanäle und lange Zeiträume hinweg beherrschbar bleibt.

Häufig ist es außerdem gewünscht, dass die Produktmodellierung fachbereichsnah erfolgt, um den Aufwand bei der Erstellung fachlicher Vorgaben für die IT-Umsetzung zu minimieren. Daraus entsteht der Anspruch, dass die Produktmodellierung relativ einfach auch für solche Mitarbeiter erlernbar sein muss, die nicht über tiefgreifende Programmierungserfahrung verfügen.

Die sich daraus ergebenden Anforderungen sind vielschichtig und haben fachliche, technische und organisatorische Aspekte. Aus ihnen lässt sich eine Vielzahl von quantitativen und qualitativen Bewertungskriterien für ein Auswahlverfahren ableiten, die sich in folgende Themenblöcke gliedern:

• Anbietercharakteristik
• Fachliche Anforderungen: Produkte, Sparten, Varianten
• Fachliche Anforderungen: Produktmodellierung
• Technische Anforderungen: Buildtime
• Technische Anforderungen: Runtime
• Technische Anforderungen: Schnittstellen und Anbindungen
• Entwicklung und Roll Out
• Organisation

Die Bewertungskriterien können den individuellen Voraussetzungen und Zielen des jeweiligen geplanten Einsatzgebietes angepasst werden. Die so entstandene Kriteriensammlung dient als Grundlage für die Detailanalyse in der zweiten Phase der Evaluierung.

Diese beginnt in der Regel mit einer umfassenden Marktuntersuchung mit dem Ziel, einen vollständigen Überblick über mögliche Anbieter bzw. Systeme zu erhalten. Das Ergebnis dieser ersten Phase ist eine „Long List“, die durch ein erstes Auswahlverfahren anhand von K.O.-Kriterien zu einer „Short List“ reduziert wird. Beispiele für K.O.-Kriterien sind mangelnde Referenzen im deutschen Raum, Ausrichtung auf bestimmte, nicht relevante Versicherungssparten oder technische Restriktionen.

Die Kriteriensammlung kann der Versicherer dann als Fragenkatalog an die verbliebenen Anbieter zur schriftlichen Beantwortung versenden. Es hat sich außerdem in der Praxis bewährt, jeweils Workshops durchzuführen, um den Herstellern so die Gelegenheit zu geben, ihre Software einem internen Expertenkreis vorzustellen und Fragen zu diskutieren. Im Rahmen der Workshops kann der Anbieter Lösungen zu einem Showcase präsentieren, der zuvor in der „Short List“ als „Hausaufgabe“ gestellt wurde.

Die Ergebnisse der Evaluierung sind dann im Rahmen einer Nutzwertanalyse darstellbar und dienen der systematischen Bewertung der in Frage kommenden Produktmanagementsysteme.