Es ist noch gar nicht so lange her, dass Versicherungen und ihre Außendienste beim Vertrieb von Biometrie-Produkten mit reichlich Papier hantierten. Das hat sich in den vergangenen zwei Jahren zwar gebessert, aber das einigermaßen verbreitete elektronische Formularwesen für Arztberichte und der Umgang mit Gesundheitsdaten zwischen Vertrieb und Risikoprüfung muten angesichts der rasanten Entwicklung in der IT meist doch noch etwas hemdsärmelig an.

Da werden Daten manuell auf vorgegebenen Masken erfasst und an die Versicherung zur Prüfung weitergeleitet. Es folgen Rückfragen, der Bericht des Arztes lässt auf sich warten und widerspricht in Teilen den Angaben des Antragstellers – und Unterschriften sind auch noch zu leisten. Eine fallabschließende Risikobewertung mit konkretem Angebot noch direkt am Point-of-Sale ist so nicht zu erreichen.

Klar: Eine hinreichend komplexe Risikoprüfung eines Antrags erfordert Expertenwissen. Vor den Zeiten der computergestützten Risikoprüfung war die Risikoprüfung unmittelbar nach Ausfüllen der Offerte oder des Antrags vor Ort aufgrund der fehlenden Expertise nicht möglich. Erst mit der Einführung der computergestützten Gesundheitsprüfung eröffnete sich die Möglichkeit, die Risikoprüfung ohne Expertenwissen zeit- und ortsunabhängig durchzuführen – theoretisch.

Denn 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“) mehr als 20 Jahre alt ist, hat sie sich bis heute in der Personenversicherung immer noch nicht flächendeckend durchgesetzt. Manche fürchten einen zu hohen technischen Aufwand, der Vertrieb einen zeitlichen Mehraufwand und andere haben vielleicht auch schon Enttäuschungen erlebt. Die ersten beiden Argumente sind unbegründet: Der technische Aufwand kann sehr überschaubar gestaltet werden und eine solche Software erspart dem Außendienst viel Bürokratie.

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, sollte die zugrunde liegende Datengrundlage der Risikoprüfung über alle Vertriebskanäle stets dieselbe sein.

Am Rande sei dazu bemerkt, dass standardisierte Fragebögen und Antragsformulare von Portalanbietern, die in der Regel nicht denen der Versicherungsgesellschaft entsprechen, entweder keine seriöse Risikoprüfung zulassen oder die Versicherung lässt unterschiedliche Arten der Risikoprüfung für ein und denselben Tarif gelten, eigentlich ein No-Go.

Die Datengrundlage muss also unabhängig von System-Plattformen, Eingabe-Ort, Programm und Eingabemaske stets dieselbe sein. Da die Umsysteme (Angebots- und Antragssysteme) im Antragsprozess pro Vertriebskanal unterschiedlich sein können, sollte die Risikoprüfung nicht zusammen mit dem Antragsprozess von einem einzigen System abgedeckt werden, obgleich manche Software-Anbieter solche Systeme tatsächlich wohlklingend als „Standardsoftware“ vertreiben.

Es gibt keinen Standard für ein solches System, denn es ist enorm vielen Änderungsparametern in mehreren Dimensionen ausgesetzt (spezifische Kundenwünsche, technologische Neuerungen, Einführung neuer Tarife, neue Vertriebskanäle, Unterstützung mehrerer Sparten gleichzeitig) und die Gefahr, es dem einen Kunden auf Kosten eines anderen Recht zu machen, ist groß.

Und: Eine Lösung von der Stange erlaubt keine individuelle, versicherungsspezifische Handhabung der Risikoprüfung. Somit ist die Risikoprüfung als fachliche und technische Zusatz-Komponente im Antragsprozess zu sehen – wenngleich als eine sehr wichtige, liefert sie doch die Kalkulationsbasis für Risiken und etwaige Angebote.

Integration in Umsysteme

Die Prüf-Software lässt sich prinzipiell reibungslos in die IT des Versicherers integrieren, wenn sie über die folgenden sechs software-technischen Eigenschaften verfügt, die zudem den späteren wartungsarmen Betrieb ermöglichen:

Erstens: Die Komponente kann ohne Neukompilation des Quellcodes auf unterschiedlichen Systemplattformen betrieben werden. Das 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.

Zweitens: Die Architektur der Prüf-Software 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 grafische Benutzerschnittstelle (GUI) mit allen GUI-Technologien programmieren, die er unterstützen möchte und die je nach Vertriebskanal unterschiedlich sein können. 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.

Drittens: Die Schnittstelle zum Umsystem muss auf das Minimum reduziert, einfach und unzweideutig beschrieben sein. Das geht soweit, dass die Risikoprüfung über ein- und dieselbe Schnittstelle über mehrere Versicherungssparten betrieben werden kann. Das funktioniert aber nur, wenn überall dasselbe Prüfsystem im Einsatz ist. Geschlossene, monolithisch aufgebaute Risikoprüfungssysteme, die womöglich Geschäfts- und Maskenlogik durchmischen, sind für den spartenübergreifenden Einsatz untauglich. Es gibt jedoch bereits praxiserprobte, spartenübergreifende Lösungen, mittels derer die Risikoprüfung auf Knopfdruck für alle Sparten in einem einzigen Schritt erfolgen kann – ohne dass die IT des Versicherers auf eine Schnittstellenänderung im großen Stil reagieren müsste.

Viertens: Die Komponente muss über die heute gängigen Standardstecker verfügen. Darunter sind die Unterstützung der Service-Schnittstellentechnologien SOAP und RESTFull.

Fünftens: Die Software weist ein Minimum von Abhängigkeiten zu Fremdsystemen auf. Dieser Punkt ist der guten Praxis des Software-Engineerings geschuldet: Komplexe Systeme sind aus einfacheren Komponenten aufgebaut, die lose miteinander gekoppelt sind. Der Aspekt hat wesentliche Auswirkung auf den späteren wartungsarmen Betrieb und steht in eigenartiger Unproportionalität zur geringen Beachtung bei Entscheidern.

Sechstens: Die Komponente zeichnet sich durch Bescheidenheit in den Systemvoraussetzungen aus. Denn: Die Risikoprüfung findet auch auf Laptops von Maklern statt. Deren Rechner sind oft über zehn Jahre alt.

Ob eine Software wahrscheinlich gut in eine bestehende IT integrierbar ist, lässt sich letztlich an einem einfachen Indiz festmachen: Wenn der Anbieter nämlich keinen Integrationsaufwand verrechnet, weder extra noch verdeckt.

Der Mediziner im System

Mit der Integrierbarkeit und den Kompatibilitätsvoraussetzungen ist aber noch nicht die Qualität der Prüf-Software beschrieben. Entscheidend ist die Qualität der medizinischen Fragen zur Gesundheit des Antragstellers. Nicht die Menge der Fragen liefert ein umfassendes Gesundheitsbild, sondern die Qualität der Fragen.

Ganz einfaches Beispiel: Einen 20-jährigen Sportler braucht das System nicht nach Bluthochdruck zu befragen. Viel spannender noch wird es, wenn ein Antragsteller versucht, seinen Gesundheitszustand zu beschönigen. Mit einem Höchstmaß an integrierter versicherungsmedizinischer Kompetenz, die sich nicht nur in Statistiken erschöpft, spüren intelligente Systeme über bestimmte Algorithmen auf, wenn sich der Antragsteller widerspricht oder gar etwas vergisst anzugeben.

Als säße der Mediziner im System, durch den der Umweg über den Hausarzt (der auch nicht immer über alle Informationen verfügt) erspart bleibt. Auch ohne den Arzt steht am Ende ein gut durchkalkuliertes, nachvollziehbares und somit haftungssicheres Ergebnis.