Workflow Management: Definitionen, Hintergründe und Best-Practice

Transkript

1 Workflow Management: Definitionen, Hintergründe und Best-Practice Johannes Kern Torsten Straßer In letzter Zeit hat sich in vielen Bereichen der Anwendungsentwicklung für Geschäftsanwendungen das Schlagwort Workflow als Lösungsansatz etabliert und aktuelle Systeme werden unter der Bezeichnung workflow-basiert vermarktet. Oft wird dieser Begriff aber für Anwendungen verwendet, welche in vielerlei Hinsicht nicht der Definition eines Workflow Management Systems (WfMS) entspricht. Eine Beurteilung der tatsächlichen Nutzung eines workflow-basierten Ansatzes eines Programmpaketes ist ohne Kenntnisse der Funktionsweise und des Aufbaus eines WfMS kaum möglich. Dieser Artikel soll dem Leser das nötige Grunwissen über WfMS liefern um es ihm dadurch zu ermöglichen, ein qualifiziertes Urteil über workflow-basierte Geschäftsanwendungen zu treffen. Dazu werden die Standards und Definitionen von WfMS vorgestellt und im zweiten Teil die Grundlagen der Implementierung eines Workflow-Management-Systems beschrieben und anhand eines Beispiels verdeutlicht. Workflow-Management Eines der "Zauberworte" in der Informatik dieser Tage ist das "Workflow-Management". Oberflächlich betrachtet versteht man unter Workflow-Management die Organisation wiederkehrender Arbeitsabläufe innerhalb eines Teams (eine exakte Definition findet sich im Abschnitt Definitionen ). Selbst wenn der Begriff an sich innerhalb eines bestimmten Unternehmens noch nie gefallen ist, sind in er Regel bereits eine Vielzahl von festgelegten Arbeitsabläufen vorhanden. Computerbasiertes Workflow Management versucht diese bestehenden Abläufe nun diese unter anderem zu automatisieren, zu priorisieren, zu steuern und dank des neuen Mediums auch zu optimieren. Das Ziel hinter der Einführung von Workflow-Management und deren EDV-technische Unterstützung, ist die Kostenreduzierung duch Automatisierung und Optimierung der Arbeitsabläufe. Wie verschiedene Studien bereits aus den Anfängen des kommerziellen Workflow-Managements belegen, wurde dieses Ziel auch bereits erreicht und es zeigt sich, daß zumindest in größeren Unternehmen Workflow-Management hilft, Geld zu sparen [1]. Der Optimierung von Workflow- Prozessen kommt dabei ein großes Gewicht zu. Alltägliche Aufgaben können in Workflow-Systemen Schritt für Schritt eingebunden werden. Anschließend kann das oftmals unübersichtliche Gesamtsystem mit Hilfe von geeigneten mathematischen Verfahren ressourcenoptimal reorganisiert werden. Dadurch ist es möglich, sowohl die technischen, wie auch die menschlichen Ressourcen effizienter auszulasten. Neben diesen Optimierungsaufgaben kommt die Technik jedoch auch besonders bei der optimalen Kooperationskoordinierung zum Einsatz. Workflow-Prozesse sind, auch wenn diese Tatsache auf den ersten Blick fast trivial erscheint, sind massiv nebenläufig. Eine Vielzahl von Personen (oder allgemeiner: Ressourcen) arbeiten oftmals zeitgleich an einem gemeinsamen Ziel. Dies ist sowohl für die Analyse von Workflow-Prozessen als auch für die Implementierung von Workflow-Managment-Systemen eine wichtige Rahmenbedingung.

2 Die Workflow Management Coalition (WfMC, wurde 1993 mit dem Ziel einer kontrollierten Verbreitung und Benutzung der Workflow Management Technologie ins Leben gerufen. Sie ist eine non-profit Organisation, deren Dokumente von der Industrie weitgehend akzeptiert werden. Einen besonders wichtigen Aspekt der Arbeit der WfMC stellt die Spezifikation der fünf funktionalen Schnittstellen für die Integration verschiedener Workflow- Managment-Systeme dar. Viele Definitionen und Vorgaben zum Thema Workflow stammen von der WfMC, welche auch mit anderen bekannten Standartisierungsorganisationen (z.b. der Object Management Group und der Black Forest Group) zusammen arbeitet. Die in Kapitel 1 behandelten Themen sind weitgehend konform zu den von der WfMC definierten Standards. Definitionen Die (nicht technische) Informatik kämpft oft mit dem Problem, dass Begriffe verwendet werden, deren Definition nicht eindeutig festgelegt ist. Die Nutzung dieser Begriffe in der Literatur ist daher oftmals schwierig und führt teilweise sogar widersprüchlichen Aussagen. Im Gegensatz dazu hat es die WfMC verstanden, einen Standart zu etablieren, an welchen sich fast alle Publikationen und auch Produkte orientieren. Im folgenden werden die wichtigsten Begriffe im Umfeld von WfMS vorgestellt. Die Definitionen orientieren sich dabei an den in [5] festgelegten Vorgaben der WfMC. In [5] wird der Geschäftsprozess (Business Process) definiert als: A set of one or more linked procedures or activities which collectively realise abusiness objective or policy goal, normally within the context of an organisational structure defining functional roles and relationships. Workflow: The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. [5]. Für die Abbildung von Arbeitsabläufen durch Workflows ist es notwendig ein System von Aufgaben und Rechten einzuführen. Ein solches System wird heute im allgemeinen nur noch in Ausnahmefällen personenbezogen realisiert, sondern basiert in stattdessen auf sogenannten Rollen (Role), welche Personen oder Ressourcen bestimmten Gruppen zuordnen. Dies erleichtert das Workflow- bzw. das Rechtemanagement massiv besonders die Modellierung von Workflows und parallelen Arbeitsschritten wird erheblich vereinfacht. Teilnehmer (Actor) sind schlichtweg die Personen, die Aktivitäten erledigen also die Arbeiter. Eine erweiterte Definition schließt auch maschinelle Resourcen oder Anwendungen wie zum Beispiel Batchjobs mit ein. In Zusammenhang mit Rollen werden für Teilnehmer oft auch sogenannte Eskalationsstrategie definiert, wie z. B. bei Ausfall eines Teilnehmers. Im einfachsten Fall führt dies zu einem Stau bzw. Stillstand eines Workflows. Dieses Problem muß bei allen Aktivitäten berücksichtigt werden. Neben den Definitionen werden in [5] auch Diagramme präsentiert, welche die Zusammenhänge und die Zuordnungen der einzelnen Begriffe zueinander übersichtlich darstellen. An dieser Stelle sei noch einmal auf die hohe Qualität dieses Dokument verwiesen. Die WfMC definiert ein Workflow-Management-System (WfMS) wie folgt: A system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications. [1] Diese Definition bedeutet für gute WfMS ganz konkret:

3 Ein gutes Workflow-Management-System muss Workflow-Prozesse vom Anwender frei modellieren lassen. Dies bedeutet, dass die exklusive Integration von statischen Workflow- Prozessen nicht ausreichend ist. Das dafür nötige weitergehende Konzept beinhaltet viele Schnittstellen, auf die später im entsprechendne Abschnitt Schnittstellen noch genauer eingegangen wird. Das WfMS ist in der Lage, Aktivitäten auch automatisch zu erfüllen, d. h. eine Interaktion mit einer Person ist nicht erforderlich. Die Koordinierungsfunktion, die ein WfMS für manuelle Aktivitäten wahrnimmt, geht weit über das Versenden von einfachen Arbeitsanweisungen hinaus. Hat ein Teilnehmer bis zum Verstreichen einer Deadline eine Aufgabe nicht erfüllt, so kann das WfMS eine alternative Workflow-Route (oder einen alternativen Teilnehmer) suchen. Die Aufgabe wird dem entsprechenden Teilnehmer entzogen und einem anderen zugeordnet. Die Vergabe von Aufgaben an Rollen und nicht an Personen erleichtert diese alternativen Verteilungen; dieses Konzept alleine genügt jedoch noch nicht. Auf Basis dieser Anforderungen sind nahezu perfekte Lösungsansätze möglich: Denkbar wäre z.b. ein selbstlernendes System, das die empirisch ermittelten Bearbeitungszeiten der einzelnen Resourcen in die Verteilungsalgorithmik der Aufgabe einfließen lässt. In dieser Richtung sind noch weitere Lösungsansätze denkbar, die das Gesamtsystem verbessern. Dabei müssen perfekte Verteilungsalgorithmen nicht zwangsweise zu einer komplexeren Anwenderschnittstelle respektive zu unübersichtlichen Programmen führen. Gerade das ist es, was computerbasiertes Workflow-Management so interessant macht! Terminologie von Workflow-Diagrammen Für die Beschreibung von Workflow-Prozessen haben sich verschiedene symbolische Beschreibungssprachen etabliert. Einige elementaren Bausteine von Workflow-Diagrammen sollen hier nun mit ihrer symbolischen Repräsentation aufgelistet werden. Alle Begriffe wurden von der WfMC offiziell festgehalten und in [5] veröffentlicht. Als oft verwendete Alternative zu den nun folgenden Modellierungsmethoden werden oft auch Petri-Netze verwendet [6] oder ebenso syntaktischen Modellierungsmethoden der UML, insbesondere die der Aktivitätsdiagramme [8]. Neben diesen verschiedenen Möglichkeiten haben sich einzelne Softwareprodukte auch schon mit ihrer eigenen Notation etabliert. Daher sollte dieser Abschnitt nur als Empfehlung oder als gutes Beispiel für die symbolischen Repräsentationen von Workflow-Prozessen betrachtet werden. Allen Systemen ist aber wiederum gemeinsam, dass sie entweder die gleichen Symbole verwenden oder für jedes der Symbole lediglich eine alternative Darstellungsform verwendet. Begriff Aktivität Eine oder mehrere Aktivitäten bilden einen Geschäftsprozess. Eine Aktivität ist ein Stück Arbeit, dass entweder von einem Computer koordiniert und von einer Person erledigt wird (manuelle Aktivität) oder auch direkt von einem Computer erledigt werden kann (automatisierte Aktivität oder Batch Aktivität). Datenfluss Der Daten- bzw. Informationsfluss innerhalb eines Workflow Dokumentes wird durch einfach Pfeile visualisiert. Datenflüsse finden zwischen Aktivitäten statt. Bedingte Entscheidungen (Decision Point) Um Workflow Diagramme dynamisch gestalten zu können, gibt es auch bedingte Entscheidungen. Ein Datenfluss wird demnach in Abhängigkeit einer Bedingung gestellt. Symbolische Repräsentation oder wichtig? nein ja

4 Begriff AND/OR Split Prinzipiell können bei Workflows parallele Vorgänge gestartet werden: Nach einer Aktivität folgt ein AND-Split. (Hinweis: Besonders an dieser Stelle unterscheiden sich die unterschiedlichen Diagrammtypen häufig. Alternative z.b. Fork ) Bedingte Entscheidungen können auch innerhalb einer Aktivität zu verschiedenen Ausgaben führen. Der OR-Split realisiert dies. AND/OR Join Der AND Join dient dazu, parallele Vorgänge wieder zu synchronisieren. Der Join wird erst vorgenommen, wenn alle Aktivitäten beendet sind. Der OR Join hingegen ist für nicht parallele Abläufe gedacht und realisiert deswegen auch keine Synchronisation. Start und Ende eines Workflows Hierfür wurden zwei sehr einfach Symbole gewählt, die keine Informationen über den Erzeuger oder den Auslöser geben. OR-Split Symbolische Repräsentation OR-Join... AND- Split AND- Join Ereignis (Event) Ein Ereignis führt dazu, dass ein Workflow Prozess angestoßen wird. Ein Event besteht aus zwei Elementen: Der Trigger gibt an, was die Voraussetzungen für das Eintreten des Events sind. Dem Trigger folgt eine Aktion (Action). Sonderaktivitäten Zur einfacheren Visualisierung von unübersichtlichen Diagrammen werden Sonderaktivitäten eingefügt, die eigentlich nicht existieren. Das nebenstehende Beispiel verdeutlicht den Vorteil. Tabelle 1: Begriffe und Symole Als Symbol werden oft eindeutige Bilder gewählt. Ein Beispiel könnte eine Person einen Brief schreiben, der dann per Post zugestellt wird. A1 A2 A3 Johannes Kern Musterstrasse Schwabmünchen SA A4 A5 A6 oder A1 A2 A3 A4 A5 A6 Schnittstellen Für moderne WfMS ist es von zwingender Notwendigkeit, daß sie Möglichkeiten bieten externe Systeme anzubinden. WfMS dürfen nicht mehr nur auf die Abarbeitung der einzelnen Workflows fixiert sein, sondern müssen sich vielmehr in bestehende Softwareinfrastrukturen einbinden lassen, um Geschäftsprozesse voll abbilden zu können. Der Wunsch nach Konsolidierung hat auch den Bereich der Unternehmenssoftware erreicht. Kein Unternehmen kann es sich leisten, zwei parallele WfMS zu betreiben, nur weil die im CMS integrierte Workflow Engine keine Interaktion mit anderen Programmen erlaubt. Um die Interoperabillität eines WfMS zu externen Systemen oder auch anderen WfMS zu gewährleisten, hat die WfMC fünf Schnittstellen definiert, in denen die Kooperation verschiedenster Workflow-Komponenten und verschiedener WfMS geregelt ist. Im folgenden werden diese Schnittstellen vorgestellt. Die folgende Grafik (Abbildung 1) verdeutlicht die Nutzung der Schnittstellen eines WfMS. Interface 1 regelt die Veränderung der Workflow-Prozesse, die von der Workflow-Engine verwaltet werden. Neben dem Interface wird hierfür auch eine Möglichkeit benötigt, Prozesse mittels einer Sprache zu beschreiben. In [7] werden die verschiedenen, im folgenden genannten, Sprachen näher beschrieben und ihre Fähigkeiten verglichen.

5 XPDL XML Process Definition Language WSFL Web Service Flow Language BPML Business Process Modelling Language Interface 2 und 3 werden WAPI's (Workflow APIs and Interchange Formats) genannt und regeln den überwiegenden Teil der regulären Kommunikation. Interface 4 ist für den Inter- Abbildung 1: Schnittstellen eines WfMS Engine -Workflow verantwortlich. Er ist in acht verschiedene Levels eingeteilt und ermöglicht unternehmensübergreifende Workflows. Ein Beispiel für die Anwendung unternehmensübergreifender Workflows ist die enge Einbindung von Zulieferen in die Automobilindstrie [12 und weitere]. Interface 5 dient der Prüfung, Beobachtung und Überwachung von Workflows und deren Teilnehmer. Einen detailierten Überblick über die Interfaces liefern [5] und [1]. In [5] werden u.a. auch Begriffe wie Workflow-Application verbindlich und eindeutig definiert womit Namenskonflikte mit den Detaildokumenten der Interfaces oder anderen Autoren vermieden werden. Diese Begriffsdefinitionen sind als vorbildlich innerhalb des IT-Sektors zu betrachten. Mathematische Modelle Die Abbildung von Geschäftsprozessen durch Workflows bietet viele Ansätze der Optimierung und dadurch die Möglichkeit einer Steigerung der Effizienz. Neben den Innerhalb von Workflow Prozessen gibt es eine Menge von Ansätzen zur Optimierung der Effizienz. Neben der Betrachtung der Organisationsstrukturen und der Verbesserung der Arbeitsabläufe dieser durch zum Beispiel Business Process Engineering [13], existieren auch rein mathematische Methoden für die Optimierung der Geschäftsprozesse. Diese oft komplexen und häufig auch auf das Spezialproblem zugeschnittenen Optimierungsmethoden werden hier nur ergänzend erwähnt und beschrieben. Spezielle Algorithmen zur Optimierung von Workflows finden sich in [9]. Die Grundlage von Netzwerkflüssen und ähnlichen verwandten Themen (wie auch Workflows) bildet die mathematische Graphentheorie. Eine Einführung in deren Funktionsweise kann in vielen Werken aus dem Umfeld der theoretischen Informatik gefunden werden (z.b. [10] oder [11]). Ein allgemein verwendbarer Algorithmus zur Optimierung in Workflow Prozessen ist dagegen die Partitionierung. In [2] finden sich u. a. dazu gut nachvollziebare Studien und Beispiele. Die theoretischen Überlegungen, welche sich auf die Hintergründe von Petrinetzen beziehen, lassen sich ebenso auf Workflows anwenden. Bei genaueren Betrachtungen kann sogar festgestellt werden, daß die Elemente von Petrinetzen denen von Workflows sehr ähneln. Da Petrinetze schon seit langem fester Bestandteil der theoretischen und der angewandten Informatik sind, scheint es sinnvoll deren Konzepte auf das Workflow-Management zu übertragen. In [3] wird z. B. empfohlen, Petrinetze mit ereignisgesteuerten Prozeßketten (EPK) zu kombinieren.

6 Workflow-Management-Systeme Während der erste Teil dieses Artikels Grundlagen und Definitionen von Workflows beschrieben hat, soll nun im zweiten Teil auf das Herzstück eines Workflow-Management-Systems eingegangen werden: der Workflow-Engine. Die Workflow-Engine ist für die Abarbeitung der aus einzelnen Aktivitäten aufgebauten Workflows zuständig. In den letzen Jahren hat eine Evolution der WfMS stattgefunden. Dabei werden vier verschiedene Generationen unterschieden (vgl. [13]): 1. Generation: Hierbei handelt es sich um Applikationen, die oft nur einen einzigen Typ von Vorgängen bearbeiten können. Die Ablauflogik ist dabei fest in der Programmlogik verdrahtet. Es wird so nur eine Art Pseudo-Workflow erlaubt. 2. Generation: Bei Systemen dieser Art wird die fest kodierte Ablauflogik durch eine Beschreibunggssprache, der sogenannten Workflow-Definition-Language (WDL) ersetzt. Die definierten Workflows werden somit deutlich flexibler und können unabhängig vom WfMS definiert werden. 3. Generation: Hier nutzt das WfMS die Vorteile der Datenbanktechnik, wie Sicherheit und Transaktionskonzepte. Je nach Implementierung werden nur Log-Daten oder auch die kompletten Protokoll- und Kontrolldaten der Workflows in der Datenbank gehalten. 4. Generation: Zusätzlich zu den Eigenschaften der vorhergehenden Generationen wird hier Client-Server-Prinzip durch die Verwendung von Object-Management-Systemen, wie sie von der Open Management Group (OMG) beschrieben werden, genutzt. Die Konzepte der WfMS basieren auf der Zusammenfassung von Ideen aus vier verschiedenen Anwendungsklassen (siehe [13]): Operative Anwendungen zur Ablaufsteuerung Dokument-Management-Systeme Kollaborationsanwendungen ( , etc.) Integrierte Bürosysteme Oft sind WfMS auch direkt aus der Weiterentwicklung verschiedener Anwendungen dieser Klassen hervorgegangen. Dies erklärt, daß vor allem im Bereich der Content-Management-Systeme, einer Ausprägung der Dokument-Management-Systeme, WfMS schon früh Einzug hielten. Aufbau und Aufgaben eines WfMS Anders als Leymann und Roller [4], werden in Abbildung 2 Transaktionen und Message Queue nicht nur zwischen dem WfMS und dem DBMS eingesetzt, sondern ebenso in der Kommunikation zwischen den Client-Anwendungen. Dies gewährleistet die Erfüllung der Anforderungen an eine sichere und zuverlässige Kommunikation auch bei Fehlern.

7 Abbildung 2: Standard Schematischer Applications Aufbau WfMS Interfaces Distributed Transactions Workflow Management Message Queuing Database Management Operating System Wie im vorhergehenden Teil beschrieben, erlauben definierte Schnittstellen (Abbildung 1) eine Kommunikation mit Client-Anwendungen, Applikationen und sogar anderen WfMS. Wie bereits angedeutet, basieren moderne WfMS auf einen verteilten Client-/Server-Ansatz. Dadurch ergeben sich eine Reihe von Anforderungen für die Implementierung eines solchen System (vgl. [14]): 1. Dezentrale Architektur: Das System sollte nicht von zentralen Ressourcen wie Datenbanken oder Servern abhängen, da sich sonst die Möglichkeit eines sogenannten single-point-of-failure ergibt und das ganze System abstürzen könnte. 2. Heterogenität: Ein WfMS sollte unabhängig von Hardware-Plattformen, Betriebssystemen und anderen Softwareumgebungen sein. 3. Interoperabillität: Bestehende Anwendungen müssen in Workflow-Prozesse integrierbar sein. 4. Skalierbarkeit: Eine steigende Auslastung durch z. B. eine hohe Anzahl von Workflow-Instanzen darf zu keiner Performanzverschlechterung führen. 5. Dynamische Ressourcenzuordnung: Wie im ersten Teil bereits beschrieben, muß ein WfMS ein Rollenmodell bieten, daß auch eine dynamische Zuordnung von Rollen zu Aktivitäten und Eskalationsstrategien unterstützt. Im Zentrum eines WfMS steht die Workflow-Engine. Abbildung 3 zeigt die Aufgaben der Workflow-Engine, die im folgenden näher beschrieben werden: Integration von manuellen und automatischen Aktivitäten: Schnittstellendefinition zu externen Aktoren Anbindung der Aufbauorganisation: Beschreibung von organisatorischen Zuordnungen, dynamische Zuordnung von Rollen zu Personen, Überwachung der Business Rules Scheduling von Workflows: Auswahl des aktuellen Workflows, Aktivierung des Kontrollflusses zwischen Workflows, Zeitüberwachung, Deaktivierung/Aktivierung Workflow-Datenverwaltung: Da-tenversorgung der Workflow-Instan-zen, Verwaltung persistenter Daten (Workflow-Ergebnisse / -Parameter), Speicherung persistenter Kontexte, Ablaufhistorie Workflow-Reposistory: Verwaltung der Workflow-Schemata und Inte-gritätsbedingungen, Definition der Abhängigkeiten zwischen Aktivitäten Zugriffskontrolle: Authentifikation und Autorisierung, Kontrolle des Rechtetransfers Unter den gerade beschriebenen Gesichtspunkten bearbeitet die Workflow-Engine die als Workflows umgesetzten Geschäftsprozesse. Die Workflows definieren hierbei eine Ablauflogik, die von der Workflow-Engine dynamisch, innerhalb vorgegebener Grenzen, abgeändert werden kann, um zum Beispiel eine optimale Ressourcenauslastung zu erreichen oder eine Eskalation durchzuführen. Ein Workflow-Instanz, d. h. eine konkrete Ausprägung einer Workflow-Definition, besitzt verschiedene Zustände und erfährt während ihrer Abarbeitung Zustandsübergänge zwischen diesen. Die folgende Grafik zeigt die möglichen Zustände und die Übergänge zwischen diesen.

8 Initiate Eine Workflow-Definition legt eine Reihe von Aktivitäten und deren Beziehungen, d. h. ihre Abarbeitungs-reihenfolge fest. Nach dem Starten eines Workflows bearbeitet die Workflow-Engine alle in der Workflow-Definition festgelegten Aktivitäten. Aktivitäten werden in der Regel als Programmfragmente, seltener als ganze Applikationen, realisiert. Sie sind der Teil eines WfMS, welcher die eigentliche Arbeit verrichtet. Aktivitäten können von der Workflow-Engine selbst ausgeführt werden, oder aber sie beauftragt eine andere Instanz mit der Ausführung dieser. Auch Aktivitäten besitzen verschiedene Zustände, welche von der Ausführenden Einheit kontrolliert Start Suspend / Resume Initiated Suspended Inactive Start Restart Suspend / Resume Suspended Running Complete Active Terminate / Abort Terminated Active Iterate through all Activities (1 or more activity instances) Completed werden. Die Ergebnisse einer Aktivität werden von der Workflow- Engine ausgewertet und bestimmen den weiteren Weg der Ausführung der Workflow-Instanz und die Eingaben für die nächste Instanz. WfMS von DISO 2 Bei DISO 2 handelt es sich um eine Neuentwicklung einer Branchensoftware für Druckereien und papierverarbeitende Unternehmen. DISO I hat sich zu einem Quasistandard in der Branche etabliert, soll nun jedoch nach mehr als zehnjärigen Einsatz durch DISO 2 abgelöst werden, um die Anforderungen, welche an moderne Anwendungen gestellt werden, zu erfüllen. Neben vielen anderen Features soll unter anderen auch der gesamte Ablauf der Verarbeitung auf einen workflowbasierten Ansatz umgestellt werden, wofür sich die bisher bereits vorhandenen Geschäftsprozesse dieser Branche sehr gut eignen. DISO 2 ist eine in Java entwickelte Client-/Serveranwendung. Die erfüllt die für moderen WfMS geforderte Unterstützung der Heterogenität, welche besonders in der Druckindustrie einen wichtigen Erfolgsfaktor darstellt, da hier viele IBM Systeme mit AS/400 als Betriebssystem/Datenbank-Kombination arbeiten und die Serverkomponenten von DISO 2 auch unter diesem lauffähig sein sollten. Herzstück von DISO 2 ist neben einer ausgeilten Persistenzschicht die Workflow-Engine. Sie ist als eine multithreaded Anwendung implementiert, die mit den Clients über Remote Method Invocation (RMI), dem Java Pendant zum Remote Procedure Call, kommuniziert. Alternativ kann jedoch auch eine Erweiterung für Java's Java Message Service angebunden werden. Die Client-Applikation ist als sogenannter Fat-Client realisiert, d. h. er enthält die gesamte Anwendungslogik, die in diesem Fall aus einzelnen Modulen wie z. B. Kalkulation, Konstruktion, Kundenverwaltung oder CRM besteht. Zentrales Element in der Client-Applikation ist jedoch eine sogenannte Todo-Liste, welche die Aktivitäten, die einem Benutzer zugewiesen worden sind, enthält. Diese Aktivitäten lösen in der Regel nach dem Aufruf durch den Benutzer die Bearbeitung eines Vorgangs in einem der einzelen Module aus.

9 Die Zuweisung von Aktivitäten an Benutzer erfolgt wie üblich durch ein rollenbasiertes System, daß jedoch um ein ausgefeiltes Berechtigungskonzept erweitert wurde. Eine Aktivtät wird einem Benutzer nicht nur zugwiesen, weil er Mitglied einer bestimmten Rolle ist, sondern er muß auch die nötigen Berechtigungen besitzen, um mit den Daten arbeiten zu können, die mit der Aktivität verbunden sind. Neben den Aktivitäten, welche für die Ausführung von Benutzern bestimmt wird, sogenannte Client-Activities, existieren noch zwei weitere Typen von Aktivitäten: ServerActivities und RoboClientActivities. Beide sind dafür gedacht, den Aufruf von Batch-Jobs zu erlauben, also Arbeiten die unabhängig von Benutzer ablaufen. Beispiele hierfür sind der automatisierte Ablauf von Programmen oder Aktivitäten, welche von Maschinen (z. B. Druckmaschinen) ausgeführt werden. Im Gegensatz zu ServerActivities werden RobotClientActivities nicht direkt von der Workflow-Engine ausgeführt, sondern an sogenannte RobotClients, delegiert, die deren Ausführung übernehmen. Dies erlaubt eine Aufweichung der monolithischen Struktur des WfMSs und verhindert, daß ein Problem in einer Aktivität zum Absturz der gesamten Workflow-Engine führt. Demzufolge sollten ServerActivities nur in Ausnahmefällen verwendet werden. Realisiert werden Aktivitäten durch Javaklassen, welche alle eine gemeinsame Schnittstelle durch Generalisierung einer abstrakten Oberklasse implementieren. Diese abstrakte Oberklasse Abstract wird noch einmal unterteilt in die drei Kindklassen AbstractServer, AbstractRobotClient und AbstractClientActivit. Dies ermöglicht der Workflow-Engine den Ausführungsort einer Aktivität zu bestimmen, d. h. ob sie durch die Engine selbst, durch den Client oder durch einen RobotClient ausgeführt werden soll. Client-Aktivitäten implementieren zusätzlich noch eine Schnittstelle, die deren Ausführung im Applikations-Client erlaubt. Dieser Ansatz erlaubt eine größtmögliche Flexibiliät der Funktionalität der Aktivitäten. Der Austausch von Daten zwischen Aktivitäten und zwischen Aktiviäten und Workflow-Engine erfolgt dabei über einen gemeinsamen Kontext, der für alle Aktivitäten und die Workflow-Engine schreib- und lesbar ist. Die Modellierung von Workflows erfolgt durch einen ebenfalls in der Client-Applikation als Modul integrierten Workflow-Definer. Er bietet eine graphische Oberfläche, welche ähnliche Notationen zu den von der WfMC beschriebenen nutzt. Daneben verfügt er über ein Repository von Aktiviäteten, denen die vorher beschriebenen Klassen zugeordnet sind. Der Workflow-Definer verfügt auch die Möglickeit einer Überprüfung der Zusammenarbeit verschiedener Aktivitäten anhand eines Regelwerks, das als Metadefinition (in XML) zu jeder Aktivität vorhanden ist. Ein Beispiel hierzu wäre der Test, ob die Ausgänge der Vorgängeraktivität zu den Eingängen der aktuellen Aktivität passen. Die Workflow-Engine führt diesen Test während der Ausführung ebenfall durch, um die semantische Integrität der Workflows zu gewährleisten. Die Workflow-Definitionen werden in einer XML-Syntax über die Persistenzschicht in einer Datenbank gespeichert und können auch mittels der Workflow-Definition-Language XPDL exportiert werden. Fazit Obwohl Workflow-Systeme schon seit einigen Jahren als eine der Schlüsseltechnologien für die moderne Entwicklung von Geschäftsanwendungen gehandelt wird, ist ein großflächiger Einsatz dieser bis heute noch nicht eingetreten. Neben organisatorischen und den teilweise immer noch vorhandenen technischen Schwierigkeiten bei der Implementierung, liegen die Hauptprobleme für die Einführung von Workflow-Systemen wohl im sozialen Bereich. Im orgisatorischen Bereich begründen sich die Probleme für die Einführung eines WfMS vor allem in der Modellierung von Geschäftsprozessen in Workflows, da diese oft auch eine Neuordnung der Unternehmensstrukturen nötig macht. Ein weiterer Hinderungsgrund, der vorallem auf Erfahrungen aus der Anfangszeit der WfMS basiert, ist die problematische technische Implementierung der meisten WfMS: Diese sind in der

10 Regel monolithisch aufgebaut, d. h. sie besitzen einen zentralen Server. Neben Problemen bei der Ausfallsicherheit führt dies auch zu hohen Anforderungen an die Hardware des Systems. Hier können aber Ansätze wie agenten-basierte WfMS [15] Abhilfe schaffen. Das wohl am schwierigsten zu beseitigende Problem ist die soziale Komponente der Einführung eines WfMS. In der Regel befürchten Mitarbeiter eine zu starke Überwachung ihrer Arbeit und eine Einschränkung in Ihrer Entscheidungsfreiheit. Hier kann nur eine konsequente Aufklärungsarbeit zu einer Lösung führen. Trotz dieser Herausforderungen haben sich WfMS vorallem im Bereich des E-Commerce bereits stark etabliert und auch in geschäftskritischen Anwendungen führen die Vorteile dieser Systeme zu einer immer größer werdenen Verbreitung. Referenzen [1] Rob, A.: Workflow: An Introduction, [2] Homik, M: Ressourcenoptimierung von Workflow Problemen, Diplomarbeit, Universität des Saarlands [3] Molt D., Rodenhagen J.: Ereignisgesteuerte Prozeßketten und Petrinetze zur Modellierung von Workflows, Universität Hamburg und Informatec Nord GmbH [4] Leymann F., Roller D.: Workflow-based applications, IBM Systems Journal, 1997 [5] Workflow Management Coalition: Terminology & Glossary, [6] Oberweis, A.: Modellierung und Ausführung von Workflows mit Petri-Netzen, Teubner Verlagsgesellschaft, Leipzig, 1996 [7] Barklage, K.: XML und Workflows, Seminarpaper, Technische Universität Kaiserslautern, 2003 [8] Braun, C.: Entwicklung eines Workflow-Management-Systems basierend auf UML- Aktivitätsdiagrammen, Diplomarbeit, Institut für Informatik Universität München, 2002 [9] Kim, S.: Modellierung von Workflow-Prozessen in der Radiologie, Diplomarbeit, Fachbereich Informatik Universität Hamburg, 2003 [10] Stork, B.: Systemtheorie I, Skript zur Vorlesung, Fachbereich Informatik Fachhochschule Augsburg [11] Hagerup, T.: Informatik III, Skript zur Vorlesung, Lehrstuhl für Theoretische Informatik Universität Augsburg [12] Lange, B.: So flutscht die Arbeit, in ix 04/1998, Seite 103 ff. [13] Rininsland, P.: Geschäftsprozesse im Internet am Beispiel der Versicherungswirtschaft, Diplomarbeit, Institut für Telematik Universität Karlsruhe, 1997, Seite18 ff. [14] Schill, A. und Mittasch Ch.: Workflow Management Systems on Top of OSF DCE and OMG CORBA, 1996 [15] Stormer, H. und Knorr, K.: AWA Eine Architektur eines agenten-basierten Workflow- Systems, Institut für Informatik Universität Zürich, 2001,