Herausforderungen auf dem Weg zu
datenorientierten Prozess-Management-Systemen
Vera Künzle und Manfred Reichert
Institut für Datenbanken und Informationssysteme, Universität Ulm
{vera.kuenzle,manfred.reichert}@uni-ulm.de
Zusammenfassung
Workflow-Management-Systeme (WfMS) sind mittlerweile mächtige Werkzeuge für die computerun-
terstützte Ausführung von Geschäftsprozessen. Letztere können unabhängig von spezifischen An-
wendungen modelliert, ausgeführt und überwacht werden. Trotzdem existieren auf dem Software-
Markt noch zahlreiche Anwendungen mit im Code fest verdrahteter Prozesslogik. Die Ursache dafür,
dass konventionelle WfMS bei der Entwicklung prozessorientierter Anwendungen noch nicht die er-
hoffte Verbreitung erfahren haben, ist zum einen auf ihre Architektur und zum anderen auf ihr aktivi-
tätsorientiertes Paradigma zurückzuführen. Die Verwaltung von Anwendungsdaten erfolgt, außerhalb
des WfMS, d.h. innerhalb der eingebundenen externen Applikationen. Geschäftsprozesse und Ge-
schäftsdaten können jedoch nicht unabhängig voneinander betrachtet werden, sondern Prozessmo-
delle sollten in Analogie zur Datenstruktur definiert werden können. Des Weiteren sind die in WfMS
fest vorgegebenen Kontrollstrukturen zu starr für die Ausführung datenorientierter Prozesse. Der Fort-
schritt eines Prozesses ist hier nicht primär abhängig von bereits ausgeführten Aktivitäten, sondern
von Änderungen der Attributwerte innerhalb der Anwendungsobjekte. In diesem Artikel fassen wir die
charakteristischen Eigenschaften von daten- und prozessorientierten Anwendungen zusammen, die
wir anhand verschiedener Fallstudien gesammelt haben. Wir zeigen, in wie weit konventionelle WfMS
diesen Herausforderungen gewachsen sind. Auf dieser Basis leiten wir die Anforderungen ab, die eine
generische Komponente zur Unterstützung datengetriebener Prozesse mit einer integrierten Sicht auf
Prozesse und Daten, erfüllen sollte.
1 Motivation
Derzeit existieren auf dem Software-Markt viele spezifische Anwendungen (z.B. ERP-, CRM- oder
SCM-Systeme) zur Verwaltung und Bearbeitung von Daten für verschiedene Unternehmensbereiche.
Diese datenorientierten Software-Systeme bieten dem Benutzer, neben einem Zugang zu Geschäfts-
informationen, oftmals eine engintegrierte Sicht auf die zugehörigen Prozesse. Die unterstützten Pro-
zesse sind stark wissensintensiv und erfordern häufige Benutzerentscheidungen. Des Weiteren ist die
entsprechende Anwendungssoftware auf die Bearbeitung großer Datenmengen ausgerichtet, und
stellt dazu ein großes Funktionsspektrum für den jeweiligen Aufgabenbereich zur Verfügung. Als Basis
zur Speicherung der Informationen wird typischerweise eine (objekt-)relationale Datenbank verwendet.
Ein großes Manko entsprechender Anwendungssoftware ist jedoch die feste Verdrahtung der Pro-
zesslogik im Anwendungscode. Die Vermischung der fachlichen Logik mit dem Anwendungscode
macht diesen komplex und nur schwer wartbar. Hieraus resultieren lange Entwicklungszeiten und da-
mit hohe Kosten bei späteren Anpassungen der Software. Hinzu kommt die oftmals redundante
Streuung der Prozesslogik im Code, welche vielfach zu unerwünschten Seiteneffekten und Inkon-
sistenzen bei Änderungen führt. Dadurch ist die Anwendungssoftware sehr fehleranfällig und erfordert
hohe Testaufwände, was wiederum die Entwicklungskosten in die Höhe treibt.
Workflow-Management-Systeme (WfMS) bieten in diesem Zusammenhang vielversprechende Per-
spektiven [RD00] [AH04]. Mit ihrer Hilfe können Prozesse unabhängig von spezifischen Anwendungen
modelliert, ausgeführt und überwacht werden. Trotzdem haben WfMS bisher noch nicht die erhoffte
Verbreitung bei der Entwicklung prozessorientierter Anwendungssoftware erfahren. Die derzeit auf
dem Markt verfügbaren WfMS wie die AristaFlow BPM Suite, Staffware und der WebSphere Process-
Server sind zwar ein Schritt in die richtige Richtung, die technologische Reife für die Realisierung der
Prozesse in datenorientierten Anwendungen ist jedoch noch nicht voll erreicht.
Wir zeigen nachfolgend, warum konventionelle WfMS datenorientierte Anwendungen noch nicht hin-
reichend unterstützen können. Dazu haben wir die Charakteristika dieser Anwendungen systematisch
untersucht und fassen diese in der Folge zusammen. Auf Basis dieser Erkenntnisse beschreiben wir,
welche Art der Systemunterstützung man hinsichtlich einer generischen Komponente für datenorien-
tierte Prozesse, mit integrierter Sicht auf Prozesse und Daten, benötigt.
Zur besseren Differenzierung eines solchen Systems von herkömmlichen WfMS, sprechen wir in der
Folge von datenorientierten Prozess-Management-Systemen.
In Kapitel 2 beschreiben wir die Arbeitsweise konventioneller WfMS und stellen ein einfaches Beispiel
vor entlang dessen wir nachfolgende Ausführungen illustrieren. In Kapitel 3 beschreiben wir die fünf
wichtigsten Herausforderungen an ein datenorientiertes Prozess-Management-System. Hierbei stellen
wir die Eigenschaften von datenorientierten Anwendungen jeweils den Problemen gegenüber, die sich
bei der Umsetzung mit einem konventionellen WfMS ergeben. Insbesondere leiten wir daraus die An-
forderungen an ein datenorientiertes Prozess-Management-System ab. Kapitel 4 beschreibt bisherige
Ansätze zur Lösung einzelner Problematiken. Wir zeigen, warum diese für eine Gesamtlösung nicht
ausreichend sind. Kapitel 5 gibt einen Ausblick auf unsere zukünftigen Forschungsarbeiten zu daten-
orientierten Prozess-Management-Systemen.
2 Grundlagen & Beispiel
Um in der Folge auf Limitierungen derzeit verfügbarer Workflow-Technologie eingehen zu können,
fassen wir zunächst die grundlegende Arbeitsweise aktueller WfMS zusammen (siehe Abbildung 1).
Die Modellierung der Prozesse erfolgt in WfMS auf Basis einzelner Aktivitäten, deren Reihenfolge und
Ausführungsbedingungen durch den Kontrollfluss festgelegt werden. Dazu stehen z.B. Modellierungs-
konstrukte für sequentielle, alternative und parallele Abläufe sowie für Schleifen zur Verfügung. Einige
Systeme erlauben zusätzlich fortschrittlichere Konstrukte [AHKB03]. Für die spätere Ausführung wird
jede Prozess-Aktivität mit einem Anwendungsdienst verknüpft. Interaktiven Aktivitäten, die eine Aktion
des Benutzers erfordern, wird zusätzlich ein Bearbeiterausdruck (z.B. eine Benutzerrolle) zugeordnet.
Zur Laufzeit wird für jede Ausführung eines Prozesses eine eigene Prozessinstanz angelegt. Eine Ak-
tivität kann innerhalb einer Instanz genau dann aktiviert werden, wenn alle im Kontrollfluss vorausge-
henden Aktivitäten der Instanz beendet sind, bzw. wenn feststeht, dass keine vor ihnen mehr aktiviert
werden kann (ausgenommen über Schleifen und Rücksprünge). Alle aktivierbaren Aktivitäten werden
den jeweils zuständigen Bearbeitern innerhalb ihrer Arbeitsliste zur Ausführung angeboten. Bei der
Aktivierung wird automatisch die mit der Aktivität verknüpfte Anwendung gestartet. [RD00] [AH04]
Abbildung 1: Arbeitsweise konventioneller Workflow-Management-Systeme
Um die nachfolgenden Ausführungen besser illustrieren zu können stellen wir hier zunächst als Fall-
beispiel den Bearbeitungsprozess einer Bewerbung aus dem Bereich Human Ressource Management
vor. Der Einfachheit halber gehen wir nur auf Grundfunktionen und allgemeine Abläufe ein:
Anhand eines Online-Formulars im Internet haben Interessenten die Möglichkeit, sich auf eine offene
Ausschreibung zu bewerben. Ziel des Prozesses ist es, eine Entscheidung darüber zu treffen, welcher
Bewerber zur Besetzung der offenen Stelle eingestellt werden soll. Dazu werden zunächst die Kennt-
nisse der Bewerber mit den Anforderungen der Stelle verglichen. Zur weiteren Entscheidungsfindung
haben die Sachbearbeiter in der Personalabteilung die Möglichkeit, die Bewerbungen zwecks Beurtei-
lung den Führungskräften der jeweiligen Fachabteilungen vorzulegen. Dazu wird für die Mitarbeiter
aus den Fachabteilungen von der Personalabteilung jeweils ein Gutachten angelegt. Diese müssen
von den betreffenden Mitarbeitern der Fachabteilung ausgefüllt werden. Anhand eines Ausgabeda-
tums pro Gutachten kann die Personalabteilung festgelegen, zu welchem Zeitpunkt der jeweilige Mit-
arbeiter das Gutachten erstellen soll. Ist dieses Datum erreicht, kann der Mitarbeiter die zugehörige
Bewerbung einsehen, eine Bewertung festlegen und einen Kommentar vermerken. Des Weiteren
muss der Mitarbeiter einen Vorschlag für das weitere Verfahren angeben. Dies kann unter anderem
eine Absage für den Bewerber oder die Einladung zu einem Vorstellungsgespräch sein. Nach Rück-
gabe der Gutachten werden diese von der Personalabteilung ausgewertet und als Entscheidungs-
grundlage (bzw. für die Auswahl einer Folgeaktion) verwendet. Da Gutachten zu verschiedenen Zeit-
punkten angelegt werden können und zu unterschiedlichen Zeitpunkten zurückgegeben werden, wer-
den alle bereits ausgewerteten Gutachten von der Personalabteilung als "erledigt" gekennzeichnet.
3 Beobachtungen, Probleme und Anforderungen
Im Rahmen mehrerer Fallstudien haben wir die Eigenschaften von datenorientierter Anwendungssoft-
ware mit integrierter Prozesslogik untersucht. In diesem Kapitel fassen wir die hieraus gewonnenen
Erkenntnisse zusammen und illustrieren sie entlang des oben vorgestellten Beispielszenarios. Des
Weiteren verdeutlichen wir die jeweils identifizierten Probleme, die sich bei Umsetzung der Eigen-
schaften mittels konventioneller WfMS ergeben. Daraus leiten wir in einem dritten Schritt die jeweili-
gen Anforderungen ab, die an ein datenorientiertes Prozess-Management-System zur Unterstützung
dieser Prozesse zu stellen sind.
Herausforderung 1: Datenintegration
Beobachtungen
Anwendungssysteme verwalten Daten in Form verschiedener Objekttypen. Diese sind jeweils durch
eine Menge von Attributen definiert. Für jeden Objekttyp existieren zur Laufzeit mehrere Objektinstan-
zen. Diese unterscheiden sich in den Werten der jeweiligen Attribute. Jeder Objekttyp besitzt mindes-
tens ein Attribut zur Speicherung einer Objekt-ID. Anhand dieses Attributs kann jede Objektinstanz
eindeutig identifiziert werden. Auch Datenbeziehungen werden auf Typebene anhand von Attributen
beschrieben. Diesen Beziehungs-Attributen werden zur Laufzeit die Objekt-IDs anderer Objektinstan-
zen zugeordnet. Einer Objektinstanz können dadurch jeweils mehrere Objektinstanzen eines anderen
Objekttyps zugeordnet werden.
Anwendungsdaten bestehen aus einer variablen Anzahl von Objektinstanzen verschiedener
Objekttypen die zueinander in Beziehung stehen.
job offer
employee
application
review
1
n
1
n1n
objecttypes objectinstances
ID-review
ID-application
ID-employee
delivery date
recommendation
grading
comment
submit
finish
attributes
job offer
employee
application
review
ID-review
ID-application
ID-employee
delivery date
recommendation
grading
comment
submit
finish
attributes
a) build time b) run time
Abbildung 2: Datenstruktur zur Modellierzeit und zur Laufzeit
Abbildung 2a beschreibt die Daten-
struktur für das vorgestellte Fallbei-
spiel im Bewerbermanagement. Für
jede Bewerbung können mehrere
Gutachten angelegt werden. Die ge-
naue Anzahl der Objektinstanzen zu
einem Objekttyp ist variabel und kann
sich zur Laufzeit dynamisch verän-
dern (siehe Abbildung 2b). Dies gilt
auch für die jeweils zugeordneten
Objektinstanzen. So ist z.B. die Men-
ge der Gutachten, die für eine Be-
werbung angelegt werden, von Be-
werbung zu Bewerbung unterschied-
lich.
Charakteristisch für datenorientierte Systeme ist, dass alle Informationen unabhängig von Pro-
zessen zu jedem Zeitpunkt eingesehen und bearbeitet werden können [AWG05].
Innerhalb von Übersichtstabellen etwa können die einzelnen Objektinstanzen eines Objekttyps zei-
lenweise aufgelistet werden. Die einzelnen Spalten beziehen sich dann auf die Attribute des Objekt-
typs bzw. auf die Attributwerte der Objektinstanzen. Attribute, die Datenbeziehungen repräsentieren,
werden aufgelöst und durch ein Attribut der referenzierten Objektinstanz ersetzt, letzteres soll die Ob-
jektinstanz möglichst aussagekräftig beschreiben. Weiterführende Informationen können instanzspezi-
fisch eingesehen werden. Dazu gehören Attribute, die aus Platzgründen nicht innerhalb der Übersicht
angezeigt werden können, sowie detaillierte Informationen über die referenzierten Objektinstanzen.
Abbildung 3 zeigt eine Übersicht für die Gutachten zu verschiedenen Bewerbungen. Durch Auflösung
der Attribute mit Referenzen auf andere Objektinstanzen können die zugehörige Bewerbung, die Aus-
schreibung und der Mitarbeiter, dem dieses Gutachten zugeordnet ist, angezeigt werden. Die Werte
weiterer Attribute sowie genauere Informationen über die referenzierten Objektinstanzen (z.B. Bewer-
bung, Ausschreibung und Mitarbeiter) können anhand einer optionalen Aktivität eingesehen werden.
Diese kann in der Abbildung anhand des Lupen-Symbols aufgerufen werden.
Abbildung 3: Datensicht in datenorientierter Anwendungssoftware
Ausgehend von dieser datenorientierten Sicht können die Attributwerte der einzelnen Objektinstanzen
bearbeitet werden. Diese Aktivität kann jederzeit für alle Objektinstanzen von allen Objekttypen, unab-
hängig vom Prozess, aufgerufen werden. Im Vergleich zu den Aktivitäten innerhalb des Prozesses, die
obligatorisch ausgeführt werden müssen, ist diese Aktivität optional. In Abbildung 3 ist der Aufruf die-
ser Aktivität anhand des Stift-Symbols möglich. Dadurch können Informationen genau zu dem Zeit-
punkt erfasst werden, zu dem sie im Prozessverlauf zur Verfügung stehen.
Probleme
Innerhalb vieler WfMS können nur atomare Datenelemente verwaltet werden. Diese speichern jeweils
einfache Daten aus den Datenverwaltungen der eingebunden Anwendungen, die für die Steuerung
und Ausführung des Prozesses benötigt werden (sog. prozessrelevante Daten). Alle anderen Anwen-
dungsdaten sind dem WfMS nicht bekannt. Durch die Trennung der Anwendungsdaten von der Pro-
zesslogik ist kein integrierter Zugang zu Geschäftsprozessen und -informationen möglich. D.h. der
Zugang zu detaillierten Informationen ist nur innerhalb der eingebundenen Anwendungen im Zusam-
menhang mit der Ausführung einer Aktivität möglich. Welche Informationen jeweils angezeigt werden,
kann innerhalb herkömmlicher WfMS deshalb nicht oder nur eingeschränkt gesteuert werden. Dazu
können die Objekt-IDs der benötigten Objektinstanzen in Datenelementen verwaltet und den entspre-
chenden Aktivitäten als Übergabeparameter zur Verfügung gestellt werden. Wie sich in der Praxis ge-
zeigt hat, führen fehlende oder unvollständige Kontextinformationen jedoch häufig zu ineffizientem Ar-
beiten und fehlerhaften Ergebnissen [AWG05].
Abbildung 4: Zugriff auf Kontextinformationen
Abbildung 4 zeigt eine Aktivität zur Ein-
sicht einer Bewerbung. Welche Bewer-
bung eingesehen werden soll kann durch
Übergabe der entsprechenden Objekt-ID
gesteuert werden. Es kann jedoch nicht
kontrolliert werden, welche Attributwerte
der Objektinstanz für die Bewerbung an-
gezeigt werden. Des Weiteren kann der
Zugriff auf referenzierte Objektinstanzen
(z.B. Bewerbung) nicht beeinflusst werden.
Eine Integration von optionalen Aktivitäten (z.B. für die Eingabe zusätzlicher Informationen) in
den Prozess ist anhand von parallelen Pfaden zwar prinzipiell möglich, führt aber zu künstlich
aufgeblähten und dadurch komplexen und unübersichtlichen Prozessmodellen.
Außerdem können solche optionalen Aktivitäten mangels fehlender Differenzierbarkeit vom Bearbeiter
innerhalb seiner Arbeitsliste nicht von den für den Prozessfortschritt zwingend erforderlichen Aktivitä-
ten unterschieden werden. Abbildung 5 zeigt den Prozess einer Bewerbung mit integrierten optionalen
Aktivitäten zur Bearbeitung der Daten.
Abbildung 5: obligatorische und optionale Aktivitäten in konventionellen WfMS
Ohne die Integration optionaler Aktivitäten in das WfMS werden die eingebundenen Anwendungen
aber oft parallel zum WfMS gestartet. Dadurch können auch Datenelemente verändert werden, die in-
nerhalb des Datenflusses redundant vom WfMS verwaltet werden. Die entstehenden Inkonsistenzen
zwischen Daten- und Prozesszustand führen zu Laufzeitfehlern beim Aufruf der Anwendungen oder
zu einer fehlerhaften Prozesssteuerung.
Anforderungen
Anwendungsdaten sollen in einem datenorientierten Prozess-Management-System vollständig integ-
riert werden. Dazu müssen Daten anhand von Objekttypen und nicht nur auf Basis atomarer Daten-
elemente verwaltet werden [NC03]. Das System muss weiter mit einer zur Laufzeit variablen und dy-
namischen Anzahl von Objektinstanzen umgehen können. Dabei müssen auch die Beziehungen der
Objektinstanzen zueinander transparent sein. Informationen müssen zu jedem Zeitpunkt, unabhängig
vom Prozess, eingesehen und bearbeitet werden können [AWG05].
Herausforderung 2: Wahl der Granularität von Prozessen und Aktivitäten
Beobachtungen
Für viele Objekttypen existieren jeweils eigene Bearbeitungsprozesse [MRH07]. Die Instanziie-
rung eines Prozesses ist unmittelbar mit der Anlage eines Objekts des entsprechenden Typs
verbunden.
Dadurch existiert zur Laufzeit für jede Objektinstanz genau eine Prozessinstanz. Diese 1:1-
Zuordnungen zwischen Objekt- und Prozesstyp bzw. zwischen Objekt- und Prozessinstanz werden in
Abbildung 6 illustriert. Dem Objekttyp einer Bewerbung ist ein eigener Prozesstyp zugeordnet. Zur
Laufzeit existieren mehrere Objektinstanzen einer Bewerbung. Für jede Objektinstanz einer Bewer-
bung wird automatisch eine entsprechende Prozessinstanz erzeugt.
Abbildung 6: Analogie zwischen Objekt und Prozess
Innerhalb des Prozesses für einen spezifischen Objekttyp beziehen sich die einzelnen Aktivitä-
ten jeweils auf ein oder mehrere Attribute des Objekttyps.
Für jedes Attribut existiert eine Aktion zur Anzeige oder zur Bearbeitung des dem Attribut zugeordne-
ten Werts. Eine Aktivität setzt sich jeweils aus einer oder mehrerer dieser Aktionen zusammen. Abbil-
dung 7 zeigt den Objekttyp eines Gutachtens sowie den zum Gutachten gehörenden Prozesstyp. Je-
de Aktivität einer Prozessinstanz liest oder schreibt mindestens ein Attribut der zugehörigen Objektin-
stanz.
Abbildung 7: Granularität von Aktivitäten
Innerhalb eines Prozesses werden oft weitere, untergeordnete Prozesse angestoßen. Ergebnisse, die
bei der Ausführung der Prozessinstanzen untergeordneter Prozesstypen gesammelt werden, sind für
die weitere Ausführung der jeweils übergeordneten Prozessinstanz relevant. Die Instanziierung erfolgt
auch bei untergeordneten Prozesstypen durch Anlage einer Objektinstanz. Diese untergeordnete Ob-
jektinstanz muss die Objektinstanz der übergeordneten Prozessinstanz referenzieren.
Die Zuordnung der Prozesstypen zueinander entspricht somit der Zuordnung der Objekttypen
innerhalb der Datenstruktur [MRH07].
Die Anzahl der untergeordneten Prozessinstanzen ist abhängig von der Anzahl der Objektinstanzen
des untergeordneten Objekttyps.
Abbildung 8 verdeutlicht die Analogie zwischen Daten- und Prozessstruktur am Beispiel von Bewer-
bungen mit einer jeweils unterschiedlichen Anzahl an zugehörigen Gutachten.
Abbildung 8: Analogie zwischen Daten- und Prozessstruktur
Probleme
Bei der Modellierung der Prozesse innerhalb konventioneller WfMS ist die Granularität von Prozess
und Aktivitäten nicht klar vorgegeben. D.h. Aktivitäten, Prozesse und Sub-Prozesse können im Prinzip
frei gewählt und modelliert werden. Es existieren weder eine einheitlich Methodik noch konkrete Richt-
linien für die Wahl der Granularität [RLA03]. Dies führt in der Praxis zu uneinheitlichen und nur schwer
vergleichbaren Modellen für ein und denselben Prozess.
Bei der Modellierung kann die zugrundeliegende Datenstruktur nur manuell, d.h. ohne Systemunter-
stützung, berücksichtigt werden. Untergeordnete Prozesse können in Form von Sub-Prozessen mo-
delliert werden. Zur Laufzeit treten jedoch zwei Probleme auf. Prozessinstanzen müssen explizit, un-
abhängig von der Anlage einer Objektinstanz, erzeugt werden. Des Weiteren muss in einigen der her-
kömmlichen WfMS die Anzahl der benötigten Prozessinstanzen schon zur Modellierzeit feststehen
[ABEW00].
Anforderungen
Die Modellierung von Prozessen muss systemunterstützt in Synchronität mit der Definition der Daten-
struktur erfolgen [RLA03]. Hierbei muss zwischen Objekt- und Strukturebene differenziert werden. Das
bedeutet, einzelne Prozesstypen müssen mit Bezug auf einen Objekttyp modelliert werden [NC03].
Dabei müssen sich die einzelnen Aktivitäten auf die Attribute des Objekttyps beziehen können. Des
Weiteren sollte die Hierarchie der Prozesse der Hierarchie der Objekttypen innerhalb der Datenstruk-
tur entsprechen. Die Instanziierung eines Prozesses muss unmittelbar mit der Anlage einer Objektin-
stanz gekoppelt sein.
Herausforderung 3: Datenbasierte Modellierung
Beobachtungen
Der Fortschritt einer Prozessinstanz ist innerhalb der Attributwerte der zugehörigen Objektin-
stanz erkennbar.
Abbildung 9 zeigt die Prozessinstanz für eine Objektinstanz des Objekttyps Gutachten. Dabei werden
die jeweiligen Attributänderungen innerhalb der Objektinstanz für jede Aktivität verdeutlicht.
Abbildung 9: Prozessfortschritt innerhalb der Daten
Die einzelnen Prozessschritte sind hier weniger anhand von Aktivitäten, sondern vielmehr an-
hand von Datenbedingungen definiert.
D.h. der Prozess wird durch Vorgabe von Bearbeitungszielen definiert. Diese werden anhand von Be-
dingungen mit Bezug auf die Attributwerte beschrieben. Die prozessrelevanten Aktivitäten bestehen
aus Aktionen zur Änderung der Attributwerte die für die Erfüllung der Datenbedingung des jeweils
nächsten Prozessschritts geändert werden müssen [AWG05].
Abbildung 10 zeigt dieselbe Prozessinstanz wie Abbildung 9. Die einzelnen Prozessschritte werden
nun anhand von Datenbedingungen mit Bezug auf die Attribute der Objektinstanz eines Gutachtens
definiert.
Abbildung 10: Datenbasierte Prozessmodellierung
Durch diese Art der Prozessdefinition sind Daten- und Prozesszustand per Konstruktion zu jedem
Zeitpunkt synchron.
Probleme
Bei der aktivitätsbasierten Modellierung in WfMS wird festgelegt, welche Aktivitäten in welcher Reihen-
folge durchgeführt werden sollen. Ob sich mit diesen Aktivitäten auch das gewünschte Bearbeitungs-
ziel erreichen lässt, kann systemseitig weder überprüft noch sichergestellt werden [RKG06, RDHI07,
GS07].
Manche Ansätze definieren Vor- und Nachbedingungen für einzelne Aktivitäten in Bezug auf die An-
wendungsdaten. Können diese Bedingungen jedoch zur Laufzeit nicht erfüllt werden, ist eine weitere
Ausführung des Prozesses nicht mehr möglich. Es ist nicht ausreichend, bestimmte Attributwerte für
die Ausführung einer Aktivität zu fordern. Zur Laufzeit muss dynamisch auf die aktuellen Attributwerte
der jeweiligen Objektinstanzen reagiert werden können.
Anforderungen
Die Modellierung von Prozessen darf nicht auf Basis von Aktivitäten erfolgen. Die einzelnen Schritte
eines Prozesses müssen anhand von Bedingungen in Bezug auf die Attribute des zum Prozesstyp
gehörenden Objekttyps definiert werden.
Herausforderung 4: Synchronisation von Prozessen
Beobachtungen
Die Instanziierung einer untergeordneten Prozessinstanz erfolgt innerhalb der übergeordneten Pro-
zessinstanz [ABEW00]. Dazu wird eine Objektinstanz eines untergeordneten Objekttyps angelegt.
Auch dieser Prozessschritt ist anhand einer Datenbedingung definiert.
Die Anlage einer untergeordneten Objektinstanz ist daher abhängig vom Fortschritt der Pro-
zessinstanz des übergeordneten Objekts.
Dieser Zusammenhang wird in Abbildung 11 veranschaulicht. Es kann erst dann ein Gutachten für ei-
ne Bewerbung angelegt werden, wenn die Kenntnisse des Bewerbers mit den Anforderungen der of-
fenen Stelle verglichen wurden.
Innerhalb der übergeordneten Prozessinstanz werden Informationen aus untergeordneten Pro-
zessinstanzen ausgewertet.
Dazu muss die Menge der untergeordneten Objektinstanzen aggregiert werden [ABEW00]. Das heißt,
es müssen verschiedene Werte der jeweils gleichen Attribute aus einer Menge von untergeordneten
Objektinstanzen zusammengefasst werden können. Welche untergeordneten Objektinstanzen bei der
Aggregation berücksichtigt werden, ist hierbei abhängig vom Fortschritt der jeweils zugehörigen Pro-
zessinstanz.
Abbildung 11 verdeutlicht die Aggregation von Informationen. Innerhalb der Prozessinstanz für eine
Bewerbung werden die Ergebnisse aus den zur Bewerbung gehörenden Gutachten ausgewertet.
Hierbei werden jedoch nur die an die Personalabteilung zurückgegebenen Gutachten berücksichtigt.
Neben der Erzeugung untergeordneter Prozessinstanzen durch Anlage untergeordneter Ob-
jektinstanzen und der Zusammenfassung untergeordneter Prozess- bzw. Objektinstanzen kön-
nen weitere Abhängigkeiten zur Synchronisation objektspezifischer Prozessinstanzen be-
schrieben werden [MRH07].
Dazu werden die Datenbedingungen, anhand derer die einzelnen Prozessschritte definiert sind, um
Bedingungen an die Attribute anderer Objektinstanzen erweitert.
In Abbildung 11 kann beispielsweise ein Gutachten erst dann als "erledigt" gekennzeichnet werden,
wenn eine Entscheidung über die Bewerbung getroffen wurde.
Abbildung 11: Synchronisation von Prozessen
Zusätzlich zu den Abhängigkeiten für die Synchronisation von Prozessinstanzen unterschiedlicher
Prozesstypen können auch Prozessinstanzen desselben Prozesstyps miteinander synchronisiert wer-
den [ABEW00, MRH07]. Beispielsweise kann eine Bewerbung nur dann zugesagt werden, wenn noch
keine andere Bewerbung für dieselbe offene Stelle zugesagt wurde.
Probleme
Innerhalb konventioneller WfMS wird jede Prozessinstanz isoliert ausgeführt. Das bedeutet, es können
weder Abhängigkeiten zwischen Prozessinstanzen verschiedener Prozesstypen noch zwischen Pro-
zessinstanzen desselben Prozesstyps definiert werden. Oft wird versucht, die fehlende Möglichkeit zur
Synchronisation durch die Modellierung von Sub-Prozessen zu umgehen. Instanzen der Sub-
Prozesse können dabei untereinander asynchron ausgeführt werden. Problematisch ist jedoch, dass
die untergeordneten Prozessinstanzen nur synchron zur übergeordneten Prozessinstanz ausgeführt
werden können. Dies bedeutet, dass die Ausführung der übergeordneten Prozessinstanz solange blo-
ckiert ist, bis alle untergeordneten Prozessinstanzen beendet sind. Dadurch können weder aggregier-
te Aktivitäten noch weitere Abhängigkeiten definiert werden [ABEW00]. Aggregierte Aktivitäten müs-
sen anhand der eingebunden externen Anwendungen realisiert werden.
Anforderungen
Sowohl die Prozessinstanzen desselben Prozesstyps als auch Prozessinstanzen unterschiedlicher
Prozesstypen müssen asynchron zueinander ausgeführt werden können. Allerdings müssen einzelne
Prozessinstanzen eines Prozesstyps sowohl untereinander als auch mit Prozessinstanzen anderer
Prozesstypen koordiniert werden können. Mehrere Prozessinstanzen eines untergeordneten Prozess-
typs sind jeweils einer übergeordneten Prozessinstanz zugeordnet. Diese Mengenbeziehung muss bei
der Koordination der Prozesse berücksichtigt werden können.
Herausforderung 5: Flexibilität
Beobachtungen
Neben optionalen Aktivitäten zur Erfassung von Informationen an beliebiger Stelle im Prozessverlauf
gibt es Aktivitäten, die für den Fortschritt des Prozesses obligatorisch ausgeführt werden müssen.
Diese Aktivitäten beinhalten Aktionen für genau die Attribute, die zur Definition eines Prozessschritts
verwendet wurden.
Eine prozessrelevante Aktivität kann jedoch mehreren Prozessschritten zugeordnet werden.
Die Aktivierung einer Aktivität ist im Prinzip unabhängig von anderen Aktivitäten. Eine Aktivität
kann ausgeführt werden, sobald ihre zugehörige Datenbedingung erfüllt ist.
Dadurch ist auch eine wiederholte Ausführung von Aktivitäten möglich. Je nach Definition der Pro-
zessschritte ergibt sich eine asynchrone Ausführungsreihenfolge für die einzelnen Aktivitäten. Diese
wird exemplarisch in Abbildung 12 verdeutlicht.
Abbildung 12: Asynchronität von Aktivitäten
Nicht nur die prozessrelevanten Aktivitäten sondern auch die optionalen Aktivitäten zur Bearbeitung
der Attributwerte von Objektinstanzen sind von den Datenbedingungen für die einzelnen Prozess-
schritte abhängig.
Welche Attributwerte bei der Bearbeitung der Daten einer Objektinstanz jeweils gelesen und
geschrieben werden können, ist abhängig vom Fortschritt der zur Objektinstanz gehörenden
Prozessinstanz.
Abbildung 13 verdeutlicht die einzelnen Aktionen die zu einem bestimmten Zeitpunkt innerhalb der op-
tionalen Aktivität zur Bearbeitung der Attributwerte einer Objektinstanz eines Gutachtens zur Verfü-
gung stehen.
Abbildung 13: Horizontale dynamische Granularität von Aktivitäten
Die zur Erreichung des nächsten Prozessschritts erforderlichen Attributänderungen können prinzipiell
auch innerhalb der optionalen Aktivität für die Bearbeitung der Attributwerte der betreffenden Objekt-
instanz durchgeführt werden. Innerhalb der optionalen Aktivität können die einzelnen Aktionen auf
Grund ihrer Prozessrelevanz unterschieden werden.
Abbildung 14 zeigt die jeweils relevanten Aktionen die innerhalb einer Prozessinstanz für ein Gutach-
ten obligatorisch ausgeführt werden müssen.
Abbildung 14: Obligatorische und optionale Aktionen
Optionale Aktivitäten zur Bearbeitung der Attributwerte einzelner Objektinstanzen passen sich somit
dynamisch an den Prozessfortschritt an. D.h. in Abhängigkeit vom Fortschritt des Prozesses stehen
unterschiedliche Aktionen zur Verfügung. Dies bezeichnen wir als horizontale dynamische Granularität
von Aktivitäten. Bei der Erfassung von Informationen für ein Gutachten hat ein Mitarbeiter der Fachab-
teilung beispielsweise die Möglichkeit, einen Vorschlag anzugeben, eine Bewertung zu machen und
eine Bemerkung einzugeben. Nach der Rückgabe des Gutachtens an die Personalabteilung können
beim Aufruf derselben Aktivität diese Felder jedoch nicht mehr editiert werden.
Obligatorische Aktivitäten können auch für verschiedene Prozessinstanzen desselben Prozesstyps
gemeinsam durchgeführt werden. Dazu kann der Benutzer alle Aktivitäten, für die er dieselben Daten
eingeben möchte, gruppieren und gleichzeitig ausführen [SO05]. Dementsprechend muss er die glei-
chen Angaben nur einmal für mehrere Objektinstanzen eingeben. Dies bezeichnen wir als vertikale
dynamische Granularität von Aktivitäten (siehe Abbildung 15). Mitarbeiter der Personalabteilung ver-
wenden jeweils die Informationen aus mehreren zurückgegeben Gutachten bei der Entscheidungsfin-
dung. Im Anschluss müssen alle verwendeten Gutachten von der Personalabteilung als "erledigt" ge-
kennzeichnet werden. Diese Aktivität sollte nicht für jedes einzelne Gutachten sondern für alle ver-
wendeten Gutachten gleichzeitig ausgeführt werden können.
set
delivery
view
appli.
propose
rec. submit evaluate
rec. finish
run time time time
set
delivery
view
appli.
propose
rec. submit evaluate
rec. finish
set
delivery
view
appli.
propose
rec. submit evaluate
rec. finish
finish
Abbildung 15: Vertikale dynamische Granularität
Probleme
Neben der aktivitätsbasierten Modellierung führt auch die aktivitätsgetriebene Ausführung der Prozes-
se in herkömmlichen WfMS zu Flexibilitätsproblemen. Abgesehen von Schleifen kann jede Aktivität
genau einmal in einem eng festgelegten Kontext aktiviert werden. In der realen Arbeitspraxis müssen
manche Aktivitäten jedoch wiederholt ausgeführt werden, während andere dynamisch vorgezogen
oder zu einem späteren Zeitpunkt nachgeholt werden sollten [AWG05].
Jede aktuelle Aktivität, für deren Bearbeitung ein Benutzer autorisiert ist, wird innerhalb seiner Arbeits-
liste aufgeführt. Da ein Bearbeiter oft an mehreren Instanzen eines Prozesses beteiligt ist, sind oft vie-
le gleiche Aktivitäten in einer Arbeitsliste enthalten. Auch hier führt die isolierte Betrachtung einzelner
Prozessinstanzen zu Problemen, da jede Aktivität separat gestartet und durchgeführt werden muss
[SO05]. Dieses Vorgehen stimmt nicht immer mit der realen Arbeitspraxis überein und führt zudem zu
höheren Bearbeitungszeiten.
Anforderungen
Die Ausführung und Steuerung der Prozesse darf sich nicht an Aktivitäten orientieren, sondern muss
auf den jeweiligen Bearbeitungsfortschritt der Objektinstanzen ausgerichtet sein. Dadurch können ein
flexibleres Ausführungsverhalten und optionale Aktivitäten realisiert werden.
Die Granularität der Aktivitäten muss sich dynamisch an den Zustand der Prozessinstanzen anpas-
sen. Hierzu müssen sowohl eine horizontale als auch eine vertikale Dynamik möglich sein. Dies be-
deutet, Anzahl und Art der Aktionen in optionalen Aktivitäten muss auf den Fortschritt der zugehörigen
Prozessinstanz reagieren. Des Weiteren müssen gleiche obligatorische Aktivitäten für verschiedene
Prozessinstanzen bei Bedarf variabel zusammengefasst werden können.
Anhand der beschriebenen Herausforderung werden die Limitierungen derzeitiger WfMS deutlich.
Es ist nicht ausreichend Daten nur anhand von Attributen bzw. atomaren Datenelementen innerhalb
eines Prozess-Management-Systems zur Verfügung zu stellen. Eine vollständige Datenintegration
muss auf Attribut-, Objekt- und Strukturebene erfolgen. Diese Ebenen spiegeln sich in der Granulari-
tät der Prozesse wieder. Aktivitäten sollten im Bezug auf Attribute und Prozesse im Bezug auf Objekte
modelliert werden. Die Hierarchie und Synchronisation der Prozesse sollte analog zur Struktur der Da-
ten definiert werden. Eine Modellierung der Prozesse im direkten Bezug auf Daten anstatt anhand von
fest vorgegeben Aktivitäten, ermöglicht eine sehr viel flexiblere Auswahl und Ausführung von Aktivitä-
ten zu Laufzeit.
4 Verwandte Arbeiten
Die beschriebenen Herausforderungen wurden teilweise bereits von anderen Autoren adressiert. Die-
se stellen Teillösungen für einzelne Problematiken bereit. Eine Gesamtlösung ist derzeit jedoch nicht
zu finden. Abbildung 16 verdeutlicht, welcher Ansatz auf welche Herausforderungen eingeht bzw. Teil-
Lösungen dafür zur Verfügung stellt. Diese Einordnung wird innerhalb dieses Kapitels nun genauer er-
läutert.
atomic elements / attributes
objects
relations between data
flexible quantity
access beyond activities
activity
process
databased modelling
synchronisation
horizontal dynamic granul.
vertical dynamic granularity
data-driven execution
integration of data
granu-
larity
flexibility
Artifact Centric Modelling
IBM Research USA
Batch activities
University of Queensland
Case Handling
University of Eindhoven
Hasso Plattner Institute Potsdam
Data Driven Coordination
University of Twente / Ulm
Proclets
University of Eindhoven,
Colorado, Campinas
Production Based Support
University of Eindhoven
XX XXX
X X O
X X X
O
X
X X X
O X O X
O X O X
X X
X
X
X O X
Abbildung 16: Einordnung verwandter Arbeiten
Herausforderung 1: Datenintegration
Konzepte für eine stärkere Integration von Prozessen und Daten werden in den Ansätzen "Artifact-
Centric-Modeling" (ACM) [NC03, lBW07], "Production-Based-Workflow-Support" (PBWD) [RLA03,
VRA08], "Data-Driven-Process-Coordination" (Corepro) [MRH06, MRH07] and "Case Handling"
[AWG05] beschrieben.
Der Ansatz PBWS [RLA03, VRA08] integriert Beziehungen zwischen atomaren Datenelementen. Eine
Kapselung zu Objekten ist jedoch genauso wenig möglich wie die Berücksichtigung von variablen Ob-
jektmengen zur Laufzeit. Eine Verwaltung von Objekten sowie von deren Beziehungen zueinander
sind in Corepro [MRH06, MRH07] möglich. Des Weiteren können hier Beziehungen zwischen Objek-
ten beschrieben werden. Die Definition der Objekte erfolgt jedoch abstrahiert von einzelnen Attributen
anhand von Zuständen. Da Objekte anhand von Objekttypen definiert werden sind zur Laufzeit mehre-
re Objektinstanzen möglich. Die Anzahl der jeweiligen Objektinstanzen eines Typs sollte jedoch bei
der Modellierung festgelegt werden. Zur Laufzeit können zwar Objektinstanzen hinzugefügt werden,
für diese müssen dabei jedoch auch die benötigten Transitionen manuell "nachmodelliert" werden
[MRH08]. In ACM [NC03, lBW07] werden vor der Erstellung eines operationalen Modells so genannte
"Artifakte" identifiziert. Wie Objekte bestehen diese zwar aus verschiedenen Attributen, werden jedoch
nicht auf Typebene definiert. Eine mehrfache Instanziierung ist dadurch nicht möglich. Auch die Be-
schreibung von Beziehungen wird nicht unterstützt. Der Zugriff auf Daten ist bei allen diesen Ansätzen
nur im Kontext der Ausführung von Aktivitäten (d.h. an einer bestimmten Stelle im Prozessverlauf)
möglich. Der einzige Ansatz, der einen Zugriff auf Daten außerhalb von Aktivitäten erlaubt, ist Case
Handling [AWG05]. Allerdings können hier wiederum nur atomare Datenelemente verwaltet werden.
Betrachtet man den "Case" jedoch als Objekt, so kann von einer indirekten Kapselung der Attribute
gesprochen werden. Eine Definition von Beziehungen zwischen den Datenelementen ist beim Case
Handling allerdings nicht möglich.
Herausforderung 2: Wahl der Granularität von Aktivitäten und Prozessen
Daten und Datenstruktur schaffen Richtlinien für die Wahl der Granularität von Aktivitäten, Prozessen
und Sub-Prozessen. Prozesse definieren sich im Bezug auf Objekte und Aktivitäten dienen zur Bear-
beitung der zugehörigen Attribute. Des Weiteren können Prozesse zueinander in eine Hierarchie ge-
stellt werden. Diese ergibt sich anhand der Beziehungen zwischen den Objekten. Die vier oben ge-
nannten Ansätze sowie der "Proclets"-Ansatz [ABEW00] gehen auf die Granularität von Aktivitäten
oder Prozessen ein. Eine vollständige Definition der Prozesse in Analogie zu Attributen, Objekten und
Beziehungen ist jedoch in keinem dieser Ansätze möglich. In ACM [NC03, lBW07] findet eine Model-
lierung von Aktivitäten jeweils in Bezug auf ein oder mehrere Artifakte statt. Auf die Granularität des
Prozesses wird dagegen nicht eingegangen. Proclets [ABEW00] wiederum sind leichtgewichtige Pro-
zesse, die untereinander mittels Nachrichten kommunizieren. Hierbei können unterschiedliche Men-
gen von Prozessinstanzen der verschiedenen Prozesstypen berücksichtigt werden. Die Granularität
eines Prozesses wird nicht explizit definiert. Durch die Berücksichtigung der Mengenbeziehungen er-
gibt sich jedoch implizit eine Analoge zwischen Prozess und Objekt. Des Weiteren kann der Nachrich-
tenaustausch zwischen den Prozessen auf die Datenstruktur zurückgeführt werden. Über die Granula-
rität der Aktivitäten eines Prozesses wird allerdings keine Aussage gemacht. Corepro [MRH06,
MRH07] beschreibt eine explizite Koordination einzelner Prozesse in direktem Bezug auf die zugrun-
deliegende Datenstruktur. Die Granularität dieser Prozesse sowie die der einzelnen Aktivitäten kann
weiterhin frei gewählt werden. Der in PBWS [RLA03, VRA08] beschriebene Ansatz bezieht sich so-
wohl auf die Granularität von Aktivitäten als auch auf die Granularität von Prozessen. Aktivitäten be-
ziehen sich jeweils auf eine oder mehrere atomare Datenelemente. Die Struktur des Prozesses ergibt
sich 1:1 aus den Beziehungen der Datenelemente. Durch die fehlende Kapselung der Datenelemente
zu Objekten entsteht jeweils ein Gesamtprozess. Sub-Prozesse spielen in diesem Ansatz somit keine
Rolle. Auch beim Case Handling werden die einzelnen Aktivitäten in Bezug auf atomare Datenelemen-
te beschrieben. Durch deren implizite Kapselung zu einem "Case" ist auch die Granularität eines Pro-
zesses eindeutig. Allerdings ist keine Berücksichtigung der Datenbeziehungen möglich. Es können
keine Abhängigkeiten zwischen einzelnen Cases in expliziten Bezug auf die Datenstruktur modelliert
werden.
Herausforderung 3: Datenbezogene Modellierung
In ACM [NC03, lBW07] findet zwar keine datenbezogene Modellierung statt, jedoch werden einzelne
Aktivitäten in direktem Bezug auf die identifizierten Artifakte modelliert. Auch in Corepro [MRH06,
MRH07] werden Aktivitäten und Prozesse auf konventionelle Art modelliert. Die Koordination von Pro-
zessen erfolgt jedoch datenbasiert mit Bezug auf Objekte und deren Beziehungen. Die Objekte sind
hierbei anhand von Zuständen und Übergängen zwischen Zuständen definiert. Durch die Zuordnung
der Prozesse zu Zustandsübergängen wird für die Prozesse eines Objekts eine Reihenfolge festge-
legt. Prozesse, die unterschiedlichen Objekten zugeordnet sind, können anhand von sogenannten ex-
ternen Transitionen zueinander in Beziehung gesetzt werden. Externe Transitionen beschreiben Be-
dingung für den Zustandswechsel eines Objekts in Abhängigkeit von den Zuständen anderer Objekte.
Im Bezug auf eine datenbasierte Modellierung geht der Case Handling-Ansatz [AWG05] und PBWS
[RLA03, VRA08] am weitesten. Hier findet eine datenbezogene Modellierung von Aktivitäten in Bezug
auf atomare Datenelemente statt. Für jeden Prozessschritt wird jedoch nach wie vor auch eine Aktivi-
tät definiert. Von einer echten datenbasierten Modellierung kann deshalb auch hier nur eingeschränkt
die Rede sein.
Herausforderung 4: Synchronisation
Wie erwähnt, können bei Proclets [ABEW00] die Prozesse anhand von Nachrichten miteinander syn-
chronisiert werden. Hierbei kann eine zur Laufzeit variable Menge von Prozessinstanzen berücksich-
tigt werden. Ein Nachteil ist, dass die Synchronisation nicht explizit auf der Basis der Datenstruktur de-
finiert werden kann. Der mit Abstand stärkste Ansatz in Bezug auf diese Herausforderung ist die da-
tengetriebene Koordination von Prozessen [MRH06, MRH07]. Die Synchronisation erfolgt hier explizit
mit Bezug auf die zugrunde liegende Datenstruktur. Eine variable Menge von Instanzen kann zur
Laufzeit jedoch nur indirekt durch Ad-hoc-Änderungen am Prozess gehandhabt werden.
Herausforderung 5: Flexibilität
Eine horizontale dynamische Granularität ist nur beim Case Handling [AWG05] möglich. Ein Daten-
element kann innerhalb von mehreren Aktivitäten gelesen und geschrieben werden. Dabei können die
Datenelemente jeweils entweder als frei, obligat oder optional gekennzeichnet werden. Ein Datenele-
ment, das für eine Aktivität obligat ist, kann in vorausgehenden Aktivitäten optional zur Verfügung ge-
stellt werden. Der in [SO05] beschriebene Ansatz geht auf die vertikale dynamische Granularität von
Aktivitäten ein. Der Benutzer hat die Möglichkeit, innerhalb seiner Arbeitsliste gleichartige Aktivitäten
aus verschiedenen Prozessinstanzen zu gruppieren, um diese dann gemeinsam auszuführen. Eine
datengetriebene Ausführung von Prozessen beschreiben [AWG05] und [RLA03, VRA08]. Die Steue-
rung der Prozesse erfolgt hier in Abhängigkeit von den vorliegenden Daten bzw. den vorliegenden
Werten der Daten. In Corepro [MRH06, MRH07] werden die einzelnen Prozesse zwar nach wie vor
aktivitätsbasiert ausgeführt, es findet jedoch eine datengetrieben Koordination statt.
Alle bisherigen Ansätze beziehen jeweils nur auf wenige Teilaspekte der in diesem Aufsatz diskutier-
ten Herausforderungen. Eine Gesamtlösung für ein datenorientiertes Prozess-Management-System
steht nicht zur Verfügung.
5 Vision und Ausblick
Unser Ziel ist die Entwicklung eines Rahmenwerks für ein datenorientiertes Prozess-Management-
System. Dadurch soll die generische Unterstützung von datenorientierten Prozessen mit einer integ-
rierten Sicht auf Informationen und Prozesse möglich sein. Das System soll die Funktionalität von da-
tenorientierten Anwendungen abbilden können und gleichzeitig die Vorteile bieten, die konventionelle
Workflow-Management-Systeme mit sich bringen. Um dies zu erreichen, müssen nicht nur Daten und
Prozesse besser integriert werden. Auch in Bezug auf die Einbindung des Benutzers entstehen neue
Herausforderungen. Anwendungsdaten und Organisationsmodell können nicht mehr getrennt verwal-
tet werden. Des Weiteren ist die Vergabe von Berechtigungen in Bezug auf einzelne Aktivitäten nicht
mehr ausreichend. Zusätzlich ist entscheidend, auf welche Daten ein Benutzer innerhalb einer Aktivi-
tät Zugriff hat. Dies kann nicht mehr allein auf Typebene definiert werden. Durch die direkte Zuord-
nung von Benutzern zu einigen Objektinstanzen entstehen Beziehungen zwischen Objekten und Be-
nutzern die bei der Autorisierung berücksichtigt werden müssen.
Aktuell entwickeln wir deshalb eine grundlegend neue Architektur für ein datenorientiertes Prozess-
Management-System. Weitere Arbeiten werden die detaillierte Beschreibung der einzelnen Kompo-
nenten und deren Zusammenhänge umfassen.
Literatur
[RD00]
M. Reichert, P. Dadam: Geschäftsprozessmodellierung und Workflow-Management -
Konzepte, Systeme und deren Anwendungen. GITO-Verlag, Industrie Management,
Vol. 16, No. 3, pp. 23-27.
[AH04] W. M. P. van der Aalst, K. van Hee: Workflow-Management - Models, Methods and
Systems. MIT Press, 2004.
[AHKB03] W.M.P van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros: Workflow
Patterns, Distributed and Parallel Databases, 14(3), pages 5-51, July 2003.
[NC03]
A. Nigam, N.S.Caswell: BusinessArtifactsAnApproachToOperationalSpecification. IBM
Systems Journal, Vol 42, No3, 2003.
[lBW07]
R.Liu, K.Bhattacharya, F.Y.Wu: ModelingBusinessContextureAndBehaviorUsingBusi-
nessArtifacts. Proc. CAiSE 2007, LNCS 4495, pp.324-339.
[GS07]
C. E. Gerede, J. Su: Specification and Verification of Artifact Behaviors in Business
Process Models. Proc. ICSOC 2007, LNCS 4749, pp. 181-192.
[AWG05]
W. M. P. van der Aalst, M. Weske, D. Grünbauer: Case Handling: A new paradigm for
business process support. Data & Knowledge Engineering 53 (2005) 129-162.
[MRH06]
D. Müller, M. Reichert, J.Herbst: Flexibility of Data-Driven Process Structures
Proc. BPM 2006 Workshops, pp. 179-190. LNCS 4103.
[MRH07]
D. Müller, M. Reichert, J. Herbst: Data-Driven Modeling and Coordination of Large
Process Structures. Proc. CoopIS 2007, pp. 131-149.
[MRH08]
D. Müller, M. Reichert, J. Herbst: A New Paradigm for the Enactment and Dynamic Ad-
aptation of Data-driven Process Structures. Proc. CAiSE'08, Montpellier, France.
Springer, LNCS 5074, pp. 48-63.
[G05]
K. Göser: Plug & Play - Aspekte und Integration Zustandsbehafteter Daten in Prozess-
Management-Systeme. Diplomarbeit, Universität Ulm, Abteilung DBIS.
[RKG06]
K. Ryndina, J. M. Kuester, H. Gall: Consistency of Business Process Models and Ob-
ject-Life-Cycles. Proc. MoDELS 2006 Workshops, LNCS 4364, pp. 80-90.
[KRG07]
J. M. Kuester, K. Ryndina, H. Gall: Generation of Business Process Models for Object-
Life-Cycle-Compliance. Proc. BPM 2007, LNCS 4714, pp. 165-181.
[RDHI07]
G. Redding, M. Dumas, A. H. M. ter Hofstede, A. Iordachescu: Transforming Object-
oriented Models to Process-oriented Models. Proc. BPM 2007 Workshops, LNCS 4928,
pp. 132-143.
[RLA03]
H. A. Reijers, S. Limam, W. M. P. van der Aalst: Product-Based Workflow Design. Jour-
nal of Management Information Systems 2003, Vol. 20, No 1, pp. 229-262.
[VRA08]
I. Vanderfeesten, H. A. Reijers, W. M. P. van der Aalst: Product-Based Workflow Sup-
port: Dynamic Workflow Execution. Proc. CAiSE 2008, LNCS 5074, pp. 571-574.
[SO05]
S. Sadiq, M. Orlowska: When workflows will not deliver - The case of contracting work
practice. Proc. BIS 2005, Poland.
[ABEW00]
W. M. P. van der Aalst, P. Barthelmess, C. A. Ellis, J. Wainer: Workflow Modeling Using
Proclets. Proc. CoopIS 2000, volume 1901 of Lecture Notes in Computer Science,
pages 198-209.
