446 KB - GDV-Online Homepage
Werbung
Gesamtverband der Deutschen Versicherungswirtschaft e.V. Prozesse Objekte Funktionen Daten Komponenten Request Broker VA A E di t io n 1 9 9 9 Die Anwendungsarchitektur der Versicherungswirtschaft WORKFLOW -/ VORGANGSMANAGER VERSION 2.1 PROZEDURAL © GDV 1999 http://www.gdv.de/vaa Autoren: Das Projektteam "Workflowmanager" Administration, Koordination: Gesamtverband der Deutschen Versicherungswirtschaft e.V., Berlin http://www.gdv.de/vaa © GDV 1999 Workflow-/ Vorgangsmanager Willkommen bei VAA Edition 1999! Liebe Leserin, lieber Leser, haben Sie bereits eine der Broschüren der VAA Edition 1999 gelesen? Wenn ja, können Sie gleich weiter blättern, denn dieses Kapitel steht gleichlautend am Anfang jedes Dokuments dieser VAAEdition. Ansonsten freuen wir uns über Ihr Interesse an der VAA und gratulieren Ihnen zu Ihrer Entscheidung, sich mit diesem Thema zu beschäftigen, an dem wir seit Jahren mit großem Engagement und immer noch mit viel Spaß arbeiten. Mit WIR sind alle gemeint, die sich in den letzten Jahren direkt an der Arbeit in den VAA-Gremien beteiligten. Um wen es sich dabei im einzelnen handelt, können Sie in einem Anhang der Broschüre ANFORDERUNGEN UND PRINZIPIEN nachlesen, darüber hinaus werden die VAA-Gremien auf der neuen VAA-CD und im Internet (Adresse http://www.gdv.de/vaa) vorgestellt. Nun zur Sache: Die VAA wurde in den vergangenen zwei Jahren in zwei Richtungen weiterentwickelt. Der erste Schritt in Richtung Objektorientierung ist getan. Sie finden in der VAA Edition 1999 das OBJEKTORIENTIERTE FACHLICHE REFERENZMODELL RENZMODELL und das OBJEKTORIENTIERTE TECHNISCHE REFE- der VAA. Das Geschäftsobjekt PRODUKT wurde bereits detailliert ausgearbeitet. Die prozedurale Variante lebt weiter. Sie wurde ergänzt um eine weitere fachliche Komponente, INKASSO/KONTOKORRENT. Darüber hinaus wurden die aufgrund der Aufnahme der Objektorientierung notwendig gewordenen Überarbeitungen und Ergänzungen der Dokumente der 2. Auflage von VAA vorgenommen. Es entstand eine Vielzahl von zum Teil sehr umfangreichen Dokumenten, die auf drei Wegen veröffentlicht werden: CD-ROM, Internet und als gebundene Broschüren in Papierform. Um Ihnen die Orientierung zu erleichtern, haben wir als Übersicht über die verfügbaren Dokumentationen der VAA Edition 1999 einen grafischen Wegweiser erstellt, den Sie auf der nächsten Seite finden können. Vielleicht hilft er Ihnen, sich zurechtzufinden und Ihre Schwerpunktthemen "herauszufischen". Viel Spaß beim Studium des hier und in den übrigen Dokumenten zusammengestellten VAA-Wissens. © GDV 1999 http://www.gdv.de/vaa Workflow-/ Vorgangsmanager Dokumentenstruktur der VAA Edition 1999 Anforderungen und Prinzipien neu Glossar überarbeitet VAA prozedural (pVAA) Version 2.1 Prozeduraler Rahmen neu Fachliche Beschreibung Inkasso/Kontokorrent neu Partner Partner/Anhang Provision überarbeitet Schaden/Leistung Vertrag Technische Beschreibung Datenmanager Datenmanager/Anhang Dialogmanager Parametersystem Workflow-/Vorgangsmanager VAA objektorientiert (oVAA) Version 1.0 Objektorientiertes fachliches Referenzmodell Hauptdokument neu Anhang A – Use-Case-Modell – neu Anhang B – Klassenmodell – neu Modell in Rational-Rose-Format neu Objektorientiertes technisches Referenzmodell neu Produkt neu http://www.gdv.de/vaa © GDV 1999 Workflow-/ Vorgangsmanager I. Inhalt Abgrenzung und Wirkungsweise ....................................................................................... 3 I.1. I.1.1. Einleitung und Problemstellung ............................................................................................. 3 I.1.2. Ziele der Workflow-/Vorgangssteuerung ............................................................................... 4 I.1.3. Funktionale Anforderungen ................................................................................................... 5 I.1.4. Technische Anforderungen ................................................................................................... 5 I.1.5. Schnittstellenanforderungen ................................................................................................. 6 I.1.6. Sicherheitsanforderungen ................................................................................................... 10 I.2. Abgrenzung, Einschränkungen und offene Punkte ..................................................................... 10 I.2.1. Was gehört nicht zum Auftrag ............................................................................................. 10 I.2.2. Offene Punkte Liste............................................................................................................. 11 I.3. II. Beschreibung ................................................................................................................................ 3 Grundlegende Bauprinzipien und Algorithmen ............................................................................ 12 I.3.1. dynamisches Modell der Einbindung in die VAA ................................................................. 12 I.3.2. Beispiel für dynamisches Zusammenspiel der einzelnen Bestandteile ............................... 15 Formale Beschreibung und Schnittstellen ...................................................................... 17 II.1. Metamodell ................................................................................................................................. 17 II.1.1. Einleitung ............................................................................................................................ 17 II.1.2. Das Konfigurationsmodell zur Workflow-/Vorgangssteuerung ............................................ 18 II.1.3. Das operationale Modell der Workflow-/Vorgangssteuerung .............................................. 26 II.2. funktionale Anforderungen .......................................................................................................... 30 II.2.1. Organisationsmodellierung ................................................................................................. 30 II.2.2. Prozeßmodellierung ............................................................................................................ 30 II.2.3. Laufzeitfunktionen ............................................................................................................... 31 II.3. Workflownahe Dienste ................................................................................................................ 37 II.3.1. Termin- / Ereignisverwaltung .............................................................................................. 37 II.3.2. Organisationsverwaltung / Organisationsmodell (OM) ........................................................ 37 II.3.3. Transaktionsverwaltung ...................................................................................................... 39 II.4. III. Schnittstellen ............................................................................................................................... 39 Anhang ............................................................................................................................ 39 III.1. vorhandene Produkte und aktuelle Entwicklungen ................................................................. 39 III.1.1. vorhandene Produkte .......................................................................................................... 39 III.1.2. Standards und aktuelle Entwicklungen ............................................................................... 39 III.2. weitere Ausarbeitungen - Stoffsammlung ............................................................................... 39 III.2.1. Dokument - Dynamischer Ablauf von Geschäftsprozessen ................................................ 40 III.3. Termin- / Ereignisverwaltung .................................................................................................. 49 III.4. Organisationsverwaltung / Organisationsmodell (OM) ............................................................ 51 III.5. Transaktionsverwaltung. ......................................................................................................... 58 © GDV 1999 i Workflow-/Vorangssteuerung Abgrenzung und Wirkungsweise I. Abgrenzung und Wirkungsweise I.1. Beschreibung I.1.1. Einleitung und Problemstellung In Arbeitskreisen des GDV wurde bis 1995 die Struktur einer Versicherungsanwendungsarchitektur erarbeitet (VAA). Für die Strukturierung der technischen Architektur wurde eine Kontrollflußschichtung als Prinzip gewählt, welche die Ebenen Steuerungsebene, Arbeitsebene und Dienstebene umfaßt. Die Steuerungsebene besteht in dieser Struktur aus den Komponenten Workflow-Manager und DV-Vorgangssteuerung. Die Funktionalität dieser Komponenten wurde grob beschrieben. Für die detaillierte Beschreibung dieser Komponenten ist die Projektgruppe Workflow/Vorgangssteuerung gegründet wurden. Im Laufe der Projektarbeit stellte sich heraus, daß eine dritte Komponente in der Steuerungsebene benötigt wird, die Dialogsteuerung. Die Erarbeitung der benötigten Funktionalität der Dialogsteuerung wurde im Projekt „Präsentationsmanager“ vorgenommen, da die Dialogsteuerung als Teil des Präsentationsmanagers gesehen wurde und wird. Im folgenden Dokument werden also nur die Komponenten Workflow-Manager und DV-Vorgangssteuerung behandelt. Eventuelle Inkonsistenzen, die aus der Zuordnung der Dialogsteuerung in die Steuerungsebene resultieren, bedürfen noch der Überarbeitung Mit dem TITEL „Workflow“ beschäftigt sich heute eine Vielzahl von Arbeitsgruppen, Projekte, Studien und nicht zuletzt viele Anwender. Eine besondere Rolle spielen dabei die Arbeiten der Workflow Management Coalition (WfMC), der ein großer Teil der Hersteller von WorkflowSystemen und viele bedeutende Anwender angehören. Um die Definition der Aufgabenstellung zu erleichtern, wurde zunächst versucht, eine Einordnung der in der VAA definierten Teile der Steuerungsebene (Workflow-Manager und DVVorgangssteuerung) in das von der WfMC erarbeitete Workflow Reference Model vorzunehmen. Ziel war die Abgrenzung der Teile der VAA, welche nicht von den Funktionen der Workflow Engine der WfMC abgedeckt werden. Dabei zeigte sich, daß, bedingt durch die weltweite sowie hersteller- und branchenübergreifende Orientierung der WfMC, die dort erarbeiteten Definitionen häufig nur einen „kleinen gemeinsamen Nenner“ darstellen. Für eine Architektur, die sich primär an den Anforderungen der deutschen Versicherungswirtschaft orientiert, lassen sich z.T. wesentlich weitergehende Definitionen treffen. Diese sollten zu den innerhalb der WfMC getroffenen Definitionen „aufwärtskompatibel“ sein, da damit zu rechnen ist, daß eine große Zahl an Herstellern von Workflow-Systemen ihre Systeme zunächst an den Definitionen der WfMC ausrichten werden. Die Ausrichtung der VAA auf die Bearbeitung von Geschäftsprozessen ist eine sehr wichtige Designentscheidung. Sie fördert fachlich die durchgängige Unterstützung von Geschäftsprozessen durch Anwendungssysteme und erlaubt technisch die unabhängige Entwicklung von Softwarebausteinen in unterschiedlichen Unternehmen durch Einbindung in die Geschäftsprozeßsteuerung. Der Geschäftsprozeß wird definiert durch den Ablauf der einzelnen Teilprozesse. Falls notwendig, kann bis zum Elementarprozeß weiter untergliedert werden. Um die Teilprozesse durchzuführen, benötigt und erzeugt die durchführende Organisationseinheit Informationen. Diese werden von Menschen oder Programmen bearbeitet. Dafür benötigen sie Informationen und Regeln. Die einzelnen Teilprozesse können an verschiedenen Orten zu unterschiedlichen Zeiten von verschiedenen Programmen oder Personen bearbeitet werden. Die Workflow-/Vorgangssteuerung steuert dabei den Arbeitsfluß zwischen allen beteiligten Personen und Teilprozessen. © GDV 1999 3 Abgrenzung und Wirkungsweise Workflow-/ Vorgangsmanager Dazu gehören insbesondere die Verteilung einzelner Arbeitsschritte auf die Organisationseinheiten und die Steuerung der zeitlichen Abfolge eines Geschäftsprozesses (inklusive Terminsteuerung). Die Workflow-/Vorgangssteuerung deckt dabei sowohl den Bereich der unstrukturierten wie auch der strukturierten Prozesse ab und übernimmte folgende Funktionen: Steuerung der Geschäftsprozesse sowie der Teilprozesse innerhalb eines Geschäftsprozesses bis hin zu den Anwendungsbausteinen Kommunikation / Datenaustausch / Datenzuordnung zwischen Geschäfts- und Teilprozeß Zuständigkeits-, Berechtigungs- und Freigabeprüfungen Bereitstellung von Arbeits- und Postkorbfunktionen Historisierung und Archivierung von Geschäftsprozessen Geschäftsprozeß geregelte Teilprozesse Ereignis Ergebnis Arbeitskorb mit Informationen und Nachrichten Abbildung I.1: Fachliche Sicht eines Geschäftsprozesses I.1.2. Ziele der Workflow-/Vorgangssteuerung I.1.2.1. Unterstützung einer kundenorientierten Verarbeitung Auf der fachlichen Seite ermöglicht Workflow die Kontrolle/Übersicht über eine Geschäftsprozeß ab Bekanntwerden eines Kundenwunsches im Unternehmen, ggf. sogar ab erster Kontaktaufnahme und Akquisition des Vermittlers. In diesem Zusammenhang sollen mit dem Einsatz von Workflow folgende Ziele erreicht werden: ständige Auskunfts-/Service-Bereitschaft gegenüber dem Kunden durch Führen einer Historie zu allen abgeschlossen und laufenden Geschäftsprozessen eines Kunden (Verträge, Ablehnungen, Schäden, Hypotheken, Mahnungen usw.) schnellere Bearbeitung von Kundenwünschen durch Vermeidung/Reduzierung von internen Laufzeiten und Zugriffszeiten auf Dokumente Unterstützung der „Sachbearbeitung in einer Hand“ durch Bereitstellen einer entsprechenden technischen Infrastruktur (Zugriff auf Dokumente aller Art (z.B. in Archiven) von jedem Arbeitsplatz aus, Transparenz der Geschäftsprozeßbearbeitung) Unterstützung von strukturierten und unstrukturierten Prozessen (Die heutige Unterstützung der Sachbearbeitung im VU ist fast ausschließlich durch die Abbildung starr strukturierter Prozesse realisiert. Bei Prozessen mit unmittelbarem Kundenkontakt wird dies nicht immer möglich sein.) 4 © GDV 1999 Workflow-/Vorangssteuerung Abgrenzung und Wirkungsweise I.1.2.2. Integration von Organisation und Informationsverarbeitung Auf der organisatorischen Seite ermöglicht Workflow eine verbesserte Integration von Organisation und Informationsverarbeitung. In diesem Zusammenhang sollen mit dem Einsatz von Workflow flexible Möglichkeiten zur Änderung von Ablauf- und Aufbauorganisation erreicht werden: durch die unmittelbare Umsetzung der organisatorische Gestaltung von Geschäftsprozessen (z.B. Zuordnung von Teilprozessen zu ausführenden Stellen) in eine DV-technische Steuerung durch die technische Unterstützung für die Einhaltung organisatorischer Regeln (z.B. Weiterleitung von Dokumenten an die richtigen Stellen, Einhaltung von Fristen und Terminen) durch die Möglichkeiten Überwachung und Analyse von Geschäftsprozessen I.1.2.3. Trennung von Ablauflogik und Anwendungslogik Auf der technischen Seite ermöglicht Workflow als Steuerungsebene die Trennung von Ablaufund Anwendungslogik Dadurch können folgende Ziele erreicht werden: Modularisierung der Software Integration von Softwarebausteinen, die von unterschiedlichen Unternehmen entwickelt werden können durchgängige maschinelle Unterstützung von Geschäftsprozessen I.1.3. Funktionale Anforderungen Die Steuerungsebene übernimmt in der VAA die Steuerung der Geschäftsprozesse. Dies beinhaltet zum einen „klassische“ Workflow-Funktionen wie Zu- und Weiterleitung Protokollierung Ermittlung von Zuständigkeiten anhand gegebener Organisationsmodelle Termin- und Ereignisverwaltung, zum anderen anwendungssteuernde Funktionen wie Ermittlung der nächsten zu startenden Anwendung Unterstützung eines Transaktionskonzeptes Ermöglichen von Unterbrechung / Abbruch. Einige Funktionen (wie z.B. Termin- und Ereignisverwaltung) können dabei zum einen als Funktion der Steuerungsebene implementiert werden, sie können aber auch über Dienstsysteme realisiert werden, wobei die Steuerungsebene dann diese Dienste nutzen können muß. Eine detaillierte Auflistung der funktionalen Anforderungen an die Workflow/Vorgangssteuerung findet sin in Kapitel II.3. I.1.4. Technische Anforderungen Zunächst beinhalten die technischen Anforderungen an die Steuerungsebene diejenigen Anforderungen, die bezüglich Interoperabilität Portierbarkeit Konfigurierbarkeit © GDV 1999 5 Abgrenzung und Wirkungsweise Workflow-/ Vorgangsmanager Plattformunabhängigkeit an die VAA insgesamt gestellt werden. Zusätzlich sind von der Workflow-/Vorgangssteuerung folgende Anforderungen zu erfüllen: Ermöglichen der Integration von nicht-VAA-konformen Anwendungen. Dies bedeutet, daß er neben dem DV-Vorgang auch die Möglichkeit bieten muß, andere Anwendungen anzusteuern. Die Workflow-/Vorgangssteuerung übernimmt damit bei der Migration zu einer VAA eine zentrale Rolle. Eine Zusammenarbeit mehrerer, evtl. auf verschiedene Lokalitäten verteilter WorkflowManager muß möglich sein. Die Art und Weise der Zusammenarbeit orientiert sich an den von der Workflow Management Coalition (WfMC) definierten Interoperabilitätsleveln. Eine Minimalanforderung ist hier die Unterstützung des Levels 3. Dieses Level besagt, daß es möglich sein muß, eingebettete Teile von Geschäftsprozessen (Teilprozesse) vollständig von einer anderen Workflow-Steuerung ausführen zu lassen, wobei diese die Kontrolle nach der vollständigen Ausführung des Teilprozesses an die rufenden Workflow-Steuerung zurückgibt. Der Workflow-Manager kann eine Reihe von workflow-nahen Diensten wie Terminverwaltung, Benutzerverwaltung usw. enthalten, muß aber auch in der Lage sein, diese Dienste, wenn sie bereits vorhanden sind, zu benutzen. Diese Anforderung resultiert aus der Tatsache, daß es in vielen Unternehmen diese oder ähnliche workflownahe Dienste bereits gibt und nicht im Rahmen der Einführung eines Workflowsystems vergleichbare Dienste ein zweites Mal installiert werden sollen. Andererseits muß beim Nichtvorhandensein dieser Dienste der Workflowmanager diese Dienste bereitstellen. Zusätzlich ergeben sich Anforderungen bzgl. Performance und Durchsatz, die aus den Mengen der zu verarbeitenden Geschäftsprozesse resultieren: Sicherstellung von für den Benutzer akzeptablen Antwortzeiten. Zu beachten ist, daß diese Antwortzeiten nur z.T. von der DV-Vorgangssteuerung beeinflußt werden können. Den größeren Einfluß haben die Anwendungsbausteine selbst sowie andere Komponenten der Architektur wie z.B. der Datenmanager. Ermöglichen eines Durchsatzes von mehreren Millionen DV-Vorgängen (auch des gleichen Typs) pro Tag in einem System. I.1.5. Schnittstellenanforderungen Im folgenden erfolgt ein Überblick über die verschiedenen Schnittstellen der Steuerungsebene. Eine Beschreibung der Schnittstellen erfolgt in Kapitel II.3. 6 © GDV 1999 Workflow-/Vorangssteuerung Abgrenzung und Wirkungsweise I.1.5.1. Schnittstellen der Steuerungsebene Dienstebene 1 Workflow-Manager Termin-/Ereignisverwaltung 2 Organisationsverwaltung 6 DV-Vorgangssteuerung 3 Benutzerverwaltung 4 Transaktionsverwaltung 7 Dialogsteuerung 5 8 Dokumentenveraltungssystem Arbeitsebene Anwendungs Anwendungs baustein 1 baustein 2 Welche Schnittstellen in einer konkreten Implementierung einer VAA-konformen Workflow/Vorgangssteuerung benötigt werden, ist auch abhängig von deren innerer Struktur. So muß ein Workflow-System, welches eine Benutzerverwaltung enthält, nicht unbedingt auch eine Schnittstelle zu einer externen Benutzerverwaltung enthalten. Ziel sollte allerdings sein, daß ein VAAkonformes Workflow-/Vorgangssteuerungssystem diese Schnittstellen alle bietet, da nur dann eine optimale Konfigurierung möglich ist. Folgende Schnittstellen sind erforderlich: Schnittstelle 1 Workflow-Manager - Termin-/Ereignisverwaltung Schnittstelle 2 Workflow-Manager - Organisationsmodell Schnittstelle 3 Workflow-Manager - Benutzerverwaltung Schnittstelle 4 Workflow-Manager - Transaktionsverwaltung Schnittstelle 5 Workflow-Manager - Archivsystem Schnittstelle 6 Workflow-Manager . DV-Vorgangssteuerung © GDV 1999 7 Abgrenzung und Wirkungsweise Workflow-/ Vorgangsmanager Schnittstelle 7 DV-Vorgangssteuerung - Dialogsteuerung Schnittstelle 8 Workflow-Manager - Dialogsteuerung I.1.5.2. Schnittstellen der Steuerungsebene mit anderen Komponenten Neben den Schnittstellen innerhalb der Steuerungsebene existieren eine Reihe von Schnittstellen der Komponenten der Steuerungsebene mit anderen Komponenten der VAA. Dies sind insbesondere Schnittstellen zu Anwendungsbausteinen zum Datenmanager zu den workflownahen Diensten zu sonstigen Diensten und Dienstsystemen. Diese Schnittstellen werden z.T. bei der Definition der jeweligen Komponenten (z.B. Anwendungsbausteinen) beschrieben. 8 © GDV 1999 Workflow-/Vorangssteuerung Abgrenzung und Wirkungsweise I.1.5.3. Schnittstellen des Workflow Reference Models Analyse / Design / Simulation Aufbau- und Ablauforganisation Berechtigung / Freigabe / Zuständigkeit Interface 1 Kommunikationsdienste Administration Statistik Workflow Manager Workflow Manager Interface 5 Interface 4 Interface 2 Interface 3 Kommunikationsdienste Arbeitskorb Postkorb MIS DV-Vorgangs-Steuerung Altanwendungen Bei den Arbeiten zum TITEL Workflow-/Vorgangssteuerung war es häufig erforderlich, auch andere aktuelle Entwicklungen zu berücksichtigen. Insbesondere trifft dies für die Arbeiten der Workflow Management Coalition zu, die ein Wokflow Reference Model entwickelt und veröffentlicht hat. Die Grafik soll eine mögliche Einordnung der VAA-Komponenten in dieses Workflow Reference Model zeigen. Ebenso wurden im Rahmen der WfMC verschiedene Interoperabilitätslevel für die Zusammenarbeit mehrere Workflowsysteme untereinander definiert. Ein VAA-konformes Workflow-System muß mindestens dem dort definierten Model 2 - Hierarchical - entsprechen. Dies bedeutet, daß es möglich sein muß, einen Teilprozeß innerhalb eines Geschäftsprozesses komplett von einem anderen WF-System auf einem andere Server ausführen zu lassen. Die dafür benutzte Schnittstelle ist das Interface 4 im Workflow Reference Model. Die Grafik verdeutlicht die Einordnung der Workflow-/Vorgangssteuerung (grau unterlegter Bereich) in das Workflow Reference Model. Dabei wird deutlich, daß ein Teil der Workflow/Vorgangssteuerung, nämlich der Workflowmanager, in diesem Modell der Workflow Engine der WfMC entspricht, während es für die DV-Vorgangssteuerung keine korrespondierende Komponente in diesem Modell gibt. D.h., daß die Aufgaben der DV-Vorgangssteuerung im Workflow Reference Model von den jeweiligen Anwendungen (Invoked Applications) übernommen werden müssen. © GDV 1999 9 Abgrenzung und Wirkungsweise Workflow-/ Vorgangsmanager I.1.6. Sicherheitsanforderungen Die Sicherheitsanforderungen sind getrennt zu betrachten in Anforderungen an die Datensicherheit und Anforderungen an den Datenschutz. Dabei bezeichnet Datensicherheit alle Maßnahmen zum Schutz der Daten vor Verlust im Fehlerfall, während unter Datenschutz alle Maßnahmen zum Schutz der Daten vor unberechtigtem Zugriff verstanden werden. Für Datensicherheit und Datenschutz der von der Steuerungsebene aktivierten Anwendungen sind diese Anwendungen grundsätzlich selbst verantwortlich. Die beschriebenen Anforderungen gelten ausschließlich für die Daten, welche die Komponenten der Steuerungsebene verwalten. I.1.6.1. Datensicherheit Grundsätzlich gelten an die Daten der Steuerungsebene die gleichen Anforderungen bzgl. der Datensicherheit wie an DV-Systeme ganz allgemein. Dies bedeutet, daß die Daten im Falle von Abbrüchen und Systemausfällen wiederherstellbar sein müssen. Als besondere Anforderung ist zu beachten, daß im Falle der Rücksetzung von Daten auf den letzten konsistenten Stand eine Synchronisation mit den anwendungsbezogenen Daten erfolgen muß. Bsp.: Wenn im Falle eine Systemabsturzes die noch nicht persistenten Daten des Anwendungsbausteines „Kunden anlegen“ verlorengegangen sind, muß die DV-Vorgangssteuerung dafür sorgen, daß dieser Anwendungsbaustein erneut aufgerufen wir, auch wenn sie ursprünglich die Abarbeitung dieses Anwendungsbausteines bereits protokolliert hatte. I.1.6.2. Datenschutz Der Schutz der Anwendungsdaten vor unberechtigtem Zugriff obliegt der jeweiligen Anwendung. Zusätzlich ist (über die Rollenbeschreibung) zur Prozeßdefinition hinterlegt, wer in einem Prozeß mit welchen Teilprozessen welche Aktivitäten ausführen darf. Darüberhinaus unterliegen auch die Daten welche von den Komponenten der Steuerungsebene verwaltet werden, insbesondere Daten, die den Verlauf von Geschäftsprozessen protokollieren, besonderen Anforderungen an den Datenschutz. Diese Daten müssen aus Gründen der Revisionssicherheit vor nachträglichen Änderungen geschützt werden, um den Verlauf der Bearbeitung eines Geschäftsprozesses ständig lückenlos und fehlerfrei dokumentieren zu können. I.2. Abgrenzung, Einschränkungen und offene Punkte I.2.1. Was gehört nicht zum Auftrag Aufgabe der Projektgruppe ist die Beschreibung und Definition der Komponenten der Steuerungsebene innerhalb der VAA. Folgenden Punkte sind nicht Gegenstand des Projektes und damit auch nicht in dieser Ausarbeitung enthalten: I.2.1.1. Methodik der Prozeßmodellierung Es ist nicht Aufgabe des Projektes, eine Methode zur Prozeßmodellierung zu entwickeln oder vorhandene Methoden zu untersuchen und zu bewerten. Für die Beschreibung der Funktionalität der Workflow-/Vorgangssteuerung ist es jedoch erforderlich, von einem konkreten Metamodell auszugehen, da die dort möglichen Definitionen von den Steuerungskomponenten umgesetzt werden müssen. Da die Modellierung von Geschäftsprozessen letztlich dazu dient, eine Prozeßbeschreibung in der Form eines solchen Metamodells zu erzeugen, besteht indirekt eine Verbindung zur Prozeßmodellierung. Sämtliche Angaben zur Prozeßmodellierung in diesem Dokument, insbesondere auch die Konstrukte zur graphischen Notation von Geschäftsprozeßdefinitionen, sind als Beispiele zur Verdeutlichung von Sachverhalten zu verstehen und nicht als Vorgabe des Projektes. Eine Vorgabe für eine Methodik zur Prozeßmodellierung ist insbesondere auch deshalb nicht sinnvoll, da es für die Prozeßmodellierung keinen anerkannte Standardmethode (vergleichbar 10 © GDV 1999 Workflow-/Vorangssteuerung Abgrenzung und Wirkungsweise der ER-Methode bei der Datenmodellierung) gibt. Vielmehr wird die Art und Weise der Prozeßmodellierung sehr von den Zielen bestimmt, die mit der Modellierung verfolgt werden. I.2.1.2. Modellierung konkreter fachlicher Prozesse Die Modellierung konkreter fachlicher Prozesse ist ebenfalls nicht Gegenstand des Projektes. Sollte dies überhaupt innerhalb VAA erfolgen, müßte es innerhalb der jeweils zuständigen Fachprojekte geschehen. Darüberhinaus ist ein Grundsatz von VAA, daß es die Architektur den einzelnen Versicherungsunternehmen ermöglichen muß, ihre unternehmensspezifischen Prozesse zu definieren und auch abzuarbeiten, da sich darin die konkrete Unternehmensphilosophie widerspiegelt und die Gestaltung der Geschäftsprozesse für ein VU eine wesentliche Möglichkeit zur Erlangung von Wettbewerbsvorteilen ist. Prozeßdefinitionen in diesem Dokument sind daher immer nur als Beispiel zu verstehen, die einen Sachverhalt verdeutlichen sollen. Sie erheben insbesondere keinen Anspruch auf fachliche Richtigkeit und Vollständigkeit. I.2.1.3. Plattformübergreifende Kommunikation Ein typisches Merkmal von Workflow-Systemen ist die Abwicklung von Geschäftsprozessen über verschiedene Lokalitäten und Plattformen hinweg. Daraus ergeben sich Probleme der Kommunikation der Workflow-Steuerung mit den jeweiligen Anwendungen. Diese Probleme zu lösen, ist die Aufgabe eines VAA-Dienstes, des Kommunikationsdienstes. Insofern werden derartige Probleme hier nicht betrachtet. I.2.2. Offene Punkte Liste I.2.2.1. Deterministische vs. Ad-hoc-Abläufe Bei den Betrachtungen zur Steuerungsebene wurden primär modellierte Geschäftsprozesse betrachtet, die aufgrund einer Prozeßdefinition deterministisch abgearbeitet werden. Sogenannte Ad-hoc-Geschäftsprozesse, welche keinen vorher definierten Ablauf haben, wurden nur am Rande betrachtet. Inwieweit die Durchführung von Ad-hoc-Geschäftsprozessen zusätzliche Anforderungen an eine Workflow-/Vorgangssteuerung stellt, wurde nicht betrachtet. Aus heutiger Sicht wird für derartige Geschäftsprozesse lediglich eine Teilfunktionalität der Workflow-/Vorgangssteuerung benötigt. I.2.2.2. Dokumentenverwaltungssystem Viele am Markt erhältliche Workflow-Systeme beinhalten eine Komponente zur Dokumentenverwaltung / Archivierung. Dies ist zum einen historisch bedingt (viele Workflow-Systeme sind aus Image-/Archivierungssystemen hervorgegangen), zum anderen auch durch den engen fachlichen Zusammenhang von Geschäftsprozeßsteuerung und Dokumentenverwaltung. Innerhalb der VAA ist die Dokumentenverwaltung / Archivierung nicht Aufgabe der Workflow/Vorgangssteuerung, sondern ist ein eigenes Dienstsystem. Durch die besondere Bedeutung von Dokumenten bei der Abarbeitung von Geschäftsprozessen soll der Workflow-Manager Schnittstellen bereitstellen, über die er mit einem Dokumentenverwaltungssystem kommunizieren kann. Insbesondere müssen existierende oder in Entwicklung befindliche Standards berücksichtigt werden (siehe Anhang - vorhandene Produkte und Entwicklungen). Ein in diesem Zusamenhang wesentlicher Punkt ist die Schnittstellenproblematik. Folgende Fragen müssen betrachtet und beantwortet werden: Erfolgt der Zugriff auf im Dokumentenverwaltungssystem gespeicherte Dokumente mittels des Datenmanagers, oder bleibt dies dem jeweiligen Dokumentenverwaltungssystem überlassen. Erfolgt die Darstellung von Dokumenten (Images) ebenfalls mittels des Präsentationsmanagers. © GDV 1999 11 Abgrenzung und Wirkungsweise Workflow-/ Vorgangsmanager I.3. Grundlegende Bauprinzipien und Algorithmen I.3.1. dynamisches Modell der Einbindung in die VAA I.3.1.1. Rückblick Im Konzept VAA V1.0, welches im Oktober 1995 veröffentlicht wurde, wurde die Steuerungsebene in die Komponenten Workflow-Manager und DV-Vorgangssteuerung aufgeteilt. Damit verbunden war eine Aufteilung der Funktionalität auf die beiden VAA-Komponenten. Dem Workflow-Manager wurden in diesem Zusammenhang die „klassischen“ Workflow-Funktionen zugeordnet wie Weiterleitung Protokollierung Ermittlung von Zuständigkeiten anhand Rollen-/Orgadefinitionen, während der DV-Vorgangssteuerung die Funktionen zur Anwendungssteuerung wie Ermittlung und Aufruf des nächsten Anwendungsbausteins Ermittlung und Aufruf von Dialogen Sicherstellung des Konzepts fachlicher Transaktionen (ein DV-Vorgang kann nur ganz oder gar nicht wirksam werden und bildet damit eine Logical Unit of Work (LUW)) zugeordnet wurden. Mit dieser Aufteilung verbunden war die Annahme, daß bei der Definition von Geschäftsprozessen explizit (d.h. durch denjenigen, der den Prozeß definiert), eine Unterteilung eines Geschäftsprozesses in DV-Vorgänge erfolgt. Daraus resultierten allerdings Einschränkungen bzgl. der Flexibilität bei der Prozeßdefinition, die zum Überdenken der o.g. Aufteilung in der Projektgruppe führten. Eine Konsequenz aus dieser Aufteilung war beispielsweise, daß, da die DVVorgangssteuerung keine Funktionen zur Ermittlung von Zuständigkeiten / Berechtigungen enthielt, ein DV-Vorgang insgesamt immer einer bearbeitenden Orga zugeordnet war. Eine weitere Festlegung besagte, daß ein DV-Vorgang einer LUW entspricht. Aufgrund dieser Einschränkungen war es z.B. nicht möglich, Teile eines Geschäftsprozesses, die von mehreren Bearbeitern erledigt werden müssen, zu einer LUW zusammenzufassen, was aber fachlich durchaus eine sinnvolle Forderung sein kann. I.3.1.2. Heutiger Stand Zur Vermeidung dieser Einschränkungen wurden folgende Annahmen getroffen: Eine explizite Definition einer Ebene „DV-Vorgang“ bei der fachlichen Modellierung eines Geschäftsprozesses ist nicht sinnvoll. Ebenso ist es nicht sinnvoll, Eigenschaften wie „wird von einem Bearbeiter bearbeitet“, „bildet eine LUW“ miteinander zu verknüpfen, indem sie dem DVVorgang zugeordnet werden. Andererseits ist eine Aufteilung der Steuerungsebene in die Komponenten Workflow-Manager und DV-Vorgangssteuerung aufgrund der Tatsache, daß die DV-Vorgangssteuerung nur einn Teil der Funktionalität der Steuerungsebene benötigt, sowie aufgrund unterschiedlicher Anforderungen bzgl. Performance, Durchsatz usw. sinnvoll. Damit besteht auch die Notwendigkeit, DV-Vorgänge zu definieren. Dies sollte in einem auf die fachliche Modellierung folgenden , zweiten Schritt erfolgen, bei dem sozusagen ein technisches Prozeßmodell entsteht, eine fachlicher Geschäftsprozeß also in eine konkrete technische Umgebung abgebildet wird. Folgende Eigenschaften sind kennzeichnend für einen DV-Vorgang: Ein DV-Vorgang bildet einen Teil eines Geschäftsprozesses in eine DV-Umgebung ab. Dieser ist Teil eines Prozeßmodells. Welche Teilprozesse als ein DV-Vorgang abgebildet werden können, leitet sich aus den folgenden Punkten ab, die eine Abgrenzung „nach oben“ vornehmen.. Ein DV-Vorgang ist nicht die kleinste Einheit im Prozeßmodell. Er erscheint im fachlichen Modell nicht, sondern erst bei der Übertragung dieses fachlichen in ein technisches Modell. 12 © GDV 1999 Workflow-/Vorangssteuerung Abgrenzung und Wirkungsweise Der interne Ablauf eines DV-Vorgangs wird nicht vom Workflow-Manager protokolliert. Dies bedeutet, daß der Workflow-Manager zur Laufzeit mit DV-Vorgängen arbeitet. Wird ein Teilprozeß von einem DV-Vorgang umgesetzt, gelten für diesen Teilprozeß folgende Einschränkungen: Er darf keinen definierten Rollenwechsel enthalten. Das heißt, daß ein DV-Vorgang grundsätzlich von einem Bearbeiter bearbeitet werden kann. Innerhalb des Teilprozesses gibt es keine Termin- oder Ereignisabhängigkeiten. D.h., daß ein DV-Vorgang grundsätzlich zusammenhängend bearbeitet werden kann. Dieser Teilprozeß gehört immer zu einer LUW (Logical Unit of Work) Ein DV-Vorgang wird zur Laufzeit als ein „Work-Item“ dem Sachbearbeiter gegenüber präsentiert. Die Steuerung eines DV-Vorgangs erfolgt auf einem System / Server. Dies bedeutet nicht, daß sämtliche Anwendungsbausteine, die in diesem DV-Vorgang eingebunden sind, auch auf diesem System laufen müssen. Die o.g. Definitionen geben allerdings lediglich Restriktionen an, die sich für die Definition von DV-Vorgängen ergeben. Die endgültige Festlegung, welcher Teilprozeß als ein DV-Vorgang abgearbeitet wird, ist eine Designentscheidung, welche nach der Definition des fachlichen Modells des Geschäftsprozesses getroffen werden muß. Als Konsequenz daraus hat ein Geschäftsprozeß ein fachliches Modell, welches nur Teilprozesse kennt, und ein daraus abgeleitetes technisches Modell, in welchem u.a. die Definition von DV-Vorgängen und die Zuordnung der konkreten Anwendungsbausteine und Dialoge zu den Teilprozessen auf unterster Ebene erfolgt. Die Dialogsteuerung ist ein Teil des Präsentationsmanagers und Bestandteil der Steuerungsebene. Die Dialogsteuerung wird von der DV-Vorgangssteuerung immer dann aktiviert, wenn ein Elementarprozeß durch einen Dialog umgesetzt wird. Neben Anwendungen, die im Rahmen von Geschäftsprozessen laufen, gibt es auch Anwendungen, die nicht zu einem fachlichen Geschäftsprozeß gehören, trotzdem aber nach den Prinzipien der VAA aufgebaut sein sollen, d.h. aus Anwendungsbausteinen und Dialogen bestehen. Diese Anwendungen benötigen ebenfalls nur einen Teil der Funktionen der Steuerungsebene, nämlich die anwendungssteuernden Funktionen, während Funktionen wie Weiterleitung, Terminsetzung usw. nicht benötigt werden. Ein Beispiel für eine solche Anwendung ist eine Postkorbanwendung. Aber auch Auskunftsanwendungen oder allgemeine Systeme wie Textverarbeitungen können außerhalb von fachlichen Geschäftsprozessen laufen. Die Aufteilung der Steuerungsebene innerhalb der VAA in die Komponenten WorkflowSteuerung und DV-Vorgangssteuerung erscheint sinnvoll. Inwieweit bie einem konkreten Produkt Workflow-Manager und DV-Vorgangssteuerung als ein oder als zwei Softwarebausteine realisiert sind, bleibt dem jeweiligen Hersteller überlassen. Bei der Realisierung in einem Baustein ist es jedoch erforderlich, daß die speziellen Anforderungen hinsichtlich Performance usw. an die DV-Vorgangssteuerung beachtet werden. I.3.1.3. Einbindung von Dialogen Für den Benutzer sichtbar ist eine Anwendung immer dann, wenn innerhalb eines Geschäftsprozesses oder einer anderen Anwendung ein Teilprozeß durch einen Dialog abgearbeitet wird. Man muß also beim Begriff des Dialoges unterscheiden zwischen dem Dialog aus Sicht des Benutzers und einem Dialog aus VAA-Sicht. Den Dialog aus VAA-Sicht könnte man auch als Dialogbaustein- bezeichnen, was dem Charakter des VAA-Dialoges besser entsprechen würde. Aus Sicht des Benutzers ist i.A. alles, was er in einem zeitlichen Zusammenhang zu einem Geschäftsprozeß erledigt, ein Dialog. So ist beispielsweise die Bearbeitung eines Angebotes aus Benutzersicht ein Dialog, während aus VAA-Sicht z.B. die Dialoge „Partner erfassen“, „Angebot erstellen“ und „Ausdruck bearbeiten“ als drei Dialoge enthalten sein könnten. Aus Sicht VAA sind also in diesem Fall evtl. mehrere Dialoge aktiv gewesen, dazwischen haben die DVVorgangssteuerung und evtl. auch der Workflow-Manager die Kontrolle bekommen. Ein Dialog © GDV 1999 13 Abgrenzung und Wirkungsweise Workflow-/ Vorgangsmanager ist aus Sicht der DV-Vorgangssteuerung lediglich eine (abgegrenzte) Arbeitseinheit, die durch die Daten gekennzeichnet ist, die sie dem Benutzer präsentiert bzw. vom Benutzer erfragt. Ein solcher Dialog wird von der DV-Vorgangssteuerung gestartet, er interagiert in einem oder mehreren Schritten mit dem Benutzer und gibt anschließend die Kontrolle wieder an die DVVorgangssteuerung zurück. I.3.1.4. Technische Einbindung von Workflow in VAA Die Steuerungsebene ist innerhalb der VAA die zentrale Komponente, d.h. sie kontrolliert (logisch) den Ablauf sämtlicher Anwendungen, die innerhalb der VAA ablaufen. Die technische Einbindung muß nicht automatisch den gleichen Prinzipien folgen. Allerdings ist es für eine exakte Schnittstellenbeschreibung erforderlich, die Art der Einbindung der Workflow/Vorgangssteuerung in die VAA festzulegen. Durch die Anforderung, nicht-VAA-konforme Software einzubinden, ist eine Entscheidung für eine einheitliche Verfahrensweise nicht möglich. Für die technische Einbindung gibt es drei Möglichkeiten: I.3.1.4.1. Einbindung als steuernde Komponente Eine Einbindung als steuernde Komponente bedeutet, daß die Workflow-/Vorgangssteuerung bei jeder VAA-Anwendung sozusagen als „Hauptprogramm“ läuft und die einzelnen Anwendungsbausteine „aufruft“. Eine solche Implementierung stellt relativ geringe Anforderungen an die Workflow-Konformität der Anwendungen, da eine Rückgabe der Kontrolle an die Workflow/Vorgangssteuerung sozusagen erzwungen wird. I.3.1.4.2. Einbindung als Dienst Eine Einbindung als Dienst bedeutet, daß die Workflow-/Vorgangssteuerung gerufen wird und ihr mitgeteilt wird, welche Aktion sie ausführen soll. Dies kann das Verbuchen von Aktivitäten, das Ermitteln der nächsten Aktvität usw. sein. Bei einer solchen Implementierung wird die Workflow-Client-Anwendung die Aufgabe bekommen, die Workflow-Steuerung aufzurufen, um nächste Arbeitsschritte usw. zu ermitteln. I.3.1.4.3. Kooperative Steuerung Bei einer asynchronen Einbindung wird die Workflow-/Vorgangssteuerung aufgerufen, gibt aber die Kontrolle nicht an den Aufrufer zurück, sondern an die Komponente, welche von ihr als die nächste zu startende ermittelt worden ist. Allerdings wartet sie das Ende der Bearbeitung nicht ab, sondern es ist Aufgabe der aktivierten Anwendung, dafür zu sorgen, daß nach Beendigung der Aktivität die Workflow-/Vorgangssteuerung die Kontrolle erneut erhält. I.3.1.4.4. Bewertung der Alternaiven I.3.1.5. Migration zu VAA-Architektur Die Einführung von Anwendungen mit einer VAA-Architektur wird i.A. nicht „auf der grünen Wiese“, sondern in bestehenden DV-Umgebungen mit komplexen bestehenden Anwendungssystemen erfolgen. Außerdem wird es auch in Zukunft erforderlich sein, nicht VAA-konforme Anwendungen einzusetzen. Diese Anwendungen (sowohl Altanwendungen als auch andere nicht VAA-konforme) sollen i.d.R. in Geschäftsprozesse, die unter der Kontrolle der Workflow/Vorgangssteuerung ablaufen, eingebunden werden. Dafür gibt es die Möglichkeiten Einbindung auf der Ebene DV-Vorgang Einbindung auf der Ebene Anwendungsbaustein Für die Schnittstellenproblematik müssen dabei in beiden Fällen gegebenenfalls Anpassungsprogramme implementiert werden. 14 © GDV 1999 Workflow-/Vorangssteuerung Abgrenzung und Wirkungsweise I.3.1.5.1. Einbindung auf der Ebene DV-Vorgang Eine Einbindung auf der Ebene DV-Vorgang bedeutet, daß eine Nicht-VAA-Anwendung analog einem Vorgang in einen Geschäftsprozeß eingebunden und vom Workflow-Manager gestartet und beendet wird. Der Workflow-Manager übernimmt auch die Funktionen zur Protokollierung der Aktivitäten, zur Berechtigungs- und Zuständigkeitsprüfung usw. Die Anwendung ist selbst für alle Funktionen verantwortlich, die sonst von der DVVorgangssteueung bereitgestellt oder angesteuert werden, insbesondere für die Bildschirmeinund -ausgabe. Außerdem ist auch die Nutzung des Vorgangsspeichers und des damit verbundenen Konzepts fachlicher Transaktionen nicht möglich, d.h. die Ergebnisse der Anwendung sind unmittelbar nach Beenden der Anwendung aktiv. Diese Art der Einbindung entspricht dem Einsatz eines herkömmlichen Workflow-Systems mit bestehenden Anwendungen. Eine solche Einbindung ist bspw. beim Einsatz eines StandardTextverarbeitungsprogrammes sinnvoll. I.3.1.5.2. Einbindung auf der Ebene Anwendungsbaustein Eine Einbindung auf der Ebene eines Anwendungsbausteines bedeutet, daß dort, wo innerhalb einer DV-Vorgangs normalerweise ein (VAA-konformer) Anwendungsbaustein aufgerufen wird, ein nicht VAA-konformes Programm gerufen wird. Dieses muß allerdings einige Anforderungen, die an Anwendungsbausteine gestellt werden, auch erfüllen. Insbesondere darf es nicht unterbrechbar sein und keine Funktionen zur Bildschirmein- und -ausgabe enthalten. Auch in diesem Fall ist eine Nutzung des Konzepts der fachlichen Transaktionen mit Vorgangsspeicher usw. nicht möglich, da der Datenzugriff (Be- und Entsorgung) nicht über die Datenmanagerschnittstelle erfolgt. Diese Art der Einbindung ist sinnvoll für Programme, die über eine Schnittstelle Funktionen bereitstellen, die in Geschäftsprozessen gebraucht werden (z.B. Druckausgabeaufbereitung, Tarifierung...). I.3.2. Beispiel für dynamisches Zusammenspiel der einzelnen Bestandteile Im folgenden soll versucht werden, den Ablauf einer Anwendung innerhalb der VAA darzustellen. Dafür wird eine einfache Anwendung angenommen, eine Kontoauskunft mit evtl. Suche nach dem Kunden und dem Druck eines Briefes an den Kunden. I.3.2.1. Kurze verbale Beschreibung des Geschäftsprozesses: 1. Kunde ruft an und möchte einen Kontoauszug gedruckt haben. Aufgrund der Angaben des Kunden sucht der SB zunächst den Kunden: 2. Kunde wird nicht gefunden, dann zurück zum Anfang, erneute Vorgabe von Kundendaten und Suche 3. ein Kunde wird gefunden, veranlassen des Drucks des Kontoauszuges 4. mehrere Kunden gefunden, Selektion des gewünschten Kunden und veranlassen des Drucks des Kontoauszuges. I.3.2.2. Abarbeitung dieses Geschäftsprozesses innerhalb der VAA In der folgenden Tabelle wird angegeben, in welcher Situation (aus Sicht des DV-Systems) welche Komponente der Architektur die Kontrolle hat bzw. weitergibt: Dabei bedeuten: © GDV 1999 15 Abgrenzung und Wirkungsweise W- Workflow-Manager V- Vorgangssteuerung P- Präsentationsmanager mit Dialogsteuerung D- Datenmanager A- Anwendungsbaustein >- ... gibt Kontrolle an ... Workflow-/ Vorgangsmanager Zugriffe auf das Parametersystem werden nicht explizit angegeben, da diese in jeder Situation und sehr häufig erfolgen können. Situation 1. befindet sich in einer Einstiegsoberfläche, in der er die Möglichkeit hat, verschiedene Anwendungen auszuwählen, Er wählt eine Partnersuche, um den Kunden ermitteln zu können (über Kommando, Menü o.ä.) P>V 2. Die Partnersuche wird gestartet. Der auszugebende Bildschirm wird ermittelt, in welchem die bekannten Partnerdaten eingegeben werden können. V>P 3. Der ausgewählte Bildschirm wird gesendet. P 4. Der Benutzer gibt die ihm bekannten Daten ein, sie werden (bei der Eingabe oder auf Benutzeranforderung) formal geprüft. P 5. Die eingegebenen Daten werden einem Anwendungsbaustein übergeben mit der Aufforderung, entsprechende Partner zu suchen. P>V>A 6. Der Anwendungsbaustein richtet Anfragen an den Datenmanager, um in der Partnerdatenbank nach einem entsprechenden Partner zu suchen. A>D>A> V Fall 1 - kein Partner gefunden 7. Ausgabe einer entsprechenden Meldung an den Benutzer und zurück zu 3. V>P Fall 2 - mehr als ein Partner gefunden 8. Aufruf eines Dialoges, der die Partnerdaten anzeigt und Blättern ermöglicht. V>P 9. Der Benutzer blättert und wählt dann den betreffenden Partner aus. Weiter bei 10. P Fall 3 - genau ein Partner gefunden 10. Der Benutzer startet (durch eine entsprechende Eingabe) den Geschäftsprozeß Kontoauszug verschicken Der ausgewählte Partner wird diesem Geschäftsprozeß mit übergeben. P>V>W 11 Der Geschäftsprozeß sucht den ersten erforderlichen Anwendungsbaustein (Kontoauszug zusammenstellen) W>V>A 12 Der Anwendungsbaustein fordert beim Datenmanager die Kontodaten des Partners an A>D 13 Die Kontodaten des Partners werden gelesen und dem Anwendungsbaustein übergeben D>A 14 Der Anwendungsbaustein stellt die Daten des Kontoauszuges zusammen und gibt die Kontrolle zurück. A>V 15 Der nächste Anwendungsbaustein (Druck eines Formschreibens) wird ermittelt und aufgerufen. Über Parameter wird mitgeteilt, welche Art Formschreiben (Kontoauszug) mit welchen Daten (Partnernummer..) zu erstellen ist V>A 16 Der Anwendungsbaustein bereitet das Formschreiben für den Druck vor und veranlaßt den Druck. Es erfolgt eine Rückmeldung über den erfolgreichen Druck. A>V 17 Der Geschäftsprozeß wird beendet. V>W 16 © GDV 1999 Workflow-/Vorangssteuerung 18 Formale Beschreibung und Schnittstellen Der Benutzer befindet sich wieder in seinem Einstiegsbild, in dem er die jeweilige Awendung auswählt. W>V>P II. Formale Beschreibung und Schnittstellen II.1. Metamodell II.1.1. Einleitung Der VAA-Architekturrahmen definiert zwei Kategorien von Daten, die die Abwicklung eines Prozesses zur Laufzeit beinflußen: Parameter-Daten Dies sind aus VAA-Komponenten ausgelagerte Definitionen, um das Verhalten dieser Komponenten für verschiedene Anforderungssituationen konfigurieren zu können. Ihre Bereitstellung erfolgt über das Parametersystem. Operationale Daten Dies sind die Anwendungsdaten, die in einer Prozeß-Instanz bearbeitet werden. Der Zugriff auf diese Daten erfolgt über den Datenmanager. Beide Datenkategorien treten auch im Bereich der Workflow-/Vorgangsteuerung auf. So müssen einerseits die Eigenschaften eines Geschäftsvorgangs in einer Prozessdefinition abgelegt werden. Andererseits entstehen aus der Abwicklung einzelner Geschäftsprozesse operationale Prozessinformationen, die für nachfolgende Prozeßauskünfte oder zur Steuerung von Folgeprozessen verwendet werden. Nachfolgend werden die beiden Datenkategorien getrennt beschrieben durch das Konfigurationsmodell und das operationale Modell für die Workflow-/Vorgangssteuerung. Für die Darstellung wurde die folgende Syntax herangezogen: © GDV 1999 17 Formale Beschreibung und Schnittstellen Workflow-/ Vorgangsmanager Konfigurationsobjekt gemeinsame Änderungsmenge unabhängige Entität Entität mit hierarchischer Beziehung 1:n-Beziehung Entität mit rekursiver Beziehung n:m-Beziehung Entität mit zweifacher Elternbeziehung n:m-Beziehung Die Syntax entspricht der Darstellung von Datenmodellen im Rahmen der VAA-Architektur. Zur einfacheren Erstellung von Modellvarianten sind für die Darstellung von Entitätsbeziehungen in den folgenden Grafiken jedoch Einfach-Pfeile verwendet worden. II.1.2. Das Konfigurationsmodell zur Workflow/Vorgangssteuerung II.1.2.1. Allgemein Das Konfigurationsmodell beschreibt die Datenstrukturen mit ihren Beziehungen für die Konfiguration der Workflow-/Vorgangssteuerung. Das hier dargestellte Modell beschränkt sich auf die wichtigsten Entitäten und deren Attribute. Zudem ist für Konfigurationsobjekte, die nicht zum Kern der Geschäftsprozeß-Definition gehören, die innere Struktur nicht weiter aufgebrochen. Es wurde eine Gruppierung in Konfigurationsobjekte vorgenommen, die einer gemeinsamen Pflege und Versionierung unterliegen sollten. Diese Informationen werden in eine Verwaltungseinheit zusammengefaßt. weil sie in einem engen fachlichen Zusammenhang stehen und häufig gleichzeitig geändert werden. In der nachfolgenden Darstellung wird von keiner Modelltrennung für Workflow- und Vorgangssteuerung ausgegangen. 18 © GDV 1999 Workflow-/Vorangssteuerung Formale Beschreibung und Schnittstellen II.1.2.2. Konfigurationsmodell GeschäftsProzeß GeschäftsEreignis Prozeß-Rolle Teil-Prozeß EreignisBeziehungen EinbettungsBeziehung Prozeß-Funktion VorgängerBeziehung RollenZuordnung Proz-FunktionsZuordnung © GDV 1999 EreignisErzeugung Prozeß-AnstoßBeziehung GeschäftsObjekt Ereignis-ObjektZuordnung ProzeßErgebnisse GeschäftsobjektZuordnung 19 Formale Beschreibung und Schnittstellen Workflow-/ Vorgangsmanager II.1.2.3. Beschreibung des Modells: II.1.2.3.1. Allgemein Im folgenden werden die drei Hauptbestandteile der Konfiguration von Geschäftsprozessen beschrieben, da sie wesentlich die Geschäftsprozeßbearbeitung beeinflußen: die Geschäfts-Ereignis-Definition die Geschäfts-Prozeß-Definition Die anderen angesprochenen Konfigurations-Bestandteile gehören zu anderen Architekturkomponenten und werden hier nicht weiter behandelt. Dies sind: die Definitionen von Prozeßfunktionen die Geschäfts-Objekt-Definitionen II.1.2.3.2. Die Geschäfts-Ereignis-Definition Geschäfts-Ereignisse sind die Auslöser für Geschäftsprozesse und Teilprozesse. Sie können durch äußere Einwirkungen entstehen, d.h. durch Anstöße außerhalb des Workflow-Systems, z. B. Bearbeitungs-Anstoß eines Sachbearbeiters oder durch Datenträger-Austausch von einer externen Stelle oder durch Anstöße aus der internen Prozeßbearbeitung des Workflow-Systems, z. B. Erreichen eines Bearbeitungstermins Anstoß durch einen vorangehenden Geschäftsprozeß oder Teil-Prozeß Im Rahmen der Ereignisbehandlung sind folgende Funktionen notwendig: Registrierung der Ereignisse Das eintreffende Ereignis muß dem System bekannt gemacht werden und der Ereignistyp muß bestimmt werden. Zuordnung des Ereignisses zu Geschäftsobjekt-Instanzen Das Ereignis muß den Geschäftsobjekten zugeordnet werden, die durch das Ereignis an- 20 © GDV 1999 Workflow-/Vorangssteuerung Formale Beschreibung und Schnittstellen gesprochen werden. Dies ist notwendig, um laufende oder parallele Geschäftsprozesse zum gleichen Geschäftsobjekt erkennen zu können. Zuordnung des Ereignisses zu Teilprozessen und Geschäftsprozeß-Instanzen Aus Ereignis und bereits vorhandenen Geschäftsprozeß-Instanzen muß abgeleitet werden, ob durch das Ereignis vorhandene Geschäftsprozesse wieder aufgenommen oder neue Geschäftsprozesse ausgelöst werden. Bestimmung der Ereignisfälligkeit Es ist festzuhalten, wann das Ereignis die Instanzierung der Prozesse anstößt. Der Anstoß kann vom Eintreffen eines zeitlichen Termins oder der Fälligkeit anderer Ereignisse abhängen (Ereignis-Synchronisation). In der Ereignisdefinition muß die Beschreibung enthalten sein, die dem Workflow-Manager die Ausführung dieser Arbeiten ermöglicht. Sind die Angaben hierzu nicht vollständig, muß ein Bearbeiter die notwendigen Informationen vorgeben. Die Ereignis-Definition selbst enthält folgende Eigenschaften: Entität Geschäfts-Ereignis Beschreibung ist die führende Entität der Ereignis-Definition und enthält die Grundattribute zum Ereignis: Ereignis-Name Version Bezeichnung Ereignistyp Erzeuger-Prozeß Prozeß-Anstoß definiert den Zusammenhang zu auszulösenden Teil-Prozessen und legt mögliche Prozeßzuordnungen fest ein Ereignis kann auch mehrere Prozesse auslösen je Beziehung Attribute für die Prozeß-Zuordnung (z.B. Parameter für den Prozeßaufruf) Beziehung zu anderen Geschäfts-Ereignissen Beziehung zu Geschäftsobjekten definiert Abhängigkeiten zu weiteren Geschäftsereignissen ermöglicht z.B. die Synchronisation von Ereignissen, die gemeinsam einen Prozess auslösen. beschreibt die Zuordnung von Geschäftsobjekten zu ändernde Geschäftsobjekte zu benutzende Geschäftsobjekte ermöglicht z. B. die Einstiegsunterstützung auf Ereignisse aus der Sicht von Geschäftsobjekten © GDV 1999 21 Formale Beschreibung und Schnittstellen Workflow-/ Vorgangsmanager II.1.2.3.3. Die Geschäfts-Prozeß-Definition Ein Geschäfts-Prozeß ist die größte fachliche Prozeß-Einheit, die gemeinsam durch das Workflow-System verwaltet wird. Er setzt sich zusammen aus Teilprozessen, die die Ablaufelemente des Gesamtprozesses darstellen und die durch Ablaufbeziehungen miteinander verbunden sind. Ein Teilprozess kann sich zerlegen in weitere Teilprozesse oder ist ein Teilprozeß, dem ein Anwendungsbaustein oder ein Dialog zugeordnet ist. Die Geschäftsprozeß-Definition muß demnach alle Informationen liefern, um einen Geschäftsprozeß instanzieren und beenden zu können Teilprozesse in ihrer Ablauffolge zu erzeugen Prozeßfunktionen zuzuordnen mögliche Bearbeiter zuzuordnen Ablaufunterstützung innerhalb von Teilprozessen zu geben (Weiterleitung, Unterbrechung etc.) den Status eines Prozesses anzeigbar zu machen den Prozeß zu protokollieren und Verbindungen zu operationalen Beständen zu halten. Eine wichtige Forderung an die Geschäftsprozeß-Definition ist es, die Einbettung von Teilabläufen zu ermöglichen, damit deren Beschreibung nicht mehrfach gepflegt werden muß. 22 © GDV 1999 Workflow-/Vorangssteuerung Formale Beschreibung und Schnittstellen Die Geschäftsprozeß-Definition enthält folgende Entitäten: Geschäfts-Prozeß ist die führende Entität zur Prozeß-Definition und enthält die Grund-Attribute zum Prozeß Name Version Bezeichnung Teil-Prozeß sind Prozeßeinheiten, die die Ablaufelemente des Geschäftsprozesses darstellen. zu unterscheiden sind den Geschäftsprozeß startende Teilprozesse den Geschäftsprozeß beendenden Teilprozesse sonstige Teilprozesse zu unterscheiden sind manuelle Teilprozesse maschinell unterstützte Teilprozesse maschinelle Teilprozesse mögliche Teilprozeß-Typen: Arbeitsprozeß hat Verweise auf Prozeß-Funktionen hat Verweise auf Prozeß-Rollen hat Verweise auf Geschäftsobjekte erzeugt Geschäftsereignisse hat keine Verweise auf eingebettete Teil-Prozesse hat Prozeß-Ergebnisse Blockprozeß hat Verweise auf weitere Teilprozesse, die an dieser Ablaufstelle in den Prozeß eingebettet werden VorgängerBeziehungen bildet eine Ablauf-Abhängigkeit zwischen den Teilprozessen ab ein Vorgänger-Teilprozeß ist Voraussetzung für die Ausführung des Nachfolger-Teilprozesses es gibt auch unabhängige Teilprozesse, die in keiner Abhängigkeit zu einem Vorprozeß stehen EinbettungsBeziehungen bildet den Zusammenhang zwischen einem Blockprozeß und seinen eingeschlossenen Teilprozessen ab verweist auf den Start-Teilprozeß einer abhängigen Menge/Folge von Teilprozessen Rollen-Zuordnung hält fest, welche Prozeß-Rollen diesen Teilprozeß bearbeiten dürfen und welche besonderen Eigenschaften erwartet werden die Rollenzuordnung wird nur benötigt für manuelle oder ma- © GDV 1999 23 Formale Beschreibung und Schnittstellen Workflow-/ Vorgangsmanager schinell unterstützte Teilprozesse Funktions-Zuordnung verweist auf auszuführende Prozeßfunktionen (Anwendungsbausteine und Dialoge) Attribute Aufrufbedingung Ausführungs-Plattform Ausführungs-Parameter Die Funktionszuordnung fehlt bei manuellen Teilprozessen Ereignis-Erzeugung enthält Verweise auf Geschäftsereignisse, die durch den TeilProzeß erzeugt werden Attribute Referenz auf Ereignisdefinition Bedingungen für die Erzeugung Parameter für die Übergabe an das erzeugte Ereignis (z.B. Ordnungsbegriffe, Fälligkeit etc.) Prozeß-Ergebnis beschreibt den Inhalt der Prozeß-Akten Attribute Datensicht für Protokoll-Daten Beschreibung der Protokollinformationen Vorgabe für Protokollumfang während des Prozeßablaufs und nach Prozeßende GeschäftsobjektZuordnung enthält Verweise zu Geschäftsobjekten, die in diesem Teilprozeß bearbeitet werden Anwendungsdaten Dokumente, Belege etc. Erläuterungen: 1. Ein Geschäfts-Prozeß kann mehrere mögliche Start-Punkte haben. 2. Der Gesamt-Prozeß hat mehrere mögliche Ende-Punkte. Ein Geschäfts-Prozeß ist beendet , wenn ein mögliches Prozeß-Ende erreicht wird. 3. Ein Geschäftsprozeß kann immer abgebrochen werden. Bereits abgelaufene Teilprozesse werden hierbei nicht mehr rückgängig gemacht 4. Eine Personenzuordnung aufgrund einer Rollenzuordnung sollte möglichst erst zum Zeitpunkt der Prozeß-Aktivierung geschehen, damit möglichst die aktuelle Verfügbarkeit von Personen verwertet wird. 5. Über Ereignisse können mehrere Geschäftsprozesse miteinander verkettet sein. Dies ist aber lediglich eine Unterstützung bei der Abwicklung, eine gemeinsame Auswertung oder Auskunft ist über die Protokolldaten nicht direkt erhältlich. 24 © GDV 1999 Workflow-/Vorangssteuerung © GDV 1999 Formale Beschreibung und Schnittstellen 25 Formale Beschreibung und Schnittstellen Workflow-/ Vorgangsmanager II.1.3. Das operationale Modell der Workflow/Vorgangssteuerung II.1.3.1. Allgemein Das operationale Modell beschreibt die Entitäten und ihre Abhängigkeiten, die für das Laufzeitsystem von Bedeutung sind. Es beschreibt damit die Struktur und den Zusammenhang der Dateninstanzen, auf denen das operationale System arbeitet. II.1.3.2. Darstellung des Modells GeschäftsProzeß GeschäftsEreignis Prozeß-Schritt GeschäftsObjekt SchrittBeziehungen Proz-EreignisBeziehungen Obj-EreignisBeziehungen Journal-Zusatz Obj-ProzeßBeziehung 26 © GDV 1999 Workflow-/Vorangssteuerung Formale Beschreibung und Schnittstellen II.1.3.3. Beschreibung des Modells Das Modell beschreibt den Informationsumfang, der für aktive und abgeschlossene Geschäftsvorgänge verwaltet werden sollte. Für den operationalen Betrieb ist wichtig, daß zu jedem Geschäftsprozeß, inclusive der eingebetteten Geschäfts-Prozesse, eine Geschäfts-Vorgangs-Akte geführt wird. Sie dient o zur Information über den aktuellen Status und den bisherigen Ablauf o zur Information über die fachlichen Ergebnisse des Geschäftsprozesses o zur Ansteuerung von noch nicht abgewickleten Prozeßschritten o dem Verweis auf beteiligte Geschäfts-Objekte Möglich ist, daß nach Ende eines Geschäftsprozesses der Umfang der noch gehaltenen Geschäftsprozeß-Information reduziert wird, da die Einzelinformation der Prozeßschritte langfristig nicht mehr relevant ist. Eine Protokollierung des inneren Ablaufs eines DV-Vorgangs (Ablauffolge seiner AnwendungsBausteine) erscheint nicht sinnvoll. Damit stellt das dargestellte Modell den vollen Umfang der Protokollierung des Prozeßablaufs dar. Neben der fachlichen Protokollierung ist es denkbar, daß eine mehr technische Journalisierung von Ablauf-Information erfolgt. Die Journalisierung dient o der Information zur Resourcenauslastung o für Informationen zur Kostenverrechnung o zur Optimierung des technischen Systems. Die technische Journalisierung wird hier nicht weiter betrachtet. II.1.3.3.1. Der Geschäftsprozeß Im Informationsobjekt „Geschäfts-Prozeß“ werden allgemeine Daten zu einer GeschäftsprozeßAkte abgelegt. Sie wird bei der Instanzierung des Prozesses angelegt. Im Laufe der Bearbeitung werden weitere Versionen der Entität „Geschäftsprozeß“ angelegt und am Abschluß der Gesamtstatus festgehalten. © GDV 1999 27 Formale Beschreibung und Schnittstellen Workflow-/ Vorgangsmanager Die protokollierte Datenmenge wird teilweise generell erzeugt, d.h. für jeden Prozeß gleichartig, teilweise aber über die Konfigurationsdefinition für den einzelnen Prozeß individuell vorgegeben. Geschäfts-Prozeß ist die führende Entität zur Geschäftsprozeß-Akte und enthält generelle Daten zur Prozeßausführung Start Ende Status (instanziert, in Arbeit, inaktiv, ereledigt, etc.) Name Prozeßklasse verbrauchte Resourcen Prozeßergebnis (global) etc. II.1.3.3.2. Der Prozeß-Schritt Das Informationsobjekt „Prozeß-Schritt“ wird für jeden zeitlich zusammenhängenden Ablaufschritt des Geschäfts-Prozesses erzeugt und enthält Daten zum abgewickelten Teilprozeß. Die Informationen zum Prozeß-Schritt werden am Ende des Ablaufschrittes erzeugt, weitere Ablaufschritte erzeugen weitere Protokoll-Instanzen. Da die bisherige Ablauf-Historie nicht überschrieben wird, kann der Prozeß in seinem Ablauf lückenlos nachvollzogen werden. Prozeß-Schritt hält Informationen zu jedem Ablaufschritt des Prozesses fest Start Ende Status (in Arbeit, unterbrochen, erledigt, etc.) Teilprozeß verbrauchte Resourcen Bearbeiter/Rolle ausgeführte Prozeßfunktion Schritt-Beziehungen etc. enthält Verweise auf vorausgegangene Teilprozesse, die Voraussetzung für diesen Teilprozeß waren folgende Typen sind denkbar 28 © GDV 1999 Workflow-/Vorangssteuerung Formale Beschreibung und Schnittstellen Fortsetzungsschritte von unterbrochenen Teilprozessen Teilprozesse aus der direkten Nachfolgerbeziehung über Ereignisse verbundene Teilprozesse (auch aus anderen Geschäftsprozessen) Ereignis-Beziehungen enthält Verweise auf Ereignisse, die für diesen Ablaufschritt erzeugend waren oder durch diesen Ablaufschritt ausgelöst wurden Objekt-Beziehungen enthält Verweise auf die benutzten Anwendungsbestände geändert / gelesen Dokumente, Geschäftsobjekte etc. dienen auch zur Einstiegsunterstützung aus der Sicht der Geschäftsobjekte (wer hat wann dieses Geschäftsobjekt angefaßt) oder aus der Sicht der Prozesse (wie wurde ein Geschäftsobjekt in diesem Prozeß verändert) Journalzusatz enthält weitere Protokolldaten zu einem Prozeßschritt II.1.3.3.3. Das Geschäftsereignis Das Informationsobjekt „Geschäftsereignis“ wird angelegt, wenn ein Ereignis im System bekannt wird. Weitere Versionen werden erzeugt, wenn das Ereignis nicht sofort fällig ist. Geschäfts-Ereignis hält die Daten zu den aufgetretenen Ereignissen fest Anlege-Zeitpunkt Status Name Typ Ereignis-ObjektBeziehung © GDV 1999 hält Verweise auf betroffene Geschäftsobjekte Ermöglicht den Einstieg auf Ereignisse über GeschäftsobjektNummern 29 Formale Beschreibung und Schnittstellen Workflow-/ Vorgangsmanager II.2. funktionale Anforderungen Bei der Definition der funktionalen Anforderungen wurde zunächst nicht unterschieden zwischen Anforderungen, die der Workflow-Manager erfüllen muß, und denen, die die DVVorgangssteuerung erfüllen muß, unterschieden. Aus der Definition eines DV-Vorgangs ist allerdings ersichtlich, welche Funktionen zur Steuerung eines DV-Vorgangs benötigt werden welche nicht. In der Definitionsebene werden Ablauf- und Aufbauorganisation beschrieben, soweit sie für die Prozeßsteuerung von Bedeutung sind. Da Workflow im Rahmen der VAA hauptsächlich als technische Steuerungsebene gesehen wird, ist die Definitionsebene nur insofern relevant, als hier im Organisations- und Proezeßmodell die Steuerungsinformationen abgelegt werden. Insbesondere die Steuerungstiefe von Workflow und die Anforderungen an ein Prozeßcontrolling bestimmen den Modellierungsbedarf. Anforderungen an die Definitionsebene wie Unterstützung der Prozeßmodellierung und Analyse durch Konsistenzprüfungen oder Simulationen werden in diesem Kapitel nicht betrachtet. Auch Fragestellungen zu dem Zusammenspiel von Produkt- und Prozeßmodell (z.B.: Inwieweit lassen sich zu komplexen Produkten ggf. Prozesse automatische aus Sparten-Teilprozessen bzw.und Sparten-Anwendungsbausteinen zusammensetzen?) werden hier nicht in Anforderungen umgesetzt. Eine Unterscheidung in Funktionalitäten, die der Workflow-Manager selbst in jedem Fall bereitstellen muß, und solche, die auch von workflownahen Diensten bereitgestellt werden können, erfolgt im Rahmen der Anforderungsdefinition hier nicht. II.2.1. Organisationsmodellierung Für Zuständigkeits-, Berechtigungs- und Freigabeprüfungen folgende Definitionen zur Beschreibung der Aufbauorganisation erforderlich: Stellen, Rollen und entsprechende Hierarchien mit/ohne Vererbung von Berechtigungen Rollen mit Zuständigkeiten und Berechtigungen für die Nutzung von Anwendungen (ggf. mit Attributen für Lese-, Schreib- und Lösch-Berechtigung o.ä.) in Abhängigkeit von Dateninhalten (Maximalbeträge, Kennzeichen für „manuelle Tarifierung“ o.ä.) für bestimmte Teilmengen von Daten (z.B. nach Region, Vermittler oder Organisation) Dazu soll es ggf. auch möglich sein, bereits vorhandene externe Organisationsbeschreibungen in das Workflow-System einzubinden (am besten durch Online-Zugriff, mindestens aber durch eine Batch-Schnittstelle). II.2.2. Prozeßmodellierung Für die Prozesse sind folgende Komponenten steuerungsrelevant und müssen definiert werden können: 30 © GDV 1999 Workflow-/Vorangssteuerung Formale Beschreibung und Schnittstellen Ereignisse: verschiedene Arten von Ereignissen sind zu unterstützen: interne und externe timer-gesteuerte (relative und absolute) und event-gesteuerte Verknüpfung von Ereignissen mit Prozessen Beschreibung der Ergebnisse Für das Zurücksetzen von Ergebnissen: Definition von kompensierenden Aktionen für Teilprozesse und ganze Geschäftsprozesse Zielvorgaben für das Prozeßcontrolling: Bearbeitungs- und Durchlaufzeiten, Anzahl der Bearbeitungsschritte (Vorgabe einer Anzahl von Unterbrechungen) Ablauflogik von Prozessen: lineare Folgen, automatisches Verzweigen (bei strukturierten Prozessen), situatives Verzweigen (bei unstrukturierten Prozessen), Schleifenbildung, Nebenläufigkeit und Synchronisation verschiedener Prozesse, Warten auf Ereignisse usw. Zusammenfassung von Elementarprozessen zu Logical Units of Work (LUW) Zuordnung von Stellen / Rollen zu Teilprozessen Definition von Fristen und Terminen Definition von Prioritäten Zuordnung von Anwendungsbausteinen (im fachlichen Modell inklusive Unterscheidung Mensch/Maschine) Umfang der Protokollierung und zugehörige Aufbewahrungsfristen II.2.3. Laufzeitfunktionen Die Anforderungen an die Laufzeitfunktionen definieren den Leistungsumfang der Steuerungsebene Workflow. Welche Rolle Workflow in den einzelne Unternehmen spielen wird, ist unternehmenspezifisch festzulegen: Workflow kann an Arbeitsplätzen die alleinige und oberste Steuerungsebene sein, die ab Tagesstart die Arbeit des Sachbearbeiters im System führt, d.h. die Arbeitssteuerung erfolgt ausschließlich über die Arbeitsverwaltung (Postkorb) des Workflow-Systems. An anderen Arbeitsplätzen werden ggf. nur bestimmte Tätigkeiten unter WorkflowSteuerung durchgeführt. II.2.3.1. Prozeßmanagement II.2.3.1.1. Instanziierung Ein Geschäftsprozeß kann explizit durch einen Sachbearbeiter im interaktiven Betrieb angestoßen werden oder er wird ereignisgesteuert oder automatisch vom System initialisiert. Der Wechsel von Prozeßtypen muß möglich sein. Der Typ des Geschäftsprozesses kann zunächst noch unbekannt sein und erst in einem nächsten Teilprozeß (Selektion) bestimmt werden. Ein Geschäftsprozeß muß einen weiteren Geschäftsprozeß anstoßen können (z.B. Mahnung/Kündigung). © GDV 1999 31 Formale Beschreibung und Schnittstellen Workflow-/ Vorgangsmanager Eine organisatorische Zusammenfassung von Prozessen, die sich auf das gleiche Objekt oder Ereignis beziehen, muß möglich sein. II.2.3.1.2. Unterbrechung Es sind zwei Arten von Unterbrechungen zu unterscheiden, die unterschiedliche Aktionen des Workflow-Systems hervorrufen. Technische Unterbrechung: Der Sachbearbeiter teilt dem Workflow-System per Funktionstaste o.ä. mit, daß er die Arbeit an einem Vorgang unterbrechen will, um später an der gleichen Stelle wieder aufzusetzen. Workflow teilt ggf. allen offenen Anwendungsbausteinen mit, daß die Arbeit unterbrochen wird. Die Anwendungsbausteine - auch Standardanwendungen wie Textverarbeitung müssen mit dieser Meldung umgehen können und ggf. Datensicherung etc. einleiten. Workflow setzt Termin für Wiedervorlage und einen entsprechenden Status (unterbrochen, könnte weiterbearbeitet werden). Bei Wiederaufnahme der Bearbeitung sorgt Workflow für den Start aller abgebrochenen Anwendungsbausteine. 32 © GDV 1999 Workflow-/Vorangssteuerung Formale Beschreibung und Schnittstellen Fachliche Unterbrechung: Während der Bearbeitung eines Vorgangs wird festgestellt, daß der Vorgang wegen fehlender Unterlagen, fehlender Kompetenz etc. nicht zuende bearbeitet werden kann. (Bemerkung : Die ist keine Unterbrechung im Sinne der WFMC:) Der Anwendungsbaustein teilt Workflow mit, daß eine Unterbrechung der Bearbeitung erfolgt, auf welches Ereignis zu welchem Termin gewartet wird und an welcher Stelle die Arbeit fortgesetzt werden soll. Workflow teilt ggf. übrigen offenen Anwendungsbausteinen mit, daß die Arbeit unterbrochen wird. Die Anwendungsbausteine - auch Standardanwendungen wie Textverarbeitung müssen mit dieser Meldung umgehen können und ggf. Datensicherung etc. einleiten. Workflow setzt Termin für Wiedervorlage und einen entsprechenden Status (unterbrochen, wartet auf Ereignis) und sichert Workflow-relevante Daten Bei Eintreffen des Ereignisses wird der Termin für die Wiedervorlage auf das Tagesdatum gesetzt und der Status wird umgesetzt. (unterbrochen, könnte weiterbearbeitet werden). Bei Erreichen des Termins wird der Vorgang in eine Wiedervorlage gestellt oder eine definierte Aktion angestoßen. Bei Wiederaufnahme der Bearbeitung gem. Wiedervorlage sorgt Workflow für den Start aller abgebrochenen Anwendungsbausteine. Bemerkung: Wenn ein Sachbearbeiter mehrere Vorgänge parallel bearbeitet, kann auch die Arbeit an einem Vorgang temporär unterbrochen sein, z.B. währende einer telefonischen Auskunft. Diese Vorgänge sind im Sinne von Workflow beide "in Arbeit". Es erfolgt keine Steuerung durch Workflow. II.2.3.1.3. Weiterleitung und Delegation Bei der Weiterleitung eines Vorgangs durch Workflow an eine andere Stelle müssen zwei Formen unterschieden werden können: Weiterleitung: Abgeben der Aufgabe und der Verantwortung für das Ergebnis an einen anderen Delegation: Abgeben der Aufgabe, aber das Ergebnis muß vom Abgebenden abgezeichnet werden, und er trägt die Verantwortung für die Korrektheit Sowohl Weiterleitung als auch Delegation sollen an vordefinierte Stellen / Personen / Rollen oder mit manueller Eingabe des Adressaten vorgenommen werden können. Eine ad-hoc-Änderung des vordefinierten Arbeitsablaufs soll (für Ausnahmefälle) an jeder Stelle der Bearbeitung möglich sein. II.2.3.1.4. Abbruch/Löschung Abbruch bzw. Löschung eines Geschäftsprozesses muß auf jeden Fall möglich sein, zumindest während der Bearbeitung des ersten Teilprozesses, d.h. solange noch keine Zwischenergebnisse erzeugt wurden, die ggf. Außenwirkung haben. Dies gilt analog für den Abbruch eines Teilprozesses innerhalb der Pozeßbearbeitung. Vorangegangene Arbeitsschritte und Ergebnisse müssen dann gültig bleiben. © GDV 1999 33 Formale Beschreibung und Schnittstellen Workflow-/ Vorgangsmanager Für den Abbruch nach Abschluß eines Teilprozesses müssen ggf. die entsprechenden kompensierenden Aktionen definiert sein. In allen anderen Fällen darf das Workflow-System den Abbruch nicht zulassen. Der Vorgang Abbruch / Löschung ist mit den zugehörigen Eingabedaten und Dokumenten zu protokollieren. II.2.3.1.5. Abschluß Bei Abschluß der Bearbeitung eines Prozesses muß Workflow für eine Protokollierung des Vorgangs und die Archivierung relevanter (vorher definierter) Arbeitsergebnisse und Bemerkungen sorgen. Ziel ist zum einen eine maschinelle Nachvollziehbarkeit von Geschäftsprozessen im Rahmen rückwirkender Änderungen und zum anderen eine Referenz der Vorgangshistorie. Wenn ein Geschäftsprozeß im Sinne von Workflow einmal abgeschlossen ist, ist keine Wiederaufnahme der Bearbeitung des Prozesses mehr möglich. II.2.3.1.6. Steuerung Auf Basis der bei der Prozeßmodellierung getroffen Definitionen sorgt das Workflow-System für die durchgängige Steuerung aller Tätigkeiten (Teil- und Elementarprozesse) des Geschäftsprozesses und sorgt für die Sicherung und Bereitstellung der dazu erforderlichen Daten. Steuerung der Teil- und Elementarprozesse: Aufgrund der Ergebnisse eines Teil- bzw. Elementarprozesses und den Definitionen zur Ablauflogik des Prozesses muß der Workflow-Manager, den nächsten Teil- bzw. Elementarprozeß innerhalb eines Geschäftsprozesses aktivieren. Alle unter "Prozeßmodellierung" erwähnten Steuerungskonstrukte sind zu unterstützen. Bei maschinell durchzuführenden Tätigkeiten ist der zugeordnete Anwendungsbaustein aufgerufen, bei manuellen Tätigkeiten ist ein Hinweis zum betreffenden Teiloder Elementarprozeß im Arbeitskorb des zuständigen Sachbearbeiters anzuzeigen. Koordinierung bei asynchroner Verarbeitung: Bei der Verteilung von Anwendungen sowie bei der Einbeziehung von BatchFunktionen ist asynchrone Verarbeitung notwendig. Die damit zusammenhängenden Funktionen der Koordinierung / Statusanzeige sind von Workflow-System wahrzunehmen. Datenaustausch: Jedem Geschäftsprozeß ist eine Menge von Daten zugeordnet. Dies sind insbesondere die im Laufe des Geschäftsprozesses bisher getätigten Eingaben, aber auch Notizen des Sachbearbeiters, eingehende/ausgehende Post oder aufgrund eines Datenaustauschs vorliegende Daten. Die Vorgangsdaten sind prozeßbezogen zu verwalten, so daß sie allen Teilprozessen innerhalb des Geschäftsprozesses bekannt sind. Auch der Austausch von Daten zwischen unterschiedlichen Geschäftsprozessen ist zu unterstützen. Der Verlauf eines Geschäftsprozesses kann dazu führen, daß weitere Geschäftsprozesse initialisiert werden müssen. Diesen werden dann die bereits vorliegenden Daten zur Verfügung gestellt. II.2.3.1.7. Arbeitsverwaltung Der Arbeitsvorrat eines Sachbearbeiters wird im Arbeitskorb (Postkorb) abgebildet. Bei jedem Aufruf des Arbeitskorbes wird der Stand aktualisiert. Aus dem Arbeitskorb heraus ist der Einstieg in eine ausgewählte Verarbeitung direkt möglich. 34 © GDV 1999 Workflow-/Vorangssteuerung Formale Beschreibung und Schnittstellen Unter "Arbeitsverwaltung" ist sowohl die individuelle Arbeitsverwaltung an einem Arbeitsplatz als auch die übergreifende Arbeits - und Lastverteilung zusammengefaßt. Folgende Anforderungen sind an die Arbeitsverwaltung zu stellen: Arbeitskörbe sollen sowohl für Einzelpersonen als auch für Gruppen geführt werden können. Die Abarbeitung muß in vorgegebener oder wahlfreier Reihenfolge möglich sein. Für die Anzeige der offenen Vorgänge sollen Sortierkriterien vorgeben werden können (Termine, Prioritäten etc.) Die Prioritäten der Vorgänge müssen - bei geeigneter Kompetenz - modifiziert werden können. Neben dem Einstieg in die Vorgangsbearbeitung über den Arbeitskorb muß auch der wahlfreie Einstieg über Schlüsselattribute möglich sein. Die parallele Bearbeitung mehrerer Vorgänge muß möglich sein. Die Umverteilung der Arbeitslast muß auf "Vertreter" oder sonstige andere Stellen möglich sein. II.2.3.1.8. Terminverwaltung und Wiedervorlage Zwischen zwei Teilprozessen kann eine Terminsetzung erforderlich sein. Diese Termine werden vom Terminsystem als Teil des Workflow-Managers überwacht. Dabei kann es sich sowohl um maschinell als auch um manuell gesetzte Termine handeln. Folgende Anforderungen sind an Terminverwaltung und Wiedervorlage zu stellen: Setzen von Terminen und Termingründen an beliebigen Stellen der Geschäftsprozeßbearbeitung Anstoß von definierten Prozessen bei Terminerreichung bzw. bei Eintritt definierter Ereignisse Anzeige der Termine bei Bedarf, ggf. mit Vorgabe von Fristen (z.B. auch bei Anmeldung in das System) Unterschiedliche Anzeigefunktionen (Sortierungen/Auswahl nach Prioritäten, Geschäftsprozeßarten usw.) Sprung in die Geschäftsprozeßbearbeitung optische / akustische Signale bei Eintreffen eines erwarteten Ereignisses II.2.3.1.9. Zuständigkeiten, Berechtigungsverfahren, elektronische Unterschrift Zu jedem Teilprozeß muß ermittelt werden, wer für die Bearbeitung dieses Schrittes zuständig ist. Dies können mehrere Sachbearbeiter (z.B. eine Gruppe) sein. Die Information über die Zuständigkeit kann direkt gespeichert sein (z.B. bei Weiterleitung an eine konkrete Organisationseinheit), oder sie wird aus den Daten des Geschäftsprozesses (Ordnungsbegriff, Geschäftsprozeß-Typ, ...) ermittelt. Die Prüfung der Berechtigung zum Durchführen von Teilprozessen und zum Erzeugen von Ergebnissen werden über ein Berechtigungssystem geprüft, in dem zentral die Berechtigungsregeln hinterlegt sind. Vom Berechtigungssystem wird auch gemeldet, wenn ein Teilprozeß insgesamt oder sein Ergebnis freizugeben ist. Ebenso wird die Freigaberegel (wer darf freigeben, sind noch Änderungen möglich...) geliefert. Die Prüfung der Berechtigung gem. Definition je Rolle muß an unterschiedlichen Stellen möglich sein: © GDV 1999 35 Formale Beschreibung und Schnittstellen Workflow-/ Vorgangsmanager bei Start der Bearbeitung an wohldefinierten Stellen der Geschäftsprozeßbearbeitung (z.B. nach der Eingabe von Auszahlungssummen) Die Weiterleitung an die autorisierte Person soll automatisch erfolgen. Das Vier-Augen-Prinzip muß unterstützt werden. Das Freigabeverfahren ist ein Anwendungsbaustein und wird von Workflow angestoßen. II.2.3.2. Prozeßauskunft Die bei Unterbrechung oder Abschluß eines Vorgangs abgelegten Informationen können als Vorgangshistorie angezeigt werden. Die Menge der Informationen wird bei der Prozeßdefinition festgelegt. Aus der Vorgangshistorie muß eine Verzweigung auf den jeweils angezeigten Geschäftsprozeß bzw. Teilprozeß möglich sein, um Eingaben und Datenzustände nachvollziehen zu können. II.2.3.2.1. Status eines Prozesses Die Auskunft zum Bearbeitungsstand eines Prozesses soll zumindest folgende Informationen ausweisen: Arbeitsstatus (z.B. „aktiv“, „wartet auf Ereignis“) Arbeitsschritte (aktueller, Vorgänger, Nachfolger) Bearbeiter Kontext (z.B. parallel laufende Prozesse zum gleichen Ordnungsbegriff oder Ereignis) eingehende und ausgehende Dokumente Termine II.2.3.2.2. Verlauf eines Prozesses Die Auskunft zum Verlauf eines Prozesse soll auf gröberer Ebene in Sicht auf den Gesamtprozeß folgende Informationen ausweisen: bisher durchlaufene Arbeitsschritte getroffene / anstehende Entscheidungen II.2.3.3. Prozeßstatistik Workflow bietet grundsätzlich die Möglichkeit zu einer Vielzahl von Auswertungen und einem sehr weitreichendem Prozeßcontrolling. Die Nutzung dieser Möglichkeiten wird sehr unternehmensspezifisch sein und beeinflußt die Definitionsebene. Auswertungen sollten zumindest möglich sein über: Arbeitszeiten Durchlaufzeiten Wartezeiten Unterbrechungen offene Geschäftsprozesse anstehende und überschrittene Termine 36 © GDV 1999 Workflow-/Vorangssteuerung Formale Beschreibung und Schnittstellen II.3. Workflownahe Dienste Die am Markt verfügbaren Workflowsysteme bieten neben den Funktionen zur Steuerung von Geschäftsprozessen i.a. eine Reihe von Zusatzfunktionen an, die für die Arbeit mit einem Workflowsystem erforderlich sindm aber nicht unbedingt Bestandteil des Workflowsystems sein müssen. In VAA werden diese Funktionen der Dienstebene zugerechnet. Ein Workflowsystem muß dann die Möglichkeit bieten, neben der eigenen Implementierung dieser Funktionen auch diese Dienste zu nutzen. Die Ausarbeitungen zu diesen workflownahen Diensten bedürfen noch der Überarbeitung und sind deshalb nur im Anhang aufgeführt. II.3.1. Termin- / Ereignisverwaltung Ein im Ansatz der WfMC nicht berücksichtigter Komplex von Funktionalitäten ist die Termin/Ereignis-Systematik. Es ist im WfMC-Referenzmodell Aufgabe der Anwendungen (Client Applications), für die entsprechende Ereignisverwaltung und Terminhaltung zu sorgen. Die betreffenden Funktionen werden in den VU häufig benötigt. Darüberhinaus erscheint es möglich, durch die vergleicbaren Aufgabenstellungen der VU eine Termin-/Ereignissystematik zu schaffen, die den Anforderungen mehrerer VU gerecht wird Unter Ereignis soll hier ein plötzlich eintretender, fachlich relevanter Sachverhalt verstanden werden. Ein Ereignis selbst beinhaltet keine Information darüber, wer wie und wann auf dieses Ereignis reagieren muß. Ein Termin ist ein Datum, auf dessen Erreichen eine bestimmte Anwendung in einer definierten Weise reagiert. Ein Termin-/Ereignisverwaltung soll folgende Funktionen unterstützen: Verwaltung von Terminen und Anstoß der betreffenden Aktionen bei Terminerreichung (aktive Terminverwaltung) Möglichkeit der Abfrage von Terminen nach bestimmten Ordnungskriterien (z.B. Benutzer, Ordnungsbegriff, Geschäftsvorfall) Möglichkeit der Terminänderung bereits gesetzter Termine Systematik zur Verwaltung von Standardterminen und Verfügbarmachung eines entsprechenden Metamodells zur Definition von Standardterminen Protokollierungsfunktionen Unterscheidung von individuell gesetzten und Standardterminen Entgegennahme und Speicherung von Ereignissen Entgegennahme der Anforderung eines Ereignisses von Anwendungen Meldung an Anwendungen, daß ein Ereignis eingetroffen ist Unterscheidung von generellen und speziellen Ereignissen II.3.2. Organisationsverwaltung / Organisationsmodell (OM) Eine Workflow-/Vorgangssteuerung sollte so konzipiert sein, daß sie unabhängig von einer spezifischen Organisationsform ist. Sie darf keine Annahmen über die Organisationsstruktur machen. Statt dessen muß die Steuerung Eigenschaften und Informationen über die Organisation über definierte Dienste von einem Organisationsmodell erfragen, welche aus Sicht der Steuerung alle organisationsspezifischen Informationen beinhaltet und abkapselt. Demzufolge präsentiert sich das Organisationsmodell (OM) der Steuerung über seine Dienste, d.h. über sein Interface. Unter dem Begriff Organisationsmodell soll hier sowohl ein Modell der Aufbauorganisation als auch eines der Benutzerverwaltung subsumiert werden. In einer konkreten Anwendungsarchitektur können sich die beiden letztgenannten Modelle jedoch durchaus als eigenständige Komponenten darstellen. Die Einschränkung , daß sich die Workflow-Steuerung nur über das Interface organisationsspezifische Informationen beschafft, hat zur Folge, daß einerseits eine Workflow-Steuerung mit unterschiedlichen konkreten Organisationsmodellen zusammenarbeiten kann und andererseits sich © GDV 1999 37 Formale Beschreibung und Schnittstellen Workflow-/ Vorgangsmanager die Organisationsstruktur ändern kann, ohne daß die Schnittstelle zur Steuerung davon betroffen sein muß. Innerhalb der VAA ist somit das Interface zwischen der Workflow-/Vorgangssteuerung und der Organisationsverwaltung zu normieren. Technisch gesehen bedeutet das, daß die Workflow/Vorgangssteuerung nicht mit den internen Datenstrukturen des Organisationsmodells arbeitet, sondern nur die vom OM anzubietenden API-Funktionen aufruft. 38 © GDV 1999 Workflow-/Vorangssteuerung Anhang II.3.3. Transaktionsverwaltung DV-Systeme, auf denen Anwendungen laufen, kennen nur techniche Transaktionen (DBTransaktionen, TP-Monitor-Transaktionen). Nach Ablauf einer solchen (i.a. kurzen) Transaktin sind die darin erzeugte Daten persistent und freigegeben. Aus fachlicher Sicht ist es aber häufig erforderlich, die Tätigkeiten wesentlich größerer Zeiteinheiten zu einer (fachlichen) Transaktion zusammenzufassen. So ist. z.B. aus fachlicher Sicht eine Antragserfassung erst beendet, wenn sämtliche Daten zum Versicherungsnehmer und zu den beantragten Deckungen vorliegen. Technisch sind in diesem Fall aber schon eine Reihe von Transaktionen abgelaufen. Zur Umsetzung eines solchen Konzepts von fachlichen Transaktionen (Logical Unit of Work, LUW) ist es sinnvoll, eine Transaktionsverwaltung als eigenständige Komponente zu implementieren. Ein wesentliches Konzept ist der Vorgangsspeicher. In ihm werden die Daten eines Vorgangs während einer fachlichen Transaktion gehalten, aus ihm erhalten die Anwendungsbausteine Daten. Die Verwaltung des Vorgangsspeichers erfolgt über die Schnittstelle des Datenmanagers, die möglichen Funktionen werden beim Datenmanager beschrieben. Die Transaktionsverwaltung bedient sich des Vorgangsspeichers, um ihre Funktion zu erfüllen. II.4. Schnittstellen Folgende Schnittstellen sind zu beschreiben: Workflowmanager - DV-Vorgangssteuerung DV-Vorgangssteuerung - Präsentationsmanager DV-Vorgangssteuerung - Anwendungsbaustein Workflowmanager - Dienstsysteme (Terminsystem, Organisationsmodell, Arbeits- und Lastverteilung, Transaktionsverwaltung III. Anhang III.1. vorhandene Produkte und aktuelle Entwicklungen III.1.1. vorhandene Produkte Hier sollten die am Projekt beteiligten Softwarehäuser ihr Produkt kurz vorstellen und hinsichtlich der gestellten Anforderungen bewerten. Außerdem erscheint ein Hinweis auf die neueste Auflage der bekannten DSK-Studie, die zumindest quantitativ einen guten Marktüberblick gibt. III.1.2. Standards und aktuelle Entwicklungen Entscheidende Impulse für Standardiserungsbemühungen im Workflow-Bereich gehen von der Workflow Management Coalition aus, der weltweit die meisten namhaften Hersteller von Workflow-Produkten angehören. Das dort definierte Workflow Reference Model und die darin definierten Interfacec bildeten auch für die Arbeit der Projektgruppe eine wesentliche Grundlage. Weitere workflow-relevante Standardisierungsbemühungen gibt es im Bereich Document Management. III.2. weitere Ausarbeitungen - Stoffsammlung Dieses Kapitel enthält Dokumente, die im Rahmen der Projektarbeit erstellt wurden, aber aufgrund ihres Detaillierungsgrades nicht zum sonstigen Dokuent passen oder noch nicht umfas- © GDV 1999 39 Anhang Workflow-/ Vorgangsmanager send in der Projektgruppe besprochen wurden. Ihre Auf- und Einarbeitung bleibt damit einer späteren Projektphase vorbehalten. III.2.1. Dokument - Dynamischer Ablauf von Geschäftsprozessen III.2.1.1. DV-Vorgang als Grund-Element eines Geschäftsprozesses III.2.1.1.1. Allgemein Ein DV-Vorgang stellt in einem Geschäftsprozeß eine zusammenhängende Arbeitseinheit dar, die für das Gesamtverständnis des Ablaufs von grundsätzlicher Bedeutung ist. Er stellt für die Ausführung der geforderten Prozeß-Aufgaben die notwendigen Instrumentarien bereit, wobei durch eine hohe Integration der Bauteile eine optimierte Unterstützung angestrebt wird. Eine wesentliche Eigenschaft eines DV-Vorganges wird durch das Transaktionskonzept festgelegt: Parallele DV-Vorgänge beeinflußen sich während der Ausführung gegenseitig nicht, da die Ergebnisse eines DV-Vorgangs erst am Vorgangsende für andere DV-Vorgänge verfügbar werden. Ein DV-Vorgang arbeitet während seiner Abwicklung immer auf einer konsistenten Datenbasis, da er nur solche Informationen zur Verarbeitung heranzieht, die zum Vorgangs-Startzeitpunkt schon bekannt waren (dies gilt auch für Daten-Nachforderungen). Es gilt das Alles-Oder-Nichts-Prinzip: entweder wird das geprüfte Vorgangsergebnis in seiner Gesamtheit freigegeben oder insgesamt weggeworfen. Ein DV-Vorgang unterstützt die Durchführung von Einzelverarbeitungen, die voneinander unabhängig abgewickelt werden. Hierbei sollte der Verarbeitungsumfang jedoch eine bestimmte Größenordnung nicht überschreiten, da der Arbeitsstatus in einem Vorgangsspeicher temporär gehalten wird und sämtliche Ergebnisse bei nicht ordnungsgemäßen Abschluß verloren sind. Ein DV-Vorgang kann in verschiedenen Formen auftreten: zur interaktiven Abwicklung eines Teilprozesses im Rahmen einer GeschäftsprozeßBearbeitung, d.h ein Bediener beeinflußt durch seine Eingaben den Ablauf und Umfang der Verarbeitung zur dialoglosen Abwicklung von Teil-Prozessen im Rahmen einer GeschäftsprozeßBearbeitung. Damit ist es möglich, die Verarbeitung vieler Geschäftsobjekte als eine Menge von bedienerlosen Einzelverarbeitungen durchzuführen. Ein DV-Vorgang muß aber nicht unbedingt innerhalb eines Geschäftsprozesses ablaufen, wenn dafür kein fachlicher Grund vorliegt. So können Auskunftsvorgänge oder unwichtigere Aktivitäten, deren Einbindung in einen Geschäftsprozeß nicht notwendig erscheint, auch als losgelöste Einzelprozesse ablaufen. 40 © GDV 1999 Workflow-/Vorangssteuerung Anhang III.2.1.1.2. DV-Vorgänge innerhalb einer Geschäftsprozeß-Bearbeitung Bei der Abwicklung eines Teilprozesses im Rahmen einer Geschäfts-Prezeß-Abwicklung können drei Schritte unterschieden werden: (1) Aufnahme eines Arbeitschrittes Ein Bediener übernimmt einen anstehenden Teilprozeß. der damit den Zustand „in Bearbeitung“ annimmt. Diese Zustands-Änderung des Prozesses sollte nach außen bekanntgemacht werden, wenn eine konkurrierende Zweitaufnahme des Teilprozesses verhindert werden soll. (2) Abarbeitung des Teilprozesses Dahinter steht die inhaltliche Bearbeitung des Teilprozesses durch einen AnwendungsVorgang, der enden kann - mit einer Fortschreibung der Anwendungs-Datenbanken endet - einem Abbruch des Teilprozesses - oder einer Unterbrechung (evtl. mit Weiterleitung) des Teilprozesses (3) Beendigung des Arbeitschrittes Das Ergebnis des Schrittes ist beim Geschäfts-Prozeß zu protokollieren und Folgemaßnahmen sind einzuleiten. Diese 3 Aufgaben können in einem DV-Vorgang zusammengefaßt werden oder ingetrennten DV-Vorgängen abgelegt sein. Dabei sind folgende Konsequenzen zu beachten: (1) + (2) + (3) in einem DV-Vorgang - es wird eine vollständige Ergebnis-Synchronisation erreicht: inhaltliche Ergebnisse Arbeitsschritt-Ende sind entweder beide vollzogen oder nicht. - eine Reservierung des Teilprozesses am Vorgangsstart erfolgt nicht - sinnvoll einsetzbar bei Prozessen ohne Dialogverkehr und ohne konkurrierende Ansteuerung von Teilprozessen - aber: problematisch, wenn WF-DB und Awendungs-DB auf getrennten Plattformen und (1) in einem und (2) + (3) in einem DV-Vorgang - es wird wieder eine vollständige Ergebnis-Synchronisation errreicht - zusätzlich erfolgt eine Reservierung des Teilprozesses bei Vorgangsstart - optimal einsetzbar bei allen Prozessen, da die Ergebnisse der Anwendungsverarbeitung für die Workflow-Steuerung verfügbar sind - aber: problematisch, wenn WF-DB und Awendungs-DB auf getrennten Plattformen (1) und (2) und (3) in getrennten DV-Vorgängen - keine Ergebnis-Synchronisation, d.h. Anwendungs-Datenbanken werden fortgeschrieben und in einem unabhängen Vorgang erst das Arbeitschritt-Ende festgehalten. - eine Reservierung des Teilprozesses bei Vorgangsstart erfolgt - sinnvoll einsetzbar bei Prozessen, für die WF-DB und Anwednungs-DB auf getrennten Rechnern liegen oder bei denen die Workflow-Verarbeitung nicht integrierbar ist mit dem Anwendungsvorgang. © GDV 1999 41 Anhang Workflow-/ Vorgangsmanager III.2.1.2. DV-Vorgänge in Beispiel-Szenarien III.2.1.2.1. Einschrittiger Geschäfts-Prozeß BS Anstoß-Vorgang 1 WF AS-Start 2 WF AN BS Arbeits-Vorgang 3 1. Aus einem Auswahl-Vorgang (oder einem beliebigen Vorgang mit Anstoß-Möglichkeit) heraus wird ein Geschäfts-Prozeß gestartet. Der Auswahl-Vorgang selbst bleibt weiterhin aktiv. 2. Mit dem Start des Teilprozesses wird auch der zugehörige Geschäftsprozeß instanziiert. Der Start der Bearbeitung selbst wird in der WF-Datenbank protokolliert. Dieser WF-Vorgang wird beendet, der Arbeitsvorgang selbst gestartet. 3. Der Arbeits-Vorgang wird durchgeführt, notwendige Anwendungsdialoge werden ausgegeben und bedient. Am Vorgangsende werden die Ergebnisse auf Anwendungs-Datenbanken geschrieben. Anschließend wird das Arbeitschritt-Ende protokolliert. Gleichzeitig wird auch der Geschäftsprozeß abgeschlossen, wenn ein einschrittiger Prozeß vorliegt. Anschließend kann der Bediener die Bearbeitung im ursprünglichen Auswahl-Vorgang fortsetzen 42 © GDV 1999 Workflow-/Vorangssteuerung Anhang III.2.1.2.2. Mehrschrittiger Geschäftsprozess BS Postkorb-Vorg. 1 WF AS-Start 2 WF AN BS Arbeits-Vorgang 3 1. Anstoßvogang wie beim einschrittigen Prozeß 2. Arbeitsschritt-Start wie beim einschrittigen Prozeß 3. Der erste Arbeits-Vorgang wird durchgeführt, notwendige Anwendungsdialoge werden ausgegeben und bedient. Am Vorgangsende werden die Ergebnisse auf AnwendungsDatenbanken geschrieben. Anschließend wird das Arbeitschritt-Ende protokolliert. Der nächste Arbeits-Vorgang wird ermittelt und sein Beginn protokolliert. Anschließend wird dieser Arbeits-Vorgang gestartet. 4. Der Arbeits-Vorgang wird durchgeführt, notwendige Anwendungsdialoge werden ausgegeben und bedient. Am Vorgangsende werden die Ergebnisse auf Anwendungs-Datenbanken geschrieben. Anschließend wird das Arbeitschritt-Ende protokolliert. Gleichzeitig wird auch der Geschäftsprozeß abgeschlossen, wenn ein einschrittiger Prozeß vorliegt. Anschließend kann der Bediener die Bearbeitung im ursprünglichen Auswahl-Vorgang fortsetzen. © GDV 1999 43 Anhang Workflow-/ Vorgangsmanager III.2.1.2.3. Arbeitsaufnahme aus Postkorb 1. Der Postkorb-Vorgang ist ein Auskunfts-Vorgang, der die Worklfow-DB nur liest. In ihm werden Ereignisse ausgewählt, die bearbeitet werden sollen. Die Auswahl führt möglicherweise zu mehreren betroffenen Geschäfts-Prozessen und Teilprozessen, was zu einem zusätzlichen Auswahlbild in diesem Vorgang führen kann. Ist ein Teilprozess zur Bearbeitung ausgewählt, wird ein Start-Vorgang für den Arbeitschritt ausgelöst. 2. Der Start-Vorgang für den Arbeitschritt protokolliert den Start und löst den eigentlichen Anwendungs-Vorgang aus. 3. Der Arbeits-Vorgang wird durchgeführt, notwendige Anwendungsdialoge werden ausgegeben und bedient. Am Vorgangsende werden die Ergebnisse auf Anwendungs-Datenbanken geschrieben. Anschließend wird das Arbeitschritt-Ende protokolliert. Falls in diesem Prozess weitere Arbeits-Vorgänge demselben Sachbearbeiter zugeordnet werden, werden diese direkt zur weiteren Bearbeitung angeboten. Ansonsten wird wieder in den Postkorb-Vorgang verzweigt, um weitere Ereignisse zur Bearbeitung auszuwählen. 44 © GDV 1999 Workflow-/Vorangssteuerung Anhang III.2.1.2.4. Ereignisverarbeitung ohne Dialog BS Anstoß-Vorgang 1 WF Treiber-Vorgang 2 WF AN Arbeits-Vorgang 3 WF AN Arbeits-Vorgang 4 WF AN Arbeits-Vorgang 4 WF Treiber-Vorgang 5 WF AN Arbeits-Vorgang 6 WF AN Arbeits-Vorgang 7 WF Treiber-Vorgang 8 © GDV 1999 45 Anhang Workflow-/ Vorgangsmanager 1. Der Anstoß-Vorgang startet den gesamten Ablauf, indem er einen Treiber-Vorgang auslöst. 2. Der Treiber-Vorgang greift auf die Workflow-DB zu und prüft auf fällige Ereignisse. Hat er ein Paket von Ereignissen ermittelt, startet er die zugehörigen Arbeits-Vorgänge. Zusätzliche startet er einen neuen Treiber-Vorgang 3. In den Arbeits-Vorgängen wird die notwendige Verarbeitung ausgeführt und die Ergebnisse auf die Anwendungs-DB geschrieben. Gleichzeitig wird der Anfang und das Ende des Arbeitschrittes auf der Workflow-DB protokolliert. Die Arbeitsvorgänge werden möglichst parallel ausgeführt, um den Durchsatz zu erhöhen. Treten Fehler auf, werden Meldungsereignisse erzeugt, die diese Fälle SB-Postkörben zur weiteren manuellen Behandlung zuordnet. Da kein Dialog möglich ist, werden notwendige Eingaben von Eingangs-DB beschafft. 4. Der zweite Treiber-Vorgang ermittelt das nächste Paket fälliger Ereignisse und startet auch hierzu die notwendigen Arbeits-Vorgänge. Zusätzlich wird der nächste Treiber-Vorgang gestartet. Dieser Ablauf wird solange wiederholt, bis das letzte fällige Ereignis ermittelt und abgearbeitet ist. 46 © GDV 1999 Workflow-/Vorangssteuerung Anhang III.2.1.3. Vorkommende Vorgangstypen III.2.1.3.1. Auskunfts-Vorgang Lese-Zugriff auf Workflow-DB und/oder Anwendungs-DB mit Dialog-Bedienung keine Fortschreibung von Anwendungs-Daten oder Workflow-Daten III.2.1.3.2. Änderungs-Vorgang Lese-Zugriff Anwendungs-DB mit Dialog-Bedienung Fortschreibung von Anwendungs-Daten durch Arbeitsergebnisse keine Fortschreibung von Workflow-DB III.2.1.3.3. Start-Vorgang für Arbeitschritte Lese-Zugriff auf Workflow-DB ohne Dialog-Bedienung Fortschreibung auf Workflow-DB zur Prozeßprotokollierung III.2.1.3.4. Arbeits-Vorgang mit Dialog Lese-Zugriff auf Anwendungs-DB und bei Bedarf auf Workflow-DB mit Dialog-Bedienung Fortschreibung der Anwendungs-DB durch Vorgangserbenisse Fortschreibung auf Workflow-DB zur Prozeßprotokollierung © GDV 1999 47 Anhang Workflow-/ Vorgangsmanager III.2.1.3.5. Treiber-Vorgang Lese-Zugriff auf Workflow-DB ohne Dialog-Bedienung Fortschreibung auf Workflow-DB zur Protokollierung III.2.1.3.6. Arbeits-Vorgang ohne Dialog Lese-Zugriff auf Anwendungs-DB und Workflow-DB ohne Dialog-Bedienung Fortschreibung der Anwendungs-DB mit Vorgangsergebnissen Fortschreibung auf Workflow-DB zur Protokollierung 48 © GDV 1999 Workflow-/Vorangssteuerung Anhang III.3. Termin- / Ereignisverwaltung Ein im Ansatz der WfMC nicht berücksichtigter Komplex von Funktionalitäten ist die Termin/Ereignis-Systematik. Es ist im WfMC-Referenzmodell Aufgabe der Anwendungen (Client Applications), für die entsprechende Ereignisverwaltung und Terminhaltung zu sorgen. Die betreffenden Funktionen werden in den VU häufig benötigt. Darüberhinaus erscheint es möglich, durch die vergleicbaren Aufgabenstellungen der VU eine Terminsystematik zu schaffen, die den Anforderungen mehrerer (besser aller) VU gerecht wird. III.3.1.1. Funktionale Anforderungen Unter Ereignis soll hier ein plötzlich eintretender, fachlich relevanter Sachverhalt verstanden werden. Ein Ereignis selbst beinhaltet keine Information darüber, wer wie und wann auf dieses Ereignis reagieren muß. Ein Termin ist ein Datum, auf dessen Erreichen eine bestimmte Anwendung in einer definierten Weise reagiert. Wenn im folgenden Text von Anwendungen gesprochen wird, sind damit sämtliche Applikationen „außerhalb“ der Termin-/Ereignisverwaltung, also z.B. auch ein Workflow-System, gemeint. Ein Termin-/Ereignisverwaltung soll folgende Funktionen unterstützen: Verwaltung von Terminen und Anstoß der betreffenden Aktionen bei Terminerreichung (aktive Terminverwaltung) Möglichkeit der Abfrage von Terminen nach bestimmten Ordnungskriterien (z.B. Benutzer, Ordnungsbegriff, Geschäftsvorfall) Möglichkeit der Terminänderung bereits gesetzter Termine Systematik zur Verwaltung von Standardterminen und Verfügbarmachung eines entsprechenden Metamodells zur Definition von Standardterminen Protokollierungsfunktionen Unterscheidung von individuell gesetzten und Standardterminen Entgegennahme und Speicherung von Ereignissen Entgegennahme der Anforderung eines Ereignisses von Anwendungen Meldung an Anwendungen, daß ein Ereignis eingetroffen ist Unterscheidung von generellen und speziellen Ereignissen Generelle / spezielle Ereignisse spezielles Ereignis - Nutzer sind bekannt (einer oder mehrere) und existieren oder werden initiiert generelles Ereignis - hat keinen speziellen Nutzer III.3.1.2. Abgrenzung Die Ermittlung, wann ein Termin zu setzen ist und die Definition, welche Aktion beim Erreichen des Termins erfolgen muß, ist Aufgabe der jeweiligen Anwendung bzw. des WorkflowManagers. Das Terminsystem ist lediglich für die Verwaltung dieser Termine zuständig. Für eine Reihe von Funktionen des Terminsystems wird eine Oberfläche benötigt, die dem Benutzer die Durchführung der verschiedenen Funktionen ermöglicht. Die Bereitstellungdieser Oberfläche ist Sache des Präsentationsmanagers und nicht des Terminsystems selbst. III.3.1.3. Entwurf eines Metamodells Im Unterschied zu den individuell gesetzten Terminen muß es für die Standardtermine ein entsprechendes Metamodell geben. Dieses Metamodell soll so flexibel sein, daß es die Bedürfnis- © GDV 1999 49 Anhang Workflow-/ Vorgangsmanager se der verschiedenen VU abdeckt, und andererseits so konkret, daß sich daraus Funktionen ableiten lassen. Im folgenden Metamodell wird auf den Anhang -typ der verschiedenen Entitäten zugunsten der besseren Lesbarkeit verzichtet. Es handelt sich aber immer (Metamodell !!!) um die beschreibenden Entitäten, nicht um die konkrete Instanz beispielsweise eines Termins. Die Dartellung des Metamodells erfolgt in der Form eines ER-Diagramms. Folgende Entitäten müssen Bestandteil des Metamodells sein, um eine VAA-konforme Termin/Ereignisverwaltung zu beschreiben: Ereignis Termin Zeitpunkt Zeitraum Geschäftsobjekt Orga/Stelle Kalender Ein konkretes System kann selbstverständlich ein wesentlich erweitertes Metamodell besitzen. Ebenso ist eine andere Begriffsverwendung möglich. Wesentlich ist, daß sich die im unten skizzierten Metamodell beschriebenen Daten zuordnen lassen. III.3.1.4. Beschreibung der Entitäten: III.3.1.4.1. Ereignis Ein Ereignis ist das plötzliche Eintreten eines Sachverhaltes. Zu einem Ereignis gehört der Zeitpunkt, zu dem das Ereignis eintritt. Das Ereignis beinhaltet keine Informationen darüber, welche Aktionen bei Eintreten des Ereignisses zu treffen sind. Generelle Ereignisse sind an kein konkretes Geschäftsobjekt geknüpft, sie können Relevanz für ein oder mehrere Geschäftsobjekte besitzen, müssen dies aber nicht. Bei speziellen Ereignissen ist bekannt, für welche Geschäftsobjekte sie relevant sind. III.3.1.4.2. Zeitpunkt Bei einem Zeitpunkt handelt es sich um ein Datum , auf welches sich ein oder mehrere Termine beziehen können. Zeitpunkte wiederum können auf verschiedene Arten definiert werden: abstrakt als Datum (z.B. der letzte Arbeitstag der Jahres) bezogen auf ein zeitliches Ereignis bezogen auf ein (nicht zeitliches) Ereignis Dieses Ereignis kann wiederum verschiedene Bezüge haben. Die drei wichtigsten sind geschäftsprozeßbezogene Ereignisse - kommen im Zusammenhang mit der Bearbeitung eines Geschäftsprozesses zustande (bspw. Datum des Antragseingangs eines Neuantrages zum Geschäftsprozeß Neugeschäft) geschäftsobjektbezogene Ereignisse - kommen im Zusammenhang mit einem Geschäftsobjekt vor (bspw. Datum des Ablaufes einer Lebensversicherungs-Police, Erriechung der 18. Lebensjahres eines VN in der PKV) Anmerkung: Da auch ein Geschäftsprozeß im VAA-Modell ein Geschäftsobjekt darstellt, könnten hier auch die geschäftsprozeßorientierten Ereignisse eingeordnet werden. Die Trennung ist aber durch die herausragende Stellung des Geschäftsprozesses innerhalb der VAA gerechtfertigt. allgemeine Ereignisse. Dies sind Ereignisse, welche für das gesamte Unternehmen (und damit auch für sämtliche DV-Systeme) gültig sind. Eine Unterscheidung in unternehmensspezifische und allgemeine Ereignisse wird hier nicht mehr getroffen, da sie aus Sicht des DVAnwendungssystems gleich behandelt werden. 50 © GDV 1999 Workflow-/Vorangssteuerung Anhang Bsp.: Datum des Versandes der Januarrechnungen, letzter Arbeitstag vor dem 30.04. eines Jahres. III.3.1.4.3. Zeitraum Ein Zeitraum spezifiziert die Dauer von einem Zeitpunkt (Erreichen eines Ereignisses) bis zum Erreichen des konkreten Termines. Bsp: Wenn der Zeitpunkt „Versand der Januarrechnungen“ lautet und der Zeitraum „vier Wochen“, könnte der Termintag „Termin 1. Zahlungserinnerung“ also „vier Wochen nach Versand der Januarrechnungen“ lauten. Ein Zeitraum kann sowohl positiv als auch negativ sein (z.B. „3 Monate vor Fälligkeit“). Ein Zeitraum kann von verschiedenen anderen Daten abhängen. Die genauen Abhängigkeiten sind im Metamodell über Beziehungen dargestellt. III.3.1.4.4. Termin Ein Termin resultiert aus der Verbindung eines Zeitpunktes mit einem Zeitraum und bezeichnet das Datum, zu dem das Erreichen des Termins dem System gemeldet werden muß, welches das Terminsystem mit der Verwaltung des entsprechenden Termins beauftragt hat. III.3.1.4.5. Geschäftsobjekt Ein Geschäftsobjekt wir im vorliegenden Metamodell ausreichend spezifiziert durch den Typ des Geschäftsobjektes und einen entsprechenden Ordnungsbegriff. S.a. Glossar zur VAA III.3.1.4.6. Orga / Stelle S.a. Glossar. Die Orga / Stelle wird hier nur angegeben, um zu verdeutlichen, daß Zeiträume auch abhängig von verschiedenen bearbeitenden Stellen unterschiedlich groß sein können. III.3.1.4.7. Kalender Ein Kalender beschreibt für bestimmte Geschäftsobjekte oder bestimmte Orgas / Stellen, wie Termine berechnet werden. Er berücksichtigt insbesondere verschiedene Feiertagsregelungen Organisationsverwaltung / Organisationsmodell (OM) und Arbeitszeitmodelle. III.4.1.1. Einleitung Eine Workflow-/Vorgangssteuerung sollte so konzipiert sein, daß sie unabhängig von einer spezifischen Organisationsform ist. Sie darf keine Annahmen über die Organisationsstruktur machen. Statt dessen muß die Steuerung Eigenschaften und Informationen über die Organisation über definierte Dienste von einem Organisationsmodell erfragen, welche aus Sicht der Steuerung alle organisationsspezifischen Informationen beinhaltet und abkapselt. Demzufolge präsentiert sich das Organisationsmodell (OM) der Steuerung über seine Dienste, d.h. über sein Interface. Unter dem Begriff Organisationsmodell soll hier sowohl ein Modell der Aufbauorganisation als auch eines der Benutzerverwaltung subsumiert werden. In einer konkreten Anwendungsarchitektur können sich die beiden letztgenannten Modelle jedoch durchaus als eigenständige Komponenten darstellen. Die Einschränkung , daß sich die Workflow-Steuerung nur über das Interface organisationsspezifische Informationen beschafft, hat zur Folge, daß einerseits eine Workflow-Steuerung mit unterschiedlichen konkreten Organisationsmodellen zusammenarbeiten kann und andererseits sich die Organisationsstruktur ändern kann, ohne daß die Schnittstelle zur Steuerung davon betroffen sein muß. © GDV 1999 51 Anhang Workflow-/ Vorgangsmanager Innerhalb einer Anwendungsarchitektur ist somit das Interface zwischen der Workflow-Steuerung und dem Organisationsmodell zu normieren. Technisch gesehen bedeutet das, daß die Workflow-Steuerung nicht mit den internen Datenstrukturen des Organisationsmodells arbeitet, sondern nur die vom OM anzubietenden API-Funktionen aufruft. III.4.1.2. Komponenten eines Organisationsmodells Ein Organisationsmodell kann verschiedene Komponenten umfassen, die jeweils einen logisch eigenständigen Teil des Modells repräsentieren. Jede Funktion des OM-APIs ist einer Komponente zuzuordnen. Im Idealfall könnte ein OM somit aus verschiedenen, prinzipiell unabhängigen Teilen zusammengefügt werden. Ein OM könnte u.a. die unten aufgeführten Komponenten beinhalten. Im folgenden werden die zugehörigen Konzepte beschrieben und schließlich zugehörige Dienste aufgeführt. 52 © GDV 1999 Workflow-/Vorangssteuerung Anhang OM ... Aufbauorganisation Benutzerverwaltung Ressourcen ... III.4.1.3. Konzepte III.4.1.3.1. Aufbauorganisation Die Komponente Aufbauorganisation befaßt sich mit den in einer Organisation definierten Rollen und den Beziehungen zwischen Rollen. In einem abstrakten Modell einer Aufbauorganisation reicht es zu wissen, daß Rollen Ausdrücke sind, deren Struktur und Semantik nur die Aufbauorganisation kennt. Durch die Modellierung von Beziehungen zwischen Rollen kann ein hierarchisches Rollenmodell aufgebaut werden. Beziehungstypen können prinzipiell benannt werden (z.B. „Rolle beinhaltet Rolle“, „Rolle ist Rolle übergeordnet“). Aus Sicht der Workflow-Steuerung ist es unerheblich, wie diese Beziehungen modelliert und abgelegt werden, ja, ob sie überhaupt im OM existieren. Wesentlich ist nur, daß das OM Anfragen der Form „liefere übergeordnete Rolle von ...“ ( etwa Vorgesetzter) beantworten kann. Die interne Struktur muß auch hier hinter API-Funktionen verborgen werden. III.4.1.3.2. Der Begriff der Rolle Eine Rolle ist ein Ausdruck, der eine Gruppe von Benutzern mit gemeinsamen Eigenschaften charakterisiert. Rollen können in verschiedene Kategorien eingeteilt werden. Es könnte beispielsweise unterschieden werden nach Berechtigung, Kompetenz, Zuständigkeit, Stelle oder Organisationseinheit. Innerhalb einer Workflow-/Vorgangsbeschreibung wird einer Aktivität eine Rolle zugeordnet. Unter einer Rolle im Sinne der Workflow-/Vorgangsbearbeitung ist dabei ein Anforderungsprofil zu verstehen, welches an Benutzer gestellt wird. Dieses Anforderungsprofil wird in der Workflow-/Vorgangsbeschreibung abgelegt und kann nur durch das Organisationsmodell ausgewertet werden. Die Auswertung einer Rolle ist also abhängig vom zugrundeliegenden Organisationsmodell und von der Zeit. Das Ergebnis einer solchen Auswertung ist eine Menge von Benutzern. Umgekehrt kann man sagen, daß ein Benutzer, der eine Aktivität ausführen will, der zugeordneten Rolle genügen muß. Es ist demzufolge zu unterscheiden zwischen einer Rolle als abstraktem Ausdruck (wie er statisch in der Beschreibung eines Workflows verwendet werden kann) und der Auswertung einer Rolle als Menge von Benutzern (wie sie dynamisch durch das Organisationsmodell durchgeführt werden kann). III.4.1.3.3. Benutzerverwaltung Die Benutzerverwaltung verwaltet alle in einer Organisation bekannten Benutzer sowie die die Benutzer beschreibenden Attribute und Beziehungen. Ein Benutzer ist ein Aktivitätsträger menschlicher oder nicht-menschlicher Natur (z.B. ein Programm), der in einer Organisation bekannt ist und in Interaktion mit dem System treten kann. Neben personenbezogenen Daten werden beispielsweise Vertreterregelungen innerhalb der Benutzerverwaltung abgelegt. Von besonderem Interesse für die Workflow-Steuerung ist die Information, welche Rollen einem Benutzer zugeordnet sind, wobei ein Benutzer beliebig viele Rollen haben darf. © GDV 1999 53 Anhang Workflow-/ Vorgangsmanager Aus Sicht der Workflow-Steuerung ist ein Benutzer ein potentieller Auftraggeber, der eine Dienstleistung von ihr fordern kann (z.B. Anzeigen von Daten zu einem Geschäftsvorfall) oder in dessen Auftrag eine Dienstleistung ausgeführt werden soll (z.B. Ausführung eines Anwendungsbausteins). Sicherheitsaspekte sind schon im Design eines Geschäftsvorfalls zu berücksichtigen. Bei der Spezifikation einer (sicherheitsrelevanten) Aktivität muß der Designer angeben, welche Rolle zur Ausführung dieser Aktivität benötigt wird. Zur Ausführungszeit eines Geschäftsvorfalls muß die Workflow-/Vorgangssteuerung dann prüfen, ob der aktive Benutzer dieser Rolle genügt. Darüber hinaus hat sie schon bei der Anforderung von Funktionen des User Interface’ zu prüfen, ob der jeweilige Benutzer zur Ausführung dieser Funktion berechtigt ist. Ähnliches kann für die Ausführung von API-Funktionen (etwa durch Programme als Benutzer) gefordert werden. Die minimale Anforderung an die Benutzerverwaltung ist, daß sie Anfragen der Form „Ist Benutzer b berechtigt, Operation op auszuführen?“ beantworten können muß. Eine erweiterte Forderung wäre, daß sie auch Fragen der folgenden Form zu beantworten hätte: “Ist Benutzer b berechtigt, Operation op auf Objekt ob auszuführen?“. Als Objekte wären hier beispielsweise konkrete Geschäftsvorfälle oder Geschäftsvorfälle eines vorgegebenen Typs denkbar. Zur Ausführungszeit eines Geschäftsvorfalls hat die Workflow-/Vorgangssteuerung vor Ausführung einer Aktivität zunächst in Erfahrung zu bringen, welche Rolle benötigt wird, um diese Aktivität auszuführen. Diese Information kann der Aktivität in der Geschäftsvorfallsbeschreibung entweder direkt zugeordnet sein, oder es kann dort die Information abgelegt sein, wie das OM zur Laufzeit nach einer konkreten, hier benötigten Rolle gefragt werden kann. Letzteres ist dann relevant, wenn eine konkrete Rolle dynamisch ermittelt werden muß, etwa in Abhängigkeit von Beträgen bei Auszahlungen oder bei Gebietszuständigkeiten in Abhängigkeit von Ortsangaben wie Postleitzahlen. In einem zweiten Schritt muß die Steuerung dann das OM fragen, ob der gerade aktive Benutzer die (nun ermittelte) Rolle besitzt. III.4.1.3.4. Ressourcen Eine Ressource ist ein Mittel, das eine Dienstleistung ausführen kann oder zur Ausführung einer Dienstleistung benötigt wird. Wie Rollen müssen auch Ressourcen sowohl zur Definitions- als auch zur Ausführungszeit eines Geschäftsvorfalls berücksichtigt werden. Da eine konkrete Ressource im Gegensatz zu einer abstrakten Rolle begrenzt verfügbar sein kann (etwa ein Laser-Drucker, der auf Anforderung zugeordnet und belegt werden kann - im Gegensatz zu einer Berechtigung, die prinzipiell beliebig vielen Benutzer ohne zeitliche Limitierung zugesprochen werden kann), muß „jemand“ im System Informationen über die jeweilige Verfügbarkeit von Ressourcen besitzen. Dies führt zum Begriff des Resource Managers. Aus Sicht der Workflow-/Vorgangssteuerung ist dabei relevant, daß der Resource Manager Auskunft über die Verfügbarkeit von Ressourcen geben kann. Entsprechend müßte sie bei ihm Ressourcen beantragen und auch wieder freigeben. III.4.1.3.5. Beziehungen Es erscheint sinnvoll, die Beziehungen der verschiedenen Komponenten des Organisationsmodells kurz zu skizzieren, um ein gemeinsames Verständnis zu erzielen. Tatsächlich ist für die Steuerungsebene aber nur die Präsentation des OM über seine API-Funktionen nach außen hin relevant. Ein Benutzer wird dem System gegenüber über eine Benutzer-Identifikation (UserId) eindeutig identifiziert. Ein Benutzer kann mehrere Rollen innehaben. Rollen sind nicht benutzerspezifisch. Eine Rolle kann in Beziehung zu beliebig vielen anderen Rollen treten. Es besteht aber keine Notwendigkeit, Beziehungen zwischen Rollen zu fordern. Beziehungen sind benannt und gerichtet, wodurch eine partielle Ordnung definiert wird. In der Benutzerverwaltung muß hinterlegt sein (oder in Erfahrung gebracht werden können), wer berechtigt ist, auf geschützte Objekte (Geschäftsobjekte, Operationen, ...) zuzugreifen, sofern auch Objektschutz modelliert werden soll. Um entscheiden zu können, ob eine Operation erlaubt ist, muß die Benutzerverwaltung wissen, wer was wie benutzen will. 54 © GDV 1999 Workflow-/Vorangssteuerung Anhang Obwohl ein Modell, daß Benutzerinformationen mit denen über geschützte Objekte direkt verknüpft, die gewünschten Informationen bereitstellen könnte (ein triviales System würde jedem Benutzer alle Zugriffe auf sämtliche Objekte erlauben), erscheint es sinnvoll, diese Beziehungen mit Hilfe von Rollen auszudrücken. Dann kann man sagen, daß ein Benutzer berechtigt ist, auf ein Objekt zuzugreifen (also auch eine Operation auszuführen), wenn er eine Rolle hat, die ausreicht (nicht notwendigerweise ‘benötigt wird’), um auf das Objekt zuzugreifen. Diese Rollen muß nicht notwendigerweise unmittelbar mit dem Benutzer verknüpft sein. Vielmehr reicht es im Modell aus, wenn es eine mittelbare Beziehung zwischen dem Benutzer und dem geschützten Objekt gibt, die die Zugriffsberechtigung ausdrückt. Die mittelbare Beziehung zwischen Rollen und geschützten Objekten ist n:m. Rolle/Rolle 0,n 0,n geschütztes Benutzer Benutzer/Rolle 0,n Rolle 0,n Berechtigung 0,n Objekt 0,n Zur Erinnerung: Mit diesem Modell kann z.B. ausgedrückt werden, ob ein Benutzer berechtigt ist, eine Operation auf einem konkreten Geschäftsvorfall oder etwa einem beliebigen Geschäftsvorfall eines bestimmten Geschäftsvorfallstyps auszuführen. Auf einer anderen Ebene, nämlich der der Beschreibung eines Geschäftsvorfallstyps, ist ein geschütztes Objekt etwa eine Aktivität, der dort in der Beschreibung eine Rolle zugeordnet wird. III.4.1.4. Rollenausdrücke Auch wenn es prinzipiell möglich ist, keinerlei Annahmen über Struktur und Semantik von Rollen zu machen, um das Wissen über die Struktur von Rollen und deren Auswertung hinter APIFunktionen zu verbergen, so erleichtern einige Grundannahmen über die Struktur einer Rolle doch den Informationsaustausch zwischen Modellierungswerkzeugen zur Beschreibung von Geschäftsvorfallstypen und der Workflow-Engine einerseits sowie der Workflow-Engine und dem Organisationsmodell andererseits. Im folgenden soll beschrieben werden, aus welchen Komponenten eine (elementare) Rolle aufgebaut sein kann und wie (elementare) Rollen miteinander verknüpft werden können, um somit Rollenausdrücke zu formen. Ein derartiger Rollenausdruck kann dann in einer Beschreibung eines Geschäftsvorfalls verwendet werden und ist damit auch Gegenstand bei der Kommunikation zwischen Workflow-Engine und Organisationsmodell zur Ausführungszeit eines Geschäftsvorfalls. III.4.1.4.1. Aufbau eines Ausdrucks Jede Beschreibung einer Rolle ist als Ausdruck zu verstehen. Jeder Ausdruck kann sich aus Teilausdrücken zusammensetzen, die durch die mengentheoretischen Operatoren Vereinigung, Durchschnitt und Restmenge verknüpft werden. Ein elementarer Ausdruck ist ein Rollenausdruck in Form eines Tupels oder eine Funktion. Für die Auswertung eines Ausdrucks gelten die üblichen Vorrangsregeln: Vorrang() Vorrang() Vorrang( \ ) Bei gleichrangigen Operatoren erfolgt die Auswertung von links nach rechts. Um eine andere Auswertungsreihenfolge zu erzwingen, müssen Ausdrücke geklammert werden. © GDV 1999 55 Anhang Workflow-/ Vorgangsmanager Damit läßt sich ein Ausdruck über Rollen folgendermaßen definieren: A AA ::= | AA | A \ A | (A) | R | F III.4.1.4.1.1. Abkürzungen Hier wie im folgenden sollen folgende Abkürzungen oder terminale Symbole verwendet werden: OM: Organisationsmodell A: Ausdruck R: Rollenausdruck B: Benutzer S: Stelle O: Organisationseinheit K: Kompetenz III.4.1.4.1.2. Elementarer Rollenausdruck Ein elementarer Rollenausdruck ist ein Quadrupel mit den Attributen Benutzer, Stelle, Organisationseinheit und Kompetenz: R ::= (B, S, O, K) In einem allgemeinen Ansatz könnte man jedes Attribut als Ausdruck unter Verwendung der Operatoren Vereinigung, Durchschnitt und Rest sowie von Funktionen über dem zugrundeliegenden Attributwertebereich definieren. Um die Komplexität eines Rollenausdrucks zu reduzieren, sollen jedoch nur Mengen von Attributwerten (was letztendlich Listen mit Attributwerten entspricht) betrachtet werden. Ein exemplarischer Rollenausdruck könnte also folgende Form annehmen: (b, s, ,k1, k2, k3) Dies soll bedeuten, daß dieser Rollenausdruck die Anforderung stellt, daß der Benutzer b, die Stelle s und die drei Kompetenzen k1, k2, k3 (oder sollte es heißen: „mindestens eine der drei Kompetenzen“ ?) vorliegen müssen. An die Organisationseinheit wird in diesem Beispiel keine Anforderung gestellt. 56 © GDV 1999 Workflow-/Vorangssteuerung Anhang III.4.1.4.1.3. Rollenfunktion Eine Rollenfunktion ist entweder eine Standardrollenfunktion oder eine OM-spezifische Rollenfunktion. Eine Rollenfunktion liefert nach ihrem Aufruf eine Liste von Benutzern zurück, was genau der Auswertung der Funktion entspricht. Eine Standardrollenfunktion FS muß für jedes Attribut des bereits erwähnten Quadrupels einen Parameter bereitstellen, welcher eine (ggf. leere) Liste über der Wertemenge des Attributs darstellt. Eine OM-spezifische Rollenfunktion FOM ist bezüglich ihrer Parameter nicht festgelegt und darf somit bspw. auch problemorientierte Parameter beinhalten. Eine derartige Funktion muß also durch ein konkrete Organisationsmodell zur Verfügung gestellt werden. F ::= FS(<B>, <S>, <O>, <K>) | FOM(...) <X> stehe hier für „Liste über den Wertebereich von X“ III.4.1.4.1.4. Standardisierte Rollenfunktionen Gewisse Rollenfunktionen dürften organisationsübergreifend von Bedeutung sein, so daß es lohnenswert sein könnte, diese allgemein zu definieren. Kandidaten für derartige Funktionen sind: Ermittlung aller in Frage kommenden Benutzer zu einer gegebenen Rolle Prüfung, ob ein gegebener Benutzer eine gegebene Rolle hat Ermittlung eines Vorgesetzten zu einem gegebenen Benutzer Ermittlung eines Stellvertreters zu einem gegebenen Benutzer Ermittlung des Leiters einer Organisationseinheit Ermittlung aller im System angemeldeten Benutzer Im Gegensatz zu diesen Funktionen, die durch das Organisationsmodell ausgewertet werden, gibt es andere, die durch die Workflow-Engine bereitzustellen sind, wie etwa: Ermittlung des Benutzers zu einer gegebenen Aktivität Ermittlung des aktuellen Benutzers (als Spezialfall der obigen Funktion) Ob für die Parameter dieser Funktionen nun alle Komponenten des Quadrupels (B, S, O, K) berücksichtigt werden und die nicht benötigten durch die leere Menge bzw. die leere Liste ersetzt werden, oder ob nur der jeweils relevante Parameter berücksichtigt wird, hat nicht mehr als syntaktische Bedeutung. III.4.1.4.2. Offene Probleme III.4.1.4.2.1. Unterscheidung „darf ausführen“/“soll ausführen“ Während durch einen Rollenausdruck in einer Workflow-/Vorgangsbeschreibung spezifiziert wird, daß ein Benutzer zur Ausführung der zugehörigen Aktivität diese Anforderung erfüllen © GDV 1999 57 Anhang Workflow-/ Vorgangsmanager muß, ist noch nicht geklärt, wie man beschreiben kann, daß die Ausführung nur auf einen bestimmten Benutzer oder eine bestimmte Gruppe von Benutzern eingeschränkt werden soll. Es muß jedoch gewährleistet sein, daß die Menge der erwünschten oder bevorzugten Benutzer eine Teilmenge der berechtigten Anwender ist. III.4.1.4.2.2. Rollenbewertung nach Ausführung einer Aktivität Es kann sich die Notwendigkeit ergeben, nach Ausführung einer Aktivität, die ein Ergebnis geliefert hat, in Abhängigkeit dieses Ergebnisses zu prüfen, welche Rolle tatsächlich nötig gewesen wäre, um diese Aktivität auszuführen. Diese Situation kann insbesondere dann entstehen, wenn die Komplexität der Aktivität so groß ist, daß ex-ante keine sinnvolle Rollenbeschreibung festgelegt werden kann. Als Lösung könnte sich anbieten, eine ex-post-Betrachtung ähnlich einem Freigabeverfahren durchzuführen. III.4.1.5. Sicherheitsaspekte Sicherheitsaspekte sind in verschiedenen Bereichen relevant. a) Der Zugang zum Workflow-System kann durch ein Login-Mechanismus geschützt werden. Falls sich das System auf die Authentizität des Benutzers verlassen kann (was etwa ein übergeordnetes System, etwa ein TP-Monitor, zu gewährleisten hätte), könnte das System auch ohne einen solchen Mechanismus auskommen und die jeweilig benötigte Berechtigung dort und dann prüfen, wo und wann sie benötigt wird. b) Bevor das Workflow-System einem Benutzer eine UI-Funktion anbietet, muß das Berechtigungssystem gefragt werden, ob der Benutzer zu deren Ausführung berechtigt ist. c) Sobald eine Workflow-API-Funktion aufgerufen wird, wird das Berechtigungssystem gefragt, ob der Aufruf im Namen des beauftragenden Benutzers (ob menschlich oder nicht) erlaubt ist. d) Wenn Aktivitäten im Geschäftsvorfall ausgeführt werden, muß die Workflow-Engine prüfen, ob der Benutzer die geforderte Rolle besitzt. e) Vor dem Aufruf eines Anwendungsbausteins kann eine Baustein-spezifische Routine (d.h. ein spezifiziertes Prüfprogramm, das etwa dem Baustein direkt zugeordnet ist) aktiviert werden, um organisationsspezifische Sicherheitsaspekte zu überprüfen, die durch das allgemein gehaltene OM möglicherweise nicht abgedeckt werden. f) Innerhalb eines Anwendungsbausteins können prinzipiell benutzerdefinierte Sicherheitsprüfungen stattfinden. g) Daten (Geschäftsobjekte) können durch unabhängige Berechtigungssysteme vor unberechtigtem Zugriff geschützt werden. Während die Punkte a), b) und c) von der Berechtigungs-Komponente als Teil des OMs abgedeckt werden können müssen, wird die Information, die unter d) benötigt wird, zur Ausführungszeit durch die Workflow-Engine vom OM erfragt. Punkt e) könnte von einem Object Request Broker abgedeckt werden. Die Punkte f) und g) sind transparent für eine Vorgangssteuerung. III.5. Transaktionsverwaltung. Unter einer Transaktion wird eine Verarbeitungseinheit bezeichnet, die entweder ganz oder gar nicht durchgeführt wird. Technisch bezieht sich eine Transaktion einmal auf die Operationen, und die Daten, die in definierte Zuständen gehalten werden müssen. Realisieren läßt sich ein solches Konzept dadurch, daß man an bestimmten Punkten der Verarbeitung Konsistenzpunkte definiert, in denen ein Fortsetzen der Verarbeitung im Fehlerfall ermöglicht wird. Der wohl wichtigste Konsistenzpunkt in einer Verarbeitung ist der Endpunkt, an dem eine beliebige, unsyn58 © GDV 1999 Workflow-/Vorangssteuerung Anhang chronisierte Weiterverarbeitung sowohl technisch wie fachlich stattfinden kann, während an anderen Konsistenzpunkten idR. nur die abgebrochene Verarbeitungsfolge fortgesetzt werden kann. Problematisch wird die Sicherstellung stets konsistenter Zustände durch mehrfache Benutzung von persistenten Daten. Ändernde Funktionen können idR nicht gleichzeitig die selben Daten bearbeiten, da ein allgemeiner, intelligenter „Merger“ undenkbar ist, zumal, wenn sogar die selben Datenfelder geändert werden und sodann darüber verfügt werden muß, welcher Inhalt maßgeblich ist. Für die Aufhebung dieser Schwierigkeit sind zwei Methoden gebräuchlich: das Sperr- und das Zeitstempel-Verfahren. Beim Sperrverfahren werden alle Daten, die geändert werden sollen (oder können) für weitere ändernde Zugriffe gesperrt, dies geschieht meist mit Mitteln des jeweiligen Datenbankverwaltungssystems. Bei der Freigabe (Committ) werden die Daten geändert zurückgeschrieben und die Sperren aufgehoben. Wenn das Committ nicht innerhalb einer gewissen Zeitstrecke erfolgt, muß die Entsperrung automatisch erfolgen mit parallelem Rücksetzen des ändernden Vorganges (wenn möglich) oder Verhinderung der Änderung durch diesen. Beim Zeitstempel-Verfahren werden keine Sperren gesetzt und müssen demzufolge auch nicht verwaltet werden, sondern jedes persistente Datenfeld (oder Strukturen aus diesen) wird mit einem Zeitpunkt des letzten Update gekennzeichnet; im Änderungsfall muß geprüft werden, ob die Voraussetzungen (Zustand beim Lesen gleich Zustand zum Zeitpunkt des Schreibens) zutreffen, anderenfalls ist das Update zu unterlassen. Während beim Sperrverfahren, wenn es nicht genügend elementar in Bezug auf die Änderungsbedürfnisse ( uU. bis hinunter auf Feldebene) ansetzt, die Gefahr des (gegenseitigen) Blockierens ansteigt, besteht beim Zeitstempel-Verfahren die Gefahr, u.U. Arbeitsergebnisse zurücksetzen zu müssen, dafür ist es technisch weniger anspruchsvoll. Das grundsätzliche Verfahren der transaktionsgesteuerten Verarbeitung in beiden Varianten läßt es im Prinzip zu, zwischen Transaktionen verschiedener Ordnung, mit jeweils übergreifenden Spannen, zu operieren. Man könnte also quasi zwischen „technischen“ Transaktionen mit der Möglichkeit des Wiederaufsetzens desselben Änderungsvorganges und dessen fachlichem Abschluß unterscheiden (Logical Unit of Work LUW). Bei dieser Vorgehensweise ist aber auch festzulegen, ab wann andere unsynchronisierten Änderungen auf diesen fachlich vorläufigen Daten zulässig sind. Da es idR. zu aufwendig sein wird, zu jeder ändernden Transaktion eine Inverse zu defineren und die meisten Änderungen nicht im Sinne einer Differenz, also auch gültig gegen einen anderen Ausgangswert, handelt, sind solche Inverse für danach durchgeführte Änderungen unbrauchbar. Wenn es aber keinen Mechanismus zum Zurücksetzen von Daten nach abermaliger (Fremd-)Änderung gibt, bleibt nur die Möglichkeit, auch die LUW als technische Transaktion zu klammern. Man kann das Gesamtrisiko dadurch etwas minimieren, das man Teil-Transaktions-Strecken definiert, die aber nur für das Wiederaufsetzen ein und desselben Vorganges dienen (persistenter Vorgangsspeicher). Das heißt unterhalb einer LUW wird der Vorgangsspeicher mit Transaktionsmechanismen exklusiv für eine Instanz eines Vorganges verwaltet, im letzten Teilprozeß dieses Vorganges sind sodann in einer Transaktion die Daten des Vorgangsspeichers in die operativen Daten einzubringen und damit zu veröffentlichen und freizugeben. In der letzten Arbeitskreissitzung in Köln wurde ergänzend zu den Aussagen dieses Papiers über das Konzept und die Arbeits- und Wirkungsweise einer Logical Unit of Work (LUW) diskutiert. Dabei wurden folgende Feststellungen getroffen: 1. Eine LUW ist eine langandauernde Transaktion. Von ihrem Beginn bis zu ihrem Ende sind die von ihr veränderten Daten nicht öffentlich. Die veränderten Daten werden bei einem fachlich oder technisch veranlaßten scheitern der Transaktion auf ihren Ursprungszustand zurückgesetzt. Ist eine LUW abgearbeitet, werden die Daten veröffentlich und sind nur noch durch eigene kompensierende Programme zurückzunehmen. © GDV 1999 59 Anhang Workflow-/ Vorgangsmanager 2. Mit hoher Wahrscheinlichkeit ist innerhalb von LUW´s eine Schachtelung notwendig, z.B: um einzelene Arbeitsschritte innerhalb einer LUW zurücksetzen zu können. 3. Im Ausführungsmodell eines Prozesses sollte unserer Meinung nach der Beginn und das Ende einer LUW definiert und beschrieben werden können. 4. Eine LUW kann 1-n Arbeitsschritte beinhalten. 5. Dieses Konzept hat Auswirkungen auf die Inhalte des Vorgangsspeichers. 6. Eine Umsetzung dieses Konzeptes wäre durch eine Zusammenarbeit von einer WorkflowEngine mit einem TX-Manager und diversen Datenbanken denkbar. Es würde z.B. nach einem ausgeführten Arbeitsschritt die Workflow-Engine aufgerufen um nach dem ihr bekannten Bearbeitungsplan den Folgeschritt aufzurufen. Dabei stellt die Engine fest, daß eine LUW beginnt. Sie teilt dies einem TX-Manager, der fortan alle Aktivitäten des assoziierten Programmes mit Datenbanken über deren XA-Schnittstelle monitort. Folgearbeitsschritte derselben LUW werden mit identischer TX-Kennung dem TX-Manager mitgeteilt. Sollte die LUW nicht zu einem fachlich und technisch konsistenten definierten Endpunkt gelangen, wird der Dienst der TX-Manangers in Anspruch genommen alle Veränderungen von Daten zurückzunehmen. Wiederum kommuniziert der TX-Manager mit den diversen Datenhaltungssystemen über die XA-Schnittstelle. 60 © GDV 1999
