Verteilte Geschäftsprozesse stellen einige Anforderungen, die durch traditionelle Softwaresysteme nur unzureichend unterstützt werden. Sie benötigen eine flexible informationstechnologische Infrastruktur: Softwarekomponenten und Middleware.
Inhalt des Projekts am Lehrstuhl für Softwaretechnologie der Universität Dortmund war zunächst die Bereinigung des Geschäftsprozesses, der dann durch ein Anwendungssystem unterstützt werden sollte. Der Prozeß regelt bei einem Dortmunder Versicherungsunternehmen den Ablauf von der Antragsannahme durch einen Versicherungsvertreter bis zur Ausstellung und Zusendung der Versicherungspolice an den Kunden. Er besteht aus vier Phasen: Antragserfassung, Vorprüfungen, Risikoprüfung und Freigabe.
Die Antragserfassung erledigen sogenannte Vermittler. Bisher konnten diese die Antragsdaten beim Kunden zwar mit einem Laptop und entsprechender Software aufnehmen und berechnen, mußten die Daten jedoch später von Hand auf ein Antragspapier übertragen. Mit der Kundenunterschrift wurde dieses Antragspapier per Post an die zuständige Geschäftsstelle geschickt und von dort nach einer Vorprüfung zur endgültigen Bearbeitung in die Hauptstelle weitergeleitet. Hier erst erfaßte man den handschriftlichen Antrag per Computer. Dieses geschah zudem doppelt, um Erfassungsfehler auszuschließen. Die nachfolgenden Bearbeitungsschritte erfolgten ebenfalls nur teilweise elektronisch.
Schnell kristallisierte sich für das Projektteam heraus, daß sich durch diese halbherzige elektronische Lösung keine Zeit bei der Erfassung gewinnen und keine Reduzierung des Papieraufkommens erreichen ließ. Weil die Übertragung der Antragsdaten nicht elektronisch unterstützt wird, sind bei der gesamten Bearbeitung viele Formulare in Papierform nötig; entsprechend lang sind die Bearbeitungszeiten und entsprechend hoch der Personalaufwand. Ein weiterer Schwachpunkt dieses Geschäftsprozesses ist, daß die Außendienstmitarbeiter dem Kunden gegenüber nur begrenzt aktuelle Auskünfte erteilen können, weil sich zu keiner Zeit auf aktuelle Daten zugreifen läßt.
Eine Verbesserung dieses Geschäftsprozesses unter Electronic-Commerce-Aspekten hatte daher zum Ziel, eine möglichst durchgängige elektronische Unterstützung zu realisieren und zugleich eine Bearbeitung an mehreren Orten zu gestatten.
Dazu wird der Teilprozeß "Antragserfassung" nun vollständig durch die Software unterstützt. Die Vermittler können bei Bedarf ihre Rechner mit dem Zentralrechner in der Hauptstelle verbinden und dort Daten abrufen oder einspielen. Zur Datenübertragung nutzt die Versicherung das Internet. Die Vermittler wählen sich bei einem Internet-Provider zum Ortstarif ein.
Die zweite Bearbeitungsphase, "Vorprüfungen", beginnt nun in der Hauptstelle bereits unmittelbar nach der Registrierung des elektronischen Datensatzes mit der Vergabe der Versicherungsnummer und anschließenden maschinell durchgeführten Routineprüfungen. Für diese Arbeiten wird die erst später eintreffende Papierversion des Antrags nicht benötigt. Somit verkürzt sich dieser Teil des Geschäftsprozesses zwar, doch solange noch kein Konzept einer digitalen Unterschrift allgemein verfügbar und akzeptiert ist, muß aus rechtlichen Gründen zusätzlich eine Papierversion des Antrags unterschrieben vorliegen.
Der dritte Prozeßabschnitt beinhaltet die Risikoprüfung, nach der ein Sachbearbeiter entscheidet, ob der Antragsteller angenommen oder abgelehnt, ein Anomalieangebot erstellt oder eine Arztanfrage gestartet werden soll.
Erfolgt die Freigabe, wird die Police gedruckt und verschickt. Das vorgeschlagene Softwaresystem kann sowohl den vorzugsweise per E-Mail durchgeführten Versand der ausgehenden Korrespondenz abwickeln als auch die Zuordnung eintreffender Antwortbriefe zu einzelnen Geschäftsvorfällen vornehmen. Darüber hinaus verfügt es über eine Terminüberwachung und kann Fristüberschreitungen für Antwortbriefe verfolgen.
Das Softwaresystem entstand auf der Basis von Applets, die in der Sprache Java 1.1.6 programmiert wurden. Dieser Aufbau unterstützt eine ortsungebundene Arbeitsverteilung. Die zugewiesenen Aufgaben lassen sich von den Sachbearbeitern unabhängig davon erledigen, ob sie sich an ei- nem Rechner in der Hauptstelle oder an einem remote mit dem Hauptrechner verbundenen Laptop anmelden. Bei der objektorientierten Analyse und dem Design des Systems wurden die Modellierungssprache UML und als Werkzeug "Rational Rose" eingesetzt.
Gegenüber lokalen Geschäftsprozessen haben verteilte Geschäftsprozesse veränderte Rahmenbedingungen. So muß etwa, um Zeit und Kosten zu sparen, der Datentransfer über einen ineffizienten Kommunikationskanal reduziert werden. Dazu schuf sich das Projektteam ein Ergänzungswerkzeug. Mit dem Tool lassen sich verteilte Geschäftsprozesse grafisch modellieren und simulieren. Dabei wird neben dem Geschäftsprozeß selbst auch die zugrundeliegende Kommunikationsinfrastruktur berücksichtigt.
Das Anwendungssystem basiert auf einer Architektur, deren Grundzüge vom Gesamtverband der Deutschen Versicherungswirtschaft (GDV) entwickelt wurden. Die Versicherungs-Anwendungsarchitektur (VAA) besteht aus den typischen Bestandteilen von Versicherungsanwendungen und standardisiert deren Schnittstellen.
Somit können auch einzelne Bestandteile von den Versicherungen oder von Fremdherstellern gekauft und in eigene VAA-konforme Systeme integriert werden. Viele Unternehmen orientieren sich an der Architektur. Deswegen erscheint es sinnvoll, auch Electronic-Commerce-Anwendungen auf dieser Grundlage aufzubauen. Um jedoch eine einfache Verteilung von Geschäftsprozessen sowie bessere Wartbarkeit zu erreichen, hat das Projektteam die VAA um objektorientierte und komponentenbasierte Konzepte erweitert. Es nennt seine Variante VAA++.
Die Architektur besteht aus den drei Schichten Steuerungs-, Anwendungs- und Dienstebene (siehe Abbildung "Schichtenarchitektur"). Die erste Änderung betrifft die Aufgaben des Daten-Managers. So dient er nun zur persistenten Speicherung von Objekten, die ihm von Anwendungsbausteinen (AWB) übergeben werden. Zusätzlich kann auf jedes Objekt nur noch von einem einzigen und nicht mehr von jedem beliebigen Anwendungsbaustein zugegriffen werden. Als Spezialist kann dieser leicht für die Konsistenz seiner Daten sorgen, wohingegen in der VAA die Konsistenz aller Systemteile beachtet werden mußte.
Die Zusammenarbeit der verschiedenen Anwendungsbausteine findet in der VAA++ nicht mehr über den Zugriff auf fremde Daten, sondern durch gegenseitige Nutzung der von den Bausteinen angebotenen Dienste statt. Diese gegenseitigen Aufrufe waren in der VAA nicht möglich, sie erlauben eine Kapselung des Wissens über die Kooperation in den betreffenden Anwendungsbausteinen selbst und befreien den Vorgangs-Manager davon.
Mit der Kapselung des Vorgangswissens und des Datenzugriffs in den Anwendungsbausteinen werden die Vorteile der Objektorientierung genutzt und spezialisierte Komponenten anstelle von allwissenden und schwierig wartbaren Systemteilen eingesetzt. Dies ermöglicht auch die flexible Verteilung auf mehrere Rechner.
Die Architektur gestattet es, die Anwendungsebene vollständig isoliert von Problemen der Verteilung zu modellieren. Alle Verteilungsprobleme der Architektur werden vollständig in der Steuerungs- und Dienstebene gelöst. So kann man sich beim Entwurf von Anwendungsbausteinen auf die fachlichen Aspekte konzentrieren (siehe Abbildung "Klassendiagramm Partner").
Auch beim Entwurf der Steuerungsebene legte man zunächst die Schnittstellen der Einzelkomponenten fest und modellierte anschließend deren internen Aufbau. Der Workflow-Manager steuert die kompletten Geschäftsprozesse. Der Vorgangs-Manager bearbeitet die einzelnen Teilschritte eines Workflows und arbeitet dabei mit den Anwendungsbausteinen, dem Daten- und dem Dialog-Manager zusammen.
Die Implementierung der für den beschriebenen Geschäftsprozeß benötigten Anwendungsbausteine verlief problemlos, da die Infrastrukturkomponenten der VAA++ wesentliche Aufgaben übernehmen, beispielsweise auch die Verteilung. Die Kommunikation zwischen den einzelnen Rechnern wird dabei per Remote Method Invocation (RMI) durchgeführt.
RMI verwaltet jedoch nur lokale oder fest angegebene Rechnernamen. Darum funktioniert das Konstrukt nur in der Richtung vom Client zum Server über RMI; denn hier läßt sich der Name des Zentralrechners beim Programmstart vorgeben, während ein Client im Internet bei jedem Start eine andere Adresse haben kann. Für die umgekehrte Richtung griff das Projektteam auf Sockets zurück.
Der Workflow-Manager läuft auf einem zentralen Server, während Vorgangs- und Dialog-Manager sowie die Anwendungsbausteine auf den Clients ausgeführt werden, um Rechenlast vom Server zu nehmen. In der gewählten Konfiguration werden die einzelnen Vorgänge eines Workflows auf den Clients gestartet, die sich im lokalen Netz oder irgendwo im Internet befinden können (siehe Abbildung "Client-Server-Kommunikation").
Durch die Verwendung von RMI oder Middleware wären aber auch andere Verteilungsszenarien denkbar. So ließen sich alle Vorgänge auf einem Server abarbeiten und nur die Dialoge auf den Clients. Bei Verwendung von Terminals statt PCs könnte auch der Dialog-Manager zentral laufen.
In der gewählten Ausführung kommuniziert auch der Daten-Manager per RMI und stellt seine objektorientierte Schnittstelle auf jedem Client zur Verfügung. Die Objekte können dabei sehr einfach zwischen Daten-Server und Clients ausgetauscht werden. Der Daten-Manager legt die Objekte in einer relationalen Datenbank ab und analysiert dazu zunächst mit den Java-Reflection-Methoden deren Aufbau. So lassen sich Datenbanktabellen mit allen benötigten Spalten automatisch erzeugen, und auf ein Datenbankdesign kann verzichtet werden.
Angeklickt
Der elektronische Handel mit Waren und Dienstleistungen sowie Electronic-Business als die elektronisch unterstützte Abwicklung von Geschäftsprozessen eröffnen der Versicherungswirtschaft neue Vertriebskanäle. Dies gilt zumindest für all jene Versicherungsprodukte, die nicht allzu erklärungsbedürftig sind und sich deshalb ohne persönliches Beratungsgespräch an den Mann bringen lassen. Doch Electronic Commerce erfordert neue Organisationsstrukturen, verteilte Geschäftsprozesse und eine flexible Infrastruktur. Zusammen mit einer Dortmunder Versicherung modellierte das Uni-Team um Volker Gruhn die Antragsbearbeitung von Lebensversicherungen neu.
*Volker Gruhn ist Professor an der Universität Dortmund am Lehrstuhl für Softwaretechnologie. Mitarbeiter des Projekts waren Thomas Bühren, Andreas Dombrowski, Sven Handschumacher, Markus Heller und Christian Lüer.