So ließe sich die fallabschließende Risikoprüfung direkt im Verkaufsgespräch umsetzen

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.

• <
• 1
• 2
• 3
• zur Startseite
• >