ADEPT - Prozess-Management-Technologie
der nächsten Generation 1,2
Peter Dadam ⋅ Manfred Reichert
Universität Ulm
Fakultät für Informatik, Abt. Datenbanken und Informationssysteme
Email: {dadam, reichert}@informatik.uni-ulm.de
Zusammenfassung
Die Unterstützung unternehmensweiter und -übergreifender Geschäftsprozesse
stellt für Prozess-Management-Systeme (PMS)3 eine besondere Herausforderung
dar: Es sind sehr viele Organisationseinheiten (auch externe) involviert, die Pro-
zesse können langlaufend sein (Wochen, Monate), sie müssen rasch an neue Gege-
benheiten anpassbar sein, und bei Bedarf muss im Einzelfall spontan vom geplan-
ten Ablauf abgewichen werden können (z. B. Auslassen, Einfügen oder Ver-
schieben von Prozessschritten). Prozessorientierte Anwendungssysteme müssen –
auch im Fall von Ad-hoc-Abweichungen – für EDV-Laien einfach bedienbar sein,
sie müssen robust und stabil laufen und das PMS muss auch bei einer großen An-
zahl von Benutzern und Prozessinstanzen performant sein. Im Rahmen des
ADEPT-Projektes arbeiten wir seit 1994 intensiv an den technologischen Grund-
lagen und der Entwicklung eines PMS der nächsten Generation, das alle diese As-
pekte ganzheitlich und sehr grundlegend adressiert. Der realisierte ADEPT-PMS-
Prototyp weist die Implementierbarkeit und das Zusammenspiel der entwickelten
Konzepte nach und zeigt, dass Flexibilität, Robustheit und Effizienz keine Wider-
sprüche sein müssen. Der Beitrag erläutert die zugrundeliegende Problemstellung,
die technologischen Herausforderungen sowie die Einsatzperspektiven für ein sol-
ches System.
1 Einleitung
Mit E-Business entstehen neue Spielregeln im Markt, worauf sich die Unternehmen
rasch mit geeigneten Strategien einstellen müssen. Auf ständig neue Trends und Heraus-
forderungen müssen sie mit immer neuen Produkt- und Serviceangeboten reagieren und
diese schnell in die betrieblichen Abläufe integrieren (siehe Abbildung 1). Die optimale
1 Diese Forschung wurde vom Land Baden-Württemberg, als Teilprojekt im Rahmen des Softwarelabors Ulm,
und von der DFG im Rahmen der Projekte „Skalierbarkeit in adaptiven Workflow-Management-Systemen“
sowie „Änderungsmanagement in adaptiven Workflow-Management-Systemen“ gefördert.
2 Dieser Beitrag lehnt sich in Teilen an die Veröffentlichung [RBFD01] an.
3 Wir werden im Folgenden in Bezug auf ADEPT von Prozess- und nicht von Workflow-Management-Syste-
men sprechen, da hier eine sehr viel weitergehende und umfassendere Technologie gemeint ist, als gemeinhin
mit Workflow-Management-Systemen adressiert wird.
In: Spath, D.; Haasis, K. (Hrsg.): Aktuelle Trends in der Softwareforschung,
Tagungsband zum doIT Software-Forschungstag 2003, IRB Verlag Stuttgart 2004,
ISBN 3-8167-6453-3, S. 27-43
Gestaltung und Beherrschung der Geschäftsprozesse sowie die Fähigkeit, diese rasch
und kostengünstig an neue Gegebenheiten anzupassen, wird in diesem Kontext für viele
Unternehmen zur Überlebensfrage.
Die rasche Anpassbarkeit von Geschäftsprozessen wird auch deshalb immer wichtiger,
weil andere Rationalisierungspotenziale für Unternehmen weitgehend ausgereizt sind
und sie sich deshalb gegenüber dem Wettbewerb kaum mehr über den Preis differenzie-
ren können. In dieser Situation werden Qualitätsaspekte zu einem entscheidenden Wett-
bewerbsfaktor. Vieles, was derzeit im Kontext von E-Business diskutiert wird, wie
Customer Relationship Management (CRM), Supply Chain Management (SCM) oder E-
Procurement, zeigt bereits in diese Richtung und deutet an, was in Zukunft an Marktdy-
namik auf die Unternehmen zukommen wird.
Für den schnellen und erfolgreichen Einstieg ins E-Business genügt es aber nicht, die
Prozesse an bereitgestellte IT-Funktionen (z. B. SAP R/3) anzupassen. Die Unternehmen
müssen vielmehr auf die sich ständig ändernde Wettbewerbssituation durch rasche Um-
gestaltung ihrer Geschäftsprozesse reagieren können. Sie müssen in der Lage sein, in
kurzer Zeit – unter Umständen sogar innerhalb von Tagen oder Stunden – auf Aktionen
der Mitbewerber zu reagieren und ihre Geschäftsprozesse sowie die sie unterstützenden
Anwendungssysteme entsprechend rasch anzupassen oder sogar neu zu implementieren.
Wenn sich ein Prozess ändert, wollen Nutzer allerdings nicht jedes Mal aufwendige
Programmierarbeit leisten, sondern sie möchten ihre Abläufe möglichst rasch und ein-
fach neu strukturieren bzw. definieren können. Dabei sind sowohl zugekaufte Systeme
(z. B. ERP-Anwendungen) als auch historisch gewachsene Applikationen (Legacy Sys-
tems) auf Daten-, Funktions- und Prozessebene zu integrieren.
Dies erfordert ein radikales Umdenken hinsichtlich der IT-seitigen Unterstützung der
Geschäftsprozesse. Es gilt, die rein funktions- und datenzentrierten Sichten, bei der die
prozessorientierte Verknüpfung der Anwendungsfunktionen weitgehend in den Köpfen
der Mitarbeiter oder „hart verdrahtet“ in den Anwendungsprogrammen vorhanden ist,
konsequent zu erweitern [DaRK00]. Prozessänderungen sind in diesem Umfeld extrem
M-Commerce
B2B
E-Commerce
CRM
Web-Shops
elektronische
Marktplätze
E-Procurement
...
externe
Dienste
Interne Abläufe
Ständig neue Trends erfordern von Unternehmen ... ... ständig neue Produkt- und Service-
angebote, die in existierende Abläufe
integriert werden müssen
Abb. 1: Neue Herausforderungen durch E-Business
fehlerträchtig und nur mit sehr hohem Aufwand an Personal, Kosten und Zeit zu bewerk-
stelligen [RDMK00].
Aus diesen Gründen müssen prozessorientierte Anwendungen in Zukunft rasch im „Plug
& Play“-Stil entwickelt sowie an neue Gegebenheiten angepasst werden können (siehe
Abbildung 2). Um dies zu ermöglichen, wird eine Software-Technologie benötigt, die in
umfassender, ganzheitlicher Weise unternehmensweite und –übergreifende Geschäfts-
prozesse ausführen, verwalten und überwachen kann. Es muss ferner möglich sein, not-
wendige Prozessänderungen rasch einzubringen und sie automatisch „per Knopfdruck“
auf schon laufende Prozesse zu übertragen.
Darüber hinaus dürfen Prozesse niemals „starr“ implementiert sein. Im Bedarfsfall müs-
sen Anwender ad hoc vom vorgeplanten Ablauf abweichen können, wenn beispielsweise
eine nicht vorhergesehene Ausnahmesituation eingetreten ist [DaRK00]. Die Unter-
stützung einer solchen Flexibilität ist für viele Anwendungen unterlässlich. Sie bedingt
aber auch, dass systemseitig geprüft und sichergestellt werden kann, dass bei Ad-hoc-
Änderungen im weiteren Verlauf des betroffenen Prozesses keine Inkonsistenzen auftre-
ten [ReDa98, Reic00].
Für die elektronische Unterstützung von Geschäftsprozessen wichtige, von derzeitigen
Prozess-Mangement-Systemen (PMS) bzw. Workflow-Management-Systemen (WfMS)
aber bisher kaum oder gar nicht betrachtete Anforderungen sind:
• Konsequente Trennung von Ablauflogik und Anwendungscode
• Rapid Prototyping durch „Plug & Play“-Techniken
• Intensive Korrektheitsprüfungen bereits zur Modellierungszeit
• Unterstützung von Ad-hoc-Änderungen einzelner Prozesse mit systemseitiger Kon-
sistenzsicherung
Prozess-
Vorlagen
Applikations-
Komponenten
Anwender
Prozess-Modellierer /
Prozess-Administrator
...
Prozess 4
Prozess 3
Prozess 2
Prozess 1
Prozess 6
Prozess 5
Prozess 11
Prozess 10
Prozess 9
Prozess 8
Prozess 7
Prozess 14
Prozess 13
Prozess 12
Repository
ADEPT Workflow Management System
Process Execution Engine
Alle Tests
OK!?
Anwendungen / Application Server
Msg Queuing
Time MgmtAuthorization
Client API Web Cl. API
Role Mgmt
Dyn. Change APIModeling API
Admin. API
Recovery Audit Trail ...
ADEPT Process
Composer
Create Process Template
Modify Process Template
Check Process Template
...
Go!
RollbackAdhoc Change
Schema Evol.Distribution
Connect with Applications
Abb. 2: Zukünftige Entwicklung prozessorientierter Anwendungen mittels Plug & Play
• Unterstützung und Überwachung von temporalen Bedingungen
• Rasche Umsetzung von Prozessänderungen durch Prozess-Schemaevolution
• Skalierbarkeit für den unternehmensweiten Einsatz
• Unterstützung übernehmensübergreifender Anwendungen
• Scheduling und Resourcen-Management, Bereitstellung eines „Prozess-Leitstands“
• Fundierte theoretische Basis.
Production Workflow Systeme [LeRo00], wie MQSeries Workflow oder Staffware,
zeigen im Prinzip bereits in die richtige Richtung. Prozesslogik und Anwendungs-
funktionalität sind hier voneinander getrennt. Eine große Schwäche dieser Systeme liegt
jedoch in ihrer Starrheit, d. h. in ihrer nicht vorhandenen oder sehr schwach ausgepräg-
ten Fähigkeit, flexibel auf Ausnahmesituationen zu reagieren [CaCP98, MüRa00, Re-
Da98, Wesk98]. Dies schränkt, neben anderen wichtigen fehlenden Fähigkeiten (s.
[JaBS97, Reic00]), ihre breite Einsetzbarkeit ganz erheblich ein [DaRK00].
In diesem Beitrag geben wir einen Überblick zum ADEPT-Projekt. Es wurde 1994 mit
dem Ziel initiiert, alle relevanten Aspekte von PMS im Zusammenwirken zu untersuchen
und eine umfassende theoretische und konzeptionelle Grundlage für die ganzheitliche
Realisierung eines solchen Systems zu erarbeiten.
Der Abschnitt 2 erläutert wichtige technologische Herausforderungen für PMS der näch-
sten Generation. In Abschnitt 3 zeigen wir exemplarisch, wie einige von ihnen im
ADEPT-Projekt aufgegriffen werden und welche Konzepte hieraus hervorgegangen
sind. Der Beitrag schließt mit einer kurzen Diskussion (Kapitel 4) und Zusammenfas-
sung (Kapitel 5).
2 Technologische Herausforderungen
Prozess-Management-Systeme (PMS) müssen in der Lage sein, ein breites Spektrum an
Geschäftsprozessen flexibel und effizient zu unterstützen. Wichtige Herausforderungen
in diesem Zusammenhang sind:
1. Das PMS muss einen ausdrucksstarken Formalismus für die Prozessmodellierung
(sog. Prozessmetamodell) bereitstellen, der für Entwerfer verständlich ist und der
die konsistente Beschreibung aller relevanten Prozessaspekte (Kontroll- und Daten-
fluss, zeitliche Beschränkungen, organisatorische Aspekte, usw.) gestattet.
2. Das PMS muss ein zuverlässiges und robustes Ausführungsverhalten besitzen. Aus
diesem Grund sollte bereits zur Modellierungszeit ausgeschlossen werden, dass es
während der Ausführung von Prozessinstanzen infolge fehlerhafter Prozessmodelle
zu ungewollten „Überraschungen“ kommen kann. Beispiele hierfür sind Blockie-
rungen, nicht erfüllbare Zeitconstraints und der Aufruf von Programm-Moduln bei
fehlenden oder unvollständigen Parameterdaten.
3. In vielen Anwendungsumgebungen ist jedes starre System, auch bei ansonsten ide-
aler Prozessunterstützung, zum Scheitern verurteilt. Krankenhausprozesse etwa
weisen eine hohe Variabilität und Dynamik auf, so dass üblicherweise nicht alle
Prozessvarianten vormodelliert werden können [DaRK00, RDMK00]. Hinzu
kommt, dass unvorhersehbare Ausnahmen im Verlauf der Ausführung von Klinik-
prozessen eher den Normalfall bilden. Anwender müssen deshalb im Einzelfall
spontan vom geplanten Ablauf, d. h. vom modellierten Prozess, abweichen können,
etwa durch Auslassen, Einfügen oder Verschieben von Prozessschritten.
4. Solche Ad-hoc-Änderungen dürfen niemals zu Konsistenz- oder Korrektheitsver-
letzungen führen. Das bedeutet, dass prozessorientierte Anwendungen auch im An-
schluss an Änderungen robust und stabil laufen müssen. Die hierzu notwendigen
On-the-fly-Modellanalysen müssen effizient durchführbar sein, was mit zunehmen-
der Ausdrucksmächtigkeit des verwendeten Prozess-Metamodells jedoch immer
schwieriger wird.
5. Prozessorientierte Anwendungen müssen – auch im Fall von Ad-hoc-Abwei-
chungen – für EDV-Laien einfach bedienbar sein. Insbesondere sollte die mit der
Festlegung einer Ad-hoc-Änderung verknüpfte Komplexität vor ihnen verborgen
bleiben, etwa in Bezug auf das Re-Mapping der Ein-/Ausgabeparameter der von
der Änderung betroffenen Progamm-Module oder die Behandlung fehlender Daten
nach dem Löschen von Prozessschritten. Ebensowenig sollte sich der Benutzer um
die Anpassung von Prozesszuständen kümmern müssen. Stattdessen muss das PMS
geeignete Modifikationsoperatoren auf einem hohen Abstraktionsniveau anbieten
(kein Pop-Up eines Modell-Editors).
6. Prozessorientierte Anwendungen sind nur dann auf breiter Basis einsetzbar, wenn
sie sich rasch an geänderte Geschäftsprozesse anpassen lassen. Insbesondere müs-
sen Änderungen auf Prozess-Schemaebene (sog. Schema-Evolution) – falls ge-
wünscht und möglich – auch auf bereits laufende Prozessinstanzen angewendet
werden können. Dies muss – selbst bei großer Anzahl von Instanzen – fehlerfrei
und effizient erfolgen [ReRD03, RiRD04].
7. Die Unterstützung und Überwachung komplexer Zeitbedingungen (z. B. minimale /
maximale Zeitabstände zwischen Aktivitäten) ist für viele Anwendungen essentiell.
Ein PMS muss deshalb über Fähigkeiten zur Überwachung von Terminen und
Terminabhängigkeiten verfügen. Die fristgerechte Durchführung von Tätigkeiten
muss durch Hinweise auf drohende Terminverletzungen unterstützt werden, auch
im Kontext von gewünschten Ad-hoc-Abweichungen.
8. Von einem PMS werden häufig Daten verarbeitet, an die hinsichtlich Datenschutz
und Datensicherheit strenge Maßstäbe angelegt werden müssen. Die Rechte einer
Person für den Zugriff auf diese Daten sind dabei über die Rolle oder Funktion ge-
regelt, welche sie gerade einnimmt. Bereits im statischen Fall sind die realen Rol-
lenverteilungen und Vertretungsregelungen häufig sehr komplex und stellen hohe
Anforderungen an das PMS, insbesondere im Hinblick auf die Pflege von Organi-
sationsmodellen.
9. Im dynamischen Fall kommt erschwerend hinzu, dass durch Änderungen des Ab-
laufgraphen keine "Datenschutzlücken" entstehen dürfen. Aus diesem Grund muss
sehr fein steuerbar sein, wer in welcher Rolle und in welchen Prozesszuständen
welche Änderungen durchführen bzw. welche Informationen (z. B. Ausführungs-
historie, Änderunghistorie usw.) abrufen darf. Entsprechende Einschränkungen
sind auch deshalb sinnvoll, weil einzelne Anwender oft nur eine eingeschränkte
Sichtweise auf Abläufe besitzen. Dadurch können Prozessänderungen, die aus der
Sicht des Einzelnen durchaus sinnvoll erscheinen, im Widerspruch zu übergeordne-
ten Interessen (Einhaltung von Fristen, organisatorische Regelungen usw.) stehen.
Diese Problematik ist bei unternehmensweiten und –übergreifenden Prozessen ver-
stärkt ausgeprägt.
10. Um unternehmensweite und -übergreifende Prozesse angemessen zu unterstützen,
muss das PMS auch bei einer großen Anzahl von Benutzern und Prozessinstanzen
performant arbeiten [DaRe99, BaRD03].
Obwohl bereits sehr umfangreich, ist diese Liste längst noch nicht vollständig. Weitere
wichtige Anforderungen betreffen zum Beispiel die Handhabung von Inter-Prozess-Ab-
hängigkeiten [Hein02], die komponentenbasierte Entwicklung von prozessorientierten
Anwendungen oder das semantische Rollback von Prozessinstanzen beim Auftreten lo-
gischer Fehler. Zukünftige PMS werden, sofern sie diesen Anforderungen gerecht wer-
den, in vielen anspruchsvollen Anwendungsdomänen einsetzbar sein. Im Rahmen des
ADEPT-Projektes arbeiten wir seit 1994 intensiv an den technologischen Grundlagen
und der Entwicklung eines PMS der nächsten Generation, das alle diese Aspekte (und
noch einige mehr) ganzheitlich und sehr grundlegend adressiert.
3 Realisierung mit dem ADEPT-PMS
Den skizzierten Anforderungen kann man nicht dadurch gerecht werden, indem man sie
isoliert voneinander betrachtet. In ADEPT versuchen wir deshalb, die verschiedene Fa-
cetten prozessorientierter Anwendungen integriert zu behandeln: Benutzerschnittstellen,
Modellierungsfragestellungen und -werkzeuge, planbare / nicht planbare Ausnahme-
behandlungen, Flexibilität und dynamische Prozessänderungen, Schemaevolution, tem-
porale Aspekte, Inter-Prozess-Abhängigkeiten und Skalierbarkeit. Aus Platzgründen
können wir an dieser Stelle nicht auf alle diese Aspekte eingehen. Stattdessen konzen-
trieren wir uns auf dynamische Prozessänderungen und Skalierbarkeitsfragestellungen.
Weitergehende Informationen findet man in [Baue01, BaDa00, BaRD01, BaRD03,
HRB+00, ReBD03, ReRD03, ReDa98, Reic00, RiRD04].
3.1 Prozessmodellierung
ADEPT stellt für den Prozessmodellierer ein ausdrucksstarkes Prozessmetamodell be-
reit, das es erlaubt, Geschäftsprozesse möglichst natürlich und in einer für die Anwender
verständlichen Form abzubilden. Darüber hinaus ist die effiziente Überprüfung bzw.
Sicherstellung wichtiger Modelleigenschaften möglich, etwa im Hinblick auf die Akti-
vierbarkeit von Prozessschritten, die Verklemmungsfreiheit des modellierten Prozesses
oder die Korrektheit der definierten Datenflüsse. ADEPT verwendet dazu das graph-
basierte Prozessmetamodell ADEPTbase, das die integrierte Beschreibung der verschiede-
nen Aspekte eines Prozesses ermöglicht [RDMK00, ReBD03, Reic00].
Für die Kontrollflussmodellierung wird ein blockbasierter Beschreibungsansatz verfolgt,
bei dem Sequenzen, Verzweigungen und Schleifen als logische Blöcke mit jeweils genau
einem Ein- und Ausgangsknoten modelliert werden. Solche Kontrollblöcke können ge-
schachtelt sein, dürfen sich aber nicht überlappen. Um die Ausdrucksmächtigkeit des
Metamodells zu erhöhen, werden zusätzliche Konstrukte angeboten, etwa zur Beschreib-
ung verschiedener Arten von „Wartet-Auf“-Beziehungen zwischen Aktivitäten paralleler
Zweige oder zur Vormodellierung ausnahmebedingter Vorwärts- und Rückwärtssprünge
im Kontrollfluss (z. B. partielles Rollback der Prozessinstanz). Desweiteren stellt A-
DEPTbase auch Konstrukte zur Modellierung von Datenflüssen, zeitlichen Einschränk-
ungen (z. B. Mindest- oder Maximalzeitabstände zwischen Aktivitäten) und organi-
satorischen Aspekten bereit. Ein einfaches Beispiel eines ADEPT-Prozessmodells zeigt
Abbildung 3.
Patientenakte
überprüfen
Daten
sammeln
Patient
aufnehmen
Patient
untersuchen
Medikation
anordnen
Dosis
berechnen
Medikament
herstellen
Dosis
validieren
Labortest
durchführen
Probe
entnehmen
Laborbefund
prüfen
PatientId
Gewicht
+ Grösse
Dosis
Medikament
verabreichen
Patient
nachversor
g
en
Patient
entlassen
Weiterer
Zyklus?
false
true LOOP
Prozessvariable
AND-Split AND-Join
externer Termin
max.
Zeitabstand
3 h
Datenfluss Kontrollfluss
Abb. 3: Prozess-Modellierung in ADEPT
Auf Ausführungsebene wird jede Prozessinstanz um Zustandsinformationen angerei-
chert, die von der ADEPT Process Engine für die Prozess-Steuerung benötigt werden.
Zur Unterstützung der Kontrollflusssteuerung werden den Knoten und Kanten des Aus-
führungsgraphen einer Prozessinstanz entsprechende Zustandsmarkierungen zugeordnet.
Für ihre Handhabung gibt es wohldefinierte Regeln, die festlegen, unter welchen Graph-
markierungen eine Prozessaktivität aktiviert werden darf und welche Folgemarkierungen
sich im Anschluss an ihre Ausführung ergeben können [Reic00]. Dabei bleiben die Zu-
standsmarkierungen bereits abgearbeiteter bzw. nicht mehr ausführbarer Bereiche des
Prozessgraphen beim Fortschreiten der Bearbeitung erhalten, zumindest solange die
entsprechenden Graphregionen nicht wiederholt (z. B. nach Schleifenrücksprüngen)
durchlaufen werden. Dadurch können Informationen zum bisherigen Verlauf der Pro-
zessausführung direkt aus den aktuellen Graphmarkierungen abgeleitet werden, was für
die effiziente Überprüfung der Anwendbarkeit dynamischer Änderungsoperationen vor-
teilhaft ist [ReDa98].
3.2 Unterstützung dynamischer Prozessänderungen
Berechtigte Anwender können in ADEPT dynamische Prozessänderungen auf einem
hohen Abstraktionsniveau festlegen. Die Grundlage hierfür bildet das ADEPTflex-Kalkül,
das einen vollständigen Satz an Modifikationsoperatoren anbietet, mit denen sich die
Struktur, die Attribute oder der Status von sich in Ausführung befindlichen Prozess-
Instanzen abändern lassen [ReDa98, Reic00].
Unterstützt werden Operationen für das Hinzufügen, Löschen (vgl. Abbildung 4) und
Verschieben einzelner Aktivitäten oder ganzer Kontrollblöcke, für die Abänderung von
Datenflüssen, für die Modifikation einzelner Ausführungsattribute (z. B. Ressourcen-
/Bearbeiterzuordnungen, Verzweigungsprädikate) und für das kontrollierte Zurücksetzen
der Prozessbearbeitung. Durch ihre kombinierte Anwendung können semantisch höher-
wertige Änderungen realisiert werden, etwa für das dynamische Einfügen einer Aktivität
zwischen zwei Knotenmengen oder für die Umsetzung von Ad-hoc-Vorwärtssprüngen
(wie z. B. vorzeitige Bearbeitung einer Aktivität mit Nachholen der übersprungenen
Schritte).
a)
b)
c)
A
C B
deleteActivity(..., B, ...)
A
C
A
CB
A
C
D
B
A
D B
deleteActivity(..., C, ...) leerer Zweig!
A
C
D
B
A
C
D
B
deleteActivity(..., D, ...)
A
C
D
B
A
C
B
NT=NU
L
Abb. 4: Beis
p
iele für das Löschen von Aktivitäten in ADEPT
Prozessinstanz-Änderungen sind in ADEPT nur zulässig, wenn sie die Konsistenz des
Prozesses nicht verletzen. Zur Erfüllung dieser Forderung müssen alle Aspekte des Pro-
zesses und ihre Wechselwirkungen beachtet werden, selbst wenn sie nicht unmittelbar
Gegenstand der beabsichtigten Modifikation sind. Bei Änderungen der Kontrollfluss-
struktur sorgt ADEPT z. B. selbständig dafür, dass die Blockstrukturierung aufrechter-
halten bleibt und dass keine Verklemmungssituationen eintreten. Dies wird durch die
Vorgabe geeigneter Vor- und Nachbedingungen für die Anwendung von Änderungs-
operationen erreicht. Des weiteren wird bei Anwendung von Änderungsoperationen, wie
dem Einfügen, Löschen oder Verschieben von Aktivitäten (inkl. ihrer Schreizugriffe auf
Prozessvariablen), sichergestellt, dass im weiteren Verlauf der Prozessausführung keine
Inkonsistenzen (z. B. Lost Updates) oder Fehler (z. B. Aufruf von Aktivitätenprogram-
men mit unvollständig versorgten Eingabeparametern) auftreten. Sind z. B. obligate
Eingabeparameter einer Aktivität nach dem Löschen einer Vorgängeraktivität nicht mehr
versorgt, muss die Löschoperation entweder abgebrochen werden oder es sind beglei-
tende Anpassungen vorzunehmen (z. B. kaskadierendes Löschen datenabhängiger
Schritte, Installation von Nachforderungsdiensten, die bei der Aktivierung des datenab-
hängigen Schrittes gerufen werden, usw.).
ADEPTflex sorgt selbständig dafür, dass nach der Anwendung einer dynamischen Ände-
rung wieder ein Prozess mit konsistentem Zustand resultiert. Um dies sicherzustellen,
schränken wir die Anwendbarkeit von Änderungsoperationen durch den aktuellen Zu-
stand der jeweiligen Prozessinstanz (d. h. den Knoten- und Kantenmarkierungen ihres
Ausführungsgraphen) ein. Beispielswiese dürfen bereits abgeschlossene Aktivitäten
nicht mehr gelöscht oder ihre Ausführungsattribute nachträglich verändert werden. E-
bensowenig darf eine neue Prozessaktivität in einen bereits abgearbeiteten Teil eines
Ausführungsgraphen eingefügt werden. Entsprechende Statusüberprüfungen werden vor
Anwendung einer Änderungsoperation bzw. -transaktion durchgeführt. Darüber hinaus
wird nach der strukturellen Abänderung eines Ausführungsgraphen sein Status neu be-
wertet und ggf. angepaßt, z. B. durch die Zuordnung von Markierungen zu neu eingefüg-
ten Knoten und Kanten. Anschließend kann mit der Prozessausführung in einem
konsistenten Zustand fortgefahren werden.
Das ADEPT-PMS stellt ebenfalls sicher, dass bei der Anwendung einer Änderungstrans-
aktion wieder ein Prozess mit konsistentem, d.h. erfüllbarem Zeitplan resultiert. Die Ein-
haltung dieser Forderung wird nicht nur bei der Änderung von Zeitattributen geprüft,
sondern auch in Verbindung mit Modifikationen der Kontrollflussstruktur. Beispielswei-
se können sich durch das Einfügen einer Aktivität (mit bekannter minimaler und maxi-
maler Zeitdauer), die frühesten Anfangszeitpunkte nachfolgender Aktivitäten nach
hinten verschieben. Je nachdem, ob dadurch zuvor festgelegte Termine noch erfüllbar
sind oder nicht, können die notwendigen Anpassungen automatisch durch das PMS
erfolgen, oder sie müssen in Interaktion mit den Anwendern ermittelt werden.
3.3 Prozess-Schema-Evolution
(Geschäfts-)Prozesse sind immer wieder Veränderungen unterworfen. Sei es, dass sich
der aktuelle gewählte Ablauf als nicht optimal herausstellt, sei es, dass innerbetriebliche
Umstellungen vorgenommen oder betriebliche Funktionen aus- bzw. eingelagert werden
oder dass sich äußere Rahmenbedingungen (z. B. Markt, gesetzliche Regelungen) än-
dern, die sich auf die interbetrieblichen oder betriebsübergreifenden Abläufe auswirken.
Muss nun das Prozess-Schema geändert werden, so ist sicherlich eine Minimalanforde-
rung an ein PMS, dass die auf dem alten Schema basierenden Prozessinstanzen ungestört
bzw. individuell modifiziert zu Ende geführt werden können, während – parallel dazu –
neue Prozessinstanzen, die bereits auf dem neuen Prozess-Schema basieren, zur Ausfüh-
rung gebracht werden. Für kurzlaufende Prozesse ist diese Vorgehensweise völlig adä-
quat und ausreichend. Ist man aber mit langlaufenden Prozessen konfrontiert, wie sie
etwa im Krankenhaus (Chemotherapie: 6 Monate und länger), im Bank- und Versiche-
rungsgeschäft (Pkw-Leasing: 3 Jahre) oder im Konstruktionsbereich auftreten, dann
muss man versuchen, die schon laufenden Instanzen – soweit noch möglich und sinnvoll
auf das neue Schema umzustellen. Dieser Vorgang wird als „Workflow-Schema-
Evolution“ [RiDa03] bzw. „Prozess-Schema-Evolution“ bezeichnet. Manuell, also mit
individueller Modifikation der Prozessinstanzen, ist diese Aufgabe nur zu bewältigen,
wenn es sehr wenige Prozessinstanzen dieses Typs gibt. Ab einer gewissen Anzahl geht
es nur noch mit Systemunterstützung (siehe Abbildung 5 bis 7).
Im Rahmen des ADEPT-Projektes erarbeiten wir deshalb derzeit die formalen Grund-
lagen und Algorithmen, um auch eine sehr große Anzahl von Prozessinstanzen automa-
tisch oder semiautomatisch migrieren zu können. Hierbei betrachten wir auch nicht-
triviale Änderungen am Prozess-Schema, wie Einfügen mehrerer Schritte, Löschen oder
Verschieben von Schritten, jeweils mit und ohne Datenabhängigkeiten zwischen den
Schritten. Außerdem betrachten wir auch Schema-Evolution in Bezug auf Prozessinstan-
zen, die individuell modifiziert wurden, also nicht mehr dem Originalschema entspre-
chen. Die Ergebnisse dieser Forschungsarbeiten sind sehr vielversprechend und zeigen,
dass wir mit dem ADEPT-Ansatz auf dem richtigen Weg sind [ReRD03, RiRD03,
RiRD04].
Process
Templates
Application
Components
Users
Process Designer /
Process Administrator
...
Repository
Anwendungen / Application Server
Process 4
Process 3
Process 2
Process 1
Process 6
Process 5
Process 11
Process 10
Process 9
Prczess 8
Process 7
Process 14
Process 13
Process 12
ADEPT Process Management System
Process Execution Engine
Msg Queuing
Time MgmtAuthorization
Std Client API Web Clnt API
Role Mgmt
Dyn. Change APIModeling API
Admin. API
Recovery Audit Trail ...
ADEPT Process
Composer
Create Process Template
Modify Process Template
Check Process Template
...
Check
InstanceStatus
Check
InstanceStatus
Abb. 5: Anfrage, auf wie viele Prozessinstanzen die Schemaänderung propagiert werden kann
Modi
f
ication
4 Diskussion
In der PMS- bzw. Workflow-Literatur gibt es zahlreiche Veröffentlichungen, die sich
mit einzelnen Aspekten von PMS bzw. WfMS beschäftigen. Beispiele sind Arbeiten zu
Modellierungssprachen (z. B. [Ober96]), zu Ad-hoc-Änderungen (z. B. [MüRa00,
Wesk98]), zu Schemaevolution (z. B. [CaCP98, ElMa97, JoHe98, KrGe99]) oder zu
Skalierbarkeit und verteilter Workflow-Ausführung (u.a. [AMG+95, MWW+98,
Process
Templates
Application
Components
Users
Process Designer /
Process Administrator
...
Repository
Anwendungen / Application Server
Process 4
Process 3
Process 2
Process 1
Process 6
Process 5
Process 11
Process 10
Process 9
Prczess 8
Process 7
Process 14
Process 13
Process 12
ADEPT Process Management System
Process Execution Engine
Msg Queuing
Time MgmtAuthorization
Std Client API Web Clnt API
Role Mgmt
Dyn. Change APIModeling API
Admin. API
Recovery Audit Trail ...
ADEPT Process
Composer
Create Process Template
Modify Process Template
Check Process Template
...
Response
Response
Result :
1.238 instances
can be migrated
117 instances have
proceeded too far
Abb. 6: Das S
y
stem anal
y
siert den Status der Prozessinstanzen dieses T
yp
s
Process
Templates
Application
Components
Users
Process Designer /
Process Administrator
...
Repository
Anwendungen / Application Server
Process 4
Process 3
Process 2
Process 1
Process 6
Process 5
Process 11
Process 10
Process 9
Prczess 8
Process 7
Process 14
Process 13
Process 12
ADEPT Process Management System
Process Execution Engine
Msg Queuing
Time MgmtAuthorization
Std Client API Web Clnt API
Role Mgmt
Dyn. Change APIModeling API
Admin. API
Recovery Audit Trail ...
ADEPT Process
Composer
Create Process Template
Modify Process Template
Check Process Template
...
Propagate
changes!
Propagate
changes!
Abb. 7: Durchführung der Prozess-Schema-Evolution
ShKo97]). Jedoch gibt es kaum Projekte, welche diese Aspekte gemeinsam betrachten,
insbesondere wird deren Zusammenspiel nicht hinreichend gewürdigt. Es ist nicht das
Ziel dieser Arbeiten, ein bezüglich der Kommunikationskosten effizientes PMS zu ent-
wickeln, das funktional mächtig, skalierbar und flexibel ist. Diese Aspekte und ihr Zu-
sammenwirken wurden in ADEPT erstmalig und in ganzheitlicher Weise untersucht
(z. B. [BaRD01, DaRK00]).
WIDE erlaubt dynamische Änderungen eines Prozess-Schemas und deren Propagierung
auf laufende Prozessinstanzen [CaCP98]. Außerdem werden Prozessinstanzen verteilt
gesteuert [CGP+96]. Bei MOKASSIN [GJS+99, JoHe98] und WASA [Wesk98] wird
die verteilte Prozess-Ausführung durch die zugrunde liegende CORBA-Infrastruktur
realisiert. Außerdem sind Änderungen auf Schema- und Instanzebene möglich, wobei
auch Konsistenzfragestellungen betrachtet werden. In INCAs [BaMR96] erfolgt die
Steuerung von Prozessinstanzen auf der Grundlage von Regeln. Die Regelmenge eines
Prozesses kann zur Laufzeit modifiziert werden, um dynamische Änderungen durchzu-
führen. – Bei all diesen Ansätzen wird aber, im Gegensatz zu ADEPT, nicht explizit auf
das Zusammenspiel der erwähnten Aspekte (z. B. dynamische Änderungen und verteilte
Steuerung) eingegangen.
5 Zusammenfassung
PMS der nächsten Generation besitzen das Potenzial, die Entwicklung vorgangsorien-
tierter Anwendungen nachhaltig zu verändern. Faktisch wird durch ihren Einsatz die
Realisierung und der Betrieb prozessorientierter Anwendungssysteme im größeren Stil
überhaupt erst möglich. Dabei sollten, wie im Fall von ADEPT, die einzelnen Pro-
grammbausteine eines Prozesses als isolierte, wiederverwendbare Komponenten imple-
mentiert werden können, deren Eingabeparameter beim Aufruf von der Laufzeitum-
gebung des PMS versorgt werden und die lediglich dafür sorgen müssen, dass nach ihrer
Beendigung korrekte Werte für Ausgabeparameter erzeugt werden. Alle anderen Aufga-
ben der Ablaufsteuerung und -überwachung (inkl. Ausnahme- und Fehlerbehandlungen)
sollen durch das PMS übernommen werden.
PMS mit den skizzierten Eigenschaften bieten die Chance, zu einer gänzlich neuen Art
der Entwicklung verteilter Informationssysteme zu gelangen, bei der Anwendungen
durch die (graphische) Beschreibung von Prozessvorlagen und durch das Einstecken
vorgefertigter Programmbausteine in diese Vorlagen entwickelt werden. Spätere Pro-
zessänderungen und daraus resultierende Anpassungen der Anwendungssysteme können
bei diesem Ansatz relativ einfach durchgeführt werden. Wurde bei der Implementierung
der Programmbausteine sorgfältig vorgegangen, kann z.B. die Reihenfolge der Arbeits-
schritte eines Prozesses geändert oder es können neue Schritte hinzugenommen werden,
ohne dass hiervon die bereits existierenden Programmbausteine betroffen sind. Schließ-
lich können PMS dazu beitragen, funktionsorientierte Anwendungen prozessorientiert zu
integrieren und so eine gemeinsame Basis für die Verwaltung von Arbeitsabläufen zu
schaffen.
Der ADEPT-Prototyp [HRB+00] ist derzeit eines der funktional mächtigsten und flexi-
belsten PMS. Er weist die Implementierbarkeit und das Zusammenspiel der im ADEPT-
Projekt entwickelten Konzepte auf eindrucksvolle Weise nach und zeigt, dass Flexibili-
tät, Robustheit und Effizienz keine Widersprüche sein müssen. Der Prototyp zeigt aber
auch, dass solche High-End-WfMS große Software-Systeme sind, die leicht die Code-
Komplexität eines High-End-DBMS erreichen werden.
PMS werden in Zukunft im Rahmen der Software-Infrastruktur von Unternehmen eine
Schlüsselrolle einnehmen und sich als unverzichtbare, allgemein nutzbare Middleware-
Funktion zur flexiblen Gestaltung und Steuerung von Geschäftsprozessen erweisen.
6 Literatur
[AMG+95] Alonso, G.; Mohan, C.; Günthör, R.; Agrawal, D.; El Abbadi, A.; Kamath, M.:
Exotica/FMQM: A Persistent Message-Based Architecture for Distributed Work-
flow Management. Proc. IFIP Working Conf on Information Systems for Decen-
tralised Organisations, Trondheim, August 1995.
[BaDa00] Bauer, T.; Dadam, P.: Efficient Distributed Workflow Management Based on
Variable Server Assignments. Proc. 12th Conf on Advanced Information Systems
Engineering, Stockholm, Juni 2000, S. 94-109.
[BaRD01] Bauer, T.; Reichert, M.; Dadam, P.: Adaptives und verteiltes Workflow-Manage-
ment. Proc. Datenbanksysteme in Büro, Technik und Wissenschaft (BTW 2001),
Oldenburg, März 2001, S. 47-66
[BaRD03] Bauer, T.; Reichert, M.; Dadam, P.: Intra-Subnet Load Balancing in Distributed
Workflow Management Systems, Int'l Journal Cooperative Information Systems
(IJCIS), 12(3):295-323, September 2003
[BaMR96] Barbará, D.; Mehrotra, S.; Rusinkiewicz, M.: INCAs: Managing Dynamic Work-
flows in Distributed Environment, Journal of Database Mgmt., Vol. 7, No. 1,
1996, S. 5-15
[Baue01] Bauer, T.: Effiziente Realisierung unternehmensweiter Workflow-Management-
Systeme. Dissertation, Universität Ulm, Februar 2001
[CaCP98] Casati, F.; Ceri, S.; Pernici, B.; Pozzi, G.: Workflow Evolution. Data & Knowl-
edge Engineering, Vol. 24, No. 3, Januar 1998, S. 211-238
[CGP+96] Casati, F.; Ceri, S.; Pernici, B.; Pozzi, G.: WIDE: Workflow Model and Architec-
ture. CTIT Technical Report 96-19, Universität Twente, 1996
[DaRe99] Dadam, P.; Reichert, M. (eds.): Proc. Workshop on Enterprise-Wide and Cross-
Enterprise Workflow-Management: Concepts, Systems, Applications, 29.
Jahrestagung der GI (Informatik’99), Paderborn, Oktober 1999.
[DaRK00] Dadam, P.; Reichert, M.; Kuhn, K.: Clinical Workflows - The Killer Application
for Process-oriented Information Systems? Proc. 4th Int’l Conf. on Business In-
formation Systems (BIS‘2000), Posen, April 2000, S. 36–59.
[ElMa97] Ellis, C.; Maltzahn, C.: The Chautauqua Workflow System. Proc. 30th Hawaii
Int’l Conf on System Sciences, Maui, Hawaii, 1997
[GJS+99] Gronemann, B.; Joeris, G.; Scheil, S.; Steinfort, M.; Wache, H.: Supporting Cross-
Organizational Engineering Processes by Distributed Collaborative Workflow
Management – The MOKASSIN Approach. Proc. 2nd Symp on Concurrent Mul-
tidisciplinary Engineering, Bremen, September 1999
[Hein02] Heinlein, C.: Synchronization of Concurrent Workflows Using Interaction Ex-
pressions and Coordination Protocols. Proc. Confederated Int'l Conf. CoopIS,
DOA, and ODBASE 2002, LNCS 2519, 2002, pp. 54-71
[HRB+00] Hensinger, C.; Reichert, M.; Bauer, T.; Strzeletz, T.; Dadam, P.: ADEPTworkflow –
Advanced Workflow Technology for Adaptive, Enterprise-wide Processes. Demo-
Proc of the 7th EDBT Conf., Konstanz, März 2000.
[JaBS97] Jablonski, S.; Böhm, M.; Schulze, W. (Hrsg.): Workflow-Management: Entwick-
lung von Anwendungen und Systemen. Dpunkt, 1997
[JoHe98] Joeris, G.; Herzog, O.: Managing Evolving Workflow Specifications. Proc. 3rd
IFCIS Conf on Cooperative Information Systems, New York, August 1998
[KrGe99] Kradolfer, M.; Geppert, A.: Dynamic Workflow Schema Evolution Based on
Workflow Type Versioning and Workflow Migration. Proc. 4rd IFCIS Int’l Conf
on Cooperative Information Systems, Edinburgh, September 1999.
[LeRo00] Leymann, F.; Roller, D.: Production Workflow – Concepts and Techniques. Pren-
tice Hall, 2000.
[MüRa00] Müller, R.; Rahm, E.: Dealing with Logical Failures for Collaborating Workflows.
Proc. 5th Int’l Conf. Cooperative Inf. Sys., Eilat, September 2000, S. 210-223.
[MWW+98] Muth, P.; Wodtke, D.; Weißenfels, J.; Kotz-Dittrich, A.; Weikum, G.: From Cen-
tralized Workflow Specification to Distributed Workflow Execution. Journal of
Intelligent Inf Systems, Vol. 10, No. 2, März 1998, S. 159-184.
[Ober96] Oberweis, A.: Modellierung und Ausführung von Workflow mit Petri-Netzen.
Teubner Verlag, 1996
[RDMK00] Reichert, M.; Dadam, P.; Mangold, R.; Kreienberg, R.: Computerbasierte Unter-
stützung von Arbeitsabläufen im Krankenhaus – Konzepte, Technologien und
deren Anwendung. Zentralbl Gynakol, Vol. 122, Januar 2000, S. 56–70.
[ReDa98] Reichert, M.; Dadam, P.: ADEPTflex – Supporting Dynamic Changes of Work-
flows Without Losing Control. Journal of Intelligent Information Systems, Special
Issue on Workflow Mgmt Sys, Vol. 10, No. 2, März 1998, S. 93–129
[ReBD03] Reichert, M.; Dadam, P.; Bauer, T.: Dealing With Forward and Backward Jumps
in Workflow Management Systems. Int'l Journal Software and Systems Modeling
(SoSyM), 2(1):37-58, Springer, 2003
[RBFD01] Reichert, M.; Bauer, T.; Fries, T.; Dadam, P.: Realisierung flexibler, unterneh-
mensweiter Workflow-Anwendungen mit ADEPT. Proc. Gemeinsame Arbeits-
konferenz GI, VOI, BITKOM, OCG, TeleTrusT, "Elektronische Geschäftspro-
zesse", Klagenfurt, September 2001, S. 217-228
[Reic00] Reichert, M.: Dynamische Ablaufänderungen in Workflow-Management-Sys-
temen. Dissertation, Universität Ulm, Juli 2000
[ReRD03] M. Reichert, S. Rinderle, P. Dadam: On the Common Support of Workflow Type
and Instance Changes Under Correctness Constraints. Proc. Int’l Conf. Coopera-
tive Information Systems (CoopIS’03), Catania, Italien, November 2003
[RiDa03] Rinderle, S.; Dadam, P.: Schemaevolution in Workflow-Management-Systemen.
("Aktuelles Schlagwort"). Informatik-Spektrum, Band 26, Heft 1, Februar 2003,
S. 17-19
[RiRD03] Rinderle, S.; Reichert, M.; Dadam, P.: Evaluation of Correctness Criteria for
Dynamic Workflow Changes. Proc. BPM 2003, Int'l Conf. on Business Process
Management, Eindhoven, The Netherlands, June 2003, LNCS 2678, pp. 41-57
[RiRD04] Rinderle, S.; Reichert, M.; Dadam, P.: Flexible Support of Team Processes By
Adaptive Workflow Systems. Distributed and Parallel Databases, 2004 (ange-
nommen zur Veröffentlichung)
[ShKo97] Sheth, A.; Kochut, K.: Workflow Applications to Research Agenda: Scalable and
Dynamic Work Coordination and Collaboration Systems. Proc. NATO Advanced
Study Institute on Workflow Management Systems and Interoperability, Istanbul,
August 1997, S. 12-21
[Wesk98] Weske, M.: Flexible Modeling and Execution of Workflow Activities. Proc. 31st
Hawaii Int’l Conference on System Sciences, Software Technology Track, 1998,
S. 713-722