"Computer Aided Design for Insurance Products" (CAD/IP) nennt die Schweizerische Mobiliar Versicherungsgesellschaft, Bern, ihre Anwendung zur Produktentwicklung. Mit die-sem Tool arbeiten Produkt-Manager, die die fachlichen Anforderungen definieren und strukturieren.
Die Produkt-Manager konstruieren Produktbausteine und verknüpfen sie zu kundenspezifischen Angeboten. CAD/IP enthält Such- und Prüffunktionen, die das Zusammenstellen erleichtern, sowie diverse Report-Möglichkeiten. Außerdem kann der Anwender die Produktmerkmale, etwa die beim Vertragsabschluß relevanten Informationsbedürfnisse des Kunden, in einem Metamodell festschreiben und den Bausteinen zuordnen. Diese Definitionen bilden die Grundlage für die Ermittlung von Risiken und für die Tarifierung der neuen Versicherungsprodukte. Zugleich wird hier festgelegt, in welchen Schadensfällen eine Versicherungsleistung in welcher Höhe fällig wird, wann der Schadensfalls eintritt und wie die Erstattung statistisch erfaßt werden soll. Einige der CAD/IP-Komponenten sind derart detailliert festgelegt, daß die Produktentwickler nur noch die jeweilige Ausprägung wie Vertragsbeginn, -dauer und -ablauf zu wählen brauchen. Auch die Layouts der Kundendokumente wie Policen und Prämienrechnungen sind im Sinne einer Corporate Identity vorgegeben. Abgerundet wird die Applikation durch eine Produktverkaufssimulation, die anhand von Beispielfällen errechnen kann, mit welchen Prämien der Verkäufer zu rechnen hat.
CAP/IP entstand 1996/1997 in Zusammenarbeit mit dem Systemhaus Alldata SDV. Im Jahr 1995 wurde die schweizerische Bundesbehörde für Versicherungswesen abgeschafft. Damit setzte eine Deregulierung der Versicherungswirtschaft ein, die eine schnelle Produktentwicklung zum Wettbewerbsfaktor werden ließ, so Felix Grimm vom CAD/IP-Projekt. Da habe es nahegelegen, neue Produkte aus bereits entwickelten Komponenten - von Textbausteinen bis Geschäftsregeln - zusammenzusetzen.
Erfahrung mit dem Modulkonzept hatte die Versicherung schon in den Jahren 1994 und 1995 mit den Produkten "Mobicasa", einer Haushaltsversicherung, und "Mobipro, einer Unternehmensversicherung für kleine und mittlere Betriebe, gesammelt. Ohne ein Produktionssystem wie CAD/IP allerdings erwies sich dabei besonders die klare und strukturierte Definition der Anforderungen als arbeitsintensive Herausforderung.
Als die Entscheidung für die Entwicklung von CAD/IP fiel, stand fest, daß die Anwendung "modern" sein sollte und deshalb objektorientiert programmiert. Als Entwicklungs-Tool wählten die Entwickler "Visual Age for Smalltalk". Nach Erfahrungen mit dem "Persistant Framework" von Micado, das die Applikationsobjekte für die Speicherung in einer relationalen Datenbank aufbereitet, und mit DB2/2 entschied man sich letztlich gegen diese Lösung und für eine objektorientierte Datenbank. "Wenn Applikationsobjekte in einer relationalen Datenbank ablegt werden, ist das, als wenn man das Auto vor dem Parken in der Garage in seine Einzelteile zerlegt", lautet der Vergleich, den Grimm ins Feld führt (siehe Kasten). Die Schweizer Versicherer suchten sich das Datenbank-Management-System von Versant aus, nachdem der Hersteller innerhalb eines Monats einen Prototypen vorweisen konnte und ein OS/2-Client-Interface entwickelte. Serverseitig ist Versant auf einem AIX-Rechner implementiert.
Bis auf dieses Interface, das laut Grimm elegant und benutzerfreundlich ist, laufe die Anwendung stabil und problemlos. Der Objekt-Spezialist bemängelt allerdings, daß Versant noch kein Multithreading unterstützt, so daß es unmöglich ist, im selben Prozeß mit unterschiedlichen Programmiersprachen auf die Datenbankobjekte zuzugreifen. Das ist jedoch notwendig, da einige CAD/IP-Module nicht in Smalltalk, sondern in C geschrieben sind.
In der Kombination Smalltalk-Versant fehlen zudem Debugging-Möglichkeiten bei fehlerhaftem Datenbankzugriff. Eine weitere Schwäche zeigt Versant bei der Vergabe von Zugriffsberechtigungen; ein Sperren der Zugangsberechtigung ist lediglich für die gesamte Datenbank möglich, nicht jedoch für einzelne Klassen. Außerdem zeigt die Datenbank Mängel bei der referenziellen Integrität. Werden Klassen gelöscht, bestehen die Referenzen zu anderen Klassen weiterhin.
Konkurrenzanalysen bei der Allianz
Die Allianz-Sachgruppe löste ganz andere Probleme mit Hilfe der Objektdatenbank von Versant. Hier entsteht ein umfassendes Online-Informationssystem, mit dem das Geschäft überprüft und ausgewertet sowie geplant und simuliert werden kann. Die technische Grundlage für das "Allianz Planungs- und Simulationssystem" (APPS) ist das "Meta Planungs- und Simulationssystem" (MPSS). MPSS wird von der Meta Finanz-Informationssysteme GmbH, St. Georgen, einer 100prozentigen Tochter der Allianz, entwickelt. Mit diesem Werkzeug können die Anwender ihre Applikationen per Mausklick zusammensetzen. Es stellt die Infrastruktur und Generatoren bereit, mit denen sich die Geschäftsprozesse, Abfragedimensionen und -kriterien modellieren lassen.
Pilotanwendung des APSS ist ein Wettbewerbersystem, mit dem Controller Konkurrenzanalysen vornehmen. Die Anwendung entstand innerhalb von zwei Monaten und enthält bei etwa 50 MB rund 600000 Datensätze. Die Kennzahlen dieser Anwendung stammen vom Gesamtverband der deutschen Versicherungswirtschaft (GDV). Der Verein sammelt und publiziert die Zahlen aus den Geschäftsberichten der Mitgliedsversicherungen.
Vor der Einführung der neuen Wettbewerbsapplikation arbeiteten die Controller aus der Zentrale der Allianz-Sachgruppe mit dem DOS-basierten System "Gisela" vom GDV. 1995 wurden jedoch die Vorschriften für die Rechnungslegung der deutschen Versicherungsunternehmen geändert. Das führte dazu, daß nun wesentliche Bruttokenngrößen je Versicherung und Sparte im Geschäftsbericht der Unternehmen sichtbar werden. Diese geben bessere Hinweise auf die tatsächlichen Deckungsbeiträge, als das Nettozahlen leisten, die beispielsweise Rückversicherungsleistungen verdecken. Gisela konnte die neuen Kenngrößen wie verdiente Bruttobeiträge, Bruttoaufwendungen für den Versicherungsbetrieb und für Versicherungsfälle nur unzureichend erfassen und analysieren. So gab es beispielsweise keine Möglichkeit, die Versicherungsunternehmen mit einer Bruttoschadensquote unter einem bestimmten Betrag für die Sparte Kraftfahrzeughaftpflicht zu ermitteln. Außerdem konnte nur unzureichend nach Versicherungsunternehmenstypen wie Schadens- und Unfall-, Industrie-, Service- und Direktversicherer gruppiert werden. Der Vergleich mit den Wettbewerbern wurde zunehmend dringlicher, da auch in Deutschland 1995 die Deregulierung des Versicherungsmarktes einsetzte.
Zunächst habe man daran gedacht, die Wettbewerbsdaten mit Hilfe einer Microsoft-Access-Datenbank zu nutzen, sagt Matthias Dolderer, Controller aus der Generaldirektion der Allianz Versicherungs AG, München. Die Idee wurde jedoch ad acta gelegt, weil die Kostenkontrolleure ein Instrument in die Hand bekommen sollten, das sie selbst ohne Eingriffe der DV-Kollegen bedienen und konfigurieren können.
In der Regel kommen in solchen Fällen Olap-Werkzeuge (Olap = Online Analytical Processing) von Cognos und Business Objekts, relationales Olap wie von Microstrategy und Information Advantage oder multidimensionale Datenbanken zum Einsatz. Die Allianz entschied sich jedoch für ein objektorientiertes Metamodell und eine Objektdatenbank. In dieser spiegeln Klassen, Objekthierarchien sowie Objektbeziehungen die Dimensionen, Detailstufen und Kombinationsmöglichkeiten für die Online-Analyse wider.
Mit Hilfe des Strukturgenerators aus dem MPSS entstehen die Dimensionen und Beziehungen sowie die Drill-down-Stufen. So gehören zur Klasse Kraftfahrzeugversicherung Teil- und Vollkasko sowie Haftplicht. Fragt der Benutzer die Daten ab, bekommt er sie konsolidiert oder auf der Ebene der Teilbereiche.
APPS-Anwender können zudem Deckungsbeitragsrechnungen bezogen auf die Versicherungsunternehmen, die Sparte oder Branche, die Standorte und die Kundengruppen vornehmen. Das System ermöglicht ferner, die Verwaltungs- und die Vertriebskosten etwa aufgesplittet nach Kostenarten zu ermitteln sowie Nettoergebnisberechnungen für die mittel- und kurzfristige Planung einzusetzen.
Mit dem Grunddaten- und Formelgenerator lassen sich Regeln und Kennzahlen beschreiben, und der Tabellengenerator ermöglicht ein beliebiges Slice and dice. Neue Sichten auf die Daten entstehen, indem Dimensionen und Kriterien miteinander kombiniert werden. Die Abfrageergebnisse erscheinen als Tabellen oder grafisch auf dem Bildschirm. Bis eine zwei- oder mehrdimensionale Tabelle mit Werten gefüllt ist, vergeht maximal eine Sekunde. Wird die Abfrage durch Bedingungen eingeschränkt (zum Beispiel: Versicherer, die mehr als den Betrag X für die Schadensregulierung aufwendeten), dauert die Antwort bis zu einer Minute.
Eine Zelle dieser Auswertungstabelle läßt sich mit "dynamischen Attributen" versehen. Wurden die GDV-Daten etwa um aktuelle Informationen aus der Zeitung ergänzt, erhält dieser Wert quasi als Anhang einen Kommentar, ein "Ecxel"-Sheet oder auch den eingescannten Zeitungsbericht. Auf diese Weise läßt sich nachvollziehen, welcher Quelle der Wert entnommen wurde.
Tabellen oder Objekte?
Entscheidet sich ein Projektteam für ein objektorientiertes Datenbank-System, muß es sich mindestens folgende Fragen gefallen lassen:
- Muß die Anwendung unbedingt auf einem objektorientierten Datenbanksystem aufsetzen? Wo liegen die Vorteile?
- Ist der Einsatz nur der erste Schritt zur Migration aller Systeme auf objektorientierte Datenbanken?
- Können Objektdatenbank und existente Datensysteme nebeneinander bestehen?
- Muß zusätzliches Know-how eingekauft und aufgebaut werden? Brauchen wir Spezialisten?
- Welches ist das beste Produkt? Gibt es die Herstellerfirma in fünf Jahren noch?
Nicht alle Fragen lassen sich laut Thomas Baumann, Mitglied des Kaders der Schweizerischen Mobiliar, eindeutig beantworten. So ist die Frage nach dem besten Produkt etwa von den Applikationsanforderungen abhängig, ebenso die Wahl des Datenbanktyps. Die Mobiliar-Entwickler haben Kriterien für die Wahl relationaler und objektorientierter Datenbanken aufgestellt.
Ein relationales System sollte es sein, wenn die Daten anwendungsneutral sein müssen, so daß sie in mehreren Applikationen unverändert benutzt werden können. Auch wenn das Datenmodell bereits existiert, relativ einfache Datenstrukturen und viele Einträge in vergleichsweise wenigen Tabellen vorliegen, und kurze Transaktionen erforderlich sind, sollte sich das Projektteam für das relationale Ablegen der Daten entscheiden. Außerdem ist ein solches System bei starkem Mehrbenutzerbetrieb und bei geringer Performance pro Anwender, aber hoher Leistung bei vielen Usern sinnvoll.
Hingegen spricht alles für ein objektorientiertes Datenhaltungssystem, wenn die Modellierung nicht auf Entitäten, sondern bereits auf Objekten beruht. Erfordert die Anwendung lange Transaktionen, die sich mehrere Tage hinziehen können, eine hohe Performance für jeden Benutzer sowie viele Objekttypen, empfiehlt sich eine Objektdatenbank.