Neben Vertrieb und Marketing ist die Dokumentenverarbeitung ein Feld, auf dem gerade Versicherungen ihre Wettbewerbsposition verbessern wollen. Der Gerling-Konzern befasst sich zu diesem Zweck seit Jahren mit den Moeglichkeiten der optischen Speicherung. In der ersten Folge seines zweiteiligen Beitrags beschreibt Burkhard Bujotzek* das System, das in einer Abteilung des Lebensversicherers 1992 ans Netz ging.

*Burkhard Bujotzek ist Leiter der Abteilung Textverarbeitung und Archivsysteme in der Gerling-Konzern Gesellschaft fuer Informationsmanagement und Organisation mbH, Koeln.

Anfang der 80er Jahre fand der Gerling-Konzern den Weg zu einem CTV-System, mit dem Sachbearbeiter im Rahmen ihrer Vorgangsbearbeitung standardisierte Texte erzeugen koennen. Bis zu diesem Zeitpunkt waren allerorts Sekretariate und Schreibzimmer damit betraut, Briefe und individuelle Vertragsdokumente zu erstellen.

Das seit 1985 eingesetzte System schuf nicht nur die Moeglichkeit, die Arbeitsteilung bei der Textverarbeitung aufzuheben und Textdokumente ueber lokale Drucker spontan auszugeben, sondern es archiviert auch direkt die abgefassten Briefe und gewaehrleistet jederzeit inhaltlich originalgetreue Reproduktion ueber Bildschirm und Drucker. Logisch gebuendelt werden die Textdokumente ueber die Versicherungsnummern, wodurch sich jeweils automatisch eine elektronische Akte ergibt.

Zu Beginn konnten allerdings nur die mit CTV erstellten Texte archiviert werden, obwohl eine Reihe von DV-Systemen ablagerelevante Textdokumente vollmaschinell erzeugte. Diese Luecke wurde sukzessive geschlossen. Immer mehr DV- Systeme stellten ihre Textproduktion um, indem sie die zwischenzeitlich bereitgestellten Batch-Schnittstellen des CTV- Systems nutzten. So kann mittlerweile jeder legitimierte Mitarbeiter im Dialog auch die Texte der Akte lesen, die ein DV-Verfahren ohne menschliches Zutun automatisch produziert hat.

Derzeit sind 2,1 Millionen Dokumente archiviert und ueber jeden der zirka 4000 Bildschirme direkt greifbar. Es wird allerdings nicht jedes geschriebene Dokument archiviert, weil das rechtlich nicht erforderlich ist und das System ueber einen grossen Zeitraum hinweg nur nach und nach in den unterschiedlichen Fachbereichen des Konzerns eingefuehrt werden konnte. Zur Zeit erzeugen die Mitarbeiter, Sonderaktionen nicht eingerechnet, taeglich zirka 9000 Textdokumente, davon den groesseren Teil (ungefaehr 60 Prozent) ueber Batch-Anschluesse automatisch.

1984 pruefte man erstmals die Moeglichkeit, ein optisches Speichersystem einzusetzen, um auch die Eingangskorrespondenz der elektronischen Archivierung zuzufuehren. Der Erstanbieter solcher Systeme, Philips mit Megadoc, unterlag jedoch noch einer technischen Restriktion, die uns heute schon nostalgisch anmutet. Es war nicht moeglich, zeichenorientierte Daten und Images zugleich an einem physikalischen Schirm zu praesentieren. Folglich haette ein Mitarbeiter zwei Bildschirme auf seinem Arbeitsplatz haben muessen, ein in unseren Breiten eher unmoeglicher Zustand.

1989 begann zum zweiten Mal eine Marktsondierung unter der gleichen Fragestellung, doch diesmal mit gaenzlich anderem Ausgang. Die Zahl der Anbieter war nun beachtlich hoch, und schon die pragmatisch erforderliche Konzentration auf 15 von ihnen fiel nicht leicht.

Auch nach eingehender Bewertung der Angebote anhand des zuvor erstellten Anforderungskatalogs waren immerhin noch sieben Systeme im Rennen. Die Entscheidung fiel zugunsten der Firma Filenet, wodurch der Anbieter mit der groessten Praxiserfahrung siegte.

Am Anfang stand die Idee, Entwicklern und Anwendern einen weichen Uebergang in die neue Technologiewelt zu ermoeglichen. Doch aus dem Plan, die Arbeitsablaeufe zunaechst unveraendert zu lassen und erst nach Abschluss der Vorgangsbearbeitung die Dokumente dem Archivsystem via Scanner zuzufuehren, wurde nichts. Allen Beteiligten war klar, dass der wesentlichste Effekt in der radikalen Umgestaltung der Arbeitsablaeufe liegen wuerde. Die Entscheidungstraeger gaben den Entwicklern daher die Moeglichkeit, bereits fuer die erste Stufe der Systemnutzung den Scannvorgang vor den Bearbeitungsbeginn zu legen. Damit war nicht mehr papierlose Archivierung, sondern papierlose Sachbearbeitung das Ziel des Projekts.

Dieser Beschluss erforderte ein Redesign des Konzepts. Die Applikation musste um eine Reihe von Funktionen ergaenzt werden. Neben der elektronischen Akte als Uebersicht ueber die einem Vertrag zuzuordnenden Textdokumente galt es, den elektronischen Postkorb bereitzustellen. Er zeigt die zu bearbeitenden Dokumente und gibt darueber hinaus Auskunft ueber die Aktivitaeten, die zu dem jeweiligen Vorgang angefallen sind. Besonders komplex ist die Abbildung bislang konventionell abgewickelter Verteilungsfunktionen mit all ihren individuellen Aspekten (Unterschriftsvollmachten, Abwesenheit, Vertretungsregelungen, Dringlichkeitsfaelle). Hinzu trat der Wunsch nach einer Termin- und Schwebehaltung und nach Ergaenzung der Vorgangsinformationen um Kurznotizen.

Die Erweiterungen des Verfahrens um diese Elemente fuehrten naturgemaess zu einer deutlichen Steigerung des Entwicklungsaufwands. Sie hatten aber letztlich zum Ziel, die Arbeitsablaeufe betriebswirtschaftlich optimal zu gestalten. Mit der nunmehr geschaffenen Applikation ist es moeglich, die Bearbeitung zu beschleunigen und staendig eine optimale Auskunftsbereitschaft zu gewaehrleisten.

Einsatz in einer

neuen Abteilung

Die erste Applikation laeuft in einer neuen Abteilung der Lebensgesellschaft des Konzerns. Die Gruendung war erforderlich, weil ein neues Versicherungsprodukt verwaltet werden musste. Diese Rahmenbedingung hatte fuer das Projekt Vorteile. Jeder Mitarbeiter, der die Abteilung wechselt, weiss, dass sich seine bisherige Arbeitssituation aendern wird. Der Einsatz neuer Technologien in einer solchen Situation erscheint folglich viel natuerlicher und wird auch bereitwilliger angenommen. Andererseits musste die neue Abteilung die bestehende datentechnische und ablauforganisatorische Infrastruktur der Gesellschaften nutzen. Damit war die elektronische Archivierung nicht auf der gruenen Wiese, sondern in die gegebene organisatorische Umgebung zu integrieren.

Die Abteilung zaehlt derzeit 15 Mitarbeiter. Die Anwender sind ausnahmslos mit hochwertigen PCs ausgestattet. Laufzeittests vor dem Einsatz des Systems haben gezeigt, dass die erstellte Software auf 486er Prozessoren mit einer Taktfrequenz von 50 Hertz mit guter Performance laeuft. Die Programme werden zur Ausfuehrungszeit vom Unix- Server auf die Workstation uebertragen. Die Anwendung praesentiert sich unter Windows 3.1. Unter dem gleichen Betriebssystem ist die Host-Emulation eingebunden. Dies ermoeglicht es dem Anwender, parallel zur Aktenbearbeitung bestehende Host- Anwendungen zu nutzen (vgl. Abbildung 1).

Das Herzstueck der Anwendung wurde mittels der von Filenet bereitgestellten Software Workflo auf dem Unix-Server realisiert. Datenbasis ist eine Oracle-Datenbank, die beschreibende Informationen (Metadaten) ueber saemtliche Textdokumente beinhaltet. Sie ist logisch so strukturiert, wie es die aeusserst komplizierten Vertragsbeziehungen erfordern. So kann beispielsweise ein Kunde mehrere Vertraege besitzen, das heisst, Schreiben muessen mehreren Akten zugeordnet werden. Problematischer fuer die Archivierung sind solche Versicherungen, die Bestandteil von Vertraegen sind, die Firmen fuer ihre Mitarbeiter oder Verbaende fuer ihre Mitglieder abschliessen. Schriftstuecke koennen sich hierbei auf den einzelnen Vertrag, auf mehrere Vertraege und zusaetzlich auf den Rahmenvertrag beziehen. Die Ablage muss dementsprechend erfolgen (vgl. Abbildung 2).

Die Datenbank beinhaltet Metadaten zur Eingangspost, zur Ausgangspost und Termine. Die Eingangspost selbst liegt auf WORM- Platten, die sich in einer Jukebox befinden. Die Ausgangspost wird mit dem oben genannten CTV-System erzeugt und auf Magnetplatten des Mainframes archiviert. Die Notizen und Termine stehen ausschliesslich in der Datenbank, das heisst, die Metadaten verweisen (noch) nicht auf andernorts gespeicherte Textdokumente.

Neben der Datenbank werden im System diverse, vom Anwender zu bewirtschaftende Tabellen benutzt. Hiermit lassen sich insbesondere die automatischen Verteilungsalgorithmen steuern. So wird ein Posteingang, wenn er inhaltlich identifiziert werden konnte, automatisch an den zustaendigen Sachbearbeiter weitergeleitet. Umleitungen im Falle der Abwesenheit erfolgen ebenfalls automatisch.

Integrierter

Ablaufproze Die wesentlichen Arbeitsschritte sind das Scannen, das Indexieren und besonders die Bearbeitung ohne Papier. Das Scannen des Posteingangs ist eine originaere Funktion des Archivsystems und hat keine Beruehrungspunkte zu anderen Systemen. Beim Indexieren hingegen beginnt bereits der Bedarf nach Daten, die lediglich auf dem Host verfuegbar sind. Es gilt die Versicherungsnummer des Kunden zu ueberpruefen oder zu beschaffen. Je nach Organisation der Arbeitsverteilung koennen weitere Informationen erforderlich sein.

Besonders intensiv ist der Bedarf nach Einbettung des Archivsystems in die bestehende Systemlandschaft bei der Bearbeitung des Geschaeftsvorgangs selbst. Einerseits sind auch hier Daten erforderlich, die der Orientierung und Bewertung des Geschaeftsvorfalls dienen. Andererseits muessen die Applikationen genutzt werden, die auch bislang der technischen Abwicklung des Geschaeftsvorfalls dienten.

Die Nutzung der bestehenden Anwendungen erfolgt mittels der oben genannten Host-Emulation unter Windows. Dabei wurden die Workstations ausnahmslos direkt an den Host angeschlossen, da die Nutzungsfrequenz so hoch ist, dass ein Gateway kein Garant fuer gute Antwortzeiten war.

Fuer die Datenbeschaffung steht in der Kombination Filenet und SNI keine Programm-Programm-Verbindung analog LU6.2 zur Verfuegung. Hier konnte daher nur der Weg ueber eine Window- Window- Kommunikation helfen. Damit ist es moeglich, Daten von einem zum anderen Programm auf der Windows-Oberflaeche zu uebertragen, sofern die exakten Formate und Feldpositionen in einem entsprechenden Makro definierbar sind.

Dieser Weg hatte mehrere Nachteile. Einmal mussten fuer ein vom Benutzer gefordertes Workflo-Format Daten von den

diversen Anwendungssystemen beschafft werden. Um hier eine automatische Datenversorgung zu erreichen, haette Host-seitig eine ganze Reihe von Transaktionen abgewickelt werden muessen, was die Bearbeitungsfolge auf der Workstation stark behindert haette. Weiter wurden Daten gefordert, die nicht in bestehenden Formaten zu finden und somit nicht abgreifbar waren.

Aehnlich liegt das Problem bei Daten, die zwar in Formaten angezeigt werden, deren Position jedoch nicht verbindlich definierbar ist, weil das entsprechende Format einen variablen Aufbau hat. Das Problem wurde durch die Erstellung eines Servicebildes geloest, das als DialogSchnittstelle zwischen der Workstation-Anwendung und dem Host dient. Diese Schnittstelle ist fuer den Anwender nicht direkt nutzbar und auch nicht sichtbar. Das Format befindet sich auf dem Host und wird per Window-Window- Kommunikation durch ein Workflo-Programm aufgerufen. Dabei werden in einem variablen Bereich nach einer vereinbarten Syntax Datenanforderungen definiert, die dann das Host-Programm abwickelt. Das Ergebnis wird im gleichen Format zurueckgegeben. Auf diese Weise lassen sich nicht nur die genannten Probleme einer solchen Datenkommunikation umgehen, sondern es wird auch eine Unabhaengigkeit von Formataenderungen anderer Systeme erreicht (vgl. Abbildung 3).

Neben dem Datenaustausch im Dialog galt es noch einen File- Transfer zu realisieren, der der Oracle-Datenbank die Metadaten der CTV-Briefe uebertraegt. Da dieser File-Transfer in der Nacht nach dem Druck des Dokuments erfolgt, wird bereits beim Erstellen eines Briefes in CTV das Archivsystem darueber informiert. Ueber File-Transfer werden dann die Daten zum Beispiel um den Kurztext des Briefinhalts, Druckdatum, Autor etc. ergaenzt. Dass fuer das Archivsystem zwischen Dokumentenerstellung und File- Transfer bestimmte Besonderheiten gelten - etwa Verbot von Loeschen und Umnumerieren - ist ein weiteres Beispiel fuer die Interdependenzen der beiden Systeme.

Der Projektablauf soll verdeutlichen, wie schnell der sichere Boden der elektronischen Archivierung verlassen ist und welche Dimension selbst ein nur rudimentaeres Vorgangssystem aufweist. Rudimentaer muss es deshalb genannt werden, weil zunaechst nur die Funktionen behandelt wurden, die mit dem konventionellen Belegfluss verbunden sind. Eigentliche Vorgangsbearbeitung umfasst die standardisierte Ablauffolge saemtlicher Vorgangsfunktionen. Dieser Schritt steht noch bevor.

Systeme zur Vorgangssteuerung werden in den letzten Monaten im wachsenden Masse angeboten. Es scheint, dass ein neuer Boom ins Haus steht. Ob die Loesungen aber die Koordination diverser selbsterstellter Anwendungssysteme uebernehmen koennen, die ueberdies noch auf anderen technischen Plattformen ablaufen als die auf

PCs installierbaren Vorgangssysteme, erscheint zur Zeit mindestens fraglich.

Gerade deshalb ist es wichtig, jetzt Konzeptionen zu verabschieden, die die Anforderungen an ein Vorgangssystem und seine Abgrenzung von den Funktionen der Office-Anwendungen definiert. Nur so laesst sich gewaehrleisten, dass die Vorgangssteuerung nicht von den Faehigkeiten der Produkte bestimmt wird, sondern den Beduerfnissen der Organisation entspricht.

Abb. 1: Die Sachbearbeiter koennen parallel zur Arbeit am PC bestehende Host-Anwendungen nutzen.

Abb. 2: Ein- und ausgehende Briefe muessen teilweise mehreren

Akten zugeordnet werden.

Abb. 3: Die Workstation-Host-Schnittstelle ist fuer den Anwender nicht direkt zugaenglich.