HAUPTBEITRAG / PROZESSMANAGEMENTSYSTEME }
Prozessmanagementsysteme
Nur ein wenig Flexibilität wird nicht reichen
Peter Dadam · Manfred Reichert
Stefanie Rinderle-Ma
Einführung
Die zunehmende Verschärfung des Wettbewerbs
sowie neue Wettbewerbsformen erzeugen für alle
Unternehmen einen starken Druck, sich immer
rascher auf neue Marktsituationen einstellen zu
müssen. So kann es erforderlich werden, dass sie
ihre Produkte und Dienstleistungen in immer kür-
zerer Zeit entwickeln und herstellen, dass sie diese
mit geringeren Kosten realisieren, dass sie neue
Formen der Interaktion mit ihren Kunden entwi-
ckeln oder dass sie ihre Produkte in Kooperation
mit anderen Partnern entwickeln oder herstellen
müssen.
Diese Entwicklungen bedeuten, dass ein Unter-
nehmen in der Lage sein muss, seine betrieblichen
Abläufe, d.h. seine (Geschäfts-)Prozesse, sehr rasch
an neue Gegebenheiten anzupassen, wenn es weiter
im Wettbewerb bestehen will. Dies haben auch die
meisten Unternehmen inzwischen erkannt. Wenn
man den diversen Umfragen und Prognosen Glau-
ben schenken darf, rangiert das Thema Business
Process Management (BPM) [19]inderPrioritä-
tenskala der IT-Verantwortlichen mittlerweile ganz
weit oben. Die bislang in den Unternehmen im
Wesentlichen immer noch überwiegend manuell
und papiergebunden durchgeführten betriebli-
chen Abläufe (Prozesse) werden zunehmend als
fehlerträchtig, kostenintensiv und schwerfällig
hinsichtlich Änderungen angesehen. Wesentliche
Gründe für die Einführung von Prozessmanagement-
systemen sind unserer Erfahrung nach der Wunsch
bzw. die Notwendigkeit nach einer
– ,,aktiven“ Prozessunterstützung, indem den Be-
arbeitern die für sie bestimmten Aufgaben in
deren Arbeitslisten gestellt werden, sobald diese
Aufgaben ausführbar sind (Abb. 1),
– Automatisierung von Teilaufgaben bzw.
Teilprozessen,
– Integration heterogener Anwendungssysteme,
– rascheren Anpassbarkeit der betrieblichen Abläufe
an neue Gegebenheiten und
– besseren Nachvollziehbarkeit einzelner Prozess-
ausführungen, z.B. im Zusammenhang mit der
Erfüllung von Compliance-Vorgaben.
Welche funktionalen Anforderungen ein Prozessma-
nagementsystem (PMS) erfüllen muss, hängt stark
davon ab, welche Art von Anwendungsfunktionen
ausführbar sein sollen. Relativ geringe Anforderun-
gen haben diesbezüglich PMS, die im Wesentlichen
lediglich den Inhalt von Datenbanktabellen anzei-
gen und manipulieren lassen (formularorientierte
PMS) oder die sich auf das Anzeigen und Bearbei-
ten von Dokumenten (dokumentenorientierte PMS)
beschränken. Im Allgemeinen wird man jedoch von
einem PMS erwarten, dass mit den Prozessschrit-
ten beliebige Anwendungsfunktionen verknüpft
werden können. Dies können im Prinzip Dienste
(,,Services“) jeglicher Art sein, also z. B. Formular-
DOI 10.1007/s00287-010-0456-0
© Springer-Verlag 2010
Peter Dadam · Manfred Reichert
Universität Ulm, Institut für Datenbanken
und Informationssysteme (DBIS),
James-Franck-Ring, 89069 Ulm, Deutschland
E-Mail: {peter.dadam, manfred.reichert}@uni-ulm.de
Stefanie Rinderle-Ma
Universität Wien, Fakultät für Informatik,
Workflow Systems and Technology,
Rathausstraße 19/9, 1010 Wien, Österreich
E-Mail: stefanie.rinderle-ma@univie.ac.at
{PROZESSMANAGEMENTSYSTEME
Zusammenfassung
Die heute angebotenen Prozess- und Workflow-
managementsysteme basieren weitgehend auf
der Annahme, dass sich die zu unterstützen-
den Arbeitsabläufe – inklusive Ausnahmen –
komplett vormodellieren lassen. Ein Abwei-
chen vom vorgeplanten Ablauf zur Laufzeit
ist, falls überhaupt vorgesehen, nur unter sehr
starken Einschränkungen möglich. Für Anwen-
dungsumgebungen, die eine rasche und flexible
Reaktion auf nichtvorhergesehene Ausnahmesi-
tuationen und Notfälle erfordern, sind Systeme
dieser Art praktisch jedoch nicht einsetzbar.
Der Beitrag beschreibt, welche grundlegenden
technologischen Eigenschaften ein Prozess-
managementsystem erfüllen muss, um den
Flexibilitätsanforderungen der realen Welt
gerechtzuwerden.
und Dokumentbearbeitungsfunktionen, Daten-
bankaufrufe, Aufrufe von externen Anwendungen,
das Versenden/Empfangen von E-Mails oder
der Aufruf von Webservices zur Abfrage von
Wetterdaten oder Börsenkursen. Wesentlich bei
solch allgemein einsetzbaren PMS ist, dass im
Allgemeinen Dienste gerufen werden, denen
Aufrufparameter übergeben und von denen Resul-
Abb.1 Ausführen von
Prozessen durch ein Pro-
zessmanagementsystem
tatparameter entgegengenommen werden müssen.
Diese Resultatparameter können wiederum Ein-
gabeparameter für nachfolgende Prozessschritte
darstellen, können aber auch Einfluss auf den
sog. Kontrollfluss des Prozesses nehmen, indem
sie Werte für Verzweigungsentscheidungen oder
Schleifenbedingungen liefern.
Zu Beginn einer ,,Elektronifizierung“ der Pro-
zesse eines Unternehmens werden in der Regel
elementare Arbeitsabläufe im Vordergrund stehen,
wie z. B. Posteingangsbearbeitung oder Reisekosten-
abrechnung. Hat sich diese Maßnahme bewährt,
wird jedoch bald der Wunsch aufkommen, auch
anspruchsvollere Prozesse zu unterstützen, wie
z.B. Entwicklungsprozesse für Industrieprodukte,
Prozesse im Rahmen von Bauprojekten oder Be-
handlungsprozesse im Krankenhaus. Bei solchen,
aber auch schon bei weit weniger anspruchsvol-
len Prozessen lassen sich zur Entwurfszeit nicht
mehr alle möglichen Ausnahme- und Sonderfälle
antizipieren und vormodellieren. Eine naive An-
wendung heutiger PMS in diesen Bereichen könnte
deshalb entweder bedeuten, dass man in Sonderfäl-
len bzw. Ausnahmesituationen nicht mehr flexibel
reagieren kann oder aber das Problem unter Um-
gehung des PMS lösen muss. Die erste Alternative
dürfte meist nicht akzeptabel sein und die zweite
wäre unter dem Aspekt der Nachvollziehbarkeit und
Fehlervermeidungebenfalls keine adäquate Lösung.
Abb.2 Arten von
,,Flexibilität“ von
Prozessen
Möchte man eine durchgängige Prozessunter-
stützung realisieren, die von den elementaren
Arbeitsabläufen bis hin zu anspruchsvollen Ent-
scheidungsprozessen reicht, benötigt man PMS,
die erheblich flexibler sind als die derzeit gängi-
gen Systeme. Welche technologischen Fähigkeiten
man hierzu benötigt, und wie eine solche Techno-
logie aussehen könnte, wird in den nachfolgenden
Kapiteln diskutiert und exemplarisch beschrieben.
Arten von Flexibilität
Wie eingangs erwähnt, ist eines der wesentlichen
Motive für die Einführung von PMS die Erhöhung
der Flexibilität des Unternehmens. Deshalb wirbt
praktisch auch jeder PMS-Anbieter damit, dass
dies mit seiner Prozessmanagementtechnologie
erreicht werden kann. Hierbei wird allerdings un-
terschlagen, dass man zwei Arten von Flexibilität in
Bezug auf Prozesse unterscheiden muss – Flexibilität
zur Entwurfszeit und Flexibilität zur Ausführungs-
zeit (Abb. 2) und viele Anwender haben derzeit
auch noch realisiert, dass unzureichende oder gar
überhaupt nicht vorhandene Flexibilität bei der Pro-
zessausführung zu großen Problemen führen kann.
Wir werden beide Arten von Flexibilität nachfol-
gend diskutieren. Ein weiterer Flexibilitätsaspekt
ist die Prozesschemaevolution, auf die wir ebenfalls
eingehen werden.
Flexibilität zur Entwurfszeit
Flexibilität zur Entwurfszeit bedeutet, dass man
rasch neue Prozessmodelle erstellen kann. Moderne
PMS bieten hierfür in der Regel grafische Modellie-
rungswerkzeuge an, mittels derer man die Prozesse
beschreiben und die zur Verfügung stehenden An-
wendungsfunktionen mittels Drag and Drop oder
Kontextmenü in die Prozessmodelle einfügen kann.
Dieser Aspekt ist bei modernen PMS in der Regel
recht gut gelöst, d.h. man kann auf diese Weise
relativ rasch neue Prozesse komponieren.
Ein ganz wesentlicher Aspekt in diesem Zu-
sammenhang ist allerdings, wie rasch man ein
solches Prozessmodell anschließend ,,in Produk-
tion“ bringen kann. Das heißt, wie viel Aufwand ist
erforderlich, um herauszufinden, ob der erstellte
Prozess technisch robust und stabil läuft, d. h. keine
Laufzeitfehler verursachen wird. Diesbezüglichsieht
es bei heutigen PMS schon sehr viel schlechter aus.
Die systemseitige Fehleranalyse des Prozessmodells
ist meist recht schwach ausgeprägt, sodass die Pro-
zessmodellierer nur durch intensives Testen bzw.
Durchspielen aller möglichen Prozessausführun-
gen herausfinden können, ob der Prozess technisch
stabil und robust ausführbar sein wird. Einer der
Gründe für diese oftmals schwache Unterstützung
ist, dass viele Hersteller bei der Realisierung ihres
PMS dachten, dass eine Prozessmodellierungsspra-
che dann besondersgut und praxistauglich ist, wenn
sie viele Modellkonstrukte anbietet und auch in
Bezug auf die Strukturierung des Prozessmodells
möglichst viele Freiheiten zulässt. Zeitweise gab
es sogar einen regelrechten Wettlauf, wer mehr
Ablaufmuster (Workflow-Patterns; siehe [20]) in
seiner Modellierungssprache direkt abbilden kann.
Eine Folge sehr liberaler Prozessmodelle ist je-
doch, dass es oftmals systemseitig nicht möglich
{PROZESSMANAGEMENTSYSTEME
Abb.3 Modellierungsfehler – fehlender
Kontrollkonnektor
Abb.4 Modellierungsfehler – XOR-Split
mit AND-Join abgeschlossen
ist, Modellierungsfehler als solche überhaupt noch
zu erkennen [7,9].
Zur Veranschaulichung betrachten wir zwei ein-
fache Beispiele. Wenn ein PMS erlaubt, dass ein
Prozessmodell mehrere Startknoten haben kann,
würde die Ausführung des in Abb. 3dargestellten
Prozesses parallel mit den Schritten A und C begin-
nen und die beiden abgebildeten Fragmente würden
als quasi voneinander unabhängige Teilprozesse aus-
geführt werden. Dies hat der Prozessmodellierer
aber ggf. nicht beabsichtigt, was zu Inkonsisten-
zen oder Laufzeitfehlern führen kann. In diesem
einfachen Beispiel sieht man einen solchen Model-
lierungsfehler natürlich sofort. In einem großen,
komplexen Prozessmodell mit dutzenden oder gar
hunderten von Prozessschritten hingegen kann die
Suche nach Fehlern dieser Art aber schnell zu einem
Alptraum werden.
In dem in Abb. 4dargestellten Beispiel habe
der Modellierer versehentlich einen XOR-Split (d.h.
eine alternative Verzweigung bei Schritt F) mit ei-
nem AND-Join abgeschlossen. Falls ein PMS eine
solche Konstellation zulässt bzw. nicht als Fehler
erkennt, hängt es von der konkret implementierten
Schaltsemantik im PMS ab, was passiert, wenn die
Ausführung der Prozessinstanz am Knoten J an-
kommt. Vom Laufzeitfehler über Blockierung bis zu
frühzeitiger Terminierung der Prozessinstanz (ohne
Fehlermeldung)ist hier im Prinzip alles denkbar.
Weitere Probleme ergeben sich, wenn die Pro-
zessmodellierungssprache auch Schleifen erlaubt,
es hierfür aber kein spezielles Schleifenkonstrukt
gibt. In diesem Fall kann man einen versehentlich
modellierten Zyklus, der möglicherweise zu einer
Blockierung führt, nicht von einer gewolltenSchleife
unterscheiden.
Leider ist in heutigen PMS die mangelnde Un-
terstützung zur Erkennung oder Vermeidung von
Fehlern der obigen Art nicht der einzige Grund,
warum nach der Modellierung meist ausführli-
ches Debuggen und Testen der Prozesse angesagt
ist. Ebenso kritisch ist, dass die meisten PMS nicht
wissen, welche Datenflüsse zwischen den Anwen-
dungsfunktionen stattfinden (oder aber dieses
Wissen nicht ausnutzen). Das heißt, das PMS weiß
nicht, welche Parameter beim Aufruf versorgt bzw.
welche Eingabedaten vorhanden sein müssen und
welche Rückgabewerte nach dem Aufruf zurück-
kommen (Abb. 5). Dieses Manko hat zur Folge, dass
ein solches PMS zur Modellierungszeit auch nicht
prüfen kann, ob die durch das Prozessmodell (d. h.
den ,,Kontrollfluss“)festgelegten möglichen Aufruf-
reihenfolgen der Anwendungsfunktionen mit den
Datenflüssen zwischen ihnen harmonieren. Wenn
diese beiden Aspekte in Widerspruch zueinander
stehen, werden möglicherweise Anwendungsfunk-
tionen aufgerufen, deren Eingabedaten nicht zur
Verfügung stehen. Dies kann zu einem Laufzeitfeh-
ler dieser Anwendungsfunktion, etwa in Form eines
Programmabsturzes, führen.
Flexibilität zur Ausführungszeit
Flexibilität zur Ausführungszeit bedeutet, dass man
auf Prozessinstanzebene (z. B. bei der Bearbeitung
der Kreditanfrage eines bestimmten Kunden oder
der Behandlung eines bestimmten Patienten) vom
Abb.5 Datenflüsse
zwischen
Anwendungsfunktionen
vorgeplanten Ablauf abweichen kann, also das Pro-
zessmodell dieser Instanz durch Einfügen, Ändern,
Löschen oder Verschieben von Prozessschritten in-
dividuell verändern kann. Das denkbare Spektrum
an Änderungen reicht hierbei von minimalen Ein-
griffen bis zur völligen Umgestaltung des weiteren
Ablaufs der Prozessinstanz. Auf den ersten Blick ist
die Vorstellung, dass man vom geplanten Prozessab-
lauf individuell (und womöglich sogar noch massiv)
abweichen kann, vielleicht erschreckend.Man führt
invielenFälleneinPMSjagenauausdemGrundeein,
weil die Mitarbeiter sich nicht strikt genug and den
vorgesehenenAblauf halten. Dass ein PMS evtl. die
technischenMöglichkeiten bietet, vom vorgeplanten
Prozessablauf abzuweichen, bedeutet jedoch noch
lange nicht, dass dies nun jedermann tun kann. Das
heißt, ob und wer von dieser Möglichkeit ggf. Ge-
brauch machendarf, muss natürlich durchgeeignete
Autorisierungskonzepte festgelegt werden [17].
Bietet ein PMS keinerlei Flexibilität zur Aus-
führungszeit an, dann bedeutet dies, dass man
entweder, egal was passiert, stur am vorgegebenen
Prozessablauf festhalten muss (was in der Realität
oftmals überhaupt nicht möglich ist) oder dass man
das Problem unter Umgehung oder durch ,,Austrick-
sen“ des PMS lösen muss, etwa durch Eingriffe in
dessen ,,Innereien“ mit manuellem Ändern von Pro-
zesszustandsdaten. Wenn man sich nur einmal vor
Augen hält, was einen selbst bei den einfachen Din-
gen im täglichen und geschäftlichen Leben bereits
gezwungen hat, vom geplanten Ablauf abzuweichen,
dann wird einem rasch klar, dass sich eigentlich
nicht die Frage stellt, wo man eventuell Flexibilität
benötigt, sondern vielmehr, wo man diese Notwen-
digkeit von vornherein mit Sicherheit ausschließen
kann. Man kann eben nicht alle Eventualitäten des
Lebens vorplanen. Das heißt, man muss in der gege-
benen Situation einen Weg finden, um das Problem
zu lösen bzw. die zu erledigende Aufgabe dennoch
zu bewältigen.
Darüber hinaus gibt es natürlich sehr viele
Anwendungen, bei denen der Bedarf nach Flexi-
bilität zur Laufzeit offensichtlich ist. Beispielhaft
seien hier industrielle Entwicklungsprozesse von
komplexen Produkten, wie etwa einem Fahrzeug
oder einem Flugzeug, genannt, bei denen oftmals
hunderte oder sogar tausende von Komponenten
auf einander abgestimmt entwickelt und getes-
tet werden müssen. Wenn sich hier während des
Entwicklungsprozesses herausstellt, dass es Inter-
ferenzen zwischen Komponenten gibt, dann muss
man sehr gezielt und problemspezifisch vorgehen,
um die Ursachen zu lokalisieren, die notwendi-
gen Änderungen anzuwenden und anschließend
alle damit in Zusammenhang stehende Tests noch-
mals gezielt durchführen [10,16]. Oder nehmen wir
Behandlungsprozesse im Krankenhaus. Da jeder Pa-
tient anders ist, kann jegliche Art von vorgeplantem
Ablauf stets nur ein Vorschlag sein, der von den be-
handelnden Ärzten immer daraufhin zu überprüfen
ist, ob dieser im konkreten Einzelfall anwendbar
bzw. angemessen ist. Wenn sich während der The-
rapie z. B. herausstellt, dass eine andere Erkrankung
als die ursprünglich diagnostizierte vorliegt, muss
möglicherweise der Behandlungsprozess ab diesem
Zeitpunkt komplett geändert werden. Kein Prozess-
modellierer kann den Ärzten diese Entscheidung
und Verantwortung abnehmen [2,8]. Bei beiden
Beispielen ist es auch wichtig, im Einzelfall später
einmal nachvollziehen zu können, wie der konkrete
Ablauf seinerzeit war.
Der Vorrat an Beispielen aus verschiedensten
Anwendungsdomänen, in denen eine systemsei-
tige Prozessunterstützung wünschenswert ist, aber
{PROZESSMANAGEMENTSYSTEME
starre Prozesse nicht in Frage kommen, ist prak-
tisch unerschöpflich. Entsprechend groß ist das
Anwendungspotenzial für PMS, die Flexibilität zur
Ausführungszeit in geeigneter Weise unterstützen
können. Ein PMS, welches in ausreichendem Maße
Flexibilität zur Laufzeit anbieten kann, eröffnet dar-
über hinaus eine Fülle neuer Einsatzmöglichkeiten,
die wir hier aus Platzgründen nur anreißen können:
– Verwaltung von Sonderfällen und vorgenomme-
nen Anpassungen in einer Wissensbasis. Das Pro-
zessmodell repräsentiert dann nur noch den
Normalfall; dynamische Änderungen der Pro-
zessinstanz können bei Bedarf, ggf. unter Wieder-
verwendung einer früher getroffenen Entschei-
dung aus der Wissensbasis, flexibel vorgenommen
werden [18].
– Sehr viel rascheres Einsetzen von Prozessen, da
man eventuell bestehende Schwächen im Prozess-
modell auch noch im laufenden Betrieb durch
Änderung der Prozessinstanz ,,ausbügeln“ kann.
– Inkrementelle Fortschreibung von Prozessen:
Diese ist für lange laufende Prozesse (z.B. bei
lang laufenden Bauvorhaben) interessant, bei
denen man die späteren Phasen noch nicht im
letzten Detail festlegen will. Mittels Änderung auf
Prozessinstanzebene kann man solche Prozesse
nach und nach fortschreiben.
– Individuelle Prozesse: Im Prinzip kann man eine
Prozessinstanz beim Start auch mit einem ,,pri-
vaten“ individuellen Prozessmodell ausstatten,
das spezifisch für den konkreten Einzelfall (z.B.
von einem Entscheidungsunterstützungssystem)
generiert wurde [1].
Wie sieht es nun bezüglich Flexibilität zur Ausfüh-
rungszeit bei den derzeit angebotenen PMS aus?
Hier muss man leider feststellen, dass die Hersteller
von allgemein einsetzbaren PMS die Anforderung
nach Flexibilität zur Ausführungszeit bis vor kur-
zem praktisch völlig ignoriert haben. Erst seit relativ
kurzer Zeit bieten einige PMS die Möglichkeit, zu-
mindest einfache Ad-hoc-Abweichungen, wie etwa
das Ersetzen eines Prozessschrittes durch einen
anderen Prozessschritt mit kompatibler Schnitt-
stelle (im Sinne von ,,late binding“) oder aber das
einfache Einfügen eines Prozessschrittes an der ak-
tuellen Position, durchführen zu können. Da viele
PMS, wie bereits erwähnt, die zwischen den An-
wendungsfunktionen stattfindenden Datenflüsse
nicht kennen, können aber selbst diese einfachen
Maßnahmen kritisch für die Robustheit der weiteren
Prozessausführung sein, sodass solche Änderun-
gen auf Prozessinstanzebene eigentlich nur von
Prozessspezialisten vorgenommen werden können.
Größere bzw. komplexere Änderungen beherrschen
die gängigen PMS derzeit bei weitem nicht.
Prozessschemaevolution
Prozessmodelle sind ihrer Natur nach immer wie-
der Änderungen unterworfen, sei es, dass ein
Unternehmen intern umstrukturiert wird, dass
Aufgaben ausgelagert oder ins Unternehmen ge-
holt werden, dass das alte Prozessmodell Schwächen
aufweist oder dass geändertegesetzlicheoder andere
Rahmenbedingungen eine Prozessänderung erfor-
derlich machen. Wird von einem Prozessmodell A
(auch Prozessschema genannt) eine neue Version A’
abgeleitet, so folgen alle auf Basis von A gestarteten
Prozessinstanzen erst einmal weiterhin dem in A
hinterlegten Prozessmodell. Gibt es jedoch schwer-
wiegende Probleme mit dem bisherigen Prozess
oder muss man ab einem gewissen Stichtag neue
Vorgaben erfüllen,dann mussman dieauf demalten
Prozessschema bereits gestarteten Prozessinstanzen
irgendwie auf die neue Verfahrensweise umstellen.
Verfügt das PMS über die Fähigkeit zur Abwei-
chung auf Prozessinstanzebene, könnte man im
Prinzip dieses Mittel einsetzen, um das neue Ver-
halten zu erzielen. Sind jedoch bereits sehr viele
Prozessinstanzen dieses Typs unterwegs, ist diese
Vorgehensweise meist zu aufwendig und fehler-
trächtig. Sehr viel eleganter ist in einem solchen Fall
die Prozessschemaevolution. Hierunter versteht man
die Fähigkeit eines PMS, Prozessinstanzen auf ein
geändertes Schemabzw. Prozessmodell migrieren zu
können. Als Minimalforderung wird man erwarten,
dass dies zumindest für die unveränderten Prozess-
instanzen angeboten wird, aber natürlich sollte es
diese Möglichkeit auch für individuell geänderte
Prozessinstanzen geben. Natürlich kann man nicht
jede Prozessinstanz so einfach auf das neue Schema
,,umhängen“. So ergibt es z.B. keinen Sinn (und
kann sogar in der Folge zu Laufzeitfehlern führen),
Prozessinstanzen zu migrieren, die im Ablauf bereits
zu weit fortgeschritten sind oder bei denen die Sche-
maänderung mit individuellen Instanzänderungen
in Konflikt steht [14].
Die kommerziellen Hersteller von PMS haben
mittlerweile erkannt, dass sie hier etwas anbie-
ten müssen, und so sieht man inzwischen einige
Systeme, die diese Fähigkeit aufweisen. In Anbe-
tracht der Tatsache, dass die wenigstenHersteller bei
eventuellen Korrektheitsanalysen die Datenflüsse
mit einbeziehen, sollte der Prozessmodellierer bzw.
-verantwortliche jedoch sehr genau prüfen, ob alle
vom PMS ggf. zur Migration angebotenen Instanzen
auch tatsächlich ohne Konsistenzprobleme migrier-
bar sind. Andernfalls drohen Inkonsistenzen oder
Laufzeitfehler. Nachdem von den gängigen PMS,
wenn überhaupt, nur rudimentäre Unterstützung
von Abweichungen auf Prozessinstanzebene ange-
boten werden, wird die Menge der PMS, welche eine
Migration von individuell geänderten Prozessin-
stanzen unterstützen, derzeit sehr klein (wenn nicht
sogar leer) sein.
Durchgängige Prozessflexibilität
am Beispiel von ADEPT
ImFolgendensollamBeispieldervonunsentwickel-
tenADEPT-Technologiebzw.derdaraufbasierenden
AristaFlow®BPM Suite [21] gezeigt werden, dass
man PMS (und darauf aufbauend prozessorien-
tierte Informationssysteme) realisieren kann, welche
die obigen Anforderungen an Flexibilität sowohl
zur Entwurfs- als auch zur Ausführungszeit be-
reits weitgehend erfüllen können. Auslöser dieser
Forschungsarbeiten war ein umfangreiches For-
schungsprojekt im klinischen Bereich, das von 1992
bis 1994 in Zusammenarbeit mit verschiedenenPart-
nern des Universitätsklinikums Ulm durchgeführt
wurde und das die Erarbeitung von Konzepten für
klinische Informationssysteme der nächsten Ge-
neration zum Gegenstand hatte [5,6]. In diesem
Zusammenhang haben wir uns u. a. sehr intensiv mit
medizinisch-organisatorischen Abläufen und de-
ren Anforderungen befasst. Dabei wurde mehr und
mehr klar, dass die Einführung prozessorientierter
klinischer Informationssysteme für das Klinikper-
sonal einen wirklich großen Fortschritt mit sich
bringen würde.
Allerdings war auch klar, dass man eine Reihe
konfliktärer Ziele unter einen Hut bringen muss.
So sollte z. B. das Prozessmodell ausdrucksstark
genug sein, um alle im klinischen Umfeld auftre-
tenden Prozessstrukturen geeignet modellieren zu
können. Das heißt, es müssen nicht nur alternative
Pfade, sondern auch Parallelpfade und zyklische
Ausführungen abgebildet werden können. Au-
ßerdem kann man sich nicht auf formular- oder
dokumentenorientierte Prozesse beschränken, son-
dern es müssen Anwendungssysteme bzw. -dienste
jeglicher Art integrierbar sein, etwa zur Ansteue-
rung von Laborautomaten oder für den Zugriff auf
Terminplanungssysteme. Des Weiteren müssen in
der klinischen Anwendungsdomäne neue Prozesse
rasch einführbar und bestehende Prozesse rasch
änderbar sein. Dies wiederum bedeutet, dass die
Komplexität für die Anwendungsentwickler nicht si-
gnifikant ansteigen darf; und dies gelingt nur, wenn
Modellierungsfehler der vorangehend beschriebe-
nen Art weitgehend systemseitig erkannt oder –
noch besser – von vornherein ausgeschlossen wer-
den. Außerdem, und das war mit die größte sich
uns stellende Herausforderung, können Prozesse in
dieser Domäne nicht starr sein. Flexibilität zur Aus-
führungszeit ist hier ein absolutes Muss! Allerdings
nützt Flexibilität zur Ausführungszeit nichts, wenn
diese in der Handhabung ,,vor Ort“ so kompliziert
ist, dass man hierfür stets einen Prozessspezialisten
benötigt. Das heißt, eine ganz wesentliche Her-
ausforderung war, die ganze damit einhergehende
Komplexität vor den Anwendern, aber letztlich auch
vor den Prozessmodellierern und Entwicklern von
Anwendungsfunktionen, unter der Systemober-
fläche zu verstecken und ,,nach oben“ einfach zu
bedienende Schnittstellen anzubieten. Ausführli-
chere Darstellungen der Entwicklungsgeschichte
des ADEPT-Projekts sowie der technologischen
Lösungen finden sich in [4], auf den Seiten des
AristaFlow-Forums [22] sowie den Webseiten des
Instituts für Datenbanken und Informationssysteme
der Universität Ulm [23].
Prozessmodellierung mittels
,,Correctness by Construction“
Ein wesentliches Anliegen beim Entwurf des
ADEPT-Prozess-Meta-Modells (Abb. 6) war, dass es
ausdrucksstark genug sein sollte, um alle wichtigen
Prozessstrukturen geeignet abbilden zu können. Als
,,Messlatte“ dienten zahlreiche Prozessbeispiele aus
einem weiteren Forschungsprojekt [11]. Das Prozess-
Meta-Modell sollte aber auch eingeschränkt genug
sein, um möglichst viele Modellierungsfehler durch
formale Analysen erkennen zu können bzw. sie von
vornherein auszuschließen. Das unter diesen Rand-
bedingungen entwickelte Prozess-Meta-Modell ist
trotz seiner Blockstruktur aufgrund verschiedener
Erweiterungen sehr ausdrucksstark, hat eine solide
formale Basis und erlaubt effiziente Überprüfungen
{PROZESSMANAGEMENTSYSTEME
Abb.6 ADEPT Prozess-Meta-Modell
Abb.7 AristaFlow Process
Template Editor
der erstellten Prozessmodelle auf Korrektheit. Im
Kontext von Ad-hoc-Abweichungen (s. u.) ermög-
licht es darüber hinaus, sehr rasch zu entscheiden,
ob und – falls ja – wie eine gewünschte Änderung
realisiert werden kann [3,12,13].
Im Gegensatz zur gängigen Praxis, das Prozess-
modell erst einmal relativ freihändig komponieren
zu lassen und es dann anschließend auf Fehler zu
analysieren, wird der Prozessmodellierer in ADEPT
bzw. AristaFlow von Anfang an so geführt, dass
viele Modellierungsfehler ,,per Konstruktion“ erst
gar nicht gemacht werden können. Wenn man
z.B. ein neues Prozessmodell erstellt, startet der
AristaFlow Process Template Editor mit einem in-
Abb.8 Markierungen im Prozessmodell und freigeschaltete Operationen
Abb. 9 Erkennung eines inkonsistenten Datenflusses
itialen Prozessmodell, das nur aus einem Start-
und einem End-Knoten besteht und welches das
kleinstmögliche, strukturell konsistenteste Prozess-
modell darstellt (Abb. 7). Im Teilfenster ,,Change
Operations“ werden jeweils die Operationen an-
gezeigt und freigeschaltet, die auf das angezeigte
Prozessmodell und die dort ggf. getroffene Auswahl
anwendbar sind. Da im angezeigten Prozessmo-
dell nichts ausgewählt bzw. markiert wurde, sind
rechts keine Operationen wählbar (mit Ausnahme
von ,,Insert Data Element“ das in der Liste weiter
unten kommt und deshalb in Abb. 7nicht angezeigt
wird).
Mittels Preselection (= grün bzw. hellgrau in
einem Graustufenausdruck) und Postselection
(= blau bzw. dunkelgrau in einem Graustufenaus-
druck) kann ein Bereich im Prozessmodell markiert
werden, woraufhin die dann wählbaren Opera-
tionen freigeschaltet werden. Abbildung 8zeigt
exemplarisch das Zusammenspiel zwischen Mar-
kierungen im Prozessmodell und Freischaltung
von Änderungsoperationen. Alle freigeschalte-
{PROZESSMANAGEMENTSYSTEME
Abb.10 Durchführung einer Ad-hoc-Änderung durch Endbenutzer
ten Operationen sind in ihrer Wirkung auf das
Prozessmodell eindeutig bestimmt und überfüh-
ren es aus einem strukturell konsistenten Zustand
in einen neuen strukturell konsistenten Zustand.
Andere Inkonsistenzen, die nicht schon auf diese
Weise ,,per Konstruktion“ vermieden werden kön-
nen, wie etwa unversorgte Aufrufparameter von
Prozessschritten (bzw. den diesen Schritten zuge-
ordneten Anwendungsfunktionen), werden durch
nebenläufige Analysen erkannt und im ,,Problems“-
Fenster anzeigt. In dem in Abb. 9dargestellten
Prozess wird z. B. das Datenelement ,,AuftragsId“
vom Schritt ,,Auftrag bearbeiten“ gelesen, d. h.
der Inhalt dieses Datenelements wird von diesem
Prozessschritt zur Ausführungszeit als ,,Input“ be-
nötigt. Im dargestellten Prozessmodell wird dieses
Datenelement jedoch nurimoberenZweigder
XOR-Verzweigung ,,versorgt“. Dieser Fehler im
Datenfluss wird sofort erkannt und durch Markie-
rung der betroffenen Elemente sowie als Text im
,,Problems“-Fenster (siehe unteres Teilfenster in
Abb. 10) angezeigt.
ADEPT wurde dafür konzipiert, dass sich
Anwendungsfunktionen verschiedenster Art
integrieren lassen. Dazu werden diese dem Pro-
zessmodellierer in homogener Weise angeboten,
d. h. von internen Implementierungs- und Aufruf-
details wird abstrahiert. Nach Registrierung einer
Anwendungsfunktion im sog. Activity Repository
steht diese im Process Template Editor zur Verfügung
undkanndanneinfachausdementsprechenden
Teilfenster mittels Drag and Drop auf einen Knoten
oder eine Kante im Prozessmodell gezogen wer-
den. In diesem Zusammenhang prüft das System,
ob für die Anbindung eventueller Ein- und Ausga-
beparameter dieser Anwendungsfunktion bereits
typgerechte Datenelemente im Prozessmodell vor-
liegen und bietet diese ggf. zur Verknüpfung an.
Hierbei wird der resultierende Datenfluss wieder auf
Korrektheit geprüft. Die oben skizzierte Führung
der Anwender bei der Modellierung, in Verbindung
mit umfassenden Datenflussanalysen sowie weite-
ren nebenläufig durchgeführten Überprüfungen,
bezeichnen wir als ,,Correctness by Construction“.
Sie hilft die Entwicklungs- und Testzeit für Prozesse
signifikant zu reduzieren.
Ad-hoc-Abweichungen zur
Ausführungszeit
In Bezug auf die Unterstützung von Ad-hoc-Ände-
rungen bestanden mehrere Herausforderungen.
Erstens war das volle Spektrum an Änderungsope-
rationen anzubieten, zweitens sollten dabei keine
Abstriche in Bezug auf Konsistenzüberprüfungen
gemacht werden und drittens waren die Schnitt-
stellen so zu gestalten, dass – zumindest in einfach
gelagerten Fällen – Endbenutzer mit entsprechen-
der Autorisierung die Ad-hoc-Änderungen auf
Prozessinstanzebene selbstständig durchführen
können. Unser Lösungsansatz ist es, semantisch
hohe Schnittstellen für Ad-hoc-Änderungen zu
realisieren und die damit inhärent verbundene
Komplexität unter der Systemoberfläche zu verste-
cken. Die auf Systemebene zu bedienende (Service-)
Schnittstelle benötigt z. B. für das Einfügen eines
Prozessschrittes im Wesentlichen nur die folgenden
Informationen:
1. Um welche Anwendungsfunktion handelt es sich?
2. Nach welchem Prozessschritt soll der neue
Prozessschritt zur Ausführung angeboten
werden?
3. Vor welchem Prozessschritt soll der einzufügende
Schritt abgeschlossen sein?
Abbildung 9illustriert, wie man auf Basis dieser
Systemschnittstelle die Interaktion mit dem An-
wender realisieren könnte. In diesem Beispiel soll
ein Oberarzt die Entscheidung eines Ambulanzarz-
tes hinsichtlich eines operativen Eingriffs absegnen
bzw. ablehnen. Im konkreten Fall möchte er jedoch
selbst noch eine Laboruntersuchung veranlassen,
was an sich im Prozessmodell nicht vorgesehen ist.
Da er zu den autorisierten Personen gehört, die in
eingeschränktem Umfang Ad-hoc-Abweichungen
vornehmen dürfen, kann er via ,,Ausnahmeknopf“
und den dort angebotenen Operationen gewisse Än-
derungen an der Prozessinstanz vornehmen. Die
vorgenommenenÄnderungen werdenim Prozesslog
protokolliert und können deshalb später jederzeit im
Detail nachvollzogen werden. Dem Prozessspezialis-
ten steht natürlich eine mächtigere Schnittstelle zur
Durchführung von Ad-hoc-Änderungen zur Verfü-
gung. Diese bietet praktisch die volle funktionale
Mächtigkeit des Process Template Editors, wiederum
unter (hier erweiterter) Beachtung des ,,Correctness
by Construction“-Prinzips.
Prozessschemaevolution
Im ADEPT-Projekt wurden grundlegende und um-
fassende Konzepte für Prozessschemaevolutionent-
wickelt. Diese ermöglichen nicht nur die Migration
unveränderter,sondernauchindividuell veränderter
Prozessinstanzen. Bei der systemseitigen Überprü-
fung wird nicht nur berücksichtigt, ob die jeweils
betrachtete Prozessinstanz in ihrem Ausführungs-
zustand zu weit fortgeschritten ist, sondern es wird
auch geprüft, ob eventuell vorgenommene indivi-
duelle (Ad-hoc-)Änderungen mit den Änderungen
auf Schemaebene harmonieren bzw. in Konflikt ste-
hen [15].DesWeiterenwerdenhierwiederdiebereits
erwähnten Konsistenzregeln beachtet. Leider kön-
nen wir aus Platzgründen nicht im Detail auf dieses
{PROZESSMANAGEMENTSYSTEME
Abb.11 Prozessschemaevolution
mächtige (und weltweit in dieser Form bislang ein-
malige) Feature der ADEPT-Technologie eingehen.
Stattdessen begnügen wir uns mit einer Illustration
(Abb. 11), die zeigen soll, wie man sich den Ablauf
einerProzessschemaevolutionvorzustellenhat.
Der Prozessmodellierer lädt das zu modifi-
zierende Prozessmodell bzw. -schema, führt die
gewünschten Änderungen durch und speichert
eine neue Version dieses Prozessmodells (Abb. 11a).
Anschließend kann er das ADEPT-System prüfen
lassen, welchederaufdemaltenSchemabasierenden
Prozessinstanzen auf das neue Schema migrierbar
sind (Abb. 11b). Er erhält eine (in Abb. 11cstark
vereinfacht dargestellte) Liste dieser Instanzen mit
näheren Angaben, warum eine Instanz systemsei-
tig als migrierbar oder nicht migrierbar eingestuft
wurde. Aus der Liste der als migrierbar eingestuften
InstanzenkannerüberFilterbei BedarfnochInstan-
zen abwählen, d. h. von der Migration ausschließen.
Anschließend beauftragt er das System, die verblie-
benen Instanzen auf das neue Schema zu migrieren
(Abb. 11d). Wird zu einem späteren Zeitpunkt eine
weitere Version von diesem Prozessmodell abge-
leitet, wären alle noch laufenden Instanzen dieses
Schemas (also auch die zuvor erst auf dieses Schema
migrierten) wieder Kandidaten für eine sich evtl.
erneut anschließende Prozessschemaevolution.
Fazit
Die Unterstützung betrieblicher Abläufe durch
ein PMS bietet vielfältige Vorteile, etwa im Hin-
blick auf die aktive Koordination der Prozesse
(z.B. Reduzierung von Leerlaufzeiten und falschen
Bearbeitungsreihenfolgen), die Möglichkeit der
(Teil-)Automatisierung der Prozesse oder die ver-
besserte Einhaltung von Compliance-Vorgaben
einschließlich entsprechender Nachweise. Die bis-
lang in den Unternehmen überwiegend manuell
ausgeführten Prozesse haben viele Schwächen und
Nachteile, besitzen aber auch eine große Stärke:
In Ausnahmesituationen kann man sehr flexi-
bel reagieren und zur Not auch einmal komplett
vom vorgeplanten Ablauf abweichen. Die gängi-
gen PMS besitzen diese Eigenschaft nicht bzw. nur
in sehr eingeschränktem Maße. Damit sind ihre
Einsatzmöglichkeiten stark eingeschränkt.
Am Beispiel der ADEPT- bzw. AristaFlow-
Technologie haben wir gezeigt, dass man techno-
logisch durchaus in der Lage ist, PMS zu entwi-
ckeln, die um Größenordnungen flexibler sind als
die bisherigen Systeme und diesen eigentlich in al-
len die Flexibilität betreffenden Belangen – d. h. der
Flexibilität zur Entwurfszeit, der Flexibilität zur Aus-
führungszeit sowie der Prozessschemaevolution –
haushoch überlegen sind. Voraussetzung hierfür ist,
dass man sich bei der Entwicklung von PMS darauf
zurückbesinnt, was die wirklich fundamentalen An-
forderungen an diese Systeme sind und hierfür die
geeigneten technologischen Konzepte entwickelt. Es
ist unschwer vorauszusagen, dass den PMS nur dann
ein ähnlicher Siegeszug wie den relationalen Daten-
banksystemen beschert sein wird, wenn es gelingt,
sie ebenfalls auf eine sehr viel mächtigere Techno-
logiebasis zu stellen, die es zudem ermöglicht, die
komplizierten Dinge weitgehend ,,unter der Ober-
fläche“ zu erledigen und ,,nach oben“ einfach zu
bedienende Schnittstellen anzubieten. Gelingt dies
nicht, werden PMS eine Nischentechnologie mit eng
begrenztem Einsatzbereich bleiben.
Literatur
1. Bassil S, Benyoucef M, Keller RK, Kropf P (2002) Addressing Dynamism in E-ne-
gotiations by Workflow Management Systems. Proc Int Workshops on Database
and Expert Systems Applications, DEXA’2002, Third Int Workshop on Negotiations
in e-Markets – Beyond Price Discovery, September 2002, Aix-en-Provence, France
2. Dadam P, Reichert M, Kuhn K (2000) Clinical Workflows – The Killer Application
for Process-oriented Information Systems? Proc Int Conf on Business Information
Systems, BIS 2000, 4th Int Conf., April 2000, Poznan, Poland, Springer, pp 36–59
3. Dadam P, Reichert M (2009) The ADEPT Project: A Decade of Research and Deve-
lopment for Robust and Flexible Process Support. Comput Sci Res Dev 23(2):81–
98
4. Dadam P, Reichert M, Rinderle-Ma S, Göser K, Kreher U, Jurisch M (2009) Von
ADEPT zur AristaFlow BPM Suite – Eine Vision wird Realität: ,,Correctness by Con-
struction“ und flexible, robuste Ausführung von Unternehmensprozessen. EMISA
FORUM 1:9–28
5. Kuhn K, Reichert M, Nathe M, Beuter T, Dadam P (1994) An Infrastructure for Co-
operation and Communication in an Advanced Clinical Information System. Proc.
18th Ann Sym on Computer Applications in Medical Care 1994, SCAMC ’94, Wa-
shington, pp 519–523
6. Kuhn K, Reichert M, Nathe M, Beuter T, Heinlein C, Dadam P (1994) A Concep-
tual Approach to an Open Hospital Information System. Proc 12th Int Congress
on Medical Informatics, MIE ’94, May 1994, Lissabon, pp 374–378
7. Laue R, Mendling J (2008) The Impact of Structuredness on Error Probability of
Process Models. Proc. 2nd Int United Information Systems Conf, UNISCON 2008,
April 2008, Klagenfurt, Österreich, LNBIP 5, pp 585–590
8. Lenz R, Reichert M (2007) IT Support for Healthcare Processes – Premises, Chal-
lenges, Perspectives. Data Knowl Eng 61(1):39–58
9. Mendling J (2009) Empirical Studies in Process Model Verification. Transactions
on Petri Nets and Other Models of Concurrency II. Special Issue on Concurrency
in Process-Aware Information Systems, LNCS 5460, pp 208–224
10. Müller D, Reichert M, Herbst J (2007) Data-driven Modeling and Coordination of
Large Process Structures. Proc. Int Conf on Cooperative Information Systems,
CoopIS, November 2007, Vilamoura, Algarve, Portugal, LNCS 4803, pp 131–149
11. Reichert M, Dadam P, Mangold R, Kreienberg R (2000) Computerbasierte Unter-
stützung von Arbeitsabläufen im Krankenhaus – Konzepte, Technologien und de-
ren Anwendung. Zentralbl Gynäkol 1:53–67
12. Reichert M, Dadam P (1998) ADEPTflex – Supporting Dynamic Changes of Work-
flows Without Losing Control. J Intell Inf Syst 10(2):93–129
13. Reichert M (2000) Dynamische Ablaufänderungen in Workflow-Management-
Systemen. Dissertation, Universität Ulm, Fakultät für Informatik
14. Rinderle S, Reichert M, Dadam P (2004) Correctness Criteria for Dynamic Changes
in Workflow Systems – a Survey. Data Knowl Eng 50(1):9–34
15. Rinderle SB (2004) Schema Evolution in Process Management Systems. Disserta-
tion, Universität Ulm, Fakultät für Informatik
16. Vanderfeesten I, Reijers HA, Aalst WMP (2008) Product Based Workflow Support:
Dynamic Workflow Execution. Proc Int Conf on Advanced Information Systems
Engineering, CAiSE 2008, Juni 2008, Montpellier, France, LNCS 5074, pp 571–
574
17. Weber B, Reichert M, Wild W, Rinderle S (2005) Balancing Flexibility and Security
in Adaptive Process Management Systems. Proc. 13th Int Conf on Cooperative In-
formation Systems (CooplS ’05), Agia Napa, Cyprus, LNCS 3760, pp 59–76
18. Weber B, Reichert M, Rinderle-Ma S, Wild W (2009) Providing Integrated Life Cy-
cle Support in Process-Aware Information Systems. Int J Coop Inf Sys 18(1):115–
165
19. Weske M (2007) Business Process Management. Springer, Berlin
20. http://www.workflowpatterns.com/patterns/control/, letzter Zugriff 30.6.2010
21. www.AristaFlow.com, letzter Zugriff 30.6.2010
22. www.AristaFlow-Forum.de, letzter Zugriff 30.6.2010
23. www.uni-ulm.de/dbis, letzter Zugriff 30.6.2010
