Geschäftsfall und Geschäftsobjekte

Teil des Prozesswissens. Der Geschäftsfall ist die Klammer, die Geschäftsobjekte tragen Inhalt und Zustand; sie entstehen durch Erzeugung oder Ableitung, können einem Hauptobjekt untergeordnet sein und teilen dieselben Kernmerkmale, und die Berechnung ist je nach Aufbewahrung Auskunft oder Geschäftsobjekt.

Geschäftsfall als Klammer

Der Geschäftsfall (business case) ist die Kennung, unter der zusammengehörige Geschäftsobjekte liegen: in der Antragsstrecke Berechnungen, Offerte, Antrag und Vertrag eines Vorgangs; in der Vertragsänderung der Änderungsantrag zu einem bestehenden Vertrag. Er wird in OMDS 3 durch die Geschäftsfallnummer repräsentiert.

Der Geschäftsfall trägt drei Dinge:

  • Persistenz, Berechtigung und gemeinsame Bearbeitung. Ob der Versicherer den Geschäftsfall aufbewahrt, wer darauf zugreifen darf und ob Dritte – weitere Vermittler, Sachbearbeiter des Versicherers – ihn gemeinsam bearbeiten können, sind Eigenschaften des Geschäftsfalls, die der Versicherer als Prozesswissen deklariert.

  • Die Folgeschritte. Jede Antwort nennt am Geschäftsfall und an seinen Objekten, welche Operationen jetzt zulässig sind (Folgeschritt-Links). Was dort nicht steht, ist nicht zulässig.

  • Den Typ. Jeder Geschäftsfall gehört zu genau einem Geschäftsfalltyp (siehe Geschäftsfalltypen), der festlegt, welche Geschäftsobjekte unter ihm entstehen können.

Was der Geschäftsfall nicht hat, sind fachliche Zustände. „Berechnet“, „offertiert“, „eingereicht“, „angenommen“ sind Zustände der Geschäftsobjekte, nicht der Klammer. Ein Geschäftsfall, unter dem ein Offert und ein Antrag liegen, hat keinen eigenen Zustand, der die beiden zusammenfasst; er ist offen, solange unter ihm gearbeitet wird, und beendet, wenn sein Typ das vorsieht (Vertrag abgeleitet, Antrag abgelehnt, Offert abgelaufen, Vorgang storniert).

Geschäftsobjekt

Ein Geschäftsobjekt (business object) ist das, was der Versicherer aufbewahrt und was sich verändern lässt: Berechnung, Offert, Antrag, Vertrag, Änderungsantrag, Schadenmeldung. Es hat eine eigene IRI unter der IRI des Geschäftsfalls, einen Inhalt – in der Antragsstrecke die Produktkonfiguration mit Risikoobjekten, Personen und Antragsfragen – und einen fachlichen Zustand. Die Zustände leben am Geschäftsobjekt; wie sie entstehen und wechseln, beschreibt Zustände eines Geschäftsobjekts.

Entstehen: Erzeugung und Ableitung

Ein Geschäftsobjekt entsteht auf einem von zwei Wegen:

  • durch Erzeugung ohne Vorgänger: Der Client legt das Objekt vollständig an – ein Offert direkt, ein Antrag ohne vorheriges Offert, eine Schadenmeldung zu einem Vertrag;

  • durch Ableitung aus einem Vorgänger: Das neue Objekt übernimmt den Inhalt des Vorgängers und trägt dessen IRI als Herkunft. Die Herkunft ist ein Verweis, keine feste Bindung: Ein Offert kann aus einer Berechnung abgeleitet und später neu abgeleitet werden (neue Version des Offerts in der Historie des Geschäftsfalls), die Berechnung bleibt dabei unverändert, und das Offert lebt weiter, wenn die Berechnung später verworfen wird.

In der Antragsstrecke sind die Ableitungen Berechnung → Offert und Offert → Antrag optional: Jedes dieser Objekte darf auch ohne Vorgänger erzeugt werden (OMDS 3 kennt das als „Offert ohne Berechnung“ und „Einreichung ohne vorheriges CreateApplication“). Die einzige verpflichtende Ableitung ist Antrag → Vertrag: Es gibt keinen Vertrag ohne Antrag, und diese Ableitung stößt der Versicherer an, nicht der Vermittler.

antragsstrecke-kette-geschaeftsobjekte

Das Bild zeigt die Antragsstrecke als Kette selbständiger Geschäftsobjekte unter einer Klammer: Die Berechnung bleibt unverändert, während das Offert aus ihr abgeleitet und später durch eine neue Version ersetzt wird; der zweite Geschäftsfall beginnt mit einem ohne Vorgänger erzeugten Offert; jeder Vertrag hat genau einen Antrag als Herkunft. Je Geschäftsobjekttyp gibt es im Geschäftsfall höchstens ein aktuelles Hauptobjekt; frühere Stände trägt der Geschäftsfall als Versionen in seiner Historie. Über die Typen hinweg hat der Geschäftsfall dagegen mehrere Objekte: In der Antragsstrecke bestehen Berechnung, Offert, Antrag und Vertrag nebeneinander, jedes mit seiner Herkunft, und das jüngste Glied der Kette ist das aktuelle Geschäftsobjekt des Geschäftsfalls, an dem die Folgeschritte hängen. Welche Typen in welcher Zahl vorkommen dürfen, legt der Geschäftsfalltyp fest, nicht der Kern des Modells.

Untergeordnete Geschäftsobjekte

Ein Geschäftsobjekt kann einem anderen Geschäftsobjekt desselben Geschäftsfalls untergeordnet sein (subordinate business object, bc:parent). Das übergeordnete Objekt heißt Hauptobjekt (main object): in der Antragsstrecke Offert, Antrag oder Vertrag. Ein untergeordnetes Objekt hat IRI, Inhalt, Art und eigenen Lebenszyklus wie jedes Geschäftsobjekt und ist ein eigenes Aggregat: eigene Version, eigene Sperre, eigene Konformität seines Inhalts. Haupt- und untergeordnetes Objekt teilen keine Invariante; was sie verbindet, ist eine Abhängigkeit, die der Versicherer bei jeder Verarbeitung neu bewertet. Die erste Art untergeordneter Objekte sind die Nebenprozesse.

Die Regel „je Typ höchstens ein aktuelles Objekt“ gilt nur für Hauptobjekte: Ein Antrag kann mehrere Nebenprozesse tragen, etwa eine Rabattabzeichnung und eine Vorschadenbesichtigung zugleich. Wie viele untergeordnete Objekte welcher Art ein Hauptobjekt tragen darf, deklariert der Geschäftsfalltyp. Wird das Hauptobjekt abgeleitet (Antrag → Vertrag), wandern offene und erfüllte untergeordnete Objekte mit, soweit die Deklaration ihrer Art es vorsieht; sonst bleiben sie beim Vorgänger.

untergeordnete-geschaeftsobjekte

Berechnung: Auskunft oder Geschäftsobjekt

Eine anonyme Berechnung – der Client sendet eine Konfiguration und erhält Prämie und Prüfbericht – ist kein Geschäftsobjekt und begründet keinen Geschäftsfall. Sie ist eine Auskunft: Beim Versicherer bleibt nichts zurück, und sie lässt sich beliebig oft wiederholen, wie ein Tarifrechner. Sobald der Versicherer die Berechnung aufbewahrt – weil der Vermittler sie später wiederfinden, mit Dritten teilen oder ein Offert daraus ableiten will –, wird sie zum Geschäftsobjekt und begründet damit einen Geschäftsfall. Der Übergang von der Auskunft zum Geschäftsobjekt ist eine Erzeugung, keine stille Nebenwirkung der Auskunft.

berechnung-auskunft-oder-geschaeftsobjekt

Kernmerkmale jedes Geschäftsobjekts

Neben Inhalt und Zustand trägt jedes Geschäftsobjekt – Hauptobjekt wie untergeordnetes Objekt – denselben Satz Merkmale. Ein Client, der sie einmal auswerten kann, kommt mit jedem Objekt jedes Geschäftsfalltyps zurecht.

Merkmal Bedeutung

Erstellt, zuletzt geändert (bc:created, bc:modified)

Zeitpunkte der Entstehung und der letzten Änderung von Inhalt oder Zustand.

Version (bc:version)

Kennung des aktuellen Stands, zugleich Kennung des Eintrags in der Historie. Sie sichert das bedingte Schreiben: Bearbeitung, Ersetzung und Übergang nennen die Version, die sie voraussetzen (HTTP If-Match); stimmt sie nicht, lehnt die Zulässigkeitsprüfung ab und nichts verändert sich. Das Gegenstück ist das bedingte Lesen: Jede Auskunft, die ein Objekt oder Produktwissen liefert, trägt die Version als ETag und beantwortet If-None-Match mit „nicht verändert“, so dass unveränderte Objekte nicht erneut übertragen werden. Eine Bearbeitung darf mehrere Deltas in einem Aufruf übermitteln; sie bestehen oder scheitern als Ganzes gegen eine Version, und der Zustand wird einmal neu zuerkannt.

Begründung zum Zustand (bc:stateReason)

Zu jedem gesetzten Zustand optional ein Code aus einer je Typ deklarierten Liste und ein Text; verpflichtend für abgelehnt, abgebrochen, abgelaufen, ungültig und storniert. Meldungen der Konformitäts- und Vollständigkeitsprüfung bleiben davon getrennt (Zustände eines Geschäftsobjekts).

Drei Rollen: Veranlasser, Verantwortlicher, am Zug (bc:requester, bc:owner, bc:actor)

Der Veranlasser hat das Objekt entstehen lassen, der Verantwortliche entscheidet über Zustand und Ergebnis (in der Regel der Versicherer), am Zug ist, wer als Nächstes handeln muss: Kunde, Vermittler, Versicherer oder Dritter. Veranlasser und Verantwortlicher werden bei der Entstehung gesetzt, „am Zug“ ändert sich mit dem Zustand – beim Antrag in Rückfrage ist der Vermittler am Zug, beim offenen Gutachten der Gutachter (Zuständigkeiten).

Frist und Folge (bc:deadline, bc:consequence)

Bis wann gehandelt werden muss und was sonst geschieht: Die Rückfrage am Antrag hat eine Frist, das Offert eine Gültigkeitsdauer, der Nebenprozess eine Frist mit deklarierter Folge. An der Schnittstelle informativ; verbindlich sind Polizze und Schreiben des Versicherers.

Historie als Ereignisse

Jeder Eintrag trägt Zeitpunkt, Operationsart, handelnden Akteur, Versionskennung und einen Ereignisnamen aus dem Vokabular des Typs (bct:ApplicationSubmitted, bct:SubprocessFulfilled). Die Auskunft „Zustandsänderungen abrufen“ liefert diese Ereignisse für alle Objekte des Geschäftsfalls seit einem Zeitpunkt, auch für die untergeordneten.

Verweis auf die Deklaration (bc:declaredBy)

Jedes Objekt zeigt auf die Deklaration seiner Art im Prozesswissen, wie die Produktinstanz auf die Produktdefinition zeigt. So findet ein Client Übergänge, Fristen, Verbindlichkeit und Auslösebedingung der Art ohne Suche.

Navigationslinks (bc:link)

Folgeschritte sagen, was ein Client tun kann; Navigationslinks sagen, wohin er kommen kann, mit den Standardrelationen der IANA: up (Geschäftsfall bzw. Hauptobjekt), collection und item (untergeordnete Objekte), predecessor-version, successor-version, version-history und latest-version (Historie), related (Herkunft), describedby (Deklaration der Art bzw. Produktdefinition), profile (das Profil der Norm, in dem die Antwort steht). Die typisierten Verweise (bc:parent, bc:derivedFrom, bc:declaredBy) bleiben die Quelle; die Links sind ihre Hypermedia-Form, ohne eigene Hülle wie Hydra, HAL oder Siren.

Dazu kommt der Idempotenzschlüssel, mit dem ein Client eine Erzeugung, Ableitung oder einen Übergang gefahrlos wiederholen kann. Die Merkmale sind so weit vorgesehen, wie die Seiten der Geschäftsfalltypen sie nennen; Version mit bedingtem Schreiben, bedingtes Lesen und Navigationslinks folgen mit der Umstellung der Referenzimplementierungen auf Geschäftsobjekte mit eigenen Zuständen.