Referenzgeschäftsprozesse und Strategien im E-Commerce

Forschungsgruppe Unternehmensmodellierung

Workflows

08.07.2021

Abbilden von Geschäftsprozessen auf Workflows


Überblick Ansatz Geschäftsprozessmodellierung Workflowmodellierung Abbildung der Konzepte Implementierungssaspekte Literatur Version zum Ausdrucken

Grundlagen - Workflowmodellierung

Dieser Abschnitt gibt eine Einführung in grundlegende Konzepte, Technologien und Standards im Bereich des Workflow Managements.

WfMC und Workflow Spezifikationssprachen

Die Workflow Management Coalition (WfMC) wurde 1993 gegründet und ist eine Allianz von Unternehmen und Organisationen, die sich mit dem Thema Workflow Management beschäftigen. Die Zielsetzung der WfMC liegt in der Festlegung einheitlicher Begrifflichkeiten im Workflow Management und der Etablierung standardisierter Schnittstellen. Diese Schnittstellen beziehen sich sowohl auf die Definition, die Durchführung, die Verwaltung von Workflows als auch auf die Referenzierung externer Dokumente und Anwendungen [Jung01, S. 126 ff]. Die Konzeptualisierung der verschiedenen Schnittstellen ist im nachfolgend abgebildetetn WfMC-Referenzmodell dargestellt. Der Kern des Referenzmodells [Holl95] umfasst die so genannten Workflow-Enactment-Services, die eine oder mehrere Workflow-Engines zur Ausführung von Workflows verwenden. Eine Workflow-Engine ist eine Software, die Workflows verwalten und entspr. einer gegebenen Workflowdefinition ausführen kann.

WfMC-Referenzmodell [Holl95, S. 20]

Die fünf verschiedenen Schnittstellendefinitionen (Interfaces) hängen mit der Integration verschiedener externer Gesichtspunkte zusammen:

Schnittstelle 1 spezifiziert den Austausch von Workflow-Modellen zwischen externen Modellierungsprogrammen und einem Workflow Management-System. Externe Programme können grafische oder textbasierte Editoren für Workflow-Definitionen sein. Allgemein einsetzbare Modellierungsprogramme, die den WfMC-Standard unterstützen, können ebenfalls für die Spezifikation von Workflows verwendet werden [Holl95, Seite 20].
Schnittstelle 2 beschreibt den Datenaustausch zwischen einem WfMS und einer Workflow-Client-Anwendung. Workflow-Client-Anwendungen sind Programme, die eng mit der Workflow-Engine selber in Beziehung stehen. Üblicherweise bieten Sie grundlegende Funktionalitäten wie Nachrichtendienste und Datentransfer [Holl95, S. 31 ff].
Schnittstelle 3 setzt die notwendige Integration von externen Programmen um. Üblicherweise werden die notwendigen Funktionen nicht vollständig durch das WfMS zur Verfügung gestellt. Folglich muss es eine Schnittstelle zu anderen Programmen geben, die bereits im Unternehmen eingesetzt werden [Holl95, S. 35 ff]. Beispiele für solche Programme sind betriebliche Anwendungssoftware und spezifische Werkzeuge.
Ziel von Schnittstelle 4 ist die Integration von anderen Workflow Management Systemen. Die Spezifikation sieht den Aufruf entfernt stattfindender Aktivitäten, Datentransfer sowie Möglichkeiten zur Synchronisation zwischen verschiedenen Workflow-Enactment-Services vor. [Jung01, S. 126] [Holl95, S. 41 ff].
Schnittstelle 5 beschreibt die Kommunikation zwischen Workflow-Enactment-Dienstleistungen und externen Kontroll- bzw. Verwaltungswerkzeugen.

Schnittstelle 1 ist der Teil des WfMC-Referenzmodells, der für die Abbildung von Geschäftsprozessmodellen auf Workflows am wichtigsten ist. Hier werden verschiedene Arten von Workflows (Prozessen) sowie assoziierte Organisationseinheiten und Anwendungen definiert. Die system-spezifische Integration von Anwendungen wird mit Hilfe der Schnittstelle 2/3 umgesetzt [Holl95, Seite 20].
Die Workflow Prozess-Defintions-Sprache (Workflow Process Definition Language (WPDL)) war der erste Versuch der WfMC einen Standard für den Austausch von Workflowdefinitionen zu spezifizieren. Als Standard für Austauschmodelle stellt es keine graphische Notation zur Verfügung. Inzwischen wurde WDPL durch die XML Prozess Definitions Sprache (XPDL), eine XML-basierte Dokumentendefinition für Workflows, ersetzt (siehe [Nori02]).

Top

XML Prozess Definitions Sprache (XPDL)

Das Metamodell (siehe folgende Abbildung) stellt die von XPDL unterstützten Konzepte dar. Dieses Metamodell enthält statische Entitäten (z.B. Daten oder Anwendungen) und dynamische Konzepte (Prozesse). Statische Entitäten werden repräsentiert durch die Metatypen

Workflow Relevant Data (Workflow-relevante Daten),

Workflow Participant Specification (Workflow-Teilnehmer-Spezifikation) und

Workflow Application Declaration (Workflow-Anwendungs-Deklaration).

Workflow-relevante Daten werden initialisiert, erzeugt, von externen Anwendungen gelesen und während des Ablauf des Workflows verwendet [Nori02, Seite 10]. Sie können bspw. durch einen Vorgang in einem Workflow erstellt oder aus externen Datenquellen (z.B. einem Unternehmensinformationssystem) gewonnen werden. Das Erstellen von neuen Datensätzen oder das Digitalisieren von Dokumenten sind mögliche Datenquellen im Workflow-Kontext. Beispiele für externe Datenquellen sind gemeinsame Datenbanken, die relevante Daten für ein Unternehmen enthalten.
Die Workflow-Teilnehmer-Spezifikation beschreibt die Ressourcen, die einen gegebenen Workflow-Prozess ausführen [Nori02, S. 9]. Sie muss sich nicht zwangsläufig auf Menschen oder eine einzelne Person beziehen. Sie repräsentiert vielmeher eine abstrakte Ressource oder Rolle, die von einer oder mehreren Personen sowie einer Maschine ausgefüllt werden kann. Dennoch steht Workflow-Participant immer für eine in einer Organisation verfügbare Resource bzw. für eine in Entität in einem Organisationsdiagramm. Die Workflow-Anwendungsdeklaration beschreibt die Softwareanwendungen, die für die Ausführung von Workflow-Prozessen benötigt werden [Nori02, Seite 9]. Diese Anwendungen werden in der Regel durch die Workflow-Engine initiiert und Workflow-relevante Daten werden dabei als Parameter übergeben. Beispiele für Workflow-Anwendungen sind interne Anwendungen sowie externe Anwendungen wie zum Beispiel betriebliche Informationssysteme oder gemeinsame Büroanwendungen. Interne Anwendungen werden i.d.R. als Teil des Workflow-Management-Systems bereit gestellt oder können mit Hilfe proprietärer Entwicklungsumgebungen oder -sprachen selbst erstellt werden.

XPDL Metamodell [Nori02, S. 12]

Eine Workflow-Prozess-Definition besteht aus der Beschreibung statischer Entitäten (Daten, Anwendungen, Teilnehmer) und des dynamischen Systemverhaltens. Dynamische Aspekte des Metamodells werden durch die Entitätstypen Transition Information sowie Workflow Process Activity und die folgenden konkreten Subtypen repräsentiert:

Block Activity (Blockaktivität),
Atomic Activity (Einzelaktivität) und
Sub-Process Definition (Subprozessdefinition).

Unter einer Aktivität wird eine bestimmte Arbeitseinheit verstanden, die von einem Teilnehmer (Participant) unter Verwendung bestimmter Anwendungssoftware und relevanter Daten ausgeführt wird (siehe [Nori02, S. 8]). Zudem ist jede Tätigkeit durch einen Anfangs- und Endzeitpunkt charakterisiert sowie dadurch, ob sie automatisch durch das WfMS ausgeführt werden kann oder durch einen Workflow-Teilnehmer ausgeführt werden muss. Die Transitionsinformation (Transition Information) spezifiziert den Kontrollfluss zwischen den einzelnen Aktivitäten [Nori02, S. 9]. Sie besteht aus einer Anfangs- und Endaktivität und einer Bedingung unter der die Transaktion durchgeführt wird. Eine atomare Tätigkeit ist eine unteilbare Arbeitseinheit, die in einem Durchgang erledigt werden muss. Eine Subprozess-Definition erlaubt das Einbetten einer anderen Workflow-Prozess-Definition. Ein Tätigkeitsblock besteht aus einem Satz von weiteren Tätigkeiten (Typ Activity Set). Die Semantik eines Tätigkeiten-Satzes ist ähnlich zu dem eines Makros. Wenn ein Satz von Tätigkeiten während der Ausführung eines Workflow-Prozesses aufgerufen wird, werden die Tätigkeiten, die in dem Satz enthalten sind, in die aufrufende Prozessdefinition kopiert [Mato03, Seite 13].

Top

Grundlegende Workflowkonzepte

Aktivitäten und Transitionen sind die wichtigsten Konzepte für die Beschreibung dynamischer Aspekte in Workflow-Systemen. Aktivitäten entsprechen festgelegten Arbeitseinheiten, die entweder atomar sind oder aus einer Menge von Aktivitäten bestehen. Der Kontrollfluß zwischen Aktivitäten wird mit Hilfe von Transitionen spezifiziert. Folglich definiert eine Transitionsbeziehung die Reihenfolge zwischen zwei Aktivitäten. Eine Aktivität kann gestartet werden, wenn seine Vorgänger-Aktivitäten (verbunden über Transitionen) beendet sind. Transitionen, Aktivitäten und statische Entitäten werden zu sogenannten Workflowprozessdefinition zusammen gefasst.

Workflowprozessdefinitionen

Eine Workflowprozessdefinition fasst alle Element zusammen, die für die Ausführung eines Workflows wichtig sind. Das Meta-Modell macht deutlich, dass diese Elemente dynamische (Aktivitäten und Transitionen) und statische Aspekte (Daten, Anwendungen, Teilnehmer) beinhalten. Zusätzliche Attribute sind eindeutige Bezeichner, ein Name und zwei Header:

Der Prozess Header umfasst das Erstellungsdatum, eine textuelle Beschreibung und verschiedene zeitbezogene Eigenschaften eines Workflowprozesses (z.B. geschätzte Durchlaufzeit).
Der re-definierbare Header besteht aus Informationen zu dem Autor der Prozessdefinition, einem Länder-Code, dem Veröffentlichungsstatus, verantwortlichen Teilnehmern und einer Versionsnummer.

Eine Aktivitätenmenge (activity set) besteht aus Aktivitäten und Transitionen. Alle Transisitonen in einer Aktivitätsmenge können nur von den in der Menge enthaltenen Aktivitäten aus starten und in diesen enden. In anderen Worten: es gibt keine Transitionen, die die Aktivitätenmenge verlassen oder von Außen kommen. Die Eigenschaften (Attribute) eine Aktivitätsmenge sind eine Liste von Aktivitäten, eine Liste von Transistionen und ein eindeutiger Bezeichner.

Workflowprozessaktivitäten

In der untenstehenden Abbildung werden die verschiedenen Arten von Aktivitäten eine Workflowprozessdefinition aufgelistet. Eine atomare Aktivität ist ein unteilbare Verrichtungseinheit, die gesteuert vom WfMS ausgeführt wird. Eine solche Aktivität kann automatisch ausgeführt werden oder durch einen Teilnehmer (human participant) und nutzt i. A. workflowrelevante Daten. Eine Blockaktivität führt eine Aktivitätsmenge aus und hat kein eigenes Verhalten. Der Aufruf einer Aktivitätsmenge ist mit dem Starten der ersten Aktivität in der Menge gleichzusetzen. Die Ausführung endet mit der letzten Aktivität der jeweiligen Aktivitätenmenge (siehe untenstehende Abbildung, [Nori02, S. 30]). Eine so genannte route activity ist eine Aktivität ohne Verhalten. Sie dient nur dazu bestimmte Transitionsbedingungen abzubilden (siehe weiter unten).

Verschiedene Aktivitäten in XPDL [Nori02, S. 30]

In XPDL ist nur ein allgemeines XML-Element für Aktivitäten vorgesehen (Activity). Spezifische Elemente für Block- oder Route-Aktivitäten gibt es nicht. Die Differenzierung der verschiedenen Aktivitätstypen wird über die Annotation alternativer Attribute unterstützt. Diese Attribute sind Route, Implementation und BlockActivity. Zusätzlich können Aktivitäten bzgl. ihres Automatisierungsgrades (automatisch vs. manuell) sowie der Implementierungsalternativen (keine Implementierung, Werkzeug oder 'subflow') spezifiziert werden:

Eine automatisierte Aktivität kann durch die Workflow Engine vollständig unter Verwendung interner und externer Anwendungen gesteuert werden.
Manuelle Akivitäten erfordern die Einbindung einer Person.
Die so genannten no-implementation Aktivitäten können durch das WfMS nicht unterstützt werden. Sie sind üblicherweise manuelle Aktivitäten, die ohne die Unterstützung des WfMS ausgeführt werden können.
Eine werkzeuggestützte Implementierung impliziert die Nutzung einer Anwendungssoftware.
Ist der Implementierungstyp auf subflow gesetzt, so muss die Ausführung an eine andere Workflowprozessdefinition weiter delegiert werden. Hierbei können Parameter mitgegeben werden und die Art der Synchronisation kann spezifiert werden. Bei synchroner Ausführung muss der aufrufende Prozess warten, bis der aufgerufene Prozess beendet ist. Der aufgerufene Prozess könnte bspw. nach der Beendigung Parameterwerte an den aufrufenden Prozess übergeben. Während einer asynchronen Ausführung muss der aufrufende Prozess nicht auf den aufgerufenen Prozesse warten und die Übergabe von Parameterwerten durch den aufgerufenen Prozess ist nicht möglich.

Zusätzliche Informationen für Aktivitäten sind 'Deadlines' und Simulationsinformation:

Eine Deadline beschreibt den Ablauf einer fest gelegten Zeitdauer (z.B. ein Meilenstein im Projektmanagement oder ein sonstiger Termin). Das Auftreten einer Deadline kann synchron behandelt werden (d.h. die aktuelle Aktivität wird unterbrochen) oder asynchron (d.h. die Behandlung der Deadline kann parallel zur aktuellen Aktivität statt finden).
Die Simulationsinformation enthält Hinweise bzgl. der Simulation eines Modells. Beispiele sind Durchschnittskosten, erwartete Dauer und durchschnittliche Wartezeiten.

Wie in der obigen Abbildung gezeigt wird, kommen bei jeder Aktivität verschiedene Transitionen zusammen (join elements) und es gibt eine Menge von ausgehenden Transitionen (split elements). Eingehende Transitionen (join) und ausgehende Transitione (split) können jeweils entweder parallel oder alternativ ausgeführt werden. Alternativ ausgehende Transitionen (XOR) spezifizieren, dass genau eine der Transitionen ausgeführt werden darf. Alternativ eingehende Transitionen werden zur Synchronisation alternativ ausgehender Transitionen (split) verwendet. Die parallele Ausführung von Aktivitäten wird mit einem AND-split begonnen (d.h. parallele ausgehende Transitionen) und mit einem AND-join beendet (d.h. parallel eingehende Transitionen). Einschränkungen bzgl. der parallelen oder alternativen Verbindungen können über so genannte conformance classes spezifiziert werden:

Eine NON-BLOCKED conformance class stellt keine formale Bedingungen an die Verknüpfung von parallelen und alternativen ein- oder ausgehenden Transitionen.
Eine LOOP-BLOCKED conformance class erfordert, dass der Graph der aus den Aktivitäten gebildet wird, ein gerichteter azyklischer Graph ist (DAG).
Eine FULL-BLOCKED conformance class stellt die Bedingung, dass es zu jedem AND-split genau ein AND-join gibt, sowie zu jedem XOR-split genau ein XOR-join. Zusätzlich wird gefordert, dass jeder Pfad, der von einem Split ausgeht, das zugehörige Join erreichen muss.

Transitionen

Eine Transition beschreibt zumindest einen Teil des Kontrollflusses zwischen Aktivitäten. Die Information darüber, ob die ein- oder ausgehenden Transitionen alternativ oder parallel sind, wird der jeweiligen Aktivität zugeordnet. Zusätzliche Information über eine Transition wird in dem so genannten transition information-Element festgehalten. Dieses beinhaltet:

den Namen (d.h. eine Zeichenkette),
eine textuelle Beschreibung und
eine Bedingung.

Während die Beschreibung natürlichsprachlich formuliert wird, sollte die Bedingung zumindest semi-formal die Umstände für das Schalten einer Transition in einem boolschen Ausdruck spezifizieren. Zusätzlich wird hier der Start- und Endknoten festgehalten. Folglich wird jede Transition über genau eine Ursprungs-Aktivität (from) und genau eine Ziel-Aktivität (to) und einen boolschen Ausdruck, der die Schaltbedingung spezifiziert, beschrieben. Es gibt vier verschiedene Arten von Bedingungen in XPDL:

CONDITION: Eine Transition kann schalten, wenn die Bedingung als wahr ausgewertet wird.
OTHERWISE: Benennt eine Transition, die immer dann geschaltet wird, wenn keine andere Transition sich als wahr erweist.
EXCEPTION: Dies ist eine besondere Transition, die bspw. eine spezielle Bedingung anstoßen kann.
DEFAULTEXCEPTION: Wird angestoßen wenn alle anderen EXCEPTION conditions als 'false' ausgewertet wurden.

Top

Weitergehende Workflowkonzepte

Workflows werden von eine WfMS verwaltet und ausgeführt indem bestimmte Aufgaben (als Teil einer Workflowinstanz) einer bestimmten Ressource zugeordnet werden. Solch eine Ressource kann entweder eine Person sein (human participant) oder eine Workflowanwendung. Ein 'Human Participant' entspricht i. A. einer Rolle, die von einer bestimmten Person im Unternehmen eingenommen wird. Eine Workflowanwendung kann entweder intern vom WfMS bereitgestellt werden oder unabhängig vom WfMS über geeignete Schnittstellen verfügbar gemacht werden.

Da mit XPDL systemunabhängige Workflowbeschreibungen erstellt werden sollen, stellt XPDL nur abstrakte Konzepte für die Zuordnung von Humanressourcen und Softwareanwendungen bereit.

Workflow Participants

Entsprechend der XPDL-Spezifikation sind Workflowteilnehmer (Workflow Participants) "an abstraction level between the real performer and the activity, which has to be performed" [Nori02, p. 43]. Die Workflow Engine muss jeden abstrakten Teilnehmer (participant) auf einen Benutzer aus der Umgebung des WfMS abbilden. Die Beschreibung eines abstrakten Teilnehmers beinhaltet einen eindeutigen Namen und Typ. Mögliche Typen von Workflow-Teilnehmern sind:

RESOURCE: Eine spezifische Ressource, die dem WfMS zur Verfügung steht.
RESOURCE_SET: Eine Menge von Ressourcen.
ROLE: Ein Rollenbezeichner, der direkt mit einer Rolle in der Organisation übereinstimmt. Dies kann bspw. eine Funktion oder eine bestimmte Qualifikation sein.
ORGANIZATIONAL_UNIT: Ein beliebiges Element aus einem Organigramm.
HUMAN: Eine Person, die direkt mit dem WfMS interagiert (z.B.: 'John Miller')
SYSTEM: Eine Softwareanwendung, die als Teilnehmer in einem vollständig automatisierten Workflow auftritt.

Über das 'Performer'-Attribut einer Aktivität können diese Teilnehmer einer Aktivität in einem Workflow zugeordnet werden.

Workflow-Anwendungsdeklaration

Workflowanwendungen können in interne und externe Anwendungen unterteilt werden [Jung01]:

Eine interne Workflowanwendung wird als Teil des WfMS implementiert. Sie werden i. A. mit Hilfe einer proprietären Programmiersprache implementiert, die vom WfMS bereit gestellt wird. Im Rahmen von XPDL werden diese Anwendungen Prozeduren ('Procedures') genannt.
Eine externe Anwendung ist ein unabhängiges Softwarepaket, welches von dem WfMS genutzt wird.

In XPDL wird eine Workflowanwendung über einen eindeutigen Bezeichner, seinen Typ und die Liste der Parameter spezifiziert. Wie die Beschreibung der Workflow-Teilnehmer entspricht der Bezeichner einer Anwendung auch nur einem symbolischen Verweis. Die Interpratation eines solchen Verweises muss von dem jeweiligen WfMS übernommen werden. Es gibt WfMS die nur interne, nur externe oder auch beide Arten von Anwendungen unterstützen [Jung01].

Top