Anforderungen

Einleitung

Im Jahr 2000 hat die LVM Versicherung ein neues Außendienst-System entworfen, welches zur Akquise und Kundenstammdatenverwaltung im Sinne einer Customer Relationship Management-Anwendung (CRM) eingesetzt wird. Es wurde entschieden, das System sowohl auf Server- als auch auf Client-Seite in Java zu implementieren. Der Client wurde mit der Java Swing-Bibliothek als Thin-Client entwickelt. Dieser wurde so implementiert, dass Views im Client definiert werden während die Befüllung und jegliche Interaktion vom Server aus gesteuert wird. Somit ist im Client weder Business- noch Anwendungslogik enthalten.

Die einzelnen Anwendungen in dem System (z.B. Produkt-Anwendung und Inkasso-Anwendung) sind dabei über die Oberfläche sowie über Backend-Aufrufe miteinander verknüpft. Dieses System wird aktuell als Monolith freigegeben und erzeugt dadurch starke Abhängigkeiten zwischen den Entwicklungsteams. Die Fachlogik aus dem System wird in REST- und asynchronen (Batch sowie Einzelsatz) Anwendungen wiederverwendet.

Das System ist über die Jahre weiter gewachsen: Es wurde insbesondere um Vertrags- und Schaden-Anwendungen für Innendienstsachbearbeiter erweitert und ist heute zentrales Arbeitsinstrument vieler Mitarbeiter im Innen- und Außendienst. Zukünftig werden weitere Altanwendungen in dieses System migriert.

Aktuell wird untersucht, welche Alternativen es zu der aktuellen Oberfläche gibt und welche für die LVM Versicherung geeignet ist. Dabei wurde der Fokus auf browserbasierte Oberflächen gelegt, da desktopbasierte native Bibliotheken zukünftige Plattformwechsel erschweren würden. Aktuell verwendet die LVM Versicherung ein auf Ubuntu basierendes Client-Betriebssystem.

Um diese Alternativen zu betrachten, wurden die Architekturen Single-Page-Application (SPA) und Resource-oriented Client Architecture (RoCA) untersucht. SPA erzeugt auf der Client-Seite HTML, während ROCA dies ausschließlich auf der Server-Seite tut. Es gibt noch weitere Architekturen der serverseitigen HTML-Erzeugung, wie zustandsbehaftete komponenten-basierte Systeme (z.B. JavaServerFaces). Diese haben den Nachteil, dass sie durch nicht persistente Sitzungs-Daten schlechter skalierbar und in Cloud-Umgebungen nicht einsetzbar sind. Daher wurden diese Architekturvarianten ausgeschlossen.

Für die genauere Betrachtung wurden die Firmen innoQ (RoCA) und Thinktecture (SPA) beauftragt, Prototypen zu entwickeln, die die nachfolgend beschriebenen Anforderungen und Szenarien abdecken.

Entwickler von innoQ

Entwickler von Thinktecture

Ziel der Veröffentlichung auf GitHub

Nach der erfolgten Umsetzung der beiden Prototypen wollen wir, die LVM Versicherung, beide Lösungsansätze hiermit der Allgemeinheit zur Verfügung stellen, um eine öffentliche Diskussion über die Vor- und Nachteile beider Architekturen anzustoßen.

Mit welchen Fragestellungen beschäftigen wir uns?

Rahmenbedingungen

Da wir vorwiegend die Clientarchitektur untersuchen möchten, haben wir die fachlichen Services als Backend-Mock in Form von REST-Services bereitgestellt. Das Einsatzgebiet der Anwendung konzentriert sich auf die von der LVM vorgegebene Infrastruktur. Daher reicht es aus, einen Browser (z.Z. Firefox) zu unterstützen.

Fachliche Anfoderungen

Fachliches Model

Analog zu anderen CRM Applikationen soll auch im Prototyp der Endkunde im Fokus stehen. Darunter verstehen wir, dass die Anwendung alle Informationen zu dem Kunden anzeigen soll. Aus der Kundenübersicht soll der Vertreter oder Innendienst-Mitarbeiter in die jeweiligen Versicherungsprodukte verzweigen, sieht dabei jedoch weiterhin die wichtigsten Kopfdaten des Kunden.

Die einzelnen Anwendungen sollen fachlich verknüpft sein, wie z.B. das Angebots-/Antragssystem mit dem Vertragssystem. Auf Grund dessen soll eine einfache Interaktion zwischen den Anwendungen möglich sein, d.h. der Sprung z.B. aus dem Vertrag in dazugehörige Schäden oder die Anzeige von Schadeninformationen innerhalb der Vertragsübersicht soll realisierbar sein.

Durch die Integration verschiedener fachlicher Anwendungen wirkt die Gesamtanwendung gut bedienbar und somit komfortabel. Neben den kundenzentrierten Anwendungen gibt es einzelne unabhängige Anwendungen (wie z.B. Finanzrechner), die ebenso leicht erreichbar sein müssen. Die Integration ist hier durch eine sehr dünne Kopplung an der Oberfläche möglich.

Die Komplexität der Formulare umfasst eine Vielzahl von Attributen und mehrere Struktur-Ebenen (1:n:m...), die in der Oberfläche abgebildet werden sollen. Die Schwierigkeit besteht darin, eine umfangreiche und komplexe Struktur einfach und verständlich darzustellen und das Maximum an Bedienbarkeit zu gewährleisten.

In der Bearbeitung von Vorgängen (z.B. Angebotserstellung) kann es durch Kundenkontakt (Anruf oder persönlich in der Agentur) zu Unterbrechungen kommen. Deshalb soll der aktuelle Vorgang zur Seite gelegt, der Kunde bedient werden. Anschließend soll mit dem ursprünglichen Vorgang fortgefahren werden können. Ebenso sollte es möglich sein, bestimmte Formulare parallel bearbeiten zu können (z.B. mehrere Angebotsvarianten, die man dem Kunden vorstellt). Der Wechsel zwischen den Formularen soll schnell und einfach funktionieren, außerdem sollte der Überblick über alle geöffneten Formulare vorhanden sein.

Technische Anforderungen

Anwendungen insbesondere im Innendienst bestehen aus vielen Formulardaten, die vom Sachbearbeiter verarbeitet werden. In der Regel werden die Formulardaten bearbeitet, automatisch geprüft und gesichert. Neben den Formularen werden Wizards zur geführten Eingabe verwendet. Diese umfangreichen und z.T. komplexen Formulare sollen in den Prototypen abgebildet werden.

Die Szenarien des Innendienstes sind primär prozessorientiert und werden mittels einer Aufgabenliste durch den Sachbearbeiter angestoßen bzw. abgearbeitet. Daher haben wir im nachfolgenden Absatz die Szenarien mit Formularen, Wizard und einer Aufgabenliste formuliert. Das prozessorientierte Vorgehen zeigt sich darin, dass z.B. der Sachbearbeiter seine Aufgabenliste (Briefkasten) aufruft und dort einen einzelnen Eintrag öffnet. Von dort kann er in den Bezug (z.B. Vertrag oder Schaden) verzweigen und ihn ggf. dort bearbeiten. Nach der Bearbeitung wird dieser Bezug geschlossen und die Aufgabenliste wird wieder angezeigt. Dieser Prozess kann mehrere Ebenen haben (z.B. Aufgabenliste -> Vertrag -> Schaden), was im Prototypen abgebildet werden soll.

Formularfelder haben teilweise fachliche Abhängigkeiten untereinander: z.B. müssen bei der Veränderung eines beitragsrelevanten Feldes alle Ergebnisfelder abgelöscht werden. Dies soll direkt im Client ohne Interaktion mit dem Server ausgeführt werden.

Durch die Erfahrung der immer größer werdenden Gesamtanwendung und dem monolithischen System soll das zukünftige System modular aufgebaut werden, d.h. dass einzelne Anwendungsteile (Schaden, Vertrag, Briefkasten) losgelöst von einander betrieben und bereitgestellt werden. Trotz dieser Modularisierung soll eine Integration möglich sein, wobei dies ein einfacher Link oder eine eingebundene Komponente sein kann. Eine Wiederverwendung von Komponenten muss ermöglicht werden (z.B. Berufsauswahl muss übergreifend zur Verfügung gestellt werden).

Um eine große Anzahl an Oberflächen produzieren zu können, soll ein einheitliches Layout mit zentral bereitgestellten GUI-Komponenten realisiert werden können. Diese Komponenten sollen einfach einzusetzen und leicht erweiterbar sein.

Da die Anwendung auch im Vertrieb verwendet wird, soll sie mit geringer Bandbreite und hoher Latenz auskommen und dennoch eine ausreichende UserExperience (UX) bieten.

Zukünftig strebt die LVM Versicherung an, den Browser als Laufzeitumgebung für Anwendungen zu verwenden. Daher ist es notwendig, native Funktionen moderner Web-Browser, wie speicherbare URLs, Vor- und Zurück-Navigation und Tabs zu unterstützen.

Szenarien

Mit den Szenarien wollen wir die grundlegenden Anforderungen abbilden. Diese müssen durch folgende Anwendungen in eigenen Modulen umgesetzt werden: Kundensuche und Kundenübersicht (Rahmenanwendung), Aufgabenliste (modulare Anwendung), Brieferzeugung (Wizard), Berufsauswahl (modulare Komponente), Schaden (modulare Anwendung)

Szenario 1: "Kundengespräch mit Schadenaufnahme"

Über einen Dialog wird der Kunde über seinen Namen und weitere Kriterien gesucht. In der Ergebnisliste wird ein Kunde ausgewählt und geöffnet. In der geöffneten Kundenübersicht werden allgemeine Informationen zu dem Kunden, wie Kontakthistorie, Angebote, Anträge und Verträge angezeigt. Über einen Button öffnet sich ein neues Angebot, in dem das Geburtstagsdatum und die Anschrift des zuvor ausgewählten Kunden vorbelegt sind. Die Berechnen-Funktion wird aufgerufen und es erscheint ein Fehlerdialog mit mehreren Meldungen. Über die Fehlermeldungen kann zu den fehlerhaften Feldern navigiert werden.

Eine weitere Anwendungskomponente stellt die Funktion der Berufssuche zur Verfügung. Über diese wird ein Beruf im Angebot erfasst.

Nachdem der Anwender das Angebot gesichert hat, kopiert er das Angebot und öffnet damit beide Angebote parallel. Zwischenzeitlich wird ein weiterer Kunde über die Kundensuche mittels der Vertragsnummer geöffnet. Zu diesem Vertrag erfolgt eine Schadenserfassung. Anschließend wird der erste Kunde als offener Vorgang erneut geöffnet. Alle offenen Vorgänge (Angebote) zu dem Kunden werden geschlossen - es erscheint der Hinweis auf ungesicherte Daten.

Szenario 2: "Integration und Zusammenspiel von Anwendungen"

Die Aufgabenliste wird geöffnet und zeigt eine Liste aller Einträge an. Einem Eintrag kann ein Bezug (z.B. Vertrag, Schaden) zugeordnet sein. Ist ein Bezug zugeordnet, erhält der Anwender die Möglichkeit, in die entsprechende Anwendung zu verzweigen. Wird die geöffnete Anwendung geschlossen, wird erneut die Aufgabenliste dargestellt.

Szenario 3: "Wizard"

Innerhalb der Vertragsanwendung soll eine Brieferstellung per Wizard möglich sein. Hierzu werden in einzelnen Schritten (Dokumentenauswahl, Empfängerauswahl, Zusammenfassung) die benötigten Informationen zur Brieferstellung zusammengetragen.

Github-Repos

Um die unterschiedlichen Prototypen zu starten, benötigt man das Backend-Mock und die Repositories der jeweiligen Architektur. In den Repositories befinden sich README-Dateien als Anleitungen für die Installation und Ausführung der Anwendungen.

Backend-Mock:

RoCA Anwendungen:

SPA Anwendungen

Darin enthalten:

Links

Ansprechpartner