"An dieser Stelle möchte ich allen aufrichtig danken, die mich während der

Schaffung meiner Diplomarbeit unterstützt haben. Damit meine ich nicht nur

den unschätzbaren fachlichen Rat meiner Arbeitskollegen und Freunde, sondern

auch die moralische Unterstützung meiner Eltern, meiner Geschwister, meiner

ganzen Familie und meiner Laura."

Inhaltsverzeichnis

Inhaltsverzeichnis   3

Kapitel  1 - Einleitung  7

1.1  Motivation  7

1.2  Grundbegriffe  8

1  3 B Business-Prozess / Geschäftsprozess  9

   1.2.1

1  4 B Workflows  9

   1.2.2

1  5 B Workflow Management System (WfMS)  10

   1.2.3

1  6 B Abarbeitung und Steuerung von Workflows  14

   1.2.4

1.2.5  Korrektheit  16

1  7 B Erfahrungsmanagement  17

   1.2.6

1.3  Technologische Grundlagen  18

1  8 B Agilität in Workflows  18

   1.3.1

1  9 B Fallbasiertes Schließen  20

   1.3.2

1.4  Ziel dieser Arbeit  24

1.5  Aufbau dieser Arbeit  26

Kapitel  2 - Ähnliche Forschungsansätze  27

2.1  AdaptFlow  27

2.2  CODAW  27

2.3  CBRFlow  28

2.4  Phala  29

2.5  Bewertung der Systeme  29

Kapitel  3 - Die CAKE Systeme  31

3.1  CAKE I  31

3.1.1  Architektur  32

3.1.2  Datenmodell  33

3.1.3  Ähnlichkeitsmodell  36

3.2  CAKE II  37

3.2.1  Architektur  37

3.2.2  Die CAKE Modellierungssprache  38

3.2.3  Konsistenz von Workflows  41

3.2.4  Das CAKE Statusmodell  42

3.2.5  Abarbeitung von Workflows  43

3.2.6  Anhalten von Workflows  45

3.3  CAKE III  47

3.3.1  Integration der CAKE Systeme  47

Kapitel  4 - Konzeptentwicklung  49

4.1  Anforderungsanalyse  49

4.1.1  Szenarien  49

4.1.2  Anforderungen an den Adaptionsprozess von Workflows  53

4.1.3  Anforderungen an die Repräsentation von Fällen.  53

4.2  Fallrepräsentation  54

4.2.1  Das Retrievalformat für Workflows  56

4.2.2  Die ADD- und DELETE-Listen  58

4.3  Der Adaptionsprozess  60

4.3.1  Der Adaptionszyklus  60

4.3.2  Setzen von Breakpoints  63

4.3.3  Das Retrieval von Adaptation Cases  64

4.4  Das Ankerprinzip  65

4.4.1  Das Lokalisierungsproblem  65

4.4.2  Adaptionsalgorithmen.  69

4.4.3  Beispiel einer Workflow Adaption  71

4.5  Evaluation der Adaptionsalgorithmen  74

4.6  Beurteilung und Zusammenfassung  77

Kapitel  5 - Umsetzung des Konzeptes  78

5.1  Voruntersuchungen  78

5.1.1  Performanztest von CAKE I  78

5.1.2  Untersuchung von Kochprozessen  80

5.2  Erweiterung von CAKE I  83

5.2.1  Implementierung der Fallrepräsentation  83

5.2.2  Implementierung des Retrievalformats für Workflows  85

5.2.3  Implementierung der ADD- und DELETE-Listen  89

5.3  Der Adaptation Manager  91

5.4  Die Interaktion der CAKE Systeme  93

5.5  Implementierung des CAM Algorithmus  98

5.6  Zusammenfassung und Beurteilung  103

Kapitel  6 - Schlussbemerkungen  104

Anhang   107

Anhang 1  - XML Schema für Adaptation Cases  107

Anhang 2  - CAKE III Sequenzdiagramm einer automatischen Adaption  111

Anhang 3  - XSLT zur Erzeugung des Retrieval Formats für Workflows  112

Anhang 4  - Pseudocode des Composite Anchor Mappings  114

Abbildungsverzeichnis   117

Literaturverzeichnis   119

Kapitel 1 - Einleitung

1.1 Motivation

Die Menschheit hat vor 200 Jahren einen Prozess begonnen, der unsere Gesellschaft bis heute prägt und sich ständig zu beschleunigen scheint. Die Rede ist von Arbeitsteilung und Arbeitseffizienz durch Technik mit Beginn der industriellen Revolution. Arbeitsteilung und Arbeitseffizienz sind zwei der wesentlichsten Faktoren, die darüber entscheiden, ob ein Unternehmen am Markt überlebensfähig ist. Ein wachsender Wettbewerb innerhalb einer Branche erfordert von Unternehmen eine genauere Betrachtung ihrer Organisationsstruktur und der darin enthaltenen Arbeitsabläufe. In klassischen Branchen, wie der Autobranche oder Stahlindustrie herrscht für Arbeitsabläufe schon lange ein hoher Grad der Formalisierung. Ganz anders sieht es dagegen bei Dienstleistern aus. Kosten und Arbeitseffizienz lassen sich bei Dienstleistungen oft nur schwer kalkulieren. Dieses Problem gewinnt immer mehr an Bedeutung, da der Großteil der Gründungen der letzten Jahre im Dienstleistungssektor stattfand ¹ . Darüber hinaus ist es für Dienstleistungsunternehmen schwieriger, eine gleichbleibende Qualität an ihre Kunden zu liefern, wenn es keine Standardisierung für die erbrachte Dienstleistung gibt. Ein Unternehmen hat einen Vorteil gegenüber seinen Mitbewerbern, wenn es in der Lage ist, das Wissen über seine Arbeitsabläufe zu formalisieren, sodass es in der Organisation verbleibt und auch an neue Mitarbeiter weitergegeben werden kann. Neben Produktionsabläufen existiert in einer Organisation eine Vielzahl verborgener Prozesse, die die interne Kommunikation steuern und aufrechterhalten. Diese Abläufe in einer Organisation sind häufig unstrukturiert, da sie nicht explizit bekannt sind und somit nicht von allen Mitarbeitern auf Anhieb verstanden werden können. Um nun wettbewerbsfähiger zu werden, haben viele Unternehmen begonnen, ihre eigenen Prozesse festzuhalten, zu formalisieren und zu optimieren. Nicht selten wird dabei versucht „Best Practice“ Abläufe der Branche im eigenen Unternehmen zu verankern, um wettbewerbsfähig zu bleiben. Für viele kleine und mittelständische Unternehmen bedeutet das Überschreiten einer gewissen Größe einen Wandel des Aufgabenbereichs der Führung; weg von ausführenden hin zu planenden Aufgaben. Solche Unternehmen im Mittelstand werden bspw. durch die UPTODATE-Offensive1 F ² unterstützt. Die UPTODATE-Offensive hilft Handwerksunternehmen ihr

¹ Laut KfW Gründungsmonitor machte allein 2009 der Anteil der Gründungen im Dienstleistungssektor 86% aus.

² Für nähere Informationen: http://www.profi-im-handwerk.de

S e i t e | 7

Einleitung / Grundbegriffe

Wachstum zu bewältigen, indem standardisierte Prozesse im Unternehmen etabliert werden. Größere Unternehmen nutzen zur Betreuung ihres Kundenstamms häufig die „Best Practice“ Vorschläge aus der „Information Technology Infrastructure Library“(ITIL). ITIL stellt eine Sammlung von Leitfäden dar, die bewährte, aus der Praxis gewonnene Erkenntnisse, Modelle und Architekturen beschreibt, die als Richtlinie zum systematischen Aufbau und zum Betrieb einer durchgängig abgestimmten IT-Servicestruktur benutzt werden kann [Ol04].

Die Bedeutung der Prozessorganisation von Unternehmen wird in den kommenden Jahren nicht nur erhalten bleiben, sondern größer werden. Denn die Gründe, die zu einer intensiveren Auseinandersetzung mit den Prozessen geführt haben, werden nicht wegfallen, sondern sich eher noch verstärken [Wi07]. Diese Arbeit beschäftigt sich mit dem Problem, dass solche etablierten und standardisierten Prozesse fehlerhaft sein können oder geändert werden müssen, weil sich Umweltbedingungen geändert haben. Unerwartete Fehler können immer in Prozessen auftreten, unabhängig davon, ob es ein selbst erstellter oder übernommener Prozess ist. Der hier vorgestellte Forschungsansatz unterstützt den Prozessmodellierer, indem Prozesse automatisch von einem System sowohl zur Laufzeit als auch während der Modellierung geändert werden können. Dazu wird eine Methode aus einem Teilgebiet der künstlichen Intelligenz verwendet, die später genauer erklärt wird.

1.2 Grundbegriffe

Um die nächsten Kapitel und insbesondere die technologischen Grundlagen dieser Arbeit nachvollziehen zu können, ist es notwendig einige Begriffe zu verstehen. Die Abarbeitung von Prozessen wird dazu erläutert, beginnend auf einer eher abstrakten Beschreibungsebene bis hin zur technischen Realisierung. Die abstrakte Beschreibungsebene ist für die betriebswirtschaftliche Sicht interessant, da sie der Führung eines Unternehmens hilft, in einem ersten Schritt die Prozesse zu begreifen und darauf aufbauend Entscheidungen zu treffen. Auf der anderen Seite ist das Verständnis für die technische Realisierung und Abarbeitung eines Prozesses unerlässlich, um den Forschungsansatz in dieser Arbeit zu begreifen und analysierte Probleme zu verstehen. Neben der Prozessthematik und ihrer technischen Realisierung wird der Begriff des Erfahrungsmanagements näher beschrieben, um ihn in den darauf folgenden technologischen Grundlagen fassbarer zu machen.

8 | S e i t e

Einleitung / Grundbegriffe

1.2.1 1 3 B Business-Prozess / Geschäftsprozess

Ein Prozess, der sich auf ein Unternehmen und dessen Geschäftsziele bezieht, wird als Business-Prozess (Synonym zu Geschäftsprozess) bezeichnet. In der Literatur herrscht keine einheitliche Definition des Begriffes Geschäftsprozess [RvHS04]. So definieren Aalst und Hee Kees einen Geschäftsprozess als:

„Ein Geschäftsprozess ist ein Prozess, der auf die Produktion bestimmter Produkte abzielt. Diese Produkte können physischer Natur oder auch weniger fassbar sein, wie ein Design, ein Rezept oder eine Bewertung. Mit anderen Worten, das Produkt kann ebenso ein Service sein.“ [vdAvHK04, S.346, eigene Übersetzung]

Aalst und Hee Kees erwähnen in ihrer Definition bereits explizit, dass sich ein Prozess auch auf immaterielle Güter und Produkte außerhalb eines betrieblichen Kontextes beziehen kann. So ist der Entwurf eines Designs oder das Kochen eines Rezeptes vielmehr ein kreativer Akt, dessen Rahmenablauf prozedural beschrieben werden kann. Die tatsächliche Ausführung des Prozesses weicht jedoch häufig vom ursprünglichen Prozess ab. Eine etwas andere Sicht auf einen Geschäftsprozess wird von der Workflow Management Coalition2 F ³ (WfMC) getroffen. Sie widerspricht nicht der Definition von Aalst und Hee Kees und kann als eine Erweiterung ihrer Definition angesehen werden. Sie erweitert die Definition von Aalst und Hee Kees um eine Organisationsstruktur, die für eine Arbeitsteilung im Prozess notwendig ist:

Ein Geschäftsprozess ist „eine Menge von einer oder mehreren Prozeduren oder Aktivitäten, die gemeinsam ein Geschäftsziel oder eine Geschäftsstrategie verwirklichen. Normalerweise geschieht dies im Kontext einer Organisationsstruktur, in der funktionale Rollen und Beziehungen definiert werden müssen.“ [Fi07, S.18, eigene Übersetzung]

1.2.2 1 4 B Workflows

„Bei einem Workflow handelt es sich um die automatische Abarbeitung - im Ganzen oder in Teilen - eines Business-Prozesses. Während dieser Abarbeitung werden Dokumente, Informationen oder Aufgaben von einem Teilnehmer an einen anderen Teilnehmer weitergereicht, um Aktionen auszuführen, die einer Menge prozeduraler Regeln entsprechen.“ [Fi07, S.18, eigene Übersetzung]

Ein Workflow kann also als Pendant zum Business-Prozess auf der technischen Ebene verstanden werden, in der ein (Business-)Prozess maschinell ausgeführt wird. Die

³ Die Vereinigung wurde 1993 gegründet und hat sich zum Ziel gesetzt ein Referenzmodell für Workflow Management Systeme zu entwickeln, sodass Module unterschiedlicher Hersteller, wie z.B. Bedienoberflächen für Modellierungswerkzeuge, miteinander verknüpft und betrieben werden können. Zu den bekanntesten Mitgliedern gehören unter anderem Fujitsu und NEC.

S e i t e | 9

Einleitung / Grundbegriffe

Abarbeitung wird ermöglicht, in dem ein vorgegebenes (Teil-)Ziel aus einem Prozess in einzelne, logisch abgeschlossene Arbeitsschritte zerlegt wird. Diese abgeschlossenen Arbeitseinheiten werden als Tasks bezeichnet. Handelt es sich bei einem Workflow um einen ausgeführten Prozess im Sinne von Aalst und Hee Kees, so lassen sich unterschiedliche Alltagssituationen finden, die Merkmale von Prozessen aufweisen. Kochen ist sicherlich nicht das typischste Beispiel für einen Prozess, trotzdem weißt es alle Merkmale eines Prozesses auf: Unterschiedliche Aufgaben/Tasks müssen in einer bestimmten Reihenfolge abgearbeitet werden, damit ein bestimmtes Ziel, die Speise, erreicht werden kann. Modellierte Beispiele aus der Kochdomäne werden später wegen ihrer eigenen Komplexität genauer betrachtet werden.

1.2.3 1 5 B Workflow Management System (WfMS)

Ein WfMS ist von der Workflow Management Coalition (WfMC) definiert als „ein System, das die Ausführung von Workflows definiert, erzeugt und kontrolliert. Die dabei benutzte Software läuft auf einer oder mehreren Workflow Engines, die in der Lage sind Prozess-Definitionen zu interpretieren, mit den Benutzern des Workflow-Systems zu interagieren und wo notwendig auch IT-Tools und Anwendungen aufzurufen.“ [WFMC08, S.9, eigene Übersetzung]

Ein Workflow Management System lässt sich nach obiger Definition in drei funktionale Bestandteile aufteilen [Mü05]:

• Die „build time“ - Definieren des Workflows.

• Die “run time process control” - Erzeugen des Workflows.

• Die “run time activity interaction” - Kontrollieren des Workflows.

Im klassischen Workflow Management gehört die Trennung zwischen „build time“ und „run time“ zu den wesentlichen Bestandteilen [We07]. Während der „build time“ eines Workflows wird ein Workflow-Modell vollständig spezifiziert. Normalerweise wird dabei ein grafisches Tool zur Modellierung genutzt. Workflow-Modelle - im Folgenden Workflow Definitionen genannt - sind die Vorlage für die Ausführung eines Business-Prozesses im WfMS. Workflow Definitionen müssen im Einklang mit dem Business-Prozess sein und erweitern diesen um technische Informationen, die notwendig sind, um den Workflow später auszuführen. Ist die Workflow Definition erstellt und entspricht sie dem Anforderungsprofil des Geschäftsprozesses, so ist die „build time“ eines Workflows abgeschlossen. Die so erstellten Workflow Definitionen können geordnet abgespeichert werden, um später z. B. Projekten zugeordnet zu werden.

Sobald eine Workflow Definition gestartet wird, erzeugt das Workflow Management System von ihr eine Kopie, die als Workflow Instanz bezeichnet wird. Mit Anlegen der

10 | S e i t e

Einleitung / Grundbegriffe

Workflow Instanz beginnt die „run time process control“-Phase (kurz „run time“). Die Workflow Definition dient also als Vorlage, von der es mehrere laufende Instanzen geben kann. Die Workflow-Instanz ist eine spezifische interne Repräsentation, die das WfMS nutzt, um den Workflow auszuführen [Mü05].

Die „run time activity interaction“ sorgt dafür, dass Benutzer und System während der Laufzeit von Instanzen miteinander interagieren können [Mü05].

Für die Entwicklung eines Workflow Management Systems existiert ein Referenzmodell (siehe Abbildung 1), das von der WfMC entworfen wurde. Es umfasst dabei fünf Komponenten, von denen vier für diese Arbeit als wesentlich angesehen werden können:

• Tools zur Modellierung von Workflow Definitionen (Interface 1).

• Monitoringtools um aktive Workflows zu untersuchen und ggf. Fehler

aufzuspüren (Interface 5).

• Der „Worklist Handler“, der Aufgaben automatisch an Mitarbeiter delegiert

und das Fortschreiten des Workflows sicherstellt (Interface 2).

• Die Kernkomponente „Workflow Enactment Service“.

Einleitung / Grundbegriffe

Diese Arbeit beschäftigt sich in erster Linie mit Workflows, in denen Menschen miteinander arbeiten und interagieren. Aus diesem Grunde steht das Aufrufen externer Anwendungen (Interface 3) nicht im Mittelpunkt. Ist in späteren Kapiteln die Rede von Tasks, so kann davon ausgegangen werden, dass es sich um Tasks handelt, die von Menschen ausgeführt werden müssen. Das WfMS interagiert über seine Schnittstellen/Interfaces permanent mit unterschiedlichen Nutzergruppen. Personen, deren Sicht durch das WfMS darauf beschränkt ist, dass sie neue Aufgaben zu verrichten haben, werden als Workflowteilnehmer bezeichnet. Dabei handelt es sich in der Regel um normale Mitarbeiter innerhalb einer Organisationsstruktur. Um den Mitarbeitern Aufgaben zuzuordnen, wird der sog. „Worklist Handler“ (Interface 2) eingesetzt. Im einfachsten Fall wird ein Mitarbeiter per E-Mail darüber informiert, dass eine neue Aufgabe ansteht. Komplexere „Worklist Handler“ können als Browseranwendung entworfen werden, die benutzerspezifische To-do-Listen generieren (siehe Abschnitt 3.2.1). Neben den Workflowteilnehmern existiert noch eine weitere Benutzergruppe innerhalb des WfMS. Diese Gruppe beschäftigt sich mit der Modellierung von Workflows und wird aus diesem Grunde auch als Workflowmodellierer bezeichnet. Die Aufgabe des Workflowmodellierers besteht darin Prozesse seiner Umwelt, z. B. in einem Unternehmen, zu erkennen und diese mittels eines Workflows zu formalisieren. Der Workflowmodellierer sieht die Abarbeitung des Workflows aus einer anderen Perspektive (Interface 1) als der Workflowteilnehmer. Während der Workflowteilnehmer nur die Aufgaben sieht, die er durchführen soll, besitzt der Workflowmodellierer das Wissen über den gesamten Workflow, das z. B. den Abarbeitungsstand des Workflows oder aufgetretene Probleme umfasst. Diese abstraktere Sicht auf den ganzen Workflow ermöglicht es dem Workflowmodellierer auch administrative Tätigkeiten auszuüben, die durch die Schnittstelle zu Monitoringtools (Interface 5) unterstützt werden.

Das Herzstück eines WfMS ist der „Enactment Service3 F 4 “. Er kümmert sich um das Erzeugen und Starten von Workflows. Er beinhaltet die Logik, wie der Workflow auszuführen ist (siehe Abschnitt 1.2.4) und sorgt während der Ausführungsphase dafür, dass sowohl die Konsistenz als auch die Persistenz des Workflows gewahrt bleibt. Um die Persistenz zu wahren, muss der „Enactment Service“ garantieren, dass keine Daten während eines Stromausfalls verloren gehen. Ein Mangel an Persistenz würde zu inkonsistenten Workflows führen. Ein Beispiel für Inkonsistenz in Workflows wären strukturelle Mängel, die Teile des Workflows unerreichbar machen.

⁴ Synonym zu „Process Execution Environment“ [WFMC08]

12 | S e i t e

Es ist nun ersichtlich, wie die vier vorgestellten Komponenten des Referenzmodells die drei funktionalen Bestandteile eines WfMS unterstützen (siehe Abbildung 2). Während der „build time“ setzt sich der Workflowmodellierer mit der Analyse eines Prozesses (Business Process Analysis) auseinander und nutzt dafür ein Tool zur Modellierung von Workflow Definitionen (Modelling & Definition Tools). Die erstellte Workflow Definition wird dann während der „run time“ vom „Enactment Service“ gestartet und gesteuert. Treten Probleme während der Ausführung des Workflows auf, so sollte es möglich sein den Workflow zu stoppen und wieder zurück in die „build time“ zu bringen. Dass dies bei heutigen WfMS in der Regel noch nicht möglich ist, ist in Abbildung 2 durch einen gestrichelten Pfeil zwischen „Enactment Service“ und „Process Definition“ symbolisiert. In Abschnitt 1.3.1 werden Techniken vorgestellt, die diese Rückkopplung ermöglichen. Die Interaktion des „Enactment Service“ mit den Workflowteilnehmern und Workflowmodellierern führt zur „run time activity interaction“, die den „Enactment Service“ kontinuierlich mit Steuerungssignalen wie „Aufgabe beendet“ oder „Aufgabe kann nicht erfüllt werden“ versorgt. Dabei können die Workflowteilnehmer zur Erfüllung ihrer Tätigkeiten auch auf externe Programme (Applications & IT Tools) zugreifen. Falls ein WfMS direkt über einen Workflow mit externen Anwendungen (Interface 3) kommuniziert, wären die externen Programme ebenso direkter Bestandteil der „run time activity interaction“.

Einleitung / Grundbegriffe

1.2.4 1 6 B Abarbeitung und Steuerung von Workflows

Workflows können auf verschiedenartige Weise dargestellt werden. Die Repräsentation basiert auf der Modellierungssprache, die das Tool zur Workflowmodellierung bereitstellt. Die Formulierung des Workflows muss dabei nicht in graphischer (prozeduraler) Form geschehen, sondern kann auch deklarativ beschrieben werden [vdAP06]. Die deklarative Beschreibung eines Workflows ist allerdings ungeeignet, wenn Workflows kommunizierbar bleiben sollen. Gängige Standards zur Modellierung von Workflows (z. B. BPMN4 F ⁵ ) sind graphorientiert. Daher wird die Funktionsweise des „Enactment Service“ in dieser Arbeit auf prozedurale Beschreibungen beschränkt. Um einen Workflow als Graph zu beschreiben, existieren mehrere Möglichkeiten. Eine der ersten Formen, die auch eine maschinelle Verarbeitung ermöglicht, geht auf Petri-Netze zurück [vdA98]. Der Übergang in einem Petri-Netz von einem Zustand in einen anderen wird dabei als „Feuern“ (im Englischen als „enable“) bezeichnet [WP08]. Für die Konstruktion heutiger Workflows existieren zwei graphbasierte Modellierungsansätze, die sich im Wesentlichen dadurch unterscheiden was ein „Feuern“ und somit einen neuen Zustand des Workflows auslöst. Das sind zum einen datengetriebene („data driven“) Workflows und zum anderen Kontrollfluss getriebene („control flow driven“) Workflows [TDG07].

In einem datengetriebenen Workflow spezifizieren die Verbindungen zwischen Tasks die Abhängigkeit von Daten. Eine eingehende Verbindung bedeutet, dass der Task Daten benötigt, die von einem anderen Task produziert werden. Diese Abhängigkeit von Daten zur Zustandsänderung eines Workflows erhöht die Nebenläufigkeit in einem Workflow. Die Ausführung des Workflow stoppt erst, wenn es einen Task gibt, der aufgrund einer nicht erfüllten Abhängigkeit blockiert wird und es keinen anderen Task mehr gibt, der ausgeführt werden kann [TDG07]. Datengetriebene Workflows kommen häufig in Anwendungsfeldern zum Einsatz, in denen digitale Eingangssignale verbunden werden, um Geräte zu testen [TDG07]. Ein populäres neues Forschungsfeld, in dem häufig datengetriebene Workflows genutzt werden, ist e-Science [TDG07]. E-Science versucht die Forschungsgemeinde dahingehend zu unterstützen, dass Experimente standardisiert ablaufen und wiederholt werden können. Ein Beispiel für einen e-Science Workflow wäre ein kompliziertes Experiment zur Herstellung eines neuen Medikaments, an dem viele Personen über einen langen Zeitraum beschäftigt sind. Es ist möglich, dass einige chemische (Teil-)Produkte unabhängig voneinander hergestellt werden können, während andere Forscher ihre Arbeit erst erledigen können, wenn bestimmte Zwischenprodukte erzeugt wurden. Eine datengetriebene Workflowmodellierung

⁵ BPMN steht für Business Process Modeling Notation und wurde von der Business Process Management Initiative entwickelt. Der Standard ist aktuell implementiert unter anderem in Tools von Borland, Fujitsu, IDS-Scheer und SAP [OMG]

14 | S e i t e

Einleitung / Grundbegriffe

verkürzt die Dauer des Experiments, da viele Forscher Teile des Experiments gleichzeitig ausführen können, ohne dass dabei Abhängigkeiten verletzt werden.

Wird ein Workflow von einem Kontrollfluss gesteuert, so werden Tasks im einfachsten Fall sequenziell abgearbeitet. Um komplexere Prozesse abbilden zu können, verfügen Modellierungssprachen, die auf einem Kontrollfluss basieren, über Konstrukte, um die Abarbeitungsreihenfolge festzulegen. Aalst untersucht in seiner Arbeit über Workflow Patterns [vdA03] Kontrollstrukturen, die genutzt werden können, um einen Kontrollfluss zu steuern. Drei dieser Patterns/Kontrollstrukturen sind in Abbildung 3 in Form von BPMN dargestellt. Das Loop-Konstrukt erlaubt es einen Subgraph des Workflows iterativ auszuführen, bis ein Abbruchkriterium die Iteration beendet. Das AND-Konstrukt verzweigt den Kontrollfluss und erlaubt damit eine parallele Verarbeitung von Aufgaben. Nach Abarbeitung aller Tasks im AND-Konstrukt wird eine Synchronisation erzwungen, sodass der Kontrollfluss wieder sequenziell weiterlaufen kann. Das XOR-Konstrukt verzweigt den Kontrollfluss genauso wie das AND-Konstrukt mit dem Unterschied, dass nur ein Zweig ausgeführt wird. Die Auswahl des Zweiges geschieht durch eine zuvor definierte Vorbedingung.

Der Workflow in Abbildung 3 ermöglicht eine iterative Ausführung von Task A und Task B. Nach Beendigung des Loops werden Task C, D und E parallel ausgeführt und der Workflow verlässt das AND erst, wenn Task C, D und E beendet wurden. Danach wird im XOR gewählt, ob Task F, G oder H ausgeführt werden soll. Obwohl Aalst in [vdA03] noch weitere Kontrollstrukturen nennt, die eine größere Ausdrucksmächtigkeit ermöglichen

Einleitung / Grundbegriffe

würden, lässt sich mit Hilfe dieser drei Kontrollstrukturen normalerweise jeder Geschäftsprozess ausdrücken [HJM04]F ⁶ . Dabei handelt es sich jedoch um Konstrukte, die eher in Spezialfällen nützlich wären, als in allgemeinen Anwendungsgebieten. Im Folgenden werden alle Elemente in einem Kontrollfluss als Workflowelemente bezeichnet. Soll die Modellierungssprache kommunizierbar bleiben, muss ein Kompromiss zwischen Ausdrucksmächtigkeit und Komplexität der Modellierungsprache gefunden werden.

Diese zwei Typen zur Abarbeitung und Steuerung von Workflows sind zueinander ähnlich, da sie eine Interaktion zwischen zwei individuellen Aktivitäten definieren, sie unterscheiden sich aber in der Art und Weise, wie diese Interaktion implementiert ist. In Kontrollfluss getriebenen Workflows bedeutet die Verbindung zwischen zwei Aktivitäten, dass die nachfolgende Aktivität erst ausgeführt werden kann, wenn die vorherige Aktivität beendet ist. Datengetriebene Workflows werden eingesetzt, wenn Daten die Reihenfolge der Abarbeitung bestimmen. Die Abhängigkeiten von Aktivitäten werden hier durch den Datenfluss zwischen Produzent und Verbraucher der Daten beschrieben. Die erhöhte Nebenläufigkeit in datengetriebenen Workflows erfordert jedoch auch ausgeklügelte Transaktionskonzepte, die die Konsistenz des Workflows sicherstellen. Von großer Bedeutung ist hier die Abwägung zwischen der Wahrung der Flexibilität der Ausführung und notwendigem Einschränken durch Transaktionen [SW02].

1.2.5 Korrektheit

Bei der Modellierung kleiner Workflows, die nur aus wenigen Tasks bestehen, ist es recht einfach Fehler aufzuspüren. Mit wachsender Komplexität eines Workflows, steigendem Synchronisationsaufwand und der Anzahl der Bedingungen in einem Workflow wird die Verifikation eines Workflows immer schwieriger [Sa97]. Die Fehlerfreiheit und somit Korrektheit eines Workflows lässt sich dabei in syntaktische und semantische Korrektheit unterteilen. Um die syntaktische Korrektheit eines Workflows zu überprüfen, bedarf es keiner Metainformationen über die Tasks oder ihrer Kontrollstrukturen. In [Sa97] werden fünf Typen syntaktischer Fehler klassifiziert:

• „Incorrect Usage“, z. B. wenn ein AND nur eine Sequenz beinhaltet, die

synchronisiert werden soll.

• „Deadlocks“, z. B. wenn eine Synchronisation unmöglich wird, da die

eingehenden Sequenzen sich gegenseitig ausschließen.

• „Livelocks“, z. B. wenn ein Loop keine Abbruchbedingung beinhaltet.

⁶ In [HJM04] wird statt von einem XOR-Pattern von einem Preference-OR-Pattern gesprochen, das semantisch jedoch das Gleiche meint.

16 | S e i t e

Einleitung / Grundbegriffe

• „Unintentional Multiple Execution“, z. B. wenn es erlaubt ist, dass ein Task

• „Active Termination“, z. B. wenn mehrere Endpunkte eines Workflows

In Abschnitt 3.2.3 wird beschrieben wie die CAKE-Modellierungssprache mit diesen syntaktischen Fehlern umgeht.

Semantische Fehler entstehen, wenn bereits der Business-Prozess, der die Grundlage für den Workflow darstellt, fehlerhaft ist [Sa97]. Um die semantische Korrektheit eines Workflows zu überprüfen, werden domänenspezifische Metainformationen benötigt, um spezifizierte Tasks und Bedingungen inhaltlich zu verstehen. Eine syntaktische Korrektheit garantiert noch keine semantische Korrektheit. Ein Beispiel: Es existiert ein XOR mit der Auswertungsvariablen x. Das XOR besitzt zwei ausgehende Sequenzen. Sequenz A wird ausgeführt, wenn x den Wert 1 annimmt, Sequenz B wird ausgeführt, wenn x den Wert 2 annimmt. Die Bedingung im XOR mag syntaktisch korrekt sein, aber falls der Modellierer nicht bedacht hat, dass x auch den Wert 3 annehmen kann, so führt dieser semantische Fehler ebenfalls zu einem Deadlock und der Workflow wird nie einen Endzustand erreichen.

1.2.6 1 7 B Erfahrungsmanagement

Der menschliche Problemlösungsprozess basiert im Wesentlichen auf strategischem Denken, dessen Grundlage Erfahrungen sind. Insbesondere erfahrene Personen, zu denen natürlich auch Experten gehören, sind in der Lage Zusammenhänge zwischen Vergangenem und Ereignissen der Gegenwart herzustellen [Gö09]. Ein Experte zeichnet sich durch umfangreiches Wissen, erfolgreiches Vorgehen beim Erkennen und Bearbeiten von Problemen, Effizienz, Fehlerfreiheit und Flexibilität gegenüber neuen Problemsituationen aus [Hu02]. Es ist also die Expertise in einer Organisation, die als eine der wertvollsten Ressourcen genutzt werden kann, damit ein Unternehmen erfolgreich ist. Aus diesem Grunde setzen fast alle großen Unternehmen IT-gestützte Systeme ein, um das erlangte Wissen zu finden, zu erforschen und festzuhalten. Dies wird als Wissensmanagement bezeichnet [Be02]. Erfahrungsmanagement ist eine besondere Form des Wissensmanagements, die sich darauf beschränkt, spezifisches Wissen aus einem einzelnen Problemfall zu verwalten. Erfahrungsmanagement bezieht sich auf das Sammeln, Modellieren, Speichern, Wiederverwenden, Evaluieren und Bewahren von Erfahrungen [Be02].

S e i t e | 17

Einleitung / Technologische Grundlagen

Die Trennung zwischen allgemeinem Wissen und Erfahrungswissen ist nicht immer klar zu ziehen und hängt wohl auch mit der Frage zusammen, wie stark der Kontextbezug von Erfahrungen als allgemeines Wissen angesehen wird. So schreiben Althoff et al. In [AlthoffEtAl01], dass der Hauptunterschied zwischen der Anwendung von allgemeinem Wissen und Erfahrungswissen darin besteht, dass Erfahrungswissen dort zum Einsatz kommt, wo kontinuierlich Wissen benötigt wird. Der benötigte, kontinuierliche Wissensstrom wäre dann also so groß und mit wechselnden Anforderungen, dass er sich gar nicht als allgemeines Wissen formalisieren ließe. Minor in [Mi06] meint dagegen, dass Erfahrungswissen einen Gegensatz zu allgemeinem, regelbehaftetem Wissen darstellt, da Erfahrungswissen durch seinen Kontextbezug problemspezifischer ist.

Für die Leistungsfähigkeit einer intelligenten Organisation, die einen Bedarf nach einem problemspezifischen und kontinuierlichen Wissensstrom hat, ist es von besonderem Interesse, ob die Strukturiertheit von verfügbarem und gespeichertem organisationalem Wissen die Fähigkeit zum Lösen spezifischer Problemstellungen erhöht und damit zur Steigerung der Leistungsfähigkeit der Organisation beitragen kann [Hu02]. In Abschnitt 1.3.2 wird eine Technik vorgestellt, die sich in der Praxis bewährt hat, um Erfahrungswissen zu verwalten.

1.3 Technologische Grundlagen

1.3.1 1 8 B Agilität in Workflows

Agilität, d. h. Flexibilität, in Workflows ermöglicht die Anpassung von laufenden Workflows. Der Bedarf nach flexiblen Workflows geht einher mit dem Wandel der Unternehmenslandschaft hin zur Tertiärisierung und dem Bedarf nach prozess-orientierten Organisationen [Wi07]. Es ist immer öfter erforderlich, dass Prozesse auch flexibel sein können. Die Notwendigkeit einen laufenden Prozess zu ändern, tritt vor allem bei Prozessen auf, die über einen langen Zeitraum (Wochen oder Monate) laufen. Diese sog. „long-term“ Workflows unterliegen häufig externen Einflüssen. So erfordert der Rechtsstreit um die Vorratsdatenspeicherung von Internet Service Provider wie der Telekom eine ständige Anpassung ihrer Prozesse, da sie sich an geltendes Recht anpassen müssen. Neben sich ändernden Rahmenbedingungen können ebenfalls unvorhersehbare Störfälle eintreten. In Krankenhäusern werden Patienten nach genormten Workflows, den klinischen Pfaden, behandelt. Diese klinischen Pfade werden für eine Kostenträgerrechnung herangezogen. Bleibt man bei klinischen Aufgabenstellungen, so stelle man sich vor, ein Antibiotikum wirke nicht aufgrund einer Resistenz

18 | S e i t e

Einleitung / Technologische Grundlagen

des Bakterienstammes. Dann muss der Workflow angepasst werden und bspw. ein anderes Antibiotikum verabreicht werden. Die Ursache solcher Änderungen, die die Anpassung eines Workflows erforderlich machen, wird im Folgenden als „Exception“ bezeichnet. Der Begriff soll dabei nicht als „Exception“ im Sinne eines Fehlers verstanden werden, wie ihn Russell et al. [RvdAH06] verwendet. Hier soll als Exception jeder Umstand gemeint sein, der es erforderlich macht eine laufende Instanz zu ändern.

Der Grad an Agilität eines WfMS kann daran abgeschätzt werden, welche Agilitätstypen unterstützt werden. Für Workflow Instanzen, die von einer Workflow Definition abgeleitet wurden, kann Agilität in drei unterschiedliche Arten klassifiziert werden [MSB08]:

• Ad-hoc Änderungen.

• „Schema Evolution“.

• Eine hierarchische Dekomposition mittels „Late Modelling“ oder „Late

Binding“.

Die hierarchische Dekomposition [MSB08] eines Workflows erlaubt es, dass von einer Workflow Definition bereits Instanzen abgeleitet werden können, ohne dass die Workflow Definition dabei vollständig spezifiziert sein müsste. Dazu werden in der Definition Platzhalter eingefügt, die zu einem späteren Zeitpunkt mit einem Sub-Workflow gefüllt werden können. „Late Binding“ bedeutet in diesem Zusammenhang, dass in dem Platzhalter zur „build time“ mehrere Sub-Workflows hinterlegt werden, von denen einer zur Laufzeit ausgewählt werden kann. „Late Modelling“ geht noch einen Schritt weiter und erlaubt es den Platzhalter auch während der „build time“ leer zu halten, wodurch eine freie Modellierung zur Laufzeit ermöglicht wird. Erst wenn der Platzhalter ausgeführt werden soll, wird eine situationsgerechte Spezifikation notwendig, ohne dabei aus einer vorgegebenen Menge aus Workflowfragmenten wählen zu müssen. Der Begriff der hierarchischen Dekomposition verdeutlicht, dass die Tasks in einem Workflow für Subgraphen stehen können und somit ein hierarchisches Geflecht entsteht.

Schema Evolution [RRD03] erlaubt die Änderung von Workflow Instanzen über eine Anpassung der Workflow Definition, von der sie abgeleitet wurden. Änderungen an einer Workflow Definition führen dazu, dass die vorgenommene Korrektur an alle abgeleiteten Workflow Instanzen propagiert wird. Dieser Mechanismus muss dafür sorgen, dass keine Instanzen geändert werden, deren Ausführungsstatus eine Modifikation unmöglich macht oder die durch Ad-hoc Änderungen so abgewandelt wurden, dass die Änderung an der Definition die syntaktische Korrektheit der Instanz verletzten würde.

Ad-hoc Änderungen [RRD03] an einem Workflow erfordern ein Höchstmaß an Agilität. Ein typisches Beispiel für einen Businessprozess wäre z. B. das Ändern eines

Einleitung / Technologische Grundlagen

Zulieferers innerhalb eines Supply-Chain Prozesses, falls der ursprüngliche Zulieferer Lieferengpässe hat. Ad-hoc Änderungen sind in den meisten Anwendungsgebieten nicht planbar und umfassen jede Form der Anpassung. Dazu zählen das Hinzufügen, Ändern und Löschen von Workflow Elementen und auch Änderungen am Datenfluss zwischen Tasks. Für ein WfMS bedeutet dies, dass es Methoden bereitstellen muss, die die Ausführung eines Workflows nicht unterbrechen während ein bestimmter Bereich des Workflows geändert wird. Das WfMS muss dafür Sorge tragen, dass zu jedem Zeitpunkt der Ad-hoc Änderung der Workflow ausführbar und konsistent bleibt. Auf technischer Ebene muss dafür ein Mechanismus existieren, dessen Komplexität vor den Benutzern des Systems versteckt wird.

1.3.2 1 9 B Fallbasiertes Schließen

Fallbasiertes Schließen [Be02] (engl. Case-based reasoning (CBR)) ist ein Untergebiet der wissensbasierten Systeme6 F ⁷ , das sich darauf konzentriert, Probleme mit bereits gemachten Erfahrungen zu lösen. Zur Umsetzung dieses Ansatzes existieren Methoden und Techniken, die es ermöglichen, Erfahrungen zu erfassen, zu speichern, zu finden und an neue Probleme anzupassen. Fallbasiertes Schließen liefert eine vielfältige Menge an Techniken, die im Erfahrungsmanagement verwendet werden können.

In Alltagssituationen hat jeder Mensch so einen Prozess schon durchlebt: Ein Problem oder eine Aufgabe ähnelt einer Situation in der Vergangenheit. Man erinnert sich an die damalige Lösung des Problems und man erkennt, dass die alte Lösung auch das neue Problem lösen könnte. Das folgende Beispiel sei aus dem Leben eines KFZ-Mechanikers gegriffen: Ein Mechaniker stellt fest, dass ein Fahrzeug (VW Golf TDI) unter einem Leistungsverlust leidet. Der Motor arbeitet über den kompletten Drehzahlbereich, aber der Turbolader setzt erst bei 3500 statt 2300 Umdrehungen/Minute ein. Plötzlich erinnert er sich, dass er vor längerer Zeit ein anderes Fahrzeug (Audi A4 TDI) mit fast gleichen Symptomen in der Werkstatt hatte. Damals führte ein Austausch des Luftmassenmessers zur Beseitigung der Probleme. Aufgrund dieser Erfahrung des Mechanikers wurde am VW Golf der Luftmassenmesser getauscht. Nach ausgiebigen Tests stellte sich heraus, dass das Problem am VW Golf tatsächlich behoben wurde durch den Austausch des Luftmassenmessers. Der Mechaniker konnte also die Lösung eines vergangenen Problems auf ein neues Übertragen.

Im CBR wird versucht durch Formalisierung und Erfassung von gemachten Erfahrungen, neu auftretende Probleme zu lösen. Gemachte Erfahrungen werden als eine Menge von Fällen abgespeichert. Ein Fall ist ein Paar bestehend aus dem eigentlichen Problem und der dazugehörigen Lösung.

⁷ hier sind vor allem Expertensysteme gemeint

20 | S e i t e

Das CBR-System wird üblicherweise mit einem neuen Problem angefragt. Daraufhin wird die Menge aller Fälle - die Fallbasis (siehe Abbildung 4) - nach einem Problem durchsucht, das dem aus der Anfrage ähnelt. Wird ein Fall gefunden, dessen Problembeschreibung eine genügend hohe Ähnlichkeit zu dem angefragten Problem aufweist, so ist die Hypothese, dass die Lösung in dem Fall auch eine hohe Nützlichkeit zum Lösen des aktuellen Problems bietet. Unter Ähnlichkeit wird dabei ein numerischer Wert verstanden, der zwischen dem Problem aus der Anfrage und dem Problem aus dem Fall berechnet werden kann. Die Grundlage für die Berechnung der Ähnlichkeit ist ein zuvor definiertes Ähnlichkeitsmaß. Für einen Überblick oft genutzter Ähnlichkeitsmaße sei an dieser Stelle auf [Be02] verwiesen.

2 0 B Der 4R-Zyklus

Der Prozess des fallbasierten Schließens kann als Zyklus beschrieben werden [Be02], dessen Bezeichnung den Anfangsbuchstaben seiner vier Phasen entstammt: In der „Retrieve“-Phase wird die Fallbasis nach einem Fall durchsucht, dessen Problemteil ähnlich ist zu dem aktuellen Problem. Danach wird der Lösungsteil, der aus dem gefundenen Fall stammt, in der „Reuse“-Phase wiederverwendet, um das aktuelle Problem zu lösen. Möglicherweise gibt es noch eine Adaptionsphase im „Reuse“-Schritt, um die gefundene Lösung an das aktuelle Problem anzupassen. Die (adaptierte) Lösung wird dem Benutzer präsentiert, der dann in der „Revise“-Phase die Lösung überprüft. Konnte durch die vorgeschlagene Lösung das aktuelle Problem gelöst werden, so wurde eine neue Erfahrung gemacht, die vom CBR-System während der "Retain"-Phase in Form eines neuen Falls abgespeichert werden kann.

Einleitung / Technologische Grundlagen

Retrieve

Der 4R-Zyklus beginnt, wenn der Benutzer eine Anfrage an das System schickt. Als Ergebnis erhält der Benutzer vergangene Fälle geliefert, die eine möglichst hohe Ähnlichkeit zu dem Problem aus der Anfrage aufweisen. Der Begriff der Ähnlichkeit nimmt hier eine zentrale Position ein, da dadurch eine unscharfe Suche ermöglicht wird, d. h. Anfrage und Fall können in einem zuvor definierten Maß voneinander abweichen. Die Annahme hierbei ist, dass ähnliche Probleme auch ähnliche Lösungen haben. Die Wahl eines passenden Ähnlichkeitsmaßes zwischen Anfrage und den Fällen in der Fallbasis ist das entscheidende Kriterium, um eine passende Problemlösung zu finden [Be02].

22 | S e i t e

Einleitung / Technologische Grundlagen

2 1 B Reuse

Sobald ein oder mehrere Fälle gefunden wurden, werden die Lösungen aus diesen Fällen genommen, um das aktuelle Problem zu lösen. Typischerweise wird dies durch Adaption der gefundenen Lösung erreicht. Dabei unterscheidet man hauptsächlich zwischen drei Arten der Adaption [Be02]:

• Generative Lösungsanpassung („Generative Adaptation“)

• Kompositionelle Lösungsanpassung („Compositional Adaptation“)

• Transformationsbasierte Lösungsanpassung („Transformational

Adaptation“)

Bei der generativen Lösungsanpassung gilt die Annahme, dass es einen wissensbasierten Problemlöser gibt, der bereits in der Lage ist, alle Probleme auch ohne Verwendung von Fällen zu lösen. Fälle werden dann nur noch genutzt, um Lösungen schneller zu finden oder um Lösungen zu finden, die ähnlich sind zu bekannten Lösungen. Der Problemlöser und die Erfahrung aus dem Fall arbeiten gemeinsam an der Lösung des Problems.

Die kompositionelle Lösungsanpassung zerlegt das Hauptproblem in Teilprobleme und versucht dabei ein Teilproblem nach dem anderen zu lösen. Die Reihenfolge, in der die Teilprobleme abgearbeitet werden, spielt dabei eine wesentliche Rolle, da das Resultat der Lösungsanpassung davon beeinflusst wird. Das CODAW System, das in Kapitel 2 vorgestellt wird, implementiert eine solche Lösungsanpassung durch eine Erweiterung der Fälle mit Prädikatenlogik.

Bei der transformationsbasierten Lösungsanpassung gibt es normalerweise eine feste Menge von Adaptionsregeln und Operatoren, nach denen eine Lösung angepasst werden darf [Be02]. Abhängig vom Grad der angewandten Adaption wird von einer Substitutionsadaption oder einer strukturellen Adaption gesprochen. Die Substitutionsadaption wird verwendet, wenn die Anpassung der Lösung recht einfach ist und nur weniger Änderungen bedarf. Der Begriff Substitution deutet bereits an, dass lediglich Werte in der Anfrage ausgetauscht werden. Die Struktur innerhalb der Anfrage wird dabei nicht verändert. Reicht eine bloße Abänderung von Werten nicht aus und muss die Anfrage strukturell verändert werden, so wird von einer strukturellen Adaption gesprochen. Eine strukturelle Änderung kann bspw. das Hinzufügen oder Entfernen eines Attributes sein. Sowohl die Substitutionsadaption als auch die strukturelle Adaption wenden eine vorgegebene Menge von Regeln und/oder Operatoren zur Lösungsanpassung an.

In dieser Arbeit wird eine transformationsbasierte Lösungsanpassung verwendet, die im Gegensatz zu den klassischen Verfahren keine feste Menge an Operatoren oder

Einleitung / Ziel dieser Arbeit

Regeln kennt. Die Adaptationsoperatoren sind fallabhängig und somit direkt an Erfahrungswissen gebunden. Das Erfahrungswissen wird mittels eines Rekonstruktions-algorithmus an die Anfrage angepasst. Aus diesem Grunde wird eine solche Adaption auch als derivative („derivational analogy“) Adaption bezeichnet [Be02] [Carbonell83]. Es wird dabei eine Brücke zur generativen Lösungsanpassung geschlagen mit dem Unterschied, dass es keinen konkreten wissensbasierten Problemlöser gibt. Es ist Aufgabe des Rekonstruktionsalgorithmus diese Lücke zur Anpassung des Erfahrungswissens zu schließen und die im Fall spezifizierten Operatoren auf die Anfrage zu übertragen.

2 2 B Revise

In der „Revise“-Phase wird die Lösung nun vom Benutzer, der die Anfrage gestellt hat, hinsichtlich ihrer Nützlichkeit bewertet. Die Güte des Systems hängt dabei wesentlich davon ab, wie gut das Ähnlichkeitsmaß aus dem „Retrieve“-Schritt die Nützlichkeit approximiert hat. Kann die vorgeschlagene Lösung das Problem noch nicht adäquat lösen, so sollte es für den Benutzer möglich sein, die Lösung noch manuell anzupassen. Das setzt natürlich voraus, dass der Benutzer ein fundiertes Wissen über den Gegenstandsbereich besitzt.

2 3 B Retain

Die „Retain“-Phase des Zyklus kann als Lernphase verstanden werden. Wenn eine Lösung nach dem „Revise“-Schritt vom Nutzer akzeptiert wird, so kann die angepasste Lösung zusammen mit dem Problem aus der ursprünglichen Anfrage als neuer Fall in der Fallbasis abgespeichert werden. Damit wird die Fallbasis um neues Wissen erweitert, das bei einer erneuten Anfrage zur Verfügung steht.

1.4 Ziel dieser Arbeit

Nach Einführung der Begriffe und der verwendeten Technologien kann das Ziel dieser Arbeit genauer beschrieben werden. Diese Arbeit beschäftigt sich mit der Konzipierung und Realisierung einer Softwarekomponente, die Workflows automatisch anpasst. Das hier vorgestellte System ermöglicht es für eine konkrete Problemstellung des Workflowmodellierers semantisch ähnliche Workflows zu finden, von denen Teile in einer neuen Workflow Definition wiederverwendet werden können. Das beschleunigt zum einen den Vorgang der Prozessmodellierung und zum anderen werden Fehler bei der Konstruktion vermieden, da das Expertenwissen des CBR-Systems genutzt werden

24 | S e i t e

Einleitung / Ziel dieser Arbeit

kann. Auf der Ausführungsebene eines Workflows geschehen wiederum oft unvorhergesehene Ereignisse: Bestimmte Bedingungen fallen weg oder kommen hinzu oder es kommt zu sog. Exceptions (vgl. Abschnitt 1.3.1) während der Ausführung des Workflows. In solchen Situationen muss die Workflow Instanz so abgeändert werden, dass sie den neuen Anforderungen genügt und die Konsistenz der Instanz weiter gewährleistet ist.

Zur Realisierung des Konzeptes wird eine Softwarekomponente als Bestandteil der CAKE III Architektur implementiert (siehe Kapitel 3). Der Adaptionsprozess an sich soll mittels CBR geschehen. Im Gegensatz zu klassischen CBR-Systemen wird hier jedoch ein innovativer Ansatz aus [MTSB08][MinorEtAl10a] verwendet, der vorschlägt, dass das Erfahrungswissen für die Adaption in Änderungsepisoden des Workflows erfasst wird und nicht an eine Menge fester Operatoren gebunden wird (vgl. Abschnitt 1.3.2). Als Bestandteil dieser Arbeit muss ein Konzept für eine Fallrepräsentation entwickelt werden, die in der Lage ist, Änderungsepisoden zu formalisieren und sie für eine Wiederverwendung nutzbar zu machen. Da sich die Änderungsepisoden auf Workflows beziehen, muss eine adäquate Repräsentation für Workflows gefunden werden, die nicht nur der Berechnung von Änderungen an Workflows dient, sondern auch ein Retrieval der Fälle ermöglicht. Für das Retrieval muss ein Ähnlichkeitsmaß erdacht werden, das die Ähnlichkeit zwischen Fällen ermittelt, deren Inhalte nicht durch Attribut-Wert-Paare, sondern durch Strukturen von Workflows bestimmt werden. Die Übertragung von Änderungsepisoden von einem Workflow auf einen anderen ist ein neuartiger Vorgang. Um das Konzept von seinem Einsatzgebiet weitgehend unabhängig zu halten, gilt die Vorbedingung, dass es nicht notwendig ist, Metawissen über ein Einsatzgebiet in den Fällen explizit zu erfassen. Dadurch ermöglicht man eine Fallbasis, die in Interaktivität mit den Workflowmodellierern des WfMS wachsen und somit lernen kann, ohne dass Erfahrungen/Fälle von CBR Experten erfasst werden müssen. Die dabei entstehende Abtrennung des Workflowmodellierers von der technischen Ebene, in der Fälle modelliert werden müssen, erhöht die Akzeptanz bei der Einführung eines solchen Systems. Eine stark personengebundene Modellierung von Fällen würde wahrscheinlich auch zu stark unterschiedlichen Lösungen führen, die für unterschiedliche Personen unterschiedliche Nützlichkeiten aufweisen. Der Verzicht auf CBR Experten verursacht jedoch einen Mangel an Metawissen über das Anwendungsgebiet. Daher werden für diese Arbeit unterschiedliche Algorithmen entworfen und implementiert, die die Übertragung der Änderungsepisoden ermöglichen. Auf Basis dieser Algorithmen wird eine erste formative Studie durchgeführt, die die Realisierbarkeit des Konzepts evaluiert. Dazu müssen Fallbasen angelegt werden, deren Fälle empirisch erfasst werden. Vor der Umsetzung des Konzepts werden Anforderungsanalysen durchgeführt, um herauszufinden, ob und wie die bestehenden CAKE Systeme zu modifizieren sind, um die automatische Adaption von Workflows zu realisieren.