Vergleich von Workflow Management Systemen auf Open Source Basis

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungs- und Symbolverzeichnis

1 Einleitung
1.1 Generelle Notwendigkeit von Workflowsystemen
1.2 Einordnung des Themenbereiches
1.3 Gliederung der Arbeit

2 Grundlagen
2.1 Geschäftsprozess
2.1.1 Begriff und Definition
2.1.2 Geschäftsprozess-Management
2.2 Workflow
2.3 Workflow-Management
2.4 Lizensierung
2.5 Unternehmenssicht von Open Source
2.6 Theoretische Workflow Grundlagen am Beispiel von YAWL
2.6.1 YAWL
2.6.2 Die YAWL Sprache
2.6.3 Datenverwaltung in YAWL
2.6.4 Architektur des YAWL-Systems

3 Auswahl von Systemen
3.1 Sonstige WfMS-Systeme
3.1.1 jBPM
3.1.2 cuteflow
3.1.3 Bossa Workflow
3.1.4 Imixs Workflow
3.1.5 Interleave
3.1.6 Andere Projekte
3.2 Auswahl von entsprechender Software
3.2.1 Processmaker
3.2.2 Joget
3.2.3 Bonita Open Solution
3.2.4 uEngine
3.2.5 Activiti

4 Beispielworkflows
4.1 Aufgabenstellung
4.2 Einrichten eines Urlaubsantrages mit Processmaker
4.2.1 Einrichten der Aufbauorganisation
4.2.2 Definieren des Prozesses
4.3 Einrichten eines Urlaubsantrages mit Joget
4.3.1 Einrichten der Aufbauorganisation
4.3.2 Definieren des Prozesses
4.4 Einrichten eines Urlaubsantrages mit Bonita
4.4.1 Einrichten der Aufbauorganisation
4.4.2 Definieren des Prozesses
4.5 uEngine
4.5.1 Einrichten der Aufbauorganisation
4.5.2 Definieren des Prozesses
4.5.3 Prozess ausführen
4.6 Activiti
4.6.1 Einrichten der Aufbauorganisation
4.6.2 Definieren des Prozesses

5 Vergleich der Systeme
5.1 Vergleichskriterien
5.1.1 Prozessmodellierung
5.1.2 Lizensierung
5.1.3 Flexibilität / Anpassbarkeit
5.1.4 GUI / Benutzerfreundlichkeit
5.1.5 Internationalisierung / Sprachen
5.1.6 Architektur / Datenbank
5.1.7 Skalierbarkeit
5.1.8 Sicherheit / Single-Sign-On / Benutzerverwaltung
5.1.9 Schnittstellen zu anderen Systemen
5.1.10 Betriebssystem-Abhängigkeit
5.1.11 Programmiersprache
5.1.12 Benutzerformulare
5.1.13 Simulation
5.1.14 Support / Training
5.1.15 Dokumentation
5.1.16 Weiterentwicklung / Community / Transparenz
5.1.17 Updates
5.1.18 Verbreitung / Referenzen

6 Zusammenfassung und Ausblick

7 Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1 - YAWL Atomic Task

Abbildung 2 - YAWL Multiple Instance Task

Abbildung 3 - YAWL Composite Task

Abbildung 4 - YAWL Composite multiple instance task

Abbildung 5 - YAWL Condition

Abbildung 6 - YAWL Input condition

Abbildung 7 - YAWL Output condition

Abbildung 8 - YAWL AND Join

Abbildung 9 - YAWL OR join

Abbildung 10 - YAWL XOR join

Abbildung 11 - YAWL AND split

Abbildung 12 - YAWL OR split

Abbildung 13 - YAWL XOR split

Abbildung 14 - YAWL Architektur aus [Aalst1] Arthur H.M. ter Holstede et al., 2010

Abbildung 15 - Benutzerverwaltung in Processmaker

Abbildung 16 - Abteilungsverwaltung in Processmaker

Abbildung 17 - Startpunkt im Processmaker

Abbildung 18 - Beispielformular im Processmaker

Abbildung 19 - Beispielprozess im Processmaker

Abbildung 20 - Benutzerverwaltung in Joget

Abbildung 21 - Swimmlanes in Joget

Abbildung 22 - Beispielprozess in Joget

Abbildung 23 - Urlaubsantragsformular in Joget

Abbildung 24 - Formularerstellung in Joget

Abbildung 25 - Inbox in Joget

Abbildung 26 - Formular des Urlaubsantrages in Joget

Abbildung 27 - Benutzerverwaltung in Bonita

Abbildung 28 - Benutzer für den Urlaubsantrag in Bonita

Abbildung 29 - Benötigte Pools für den Urlaubsantrag

Abbildung 30 - Timeout-Definition für den Urlaubsantrag

Abbildung 31 - Vollständiger Prozess des Urlaubsantrages in Bonita

Abbildung 32 - Variablendefinition für den Urlaubsantrag

Abbildung 33 - Antragsformular - Designeransicht in Bonita

Abbildung 34 - Webfront für den Urlaubsantrag

Abbildung 35 - Inbox von Bonita

Abbildung 36 - Dashboard von uEngine

Abbildung 37 - Aufbauorganisation in uEngine

Abbildung 38 - Rollenmanager von uEngine

Abbildung 39 - Rollen für den Urlaubsantrag

Abbildung 40 - Variablen für den Urlaubsantrag

Abbildung 41 - uEngine Designer

Abbildung 42 - uEngine Rollenzuordnung

Abbildung 43 - uEngine Urlaubsantragsprozess

Abbildung 44 - Prozessübersicht von uEngine

Abbildung 45 - Benutzerformular von uEngine

Abbildung 46 - Offene Prozesse in uEngine

Abbildung 47 - Activiti Administrator

Abbildung 48 - Activiti Modeler

Abbildung 49 - Processmaker Login-Screen

Abbildung 50 - Bonita Studio - Resourcenverwaltung

Abbildung 51 - Joget Prozessstart-Button

Abbildung 52 - Joget Hilfefunktion

Abbildung 53 - Beispiel Userview

Abbildung 54 - Screenshot der Labelverwaltung

Abbildung 55 - uEngine iPhone Simulator Screenshot

Abbildung 56 - Activiti iPhone Screenshot

Abbildung 57 - Lastverteilung über Loadbalancer und Cluster

Abbildung 58 - uEngine Systemaufbau mit OKF

Abbildung 59 - Bonita Studio Simulation

Abbildung 60 - Resourcenbearbeitung in Bonita Studio

Tabellenverzeichnis

Tabelle 1 - Vergleich der Systeme - Lizensierung

Tabelle 2 - Vergleich der Systeme - Flexibilität und Anpassbarkeit

Tabelle 3 - Vergleich der Systeme - GUI und Benutzerfreundlichkeit

Tabelle 4 - Vergleich der Systeme - Internationalisierung und Sprachen

Tabelle 5 - Vergleich der Systeme - Architektur und Datenbank

Tabelle 6 - Vergleich der Systeme - Skalierbarkeit

Tabelle 7 - Vergleich der Systeme - Sicherheit, Single-Sign-On und Benutzerverwaltung

Tabelle 8 - Vergleich der Systeme - Schnittstellen zu anderen Systemen

Tabelle 9 - Vergleich der Systeme - Betriebssystemabhängigkeit

Tabelle 10 - Vergleich der Systeme - Programmiersprache

Tabelle 11 - Vergleich der Systeme - Benutzerformulare

Tabelle 12 - Vergleich der Systeme - Simulation

Tabelle 13 - Vergleich der Systeme - Support und Training

Tabelle 14 - Vergleich der Systeme - Dokumentation

Tabelle 15 - Vergleich der Systeme - Weiterentwicklung, Community und Transparenz

Tabelle 16 - Vergleich der Systeme - Updates

Tabelle 17 - Vergleich der Systeme - Verbreitung und Referenzen

Abkürzungs- und Symbolverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Durch die Komplexität der Arbeitsabläufe in vielen Unternehmen ist der zweckmäßige Einsatz von Computerunterstützung in diesen Bereichen immer mehr von entscheidender Bedeutung. Um Standards in dem Bereich der Arbeitsabläufe zu schaffen, ist es am wichtigsten, diese im ersten Schritt zu erfassen. Erst dadurch besteht die Möglichkeit, diese zu analysieren und zu optimieren. Sind diese Schritte erfolgreich durchgeführt worden, ist danach erst die Integration eines Workflow-Systems möglich. Die benötigten Schritte bis zur Einführung eines Workflow-Systems sind aber nicht Bestandteil dieser Arbeit. In diesem Fall gehen wir davon aus, dass bei der Einführung und Auswahl eines geeigneten Systems die Prozesse bekannt sind und direkt in ein entsprechendes System technisch umgesetzt werden können. Außerdem werden nur eigenständig nutzbare Systeme detailliert untersucht.

1.1 Generelle Notwendigkeit von Workflowsystemen

Durch die ständig wachsenden Anforderungen in allen Unternehmen und steigender Geschwindigkeit ist es von entscheidender Bedeutung, Informationen und Arbeitsabläufe schnell und zuverlässig an die entsprechenden Personen und Stellen zu verteilen. Ein Workflow-System sollte die Produktivität steigern, Kosten für einen Prozess senken und die Bearbeitung von externen Aufgaben beschleunigen.

1.2 Einordnung des Themenbereiches

Die Problematik gehört zum Bereich Business Engineering. „Business Engineering (BE)“ bezeichnet die methodenorientierte und modellbasierte Konstruktionslehre für Unternehmen des Informationszeitalters. Business Engineering (BE) beschäftigt sich mit Problemstellungen, die aus der Transformation der Industrie- in die Informationsgesellschaft entstehen.“^[1] Im BE wird zwischen Strategie-, Geschäftsprozess- und Systemebene unterschieden. Im Bezug auf Workflow-Systeme ist die Systemebene interessant, da dort beschrieben ist, welche Prozesse und Arbeitsschritte durch Software unterstützt werden können. Demnach ist dort die Konzeption und Integration von Workflow-Systemen anzusiedeln, da diese Ebene die Beziehung zwischen IT-Komponenten, Datenstrukturen und unterstützender Software beschreibt.

1.3 Gliederung der Arbeit

Als Orientierungshilfe wird nachfolgend für den Leser die Gliederung dieser Diplomarbeit vorgestellt.

Im 1. Kapitel wird ein Überblick über den Themenbereich und den Aufbau der Arbeit beschrieben. Dabei wird die Arbeit in einem Themenbereich zugeordnet und die generelle Notwendigkeit von Workflowsystemen beschrieben.

Das 2. Kapitel beschäftigt sich mit den theoretischen Grundlagen von Workflow-Systemen. Zuerst werden die Begriffe des Geschäftsprozesses differenziert und entsprechend erläutert. Danach wird des Begriff „Workflow“ detaillierter untersucht und die verschiedenen Arten beschrieben. Ein weiterer Aspekt den dieses Kapitel beleuchtet ist das Thema der Lizensierung, die auch bei OpenSource Software eine wichtige Rolle spielt. Neben der Lizenzierung wird im Allgemeinen der Nutzen von OpenSource Software für Unternehmen beleuchtet. Außerdem werden am Beispiel YAWL, welches von van der Aalst entwickelt wurde, die Grundelemente, Begriffe, Schnittstellen und Komponenten definiert und aufgezeigt.

Im 3. Kapitel wird ein Teil der am Markt verfügbare OpenSource-Workflow-Systeme betrachtet und im Folgenden eine Auswahl von 5 Systemen getroffen, die im weiteren Verlauf der Arbeit analysiert werden. Dabei liegt der Fokus auf Systemen die eigenständig nutzbar sind und nicht nur in Verbindung mit anderen Softwareprodukten als Workflow-System verwendet werden können.

Im 4. Kapitel wird jeweils ein Beispielworkflow (Genehmigen eines Urlaubsantrages) in den entsprechenden Systemen, welche in dem Kapitel 3 ausgewählt wurden, eingerichtet, beschrieben und getestet. Dabei ist jedes System auf einem virtuellen Server unter VMware installiert worden und anhand von Screenshots aus diesen Systemen wird dargestellt, wie sich mit den Mitteln und Produktspezifischen Funktionen die Aufgabenstellung abbilden lässt. Da nicht jedes System die identischen Funktionen hat, ist die Gliederung bei den einzelnen Produkten nicht immer identisch. Jedoch wird immer zuerst die Einrichtung der Aufbauorganisation beschrieben und dann der jeweilige Prozess mit den entsprechenden Tools erstellt.

Im 5. Kapitel werden Vergleichskriterien von Workflowsystemen analysiert und erarbeitet und mit den ausgewählten Systemen evaluiert und die Ergebnisse dargestellt. Der Kern der Diplomarbeit bildet dieses Kapitel, da in diesem Punkt verschiedene Vergleichskriterien für ein Workflow-System mit dem Fokus auf den Einsatz in einem Unternehmen beleuchtet werden. Dabei werden 18 verschiedene Kriterien ausgearbeitet und jedes der 5 ausgewählten Produkte mit dem Fokus auf diese Kriterien untersucht. Die Erkenntnisse aus den Beispielworkflows werden in diesem Kapitel verwendet um die Vergleichskriterien zu bilden. Der Aufbau dieses Kapitels ist so gestaltet, dass zuerst ein Kriterium vorgestellt wird und dann in den nachfolgenden Punkten jeweils das entsprechende Softwareprodukt untersucht wird. Anschließend werden in einer Tabelle die Ergebnisse für dieses Kriterium zusammengefasst, um diese miteinander vergleichen zu können. Dabei werden die Vor- und Nachteile, die für dieses Kriterium besonders Aufgefallen sind, herausgestellt.

Abschließend werden im letzten Teil die Ergebnisse zusammengefasst, ein Ausblick auf mögliche Weiterentwicklungen in diesem Bereich gegeben und ein Fazit gezogen.

2 Grundlagen

In diesem Kapitel werden die beiden Begriffe Geschäftsprozess und Workflow definiert und voneinander abgegrenzt.

2.1 Geschäftsprozess

2.1.1 Begriff und Definition

In der Literatur gibt es verschiedene Definitionen und Abgrenzungen des Begriffs Geschäftsprozess. Ein Geschäftsprozess ist laut Gabler: „Folge von Wertschöpfungsaktivitäten (Wertschöpfung) mit einem oder mehreren Inputs und einem Kundennutzen stiftenden Output. Geschäftsprozesse können auf verschiedenen Aggregationsebenen betrachtet werden, z.B. für die Gesamtunternehmung, einzelne Sparten- oder Funktionalbereiche.“^[2] Diese Definition ist im Bezug auf Workflows nicht ganz passend, da die Outputs eines Workflows auch zur internen Organisation dienen und keinen direkten Bezug zu einem Kundennutzen haben müssen. Ein Beispiel dafür sind sämtliche Arbeitsabläufe der Personalabteilung in einem Unternehmen, die keinen Kundenkontakt haben und keinen direkten Kundennutzen als Output generieren. Passender ist in diesem Zusammenhang eher die Definition vom „business process“ der WfMC:^[3]

„A set of one or more linked procedures or activities which collectively realise a business objective or policy goal, normally within the context of an organisational structure defining functional roles and relationships.“^[4]

Dabei steht nicht das technische Verfahren im Vordergrund, sondern Geschäftsprozesse sind auf ein Unternehmensziel ausgerichtet und beschreiben einen Teil der Wertschöpfungskette und nicht die technische Implementierung.

2.1.2 Geschäftsprozess-Management

Die Aufgaben des Geschäftsprozess-Managements sind das Planen, Organisieren und Kontrollieren der Geschäftsprozesse eines Unternehmens. Diese müssen im Fokus nach Qualität, Kosten, Zeit und Zufriedenheit der Kunden, Mitarbeiter und sämtlichen Ressourcen optimiert werden. Diese Tätigkeit ist nicht abhängig von einer bestimmten Technologie und kann nur „mit gesundem Menschenverstand“ von einer Führungskraft übernommen werden. Dabei ist das Ziel, die unternehmensinternen Abläufe zu systematisieren und das Gesamtunternehmensziel besser zu erreichen. Diese hat nach Schnetzer ^[5] jedoch einige Schwachstellen. Die entsprechende Fachkraft hat nur mangelnde Informationen über laufende Prozesse und es gibt keine Systematisierung der Prozessinformationen. Außerdem ist keine Integration über Organisationseinheiten und Abteilungen hinweg gegeben und eine Änderung bedeutet einen großen Koordinationsaufwand für alle Beteiligten.

Viele Probleme entstehen dabei durch sogenannte „Medienbrüche“. Unter einem Medienbruch versteht man einen Wechsel des informations-tragenden Mediums innerhalb eines Informationsbeschaffungsprozesses.^[6] Diese Schwachstellen sollen durch ein Workflow-System mit definierten Schnittstellen und einem verbesserten Informationsfluss behoben werden oder weitestgehend verringert werden können.

2.2 Workflow

Auch dieser Begriff ist in der Literatur unterschiedlich definiert.

Die Workflow Management Coalition (WfMC) definiert einen Workflow als: “The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.”^[7]

Demnach wird ein Geschäftsprozess unter Einbeziehung von Prozessbeteiligten und Systemen erweitert. Dadurch wird ein Geschäftsprozess durch weitergehende Spezifikationen zu einem automatisierbaren Prozess erweitert. Dieses beinhaltet aber nicht automatisch, dass er durch ein Workflow-Management-System (WFMS) unterstützt werden muss, sondern kann weiterhin über konventionelle Wege abgearbeitet werden.

2.3 Workflow-Management

Ein Workflow Management (WFMS) ist definiert als: “A system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications.”^[8]

2.4 Lizensierung

In dieser Arbeit werden die Definitionen der Open Source Initiative (OSI)^[9] verwendet.

1. Freie Weitergabe ohne Gebühren jeder Art
2. Der Sourcecode einer Software muss in lesbarer Form vorliegen
3. Abgeleitete Versionen müssen unter der gleichen Lizenzbedingung zugelassen werden
4. Schutz des Authors ist möglich, so dass Änderungen nur als Patch verteilt werden dürfen.
5. Keine Diskriminierung von Personen oder Gruppen
6. Keine Einschränkung des Einsatzbereiches
7. Weitergabe der Lizenzbedingungen in der Software
8. Die Lizenz darf nicht nur für ein bestimmtes Produkt gelten
9. Die Lizenz darf die Verwendung von anderer Software nicht einschränken
10. Die Lizenz muss technologieneutral sein

Lizenzen, die den oben genannten Bedingungen entsprechen, können von der OSI zertifiziert werden. Die Verfügbarkeit des Quellcodes verringert das Risiko, dass eine Softwareentwicklung eingestellt wird und die jeweilige Software ist an seine eigenen Bedürfnisse anpassbar. Da der Begriff „Open Source“ nicht geschützt ist, kann ihn jeder Hersteller ohne weitere Bedingungen für seine Produkte verwenden. Dahinter verbirgt sich häufig ein besonderes Geschäftsmodell. Bei diesem Modell erhält man vom Hersteller den Quellcode gegen Zahlung einer Lizenzgebühr. Dieses widerspricht sich jedoch mit dein eigentlichen Open Source Gedanken, dass der Quellcode jederzeit für jeden zugänglich ist. Erst dadurch entsteht der eigentliche Benefit von Open Source Software, da die Verwendung nicht von finanziellen Mitteln abhängig ist. Eine weitere Abstufung dieser Praktiken ist das sogenannte „Shared Source“ Modell“^[10], was unter anderem Microsoft verwendet. Dabei wird ausgewählten Kreisen von Kunden, Partnern und Bildungseinrichtungen ein Einblick in den Quellcode gewährleistet. Dieser darf jedoch nicht weiter verwendet oder in irgendeiner Form abgewandelt und weitergegeben werden. Diese Art von Lizenz dient nur Marketing-Zwecken um das Argument, dass Fehler und Sicherheitslücken in Open Source Software schneller gefunden werden, da es viel mehr Personen gibt, die den Quellcode einsehen können, aus Marketinggründen zu benutzen.

Open Source heißt aber nicht automatisch, dass alles kostenlos ist. Zwar darf bei Open Source keine Lizenzgebühr für die eigentliche Software genommen werden, jedoch ist damit nicht ausgeschlossen, dass der Support für dieses Produkt oder die Veröffentlichung der Software auf Datenträgern und das Erstellen und Verteilen von Handbüchern auch kostenlos erfolgt. Gerade bei kleineren Unternehmen basiert das Geschäftsmodell darauf, dass eine Software unter Open Source kostenlos verteilt wird und Anpassungen, Wartung und Support von den Kunden bezahlt werden muss. Dadurch haben auch kleine Firmen die Möglichkeit, dass Ihre Software von einer breiten Masse benutzt wird und im besten Fall profitiert diese dann wieder von der Weiterentwicklung von anderen. Durch dieses Vorgehen entstehen sogenannte „Communitys“. Diese werden oft mit einem kommerziellen Hintergrund von einem Unternehmen errichtet und betreut. Ziel jeder Open Source Community ist es, das eigentliche Produkt gemeinsam weiterzuentwickeln. Sollte es bei den Mitgliedern einer Community jedoch zu verschiedenen Interessen und Meinungen kommen, kann ein sogenannter „Fork“ entstehen. Ein Fork ist eine Weiterentwicklung einer bestimmten Software, jedoch wird diese Entwicklung nicht mehr an das ursprüngliche Projekt zurückgegeben und hat ein Eigenleben. Dadurch entstehen 2 Produkte, die zu einem bestimmten Zeitpunkt eine gemeinsame Basis hatten, dann jedoch unterschiedliche Richtungen in der Entwicklung gegangen worden sind. Ein bekanntes Beispiel dafür ist die Monitoring Software ICINGA^[11], welche sich Mitte 2009 als Fork von Nagios^[12] entwickelt hat^[13]. Auslöser ist dabei gewesen, dass die Integration von neuen Features und Bugs von einzelnen Personen abhängig war und dadurch die Weiterentwicklung des Projektes stockte. Daraufhin haben sich verschiedene Personen zusammengeschlossen und einen Fork gebildet und eine völlig eigene Community mit anderen Regeln und Grundsätzen erstellt.

Viele Firmen gehen auch den Weg der Doppellizensierung eines Produktes, das sogenannte „dual-licensing“. Ein berühmtes Beispiel dafür ist die Firma MySQL AB^[14], die sowohl eine kommerzielle Version der MySQL-Datenbank für seine Kunden anbietet, als auch eine Open Source Version mit entsprechender Community. Dieses kann für viele Entwickler jedoch ein großes Hindernis sein, Weiterentwicklungen an der Open Source Version vorzunehmen, da dadurch automatisch die entsprechende Firma ein Benefit für ihr eigenes Produkt hat und eine kostenlose Entwicklung genießt. Dadurch entsteht oft der Eindruck, dass man Arbeit für ein Produkt investiert, die jemand anderem Geld einbringt. Das führt häufig dazu, dass die hauptsächliche Entwicklung in dem jeweiligen Unternehmen erfolgt und nur kleine Teile von externen Entwicklern beigesteuert werden.

2.5 Unternehmenssicht von Open Source

Aus Unternehmenssicht ist eine Open Source Software neben den finanziellen Aspekten vor allem interessant, da man nicht abhängig von einem bestimmten Hersteller ist. Bei proprietärer Software ohne freien Zugang zum Quellcode ist es nicht mehr möglich, diese selbst weiter zu entwickeln, wenn dieses Produkt vom Hersteller abgekündigt ist. Dieses stellt gerade bei großen Investitionen in eine Software ein erhebliches Problem für ein Unternehmen dar, da man selbst keinen Einfluss auf den Fortbestand des Herstellers hat und somit nahezu vollkommen abhängig von diesem ist. Dieses betrifft nicht nur die Weiterentwicklung, sondern kann auch nahezu willkürliche Erhöhungen von Softwarewartungsverträgen mit sich bringen, wie dieses in letzter Zeit von SAP^[15] versucht wurde. Bei der Nutzung von Open Source Software steht es jedem frei, jemandem mit der Erweiterung oder Entwicklung zu beauftragen. Bei kommerziellen Softwareprodukten kann eine Änderung nur vom jeweiligen Hersteller vorgenommen werden oder von lizensierten Partnern, die Module für die Software entwickelt haben. Außerdem kann es sich für eine Firma auch finanziell lohnen, die Entwicklung einer bestimmten Software mit eigenen Entwicklern zu unterstützen als eine vollständige Eigenentwicklung vorzunehmen. Dadurch kann man außerdem von Entwicklungen anderer profitieren.

Für viele Unternehmen scheint es am einfachsten zu sein, ein System „Out-of-the-Box“ zu verwenden. Dieses hat aber zur Folge, dass ein Unternehmen seine Prozesse auf das System anpassen muss. Je eingefahrener ein Prozess in einem Unternehmen ist, desto schwieriger ist es, diesen zu ändern. Es liegt in der Natur der Sache, dass viele Mitarbeiter eines Unternehmens sich gegen neue oder veränderte Dinge mit allen möglichen Mitteln wehren. Daher ist es besonders wichtig, dass jedes Workflow-Projekt mit Unterstützung des Managements durchgeführt wird.

„Out-of-the-Box“-Systeme sollten aber in Bereichen eingesetzt werden, die nicht zur Kernkompetenz eines Unternehmens zählen. Besonders Punkte wie das Personalwesen oder die Buchhaltung sind in den meisten Unternehmen keine Kernkompetenzen und können mit Standardworkflows normalerweise gut abgedeckt werden. Bereiche, die nicht mit Standards abgedeckt werden können, sollten über flexible Erweiterungsmöglichkeiten des Workflowsystems abgedeckt werden können.

Für spezifische Anforderungen ist es manchmal auch notwendig, ganze Module individuell zu erstellen. Um möglichst ein großes Spektrum mit einem System abdecken zu können ist es sinnvoll, wenn dieses schon im Standard verschiedenste Schnittstellen zu Fremdsystemen beinhaltet und über Schnittstellen flexibel erweitert werden kann, ohne die eigentliche Software zu verändern. Auch wenn es bei Open Source Software möglich ist, diese vollkommen individuell an die eigenen Bedürfnisse anzupassen, so verbaut man sich die Möglichkeit, diese später durch eine neue Version zu updaten. Dieser Spagat zwischen einer hoch angepassten Software, die optimal auf ein Unternehmen zugeschnitten ist oder möglichst schnell von Weiterentwicklungen und neuen Features der Community zu profitieren ist die Kunst bei jeder Nutzung von Open Source Software.

2.6 Theoretische Workflow Grundlagen am Beispiel von YAWL

2.6.1 YAWL

Hinter dem Kunstwort YAWL verbirgt sich das Akronym „Yet Another Workflow Language“. Dieses Workflow-Management-System wurde von Wil van der Aalst und seinem Team an der Eindhoven University of Technology in Holland entwickelt. YAWL ist sowohl eine Java-Software und Engine zur Erstellung von Workflow-Prozessen als auch eine eigene Prozessbeschreibungssprache. Die komplette XML-Syntax ist in XML-Schemas spezifiziert, welche durch den YAWL-Editor erstellt werden kann. Die Darstellung von YAWL basiert im Wesentlichen auf den Mathematischen Grundlagen von Petri-Netzen, die in den 1960er Jahren von Adam Petri entwickelt wurden^[16]. Genauer gesagt ist YAWL eine Erweiterung der Petri-Netze mit Workflowspezifischen Mechanismen.

2.6.2 Die YAWL Sprache

Ein Workflow in YAWL wird mit „Workflow Nets“ beschrieben. Diese basieren direkt auf Petri-Netzen, mit dem wesentlichen Unterschied, dass diese immer einen Startpunkt und einen Endpunkt haben. Jede Veränderung, die in einem Workflow abgebildet wird, passiert zwischen diesen Start- und Endpunkten. Des Weiteren darf es in YAWL keine „dead tasks“ geben, also Workflows die zwar am Startpunkt beginnen, jedoch durch ein unerwartetes Ereignis den Endpunkt nie erreichen werden. Nach diesem Muster lässt sich ein Prozess auf Korrektheit überprüfen. Der einfachste Prozess ist die Verbindung von Start- und Endpunkt. Obwohl dieser keinerlei Zustandsänderungen hat, ist es dennoch ein vollwertiger Workflow und ist ein gültiger Prozess.

Jede Workflow-Spezifikation besteht aus einem Set von Prozessdefinitionen. Diese bestehen aus Tasks (Aufgaben) und Conditions (Bedingungen) und Kontrollstrukturen. Eine Condition ist ein Ort für einen bestimmten Zustand. Ein Task bzw. Aufgabe ist ein notwendiger Arbeitsschritt und muss immer von einer Person oder einem automatischen System bearbeitet werden. Dieser kann in YAWL entweder ein „Atomic task“, der eigenständig arbeitet, oder „Composite task“ sein und sowohl aus mehreren Instanzen bestehen als auch auf eine Prozessdefinition in einer tieferen Ebene der Hierarchie verweisen. Die folgenden Symbole werden in YAWL für Kontrollstrukturen benutzt:

2.6.2.1 Atomic Task

Abbildung in dieser Leseprobe nicht enthalten

Ein „Multiple Instance Task“ ist nahezu identisch mit einem Atomic Task, jedoch kann dieser in mehreren Instanzen ausgeführt werden. Diese Instanzen werden zur Laufzeit des Workflows automatisch ausgeführt und bieten die Möglichkeit, einen Arbeitsschritt mehrfach auszuführen und die Ergebnisse miteinander zu verknüpfen. Dabei kann je nach Definition als Zielbedingung sowohl die Beendigung einer Instanz als auch die Beendigung aller Instanzen als Erfüllung dieser Aufgabe gewertet werden.

2.6.2.3 Composite Task

Abbildung in dieser Leseprobe nicht enthalten

Diese Art von Task ist eine Zusammensetzung von mehreren Teilaufgaben und verweist auf ein anderes Netzwerk, das dem aktuellen untergeordnet ist und in einer niedrigeren Hierarchie steht. Dort ist die Art und Weise beschrieben, wie diese Aufgabe implementiert ist.

2.6.2.4 Composite multiple instance task

Abbildung in dieser Leseprobe nicht enthalten

Diese Art von Task ist vom Grundsatz her identisch wie der Composite Task, kann jedoch aus mehreren Instanzen bestehen. Dabei kann je nach Definition als Zielbedingung, wie bei dem „Multiple instance task“ auch, sowohl die Beendigung einer Instanz als auch die Beendigung aller Instanzen als Erfüllung dieser Aufgabe gewertet werden.

2.6.2.5 Condition

Abbildung in dieser Leseprobe nicht enthalten

Eine Condition ist eine Bedingung und speichert das Ergebnis einer Aufgabe. Diese wird normalerweise zwischen 2 Aufgaben verwendet. Wenn 2 Aufgaben jedoch direkt verbunden sind, ist es so, als wäre zwischen diesen beiden Aufgaben eine „unsichtbare“ Condition eingebunden.

2.6.2.6 Input condition

Abbildung in dieser Leseprobe nicht enthalten

Eine Input condition definiert einen Startpunkt in einem Workflow oder einem verschachtelten Teilprozess. Dabei darf in jedem Netzwerk nur eine Startbedingung vorkommen. Sobald mehrere Startbedingungen existieren, ist ein Workflow nicht mehr möglich.

2.6.2.7 Output condition

Abbildung in dieser Leseprobe nicht enthalten

Eine Output condition definiert einen Endpunkt in einem Workflow oder einem verschachtelten Teilprozess. Dabei darf in jedem Netzwerk nur eine Endbedingung vorkommen. Sobald diese erreicht ist, ist der gesamte Prozess abgeschlossen.

2.6.2.8 AND join

Abbildung in dieser Leseprobe nicht enthalten

Bei jedem Task können zusätzlich Eingangsbedingungen eingefügt werden. Diese sind nützlich, wenn mehr als eine Verzweigung an diesem Task wieder zusammenläuft. Mit einem AND-join müssen alle eingehenden Zweige erfüllt sein, damit die entsprechende Aufgabe ausgeführt werden kann.

2.6.2.9 OR join

Abbildung in dieser Leseprobe nicht enthalten

Bei einem OR-join muss mindestens ein Zweig erfüllt sein. Dabei können sowohl nur einer, als auch mehrere oder alle zusammen gültig sein und die entsprechende Aufgabe kann ausgeführt werden.

2.6.2.10 XOR join

Abbildung in dieser Leseprobe nicht enthalten

Im Gegensatz zum OR darf beim XOR (Exklusives Oder) nur maximal eine Bedingung erfüllt sein. Sobald mehr als ein Zweig gültig ist, ist die Bedingung nicht mehr erfüllt.

2.6.2.11 AND split

Abbildung in dieser Leseprobe nicht enthalten

Wenn bei einer ausgehenden Verzweigung der Task ein AND-split besitzt, wird der sogenannte Kontrollprozess an alle ausgehenden Verzweigungen übertragen. Damit können bei nachfolgenden Tasks die Join-Bedingungen entsprechend erfüllt werden.

2.6.2.12 OR split

Abbildung in dieser Leseprobe nicht enthalten

Bei einem OR-split wird der Kontrollprozess mindestens einem Zweig übergeben. Bei der nächsten Aufgabe wird entschieden, welcher Zweig diese Kontrollfunktion jetzt hat.

2.6.2.13 XOR split

Abbildung in dieser Leseprobe nicht enthalten

Bei einem XOR-split wird der Kontrollprozess nur an einen Zweig übergeben. Dieser muss mindestens und darf höchstens ein Zweig sein. Bei der nächsten Aufgabe wird entschieden, welcher Zweig diese Kontrollfunktion jetzt hat.

2.6.3 Datenverwaltung in YAWL

Neben verschiedenen Grunddatentypen wie String, Boolean, Double und Date ist es möglich, beliebige komplexe Datentypen per XML Schema zu definieren. Diese Daten werden dazu benutzt, um Informationen zwischen verschiedenen Instanzen und Prozesskomponenten auszutauschen. Im Folgenden werden beispielhaft 3 verschiedene Datenelemente erläutert:

2.6.3.1 Netz-Variablen

Netzvariablen sind zu einer bestimmten Instanz eines YAWL-Netzes gebunden. Zur Laufzeit wird eine neue Instanz von Netzvariablen für jede Instanz eines YAWL-Netzes generiert. Diese Variableninstanz bleibt zur gesamten Laufzeit des Netzes erhalten.

2.6.3.2 Task-Variablen

Task-Variablen sind immer an einen bestimmten Task gebunden. Zur Laufzeit werden für jeden Task auch entsprechende Task-Variablen erzeugt. Diese sind nur innerhalb des entsprechenden Tasks verfügbar und können nicht aus anderen Prozessteilen abgerufen oder verändert werden.

2.6.3.3 Multiple-Instanzvariablen

Diese Variablen sind an einer definierten Instanz einer „Multiple-Instanz“ gebunden. Diese Variablen können von allen korrespondierenden Tasks der Instanz benutzt werden.

2.6.4 Architektur des YAWL-Systems

Nachfolgend wird die Architektur des YAWL-Systems erläutert sowie die Bestandteile des Frameworks mit den entsprechenden Technologien beschrieben.

Abbildung 14 - YAWL Architektur aus [Aalst1] Arthur H.M. ter Holstede et al., 2010

Das System ist modular aufgebaut und besteht aus folgenden Komponenten:

2.6.4.1 YAWL-Engine

Die Engine ist zentraler Bestandteil von YAWL. Sie instanziiert einen Workflow und überwacht dessen Ausführung. Weitere Komponenten des YAWL-Systems sind über definierte Schnittstellen mit dieser Komponente verbunden.

2.6.4.2 Process Designer

Der Prozessdesigner dient dem Benutzer als grafisches Tool zur Erstellung von neuen Workflowspezifikationen. Diese werden anschließend von der YAWL-Engine überprüft und zur Ausführung im Repository angelegt.

2.6.4.3 Web Service Invoker

Der Web Service Invoker dient als Schnittstelle zu anderen Systemen und ist ausschließlich für die Bereitstellung von Webservices zuständig.

2.6.4.4 Worklet Service

Der Worklet Service umfasst 2 Teile. Zum einen stellt dieser Dienst Resourcen für die Ausführung von Instanzen und Multiplen-Instanzen bereit und außerdem werden dort Ausnahmen behandelt. Diese Ausnahmen sind Ereignisse, die außerplanmäßig in einem Workflow auftreten. Dazu zählen keine definierten Ereignisse des Workflows, sondern Fehler in Schnittstellen oder Programmierfehler.

3 Auswahl von Systemen

Der Fokus dieser Arbeit liegt auf Open Source Workflow Systemen. Daher wird nur Software ausgewählt, die entsprechend den Grundsätzen der OSI lizensiert sind. Des Weiteren sollte das entsprechende Produkt eigenständig nutzbar sein und sämtliche Komponenten, die für einen vollständigen Prozess benötigt werden, enthalten. Dabei wird vor allem keine Software berücksichtigt, die nur als Modul in andere Projekte eingebunden werden kann und nur das Kernsystem eines Workflows bereitstellt. Außerdem sollte ein Anwender über eine GUI selbst in der Lage sein, Prozesse ohne Programmierkenntnisse anzupassen zu können, da sich im Laufe der Zeit die Bedürfnisse ständig verändern und die Prozesse an neue Anforderungen anpasst werden müssen.

3.1 Sonstige WfMS-Systeme

Nachfolgend ist eine Übersicht verschiedener Systeme, die im Rahmen dieser Arbeit kurz untersucht wurden, jedoch den oben genannten Kriterien nicht entsprechen und somit im weiteren Verlauf dieser Arbeit kein Fokus auf diese Systeme gesetzt wird. Die folgende Liste ist nur ein kleiner Auszug der Systeme, die außer den getesteten Workflowsystemen am Markt existieren.

3.1.1 jBPM

Hersteller: jBOSS

URL: http://www.jboss.org/jbpm/

Lizenz: Engine in JGPL, Designer in EPL, Modeller in MIT

Bei jBPM gibt es 3 Möglichkeiten Prozesse zu modellieren. Zum einen über ein Eclipse Plug-In mit dem Namen „Drools Flow“. Außerdem gibt es ein jBPM5-Eclipse Plug-In, welches zurzeit noch in der Entwicklungsphase steht und es können nur einfache Prozesse mit diesem Tool designt werden. Außerdem gibt es noch einen Web-Basierten Designer, den „Orxy Designer“, welcher die Erstellung und Bearbeitung von Prozessen ohne aufwendige Eclipse Installation ermöglicht.

jBPM kann keine Aufbauorganisation verwalten. Alles wird einem „Actor“ zugeordnet. Dieser kann entweder eine Person, eine Gruppe oder Applikation sein. Die eigentliche Organisation muss per BPML erstellt werden. Da der Fokus von jBPM auf der Integration in anderen Java-Produkten liegt und nicht eigenständig nutzbar ist, wird in dieser Arbeit diese Software nicht weiter betrachtet.

3.1.2 cuteflow

Hersteller: Timo Haberkern

URL: http://cuteflow.org/

Lizenz: BSD

Cuteflow ist ein Workflowsystem, das primär dazu entwickelt wurde, die klassische Postverteilung in einem Unternehmen per Software abzubilden. Dazu können entsprechende Verteilergruppen angelegt werden, zu denen Eingangsdokumente verteilt werden. Dabei kann jeder Empfänger vorgegebene Felder mit eigenen Daten befüllen und anschließend wird das Dokument zu einem weiteren Empfänger durchgereicht. Das System ist jedoch kaum anpassbar, deckt nur eine sehr spezifische Workflow-Aufgabe ab und kann für andere Arten von Workflows nicht benutzt werden. Daher wird diese Software im weiteren Verlauf der Arbeit nicht betrachtet.

3.1.3 Bossa Workflow

Hersteller: bigboss

URL: http://www.bigbross.com/bossa/

Lizenz: GPL

Bossa Workflow ist komplett in Java implementiert und benötigt keine relationale Datenbank zur Speicherung der Zustände. Der Fokus liegt aber, ähnlich wie bei jBOSS auch, auf der Integration in andere Java-Applikationen. Daher wird diese Software im weiteren Verlauf der Arbeit nicht betrachtet.

3.1.4 Imixs Workflow

Hersteller: Imixs

URL: http://www.imixs.org/

Lizenz: GPL

Imixs Workflow basiert auf einem Java/JEE-Modell. Die Modellierung der Prozesse erfolgt über ein Eclipse-Plug-In. Ohne Programmierung in Java ist diese Software nicht produktiv einsetzbar, da keine Benutzerverwaltung oder Formulardesigner enthalten sind und der Fokus dieses Systems auf der Engine liegt, welche BPMN-Workflows ausführen kann.

3.1.5 Interleave

Hersteller: Interleave

URL: http://www.interleave.nl/en/

Lizenz: GPL

Obwohl Interleave seine Plattform als Workflowsystem anbietet, ist es eher eine Universalplattform. Mit dieser Plattform hat man zwar die Möglichkeit, verschiedene Workflows „out-of-the-box“ abzubilden, jedoch ist dieses ohne Anpassung der Programmierung auf wenige Workflowbereiche stark begrenzt. Ein möglicher Bereich ist das Bearbeiten von Tickets nach ITIL-Standard, der in diesem Tool relativ ausgeprägt ist. Weitergehende Möglichkeiten und völlig individuelle Workflows sind jedoch mit dieser Plattform nicht möglich. Daher wird diese Software im weiteren Verlauf der Arbeit nicht betrachtet.

3.1.6 Andere Projekte

Neben den oben aufgeführten Projekten gibt es im Internet noch eine ganze Reihe von anderen Produkten, die sich als WfMS ausgeben. Dazu gehört zum Beispiel das Projet Sluice, welches auf freshmeat.net gehostet wird. Das Projekt wurde im Jahr 2000 begonnen und hat das letzte Release 2004 gehabt. Da offensichtlich seit über 7 Jahren niemand an diesem Projekt gearbeitet hat, sind entsprechende Projekte, die nicht mehr aktiv gepflegt werden, für einen produktiven Einsatz in einem Unternehmen nicht verwendbar und werden daher auch nicht im Einzelnen in dieser Arbeit aufgezählt und auch nicht weiter betrachtet.

3.2 Auswahl von entsprechender Software

Folgende Produkte wurden zur detaillierten Betrachtung für diese Arbeit ausgewählt:

3.2.1 Processmaker

Hersteller: Colosa Inc.

URL: http://www.processmaker.com/

Lizenz: GNU Affero General Public License Version 3

Version: 2.0

Processmaker basiert auf dem WAMP bzw. LAMP Stack und nutzt Web-Techniken. Neben der OpenSource-Version als Community-Edition gibt es eine Enterprise Edition. Als besondere Funktionen werden von den Entwicklern der vollständig Webbasierte Prozessdesigner und die Integration eines Dokumentenmanagementsystems dargestellt. In diesem Zusammenhang gibt es außerdem ein Tool, zur Erzeugung von Dokumenten aus den Daten eines Workflows. Diese Besonderheit wird jedoch im weiteren Verlauf dieser Arbeit nicht betrachtet.

3.2.2 Joget

Hersteller: Open Dynamics Sdn Bhd

URL: http://www.joget.org

Lizenz: GPLv3

Die Software Joget wurde von der Firma Open Dynamics aus Malaysia erstellt und ist ein relativ junges Produkt, welches in der Version 1 im November 2009 auf Soureforge veröffentlicht wurde. Das System ist vollständig webbasiert und beinhaltet nach Aussage der Entwickler alle Module, die ein WfMS benötigt. Dazu zählen auch Module wie ein Benutzermanager und Formulardesigner, die vollständig in der Oberfläche von Joget integriert sind.

3.2.3 Bonita Open Solution

Hersteller: BonitaSoft

URL: http://www.bonitasoft.org

Lizenz: GPLv2

Die Firma BonitaSoft wurde 2001 von Miguel Valdés Faura gegründet und die Software ist von Anfang an als OpenSource Projekt gestartet. Nach eigenen Angaben wurde diese bereits mehrere hunderttausend Mal^[17] heruntergeladen. BonitaSoft versucht seit 2009 eine Community aufzubauen und hat dazu ein Forum, Blogs, Wiki und Bugreporter bereitgestellt. Das Forum ist mit ca. 4000 Beiträgen ziemlich belebt.

[...]

^[1] Vgl. [Hub03] Robert Winter Hubert Österle, 2003

^[2] [Gab1], 2011

^[3] WfMC (Workflow Management Coalition) ist eine 1993 gegründete non-profit Organisation, welche sich zum Ziel gesetzt hat, Workflowstandard zu schaffen und zu verbreiten.

^[4] [WfMC1], 1999

^[5] [Schn1] R. Schnetzer, 1999

^[6] [ITw1], 2011

^[7] [Joh97] John Wiley and Sons, 1997

^[8] Vgl. [Joh97] John Wiley and Sons, 1997

^[9] Vgl. [OSI1], 2011

^[10] Vgl. [MS1], 2011

^[11] www.icinga.org

^[12] Nagios ist lange Jahre die am meisten genutzte Open Source Software zur Überwachung von IT-Systemen gewesen

^[13] Vgl. [Heise1], 2009

^[14] Vgl. [mysql1], 2010

^[15] SAP ist mit ca. 50.000 Mitarbeitern und einem Jahresumsatz von ca. 13 Mrd. € einer der weltweit größten Hersteller von Unternehmenssoftware

^[16] Vgl. [Ulr88] Ulrich Grude, 1988

^[17] http://www.bonitasoft.com/company/overview.php