Entwicklung einer Komponente zur automatisierten Adaption von Workflows


Diplomarbeit, 2010

123 Seiten, Note: 1,0


Leseprobe

Inhaltsverzeichnis

Kapitel 1 - Einleitung
1.1 Motivation
1.2 Grundbegriffe
1.2.1 Business-Prozess / Geschäftsprozess
1.2.2 Workflows
1.2.3 Workflow Management System (WfMS)
1.2.4 Abarbeitung und Steuerung von Workflows
1.2.5 Korrektheit
1.2.6 Erfahrungsmanagement
1.3 Technologische Grundlagen
1.3.1 Agilität in Workflows
1.3.2 Fallbasiertes Schließen
1.4 Ziel dieser Arbeit
1.5 Aufbau dieser Arbeit

Kapitel 2 - Ähnliche Forschungsansätze
2.1 AdaptFlow
2.2 CODAW
2.3 CBRFlow
2.4 Phala
2.5 Bewertung der Systeme

Kapitel 3 - Die CAKE Systeme
3.1 CAKE I
3.1.1 Architektur
3.1.2 Datenmodell
3.1.3 Ähnlichkeitsmodell
3.2 CAKE II
3.2.1 Architektur
3.2.2 Die CAKE Modellierungssprache
3.2.3 Konsistenz von Workflows
3.2.4 Das CAKE Statusmodell
3.2.5 Abarbeitung von Workflows
3.2.6 Anhalten von Workflows
3.3 CAKE III
3.3.1 Integration der CAKE Systeme

Kapitel 4 - Konzeptentwicklung
4.1 Anforderungsanalyse
4.1.1 Szenarien
4.1.2 Anforderungen an den Adaptionsprozess von Workflows
4.1.3 Anforderungen an die Repräsentation von Fällen
4.2 Fallrepräsentation
4.2.1 Das Retrievalformat für Workflows
4.2.2 Die ADD- und DELETE-Listen
4.3 Der Adaptionsprozess
4.3.1 Der Adaptionszyklus
4.3.2 Setzen von Breakpoints
4.3.3 Das Retrieval von Adaptation Cases
4.4 Das Ankerprinzip
4.4.1 Das Lokalisierungsproblem
4.4.2 Adaptionsalgorithmen
4.4.3 Beispiel einer Workflow Adaption
4.5 Evaluation der Adaptionsalgorithmen
4.6 Beurteilung und Zusammenfassung

Kapitel 5 - Umsetzung des Konzeptes
5.1 Voruntersuchungen
5.1.1 Performanztest von CAKE I
5.1.2 Untersuchung von Kochprozessen
5.2 Erweiterung von CAKE I
5.2.1 Implementierung der Fallrepräsentation
5.2.2 Implementierung des Retrievalformats für Workflows
5.2.3 Implementierung der ADD- und DELETE-Listen
5.3 Der Adaptation Manager
5.4 Die Interaktion der CAKE Systeme
5.5 Implementierung des CAM Algorithmus
5.6 Zusammenfassung und Beurteilung

Kapitel 6 - Schlussbemerkungen

Anhang
Anhang 1 - XML Schema für Adaptation Cases
Anhang 2 - CAKE III Sequenzdiagramm einer automatischen Adaption
Anhang 3 - XSLT zur Erzeugung des Retrieval Formats für Workflows
Anhang 4 - Pseudocode des Composite Anchor Mappings

Abbildungsverzeichnis

Literaturverzeichnis

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 stattfand1. 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- Offensive2 unterstützt. Die UPTODATE-Offensive hilft Handwerksunternehmen ihr 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 ITServicestruktur 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 Beschreibungs- ebene 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 techno- logischen Grundlagen fassbarer zu machen.

1.2.1 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 Coalition3 (WfMC) getroffen. Sie widerspricht nicht der Definition von F 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 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 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 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 BusinessProzesses im WfMS. Workflow Definitionen müssen im Einklang mit dem BusinessProzess 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 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].

Abbildung 1 - Das WfMC Referenzmodell

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“.

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 Service 4. Er kümmert sich um das F 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.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 - Komponenten eines WfMS und ihre funktionale Bedeutung (In Anlehnung an [WFMC08])

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 Workflow- teilnehmern 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“.

1.2.4 Abarbeitung und Steuerung von Workflows

Workflows können auf verschiedenartige Weise dargestellt werden. Die Repräsentation basiert auf der Modellierungssprache, die das Tool zur Workflow- modellierung 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. BPMN5 ) sind graphorientiert. Daher wird die F Funktionsweise des „Enactment Service“ in dieser Arbeit auf prozedurale Beschreibung- en 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 graph- basierte 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 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.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 - Beispielworkflow in BPMN, Quelle: eigene Erstellung

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 würden, lässt sich mit Hilfe dieser drei Kontrollstrukturen normalerweise jeder Geschäftsprozess ausdrücken [HJM04]6. Dabei handelt es sich jedoch um Konstrukte, die F eher in Spezialfällen nützlich wären, als in allgemeinen Anwendungsgebieten. Im Folgenden werden alle Elemente in einem Kontrollfluss als Workflowelemente be- zeichnet. 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.
- „Unintentional Multiple Execution“, z. B. wenn es erlaubt ist, dass ein Task mehrere eingehende Kanten besitzt. Ohne Synchronisation wird dieser Task womöglich unbeabsichtigt mehrmals gestartet.
- „Active Termination“, z. B. wenn mehrere Endpunkte eines Workflows existieren. Das Erreichen eines Endpunktes würde die Beendigung des Workflows bedeuten, obwohl parallele Sequenzen noch aktiv sein könnten.

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 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].

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 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 Aufgaben- stellungen, so stelle man sich vor, ein Antibiotikum wirke nicht aufgrund einer Resistenz 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 not- wendig, 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 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 Fallbasiertes Schließen

Fallbasiertes Schließen [Be02] (engl. Case-based reasoning (CBR)) ist ein Untergebiet der wissensbasierten Systeme7, 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.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4- Grundprinzip des CBR (eigene Erstellung in Anlehnung an [Be02])

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 Ähnlichkeits- maße sei an dieser Stelle auf [Be02] verwiesen.

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.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 - Der 4R-Zyklus, Quelle: [Be02] [AP94][We07]

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].

[...]


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

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

3 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.

4 Synonym zu „Process Execution Environment“ [WFMC08]

5 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]

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

7 hier sind vor allem Expertensysteme gemeint

Ende der Leseprobe aus 123 Seiten

Details

Titel
Entwicklung einer Komponente zur automatisierten Adaption von Workflows
Hochschule
Universität Trier
Note
1,0
Autor
Jahr
2010
Seiten
123
Katalognummer
V170401
ISBN (eBook)
9783640892358
ISBN (Buch)
9783640892419
Dateigröße
2563 KB
Sprache
Deutsch
Anmerkungen
Diese Arbeit beschäftigt sich mit der Entwicklung einer Softwarekomponente, die durch Erfahrungswissen, Workflows sowohl während der Modellierung als auch während der Laufzeit automatisch anpassen kann. Zur Überprüfung des Konzepts wurde eine erste Evaluation vorgenommen.
Schlagworte
Workflows, Prozesse, Workflow Management Systeme, Prozess-Modellierung, Erfahrungsmanagement, Case-Based Reasoning, Entscheidungsunterstützung, Adaption, Agilität, agile
Arbeit zitieren
Dipl.-Wirt. Inform. M. Sebastian E. K Görg (Autor), 2010, Entwicklung einer Komponente zur automatisierten Adaption von Workflows, München, GRIN Verlag, https://www.grin.com/document/170401

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Entwicklung einer Komponente zur automatisierten Adaption von Workflows



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden