Computergestützte Risikoprüfung am Point-of-Sale (POS): Die technischen Voraussetzungen

Eine hinreichend komplexe Risiko­prüfung eines Antrags erfordert Expertenwissen. Vor den Zeiten der computergestützten Risikoprüfung war die Durchführung der Risikoprüfung nicht unmittelbar nach Ausfüllen der Offerte oder des Antrags möglich, da die dafür notwendige Expertise nicht an Ort und Stelle zur Verfügung stand. Erst mit der Einführung der computergestützten Risikoprüfung eröffnete sich die Möglichkeit, die Risikoprüfung unabhängig vom Risikoexperten zeit- und ortsunabhängig durchzuführen. Welche technischen Voraussetzungen für die Durchführung der Risikoprüfung bereits beim ersten Kundenkontakt erfüllt sein sollten, beschreibt dipl. Informatik-Ing. ETH Dr. Beat Hörmann.

von Dr. Beat Hörmann, dipl. Informatik-Ing. ETH, Software-Entwicklung, Geschäftsleitung Triangulum

Obgleich die naheliegende Idee, Anträge direkt vor Ort zu prüfen oder sogar direkt durch den Antragsteller (man spricht heute auch von „Self-Underwriting“ oder „B2C“) ungefähr 20 Jahre alt ist, hat sie sich bis heute nicht flächendeckend durchgesetzt. Die Gründe sind zahlreich und allgemein bekannt.

Weniger bekannt sind die harten technischen Voraussetzungen, die erfüllt sein müssen, damit das Projekt „Risikoprüfung am Point-of-Sale“ auch technisch zum Erfolg und im Nachhinein nicht zum Wartungsalbtraum für Fach- und IT wird.”

Gleiche Risikoprüfung für alle Vertriebskanäle

Um auszuschließen, dass ein Kunde einer Versicherung vielleicht nur aufgrund des von ihm gewählten Vertriebskanals angenommen wird, setzen wir voraus, dass die Datengrundlage, die der Risikoprüfung zugrunde liegt, über alle Vertriebskanäle gesehen stets dieselbe ist.

Am Rande sei dazu bemerkt, dass ein Portalanbieter, der die Versicherungsgesellschaft zum Ausfüllen eines Standardantrags zwingt, der nicht notwendigerweise dem der Gesellschaft entspricht, diesbezüglich den falschen Weg einschlägt. Entweder kann in einem solchen Fall keine seriöse Risikoprüfung durchgeführt werden oder die Gesellschaft lässt unterschiedliche Arten der Risikoprüfung für ein und denselben Tarif gelten, eigentlich ein No-Go.

Wir setzen also dieselbe Datengrundlage voraus, unabhängig davon, welche System-Plattformen bei der Antragserfassung zum Einsatz kommen und unabhängig davon, an welchem Ort und mit welchen Programmen und welchen Eingabemasken diese stattfindet.

Da die Umsysteme im Antragsprozess pro Vertriebskanal unterschiedlich sein können, sollte die Risikoprüfung nicht zusammen mit dem Antragsprozess als ein einziges technisches System betrachtet werden, obgleich es auf dem Markt Software-Anbieter gibt, die genau dies mit „ihrem“ System versprechen. Ein solches System ist jedoch enorm vielen Änderungsparametern in mehreren Dimensionen (spezifische Kundenwünsche, technologische Neuerungen, Einführung neuer Tarife, neue Vertriebskanäle, Unterstützung mehrerer Sparten gleichzeitig) ausgesetzt und die Gefahr, es einem Kunden auf Kosten eines anderen Kunden Recht zu machen, ist sehr groß. Auf die Gefahr der Abhängigkeit des Versicherers von einem einzigen Systemanbieter wird an dieser Stelle gar nicht eingegangen.

Deshalb betrachtet man die Risikoprüfung mit Vorzug als fachliche und technische Komponente im Antragsprozess.

Integration in Umsysteme

Die IT des Versicherers steht vor großen Herausforderungen, wenn die Software-Komponente nicht über die folgenden softwaretechnischen Eigenschaften verfügt, die eine reibungslose Integration und den späteren wartungsarmen Betrieb ermöglichen:

1. Die Komponente kann ohne Neukompilation des Quellcodes auf unterschiedlichen Systemplattformen betrieben werden.
2. Die Software-Architektur ist klar definiert. Es besteht mindestens eine Trennung von Darstellungslogik und Geschäftslogik. Der Versicherer kann auf Basis der Geschäftslogik innerhalb von wenigen Tagen eine GUI programmieren mit allen GUI-Technologien, die er unterstützen möchte und die je nach Vertriebskanal unterschiedlich sein können.
3. Die Schnittstelle zum Umsystem muss auf das Minimum reduziert, einfach und unzweideutig beschrieben sein. Dies geht soweit, dass die Risikoprüfung über ein- und dieselbe Schnittstelle mehrspartig betrieben werden kann.
4. Die Komponente muss über die heute gängigen Standardstecker verfügen: Darunter sind die Unterstützung der Service-Schnittstellentechnologien SOAP und RESTFull.
5. Die Komponente weist ein Minimum von Abhängigkeiten zu Fremdsystemen auf.
6. Die Komponente zeichnet sich durch Bescheidenheit in den Systemvoraussetzungen aus.

Zum Punkt 1: Dies setzt in der Praxis voraus, dass die Komponente in Java programmiert ist. Die „Common Intermediate Language“, die bei .Net-Sprachen von Microsoft zum Einsatz kommt, ist auf Nicht-Microsoft-Plattformen ungenügend unterstützt.

Zum Punkt 2: Die Trennung von Darstellungs- und Geschäftslogik ist sehr strikt zu verstehen: Jede Zeile Geschäftslogik, die sich fälschlicherweise in der Schicht der Darstellungslogik befindet, muss bei der Unterstützung einer weiteren GUI-Technologie nachprogrammiert werden, was die Fehleranfälligkeit und den späteren Wartungsaufwand erhöht.

Zum Punkt 3: Zur Spartenunabhängigkeit sei gesagt, dass dieselbe Risikoprüfungskomponente, dieselben Schnittstellen und derselbe Funktionenumfang verwendet werden können, unabhängig davon, welche Versicherungssparte gerade im Zentrum steht. Spartenunabhängig heißt nicht spartenübergreifend: Spartenübergreifende Risikoprüfung ist nicht ohne weiteres möglich, falls für jede Sparte ein anderes Risikoprüfungssystem verwendet wird. Insbesondere sind geschlossene, monolithisch aufgebaute Risikoprüfungssysteme, die zusätzlich womöglich Geschäfts- und Maskenlogik durchmischen, untauglich für den spartenübergreifenden Einsatz. Es gibt jedoch bereits praxiserprobte spartenübergreifende Lösungen: Detailfragen zu Diagnosen, Beruf, Freizeitbeschäftigungen, Auslandsaufenthalten etc. spartenübergreifend nur einmal erfasst werden. Die Risikoprüfung kann auf Knopfdruck für alle Sparten in einem einzigen Schritt erfolgen. Die Schnittstelle muss all dies hergeben und gleichzeitig die Aufnahme neuer Sparten unterstützen, ohne dass die IT des Versicherers auf eine Schnittstellenänderung im großen Stil reagieren müsste.

Zum Punkt 4: Verfügt die Komponente nicht über die genannten Stecker, müssen Anbieter und Versicherung diese zunächst bauen, was einen beträchtlichen Aufwand auf beiden Seiten zur Folge haben kann.

Zum Punkt 5: Dieser Punkt ist der guten Praxis des Software-Engineerings geschuldet: Komplexe Systeme sind aus einfacheren Komponenten aufgebaut, die lose miteinander gekoppelt sind. Wir gehen hier nicht in die Details, halten jedoch fest, dass die Beachtung dieses Punktes eine wesentliche Auswirkung auf den späteren wartungsarmen Betrieb hat und in eigenartiger Unproportionalität zur geringen Beachtung bei Entscheidern steht.

Zum Punkt 6: Die Risikoprüfung findet auch auf Laptops von Maklern statt. Deren Rechner sind oft über 10 Jahre alt.

Stellen Sie die richtige Frage

Fragen Sie den Anbieter einer Software zur computergestützten Risikoprüfung, wie viel er für die Integration verlangt. Ein Anbieter, der behauptet, sein System sei leicht integrierbar, wird der Versicherung keinen Integrationsaufwand verrechnen, weder extra noch verdeckt.”Beat Hörmann