6.6 KiB
6.6 KiB
Überlegungen
- Typische Operationen für Vermittler auf der Wolke der Geschäftsobjekte einer Versicherung sind: Neuanlage, Update und Lesen. Löschen kommt schon eher selten vor. Im Folgenden geht es um Neuanlage und um Update bzw. Änderung von Geschäftsobjekten.
- Die Frage ist dabei, wie viel Wissen und Logik auf Clientseite vorausgesetzt werden soll, bzw. wie viel von Serverseite unterstützt werden kann.
- Bei der OMDS Antragsstrecke setzen wir bisher stark darauf, dass der Client in der Lage ist, einen gültigen Antrag zu erstellen. Dafür muss er das Metamodell kennen und bei sich abbilden. Heute erfolgt das über Programmierung z.B. auf Basis einer Produkt- und Schnittstellendokumentation.
- Bei Update könnte man auch diesen Ansatz nutzen und vom Client verlangen, dass er das Metamodell kennt und die Instanz in neuer Form gültig übermittelt.
- Für viele Änderungen wirkt dies aber übertrieben anspruchsvoll für den Client. Wenn die Zahlungsfrequenz eines Vertrags geändert werden soll, so genügt es die Polizzennummer und die neue Zahlungsfrequenz zu übermitteln. Die Kombination aus Verfahren und reduziertem Objektmodell für das Verfahren erscheint zweckmäßiger.
- Theoretisch ließen sich nicht nur Änderungen auf diese Weise abbilden, sondern auch Neuanlagen, wenn sie sich in
Verfahrensschritte zerlegen lassen. Allerdings ist die Frage, wie sinnvoll das ist, da Clients oft Produkte
vergleichen müssen und dabei eine sukzessive Anlage nicht in Betracht kommt. - Metamodell und Instanzen können für unterschiedlichste Zwecke erstellt werden. Theoretisch ist es auch möglich, sehr statische Modelle auf diese Weise zur Laufzeit zu übermitteln. Dies ist aber nicht sinnvoll. Für Zwecke, wo das Modell auf absehbare Zeit konstant ist, ist es sinnvoll, das Modell traditionell statisch zu definieren. Dies schließt gemeinsame, service-übergreifende Elementdefinitionen nicht aus. Beispiele hierfür sind Abfrage von Dokumenten, Maklerpost, Ereignissen.
- Metamodelle zur Laufzeit machen Sinn für - komplizierte, zur Laufzeit veränderliche Requests. Zur Laufzeit veränderlich ist insbesondere das Produktwissen, welches für Anträge, Konvertierungen und Vertragsänderungen erforderlich ist.
### Process Flows
#### Antragsstrecke:
Anforderungen
Basis
- Es gibt Verfahren, diese legen fest, welche Services aufrufbar sind und welche Daten erwartet werden.
- Ein Auskunftsservice soll das Metamodell für den eigentlichen Request zurückgeben.
- Es soll einen Service zur probeweisen Ausführung der Modellinstanz geben (Validierung, Berechnung am Server) und einen Service zur eigentlichen Durchführung.
- Es gibt Use-Cases, wo man vollständige Modelle übermitteln möchte, z.B. um ein neues Geschäftsobjekt anzulegen oder zu erzeugen. Ein Beispiel wäre einen Versicherungsantrag zu übermitteln. In diesem Beispiel wird das Geschäftsobjekt komplett neu erzeugt.
- Es gibt Use-Cases, wo man existierende Geschäftsobjekte referenziert und durch die Übermittlung eines kleinen Änderungsobjekts oder Teilmodells modifiziert. Aber auch für kleinere Änderungsobjekt kann die Technik angewendet werden, dass es einen Auskunftsservice und Services für die Validierung und Durchführung der Instanz gibt.
- Versionierung: Es gibt verschiedene Versionen eines Metamodells.
Schichten
| Objekte | Prozesse |
|================================================|================================================|
| VU-spezifische Datenobjekte | |
|------------------------------------------------| |
| Spartenobjekte | |
|------------------------------------------------| |
| Märkte (Österreich, CEE ...) | |
|------------------------------------------------| |
| Spezielle Datenobjekte: | |
| - Versicherungsverträge | |
| - Anträge | |
| - Schaden | Konkrete Prozesse: |
| - ... | Verknüpfung mit Datenobjekten | |
|------------------------------------------------|------------------------------------------------|
| Datenobjekte allgemeine Eigenschaften | Pattern / Profile Geschäftsprozesse |
|------------------------------------------------|------------------------------------------------|
| Technologie: Webservices, SOAP, REST, JSOM-LD |
|------------------------------------------------|------------------------------------------------|
| TCP-IP |
|------------------------------------------------|------------------------------------------------|
Versicherungsprodukte
Antragsverfahren
- Das Antragsverfahren hat eine a-priori Produktauskunft, welche das Produktwissen übermittelt.
- Es gibt spezielle Objekte für
- Produktbaum, bestehend aus
- Deckungsbaum
- (Produkt, Ereignis, Leistung wie bei VP/MS ?)
- Versicherungssummen
- Selbstbehalten
- Deckungsvarianten
- Versicherte Interessen (ein Objektmodell)
- Deckungsbaum
- Umschläge für Berechnung, Offerterstellung, Antrag
- Personendaten
- Sicherstellungen (Vinkulierungen...)
- Zahlungsinformationen
- Vertragsrollen
- Bezugsrechte
- Produktbaum, bestehend aus
Konvertierungsverfahren
- Scope: Für einen bestehenden Vertrag bzw. mehrere bestehende Verträge werden die Änderungsmöglichkeiten bezüglich der Deckung angezeigt.
- Proposal: Es wird ein Vorschlag, für eine der gewünschten Deckung entsprechenden Folgevertrag erstellt.
- Es wird ein Antragsverfahren durchgeführt, um die Konvertierung auf den neuen Vertrag durchzuführen.
Vertragsänderungsverfahren
- Behandelt Teilmodelle bezogen auf existierende Geschäftsobjekte (insbesondere Verträge)
- Kennt zwei Profile:
- Profil 1: stateless. Services Check und Execute
- Profil 2: stateful. Services Create und Submit