| Abbildung der Konzepte |
|
|
Auf dieser Seite präsentieren wir die Abbildung von Konzepten der Geschäftsprozessmodellierung auf Workflow-Beschreibungen in XPDL.
|
| Workflow-Prozessdefinitionen |
|
Im Allgemeinen besteht jede Workflow-Prozessdefinition in XPDL aus Aktivitäten, Transitionen, Anwendungen, Teilnehmern und allgemeinen Eigenschaften eines Workflows. Somit umfasst solch eine Workflow-Prozessdefinition relevante Aktivitäten und entsprechende Ressourcen. Zusätzlich besteht eine Workflow-Prozessdefinition aus zwei unterschiedlichen Headern und einem Body. Die beiden Header sind der Definitions-Header und der neu definierbare Header (re-definable header). Der Definitions-Header eines Workflow-Prozesses ist gültig für alle Teilaktivitäten, der neu definierbare Header kann durch so genannte Subflows überschrieben werden. Die folgende Tabelle fasst die Hauptelemente der Workflowprozessdefinition in XPDL noch einmal zusammen:
|
|
| Definitions-Header |
- Meta-Informationen eines Prozesses und
- Instanzenspezifische Daten
Z.B.: Version, temporäre Einheit, geschätzte Dauer, Priorität
|
| Neu definierbarer Header |
- Meta-Informationen eines Workflow-Prozesses
- Eigenschaften können in Subprozessen überschrieben werden
- Z.B.: Autor, Publikationsstatus
|
| Aktivitätenmenge |
- Menge von Aktivitäten und Transitionen
|
|
| Definitions-Header für Workflow-Prozesse |
|
Attribute eines Definitions-Headers für Workflow-Prozesse sind in der Tabelle auf der rechten Seite aufgelistet1. Das Erstellungsdatum wird einer Prozessdefinition während ihrer Definition zugeordnet und repräsentiert somit die Definitionszeit eines Workflow-Schemas. Diese Information kann dem MEMO-OrgML unterstützenden Modellierungstool entnommen werden und ist nicht Teil der MEMO-Sprachspezifikation. Die Workflow-Prozessbeschreibung kann als Beschreibung des Prozesses der obersten Ebene einer Dekompositions-Hierarchie in MEMO-OrgML angesehen werden.
|
|
Die Gülitg-von- und Gültig-bis-Attribute erlauben die Spezifikation einer Zeitspanne für die Gültigkeit einer Prozessdefinition. Somit kann eine Prozessdefinition nur zwischen gültig von und gültig bis genutzt werden (ein leerer String bedeutet unbegrenzte Gültigkeit). Da MEMO-OrgML kein äquivalentes Konzept aufweist, wird stets von einer unbegrenzten Gültigkeit für alle Prozesse ausgegangen. Die anderen Attribute enthalten nur Informationen zu Workflow-Instanzen. Die Dauer- und Grenzattribute (die Grenze muss durch ein spezifisches WfMS interpretiert werden und hat im Kontext von XPDL keine Bedeutung) beinhalten die erwartete Dauer der Ausführung des gegebenen Workflow-Prozesses durch die Nutzung einer spezifischen Dauereinheit. Die Zeitschätzung ist eine Aggregation von Warte- und Arbeitszeit sowie der Dauer. Die Wartezeit bezieht sich auf die Vorbereitungszeit einer Prozessausführung, während die Arbeitszeit mit der erwarteten Ausführungszeit korreliert. Diese Konzepte sind in MEMO-OrgML nicht enthalten und müssen den Prozessmodellen hinzugefügt werden.
|
|
| Erstellungsdatum (meta) | Erstellt (Erstellungsdatum) |
| Prozessbeschreibung | Beschreibung |
| - | Dauer & Dauereinheit |
| - | Grenze (anbieterspezifisch) |
| - | Priorität |
| - | Zeitschätzung |
| - | Gültig von/bis |
| - | Wartezeit |
| - | Arbeitszeit |
|
|
| Neu definierbarer Header für Workflow-Prozesse |
|
Die Attribute eines neu definierbaren Headers für Workflow-Prozesse sind in der Abbildung auf der rechten Seite aufgelistet. Die Meta-Informationen über den Autor und die Version eines Modells können aus den im Modellierungstool verfügbaren Daten abgeleitet werden. Die Annotation einer Codepage hat einen eher technischen Grund; sie spezifiziert die Zeichenmenge, die zur Präsentation von Text genutzt wird. Länderschlüssel werden durch die ISO im ISO 3166 Standard spezifiziert. Der Publikationsstatus gibt an, ob eine Prozessdefinition in Revision (UNDER_REVISION), veröffentlicht (RELEASED) oder im Einsatz (UNDER_TEST) ist. Verantwortlich bezieht sich auf die für die Ausführung eines gegebenen Workflow-Prozesses verantwortliche Organisationseinheit. Die verantwortliche Person bzw. Rolle kann von der Organisationseinheit im MEMO-Diagramm abgeleitet werden.
|
|
| Modellierer (meta) | Autor |
| - | Codepage |
| - | Länderschlüssel |
| - | Publikationsstatus |
| Organisationseinheit | Verantwortliche(r) |
| Version (meta) | Version |
|
|
| Generierung von Headern |
|
XPDL-Workflow-Header beinhalten Informationen über einen Workflow-Prozess (z.B. Autor, Version), Prozessinformationen (z.B. Beschreibung, Verantwortliche) und Informationen zu Instanzen (z.B. Dauer, Zeitschätzung). Diese Art von Informationen gehören zu keiner Sprachspezifikation. Stattdessen können sie durch ein Modellierungstool verwaltet und dann direkt auf eine XPDL-basierte Beschreibung abgebildet werden. Einige Prozessinformationen (z.B. Priorität) sind in MEMO-OrgML noch nicht verfügbar und müssen durch eine Prozessdefinition ergänzt werden. Instanzenspezifische Informationen sollten in einer Geschäftsprozess-Modellierungssprache zur konzeptionellen Modellierung nicht enthalten sein. Sie könnten lediglich als zusätzliche Informationen (wie ein Workflow-Diagramm für Geschäftsprozesse) für existierende Geschäftsprozesse auf einer anderen Abstraktionsebene dienen.
|
| Oben |
| Abbildung von Ressourcen, Anwendungen und relevanten Informationen |
|
Auf den ersten Blick könnte der Eindruck entstehen, dass die Abbildung von Ressourcen auf Workflow-Teilnehmer, Workflow-Anwendungen und Workflow-relevante Daten einfach ist. Diese Aufgabe wird jedoch von einigen Details bzgl. der Abstraktion von Ressourcen einerseits und den in XPDL gegebenen Konzepten andererseits behindert.
|
| Human-Ressourcen |
|
In Anlehnung an MEMO-OrgML ist eine menschliche Ressource eine Abstraktion von Personen, Angestellten, Rollen oder anderen mitarbeiterbezogenen Aspekten. In XPDL ist ein Workflow-Teilnehmer eine Abstraktionsebene zwischen dem realen Ausführenden und der Aktivität, die ausgeführt werden muss. Während der Laufzeit werden diese abstrakten Definitionen evaluiert und konkreten Menschen und/oder Programmen zugeordnet [Nori02, S. 43]. Die Abbildung eines abstrakten Akteurs (wie in einer XPDL-Beschreibung gegeben) auf einen konkreten Akteur (z.B. der Anwender eines WfMS) muss durch das Workflow-Management-System erfolgen.
|
Wie in der Tabelle auf der rechten Seite zu sehen ist, können Name und Beschreibung der Ressourcen-Eigenschaften direkt auf eine XPDL-Datei abgebildet werden. Die Eigenschaften-Attribute Qualifikation und KompetenzProfil werden vernachlässigt, da sie keine direkte Übereinstimmung in XPDL besitzen. Ein von XPDL benötigter eindeutiger Bezeichner kann während der Abbildung von OrgML auf XPDL generiert werden.
Die Spezifikationen von "Teilnehmertyp", "erweiterte Attribute" und "externe Referenzen" sind eine Erweiterung eines Geschäftsprozessmodells (mit MEMO-OrgML modelliert). Alternativen für einen Teilnehmertyp sind Ressurcen, Rollen, Organisationseinheiten, Menschen und Softwaresysteme [Nori02, S. 44].
|
|
| - | ID |
| Name | Name |
| Beschreibung | Beschreibung |
| - | Teilnehmertyp |
| - | Erweiterte Attribute |
| - | Externe Referenzen |
| Attribute | - |
| Qualifikation | - |
| KompetenzProfil | - |
|
|
|
Erweiterte Attribute sind Name-Wert-Paare und erlauben die Annotation von systemspezifischen Informationen für verschiedene WfMS-Produkte. (Beachten Sie den Unterschied zwischen Ressourcen-Attributen und erweiterten Attributen: Ein Ressourcen-Attribut ist ein Name-Typ-Paar, ein erweitertes Attribut dagegen ein Name-Wert-Paar.) Der Name wird zur Identifikation des erweiterten Attributs genutzt und der Wert enthält für bestimmte WfMS relevante Informationen. Eine externe Referenz ist eine Referenz auf ein externes Dokument, das die Spezifikation einer Einheit enthält, die im Zusammenhang mit dem Workflow steht. Ein solches Dokument kann z.B. eine global verfügbare XML-DTD (zur Spezifikation der Struktur einer Workflow-Einheit) oder eine Schnittstellendefinition von Web-Services (mittels WSDL) sein. Alle genannten Erweiterungen müssen von einer workflowspezifischen Erweiterung von Geschäftsprozessmodellen zur Verfügung gestellt werden.
|
| Software |
Die Deklaration einer Workflow-Anwendung in XPDL verweist i. A. auf eine Software, die innerhalb eines Geschäftsprozesses genutzt wird. Eine Workflow-Anwendung repräsentiert ein Software-Tool, das für die Ausführung eines Workflows benötigt wird. Beliebige Anwendungen können durch das WfMS aufgerufen werden, da XPDL von konkreten Implementierungen abstrahiert. Jede Anwendung wird in XPDL als symbolische Referenz definiert, die durch das WfMS konkreten Anwendungen zugeordnet werden muss.
Die Ressourcen-Eigenschaften (bzgl. Software) Name und Beschreibung können direkt auf ein XPDL-Dokument abgebildet werden. Die Eigenschaften SystemAnforderungen und Skalierbarkeit werden vernachlässigt, da sie keine Übereinstimmung in XPDL besitzen. XPDL benötigt einen eindeutigen Bezeichner, der in MEMO-OrgML nicht ausgedrückt werden kann. Dennoch kann solch ein Bezeichner OrgML-Modellen explizit zugeordnet werden (was eine kleine Erweiterung der Sprache erfordern würde) oder während der automatischen Abbildung von OrgML auf XPDL generiert werden. Externe Attribute und externe Referenzen werden wie die gleichen Attribute der Human-Ressourcen (siehe oben) behandelt.
|
Das Attribut "Formale Parameter" entspricht einer Liste von einzelnen formalen Parametern, die durch folgende Eigenschaften spezifiziert werden:
- ID: Bezeichner
- Datentyp: Typ des formalen Parameters
- Beschreibung: Textuelle Beschreibung des formalen Parameters
- Index: Position in der Parameterliste
- Modus:
- IN: read-only Parameter
- OUT: write-only Parameter
- INOUT: Parameter, die als Input- und Output-Parameter genutzt werden
Die ID eines formalen Parameters muss innerhalb des Namensraums eines Prozesses eindeutig sein.
|
|
| - | ID |
| Name | Name |
| Beschreibung | Beschreibung |
| - | Formale Parameter |
| - | Erweiterte Attribute |
| - | Externe Referenzen |
| SystemAnforderungen | - |
| Skalierbarkeit | - |
|
|
| Informationen |
In der Geschäftsprozessmodellierung entspricht die Beschreibung von Informationen normalerweise der Spezifikation von Informationstypen, die innerhalb eines Geschäftsprozesses genutzt werden. Im Gegensatz dazu werden workflowrelevante Daten mit Variablen assoziiert, die konkrete Informationen enthalten. Diese Variablen werden im Allgemeinen durch einen eindeutigen Namen referenziert (als Bezeichner) und entsprechen einem gegebenen Typ.
Eine geeignete ID für eine Workflow-Spezifikation kann automatisch generiert werden. Name, Beschreibung und Datentyp können direkt aus den korrespondierenden Attributen des MEMO-Prozessmodells abgeleitet werden (siehe die Tabelle auf der rechten Seite). Erweiterte Attribute werden wie die erweiterten Attribute von Human-Ressourcen und Anwendungen behandelt. Zusätzlich kann einer Variable ein initialer Wert zugeordnet werden. Ob eine Variable von einem komplexen Datentyp ist und welche Länge sie haben kann, wird durch die Attribute IsArray (die Variable ist ein mehrwertiger Typ) und Länge (obere Grenze einer Sequenz) bestimmt.
|
|
| - | Id |
| Name | Name |
| Beschreibung | Beschreibung |
| TypBeschreibung | Datentyp |
| - | Erweiterte Attribute |
| - | Initialer Wert |
| - | Is Array |
| - | Länge |
|
|
| Oben |
| Abbildung von Prozesstypen |
|
MEMO-OrgML unterstützt mehrere unterschiedliche Arten von Prozesstypen, die auf entsprechende in XPDL gegebene Konzepte abgebildet werden müssen. In MEMO-OrgML sind Konzepte wie komponierte, manuelle, automatisierte und teilautomatisierte Prozesse vorhanden. In XPDL existieren generische und Block-Aktivitäten. In diesem Abschnitt werden konzeptionelle Beziehungen zwischen MEMO-OrgML-Prozessen und XPDL-Aktivitäten diskutiert.
|
| Manuelle Prozesse |
|
Es gibt verschiedene alternative Optionen zur Abbildung manueller Prozesse auf Workflows (vgl. den entsprechenden Arbeitsbericht für weitere Informationen). Die gewählte Alternative beinhaltet die Abbildung von manuellen Prozessen auf Workflow-Aktivitäten. Jeder manuelle Prozess wird mit einem menschlichen Akteur und ohne Anwendung (application) auf eine Aktivität abgebildet. Somit entsprechen manuelle Prozesse einer Art Dummy-Aktivität in einem Workflow-Schema. Solch eine Dummy-Aktivität dient nur der Vollständigkeit eines manuellen Prozesses. Das Ende eines manuellen Prozesses kann den Start eines folgenden Prozesses auslösen. Daraus folgt die notwendige Bestätigung jeder manuellen Aktivität im WfMS. Auf diese Weise können der Prozess an sich sowie entsprechende Teilnehmer (menschliche Ressourcen) auf das Workflow-Modell abgebildet werden.
|
|
| ID | ID |
| Name | Name |
| Beschreibung | Beschreibung |
| Organisationseinheit | Ausführender |
| - | Transitions-Restriktionen:
- Join: AND, XOR
- Split: AND, XOR
|
|
|
Die ID wird aus dem Bezeichner des manuellen Prozesses generiert und die Attribute Name und Beschreibung können direkt von der Prozessdefinition auf das XPDL-Dokument abgebildet werden. Die Organisationseinheit eines manuellen Prozesses kann auf den Ausführenden der Workflow-Aktivität abgebildet werden. Die Transitions-Restriktion spezifiziert, ob alle eingehenden Transitionen (Join) synchronisiert (AND) oder alternativ (XOR) und ob alle ausgehenden Transitionen (Split) parallel (AND) oder alternativ (XOR) sind. Diese Informationen werden durch die Art der ein- und ausgehenden Kanten des Geschäftsprozessmodells bestimmt.
Ein paralleler Split wird auf einen AND-Split, ein alternativer Split auf einen XOR-Split abgebildet. Analog dazu wird ein paralleler Join auf einen AND-Join und ein alternativer Join auf einen XOR-Join abgebildet. Informationen, die nicht im Geschäftsprozessmodell enthalten, jedoch notwendig für die Spezifikation einer Workflow-Aktivität sind, werden in der Tabelle unten aufgelistet.
Da die meisten workflowrelevanten Daten nicht in einem Geschäftsprozessmodell enthalten sind, wird eine Erweiterung dieser Modelle benötigt. Wir erstellen für jeden Geschäftsprozess ein so genanntes Workflow-Diagram, das auf ein Workflow-Schema abgebildet werden muss. Dieses Diagramm enthält alle zusätzlichen Informationen für die Implementierung und Simulation von Geschäftsprozessen in einer Workflowumgebung.
|
|
| Deadline | Spezifikation einer Deadline und einer Aktion, die auszuführen ist, wenn die Deadline erreicht ist. |
| Dokumentation | Bezeichner einer externen Dokumentationsdatei (z.B. URL oder ein Dateiname). |
| Startmodus | Manueller Modus: Der Anwender muss die Aktivität manuell starten (um auf den Beginn seiner Arbeit hinzuweisen) |
| Endmodus |
Manueller Modus: Das Ende der Aktivität muss über eine Interaktion des Anwenders angezeigt werden. |
| Implementierung | Nein: Implementierung durch manuelle Prozeduren |
| Icon | Referenz auf eine externe Datei, die eine Grafik für die Repräsentation einer Aktivität enthält. |
| Grenze | Erwartete maximale Dauer der Ausführung eines Prozesses (anbieterspezifisch) |
| Priorität | Ein Wert, der die initiale Priorität eines Prozesses beschreibt. |
| Simulationsinformationen | Schätzungen für die Simulation einer Aktivität. |
|
| Teilautomatisierte Prozesse |
|
In MEMO-OrgML werden teilautomatisierte Prozesse durch menschliche Ressourcen ausgeführt, wobei IT-Ressourcen (Soft- und Hardware) verwendet werden. Somit basieren teilautomatisierte Prozesse auf menschlichen und softwaretechnischen Ressourcen. Diese Art von Prozessen kann auf generische Aktivitäten abgebildet werden.
|
|
Die Abbildung von allgemeinen Informationen auf einen teilautomatisierten Prozess ist äquivalent zur Abbildung auf einen manuellen Prozess. Die meisten workflowspezifischen Informationen können durch die Nutzung eines Workflow-Diagramms generiert werden. Zusätzlich sind Start- und Endmodus sowie die Implementierung des Prozesses festzulegen.
|
|
| Startmodus | Manueller Modus: Der Anwender muss die Aktivität manuell starten (um auf den Beginn seiner Arbeit hinzuweisen) |
| Endmodus |
Manueller Modus: Das Ende der Aktivität muss über eine Interaktion des Anwenders angezeigt werden. |
| Implementierung | Tool: Die Implementierung wird durch eine Anwendung unterstützt. |
|
|
| Vollautomatisierte Prozesse |
|
Ein automatisierter Prozess wird ohne die Intervention von menschlichen Beteiligten ausgeführt. Trotzdem kann einem automatisierten Prozess eine Organisationseinheit zugeordnet werden; d.h. sie ist verantwortlich für die Ausführung dieses Prozesses. Grundsätzlich kann die Abbildung eines automatisierten Prozesses wie die eines manuellen Prozesses gehandhabt werden (siehe Tabelle). Im Gegensatz zu einem manuellen oder teilautomatisierten Prozess hat die Zuordnung eines Ausführenden keine Auswirkung auf die Ausführung eines automatisierten Prozesses.
|
|
| Startmodus | Automatisiert: Durch das System ausgelöst. |
| Endmodus | Automatisiert: Durch das System ausgelöst. |
| Implementierung | Tool: Die Implementierung wird durch eine Anwendung unterstützt. |
|
|
| Aggregierte Prozesse |
|
Aggregierte Prozesse in MEMO-OrgML haben keine inhärente Implementierung, sondern bestehen aus anderen Prozessen. Eine Block-Aktivität in XPDL entspricht einer Menge von Subaktivitäten und hat keine eigenen Ressourcen. Wir werden keine Teilflüsse nutzen, da jeder Teilfluss seine eigene Menge von Ausführenden und Tools enthält und Namensräume in OrgML nicht unterstützt werden. Dennoch wird jeder aggregierte Prozess auf eine Block-Aktivität abgebildet und alle enthaltenen Prozesse werden in einer Aktivitätenmenge gesammelt.
|
| Abbildung von Kontrollfluss und Ereignissen |
|
Die Art des Kontrollflusses wird durch die Definition der Workflow-Aktivität bestimmt. Alle ausgehenden Transitionen einer Aktivität sind entweder parallel (AND) oder alternativ (XOR). Gleichsam ist jeder Join (eingehende Transition) entweder eine parallele oder alternative Synchronisation. Die Spezifikation von Joins und Splits wird mit einer Prozessdefinition assoziiert.
|
|
In XPDL existieren keine Ereignisse als spezifische Konzepte. Daher existiert keine direkte Übereinstimmung zwischen Ereignissen in einem Geschäftsprozessmodell und einem Workflow-Schema. Nichtsdestotrotz können in einem Geschäftsprozessmodell vorhandene Ereignisse zur Definition der Schaltungsbedingungen einer Transition genutzt werden. Wie in der Tabelle auf der rechten Seite zu sehen ist, kann der Name und die Beschreibung eines Ereignisses auf eine XPDL-Beschreibung abgebildet werden. Die ID kann aus der Ereignis-ID und dem Kontext erstellt werden. Die Bedingung muss der Aktivitätenbeschreibung hinzugefügt werden. Vorangehende und nachfolgende Aktivitäten können aus dem Geschäftsprozessmodell abgeleitet werden.
|
|
| ID | ID |
| Name | Name |
| Beschreibung | Beschreibung |
| TypBeschreibung | Bedingung |
| - | Von (Menge von Aktivitäten) |
| - | Nach (Menge von Aktivitäten) |
|
|
| Oben |
Fußnoten:
- Für ein verbesserte Lesbarkeit wurden die XPDL-Attributnamen auf dieser Seite ins Deutsche übersetzt. Die englischen Attributnamen können Sie auf der zugehörigen englischsprachigen Seite nachlesen.
|
