Unterstützung von Frontloading und Look-ahead bei der
Entwicklung prozessorientierter Informationssysteme
in Service-orientierten Architekturen
Thomas Bauer 1, Stephan Buchwald 2
1 Hochschule Neu-Ulm, Fakultät Informationsmanagement
thomas.bauer@hs-neu-ulm.de
2 T-Systems International GmbH, Delivery Unit Automotive & Manufacturing Industries
stephan.buchwald@t-systems.com
Zusammenfassung. Die in einer Service-orientierten Architektur (SOA) im-
plementierten Geschäftsprozesse sollten durch die Fachbereiche und nicht –
wie in der Praxis oftmals der Fall – durch den IT-Bereich definiert werden.
Nur dann ist gewährleistet, dass das prozessorientiere Informationssystem
tatsächlich den gewünschten Geschäftsnutzen realisiert. Ausführungsrelevan-
te Prozessaspekte (z.B. Bearbeiterzuordnungen) sollten daher früh, d.h. be-
reits beim fachlichen Prozessentwurf, festgelegt werden (Frontloading). Au-
ßerdem sollten in dieser Phase die später bei der Prozessausführung zu ver-
wendenden und bereits existierenden IT-Artefakte (z.B. Services) angegeben
werden können (Look-ahead). Für die Festlegung solcher technischen Aspek-
te bieten existierende Geschäftsprozessmodellierungswerkzeuge jedoch nur
wenig Unterstützung. Die Herausforderung besteht darin, dass entsprechende
Ansätze für Fachanwender mit geringen IT-Kenntnissen nutzbar sein sollten,
die erzeugten Informationen aber technisch eindeutig und vollständig sein
müssen, damit sie für die spätere IT-Implementierung der Geschäftsprozesse
genutzt werden können. Nur dann lassen sich zusätzliche Interviews in den
Fachabteilungen oder Fehlinterpretationen bei der Prozessimplementierung
vermeiden. Dieser Beitrag analysiert, für welche Prozessaspekte ein Front-
loading bzw. Look-ahead sinnvoll ist und welche Anforderungen an die ent-
sprechenden Modellierungstechniken bestehen. Am Beispiel von Bearbeiter-
zuordnungen werden Möglichkeiten zur Realisierung solcher Modellierungs-
techniken aufgezeigt.
Keywords: Process Engineering, Service-Orchestrierung, SOA.
1 Motivation
Eines der fundamentalen Konzepte einer Service-orientierten Architektur
(SOA) ist die Orchestrierung von Geschäftsprozessen, d.h. deren koordinierte
Ausführung durch eine Prozess-Engine, die Services entsprechend der defi-
nierten Prozesslogik aufruft und interaktive Arbeitsschritte (sog. Human
- 9 -
Tasks) steuert [22] [23]. Außerdem ist es Ziel einer SOA, die Durchgängigkeit
bei der Umsetzung fachlicher Geschäftsprozesse in einer IT-Implementierung
zu erhöhen. D.h., es ist sicherzustellen, dass der als IT-Implementierung um-
gesetzte Geschäftsprozess die aus fachlicher Sicht bestehenden Anforderun-
gen auch tatsächlich erfüllt (Business-IT-Alignment). Diese Themen wurden
im Forschungsprojekt ENPROSO (Enhanced Process Management through
Service Orientation) betrachtet [5] [7] [8]. Bisher nicht betrachtet wurde die
Fragestellung, welche Informationen ein Fachprozess-Designer dokumentie-
ren sollte, um die spätere IT-Implementierung des Prozesses zu vereinfachen
bzw. zu beschleunigen. Hierbei müssen die im Fachprozess dokumentierten
Informationen ausreichend detailliert und vollständig sein, so dass ein IT-
Implementierer daraus eine technische Spezifikation ableiten kann, ohne zu-
sätzliches Wissen über diesen speziellen Fachbereich zu besitzen.
In diesem Zusammenhang bedeutet Frontloading, dass für Geschäftspro-
zesse bereits frühzeitig, d.h. während ihres fachlichen Entwurfs, detaillierte
Informationen zu implementierungsrelevanten Aspekten ermittelt und doku-
mentiert werden (z.B. Bearbeiterzuordnungen für Human Tasks, Stellvertre-
tungen, Ausnahmebehandlungen). Obwohl die Vorteile eines solchen Front-
loading offensichtlich sind, fehlen in den in der Praxis erstellten Fachpro-
zessmodellen entsprechende Informationen meist oder sie werden von den
Fachprozess-Designern nur ungenau festgelegt. Dies wiederum führt zu Ver-
zögerungen und Mehrkosten bei der nachfolgenden Prozessimplementierung,
weil eine zusätzliche Analysephase notwendig wird. Hierbei müssen (erneut)
Interviews mit Fachverantwortlichen bzw. -anwendern geführt werden, und
das in einer Projektphase in der diese Personen sowie die entsprechenden Pro-
jektberater oft nicht mehr zur Verfügung stehen. Um Projektverzögerungen zu
vermeiden, wird für solche ungenau definierten Prozessaspekte oftmals auch
vom IT-Bereich selbst entschieden, wie die Umsetzung im Detail zu gestalten
ist. Dies kann wiederum zu einer fehlerhaften Prozessimplementierung füh-
ren, also die Prozessqualität [19] [20] beeinträchtigen.
Es stellt sich die Frage, warum Fachprozess-Designer die später benötigten
Informationen nur unvollständig oder ungenau dokumentieren. Ein Problem
liegt darin, dass Fachanwender bzw. -berater oftmals nicht wissen, welche
Prozessaspekte in welchem Detaillierungsgrad für eine spätere Prozessimple-
mentierung benötigt werden. Auch die in Unternehmen verwendete SOA-
Methodik [1] [11] [13] [23] geht hierauf nur unzureichend ein (vgl. Abschnitt
4). Außerdem haben Fachprozess-Designer häufig nicht die erforderlichen
Kompetenzen, um Prozessaspekte auf einer detaillierten technischen Ebene zu
beschreiben. Existierende Prozessmodellierungssprachen (z.B. erweiterte
Ereignis-Prozess-Ketten (eEPK), Business Process Modeling Notation
(BPMN)) und Geschäftsprozessmodellierungswerkzeuge (z.B. ARIS) bieten
keine für diesen Personenkreis verwendbaren Techniken, um technische
- 10 -
Sachverhalte ausreichend detailliert zu dokumentieren. So kann z.B. bei einer
ARIS eEPK kaum modelliert werden, dass ein Prozessschritt Y (z.B. Ermitt-
lung der von einer geplanten Produktänderung betroffenen Bauteile) von einer
Person mit Rolle „Hardware-Entwickler“ ausgeführt werden soll, die zudem
zur selben Abteilung gehört, wie der Bearbeiter eines vorangehenden Prozess-
schrittes X („Produktänderungsantrag erstellen“). Meist wird für Prozess-
schritt Y dann nur die Rolle modelliert oder es wird zusätzlich ein Abtei-
lungsobjekt mit unklarer Semantik verwendet (vgl. Abb. 1a). Diese Informati-
on ist aber nicht ausreichend, um den Prozess so implementieren zu können,
dass er tatsächlich von einer Prozess-Engine in der gewünschten Semantik
ausgeführt werden kann. Es fehlt die Information, aus welcher Abteilung der
Bearbeiter stammen soll. In Modellierungswerkzeugen wie ARIS ist es jedoch
nicht oder nur eingeschränkt möglich, die in Abb. 1a gestrichelt dargestellten
Abhängigkeiten direkt zu modellieren. So gibt es kein Objekt, das denjenigen
Bearbeiter repräsentiert, der einen bestimmten Prozessschritt tatsächlich bear-
beitet. Ebenso gibt es keine Beziehung, die ausdrückt, dass die an einem Pro-
zessschritt modellierte Abteilung dieselbe sein soll, wie die Abteilung, wel-
cher dieser tatsächliche Bearbeiter angehört.
Abb. 1. ARIS eEPK mit a) unvollständiger Bearbeiterzuordnung, b) Flexibilitätsmarkierung.
Ähnliche Fragestellungen ergeben sich im Zusammenhang mit Look-ahead:
Meist werden Geschäftsprozesse ohne detaillierte Bezugnahme auf die bereits
existierenden IT-Artefakte modelliert. Jedoch ist es aus Sicht der Prozessimp-
lementierer wünschenswert, dass die bei der Implementierung zu verwenden-
den und bereits vorliegenden technische Artefakte (z.B. Services, Objekte des
Organisationsmodells) beim Fachprozess-Design ausgewählt und referenziert
werden. Dies zu bewerkstelligen, ist für Fachprozess-Designer aber nicht tri-
vial, da sie mit IT-lastigen Beschreibungen technischer Artefakte kaum klar
kommen. So werden Services, die durch Geschäftsprozesse aufgerufen wer-
den sollen, oftmals mittels der Web-Service Definition Language (WSDL)
beschrieben. WSDL-Artefakte sind aber für Personen ohne entsprechenden
IT-Hintergrund kaum verständlich. Selbst die von einigen IT-Bereichen ange-
botenen textuellen Service-Beschreibungen sind für Fachanwender nur be-
dingt verwendbar, da sie technische Terme enthalten oder technische Doku-
- 11 -
mentationen referenzieren (z.B. XSD-Beschreibungen für Datentypen der
Ein-/Ausgabedaten von Service-Aufrufen).
Für beide Aspekte, Frontloading und Look-ahead, werden Techniken benö-
tigt, die es Fachprozess-Designern ohne tiefgehende IT-Kenntnisse erlauben,
technische Aspekte zu definieren bzw. zu referenzieren. Dann wird es mög-
lich, die Verwendung dieser Techniken in der SOA-Methodik des Unterneh-
mens zu verankern und durch SOA-Governance sicherzustellen. Abschnitt 2
betrachtet, für welche Aspekte eines Geschäftsprozesses ein Frontloading
relevant ist. Außerdem werden die resultierenden Anforderungen beschrieben
und deren Umsetzung am Beispiel von Bearbeiterzuordnungen exemplarisch
vorgestellt. In Abschnitt 3 werden die Prozessaspekte mit Bedarf für ein Look-
ahead diskutiert. Eine Diskussion der einschlägigen Literatur und relevanter
SOA-Methodiken erfolgt in Abschnitt 4, bevor der Beitrag mit einer Zusam-
menfassung und einem Ausblick schließt.
2 Frontloading
In diesem Abschnitt analysieren wir, für welche Prozessaspekte ein Front-
loading relevant ist und welche Anforderungen hierfür bestehen. Anschlie-
ßend wird für Bearbeiterzuordnungen im Kontext von Human-Tasks exempla-
risch aufgezeigt, wie sich Frontloading konkret realisieren lässt (weitere An-
wendungen finden sich in [8]).
2.1 Relevante Prozessaspekte
Zuerst einmal geht es darum, besser zu verstehen, welcher Zweck mittels
Frontloading verfolgt werden soll. Dazu betrachten wir verschiedene Aspekte
eines Geschäftsprozesses [23] und analysieren, welche Informationen hierzu
bereits in der frühen Phase des Fachprozess-Designs dokumentiert werden
sollten.
Organisatorischer Aspekt: In einem Geschäftsprozessmodell wird mittels
sog. Bearbeiterzuordnungen festgelegt, welche Personen einen bestimmten
Prozessschritt bearbeiten sollen. Diese Bearbeiterzuordnungen werden in ei-
ner späteren Phase des Entwicklungszyklus in einem Prozess-Management-
System technisch umgesetzt [15] [25] [26] [27]. Die zugehörige Prozess-
Engine sorgt dann zur Laufzeit dafür, dass der Prozessschritt tatsächlich exakt
diesen Personen in die Arbeitsliste eingestellt wird, so dass nur diese ihn be-
arbeiten können. Daher ist die exakte fachliche Modellierung von Bearbeiter-
zuordnungen eine wichtige Grundlage für die Implementierungsphase.
Im Beispiel aus Abb. 1 muss im Fachprozessmodell die Bearbeiterzuord-
nung
- 12 -
Rolle = Hardware-Entwickler
Abteilung = Abteilung(Bearbeiter(Produktänderungsantrag erstellen))
festgelegt werden. Auf Grundlage der Teilinformation Rolle = Hardware-
Entwickler (vgl. Abb. 1a) allein ist dagegen keine vollständige bzw. korrekte
Implementierung möglich, da der resultierende Bearbeiterkreis (mit allen
Hardware-Entwicklern) zu groß wäre. Wie sich mit beschränkten IT-
Kompetenzen dennoch verwendbare Bearbeiterzuordnungen modellieren las-
sen zeigt Abschnitt 2.3.
Zum organisatorischen Aspekt eines Geschäftsprozesses gehören auch
Stellvertreterregelungen [2]. Diese legen für den Fall der Abwesenheit regulä-
rer Bearbeiter (z.B. infolge von Dienstreisen, Urlaub oder Krankheit) fest,
welche Personen einen Prozessschritt alternativ bearbeiten können. Auch die-
se Funktionalität wird von heutigen Prozess-Engines bereitgestellt. Sie sollte
auch genutzt werden, da sich Prozessschritte sonst ggf. nur in den Arbeitslis-
ten abwesender Personen befinden und daher nicht bearbeitet werden können.
Dies kann zu signifikanten Verzögerungen bei der Prozessausführung und
damit zu hohen Kosten (z.B. infolge versäumter Termine) führen. Um dies zu
vermeiden, müssen geeignete Stellvertreterregelungen für alle Geschäftspro-
zesse bzw. Prozessschritte implementiert werden. Dies ist wiederum nur mög-
lich, wenn basierend auf den fachlichen Anforderungen vorgegeben worden
ist, welcher Personenkreis als Stellvertreter fungieren kann bzw. soll. Auch
für diese Art des Frontloading können die in Abschnitt 2.3 beschriebenen
Techniken zur fachlichen Modellierung von Bearbeiterzuordnungen verwen-
det werden.
Ähnliches gilt für Eskalationsregeln: Diese definieren z.B. Mitteilungen an
bestimmte Kollegen oder Vorgesetzte, die ausgelöst werden sollen, wenn die
Bearbeitung eines Prozessschrittes nicht fristgerecht begonnen oder beendet
wird [18] [23]. Auch hier ist wieder, ausgehend von den fachlichen Anforde-
rungen, vorzugeben, in welchen Fällen, nach welchen Fristen, an welche Per-
sonen, welche Art von Eskalation ausgelöst werden soll. Eine eigenmächtige
Festlegung durch die IT-Implementierer ist auch hier nicht sinnvoll, insbeson-
dere wenn man berücksichtigt, dass eine IT-Implementierung häufig durch
externe Dienstleister erfolgt. Diese haben nur begrenzte Möglichkeiten und
kaum wirtschaftliches Interesse, unklare Sachverhalte mit dem betroffenen
Fachbereich des Auftraggebers zu klären. Insgesamt ist deshalb das Frontloa-
ding für alle Themen des organisatorischen Aspekts essentiell.
Datenobjekte: Fachliche Datenobjekttypen werden in einem Prozessmodell
benötigt, um die Schnittstellen des Prozesses zu definieren und seine internen
Datenflüsse festzulegen [17] [23]. So werden Eingabedaten einem Prozess
beim Start übergeben, während er bei seinem Ende entsprechende Ausgabeda-
ten zurückliefert. Des Weiteren müssen die Ein- und Ausgabedaten der vom
- 13 -
Prozess zur Laufzeit aufgerufenen Services verwaltet werden. Im Kontext
einer Human Task etwa repräsentieren die Eingabedaten die Informationen,
welche dem Bearbeiter in seiner Bildschirmmaske angezeigt werden, während
die Ausgabedaten den von ihm einzugebenden Daten entsprechenden [14].
Werden Datenobjekttypen in Fachmodellen nur rudimentär modelliert, et-
wa durch Angabe ihres Namens und ihrer groben Inhalte, reicht diese Infor-
mation nicht aus, um die Aufruf-Schnittstelle des Prozesses oder die von ihm
benötigten Services (inkl. Human Tasks und ihrer Bildschirmmasken) zu im-
plementieren. Um mittels Frontloading spätere Rückfragen bei den Fachabtei-
lungen reduzieren zu können, müssen für jedes Datenobjekt alle fachlich rele-
vanten Attribute (inkl. Ihrer Datentypen) modelliert werden. So muss der
Fachbereich entscheiden, ob das Attribut Kundennummer im Datenobjekt
Kunde eine Zahl sein soll, oder ob Kundennummern der Form „K285-2012“
erwünscht sind. Außerdem müssen die Datenobjekte den Geschäftsprozess-
schritten bzw. fachlichen Services eindeutig als Eingabe- oder Ausgabepara-
meter zugeordnet werden.
Services: Ein automatisch ausgeführter Prozessschritt kann einen Service
aufrufen, ihm Datenobjekte übergeben und nach dessen Ausführung die Aus-
gabedaten zurückerhalten, die dann wiederum die Prozessdaten verändern.
Frontloading fordert hier, dass die benötigten Services bereits im fachlichen
Prozessmodell möglichst detailliert beschrieben werden und nicht nur ein
Servicename als Platzhalter modelliert wird. Erst dadurch wird definiert, wie
der zusätzlich benötigte Service gestaltet werden soll.
Konkret sollte für jeden zu verwendenden Service festgelegt werden, wel-
che Funktion er erbringt, welche Ein-/Ausgabedaten er verwendet und welche
QoS-Eigenschaften [5] erforderlich sind (z.B. Antwortzeit, Transaktionsver-
halten). Dies kann vom IT-Bereich mit existierenden Services abgeglichen
werden oder als Entwurfsgrundlage für einen neu zu realisierenden Service
dienen.
Flexibilität: Für eine IT-Umsetzung ebenfalls relevant ist die Markierung der
Stellen im Geschäftsprozess, für die ein (erhöhter) Flexibilitätsbedarf besteht
[9] [10] [21] [23] [33]. Für diese Bereiche oder Objekte im Geschäftsprozess
ist eine besonders flexible Implementierung erforderlich. So gibt es Prozess-
schritte, die einen Service aufrufen, bei denen aber bekannt ist, dass der konk-
ret zu verwendende Service variiert. So kann die Überprüfung einer Kredit-
würdigkeit mittels firmeninterner Informationen und IT-Systemen erfolgen
oder von externen Dienstanbietern erbracht werden, die sich in Qualität und
Preis unterscheiden. Zudem können die Ein-/Ausgabedatenstrukturen unter-
schiedlich sein. Ist dem Fachbereich z.B. durch Erfahrungen aus der Vergan-
genheit bekannt, dass der zu verwendende Service sich häufig ändert, sollte
dieser Prozessschritt entsprechend markiert werden. Dadurch wird es möglich,
- 14 -
den Serviceaufruf in besonderem Maße entkoppelt zu implementieren, etwa
durch Verwendung eines Enterprise Service Bus (ESB) oder Message Bro-
kers.
Ein vorhersehbarer Bedarf an Flexibilität besteht auch im Hinblick auf die
Festlegung von Verzweigungsbedingungen, Geschäftsregeln, Bearbeiterzu-
ordnungen und Timeout-Zeiten. Dies sollte deshalb bereits beim Fachentwurf
dokumentiert werden. Hierfür genügt es meist, im Modellierungswerkzeug
einen speziellen Objekttypen für Flexibilitätskommentare zu definieren bzw.
von einem existierenden Objekttyp abzuleiten (vgl. Abb. 1b). Dieser muss
lediglich ein Attribut zur Angabe der Flexibilitätsart besitzen sowie eine tex-
tuelle Beschreibung der zu erwartenden Veränderungen ermöglichen. Die
Anforderungen des in Abb. 1b dargestellten Beispiels können z.B. durch Ein-
bindung einer Business Rule Engine realisiert werden.
Ausnahmesituationen: Bei der Ausführung von Geschäftsprozessen können
Ausnahmesituationen auftreten, auf die geeignet reagiert werden muss [23].
Beispiele für Ausnahmesituationen sind fehlgeschlagene Serviceaufrufe, un-
zureichende Datenqualität (d.h. fehlende oder widersprüchliche Attributwerte,
etwa nach einer Dateneingabe durch einen Benutzer) oder eine leere Bearbei-
termenge für eine Human-Task (etwa wenn Mitarbeiter das Unternehmen
verlassen haben). Für einige dieser Ausnahmesituationen ist es offensichtlich,
unter welchen Umständen sie auftreten können (z.B. Fehlschlag eines Ser-
viceaufrufs), so dass die Detektion und Behandlung der Ausnahme direkt
durch den IT-Bereich definiert werden kann, d.h. für diesen Fall besteht kein
Bedarf für ein Frontloading. Dagegen sind andere Ausnahmen nur mittels
fachlicher Zusatzinformationen erkennbar, etwa widersprüchliche Attribut-
werte (z.B. Baureihe = Actros und Bauteil = P2354-2356-3). Zur Fehlerer-
kennung muss bekannt sein, dass ein Actros ein Nutzfahrzeug ist, wohingegen
mit P beginnende Bauteilnummern zu PKWs gehören.
Während die Ausnahmenerkennung nur in manchen Fällen vom Fachbe-
reich vordefiniert werden muss, ist Frontloading für die Ausnahmebehandlung
fast immer erforderlich: So kann ein Serviceaufruf nach einem Fehlschlag
automatisch wiederholt werden. Schlägt er jedoch weiterhin fehl, muss vom
Fachbereich vorgegeben sein, ob der Aufruf weiterhin in gewissen Zeitinter-
vallen wiederholt werden soll, ob ein alternativer Service aufgerufen werden
soll (ggf. mit höheren Kosten), oder ob von Personen ausgeführte Human
Tasks stattdessen verwendet werden sollen, um die Serviceergebnisse auf die-
sem Weg zu erzeugen. Hierbei sind u.a. die resultierenden Verzögerungen bei
der Prozessausführung gegen die entstehenden Zusatzkosten abzuwägen.
Ebenso muss bei Inkonsistenzen in den Daten definiert werden, wer den Feh-
ler beheben soll. Im Falle fehlender Task-Bearbeiter sollte ein Prozessverant-
wortlicher festgelegt werden, der den Prozessschritt dann an eine fachlich
kompetente Person delegieren kann.
- 15 -
Bildschirmmasken: Oftmals verwenden Benutzer als Formulare gestaltete
Bildschirmmasken zur Bearbeitung von Human Tasks [14] [16] [17]. Die an-
zeigbaren bzw. einzugebenden Daten werden dabei durch die Ein-
/Ausgabedatenobjekte des entsprechenden Prozessschrittes bestimmt. Aller-
dings sollten dem Benutzer nicht alle möglichen Attribute aus dem Eingabe-
objekt angezeigt werden, wenn dieses redundante, irrelevante oder technische
(d.h. für Fachanwender uninteressante) Attribute enthält. Ebenso sollte der
Benutzer nicht alle theoretisch möglichen Daten eingeben, nur weil die als
Ausgabeobjekt verwendete Standard-Datenstruktur im aktuellen Kontext irre-
levante Attribute enthält. Solche Sachverhalte sind durch den Fachbereich
vorzugeben, um die spätere Implementierung von möglichst gut geeigneten
Bildschirmmasken zu ermöglichen.
Datenobjekttypen enthalten keine Informationen darüber, welche Attribute
obligat und welche optional sind. Daher kann auf Basis der als Ausgabeobjekt
verwendeten Datentypen nicht entschieden werden, ob die Eingabe eines be-
stimmten Attributs in einem Pflichtfeld erfolgen soll oder nicht. Die Masken-
implementierung kann dies aber nur berücksichtigen, wenn der Fachbereich
beim betreffenden Prozessschritt entsprechende Information explizit doku-
mentiert hat. Es sollte für jedes Attribut des Masken-Ausgabeobjektes ein
Status {verpflichtend, optional, weglassen} definiert werden sowie für At-
tribute des Eingabeobjektes ein Status {anzeigen, weglassen}.
Neben dem Inhalt von Bildschirmmasken ist auch deren Gestaltung rele-
vant. Ein Frontloading sollte daher auch Informationen zum Aussehen der
Masken beinhalten. So ist es für die spätere Maskenimplementierung hilf-
reich, wenn am Prozessschritt eine Skizze angehängt wird, welche die Positi-
onen der einzelnen Datenfelder fixiert und die darzustellenden Texte-Labels
festlegt. Außerdem kann vorgegeben werden, mit welcher Art von Steuerele-
ment eine Werteeingabe erfolgen soll (z.B. Textfeld, Listenfeld, Combo-Box,
Radio-Buttons).
Sonstiges: Bzgl. weiterer Prozessaspekte, etwa der Definition von Transakti-
onsgrenzen im Geschäftsprozess oder der Festlegung von Messpunkten für
ein späteres Prozess-Performance-Management, verweisen wir aus Platzgrün-
den auf [8].
2.2 Anforderungen an Frontloading
Frontloading-Techniken müssen die folgenden generellen Anforderungen
erfüllen:
Es muss eine Modellierungstechnik für jeden Prozessaspekt geben, wenn
dessen Ausgestaltung bei der Prozessimplementierung aus fachlicher Sicht
relevant ist.
- 16 -
Jede Technik zum Frontloading muss auch mit geringen IT-Kenntnissen
leicht verständlich und benutzbar sein.
Der resultierende Informationsgehalt bildet eine vollständige Grundlage
für eine spätere Prozessimplementierung.
Die Überführung der Informationen in eine Prozessimplementierung ist
möglich und sollte möglichst effizient durchführbar sein.
2.3 Frontloading für Bearbeiterzuordnungen
Wir stellen im Folgenden vier Beschreibungstechniken für Bearbeiterzuord-
nungen vor. Diese erfüllen die genannten Anforderungen und bieten in der
dargestellten Reihenfolge aufsteigenden Informationsgehalt und Funktionali-
tät, bei gleichzeitig zunehmendem Bedarf nach einer Unterstützung durch
Modellierungswerkzeuge.
Ansatz 1 (Freie textuelle Beschreibung): Eine heute bereits verwendbare
Beschreibungstechnik ist die freie Dokumentation am zugehörigen Prozess-
schritt. Hierfür können vom Modellierungswerkzeug angebotene Objekte für
Anmerkungen (vgl. Abb. 1b), Attribute des Prozessschrittes oder angehängte
Textdokumente genutzt werden. So könnte z.B. bei dem in Abb. 1a dargestell-
ten Beispiel am Prozessschritt „Betroffene Bauteile ermitteln“ Folgendes do-
kumentiert werden: „Bearbeiter muss Rolle Entwickler haben und gleicher
Abteilung angehören, wie der Antragssteller“.
Prinzipiell ist so ein hoher Informationsgehalt erzielbar, zudem erfordert
die Beschreibungstechnik keine speziellen Fähigkeiten der Fachprozess-
Designer. Allerdings lässt sich die Qualität solcher Beschreibungen kaum
sicherstellen, da diese ungenau und mehrdeutig sein können. So muss vor der
Überführung in eine IT-Implementierung festgestellt werden, welche Objekte
des Organisationsmodells (z.B. Rollennamen) genau gemeint sind. Dies ist
nicht immer einfach, da sich Fachprozess-Designer oftmals nicht an Standard-
Begriffe halten (z.B. Entwickler vs. Hardware-Entwickler). Auch die Ver-
knüpfung der Teilbedingungen (und/oder sowie Klammerung) und die Refe-
renzierung von Prozessschritten wird oft nicht eindeutig sein. Zudem entsteht
für die manuell durchzuführende Interpretation ein hoher Aufwand.
Ansatz 2 (Semantische Beschreibung): Eine Erweiterung von Ansatz 1 be-
steht darin, für Objektnamen ein vordefiniertes Vokabular (im Sinne einer
Ontologie) vorzuschreiben. So kann der Fachprozess-Designer z. B. verpflich-
tet werden, bei der Verwendung eines Rollennamens einen vordefinierten
Namen aus einer gegebenen Liste auszuwählen. Ansonsten darf er die Be-
schreibung der Bearbeiterzuordnung frei gestalten. Eine weitergehende Vari-
ante besteht darin, den erstellten Text automatisiert zu analysieren, um Refe-
renzierungen des Organisationsmodells zu identifizieren und mit dem vorde-
- 17 -
finierten Vokabular abzugleichen. So wird im oben dargestellten Text er-
kannt, dass es sich bei dem Wort „Entwickler“ um einen Rollennamen han-
deln soll. Ergibt der Abgleich mit dem vordefinierten Vokabular, dass es kei-
ne Rolle „Entwickler“ gibt, sondern nur „Software-Entwickler“ und „Hard-
ware-Entwickler“, wird der Fachprozess-Designer aufgefordert, seine Angabe
zu präzisieren. Im dargestellten Beispiel einer Bauteil-Ermittlung wird er die
Rolle „Hardware-Entwickler“ wählen.
Mit diesem Ansatz wird die Ungenauigkeit bzw. Unschärfe verringert, da
die Objektnamen nun eindeutig sind. Insofern reduziert sich auch der Auf-
wand für die Überführung in eine Prozessimplementierung. Allerdings ist die
Interpretation des frei formulierten Textes, ebenso wie bei Ansatz 1, erforder-
lich.
Ansatz 3 (Template-basierte Beschreibung): Eine weitere Optimierung
kann dadurch erzielt werden, dass dem Fachprozess-Designer, neben den Ob-
jektnamen, auch die Beschreibungstexte vorgegeben werden. So kann die
Menge aller relevanten Bearbeiter-Schablonen (engl. Templates) vordefiniert
und bereitgestellt werden. Abb. 2 zeigt einige Beispiele für solche Templates.
Template-Name Beschreibung
Rolle(x) Die potentiellen Bearbeitern müssen die Rolle x innehaben
Abteilung(x) Bearbeiter sind Mitglied der Abteilung x
Kompetenz(x) Bearbeiter haben Kompetenz x (z.B. Englisch)
Vorgesetzter(x) Bearbeiter ist Vorgesetzter von Person x
RolleUndAbt(x,y) Bearbeiter haben die Rolle x und sind Mitglied der Abteilung y
Abb. 2. Beispiel-Templates für Bearbeiterzuordnungen.
Der Fachprozess-Designer wählt bei der Festlegung einer Bearbeiterzuord-
nung ein Template aus und gibt die Namen der referenzierten Objekte an (an-
statt x, y). Um Mehrdeutigkeiten zu vermeiden, sollten diese Namen analog
zu Ansatz 2 aus einem vordefinierten Vokabular entnommen werden. In unse-
rem Beispiel wird der Fachprozess-Designer also das Template Rol-
leUndAbt(x,y) auswählen und als Rolle x = „Hardware-Entwickler“ sowie als
Abteilung y = „Abteilung von Bearbeiter(Schritt Produktänderungsantrag
erstellen)“ festlegen.
Mit diesem Ansatz lässt sich eine hohe Genauigkeit erzielen. Lediglich die
Referenzierung von Vorgängerschritten oder Prozessvariablen ist evtl. noch
nicht eindeutig. Dies kann aber durch eine geeignete Unterstützung seitens
des Modellierungswerkzeugs verbessert werden. Es besteht also in Bezug auf
eine weitere Reduzierung des Aufwandes für nachfolgende Entwicklungspha-
sen kaum mehr Optimierungspotential. Nachteilig bei Ansatz 3 ist allerdings,
dass sehr viele Kombinationen von Bedingungen als Template vordefiniert
werden müssen (z.B. RolleUndAbteilung, RolleUndKompetenz, Abtei-
- 18 -
lungUndGruppe …). Diese Problematik greift der nun vorgestellte Ansatz 4
auf.
Ansatz 4 (Kombinierbare Templates) Werden dem Fachprozess-Designer
lediglich elementare Templates angeboten, muss er diese zur Erstellung von
komplexeren Bearbeiterzuordnungen mittels boolescher Operationen (AND,
OR, NOT) kombinieren. Inwieweit er hierzu überhaupt in der Lage ist, hängt
von seinem (mathematischen) Kenntnisstand ab. Schwer vorstellbar ist, dass
er komplexe Formeln selbstständig korrekt erstellt. Deshalb benötigt ein
Fachprozess-Designer bei diesem Ansatz eine Unterstützung durch ein geeig-
netes Modellierungswerkzeug zur Festlegung von Bearbeiterzuordnungen.
Dieses ermöglicht die Auswahl eines (elementaren) Templates (vgl. Abb. 3a)
sowie von Objektnamen aus dem vordefinierten Vokabular. Des Weiteren
können die Namen der existierenden Prozessschritte referenziert werden.
Nach Festlegung einer ersten elementaren Bearbeiterzuordnung, ermöglicht
das Werkzeug dann die Hinzunahme weiterer Teile. Nach Festlegung jedes
weiteren Teils muss darüber hinaus die Verknüpfungsart angeben werden.
Ihre Bedeutung sollte, wie in Abb. 3b dargestellt, vom Modellierungswerk-
zeug geeignet erläutert werden.
Abb. 3. Assistent für a) die Auswahl elementarer Templates, b) und deren Kombination.
Die beliebige Kombinierbarkeit von Templates steigert die Ausdrucksmäch-
tigkeit für Bearbeiterzuordnungen. Deren Festlegung wird für Fachprozess-
Designer allerdings auch anspruchsvoller. Bzgl. der Genauigkeit der erstellten
Bearbeiterzuordnungen sowie dem Aufwand für die Überführung in eine Pro-
zessimplementierung besteht kein nennenswerter Unterschied zu Ansatz 3.
Deshalb sollte man die Entscheidung zwischen den Ansätzen 3 und 4 davon
abhängig machen, wie gut die Fachprozess-Designer mit Ansatz 4 zurecht-
kommen.
- 19 -
3 Look-ahead
Wir betrachten nun die einzelnen für Look-ahead relevanten Prozessaspekte
sowie zugehörige allgemeinen Anforderungen. Eine detaillierte Beschreibung
von Ansätzen zur Realisierung von Look-ahead für konkrete Prozessaspekte
findet sich in [8].
3.1 Relevante Prozessaspekte
Für die folgenden Prozessaspekte sollte bereits bei der Modellierung des
Fachprozesses berücksichtigt werden, ob bzw. welche IT-Artefakte bereits
existieren (oder in Entwicklung sind) und später bei der Prozessausführung
verwendet werden sollen.
Organisatorischer Aspekt: Wie bereits im Kontext von Frontloading erör-
tert, beschreibt ein Fachprozessmodell auch Bearbeiterzuordnungen, Stellver-
treterregelungen und Eskalationen. Diese werden mittels Ausdrücken defi-
niert, die organisatorische Objekte (kurz: OrgObjekte), etwas Rollen, Abtei-
lungen oder Kompetenzen, verwenden. Bei der späteren Prozessimplementie-
rung werden diese Ausdrücke so umgesetzt, dass Objekte eines Organisati-
onsmodells des Unternehmens referenziert werden. Damit dieses bei der Pro-
zessausführung auch tatsächlich zur Berechnung der entsprechenden Personen
(potentielle Bearbeiter) verwendet werden kann, enthält es außer den OrgOb-
jekten auch die jeweils aktuell gültige Zuordnung von Personen zu ihnen. So
muss z.B. gespeichert sein, welche Mitarbeiter aktuell die Rolle Hardware-
Entwickler innehaben, um Bearbeiter einer Human Task mit entsprechender
Rollenzuordnung ermitteln zu können.
Damit ein Fachprozess in eine durch eine Prozess-Engine ausführbare Im-
plementierung umgesetzt werden kann, müssen die zu verwendenden OrgOb-
jekte eindeutig identifiziert werden können. Idealerweise werden hierzu im
Fachprozess dieselben Namen für OrgObjekte verwendet, wie im Organisati-
onsmodell des Unternehmens.1 Dann ist eine einfache Umsetzung bei der
Prozessimplementierung gewährleistet.
Allerdings handelt es sich bei OrgObjekten um IT-Artefakte (wenn auch
um einfach strukturierte), die den Fachprozess-Designern nicht ohne weiteres
bekannt sind. Um sie für Look-ahead verwendbar zu machen, müssen sie die-
sem Personenkreis zugänglich gemacht werden. Dies erfordert einerseits eine
leicht verständliche Publizierung der Organisationsmodell-Struktur (z.B. der
Objekttypen Person, Rolle, Abteilung und Kompetenz sowie ihrer Beziehun-
gen). Andererseits müssen die Ausprägungen der OrgObjekte publiziert wer-
1 Durch das in Abschnitt 2.3 erwähnte vordefinierte Vokabular wird dies unterstützt, so dass die
vorgestellten Ansätze teilweise auch Look-ahead realisieren.
- 20 -
den, d.h. die konkreten im Prozessmodell verwendbaren Rollen, Abteilungen,
usw. Schließlich müssen geeignete Suchfunktionen bereitgestellt werden.
Offensichtlich erhöht Look-ahead die Präzision der Fachprozessmodelle
und reduziert zudem Mehrdeutigkeiten. Die zusätzlich resultierende Wieder-
verwendung der OrgObjekte erspart darüber hinaus deren (redundante) Fest-
legung. Noch viel entscheidender ist jedoch, dass durch die Vermeidung iden-
tischer bzw. ähnlicher Objekte der Pflegeaufwand reduziert wird: So müssen
Personen bei einem Bereichs- oder Funktionswechsel nicht mehreren ähnli-
chen OrgObjekten (z.B. Rollen) neu zugewiesen (und aus ihren ehemaligen
OrgObjekten herausgenommen) werden. Um den Pflegeaufwand weiter zu
reduzieren, lohnt es sich sogar, nur „ungefähr passende“ OrgObjekte in einem
Geschäftsprozess zu verwenden und sie mittels einer geeigneten Bearbeiter-
zuordnung anzupassen. So könnte z.B. anstatt einer noch nicht existierenden
Rolle Software-Ersteller die äquivalente Bearbeiterzuordnung Rolle = Soft-
ware-Entwickler Rolle = Software-Architekt verwendet werden, falls diese
beiden OrgObjekte bereits existieren.
Datenobjekte: In einem Fachprozess werden Datenobjekte benötigt, um den
Datenfluss innerhalb des Prozesses sowie beim Aufruf von Services oder Hu-
man Tasks festzulegen. Look-ahead bedeutet nun, dass hierfür bereits existie-
rende Typen von Datenobjekten verwendet werden sollten, d.h. Datentypen
für die bereits ein detailliertes Modell (z.B. als UML-Klassendiagramm) oder
gar eine Implementierung (z.B. als Java-Klasse) existiert. Wie bereits moti-
viert, ist es dazu erforderlich, dass die Informationen über existierende techni-
sche Artefakte auf eine für Fachprozess-Designer verständliche Art bereitge-
stellt werden.
Der offensichtliche Nutzen einer Wiederverwendung technischer Datenty-
pen ist die Reduzierung des Aufwandes für deren Modellierung, Spezifikation
und Implementierung. Noch wichtiger ist jedoch, dass durch Look-ahead er-
reicht wird, dass innerhalb eines Geschäftsprozesses dieselben Datentypen
verwendet werden, wie für Serviceaufrufe und Human Tasks. Eine solche
Harmonisierung erspart auch den Aufwand für die aufwendige Implemen-
tierung von Transformationen zwischen Datenstrukturen. Andernfalls müssten
z.B. Kundendaten vor einem Serviceaufruf von dem prozessinternen Datentyp
in den vom Service verwendeten Datentyp transformiert werden; ebenso
müssten (z.B. nach Änderung der Kundendaten durch den Service) die Rück-
gabedaten des Service wieder in die prozessinterne Datenstruktur zurücktrans-
formiert werden.
Services: Ein Geschäftsprozess ruft bei seiner Ausführung Services auf, um
Aktionen in (fremden) IT-Systemen durchzuführen. Die in einem Unterneh-
men existierenden IT-Systeme bieten hierzu die relevanten Aktionen in Form
einer Service-Schnittstelle an. Wie bereits in Abschnitt 1 erwähnt, werden die
- 21 -
angebotenen Services und ihre Operationen häufig lediglich auf einer sehr
technischen Ebene publiziert, etwas als WSDL-Beschreibungen. Diese sind
jedoch für Fachprozess-Designer mit geringen IT-Kenntnissen nicht verständ-
lich. Dasselbe Problem besteht auch bei den von manchen IT-Bereichen an-
gebotenen textuellen Servicebeschreibungen, wenn die verwendete Sprache
sich zu stark von der fachlichen Ebene unterscheidet oder gar technische Arte-
fakte wie XSD-Datentypspezifikationen für Ein-/Ausgabeparameter referen-
ziert werden. Daher ist es erforderlich, dass existierende und bereitgestellte
Services in einer für Fachanwender verständlichen Sprache bzw. Notation
beschrieben werden. Diese Beschreibungen müssen leicht zugänglich sein und
das Suchen nach benötigten Services ermöglichen. Nur dann wird es möglich,
dass Fachprozess-Designer einen geeigneten Service finden und am entspre-
chenden Geschäftsprozessschritt referenzieren können. Eine solche präzise
Festlegung eines Services (möglichst inkl. der zu verwendenden Serviceope-
ration) erspart aufwendige Rückfragen und Analysen während der Implemen-
tierungsphase des Geschäftsprozesses.
Nicht immer existiert jedoch bereits ein Service, der exakt die gewünschte
Funktionalität realisiert. Es macht aber in manchen Fällen Sinn, einen Service
zu verwenden, der eine ähnliche Funktionalität anbietet. Gibt es beispielswei-
se keinen Service, der nach Übergabe eines Bauteilnamens die Bauteildaten
bereitstellt, so kann dieser ersetzt werden durch einen bereits existierenden
Service, der die Bauteilnummer als Eingabe verwendet. Ist die Bauteilnum-
mer zu diesem Zeitpunkt im Geschäftsprozess jedoch noch nicht bekannt,
muss diese ausgehend vom Bauteilnamen ermittelt werden. Dies kann evtl.
durch Nutzung eines automatisch ausführbaren Services erfolgen oder durch
einen interaktiven Arbeitsschritt (Human Task). In beiden Fällen muss hierfür
der Geschäftsprozess umgestaltet werden, was eine fachliche Entscheidung
erfordert. Aus diesem Grund muss diese Entscheidung in der Phase des Fach-
prozess-Designs getroffen werden. Dies erfordert, dass die existierenden Ser-
vices bekannt sind und zudem eine Vorgabe existiert, diese zu verwenden,
sofern wirtschaftlich sinnvoll. Letzteres wird sehr häufig der Fall sein, da die
Wiederverwendung eines existierenden Services nicht nur Zeit und Kosten für
eine neue Serviceimplementierung erspart, sondern auch Kosten für dessen
zukünftige Wartung und Betrieb. Dagegen ist der Nachteil eines ggf. weniger
optimalen Geschäftsprozesses (d.h. langsamer, aufwendiger) vom betroffenen
Fachbereich abzuwägen.
Geschäftsregeln: Business Rules werden bei der Umsetzung von Geschäfts-
prozessen verwendet, um z.B. Verzweigungsregeln im Kontrollfluss-Ablauf
zu definieren. So können etwa Kunden automatisch in die Kategorien Premi-
um-, Standard- und Problemkunde klassifiziert werden, was Auswirkungen
auf die Art und Anzahl von Prüfaktivitäten (z.B. eines Leasing-Antrags) ha-
ben kann. Durch Verwendung einer Business Rule Engine können solche Re-
- 22 -
geln zentral administriert werden, Schwellwerte leicht geändert werden (z.B.
Online mittels eines entsprechenden Werkzeugs und ohne erneutes Deploy-
ment) und Regeländerungen teilweise sogar direkt durch Fachbereiche erfol-
gen.
Selbstverständlich ist die Wiederverwendung von Business Rules sinnvoll,
um Kosten für die Implementierung und Pflege neuer Geschäftsregeln zu
vermeiden. Zudem sollten redundante Business Rules vermieden werden, um
infolge separater Wartung ein unterschiedliches Verhalten verschiedener Ge-
schäftsprozesse zu vermeiden. So sollte ein Kunde nicht nur in einzelnen Pro-
zessen als Premiumkunde behandelt werden. Mittels Look-ahead kann auch
für Business Rules eine höhere Wiederverwendung erzielt werden. Der Fach-
prozess-Designer muss existierende Business Rules auffinden können, wofür
er eine für Fachanwender verständliche Beschreibung ihrer Funktionalität
bzw. ihres Verwendungszweckes benötigt. Zudem muss er eine Business Rule
eindeutig in einem Geschäftsprozessschritt referenzieren können.
3.2 Anforderungen an Look-ahead
Für das Thema Look-ahead ergeben sich folgende generelle Anforderungen:
Es gibt eine Beschreibungstechnik für existierende Artefakte für jeden Pro-
zessaspekt, so dass diese bei der Prozessimplementierung verwendet wer-
den können.
Jede Technik zur Beschreibung oder Suche von IT-Artefakten muss für
Fachprozess-Designer leicht verständlich und benutzbar sein.
Der Informationsgehalt einer Beschreibung muss es erlauben, über die
Verwendung eines zugehörigen technischen Artefakts zu entscheiden.
Zu verwendende technische Artefakte müssen im Fachprozessmodell ein-
deutig referenzierbar sein.
4 Diskussion
Manche Einzelaspekte für Frontloading und Look-ahead lassen sich in heuti-
gen BPM-Werkzeugen realisieren (für Details siehe [12], [29]). Ein Beispiel
hierfür sind organisatorische Aspekte, die im Fachprozess dokumentiert wer-
den können, allerdings lediglich unvollständig und nicht ausreichend eindeu-
tig (vgl. Abb. 1). Andere Aspekte, etwa Flexibilitätsmarkierungen, können
z.B. durch zusätzliche textuelle Beschreibungen im Fachprozess bereits aus-
reichend detailliert dokumentiert werden. Wichtig ist dann allerdings eine
geeignete SOA-Methodik, die Frontloading und Look-ahead verbindlich vor-
schreibt. Im Folgenden betrachten wir dazu existierende SOA-Methodiken
und -Vorgehensmodelle.
- 23 -
Service-Oriented Modeling and Architecture (SOMA) [1] adressiert einige
der in diesem Beitrag beschriebenen Einzelaspekte, etwa die Modellierung
von Flexibilitätsmarkierungen. Diese werden in der Identification-Phase durch
Angabe von Geschäftsregeln realisiert. Ausnahmesituationen und Datenobjek-
te werden in der Specification-Phase beschrieben. Die Methodik sieht jedoch
nicht vor, bereits existierende Services zu finden und diese im Fachprozess zu
verwenden. Auch werden keine Beschreibungen von organisatorischen As-
pekten oder Bildschirmmasken gefordert.
Auch im Vorgehensmodell Quasar Enterprise [13] können Flexibilitäts-
markierungen definiert werden. Die Erstellung entsprechender Geschäftsre-
geln erfordert jedoch speziell geschulte Mitarbeiter. Die Suche von Services
basierend auf fachlichen Kriterien wird nicht unterstützt und ein fachliches
Modell ist nur begrenzt vorhanden.
Die Modellierungsmethodik M3 für SOA [11] sieht für die verschiedenen
Projektphasen unterschiedliche Modelltypen vor. Organisatorische Aspekte
können beim Fachprozess-Design (Initiation-Phase) modelliert werden, aller-
dings nicht ausreichend detailliert. Datenobjekte und Geschäftsregeln lassen
sich im Fachprozessmodell beschreiben, aber ohne Unterstützung durch das
gegebene BPM-Werkzeug. Es ist kein Look-ahead für bereits existierende
Datenobjekte oder Services vorgesehen.
AVE (ARIS Value Engineering) [31] ist ein Vorgehensmodell für BPM-
Projekte und orientiert sich stark an ARIS. Deshalb ist eine vollständige Mo-
dellierung vieler Prozessaspekte nicht möglich. Die Suche nach Services mit-
tels fachlicher Kriterien im Service-Repository wird nur auf sehr einfache Art
und Weise unterstützt.
SOA-Method [23] berücksichtigt die Aspekte Service-Suche und Ser-
vice-Wiederverwendung. Andere Prozessaspekte werden nicht betrachtet.
Weitere Ansätze, wie OrVia [32], Project-Oriented SOA [30] oder SUPER
[32] betrachten ebenfalls Vorgehensweisen zur Entwicklung von Prozessap-
plikationen im SOA-Kontext. Sie unterstützen lediglich kleinere Teile der be-
schriebenen Frontloading- und Look-ahead-Aspekte.
Keine der untersuchten Ansätze erfüllt alle Anforderungen (vgl. [12]).
Manche Ansätze betrachten zwar einzelne Prozessaspekte, diese können je-
doch nur abstrakt beschrieben werden. Eine vollständige und dennoch für den
Fachprozess-Designer verständliche Technik, wie wir sie in Abschnitt 2.3 für
Bearbeiterzuordnungen skizziert haben, wird von keinem Ansatz unterstützt.
5 Zusammenfassung und Ausblick
Frontloading und Look-ahead sind für das Fachprozess-Design in einer SOA
essentiell, um Implementierungen von Geschäftsprozessen zu erhalten, die
tatsächlich die fachlichen Anforderungen erfüllen und dennoch die realen IT-
- 24 -
technischen Gegebenheiten nicht ignorieren. Wir haben analysiert, bei wel-
chen Prozessaspekten dies erforderlich ist. Frontloading wurde exemplarisch
für das Thema Bearbeiterzuordnungen detailliert.
Die in diesem Beitrag identifizierten Aspekte sind in realen Geschäftspro-
zess-Implementierungsprojekten nachhaltig zu erproben bzw. verfeinern. Da-
bei sind auch fortschrittliche Konzepte für die Visualisierung fachlicher und
technischer Prozessmodelle vonnöten [3][4]. Um die Fachprozess-Designer
nicht mit vielen Neuerungen zu überfordern, sollten für das jeweilige Projekt
besonders relevanten Aspekte ausgewählt werden, z.B. basierend auf Erfah-
rungen aus früheren Projekten. Dieser Beitrag kann hierbei als Inspiration
bzw. „Checkliste“ dienen.
Literatur
[1] A. Arsanjani, S. Ghosh, A. Allam, T. Abdollah, S. Ganapathy, K. Holley: SOMA: A
method for developing service-oriented solutions. IBM Systems Journal (2008)
[2] T. Bauer: Stellvertreterregelungen für Task-Bearbeiter in prozessorientierten Applikati-
onen. Datenbank-Spektrum (2009)
[3] R. Bobrik, M. Reichert, T. Bauer: Requirements for the visualization of system-
spanning business processes. In: Proc. DEXA'05 Workshops, pp. 948-954 (2005)
[4] R. Bobrik, T. Bauer, M. Reichert: Proviado - personalized and configurable visualiza-
tions of business processes. In: Proc. 7th Int'l Conf. on Electronic Commerce and Web
Technologies (EC-WEB'06), LNCS 4082, Springer, pp. 61-71 (2006)
[5] L. Bodenstaff, A. Wombacher, M. Reichert, M.C. Jaeger: Monitoring Dependencies for
SLAs: The MoDe4SLA Approach. In: IEEE 5th Int'l Conference on Services Compu-
ting (SCC’08), IEEE Computer Society Press, pp. 21-29 (2008)
[6] S. Buchwald, T. Bauer, M. Reichert: Bridging the gap between business process models
and service composition specifications. In: Lee, Ma, Liu: Service Life Cycle Tools and
Technologies: Methods, Trends, and Advances (2012)
[7] S. Buchwald, T. Bauer, M. Reichert: Durchgängige Modellierung von Geschäftsprozes-
sen in einer Service-orientierten Architektur. In: Proc. Modellierung (2010)
[8] S. Buchwald: Erhöhung der Durchgängigkeit und Flexibilität prozessorientierter Appli-
kationen mittels Service-Orientierung. Dissertation, Universität Ulm (2012)
[9] P. Dadam, M. Reichert: The ADEPT project: a decade of research and development for
robust and flexible process support - challenges and achievements. Computer Science -
Research and Development, 23(2): 81-97, Springer (2009).
[10] P. Dadam, M. Reichert, S. Rinderle-Ma: Prozessmanagementsysteme: Nur ein wenig
Flexibilität wird nicht reichen. Informatik-Spektrum, 34(4): 364-376, Springer (2011)
[11] M. Deeg: SOA Fängt weit vor BPEL an – Serviceorientierte Geschäftsprozessmodellie-
rung als Basis für eine SOA. OBJEKTspektrum, Onlineausgabe (2007)
[12] R. Enderle: Frühe fachliche Modellierung ausführungsrelevanter Prozess-Aspekte –
Prozessmodellierung in Zeiten von SOA. Diplomarbeit Universität Ulm (2009)
[13] G. Engels, A. Hess, B., O. Juwig, M. Lohmann, J.P. Richter, M. Voss, J. Willkomm:
Quasar Enterprise: Anwendungslandschaften serviceorientiert gestalten. Dpunkt (2008)
- 25 -
[14] J. Kolb, P. Hübner, M. Reichert: Automatically generating and updating user interface
components in process-aware information systems. In: Proc. 20th Int’l Conf on Coop-
erative Information Systems, LNCS 7565, Springer, pp. 444-454 (2012)
[15] V. Künzle, M. Reichert: Integrating users in object-aware process management sys-
tems: issues and challenges. Proc. BPM'09 Workshops, LNBIP 43, pp. 29-41 (2009)
[16] V. Künzle, M. Reichert: Towards Object-aware Process Management Systems: Issues,
Challenges, Benefits. In: Proc. 10th Int'l Workshop on Business Process Modeling, De-
velopment, and Support (BPMDS'09), LNBIP 29, Springer, pp. 197-210 (2009)
[17] V. Künzle, M. Reichert: PHILharmonicFlows: towards a framework for object-aware
process management. Journal of Software Maintenance and Evolution: Research and
Practice, 23(4): 205-244, Wiley (2011)
[18] A. Lanz, B. Weber, B., M. Reichert: Time patterns for process-aware information sys-
tems. Requirements Engineering Journal, Springer (2013)
[19] M. Lohrmann, M. Reichert: Efficacy-aware Business Process Modeling. In: 20th Inter-
national Conference on Cooperative Information Systems (2012)
[20] M. Lohrmann, M. Reichert: Understanding Business Process Quality. In: Business Pro-
cess Management - Theory and Applications, Studies in Computational Intelligence
444, Springer, pp. 41-73 (2013)
[21] C. Li, M. Reichert, A. Wombacher: Mining business process variants: challenges, sce-
narios, algorithms. Data & Knowledge Eng, 70(5):409-434, Elsevier (2011).
[22] B. Mutschler, M. Reichert, J. Bumiller: Unleashing the effectiveness of process-
oriented information systems: problem analysis, critical success factors and implica-
tions. IEEE Trans on Sys, Man, and Cyb, 38(3): 280-291, IEEE Comp Soc Press (2008)
[23] M. Reichert, B. Weber: Enabling Flexibility in process-aware information systems –
challenges, methods, technologies. Springer (2012)
[24] M. Reichert, P. Dadam, T. Bauer: Dealing with forward and backward jumps in work-
flow management systems. Int'l J Software and Systems Modeling, 2(1): 37-58 (2003)
[25] S. Rinderle, M. Reichert: On the controlled evolution of access rules in cooperative in-
formation systems. Proc CoopIS'05, LNCS 3760, Springer, pp. 238-255 (2005).
[26] S. Rinderle-Ma, M. Reichert: A formal framework for adaptive access control models.
Journal on Data Semantics IX, Springer, LNCS 4, pp. 82-112 (2007)
[27] S. Rinderle-Ma, M. Reichert: Comprehensive life cycle support for access rules in in-
formation systems: the CEOSIS project. Enterprise Inf Systems, 3(3).219-251 (2009).
[28] P. Offermann: SOAM - Eine Methode zur Konzeption betrieblicher Software mit einer
Serviceorientierten Architektur. Wirtschaftsinformatik (2008)
[29] J. Schmitzl: Durchgängige Modellierung von prozessorientierten Anwendungen mit
BPMN 2.0. Diplomarbeit Universität Ulm (2010)
[30] L. Shuster: Project-Oriented SOA. SOA Magazin (2008)
[31] Software AG: ARIS Value Engineering. White Paper (2009)
[32] S. Stein, S. Kühne, J. Drawehn, S. Feja, W. Rotzoll: Evaluation of OrViA framework
for model-driven SOA implementations: an industrial case study. In: Proc. 6th Int.
Conf. on Business Process Management (2008)
[33] B. Weber, S. Sadiq, M. Reichert: Beyond rigidity - dynamic process lifecycle support: a
survey on dynamic changes in process-aware information systems. Computer Science -
Research & Development, 23(2): 47-65, Springer (2009)
[34] I. Weber, J. Hoffmann, J. Mendling, J. Nitzsche, J.: Towards a Methodology for Se-
mantic Business Process Modeling and Configuration. In: Proc. 2nd Int. Workshop on
Business Oriented Aspects concerning Semantics and Methodologies in Service-
oriented Computing (2007)
- 26 -
