Einführung eines Workflow-Management-Systems bei einem Verlagsdienstleister unter Berücksichtigung des prozessnahen Wissens-Managements

Diplomarbeit im Studiengang Druck- und Medientechnologie Einführung eines Workflow-Management-Systems bei einem Verlagsdienstleister unter Berücksichtigung des prozessnahen Wissens-Managements vorgelegt von Gregor Fellenz an der Hochschule der Medien Stuttgart am 31. Oktober 2006 Erstprüfer: Prof. Dr. Edmund Ihler Zweitprüfer: Marko Hedler (pagina GmbH)

Kurzfassung Die Komplexität von Arbeitsabläufen nimmt ständig zu. Gleichzeitig steigt auch der Koordinationsund Dokumentationsaufwand der Abläufe. Es besteht die Gefahr, dass die Prozesse nicht mehr fehlerfrei und produktiv durchgeführt werden können. Workflow-Management kann hier die Organisation verbessern und den Verwaltungsaufwand reduzieren. Ein Wissens-Management hilft, die internen Prozesse zu dokumentieren und weitere wichtige Informationen zu sichern. Ziel ist es, einen höheren Grad an Fehlerfreiheit und Zuverlässigkeit zu erreichen. Diese Diplomarbeit vermittelt einen Überblick derzeit aktueller Open-Source Workflow- und Wiki- Systeme, die für Enterprise Applikationen geeignet sind. Dazu werden Kriterien aufgestellt, an denen eine Auswahl von Produkten evaluiert wird. Weiterhin wird eine Konzeption für ein integriertes Workflow- und Wissens-Management entworfen. Die Arbeit wird durch ein praktisches Beispiel begleitet, das die Praktikabilität der entwickelten Konzepte unter Beweis stellt.

Erklärung Hiermit versichere ich, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst habe. Sämtliche verwendeten Quellen wurden von mir im Text nachgewiesen. Die in dieser Arbeit ausgewerteten Materialien der pagina GmbH wurden von mir mit Einverständnis der pagina GmbH verwendet. Stuttgart, am 30. Oktober 2006 Gregor Fellenz

Erklärung Hiermit versichere ich, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst habe. Sämtliche verwendeten Quellen wurden von mir im Text nachgewiesen. Die in dieser Arbeit ausgewerteten, vertraulich zu behandelnden Materialien der pagina GmbH, wurden von mir mit Einverständnis der pagina GmbH verwendet. Stuttgart, am 30. Oktober 2006 Gregor Fellenz

Amistades que son ciertas nadie las puede turbar. Miguel de Cervantes Saavedra (1547 1616) Don Quixote de la Mancha

Vorwort Diese Diplomarbeit entstand bei der Firma pagina GmbH, Tübingen, wo ich von allen Kollegen tatkräftig unterstützt wurde. Besonderer Dank gilt meinen Betreuern, Herrn Marko Hedler auf Firmenseite, sowie Herrn Prof. Dr. Edmund Ihler, der mich seitens der Hochschule der Medien Stuttgart, betreute. Dank gilt auch meinen Eltern, die mich während meines ganzen Werdegangs unterstützt und gefördert haben, und der Hans Böckler Stiftung, die mir ein finanziell unabhängiges Studium ermöglichte. Weiterhin möchte ich meinem Freund Stefan Krüger, der mich durch seine kritische Auseinandersetzung mit meinen Ideen unterstützte, und vielen weiteren Freunden, die mich motivierten und mit Ideen bereicherten, danken. Stuttgart, im Oktober 2006 Gregor Fellenz

Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Listings vi vii ix Einführung 1 Aufgabenstellung......................................... 1 Generelle Bedeutung....................................... 1 Einordnung der Problematik.................................. 2 Ziel der Arbeit.......................................... 3 Aufbau der Arbeit........................................ 3 Grundlagenteil....................................... 3 Evaluation und Implementierung............................. 3 1 Workflow-Management 4 1.1 Geschäftsprozess...................................... 4 1.1.1 Begriff und Definition............................... 4 1.1.2 Geschäftsprozess-Management.......................... 5 1.2 Workflow.......................................... 6 1.2.1 Begriff und Definition............................... 6 1.2.2 Workflow-Typen.................................. 7 1.3 Workflow vs. Geschäftsprozess............................... 8 1.4 Workflow-Management................................... 9 1.4.1 Begriff und Definition............................... 9 1.5 Workflow-Management-Systeme.............................. 10 1.6 WfMC Referenzmodell................................... 11 1.6.1 Workflow-Enactment-Service........................... 11 1.6.2 Interface 1...................................... 12 1.6.3 Interface 2...................................... 13 1.6.4 Interface 3...................................... 13 1.6.5 Interface 4...................................... 13 1.6.6 Interface 5...................................... 14

Inhaltsverzeichnis iii 1.7 Workflow-Schema...................................... 14 1.7.1 Metamodell..................................... 14 1.7.2 Grafische Notationen................................ 16 1.7.3 Ausführungssprachen................................ 18 2 Wissens-Management 24 2.1 Wissensarten........................................ 24 2.1.1 Wissen........................................ 24 2.1.2 Wissenskategorien................................. 25 2.1.3 Wissensträger.................................... 26 2.2 Kernaufgaben des Wissens-Managements........................ 27 2.2.1 Handlungsbedarf.................................. 27 2.2.2 Kernaufgaben.................................... 27 2.2.3 Wissensbasis eines Unternehmens......................... 28 2.3 Instrumente und Methoden................................ 29 2.3.1 Prozesssicht..................................... 29 2.3.2 Organizational Learning und Organizational Memory............. 29 2.3.3 Wissensrepräsentation............................... 29 2.3.4 Content-Management............................... 30 2.3.5 Wissens-Management-Systeme.......................... 30 2.4 Wikis als Wissens-Management-Systeme......................... 31 2.4.1 Einführung Wikis.................................. 31 2.4.2 Wissens-Management: Lösungen mit Wikis................... 33 3 Analyse 34 3.1 Ausgangssituation und Zielsetzung............................ 34 3.2 Anforderungsanalyse an ein Workflow-Management-System mit prozessnahem Wissens-Management......................... 35 3.2.1 Grundsätzliche Anforderungen an die Produkte................. 36 3.2.2 Anforderungen Workflow-Software........................ 36 3.2.3 Anforderungen Wiki-Software........................... 39 3.3 Voraussetzungen der pagina GmbH............................ 41 3.3.1 Unternehmensweite Aspekte............................ 41 3.3.2 Vorhandene Software................................ 41 3.3.3 Wünsche aus der täglichen Arbeit........................ 42 3.4 Anforderungsanalyse der pagina GmbH an das System................. 42 3.4.1 Spezifische Anforderungen an das System.................... 42 3.4.2 Anforderungen für die 2. Ausbaustufe...................... 43 3.5 Workflow-Beschreibung Strukturoffensive........................ 44 3.5.1 Hinweise zur Workflow-Modellierung....................... 45

Inhaltsverzeichnis iv 3.5.2 Auftragsannahme.................................. 45 3.5.3 Kernprozess Satzworkflow............................. 48 3.5.4 Auftragsabschluss................................. 52 4 Evaluation 54 4.1 Ausgewählte WfMS.................................... 54 4.1.1 Enhydra Shark................................... 55 4.1.2 JBoss jbpm.................................... 55 4.1.3 Bonita........................................ 56 4.2 Ausgewählte Wiki-Software................................ 57 4.2.1 SnipSnap...................................... 57 4.2.2 Mediawiki...................................... 58 4.3 Evaluation der Produkte.................................. 59 4.3.1 Grundsätzliche Anforderungen an die Produkte................. 60 4.3.2 Workflow-Software................................. 60 4.3.3 Wiki-Software.................................... 62 4.4 Fazit............................................. 62 4.4.1 Workflow-Software................................. 62 4.4.2 Wiki-Software.................................... 64 4.4.3 Integration..................................... 64 4.4.4 Aufwandsabschätzung............................... 65 5 Konzeption 66 5.1 Software Architektur.................................... 66 5.2 Benutzerverwaltung.................................... 68 5.3 Workflow-Management................................... 69 5.3.1 Workflow-Schemata................................ 69 5.3.2 Workflow-Client.................................. 69 5.3.3 Externe Applikationen............................... 70 5.3.4 Administration................................... 70 5.4 Wissens-Management................................... 71 5.4.1 Workflowpool.................................... 71 5.4.2 Wissenspool..................................... 71 5.4.3 Expertenpool.................................... 72 5.5 Integration......................................... 73 5.5.1 Webclient...................................... 73 5.5.2 Anwendungslogik.................................. 73 5.5.3 SnipSnap-Plugin.................................. 74 5.6 Fazit............................................. 74

Inhaltsverzeichnis v 6 Implementierung 76 6.1 Projektdaten und Source-Code.............................. 76 6.2 Programmierung des Systems............................... 76 6.2.1 Preferences und Logging.............................. 77 6.2.2 Navigationsstruktur................................ 78 6.2.3 Layout Anpassungen................................ 78 Exkurs Java Server Faces................................. 79 6.2.4 Workflow-Management Webinterface....................... 81 6.2.5 Einrichtung des WMS............................... 90 6.2.6 SnipSnap-Plugin WriterPlugin.......................... 93 6.2.7 SnipSnap-Makro Comment............................ 95 6.2.8 Zusätzliche Anwendungslogik als Library.................... 96 6.3 Implementierung des Workflows Strukturoffensive.................... 98 6.3.1 jpdl-workflow-modellierung........................... 98 6.3.2 jpdl Action Handler............................... 101 6.4 Fazit............................................. 102 7 Zusammenfassung und Ausblick 103 7.1 Abschließendes Fazit.................................... 103 7.2 Ausblick........................................... 104 7.2.1 Tiefere Integration von WfMS und WMS.................... 104 7.2.2 Spezifische Weiterentwicklung für die Firma pagina............... 105 Abkürzungsverzeichnis 109 Literaturverzeichnis 111 A Anhang I A.1 Installationsanleitung................................... I A.1.1 Installation von CD................................ I A.1.2 Graphical Process Designer installieren..................... V A.2 guapa Benutzerhandbuch................................. VI A.2.1 Workflow jbpm.................................. VI A.2.2 Wiki SnipSnap................................... VIII A.2.3 Workflow-Modellierung.............................. XI A.3 Quellcode.......................................... XV A.3.1 jpdl-workflows.................................. XV

Abbildungsverzeichnis 1.1 Abgrenzung der idealen IT-Unterstützung für verschiedene Workflow-Typen..... 8 1.2 Zusammenhang der Begriffe des Workflow-Managements................ 11 1.3 Workflow-Referenzmodell und Schnittstellen [Hol95].................. 12 1.4 Workflow-Meta-Modell der WfMC [Hol95, S. 30].................... 14 1.5 Visuelle Darstellung von BPMN Flow Objects...................... 17 1.6 Visuelle Darstellung von BPMN Connecting Objects.................. 17 1.7 Visuelle Darstellung von BPMN Swimlanes....................... 18 1.8 Darstellung der Datei beispiel.xpdl durch den Open-Source Editor JPEd..... 20 2.1 Zusammenhang der verschiedenen Ebenen des Wissens................. 25 2.2 Vereinfachte Übersicht über die Wissensbausteine nach Probst, Raub und Romhardt 28 3.1 Der Prozess Strukturoffensive aus herstellerischer Sicht................. 44 3.2 Grafische Darstellung des Workflows Auftragsannahme (basierend auf jpdl).... 46 3.3 Prozessbild des Satzworkflows (basierend auf jpdl).................. 50 3.4 Prozessbild des Workflows Auftragsabschluss (basierend auf jpdl).......... 52 4.1 Interaktion durch jbpm [Koe04]............................. 56 4.2 Wissensentwicklung durch Bewertung und Kategorisierung bei SnipSnap [Sch].... 58 5.1 Grafische Darstellung des Software Architektur Entwurfs................ 67 5.2 Benutzerverwaltung des WWS.............................. 68 5.3 Vorschlag für die Organisation des Wissens im Unternehmen pagina......... 72 5.4 Integrationsaufgabe des Webclients aus Benutzersicht................. 73 6.1 Screenshot des Grundlayouts mit Menüleiste im Bereich Workflow-Management... 78 6.2 Screenshot der Taskform.................................. 82 6.3 Screenshot der Instanziierung............................... 85 6.4 Screenshot der Benutzerverwaltung............................ 87 6.5 Screenshot aus dem Bereich Monitoring......................... 89 6.6 Screenshot der Einstiegsseite in das Wissensportal................... 90 6.7 Screenshot Prozessinstanz im Wiki............................ 91 6.8 Screenshot Workflow-Schema im Wiki.......................... 91 6.9 Screenshot Wissenspool im Wiki............................. 92 6.10 Übersicht über die Software Komponenten im WWS............. 102

Tabellenverzeichnis 1.1 Geschäftsprozess vs. Workflow............................... 9 2.1 Eigenschaften von Wissensträgern............................ 26 2.2 Wiki-Syntax der Wiki-Software MediaWiki....................... 32 4.1 Vergleich der grundsätzlichen Anforderungen an die Produkte............. 60 4.2 Evaluation der Workflow-Software............................ 61 4.3 Evaluation der Wiki-Software............................... 62 6.1 Befehlsreferenz des WikiWriter Plugins.......................... 93 A.1 Wiki-Syntax von SnipSnap................................ IX

Listings 1.1 XPDL Package....................................... 20 1.2 XPDL Process....................................... 21 1.3 XPDL Activity....................................... 21 1.4 XPDL Routing Activity.................................. 22 1.5 XPDL Transition...................................... 22 1.6 XPDL Participant..................................... 22 1.7 XPDL Application..................................... 23 1.8 XPDL Extended Attribute................................. 23 6.1 Beispiel einer Preferences-Datei für java.util.preferences................ 77 6.2 Zugriff auf eine Preferences-Datei............................. 77 6.3 Verwendung des Log4j Loggers.............................. 78 6.4 Deklaration der JSF-Tag-Libraries............................ 79 6.5 Anmeldung einer Managed-Bean und Navigation-Rule in der faces-config.xml.... 80 6.6 Bindung einer Java-Bean an UI-Komponenten...................... 80 6.7 Aufbau der Tasklist in xhtml............................... 81 6.8 Festlegung der Formulare in der Datei guapaforms.xml................. 82 6.9 Ausschnitt aus der Methode initialize der TaskBean.................. 83 6.10 Ausschnitt aus der Methode save der TaskBean..................... 84 6.11 Ausschnitt aus der Methode startprocessinstance der TaskBean............ 86 6.12 Ausschnitt aus der Methode deleteuser der UsermanagementBean.......... 87 6.13 SnipSnap-Makro snip-tree................................. 90 6.14 SnipSnap-Makro search.................................. 90 6.15 Methode init des WriterPlugins.............................. 93 6.16 Methode service des WriterPlugins............................ 94 6.17 Methode addsniplabel des WriterPlugins........................ 94 6.18 Methode execute für das SnipSnap Makro Comment.................. 95 6.19 Methode send2servlet des SnipSnapWikiWriters.................... 96 6.20 Methode tosnipsnapcodekunde des SnipSnapWikiWriters.............. 97 6.21 Methode lese der Klasse ReadAccessDatabase...................... 97 6.22 Start State und Einbindung eines Sub-Workflows in jpdl............... 99 6.23 Task Node in jpdl..................................... 100 6.24 Swimlane in jpdl..................................... 100 6.25 Fork und Join in jpdl................................... 100 6.26 Action Handler DBAuslesen................................ 101

Listings ix 6.27 Action Handler WikiWriter................................ 101 A.1 Umgebungsvariablen für den Betrieb des Systems.................... II A.2 Konfigurationseinstellungen in der Datei guapa.xml................... IV A.3 Beispiel für die Datei guapaforms.xml.......................... XIII A.4 jpdl-quellcode des Workflows Auftragsannahme.................... XV A.5 jpdl-quellcode des Workflows Strukturoffensive.................... XVII A.6 jpdl-quellcode des Workflows Auftragsabschluss.................... XXI

Einführung Aufgabenstellung Der Verlagsdienstleister pagina GmbH möchte ein System zum Workflow-Management (WfMS) einführen. Durch die mittelständische Struktur des Unternehmens und die individuelle und produktspezifische Struktur der Geschäftsprozesse muss das System eine überschaubare Komplexität und für die Integration in vorhandene und zukünftige Applikationen offene Standards und Schnittstellen bereitstellen. Für Dokumentationsaufgaben und zur Wissenssicherung des Unternehmens ist zusätzlich die Einbettung eines prozessnahen Wissens-Managements gefordert. Es ist eine Anforderungsanalyse für mögliche Systeme zu erstellen und anhand dieser eine Auswahl von Open-Source Workflow-Engines und Wissens-Management-Produkten zu evaluieren. Nötige Anpassungen und Erweiterungen der gewählten Systeme sind zu implementieren. Beispielhaft wird der Prozess Strukturoffensive mit einem geeigneten Workflow-Schema modelliert. Dieser Workflow wird im Rahmen der Diplomarbeit beim Unternehmen pagina eingeführt, wobei sich die Modellierung auf den Kerngeschäftsprozess beschränkt. Generelle Bedeutung Ein Ansatzpunkt für die Bereitstellung höherer Flexibilität und Qualität bei Produkten und Dienstleistungen unter gleichzeitig wachsendem Kostendruck ist die Zusammenarbeit in Netzwerken. Sowohl die Optimierung der internen Geschäftsprozesse durch ein Workflow-Management als auch die Bewirtschaftung von Informationen in einem Wissens-Management stellt eine zentrale Herausforderung für Unternehmen dar. In vielen Unternehmen und Organisationen sind die Arbeitsabläufe so komplex, dass die Koordination nicht mehr fehlerfrei und produktiv durchgeführt werden kann. Workflow-Management kann hier die Gesamtkosten senken, die Produktivität steigern und die Abarbeitung von Aufträgen beschleunigen. Wissen und Informationen über interne Prozesse und Abläufe sowie Kunden, Zulieferer und Partner sind in vielen Unternehmen nur schwach strukturiert bzw. nicht systematisch erfasst. Mit einem

Einführung 2 Wissens-Management wird das nötige Wissen eines Unternehmens gespeichert und für den späteren Abruf vorgehalten. Die Optimierung interner Prozesse und die Systematisierung von Wissen in kleinen und mittelständischen Unternehmen (KMU) ist allerdings eine besondere Problematik, da diese meist auf gewachsene Strukturen zurückgreifen, die systematisches Arbeiten erschweren. Außerdem sind die theoretischen Ansätze und Implementierungen meist auf große Unternehmen und komplexe Systeme ausgelegt und für KMU nicht sinnvoll einsetzbar. Bei einer hoch flexiblen Produktpalette sind sowohl Workflow-Elemente als auch Wissenseinheiten eng miteinander verwoben. Stark individuelle und produktspezifische Workflows stellen hier eine besondere Herausforderung dar. Eine einfach zu bedienende und an das spezifische Unternehmen angepasste Integration von Workflow- und Wissens-Management kann eine angemessene Lösung darstellen. Einordnung der Problematik Die Problematik gehört zum Bereich Business Engineering. Hier wird zwischen Strategie-, Geschäftsprozess- und Systemebene unterschieden (Winter in [OW03, S. 93ff]). Das wesentliche Gestaltungsziel der strategischen Ebene ist die ideale Positionierung des Unternehmens im Wertschöpfungsnetzwerk [OW03, S. 94]. Die Unternehmensstrategie ist also anhand von internen Stärken und Schwächen sowie an der externen Marktsituation auszurichten. In dieser Ebene wurden in der Arbeit von Ullrich [Ull06] strategische Handlungsoptionen für das Unternehmen pagina entwickelt. Auf der Prozessebene werden die Geschäftsprozesse und deren Interaktion beschrieben [OW03, S. 94]. Hier wird jeder Geschäftsprozess detailliert, die notwendigen Arbeitsschritte und deren Reihenfolge werden festgelegt. Ziel ist die optimale Organisation des jeweiligen Prozesses. Für den Prozess Strukturoffensive ist die Detaillierung und Optimierung der Wertschöpfungskette im Frühjahr 2006 erfolgt. Auf der Systemebene wird beschrieben, welche Teilprozesse und Arbeitsschritte durch welche Software unterstützt werden sollen [OW03, S. 94]. Die Ebene umfasst auch die Beziehungen der IT- Komponenten, Datenstrukturen und unterstützende Software untereinander. Auf der Systemebene ist demzufolge die Konzeption und Integration von Workflow-Management-Systemen anzusiedeln. Wobei die vorliegende Arbeit neben der konzeptionellen Bearbeitung der Systemebene auch die praktische Implementierung der Ergebnisse zum Ziel hat.

Einführung 3 Ziel der Arbeit Die dargestellte Strategie- und Prozessebene ist aktuell für das Unternehmen pagina erstellt worden, diese Arbeit beschreibt anhand der gewonnenen Ergebnisse die Systemebene und beginnt mit der Implementierung. Die Arbeit beinhaltet die Integration eines vorhandenen Open-Source Wissens-Management- Programms in ein Workflow-Management-System für ein mittelständisches Unternehmen. Die entstandene Middleware wird bei der Firma pagina GmbH installiert und unternehmensspezifische Erweiterungen werden implementiert. Zusätzlich werden weitere Tools und Schnittstellen für das System definiert und beschrieben. Die Implementierung aller gewünschten Features und aller Geschäftsprozesse würde allerdings den Rahmen dieser Arbeit sprengen. Aufbau der Arbeit Grundlagenteil Der erste Teil der Arbeit beschäftigt sich mit den theoretischen Grundlagen des Workflow- Managements. Hier werden die verwendeten Begriffe, Spezifikationen und Schnittstellen des Workflow- Managements definiert bzw. dargestellt. Im zweiten Teil wird der Bereich Wissens-Management definiert. Insbesondere wird der Bereich auf die für das Unternehmen pagina wesentlichen Bereiche Dokumentation und Wissenssicherung reduziert. Evaluation und Implementierung Der dritte Teil beinhaltet die Analyse der Anforderungen der dargestellten Systeme. Besonderes Augenmerk wird auf die vorhandenen Workflows, Schnittstellen und die Erweiterbarkeit gelegt. Im vierten Teil werden ausgewählte Open-Source Workflow-Management- und Wissens-Management- Lösungen anhand der im dritten Teil entwickelten Kriterien evaluiert. Neben den Kriterien (gewünschte Funktionen) liegt ein weiterer Schwerpunkt auf dem Implementierungsaufwand der Erweiterungen/Anpassungen. Im fünften Teil wird eine Konzeption des Systems entworfen, die sich an der Anforderungsanalyse orientiert und die Ergebnisse der Evaluation berücksichtigt. Der sechste Teil beschäftigt sich mit der Implementierung der im fünften Teil gewählten Lösung. Abschließend werden im siebten Teil die Ergebnisse zusammengefasst und ein Fazit gezogen. Die weiteren Schritte für das Unternehmen pagina werden dargestellt.

1 Workflow-Management Thou hast seen nothing yet. Miguel de Cervantes Saavedra (1547 1616) Don Quixote de la Mancha Dieses Kapitel beschäftigt sich mit den Grundlagen des Workflow-Managements. Zunächst werden die Begriffe Geschäftsprozess und Workflow eingeführt und voneinander abgegrenzt. Im weiteren Verlauf wird dann der allgemeine Aufbau von Workflow-Management-Systemen detailliert dargestellt. Ferner werden auch das Workflow-Referenzmodell sowie Notations- und Ausführungssprachen erläutert. 1.1 Geschäftsprozess 1.1.1 Begriff und Definition In der Literatur finden sich verschiedene Ansätze, den Begriff Geschäftsprozess einzugrenzen [Gad01, S. 29ff]. Aus Sicht des Business Reengineering wird der Begriff recht lose als eine Menge von Aktivitäten, die einen oder mehrere Inputs benötigen und ein Ergebnis für den Kunden bereitstellen, definiert. Die Steuerung übernimmt hier ein Verantwortlicher aus dem Kreis des oberen Managements [Gad01, S. 29]. Die Workflow Management Coalition (WfMC) 1 detailliert in ihrer Terminologie zur Standardisierung den Begriff Business Process etwas genauer: 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. [Wor99, S. 10] 1 Die Workflow Management Coalition wurde 1993 gegründet und ist ein Zusammenschluss von über 300 Firmen, Beratern, Forschungseinrichtungen und Nutzern. Hauptziel ist die Etablierung von Standards im Bereich Workflow-Management

1 Workflow-Management 5 Wichtig für die Begriffsverwendung in dieser Arbeit ist zusätzlich der Bezug zur strategischen Ebene des Unternehmens bzw. zum Unternehmensziel. Geschäftsprozesse sind immer auf das Unternehmensziel ausgerichtet und beschreiben einen Teil der Wertschöpfungskette, nicht jedoch deren detaillierte technische Implementierung [Mü05, S. 7]. Definition Ein Geschäftsprozess ist eine Folge von logisch zusammenhängenden Aktivitäten einer Wirtschaftseinheit, die ein bestimmtes Ergebnis anstreben. Zwischen dem definierten Anfang und Ende sind verschiedene Abläufe möglich, in denen unterschiedliche Aufgaben ausgeführt werden. Er dient der Erstellung von Leistungen entsprechend der vorgegebenen Unternehmensstrategie. 1.1.2 Geschäftsprozess-Management Aufgaben des Geschäftsprozess-Managements sind planerische, organisatorische und kontrollierende Maßnahmen zur Steuerung der Wertschöpfungskette eines Unternehmens. Die Maßnahmen des Geschäftsprozess-Managements werden hinsichtlich Qualität, Kosten, Zeit und Kundenzufriedenheit optimiert, im Mittelpunkt des Konzepts stehen die Kunden als Leistungsempfänger und die Mitarbeiter als Leistungserzeuger [Sch99b]. Die Ausführung ist technologieunabhängig, die Planung, Durchführung und Überwachung wird von einer Führungskraft übernommen. Die Arbeitsschritte können auch wenig formalisiert beschrieben sein. Ziel ist es, die unternehmensinternen Informationen über Arbeitsabläufe zu systematisieren, um die Unternehmensziele besser zu erreichen. Diese Herangehensweise hat nach Schnetzer [Sch99a, S. 15] folgende Schwachstellen: Ungenügende Informationen über laufende Prozesse Keine Systematisierung der Prozessinformationen (Dokumente, Parameter) Fehlende Integration über Abteilungsgrenzen und Funktionseinheiten hinweg Großer Koordinationsaufwand Dies führt zu Problemen bei der Organisation, Ausführung und Dokumentation von Geschäftsprozessen, weil viele Medienbrüche 2 zu bewältigen sind. Diese Schwachstellen sollen durch Workflow- und Wissens-Management mit einem verbesserten Informationsfluss und definierten Schnittstellen vermindert oder behoben werden. 2 Informationen werden in unterschiedlichen Medien gespeichert, z.b. papierbasierte Akten, e-mail-ordner und Dateien auf dem Fileserver.

1 Workflow-Management 6 1.2 Workflow 1.2.1 Begriff und Definition Auch der Begriff Workflow wird in der Literatur unterschiedlich definiert [Gad01, S. 30ff]. Jablonski stellt schon 1997 [Jab97, S. 490] die Verbindung von Workflow und Workflow-Management her und beschreibt einen Workflow als eine teilweise durch ein WfMS gesteuerte Gesamtheit von Aktivitäten, die sich auf Geschäftsprozesse beziehen. Die Begriffsbestimmung bezieht sich allerdings noch überwiegend auf Prozesse mit menschlichen Aufgabenträgern. Gadatsch legt in [Gad01, S. 31] eine sehr detaillierte Definition vor. Er beschreibt einen Workflow als formal beschriebenen und zumindest teilweise automatisierten Geschäftsprozess. Er muss fachliche, zeitliche und resourcenbezogene Spezifikationen beinhalten, die für eine automatisierte Steuerung erforderlich sind. Arbeitsschritte sind Anwendungsprogrammen oder Mitarbeitern zugeordnet. Weiterhin führt er den Begriff Workflow-Instanz ein, der die konkrete Ausführung eines Workflows bezeichnet. Die Definition der WfMC fasst die oben genannten Aspekte umfassend zusammen: 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. [Wor99, S. 8] Gemeinsam ist den meisten Begriffsbestimmungen die Sichtweise, dass der Workflow einen Geschäftsprozess technisch unterstützt und weiter spezifiziert. Daraus folgt allerdings nicht, dass er zwangsweise durch ein WfMS unterstützt werden muss [Mü05, S. 8]. Um den oben aufgestellten Anforderungen gerecht zu werden, beinhaltet ein Workflow: Aufgabenträger Gruppen, Personen und/oder Computersysteme. Ablauf der Aktivitäten Was in welcher Reihenfolge erledigt werden soll und welche Daten dazu benötigt werden. Arbeitsmittel Geräte oder Programme, die zur Erfüllung der Aufgabe genutzt werden.

1 Workflow-Management 7 Zusammenfassend wird in dieser Arbeit der Begriff Workflow wie folgt verwendet: Definition Ein Workflow ist eine formal beschriebene Summe von Aktivitäten, die sich auf Vorgänge eines Geschäftsprozesses bezieht. Jeder Workflow hat einen organisierten Ablauf der Aktivitäten zwischen definiertem Anfang und Ende. Die Aktivitäten werden Personen oder Computersystemen nach festgelegten Regeln zugewiesen. Workflows können durch Informations- und Kommunikationstechnik unterstützt werden. 1.2.2 Workflow-Typen Workflows lassen sich nach dem Grad ihrer Strukturierung und Wiederholbarkeit in verschiedene Typen unterteilen. Diese Unterteilung ist von Bedeutung, da sich daran auch die Eignung für Workflow-Management-Systeme ablesen lässt. Die WfMC unterteilt in vier verschiedene Workflow-Typen: Ad-hoc-Workflows beschreiben einmalige und/oder stark variierende Prozesse mit Projektcharakter. Collaborative Workflows unterstützen die gemeinsame Erstellung eines Ergebnisses, die Teamvernetzung steht im Vordergrund. Administrative Workflows beinhalten strukturierte Routineprozesse, die selten zeitkritisch und von geringem Geldwert sind. Production Workflows beschreiben fest strukturierte und vordefinierte Vorgänge, die zeitkritisch und von strategischer Bedeutung sind. Unter der Zielsetzung, die Eignung für eine IT-Unterstützung herauszuarbeiten, eignet sich die Aufteilung nach Picot besser (Vgl.[Mü05, S. 9ff] und [Bec99, S. 50ff]). Routineprozesse haben eine beständige und gut erkennbare Struktur. Der Ablauf ist standardisiert und es besteht ein hoher Grad an Arbeitsteilung. Alle Arbeitsschritte sind spezifiziert. Regelprozesse sind von kontrollierbarer Struktur und Komplexität, es kommt allerdings zu individuellen Veränderungen der Abläufe. Individuelle Prozesse sind jedoch gut vorhersehbar. Einmalige Prozesse sind weder vom Ablauf, noch von den Teilnehmern vorhersehbar. Diese Prozesse werden meist individuell von einem Bearbeiter betreut.

1 Workflow-Management 8 Mit dieser Aufteilung lässt sich eine gute Einteilung der Eignung für ein WfMS erstellen (Abb. 1.1). Je stärker ein Prozess standardisiert und vorhersehbar ist, desto eher kann er von einem WfMS unterstützt werden. Die Tiefe der Strukturierung stellt zwar keine technische Hürde dar, lässt aber aufgrund des hohen Aufwands der Implementierung den Nutzen einer IT-Unterstützung fraglich werden. Zu beachten ist allerdings, dass auch projektartige Ad-hoc-Workflows in ein WfMS integrierbar sind, das dann jedoch nur noch grobe Richtlinien im Sinne einer Checkliste bieten sollte. Abbildung 1.1: Abgrenzung der idealen IT-Unterstützung für verschiedene Workflow-Typen 1.3 Workflow vs. Geschäftsprozess Geschäftsprozesse und Workflows beschreiben Arbeitsabläufe, eine klare Abgrenzung ist zum Teil schwierig und in der Literatur werden die Begriffe oftmals vermischt oder sogar gleichgesetzt (Bspw. [Sch99a, S. 18]). Grundsätzlich lässt sich festlegen, dass Geschäftsprozesse abstrakt anhand der Unternehmensziele beschreiben, was zu tun ist, während Workflows beschreiben, wie etwas konkret umgesetzt werden soll [Gad01, S. 35]. Während Geschäftsprozesse beispielsweise nicht technisch abbildbare Aktivitäten wie die Motivation von Mitarbeitern enthalten, sind Workflows bezüglich Arbeitsverfahren, Hilfsmitteln und Ressourcen eindeutig.

1 Workflow-Management 9 Für diese Arbeit wird weiterhin ein Schwerpunkt auf die technische Verfeinerung gelegt, ein Workflow muss als Input bzw. Regelwerk für ein WfMS verwendbar sein. Eine Übersicht der Unterschiede in Anlehnung an Gadatsch findet sich in Tabelle 1.1 [Gad01, Seite 35]. Ziel Gestaltungsebene Detaillierungsgrad Geschäftsprozess Analyse und Gestaltung von Arbeitsabläufen im Sinne strategischer Unternehmensziele. Konzeptionelle Ebene in Verbindung zu den Unternehmenszielen. Von einem Mitarbeiter an einem Arbeitsplatz ausführbare Arbeitsschritte. Workflow Rezipient Menschen WfMS Tabelle 1.1: Geschäftsprozess vs. Workflow Spezifikation der technischen Ausführung von Arbeitsabläufen. Operative Ebene in Verbindung zur vorhandenen Technologie. Konkretisierung von Arbeitsschritten hinsichtlich Arbeitsverfahren sowie technologischer und personeller Ressourcen. 1.4 Workflow-Management 1.4.1 Begriff und Definition Workflow-Management (WfM) stellt Methoden und Werkzeuge zur Analyse und Modellierung, Ausführung und Steuerung sowie Überwachung von Arbeitsabläufen bereit [Mü05, Seite 10]. Ausgehend von diesen Aufgabenbereichen lassen sich drei verschiedene Aufgabengebiete des WfM abstrahieren [Mü05, Seite 11ff]: Modellierung Das Aufgabengebiet Modellierung umfasst die Analyse, Definition und Beschreibung der Prozesse. In modernen Systemen werden Prozesse meist mit grafischen Editoren modelliert. In der Praxis kommen verschiedene Notationen zum Einsatz, die meist auch die grafische Darstellung der Prozesse beinhalten. Bekannte Modellierungssprachen sind Unified Modeling Language (UML) und Business Process Modeling Notation (BPMN), standardisierte Ausführungssprachen sind XML Process Definition Language (XPDL) und Business Process Execution Language (BPEL) ( 1.7). Die Ergebnisse der Modellierungskomponente müssen von der Steuerungskomponente ausführbar sein.

1 Workflow-Management 10 Steuerung Dieser Aufgabenbereich stellt den Kern des WfM dar. Hier werden die modellierten Prozessdefinitionen ausgeführt, d.h. den vorgesehenen Akteuren die Aufgaben zugeteilt. Mehrere Workflows können instanziiert werden. Den unterschiedlichen Akteuren werden die Aufgaben in Worklists zur Verfügung gestellt, diese melden die Bearbeitung zurück. Überwachung In den Aufgabenbereich Überwachung fallen das Monitoring der instanzbezogenen Daten (idealerweise über den gesamten Geschäftsvorfall für eine spätere Nachvollziehbarkeit) und das Abrufen vorgangsbezogener Daten (Aktivität bzw. Bearbeitungsstatus). So können zu jeder Zeit Auskünfte über aktuelle oder abgeschlossene Workflow-Instanzen eingeholt werden. 1.5 Workflow-Management-Systeme Workflow-Management-Systeme (WfMS) sind Softwaresysteme zur Umsetzung des Workflow- Managements. Demzufolge müssen sie Komponenten zur Modellierung, Steuerung und Überwachung von Workflows bereitstellen. Die Systeme sind anwendungsunabhängig und dem Middlewarebereich zuzuordnen [Gad01, S. 44]. Begriffsabgrenzungen legen besonderen Wert auf die Kooperation, Strukturierung und Wiederholbarkeit der zu unterstützenden Prozesse [HHR04, S. 730]. Die Definition der WfMC fasst die oben genannten Aspekte gut zusammen: A system which provides procedural automation of a business process by management of the sequence of work activities and the invocation of appropriate human and/or IT resources associated with various activity steps. [Wor99, S. 10] Weiterhin soll das WfMS den Akteuren (Mitarbeiter und Anwendungsprogramme) gegebenenfalls notwendige Arbeitsanweisungen, Informationen und Dokumente bereitstellen [Gad01, S. 44]. Eine grafische Übersicht über den Zusammenhang der Begriffe in einem WfMS bietet Abbildung 1.2. Die verschiedenen Komponenten werden innerhalb des Softwaresystems über Schnittstellen verbunden, als Referenzarchitektur für WfMS hat sich das Modell der WfMC durchgesetzt.

1 Workflow-Management 11 Abbildung 1.2: Zusammenhang der Begriffe des Workflow-Managements WfMS werden zunehmend auch als Plattform für eine erwünschte Enterprise Application Integration (EAI) genutzt, um vorhandene Altsysteme bei der Optimierung von Geschäftsprozessen zu integrieren. 1.6 WfMC Referenzmodell In der Literatur hat sich das Workflow-Referenzmodell der WfMC durchgesetzt (Siehe u.a. [Gad01, S. 47] oder [Mü05, S. 17]). In diesem Modell wurden schon 1995 die Schnittstellen eines WfMS beschrieben und definiert. Durch diese Standardisierung können die Systeme verschiedener Hersteller besser aufeinander abgestimmt werden und eine Systematisierung der Komponenten wird gefördert [Gad01, S. 47]. 1.6.1 Workflow-Enactment-Service Im Zentrum steht der Workflow-Enactment-Service, der eine oder mehrere Workflow-Engines für Verwaltung (Instanziierung, Aktivierung, Pausierung, Terminierung, etc.) der Workflow-Instanzen enthalten kann. Ferner erstellt die Workflow-Engine die Arbeitslisten für die Benutzer und kontrolliert die Einhaltung von Terminen. Die Workflow-Engine kann als Web-Applikation, EJB-Container, CORBA-Service oder als eigenständige Applikation implementiert werden [Hol95, S. 20ff]. Zur Kommunikation mit anderen Systemen hat die WfMC fünf Schnittstellen, die sogenannte Workflow-API (WAPI) festgelegt. Im Folgenden werden die Schnittstellen und einige der von der WfMC vorgeschlagenen Standards zur Kommunikation über die Interfaces näher erläutert (Abb. 1.3).

1 Workflow-Management 12 Abbildung 1.3: Workflow-Referenzmodell und Schnittstellen [Hol95] 1.6.2 Interface 1 Über das Interface 1 werden Workflow-Schemata an den Workflow-Enactment-Service übertragen, d.h. die von einem Modellierungstool erstellten Daten müssen entgegen genommen werden. Zur Modellierung können verschiedene Editoren verwendet werden, für XML basierte Sprachen reicht ein einfacher Text-Editor [Hol95, S. 28ff]. Die Workflow-Engine des WfMS verarbeitet das geladene Workflow-Schema und erzeugt dann entweder ein internes Workflow-Schema oder verwendet die Sprache des Workflow-Editors zur Verwaltung der Workflow-Instanzen. Die geläufigsten Sprachen zur Beschreibung von Workflows sind BPEL und XPDL, beide Sprachen sind in XML definiert und standardisiert ( 1.7.3). Daneben existieren noch unzählige proprietäre Standards, die meist nur in Zusammenhang mit einem spezifischen WfMS eingesetzt werden. Die von JBoss entwickelte Definition jbpm Process Definition Language (jpdl) erhebt den Anspruch, in der Open-Source Welt am weitesten verbreitet zu sein. Über das Referenzmodell hinausgehend ist von der WfMC inzwischen die Kommunikation für das Interface 1 über XPDL standardisiert [Wor05].

1 Workflow-Management 13 1.6.3 Interface 2 Das WfMS kommuniziert über das Interface 2 mit Benutzern und Client-Applikationen. Klassisches Beispiel ist die Worklist eines Benutzers, der die jeweils aktuellen Aktivitäten auflistet. Eine Worklist hat die Funktionalität Auftrag annehmen und Auftrag fertiggestellt [Hol95, S. 32ff]. Über Interface 2 wird auch die Workflow-Verwaltung gesteuert, insbesondere die Instanziierung. Aber auch die Priorisierung, Unterbrechung oder vorzeitige Beendigung von Workflows [Hol95, S. 34]. Häufige Schnittstellen sind Webanbindungen, die mit einem Browser bedient werden können. Hier werden die Worklists für den Webclient als HTML-Code exportiert. Mit den Webclients kann über das Hypertext Transfer Protocol (HTTP) das WfMS über angenommene und fertiggestellte Aufträge informiert werden. Weiterhin kommen als Protokolle Simple Object Access Protocol (SOAP), Common Object Request Broker Architecture (CORBA) oder Eigenentwicklungen, die beispielsweise als Java-API mit Plain old Java Objects (POJO) realisiert werden, für die Kommunikation zum Einsatz. Diese Schnittstelle ermöglicht es theoretisch, dass Clients verschiedener WfMS die unterschiedlichen Worklists lesen können. Praktisch spielt dies jedoch keine Rolle, da meist an den Funktionsumfang angepasste Clients zum WfMS mitgeliefert werden.[mü05, S. 19] An dieser Schnittstelle wird die Integration mit dem Wissens-Management in dieser Arbeit vorgenommen. 1.6.4 Interface 3 Mit dem Interface 3 werden externe Applikationen oder Hostanwendungen angesprochen, die zur Unterstützung bzw. Automatisierung von Workflows benötigt werden. Im Sinne des EAI sollte ein WfMS mehrere Methoden beherrschen, um externe Applikationen aufzurufen. Dadurch ist eine möglichst einfache Integration von Fremdsystemen möglich. Die Anzahl der benötigten Schnittstellen einer heterogenen Umgebung übersteigt trotzdem meist die des WfMS [Hol95, S. 35]. Schnittstellenunterstützung wird beispielsweise für lokale Applikationen und Skripte, SOAP oder Remote Procedure Call (RPC) angeboten. 1.6.5 Interface 4 Zur Einbindung von WfMS unterschiedlicher Hersteller stellt das Interface 4 Schnittstellen bereit [Hol95, S. 41ff]. Workflow-Schemata und Instanzdaten müssen über dieses Interface für verteilte Systeme austauschbar sein.

1 Workflow-Management 14 Zur Kommunikation wird die Spezifikation Workflow XML (Wf-XML) der WfMC oder Asynchronous Service Access Protocoll (ASAP) verwendet. 1.6.6 Interface 5 Das Interface 5 legt Standards zur Einbindung von Kontroll-, Monitoring- und Analysewerkzeugen fest [Hol95, S. 44ff]. Über diese Schnittstelle soll die Nutzer- und Rollenverwaltung, die Verwaltung der Workflow- Instanzen und die Abfrage von Statusinformationen für unterschiedliche WfMS realisiert werden. Die WfMC hat dazu 1998 einen Vorschlag für den Standard Common Workflow Audit Data (CWAD) in [Wor05] vorgelegt. Dieser konnte sich allerdings bis heute noch nicht durchsetzen. 1.7 Workflow-Schema Die Beschreibung von Workflows in ausformulierter Textform eignet sich nicht, um sie einem Computer zugänglich zu machen. Die Definition sollte demnach erst in Modelle umgewandelt werden, die maschinenlesbar definiert sind. 1.7.1 Metamodell Die WfMC hat ein Metamodell für Workflows entwickelt, das die Mindestanforderungen an eine Workflow-Definition enthält [Hol95, S. 29ff]. Es enthält Objektbeschreibungen und die Zusammenhänge zwischen den Objekten für die Definition von Geschäftsprozessen (Abb. 1.4). Abbildung 1.4: Workflow-Meta-Modell der WfMC [Hol95, S. 30]

1 Workflow-Management 15 Die folgenden Mindestanforderungen werden von der WfMC festgelegt, diese können von Produktherstellern erweitert werden. Workflow-Typdefinition (Workflow Type Definition) Prozessname Versionsnummer Start- und Endbedingung Sicherheits-, Prüf- oder andere Kontrolldaten Aktivität (Activity) Name Typ Bedingungen für Pre- und Post-Aktivitäten Andere zeitliche Einschränkungen Übergabebedingungen (Transition Conditions) Flussbedingungen Ausführungsbedingungen Auf den Workflow bezogene Daten (Workflow Relevant Data) Dateiname und Pfad Datentyp Rolle (Role) Name und organisatorische Verknüpfungen Applikation (Invoked Application) Typ und Name der Applikation Benötigte Parameter für die Ausführung Pfad zur Applikation

1 Workflow-Management 16 1.7.2 Grafische Notationen Für die grafische Darstellung von Workflow-Definitionen stehen verschiedene Sprachen zur Verfügung. Die Object Management Group (OMG) verwaltet die BPMN, die ursprünglich für die grafische Darstellung von Workflows entwickelt wurde und die UML, die sich ebenfalls zur Abbildung von Workflows verwenden lässt. UML-Diagramme werden meist für die Entwicklung objektorientierter Softwarelösungen genutzt, trotzdem eignen sich einige Diagrammtypen gut zur Modellierung und der grafischen Darstellung von Prozessen [Mü05, S. 101]. Auf der Homepage des BPMN-Standards (http://www.bpmn.org) ist auch ein Vergleich mit UML-Diagrammen zu finden. Im Folgenden wird allerdings BPMN, da diese Notation auch im Standard XPDL und für die Darstellung von BPEL Verwendung findet, näher erläutert. Business Process Modeling Notation (BPMN) Die BPMN stellt als grafische Spezifikationssprache Symbole und deren Bedeutung zur Verfügung, mit denen Workflows modelliert werden können. Es wird jedoch kein standardisiertes Format für den Austausch von Diagrammen vorgelegt. Diagramme in BPMN werden als Business Process Diagram (BPD) bezeichnet. Die Grundlage der folgenden Ausführungen ist die Spezifikation [Obj06] der OMG. Zur besseren Zuordnung zum Standard werden zunächst die englischen Begriffe eingeführt und falls nötig übersetzt und im weiteren Verlauf im Sinne einer besseren Lesbarkeit verwendet. Grafische Elemente Die Elemente werden in vier Basiskategorien eingeteilt: Flow Objects Die Knoten im Diagramm Connecting Objects Die verbindenden Kanten Swimlanes Die Akteure und Systeme Artifacts Weitere Objekte, wie z.b. Daten oder Anmerkungen Flow Objects Hierunter werden Activity (Aktivitäten), Gateway (Schnittstellen) und Event (Ereigniss) subsumiert (zur Darstellung siehe Abbildung 1.5). Eine Aktivität beschreibt die kleinste ausführbare Einheit eines Workflows und wird als Rechteck mit abgerundeten Ecken dargestellt. Logisch zusammengehörende Gruppen von Aktivitäten können in einem Subprocess (Teilprozess) zusammengefügt werden.

1 Workflow-Management 17 Schnittstellen stellen Bedingungen für Verzweigungen oder Punkte, an denen verschiedene Abläufe zusammenfließen, dar und werden als Rhombus gezeichnet. Als Bedingungen stehen AND-, OR-, XOR- oder Event-basierte Gateways zur Verfügung. Ereignisse werden nach ihrer Position im Workflow, Start- oder End-Event oder nach der Art, Timeroder Message-Event, eingeteilt. Jeder Event-Typ hat ein eigenes Symbol, das im Innern eines Kreises dargestellt wird. Abbildung 1.5: Visuelle Darstellung von BPMN Flow Objects Connecting Objects Als Verbindungslinien für die Flow Objects stehen Sequence Flows, die die Reihenfolge der Ausführung darstellen, und Message Flows, die den Daten- und Meldungsaustausch symbolisieren, zur Verfügung. Ein Conditional Flow (bedingte Verbindung) wird nur dann durchlaufen, wenn eine Bedingung zutrifft. Einige Connecting Objects sind in Abbildung 1.6 dargestellt. Abbildung 1.6: Visuelle Darstellung von BPMN Connecting Objects

1 Workflow-Management 18 Swimlanes Die Akteure des Workflows werden in so genannten Lanes dargestellt, wobei ein Pool mehrere Lanes enthalten kann. Je nach Design kann eine Lane ein System, eine Benutzerrolle oder einen einzelnen Teilnehmer darstellen. Swimlanes sind in Abbildung 1.7 dargestellt. Abbildung 1.7: Visuelle Darstellung von BPMN Swimlanes Artifacts Sonstige Objekte wie beispielsweise Datenobjekte und Kommentare sind unter der Kategorie Artifacts gesammelt. Datenobjekte werden von einer Aktivität benötigt, um sie einzusehen oder weiterverarbeiten zu können. Datenobjekte können sowohl Dokumente und Datensätze, als auch Materialien wie Druckfarbe oder Papier darstellen. 1.7.3 Ausführungssprachen Für die Ausführung von Workflows werden höhere Ansprüche an die technische Beschreibung des Geschäftsprozesses gestellt, da diese von IT-Systemen lesbar sein müssen. Nach [Bö00, S. 33ff] müssen sie mindestens den folgenden inhaltlichen Eigenschaften genügen: Fehlerfreiheit Da es für ein WfMS keinen Interpretationsspielraum gibt, müssen die Beschreibungen als unumgängliche Handlungsvorschrift verfasst sein. Vollständigkeit Ein WfMS kann nur beschriebene Varianten ausführen, mögliches vorhandenes Prozesswissen bei den Mitarbeitern kann weder vorausgesetzt noch ausgewertet werden. Berechenbarkeit Die Aufgabenzuweisungen und der Kontrollfluss muss für das WfMS berechenbar sein. Bekannte Sprachen für die Definitionen von Workflows sind BPEL und XPDL, beide Sprachen sind in XML definiert. Nach einer kurzen Übersicht zu BPEL wird der Aufbau von XPDL exemplarisch erläutert.

1 Workflow-Management 19 Business Process Execution Language (BPEL) BPEL wurde 2002 unter anderem von Microsoft, IBM und BEA unter dem Namen Business Process Execution Language for Web Services (BPEL4WS) eingeführt. Der Schwerpunkt lag auf so genannten Webservice-Orchestrierungen, also dem Management von Webservices. Problematisch für den Einsatz ist, dass innerhalb der Prozesse nur Webservices aufgerufen werden können, die dann gegebenenfalls mit Benutzern kommunizieren. Der Standard wurde im April 2003 an die OASIS 3 zur Standardisierung übergeben. Ein 2.0 Release ist in Planung, bei dem auch der Name in Web Services Business Process Execution Language (WS-BPEL) geändert werden wird [OAS06]. Ein Specification Draft liegt unter http://www.oasis-open.org vor. extensible Markup Language (XPDL) Die Sprache wurde als Standard für den Austausch von Workflow-Modellen über das Interface 1 des WfMS durch die WfMC in XML als herstellerunabhängiges Format entwickelt. Die grafische Darstellung der Workflows wird seit Version 2.0 (Oktober 2005) durch die BPMN übernommen. Die Version 2.0 ist vollständig abwärtskompatibel zur Version 1.0. Im Gegensatz zu BPEL enthält die Sprache auch ein Rollen- und Benutzerkonzept, das für den uneingeschränkten Aufbau der Workflows notwendig ist. So können die Interaktion der Benutzer und der Aufruf von externen Applikationen innerhalb eines Workflows genau definiert werden. Im Folgenden werden die wichtigsten Sprachelemente vorgestellt und der Bezug zur BPMN hergestellt. Als Quelle wurde durchgehend die Spezifikation WFMC-TC-1025 [Wor05] der WfMC verwendet. Zur besseren Zuordnung zum Standard werden zunächst die englischen Begriffe eingeführt und falls nötig übersetzt und im weiteren Verlauf im Sinne einer besseren Lesbarkeit verwendet. Die XPDL-Listings wurden der Datei beispiel.xpdl entnommen, die auf der beiliegenden CD im Ordner /xpdl zu finden ist. In Abbildung 1.8 ist der Workflow grafisch dargestellt. Package Mehrere Prozessdefinitionen können in einem Container, einem Package (Paket), gruppiert werden. Alle Daten von Benutzern, Rollen, Anwendungen und sonstigen Attribute müssen so nur einmal definiert werden und können an Prozesse innerhalb des Package vererbt werden. Die Sichtbarkeit (Scope) ist jeweils das Paket, die Attribute können jedoch auf einer tieferen Ebene überschrieben werden. 3 Organization for the Advancement of Structured Information Standards

1 Workflow-Management 20 Diese Organisationseinheit schafft eine bessere Übersicht und verhindert Doppelpflege. Packages korrespondieren zum BPMN Business Process Diagramm. <Package xmlns= http: //www. wfmc. org /2002/XPDL1.0 xmlns:xsi= http: //www.w3. org /2001/XMLSchema instance Id= v i e r t e s Name= Demo Package xsi:schemalocation= http: //www. wfmc. org /2002/XPDL1.0 http: //wfmc. org / standards /docs/tc 1025 schema 10 xpdl. xsd > <PackageHeader>... </ PackageHeader>... <WorkflowProcesses> <WorkflowProcess>... </WorkflowProcess>... </WorkflowProcesses> </ Package> Listing 1.1: XPDL Package Abbildung 1.8: Darstellung der Datei beispiel.xpdl durch den Open-Source Editor JPEd

1 Workflow-Management 21 Process Zur Prozessdefinition können Elemente und Attribute definiert werden. Die wichtigsten werden im Folgenden näher erläutert. Prozesse korrespondieren zum BPMN Process. Prozess wird hier als Synonym zu Workflow und nicht zu Geschäftsprozess verwendet. Im Element Process Header sind die Metadaten der Definition wie beispielsweise Version, Autor und Datum abgelegt. <WorkflowProcess Id= workflow basic Name= Workflow Test > <ProcessHeader> <Created>2006 07 23 15 :12:32</Created> </ ProcessHeader>... </ WorkflowProcess> Listing 1.2: XPDL Process Activity Eine Activity (Aktivität) ist eine logische Ausführungseinheit innerhalb eines Prozesses. Die einzelnen Aktivitäten befinden sich in Swimlanes, bzw. Lanes, und werden darüber den jeweiligen Teilnehmern oder Applikationen zugewiesen. Eine Aktivität wird also von dem Benutzer oder der Applikation einer Lane ausgeführt. Aktivitäten korrespondieren mit BPMN Tasks. Aktivitäten können in Containern, Subflows (Teilprozesse), gruppiert werden. <Activity Id= erstes wp1 act2 Name= Satz des Buches > <Performer>e rste s p a r2</performer> <StartMode> <Manual/> </ StartMode> <FinishMode> <Manual/> </ FinishMode> </ Activity> Listing 1.3: XPDL Activity

1 Workflow-Management 22 Activity Elemente können auch Routing-Funktionen übernehmen. Sie kommen dann zum Einsatz, wenn die Bedingungen über Transitionen nicht darstellbar sind, beispielsweise JOIN- oder SPLIT- Verbindungen. In diesem Fall korrespondiert das Element mit dem BPMN Gateway. <A c t i v ity Id= routing > <Route/> <T r a n s i t i o n R e s t r i c t i o n s> <TransitionRestriction> <Split Type= XOR > <TransitionRefs> <TransitionRef Id= erstes wp2 tra6 /> <TransitionRef Id= erstes wp2 tra5 /> <TransitionRef Id= erstes wp21 tra1 /> </TransitionRefs> </ Split> </ TransitionRestriction> </ T r a n s i t i o n R e s t r i c t i o n s> </ A c t i v ity> Listing 1.4: XPDL Routing Activity Weiterhin können Activities auch Ereignisse repräsentieren, beispielsweise Start oder Ende eines Workflows. Dieses Verhalten korrespondiert mit dem BPMN Event. Transition Information Aktivitäten werden durch Transitions (Überleitungen, Transitionen) verbunden. Als Attribute können die Herkunft, das Ziel und bei Bedarf eine Bedingung als Element eingefügt werden. Im einfachsten Falle korrespondieren die Transitionen mit dem BPMN Sequence Flow, falls zusätzlich Bedingungen eingefügt werden mit dem BPMN Conditional Flow. <Transition From= routing Id= erstes wp2 tra5 To= erstes wp2 act5 > <Condition Type= CONDITION >counter == korrektur</condition> </ Transition> Listing 1.5: XPDL Transition Participant Definition Als Participant (Benutzer) können menschliche Aufgabenträger und Rollen definiert werden. <Participants> <Participant Id= e r stes p a r2 Name= Gregor Fellen z > <ParticipantType Type= HUMAN /> </ Participant>... </ Participants> Listing 1.6: XPDL Participant

1 Workflow-Management 23 Application Declaration Im Element Application können IT-Werkzeuge für automatisierte Bearbeitungsschritte eingebunden werden. Der Standard sieht flexible Übergabeparameter für die entsprechende Software vor. <Applications> <Application Id= addition Name= addition > <Description>Addition zweier Zahlen</ Description> <FormalParameters> <FormalParameter Id= a Index= 1 Mode= IN > <DataType> <BasicType Type= INTEGER /> </DataType> <Description>Erste Zahl fuer die Addition</Description> </ FormalParameter>... </FormalParameters> <ExtendedAttributes> <ExtendedAttribute Name= ToolAgentClass Value= org. enhydra. shark. toolagent. JavaClassToolAgent /> <ExtendedAttribute Name= AppName Value= AdditionProc /> </ ExtendedAttributes> </Application>... </ Applications> Listing 1.7: XPDL Application Extended Attributes Falls der Sprachumfang nicht ausreichend ist, gibt es die Möglichkeit, für herstellerspezifische Zusatzinformationen Extended Attributes festzulegen. Diese Elemente werden unabhängig vom WfMS weitergegeben, jedoch nur vom entsprechenden System ausgewertet. Ein Beispiel für den Einsatz von Extended Attributes sind die grafischen Informationen des Workflow- Editors. <ExtendedAttributes> <ExtendedAttrib ute Name= JaWE GRAPH OFFSET Value= 400, 70 /> <ExtendedAttrib ute Name= JaWE GRAPH PARTICIPANT ID Value= jemand /> </ExtendedAttributes> Listing 1.8: XPDL Extended Attribute

2 Wissens-Management My memory is so bad that many times I forget my own name. Miguel de Cervantes Saavedra (1547 1616) Don Quixote de la Mancha In diesem Kapitel werden die Grundlagen des Wissens-Managements (WM) erläutert. Zunächst wird der Begriff abgegrenzt, die Kernaufgaben und Ziele beschrieben und eine Übersicht über Methoden und Werkzeuge gegeben, die in Wissens-Management-Systemen (WMS) eingesetzt werden. Im Gegensatz zum WfM ist das WM kaum standardisiert oder spezifiziert. Danach werden als Beispiel die Möglichkeiten von Wiki-Software als WMS dargestellt. 2.1 Wissensarten In diesem Abschnitt werden der Begriff Wissen und naheliegende Themen abgegrenzt und für diese Arbeit insbesondere in Bezug auf Wissens-Management definiert. 2.1.1 Wissen Als kleinster gemeinsamer Nenner lässt sich Wissen als verstandene Information betrachten [AG02, S. 20]. Dieser Ansatz umfasst jedoch nur das Verfügungswissen ( Was kann ich tun? ), nicht jedoch das Orientierungswissen ( Was soll ich tun? ). Dazu muss noch der Handlungsbezug des Wissens eingebunden werden und der Wissensbegriff um die Handlungsmöglichkeit im Sinne von Problemlösungskompetenz erweitert werden [EGS02, S. 43ff]. Abbildung 2.1 zeigt die verschiedenen Betrachtungsebenen. Definition Wissen ist die Repräsentation von Informationen und ihrer wechselseitigen Zusammenhänge, die einen Menschen befähigt, zielgerichtet zu denken und zu handeln. Zu beachten ist, dass die Befähigung nicht mit einer Nutzung einhergehen muss, genau so wenig wie Wissen der einzige Bestimmungsgrund des Handelns ist.

2 Wissens-Management 25 Abbildung 2.1: Zusammenhang der verschiedenen Ebenen des Wissens Darüber hinaus besitzt Wissen nach Altmeyer [AG02, S. 23] noch Eigenschaften, die es von klassischen Ressourcen abgrenzt: 1. Wissen vermehrt sich bei der Weitergabe. 2. Wissen bleibt auch beim Verkauf erhalten. 3. Wissen kann nicht verbraucht werden, sondern gewinnt bei der Verwendung sogar an Wert. 4. Der Wert des Wissens ist schwer messbar. 5. Wissen ist an Wissensträger gebunden. 2.1.2 Wissenskategorien Wissen wird in Kategorien unterteilt, jedoch lassen sich nicht alle Bereiche durch Wissens- Management erfassen. Individuelles vs. kollektives Wissen Individuelles Wissen steht nur dem Wissensträger zur Verfügung, hingegen kann kollektives Wissen anderen Menschen zugänglich gemacht werden. Kollektives Wissen wird meist in Organisationseinheiten wie beispielsweise einem Unternehmen betrachtet und ist dort den Organisationsmitgliedern zugänglich. Es entsteht durch kollektive oder kooperative Lernprozesse, wie z.b. durch die Dokumentation von Arbeitsschritten. [AG02, S. 32ff] Implizites vs. Explizites Wissen Implizites Wissen ist personengebunden und beruht auf persönlichen Erfahrungen und Eindrücken. Diese Informationen sind im Gehirn des Menschen gespeichert, das in der Lage ist, die Information innerhalb kürzester Zeit zu verknüpfen. Technische und kognitive Elemente machen es allerdings schwer formalisierbar.

2 Wissens-Management 26 Explizites Wissen hingegen ist strukturier- und formalisierbar. Es kann dokumentiert und anderen Menschen leicht zugänglich gemacht werden [EGS02, S. 43ff]. Wissens-Management beschäftigt sich vor allem mit explizitem Wissen. Wobei zu beachten ist, dass dokumentiertes Wissen im Sinne der in dieser Arbeit verwendeten Definition sich nicht mehr von Information unterscheidet und damit elektronisch gespeichert werden kann. Internes vs. externes Wissen Der Zugriff auf internes Wissen ist auf die Mitglieder der Organisationseinheit beschränkt. Es kann aber mit außen stehenden Personen verknüpft und erweitert werden. Externes Wissen ist öffentlich zugänglich und kann zur Erweiterung der Wissensbasis verwendet werden. Anbieter sind Experten, Lieferanten, Verbände, Forschungseinrichtungen und Universitäten. [AG02, S. 32ff] Funktions- vs. Prozesswissen Für die vorliegende Arbeit ist weiterhin die Betrachtung von Prozess- und Funktionswissen wichtig. Funktionswissen beinhaltet aufgabenspezifische Erfahrungen und Kenntnisse, die für die Problemlösung eines einzelnen Prozessschritts notwendig sind. Prozesswissen beinhaltet hingegen die Gesamtsicht, die Informationen über den Prozessablauf, beteiligte Personen und Anwendungsysteme und die workflow-relevanten Daten. [AH02, S. 18] 2.1.3 Wissensträger Für den Zugriff auf Wissen sind die verschiedenen Wissensträger und deren Eigenschaften zu betrachten. In Tabelle 2.1 erfolgt eine Aufteilung nach Altmeyer [AG02, S. 36]. Wissensträger Speicherort Kompetenz Personelle Wissensträger Materielle Wissensträger Kollektive Wissensträger Gedächtnis und Intuition Datenbanken, Bücher, Videos, Maschinen Zusammenschluss von materiellen und personellen Wissensträgern Haben Handlungskompetenz durch die Anwendung von Methoden auf spezifisches Wissen. Können kein eigenständiges Wissen erzeugen, sondern übernehmen Speicherfunktionen. Haben größere Handlungsmöglichkeiten durch die Vernetzung von mehreren Wissensträgern. Tabelle 2.1: Eigenschaften von Wissensträgern

2 Wissens-Management 27 2.2 Kernaufgaben des Wissens-Managements Der Begriff Wissens-Management ist nicht scharf abgegrenzt und wird sowohl in der Literatur als auch bei Systemanbietern sehr unterschiedlich verwendet. Es ist bis heute kein umfassendes theoretisches Konzept entwickelt worden, welches einen Überblick über die verschiedenen Ansätze erlaubt [Fra02, S. 3]. Die folgenden Abschnitte erheben nicht den Anspruch, dieses Konzept zu entwickeln, geben aber einen aktuellen Überblick über das Themengebiet. 2.2.1 Handlungsbedarf Wissen wurde schon immer verwaltet (z.b. externes Wissen in Bibliotheken), jedoch wurde keine systematische Rückkopplung und Erweiterung unter Einbezug der Wissensnutzer organisiert. Durch diesen Mangel konnten die gesammelten Informationen nur ein geringes Handlungspotenzial freisetzen. Verschiedene Quellen stellen fest, dass rund 80% der Unternehmensdaten schwach strukturiert sind. Die Verwendung in einem einheitlichen Informationssystem wird durch Medienbrüche zusätzlich erschwert. Des weiteren nennt Büren eine Studie der University of California, die ein jährliches Informationswachstum von rund 30% prognostiziert. Dies hat zur Folge, dass Mitarbeiter mit wissensintensiven Projekten erhebliche Zeit für den Wissenserwerb verwenden müssen. [Bü05, S. 1] Da der Anteil der Knowledge-Work steigt, wird Wissens-Management zunehmend wichtiger [War98, S. 16]. Auch bei dem untersuchten Unternehmen pagina machen wissensintensive Prozesse, insbesondere Projektarbeiten aus dem Bereich Beratung und Entwicklung, einen immer größeren Anteil am Umsatz aus [Ull06, S. 61]. Weiterhin haben Unternehmen Wettbewerbsvorteile durch den Wissensvorsprung, der aus besserem Zugang und Verfügbarkeit von Wissen entsteht [EGS02, S. 43]. 2.2.2 Kernaufgaben Anforderungen an Wissens-Management werden in den Bereichen Benutzerinteraktion, IT-Unterstützung und Datenorganisation gestellt. Eine Studie des IAO 1 Stuttgart stellt dazu Kriterien auf [IAO99, S. 54]. Der Benutzer soll Informationen schnell und einfach ablegen und wieder darauf zugreifen können. Die Datenorganisation muss Wissensklassifikationen zulassen und ein umfassender Wissenspool ist aufzubauen. Schließlich muss eine sichere und verlässliche Datenhaltung und -abfrage gewährleistet sein. 1 Fraunhofer-Institut für Arbeitswirtschaft und Organisation

2 Wissens-Management 28 Wissensbausteine Diese Kriterien lassen sich in Wissensbausteine übertragen, die nachstehend aufgelistet werden (nach Probst, Raub und Romhardt zitiert nach [EGS02, S. 45]). Wissensidentifikation Notwendiges Wissen identifizieren und erschließen. Wissenserwerb Neues Wissen schaffen. Wissensentwicklung Vorhandenes Wissen teilen und erweitern. Wissensverteilung Wissen zielgerichtet zur Verfügung stellen. Wissensnutzung Wissen systematisch nutzen. Wissensbewahrung Wissen speichern. Übergeordnete Bausteine sind die Wissensziele, insbesondere wichtig für die Wissensidentifikation, und die Wissensbewertung des gespeicherten Wissens. Abbildung 2.2 zeigt den Zusammenhang der Bausteine. Abbildung 2.2: Vereinfachte Übersicht über die Wissensbausteine nach Probst, Raub und Romhardt 2.2.3 Wissensbasis eines Unternehmens Die Wissensbasis des Unternehmens steht dem Mitarbeiter prinzipiell zur Verfügung und kann somit in die Handlungen und Entscheidungen des Unternehmens einfließen. Sie bestimmt das Handlungspotenzial des Unternehmens [Fra02, S. 3]. Problematisch ist, dass das Wissen auf verschiedene Wissensträger verteilt ist und deswegen nicht immer dort verfügbar ist, wo es benötigt wird. In Unternehmen befinden sich Informationen meist in verschiedensten Medien und Systemen und es besteht keine systematische Übersicht über die Kompetenzen der Mitarbeiter. Hinzu kommt, dass das Einzelwissen durch Meinungs- und Bewertungsunterschiede der personellen Wissensträger nicht einheitlich ist. Als Forderung leitet Franken daraus die Kopplung des Wissens an das Handeln ab [Fra02, S. 3].

2 Wissens-Management 29 Die vorliegende Arbeit versucht diesen Ansatz weiter voran zu treiben. Der Zugriff und das Ablegen von Informationen soll durch die Heranführung von Wissenseinheiten an den Arbeitsablauf optimiert werden. 2.3 Instrumente und Methoden In diesem Abschnitt wird erläutert, welches Wissen benötigt wird und wie dieses aufgefunden werden kann. Der verfolgte Ansatz versucht, Wissenspotenziale, die aus dem Tagesgeschäft entstehen, zu verwerten. Denn gerade in kleinen Unternehmen kann keine systematische Forschung und Entwicklung zum Wissenserwerb bereitgestellt werden [AG02, S. 27]. 2.3.1 Prozesssicht Bei der Umsetzung des Wissens-Managements muss auf die Ressourcen- und Prozesssicht geachtet werden. Die Ressourcensicht, mit ihrem Blickwinkel auf Lagerbestände und Personaldecke, kann keinen relevanten Beitrag für die Integration in ein WfM leisten. In der Prozesssicht hingegen wird das Wissen um die Prozesse, die ein Objekt erzeugen, in den Mittelpunkt gestellt [War98, S. 17]. 2.3.2 Organizational Learning und Organizational Memory In diesem Zusammenhang bewegt sich auch das Instrument Organizational Learning (OL), das die prozesshafte, dynamische Sicht auf das zu erwerbende Wissen lenkt. Das Organizational Memory (OM) stellt den gemeinsamen Vorrat des Wissens eines Unternehmens, das verwaltet werden muss, dar. Zielsetzung des OL ist immer eine Vergrößerung des OM, das dann das Erlernte behält und zugänglich macht. So kann sicher gestellt werden, dass der Lernzyklus nicht erneut begonnen werden muss [War98, S. 17]. 2.3.3 Wissensrepräsentation Zur Wissensrepräsentation beschreibt die ISO/IEC 13250 die Abbildung von Wissensstrukturen mit so genannten Topic Maps, die einen effizienten Zugang zu unstrukturierten Informationsmengen leisten sollen. Hauptaufgabe ist es, anstatt hierarchischer Kategorien Querbeziehungen darzustellen [EGS02, S. 49]. Die Strukturen sind vom Datenbestand losgelöst und können unabhängig von der tatsächlichen Organisation gepflegt werden. Ein zentraler Vorteil ist die Unterstützung bei der Suche und Navigation innerhalb des Datenbestands [EGS02, S. 49]. Unabhängig vom konkreten Arbeitsmittel Topic Map kann die Forderung nach einer interhierarchischen Verknüpfung der Informationen abgeleitet werden.

2 Wissens-Management 30 2.3.4 Content-Management Content-Management, als Werkzeug für das Wissens-Management, unterstützt das Erstellen, Nutzen und Archivieren von Wissen [Bü05, S. 38]. Nutzer können durch Content-Management-Systeme (CMS) auf Inhalte zugreifen und diese verändern. Eine Erweiterung des Content-Managements ist das Dokumenten-Management, welches die Verwaltung von Informationen, wie beispielsweise die Versionierung und die Organisation des Dokumentlebenszyklus 2 übernimmt [AG02, S. 48]. Diese Instrumente ermöglichen erst ein durch IT gestütztes Wissens-Management, die eigentlichen Inhalte stehen jedoch im Hintergrund. 2.3.5 Wissens-Management-Systeme Wissens-Management-Systeme WMS sind Informationssysteme, die mit Hilfe von IT-Werkzeugen die Methoden des Wissens-Managements umsetzen und die Kernaufgaben unterstützen. Definition Ein Wissens-Management-System unterstützt die zielgerichtete Identifikation und Sammlung, Entwicklung und Aufbereitung sowie Verfügbarmachung und Bewahrung des gesamten Wissens einer Organisation. Zusätzliche, nicht funktionale Anforderungen werden von Jablonski et al. aufgestellt [JHS02, S. 263]. Omnipräsenz Die Erreichbarkeit des Systems an möglichst vielen Arbeitsplätzen im Unternehmen wird angestrebt. Dieser Aspekt kann durch die Verbreitung des Internets und durch Browser-basierte Anwendungen erreicht werden. Erweiterbarkeit Zukünftige Anpassungen des Systems sollen möglich sein. Verfügbarkeit: Autorisierte Personen sollen jederzeit Zugriff auf das System haben. Dazu zählen im weitesten Sinne aber auch Ausfallsicherheit und Backupstrategien. Akzeptanz Eine möglichst große Anzahl der Mitarbeiter soll das System nutzen. Dazu zählt das Spannungsfeld zwischen mächtiger Funktionalität und einfacher Bedienbarkeit des Systems. 2 Der Dokumentlebenszyklus (Document Lifecycle) beschreibt ein Konzept, das den Prozess von Erstellung, Freigabe, Publikation, Überarbeitung und Archivierung mit der Option auf eine Weiterverwendung als geschlossenen Zyklus beinhaltet.

2 Wissens-Management 31 2.4 Wikis als Wissens-Management-Systeme Es gibt unzählige Ansätze, Wissens-Management-Systeme (WMS) technisch zu realisieren, im Folgenden werden beispielhaft die Möglichkeiten von Wikis als technische Lösung für WMS erläutert. 2.4.1 Einführung Wikis Wikis sind Seitensammlungen im Internet, die von Benutzern gelesen und online editiert werden können. Geschichte Der Name Wiki bedeutet schnell und stammt aus dem Hawaiianischen. Das erste Wiki wurde 1995 von Ward Cunningham als Wissen-Management-Tool mit dem Ziel entwickelt, Software Entwurfsmuster für andere Entwickler auf einer gemeinsamen Plattform zugänglich zu machen. Es ist heute noch unter http://c2.com/cgi/wiki abrufbar. Das wohl berühmteste Wiki ist die freie online Enzyklopädie Wikipedia (http://www.wikipedia.org). [Wik06] Konzept Zentrales Konzept ist die Möglichkeit, dass Seiten von jedem Benutzer direkt verändert werden können. Auf jeder Seite gibt es eine Schaltfläche Edit, die das direkte Bearbeiten ermöglicht. Nach dem Speichern ist die Seite in veränderter Form für alle Benutzer sichtbar. Ein weiteres Konzept ist das einfache Erzeugen neuer Seiten. Ein neu angelegter Link führt durch die Aktivierung im Browser zu einer neuen, leeren Seite innerhalb des Wikis. Die Formatierung wird über eine einfache Wiki-Syntax als Textformat vorgenommen, neuere Entwicklungen integrieren auch WYSIWYG-Editoren. Die einfache Syntax, die im wesentlichen nur Gliederungsebenen, Hyperlinks, Textauszeichnungen, Listen und Tabellen kennt, ist leicht erlernbar [Cyg02, S. 2]. In Tabelle 2.2 sind beispielhaft die wichtigsten Befehle der Wiki-Software MediaWiki, die bei Wikipedia zum Einsatz kommt, dargestellt.

2 Wissens-Management 32 Befehl kursiv fett == Überschrift 1 == === Ebene 2 === ==== Ebene 3 ==== [[Link zu Wikiseite]] http://www.test.de [[Kategorie:Beispiel]] [[:Kategorie:Beispiel]] * Erster Punkt * Zweiter Punkt * Dritter Punkt { border= 1! 1. Spalte Kopfzeile! 2. Spalte Kopfzeile - 1. Spalte 1. Zeile 2. Spalte 1. Zeile - 1. Spalte 2. Zeile 2. Spalte 2. Zeile } [[Bild:File.jpg Text]] #REDIRECT [[Artikel]] Formatierung kursiv fett Überschriften Gleichzeitig Einteilung in einzelne editierbare Einheiten. Hyperlink innerhalb des Wikis Hyperlink zu einer Website Zur Kategorie Beispiel hinzufügen Link zur Kategorie Beispiel erstellen Liste mit Aufzählungspunkten (*) Nummerierte Liste (#) Verschachtelung möglich Einfache Tabelle Kopfzeilen werden im Layout hervorgehoben. Beliebig viele Spalten und Zeilen können eingefügt werden. Bild mit Textbeschreibung Weiterleitung zu einem Artikel Tabelle 2.2: Wiki-Syntax der Wiki-Software MediaWiki Zusammengefasst sind die zentralen Ideen von Wikis: Alle Benutzer können jede Seite verändern (Jeder ist Autor). Verändern und Erzeugen von Seiten wird erleichtert (Der Inhalt bildet die Struktur). Einordnung Wikis können als spezielle Form von CMS betrachtet werden. Sie haben jedoch eine flachere Struktur, da alle Artikel auf der gleichen hierarchischen Ebene liegen und erschweren somit das Erstellen von Navigationsstrukturen. Durch die flache Struktur sind die Systeme aber leicht bedienbar. Wikis weisen eine deutlich höhere interne Verlinkung der Seiten auf [Lan05, S. 29] und erfüllen so die Forderung nach einer interhierarchischen Vernetzung. Das Konzept der Kategorisierung, welches in neueren Wikis implementiert wurde, kann außerdem einen stärker strukturierten Aufbau fördern [Lan05, S. 29].

2 Wissens-Management 33 2.4.2 Wissens-Management: Lösungen mit Wikis Wiki-Wissens-Management-Lösungen sind keine umfassenden WMS im Sinne der in dieser Arbeit verwendeten Definition. Schwachstellen bestehen insbesondere in der gezielten Bereitstellung und Nutzung von Wissen für bestimmte Aufgaben. Vorteilhaft ist jedoch der kollaborative Ansatz, der die Erzeugung von neuem Wissen aus einer vorhandenen Wissensbasis begünstigt. Dies kommt zum Tragen, wenn der Aufbau und die Pflege einer gemeinsamen Datenbasis durch die Mitarbeiter erfolgen soll. So kann bei abteilungsübergreifenden Aufgaben und Prozessen durch die Förderung der Zusammenarbeit bei der Wissenserstellung ein größeres Wissenspotenzial erschlossen werden. Die Nutzung der Wiki-Technologie kann mit dem einfachen Zugriff auf Information die Motivation der Mitarbeiter, ihr Wissen zu teilen, erhöhen. Durch den schnellen und einfachen Aufbau einer Wissensgrundlage erhöht sich auch die Akzeptanz des Systems, da es auch zum eigenen Nutzen verwendet werden kann. Ein weiterer Vorteil, insbesondere für KMU, ist die kostengünstige Anschaffung und einfache Installation 3. Weiterhin ist der Schulungsaufwand durch die einfache Bedienung gering. Die große Bekanntheit des Wiki-Prinzips durch Projekte wie Wikipedia kann diesen Aufwand nochmals senken. Als konzeptionelle Weiterentwicklung der Technologie ist das Programm SnipSnap (http:// snipsnap.org/space/bottom+up+knowledge+management) zu nennen. Hier wurden Erweiterungen im Bereich Strukturierung/Kategorisierung und die Integration von MindMaps, um Wissens- Management-Aufgaben besser zu erfüllen, vorgenommen [Sni04]. 3 Es besteht eine große Auswahl an gut dokumentierten Open-Source Produkten.

3 Analyse From pro s and con s they fell to a warmer way of disputing. Miguel de Cervantes Saavedra (1547 1616) Don Quixote de la Mancha Im Folgenden werden die Anforderungen an ein WfMS mit prozessnahem Wissens-Management erarbeitet. Der Schwerpunkt wird auf die Bedürfnisse von KMU und insbesondere auf die Anforderungen des Verlagsdienstleisters pagina GmbH gelegt. Zunächst wird eine allgemeine Anforderungsanalyse erstellt, die dann durch die spezifischen Anforderungen der pagina GmbH erweitert wird. Eine tatsächliche Beschreibung und Modellierung eines Beispielprozesses folgt der Analyse und rundet das Kapitel ab. 3.1 Ausgangssituation und Zielsetzung Ausgangssituation Die Stärke von KMU liegt in ihrer Flexibilität, komplexe Aufträge in kleinen Teams zu lösen. Im Bereich Beratung und Projektarbeit sind starre Prozesse und festgefügte Regelwerke hinderlich. Trotzdem liegt in der mangelnden Strukturierung und Standardisierung der Abläufe auch die Gefahr, Kapazitäten falsch einzusetzen und an einen erhöhten bürokratischen Organisationsaufwand zu binden. In diesem Spannungsfeld ist eine Lösung für ein flexibles WfMS zu suchen, das Freiheiten bei einzelnen Projekten ermöglicht, aber standardisierte Abläufe für wiederkehrende Aufträge erzwingt. Auch bei der pagina GmbH halten sich Regelprozesse und nicht sinnvoll planbare Einzelprojekte die Waage [Ull06, S. 61ff]. Regelprozesse kennzeichnen sich durch eine vorhersehbare sowie kontrollierbare Struktur und Komplexität, die allerdings auch individuellen Veränderungen unterworfen sind (zu den verschiedenen Workflow-Typen siehe 1.2.2). Projektarbeiten bzw. so genannte Ad-hoc- Workflows, variieren stark und können kaum strukturiert werden. Regelprozesse eigenen sich gut für die Steuerung mit WfMS, Ad-hoc-Workflows sollten nur als grobe Ablaufplanungen bzw. als Checklistenfunktion in das WfMS integriert werden.

3 Analyse 35 Im Bereich Wissens-Management gibt es kaum prinzipielle Einschränkungen für KMU, allerdings sollte die gewählte Lösung für die Mitarbeiter beherrschbar sein. Eine einzelne Abteilung für die Pflege und Organisation des Systems einzurichten, ist meist wirtschaftlich nicht vertretbar. Eine spezifische Anpassung an die Anforderung des Geschäftsbereichs und die Detaillierung der Wissensbausteine ist auch beim WMS zu erarbeiten. Zielsetzung Die Zielsetzung ist es, eine Anforderungsanalyse für die Integration von zwei vorhandenen Systemen zu erstellen, die den gestellten Anforderungen beider Sichtweisen gerecht wird. Sowohl für WfMS als auch für WMS stehen viele Softwarelösungen zur Verfügung. Auch Open- Source lizenzierte Produkte sind in ausreichender Zahl und reifem Entwicklungsgrad erhältlich. Zur Evaluation der Systeme ( Kapitel 4) wird eine detaillierte Anforderungsanalyse erstellt. Dazu wird ein Kriterienkatalog entwickelt, an dem die Produkte gemessen werden können. Es wird keine Erweiterung eines Einzelsystems angestrebt, sondern vielmehr die Verbindung des WfMS und WMS. Die Erweiterung des jeweiligen Systems um Aspekte des anderen würde enormen zeitlichen Aufwand erfordern und zusätzlich das Ergebnis von Weiterentwicklungen der Einzelkomponenten abkoppeln. Die Implementierung soll in einem eigenen Programm erfolgen, das als Glue zwischen den beiden Systemen fungiert. Dies hat auch zur Folge, dass in geringem Maße Geschäftslogik, zwar in einem eigenen Package, aber außerhalb des eigentlichen Programms implementiert wird. Die Integration wird als Schwerpunkt in der Benutzerschnittstelle implementiert, die die Zusammenführung der beiden Systeme für den Benutzer realisiert. 3.2 Anforderungsanalyse an ein Workflow-Management-System mit prozessnahem Wissens-Management Die Anforderungsanalyse stellt gleichzeitig eine Grobkonzeption des zu erstellenden Systems dar, die dann in Kapitel 5 spezifiziert wird. Zunächst werden allgemeine Anforderungen erarbeitet, die im nächsten Abschnitt um die spezifischen Anforderungen der pagina GmbH erweitert werden. Es wird eine Aufteilung in Ausschlusskriterien und wünschenswerte Kriterien vorgenommen. Während erstere kritisch für die Auswahl des Systems sind (also hinreichend erfüllt werden müssen), sind wünschenswerte Kriterien entweder leicht selber zu implementieren oder nicht zwingend notwendig für das System.

3 Analyse 36 3.2.1 Grundsätzliche Anforderungen an die Produkte In diesem Abschnitt werden nicht funktionale Anforderungen an die Software festgelegt. Wichtige nicht funktionale Kriterien sind: Programmiersprache Im Rahmen dieser Arbeit können nur Produkte in der Programmiersprache Java bearbeitet werden. Dokumentation Die ausreichende Dokumentation der Produkte ist für die geplante Entwicklung notwendig. Open-Source Open-Source Software wird favorisiert, da der Quellcode bekannt und veränderbar ist. Hier ergeben sich bessere Anpassungsmöglichkeiten für die Integration. Zusätzlich sind Kosteneinsparungen durch die Verwendung frei verfügbarer Software zu erwarten. Bekanntheitsgrad und Community Für die Entwicklung von Open-Source-Projekten ist eine große Community hilfreich, die Hilfestellung für die Erweiterung geben kann. Weiterhin erhöht ein großer Bekanntheitsgrad und eine starke Community die Chancen auf Weiterentwicklung der Software. IDE Integration Eine Integration in eine Software Entwicklungsumgebung muss für die umfangreiche Anpassung möglich sein. Weitere nicht funktionale Anforderungen können im Rahmen dieser Arbeit nicht mit erhöhter Priorität verfolgt werden. Dazu zählen beispielsweise: Sicherheit Da das System zunächst nur für den internen Gebrauch ausgelegt ist, müssen keine erhöhten Sicherheitsaspekte beachtet werden. Skalierbarkeit und Performanz Die Summe der gleichzeitig aktiven Prozessinstanzen wird relativ gering sein und weit unter der Lastgrenze der Systeme liegen. Verfügbarkeit Die Anforderungen an die Verfügbarkeit sind nicht kritisch, da sich das geplante System im Notfall durch menschliche Aufgabenträger ersetzen lässt. 3.2.2 Anforderungen Workflow-Software Die gestellten Anforderungen an das WfMS orientieren sich am Workflow Reference Modell der WfMC bzw. an der in dem Modell vorgestellten Workflow-API ( 1.6). Workflow-Enactment-Service Der Workflow-Enactment-Service stellt die zentralen Dienste für das Management der Workflow- Schemata und -Instanzen bereit.

3 Analyse 37 Die folgenden Ausschlusskriterien werden festgelegt: Steuerung der Workflow-Instanzen Die Ablaufsteuerung der Instanzen ist für ein WfMS obligatorisch. Als Steuerungsmöglichkeiten müssen mindestens die im Metamodell ( 1.7.1) beschriebenen Definitionen, Aktivitäten und Übergabebedingungen implementiert sein. Verwaltung von Workflow-Schemata Eine Versionierung und Speicherung der Schemata ist notwendig. Invoked Applications Externe Programme müssen durch das System für die automatisierte Bearbeitung von Prozessschritten aufgerufen werden können. Usermanagement Für die Organisation der Prozesse ist ein Benutzerkonzept mit der Zuordnung zu bestimmten Gruppen erforderlich. Servertechnologie Das WfMS muss als Serversystem ausgelegt sein. Idealerweise wäre das WfMS in einen Application Server integriert, um verschiedensten Anforderungen zur Automatisierung von Prozessen gerecht werden zu können. Folgende Bestandteile sind wünschenswert: Abgabeterminüberwachung Eine Terminsteuerung ist für die Organisation der Prozesse erforderlich. Interface 1 Über das Process Definition Interface werden Workflow-Schemata geladen, die von einem Modellierungstool erstellt wurden. Ausschlusskriterien für das System sind: Implementierung des Interface 1 Die Modellierung muss außerhalb des Workflow- Enactment-Service, und damit unabhängig vom laufenden Betrieb, möglich sein. Grafisches Modellierungstool Ein Modellierungstool für die Erstellung der Workflow- Schemata muss vorhanden sein. Die Erstellung der Schemata in einem Texteditor ist nicht zweckgemäß, da Prozesse typischerweise einen grafisch darstellbaren Ablaufplan abbilden. Wünschenswerte Bestandteile sind: Modellierungsmöglichkeiten Das Modellierungstool sollte auf das WfMS abgestimmt sein, d.h. die spezifischen Funktionen des WfMS berücksichtigen. Spezielle Features des WfMS sind sonst für den Prozessdesigner nur sehr schwer zugänglich.

3 Analyse 38 Standardkonformität Die Verwendung eines verbreiteten Standards erhöht die Chancen auf eine zukünftige Weiterverwendbarkeit der Workflow-Schemata. Unabhängig davon ist das erlernte Wissen der Mitarbeiter auch für andere Produkte verwendbar und damit wertvoller. Im Bereich WfMS ergibt sich allerdings die Situation, dass sich noch kein Standard durchgesetzt hat. Interface 2 Das Workflow Client Interface ist die Schnittstelle zwischen dem Benutzer und Workflow-Enactment- Service. Ausschlusskriterien für das System sind: Implementierung des Interface 2 Eine gut ausgebaute Schnittstelle für die Anpassung der Benutzerführung muss vorhanden sein. Da die Benutzerschnittstelle für die Integration neu implementiert wird, ist zusätzlich auch eine ausführliche Dokumentation der API notwendig. Schnittstellentyp/Technologie Client Für die Implementierung der Benutzerführung wird besonderer Wert auf eine bekannte Schnittstelle gelegt. Wünschenswert wäre: Vorhandener Webclient Die Implementierung der Benutzerführung soll als Webclient realisiert werden. Ein vorhandener Client könnte um die fehlenden Funktionen erweitert werden. Da jedoch eine tiefgreifende Anpassung vorgenommen wird, sind die zu erwartenden Überschneidungen gering. Interface 3 Über das Invoked Applications Interface werden externe Applikationen angesprochen, die zur Unterstützung von Workflows benötigt werden. Eine möglichst hohe Anzahl von Schnittstellen ist wünschenswert, um eine große Flexibilität des Systems zu gewährleisten. Insbesondere wichtig sind die folgenden: Lokale Applikationen Der Aufruf von Programmen über die Kommandozeile. POJO Die Integration von Java Programmen ist notwendig für die Steuerung des WMS. Wünschenswert wäre: E-Mail Eine direkte Integration von e-mail Benachrichtigungen wird mittelfristig benötigt.

3 Analyse 39 Interface 4 Die Kommunikation verschiedener WfMS wird über das Interface 4 realisiert. Für KMU ist die Integration in externe WfMS im Normalfall nicht vordringlich. Eine Implementierung des Interface 4 ist nicht notwendig. Interface 5 Über das Monitoring Interface werden Kontroll- und Monitoring-Daten ausgetauscht. Ausschlusskriterien für das System sind: Implementierung des Interface 5 Da für das WMS Monitoring-Daten benötigt werden, muss eine Schnittstelle vorhanden sein. Auch sollte für zukünftige Analysetools eine ausreichende Flexibilität bereitstehen. 3.2.3 Anforderungen Wiki-Software Die Anforderungen werden in den Bereich Benutzerführung und Wissensorganisation aufgeteilt. Sie orientieren sich an den Wissensbausteinen ( 2.2.2) bzw. der Möglichkeit, diese umzusetzen. Zusätzlich werden noch die Anforderungen an die Erweiterbarkeit der Software erarbeitet. Benutzerführung Die Benutzerführung bzw. die Möglichkeiten des Wikis sind von entscheidender Bedeutung für die Akzeptanz des Systems bei den Benutzern. Ausschlusskriterien für das System sind: Wiki-Syntax Eine einfach zu erlernende, überschaubare Syntax ist notwendig, insbesondere im Hinblick auf den Wissenserwerb, dem Erstellen neuen Wissens. Interne Links Durch einfach zu erstellende interne Verknüpfungen von Artikeln kann die Wissensentwicklung gefördert werden. Wissensidentifikation Für die Identifikation von Wissen ist minimal eine Volltext-Suche notwendig. Attachments Die Möglichkeit, Dokumente und Dateien an Artikel anzuhängen, ist für die Einbindung von externem Dokumentationsmaterial notwendig.

3 Analyse 40 Wünschenswert wäre: E-Mail/Really Simple Syndication (RSS) Benachrichtigungen durch das System über Veränderungen an bestimmten Artikeln über e-mail oder RSS sind für die Pflege der Seiten von Bedeutung. Wissensorganisation Im Bereich Wissensorganisation werden Anforderungen für ein schlüssiges Konzept der Wissensverwaltung im Hinblick auf die Strukturierung aufgestellt. Ausschlusskriterien für das System sind: Kategorisierungen Eine Einteilung in verschiedene Kategorien ist für die Wissensidentifikation und zur zielgerichteten Bereitstellung von Wissen notwendig. Usermanagement Für die Organisation des Zugriffs auf bestimmte Ressourcen, aber auch für die Identifikation des Urhebers, ist ein Benutzerkonzept notwendig. Wünschenswerte Kriterien sind: History Eine Übersicht über die Veränderungen an Artikeln (Revision History) und deren Vergleich ist wünschenswert. Datenspeicherung Für die Speicherung der Informationen wird eine Datenbanklösung favorisiert, die eine erhöhte Sicherheit und Performanz gewährleistet. Erweiterbarkeit Eine Anpassung des Quellcodes oder die Integration von Plugins ist für die geplante Verbindung notwendig. Um nicht den eigentlichen Quellcode verändern zu müssen, wird eine Plugin-Struktur der Software präferiert. Dies stellt sicher, dass auch zukünftige Versionen der Software einfach in das System eingebunden werden können.

3 Analyse 41 3.3 Voraussetzungen der pagina GmbH Im Folgenden werden Voraussetzungen der Firma pagina für die Anforderungsanalyse herausgearbeitet. Die Daten wurden in mehreren Workshops bei der pagina GmbH erhoben. Hier wurde darauf geachtet, zunächst unternehmensweite Anforderungen zu erarbeiten und danach den Detaillierungsgrad bis zur Ausformulierung des konkreten Prozesses zu steigern. Bei jeder Workshoprunde wurden die entsprechenden Verantwortlichen miteinbezogen. Die theoretische Vorarbeit, insbesondere aus dem vorhergehenden Abschnitt 3.2, wurde den verantwortlichen Mitarbeitern dargestellt. 3.3.1 Unternehmensweite Aspekte Das zu erstellende System kann ohne weitere Probleme in das bestehende Netzwerk integriert werden und übernimmt durch das Wiki als Nebeneffekt Funktionen eines Intranets. Durch die breite Erfahrung der Mitarbeiter im Bereich automatisierter Satz und XML-Datenstrukturierung, die Hauptgeschäftsfelder des Unternehmens, kann von einer technikaffinen Grundeinstellung ausgegangen werden. Dies führt einerseits zu einer höheren Akzeptanz der Systeme und andererseits können höhere Anforderungen bei der Prozessmodellierung gestellt werden. So ist beispielsweise davon auszugehen, dass in XML beschriebene Workflow-Schemata verstanden werden oder dass Applikationen bzw. Skripte selbstständig für die Automatisierung erstellt werden können. Bei der Firma pagina GmbH ist nur eine geringe Anzahl von laufenden Prozessinstanzen zu erwarten, dies bestätigt die Vernachlässigung des Aspekts Skalierbarkeit in der allgemeinen Analyse. Es sind vielfältige Dokumentationsanforderungen vorhanden, die aktuell noch mit vielen Medienbrüchen verwaltet werden. So besteht zu jedem Auftrag eine Umlaufmappe, eine Dokumentation auf dem Fileserver und ein Eintrag im Projektmanagement-Tool. 3.3.2 Vorhandene Software Für das Projektmanagement ist bereits eine eigenentwickelte Software in Benutzung. Das Tool basiert auf einer Access-Datenbank und beinhaltet die Auftrags-, Mitarbeiter- und Kundenverwaltung. Hauptaufgabe ist die Zeitabrechnung und Projektverwaltung. Für das WfMS ist eine Integration der vorhandenen Daten vorzunehmen. Dazu sind insbesondere die Projekt- und Kundendaten aus der Datenbank auszulesen. Um Doppelpflege und inkonsistente Datenbestände zu vermeiden, ist es erforderlich, das aktuell verwendete Projektmanagement-Tool zu integrieren. Weiterhin soll das vorhandene Satzsystem TUSTEP integriert werden. Die Integration ist unproblematisch, da TUSTEP über Kommandozeilenparameter bzw -skripte gesteuert werden kann.

3 Analyse 42 3.3.3 Wünsche aus der täglichen Arbeit Besonderer Wert wurde von mehreren Mitarbeitern darauf gelegt, dass die Prozesse nicht bürokratisiert werden. In Anbetracht der Firmengröße sind einige Aufgaben, die ein WfMS leisten kann, bei pagina nicht notwendig. Beispielsweise ist die Priorisierung eines Auftrages meist einfacher und sicherer mit einem kurzen Anruf innerhalb des Hauses zu bewerkstelligen, als sie über die Worklist des einzelnen Mitarbeiters anzeigen zu lassen. Hier spielt auch die verhältnismäßig geringe Auftragsdichte und damit die geringe Anzahl von laufenden Workflow-Instanzen eine Rolle. Besonderer Wert wurde von einer Projektleiterin auf eine möglichst flexible Benutzerzuweisung gelegt. Änderungen der Aufgabenzuteilung müssen auch nach der Instanziierung noch möglich sein. 3.4 Anforderungsanalyse der pagina GmbH an das System Dieser Abschnitt detailliert die spezifischen Anforderungen des mittelständischen Verlagsdienstleisters pagina an ein integriertes Workflow- und Wissens-Management-System. Die allgemeine Anforderungsanalyse aus dem Abschnitt 3.2 wird um unternehmensspezifische Aspekte erweitert. Bereits erwähnte Aspekte werden nicht erneut aufgezählt. Die Wünsche und Anforderungen der Firma pagina überschreiten den Umfang dieser Arbeit bei weitem. Sie wurden jedoch erfasst, um die Zukunftssicherheit des Systems bei der Evaluation und Konzeption sicherzustellen. In der folgenden Aufstellung sind Aspekte, die bei der Implementierung nicht berücksichtigt werden, unter dem Abschnitt 3.4.2 aufgezählt. 3.4.1 Spezifische Anforderungen an das System Die Anforderungsanalyse listet die unternehmensspezifischen Kriterien für das WfMS und WMS auf. Grundsätzliche Anforderungen an die Produkte Als weiteres Ausschlusskriterium wird festgelegt: Linux In dieser Arbeit werden nur Produkte untersucht, die unter Linux betrieben werden können. Da das System auf einem vorhandenen Linux Server installiert werden soll. Wünschenswert wäre: Integration der Access-Datenbank Die vorhandene Access-Datenbank soll in das System integriert werden, um Doppelpflege von Projekt- und Kundendaten zu vermeiden.

3 Analyse 43 Anforderungen Workflow-Software Weitere Ausschlusskriterien für den Workflow-Enactment-Service: Benutzerzuweisung nach Instanziierung Die Möglichkeit der Änderung der Benutzerzuweisung für einzelne Prozessschritte nach Instanziierung ist erforderlich. Wünschenswerte Features für das Interface 5: Monitoring Tools Mittelfristig werden Monitoring-Tools, wie beispielsweise eine Übersicht über laufende Prozesse, eine Terminübersicht oder eine Übersicht über die Benutzerzuordnung je Instanz, benötigt. Anforderungen Wiki-Software Wünschenswerte Features für das Wiki: Kundendaten Das Wiki soll neben den Workflow-Daten auch Artikel zu Kunden enthalten, die automatisch aus der Access-Datenbank aktualisiert werden. 3.4.2 Anforderungen für die 2. Ausbaustufe Anforderungen Workflow-Software Erweitertes Usermanagement Erweitertes Usermanagement mit Zugriffsverwaltung für Mitarbeiter (Bearbeiter/Administrator) und Externe (Kunden). Insbesondere im Hinblick auf ein remote Prozessmonitoring, das dem Kunden ermöglicht, jederzeit den Status seines Auftrags im Internet abzurufen. Projektmanagement Die mittelfristige Planung der Ressourcen- und Mitarbeiterauslastung im Sinne eines Projektmanagements ist gewünscht. Da dieser Bereich nicht zum Bereich WfM gehört, wird eine Integration oder Eigenentwicklung vorzunehmen sein. Applikationsintegration Für die bessere Prozessintegration wäre eine Integration von verschiedenen Applikationen wünschenswert. Dazu zählen: PDF-Tools (Konverter, Voransicht, Erzeugen druckfähiger Daten), Fileserver Funktionalität (FTP/SCP für Kunden). Repository Durch die Datenspeicherung abgeschlossener Aufträge über den Application Server könnten Kunden auf alte Daten zugreifen bzw. Teile davon sogar öffentlich zugänglich machen. Dazu zählen: Retrieval Funktionen (Durchsuchen bestimmter Datenbestände), Medienneutrale Datenhaltung (Bereitstellung von verschiedenen Ausgabeformaten) und Zugangsverwaltung.

3 Analyse 44 Anforderungen Wiki-Software Kundenwiki Als Erweiterung des Wissens-Managements könnte das Wiki in einen für Kunden zugänglichen Bereich und einen pagina internen Bereich aufgeteilt werden. WfMS Monitoring Eine Übersicht über die Prozesse, Durchlauf- und Mitarbeiterzeiten je Auftrag bzw. Schema soll im Wiki auswertbar sein. 3.5 Workflow-Beschreibung Strukturoffensive Beispielhaft wird in dieser Arbeit der Prozess Strukturoffensive beschrieben und als Workflow modelliert. Dieser zeigt einen konkreten Anwendungsfall für das zu implementierende System. Die pagina GmbH hat aus der langen Erfahrung im Werksatz eine Satzautomatisierung für standardisierte Buchproduktionen entwickelt, die unter dem Namen Strukturoffensive beworben wird. Der hohe Grad an Automatisierung gelingt durch strukturierte XML-Daten für den Satz und der Satzsoftware TUSTEP, die strukturierte Daten verarbeiten kann. Es können einfache Romane bis hin zu komplexen wissenschaftlichen Fachbüchern mit Fußnoten, Marginalien und Registern erstellt werden. Neben druckfähigen PDF- oder PostScript-Daten erhält der Kunde zusätzlich noch die XML-Daten mit allen Korrekturen und nach Wunsch eine HTML-Aufbereitung. In diesem Ablauf wird neben dem Satz die Datenqualität der Ursprungsdaten aufgewertet und es gelingt ein Roundtripping 1 der XML-Daten für mögliche Weiterverwertungen (Siehe auch Abb. 3.1). Abbildung 3.1: Der Prozess Strukturoffensive aus herstellerischer Sicht Der Geschäftsprozess wurde im Jahre 2005 neu entwickelt und aus verschiedenen bestehenden Satzabläufen zusammengestellt. Verschiedenste Eingabeformate werden bei der Datenannahme akzeptiert und von pagina in XML- Daten gemäß einer Standard Satz Document Type Definition (DTD) überführt. Die relativ flach strukturierte DTD enthält alle wesentlichen Merkmale für den Satz einer regelbasierten Typogra- 1 Roundtripping ermöglicht die Beibehaltung von inhaltlichen Korrekturen während der Produktion im ursprünglichen Datenbestand.

3 Analyse 45 fie. Die typografischen Informationen werden bei der Konvertierung eingefügt. Mit Processing Instructions (PI) können flexibel Feinkorrekturen und Sonderwünsche durch den Setzer durchgeführt werden. In den verschiedenen Korrekturläufen bekommt der Kunde jeweils Protokolle über Silbentrennungen und Umbruchprobleme sowie ab dem zweiten Satzlauf ein Vergleichsprotokoll, in dem die Änderungen zur vorherigen Version markiert sind. Nach der Durchführung der Korrekturen werden druckfähige PDF- und/oder PostScript-Daten erstellt, die XML-Daten enthalten zu diesem Zeitpunkt alle Korrekturen und werden zusammen mit einer Dokumentation über die verwendeten Elemente und Sonderzeichen an den Kunden geliefert. Weitere Informationen zu den herstellerischen und technischen Aspekten finden sich unter [pag05]. 3.5.1 Hinweise zur Workflow-Modellierung Der Workflow wird in die Zuliefer- bzw. Hilfsprozesse, Auftragsannahme und Auftragsabschluss und den Kernprozess Satzworkflow aufgeteilt. Bei der Beschreibung der Workflow-Modellierung sind folgende Konventionen zu beachten: Swimlanes werden in Kapitälchen dargestellt. Aktivitäten und allein stehende Applikationen werden nummeriert und fett gedruckt. Variablen werden kursiv ausgezeichnet. Applikationen innerhalb von Aktivitäten werden fett und kursiv ausgezeichnet. Bei den grafischen Darstellungen ist jeweils zu beachten, dass Applikationen innerhalb von Aktivitäten zur besseren Übersichtlichkeit nicht separat dargestellt werden. Die jpdl-quellcodes des Workflows können im Anhang A.3.1 eingesehen werden und sind im Eclipse Projekt pagina-processes, auf der beiliegenden CD im Ordner /opt/guapa/gpd/workflows, zu finden. 3.5.2 Auftragsannahme Das Anlegen eines neuen Auftrages ist ein Hilfsprozess, der grundsätzlich für alle Aufträge und Projekte nach Einführung des Workflow-Management-Systems eingesetzt werden soll. Dies fördert die Standardisierung für die Auftrags- und Datenverwaltung. Der Workflow kann als Sub-Workflow wiederverwendet und zentral gepflegt bzw. erweitert werden.

3 Analyse 46 Bestandsaufnahme Bei der Einrichtung eines Auftrags werden zur Zeit folgende Schritte ausgeführt: Zunächst wird im Projektmanagement-Tool der Auftrag eingerichtet. Dort wird auch die Auftragsnummer generiert. Auch in Zukunft soll das Projektmanagement-Tool unabhängig vom WfMS für die Finanzplanung und Zeiterfassung verwendet werden. Dann wird die papierbasierte Umlaufmappe angelegt und die notwendigen Dokumente werden ausgedruckt. Als Letztes wird die benötigte Ordnerstruktur vom Projektleiter auf dem Fileserver angelegt, in die dann die notwendigen Daten für die TUSTEP-Sitzung kopiert werden. Die zuständigen Mitarbeiter für die einzelnen Projektabschnitte werden dann über den Auftrag und die ihnen zugewiesenen Aufgaben informiert. Workflow-Modellierung Der Workflow Auftragsannahme ist sehr einfach strukturiert und sequenziell aufgebaut, es wird davon ausgegangen, dass die Dateneingabe in das Projektmanagement-Tool bereits erfolgt ist. In Abbildung 3.2 ist der Workflow grafisch dargestellt. Der jpdl-quellcode des Workflows kann im Anhang A.3.1 eingesehen werden. Abbildung 3.2: Grafische Darstellung des Workflows Auftragsannahme (basierend auf jpdl)

3 Analyse 47 Am Workflow ist nur die Swimlane (Rolle) Projektleiter beteiligt. 1. Auftrag konfigurieren Bei dieser Aktivität gibt ein Mitglied der Gruppe Projektleiter die Variablen Auftragsnummer und Projektart ein. Datenbank auslesen Eine Applikation liest dann die zugehörigen Auftragsdaten aus der Access-Datenbank aus. Für die Aktivität werden folgende Variablen benötigt: Projektart [Werksatz Loseblatt DTP Projekt] Auftragsnummer [Integer] Die folgenden Variablen müssen aus der Access-Datenbank ausgelesen bzw. generiert und für die Aktivität Datenkontrolle bereitgestellt werden: Projektname [String] Verantwortlich [String] Technisch verantwortlich [String] Projektende [Date] Pfad [String] Kunde [String] Ansprechpartner [String] Kommentar [String] Die Variable Kommentar wird in allen Prozessen zur Informationsweitergabe übergeben und bei jeder Aktivität angezeigt. 2. Datenkontrolle Bei der nächsten Aktivität besteht die Möglichkeit einer Datenkontrolle, bei der auch der Pfad auf dem Fileserver angepasst werden kann. Wenn die Daten korrekt sind, werden beim Verlassen der Aktivität die folgenden Applikationen aufgerufen: Pfad anlegen Nach Abschluss der Kontrolle legt eine Applikation die erforderlichen Datenstrukturen in Abhängigkeit von der Projektart auf dem Fileserver an. Umlaufmappe drucken Gleichzeitig wird ein Druckauftrag mit Informationen für die papierbasierte Umlaufmappe ausgeführt. Bei einer fehlerhaften Dateneingabe kann die Konfiguration geändert werden, dazu können in der Aktivität Konfiguration ändern die Variablen Auftragsnummer und Projektart erneut eingetragen werden. 3. Ende Auftragsannahme Vom Projektleiter müssen nun noch die projektspezifischen Daten in das erstellte Verzeichnis kopiert werden.

3 Analyse 48 3.5.3 Kernprozess Satzworkflow Der Kernprozess Satzworkflow ist spezifisch für Aufträge im Rahmen der Strukturoffensive. Er beinhaltet den Ablauf für die Erstellung des Produkts. Bestandsaufnahme Ein Auftrag für die Strukturoffensive wird zunächst wie im Sub-Workflow Auftragsannahme beschrieben angelegt. Da das komplette Werk später in einer XML-Datei gehalten wird, werden danach Kundendaten und Projektinformationen vom Projektleiter in die Meta-Daten der XML-Datei eingetragen. Dann werden die angelieferten Daten des Kunden einer Datenprüfung unterzogen und falls möglich durch den Projektleiter in XML vorkonvertiert. Mitarbeiter des so genannten Struktur-Teams übernehmen nun die XML-Daten, korrigieren Fehler in der XML-Struktur und erfassen Sonderwünsche, wie z.b. Fußnoten und Marginalien, die nicht automatisch konvertiert wurden. Für Sonderwünsche, die nicht mit der DTD abbildbar sind, werden Processing-Instructions (PI) für die spätere Umsetzung durch den Setzer in die Daten eingefügt. Zusätzlich erfolgt eine mikrotypografische Bereinigung, bei der beispielsweise feste Leerzeichen, typografische Anführungszeichen oder Bindestriche vereinheitlicht werden. Der Arbeitsschritt Konvertierung ist abgeschlossen, wenn die Daten gegenüber der DTD valide sind und in einem Probesatzlauf auf Vollständigkeit geprüft wurden. Im nächsten Schritt werden die Satzanweisungen des Kunden von einem Mitarbeiter des Satz-Teams in die Meta-Daten der XML-Datei eingefügt. Vorhandene Satzprobleme bzw. Sonderwünsche, die in den PIs vermerkt sind, werden durch den Setzer gelöst, indem die relevanten Satzbefehle für die jeweilige PI definiert werden. Ein erster Kontrollausdruck wird für die interne Kontrolle des Umbruchs und der eingefügten Satzparameter sowie einer Feinjustierung der Typografie genutzt. Diese Hauskorrektur soll mittelfristig ausgelagert werden. Der Arbeitsschritt ist nach der Ausführung der Korrekturen aus der Hauskorrektur beendet. Nun wird das Buch als PDF-Datei oder Papierausdruck dem Kunden zur Korrektur vorgelegt. Die Kunden erhalten neben dem Ausdruck ein Typoprotokoll, das Informationen zum Umbruch, Silbentrennungen und typografischen Problemen auflistet. Ab dem zweiten Korrekturlauf erhalten die Kunden ebenfalls noch ein Vergleichsprotokoll, welches die Unterschiede zum vorangegangenen Satzlauf auflistet. Die anfallenden Autorkorrekturen werden durch den Setzer ausgeführt, typografische bzw. satztechnische Veränderungen werden mit Hilfe von PIs eingefügt.

3 Analyse 49 Nach der endgültigen Freigabe durch den Kunden wird eine druckfähige PDF-Datei erstellt. Weiterhin können die XML-Daten von überflüssigen PIs bereinigt werden. Zu Dokumentationszwecken werden alle verwendeten XML-Elemente, Sonderzeichen und verbleibenden PIs ausgewertet. Je nach Kunde wird zusätzlich noch eine HTML-Version des Inhalts erstellt. Nach der Freigabe durch den Projektleiter werden die oben genannten Daten dem Kunden per e-mail, auf einem FTP-Server zum Download oder per CD-ROM zur Verfügung gestellt. Die weiteren Arbeitsschritte werden im Sub-Workflow Auftragsabschluss beschrieben. Workflow-Modellierung Im Folgenden wird ein Vorschlag für die Modellierung des Satzworkflows erarbeitet. Der Workflow ist in Abbildung 3.3 grafisch dargestellt. Der jpdl-quellcode kann im Anhang A.3.1 eingesehen werden. Für die Modellierung des Workflows werden zunächst die beteiligten Swimlanes definiert: Projektleiter Diese Swimlane wird an die Sub-Workflows vererbt. Struktur-Team Mitarbeiter aus dem Struktur-Team übernehmen die Konvertierung der XML-Daten. TUSTEP-Satz Mitarbeiter dieses Bereichs sind für den Satz des Auftrags zuständig. Korrektorat Der Ablauf des Workflows gliedert sich in die folgenden Schritte: 1. Strukturoffensive Start Nach der Instanziierung wird der Sub-Workflow Auftragsannahme ausgeführt. 2. Zusatzkonfiguration Hier können zusätzliche Satzanweisungen für den Auftrag und Hinweise für die Konvertierung vom Projektleiter eingegeben werden. Folgende Variablen werden für die Aktivität benötigt: Werktitel [String] Kurztitel [String] Projekt Datei [String] Kommentar [String] Der Projektleiter muss entscheiden, ob direkt zur manuellen Konvertierung der Daten übergegangen wird oder ob er eine automatische Vorkonvertierung veranlasst. Beim Verlassen der Aktivität wird durch die Applikation Daten Erstellen die XML-Datei für den Satz mit den vorhandenen Meta-Daten befüllt.

3 Analyse 50 Abbildung 3.3: Prozessbild des Satzworkflows (basierend auf jpdl) 3. Vorkonvertierung Dieser Applikationsaufruf wird nur ausgeführt, falls die Daten automatisch vorkonvertiert werden können. Im Anschluss wird die Aktivität Konvertierung aufgerufen. 4. Konvertierung Ein Mitglied der Gruppe Struktur-Team übernimmt die Konvertierung der Daten. Es können beliebig viele Probesatzläufe ausgeführt werden, um das Ergebnis zu kontrollieren. Mit der Variable Daten OK bestätigt der Benutzer die abgeschlossene Konvertierung. Er kann die Aktivität über die Transition Daten valide verlassen. Dann wird die Aktivität TUSTEP-Probesatz aufgerufen.

3 Analyse 51 5. TUSTEP-Probesatz Beim Eintritt in die Aktivität werden die Applikationen Satzlauf und Dokument Check ausgeführt, um notwendige Daten für den Arbeitsschritt bereitzustellen. Satzlauf Es wird ein Probesatzlauf erstellt. Dokument Check Eine Applikation überprüft die Daten auf Vollständigkeit und Besonderheiten im Satz. Ein Mitarbeiter der Gruppe TUSTEP-Satz übernimmt dann den Probesatz des Auftrags. Die Variable Satzlauf erhält beim Probesatz den Wert 0. Nach erfolgter Satzanpassung übergibt er den Auftrag zunächst an die Aktivität Interne Hauskorrektur. 6. Interne Hauskorrektur Ein Mitglied aus der Gruppe Korrektorat übernimmt die Kontrolle auf Vollständigkeit. Mit der Variable Daten OK bestätigt der Benutzer den Abschluss der Arbeiten. Danach gibt er den Auftrag an die Aktivität TUSTEP-Satz. 7. TUSTEP-Satz In diesem Prozessschritt werden die Satzläufe des Auftrags organisiert. Von einem Mitarbeiter aus der Gruppe TUSTEP-Satz können beliebig viele Satzläufe mit zwischengeschalteter Kundenkorrektur durchgeführt werden. Die Satzläufe wiederholen sich bis zur Freigabe durch den Kunden. Bei jedem Satzlauf stellt die Applikation Satzlauf bereitstellen die notwendigen Daten zur Verfügung. Die Variable Satzlauf informiert über die Anzahl der durchlaufenen Satzläufe und damit über den zu bearbeitenden Ordner. Nach der Imprimatur durch den Kunden werden mit der Aktivität PDF Erstellung die endgültigen Druckdaten erstellt. 8. Satzlauf bereitstellen Diese Applikation stellt das Typoprotokoll und ab dem zweiten Satzlauf das Vergleichsprotokoll bereit. Der Kunde kann dadurch auf die aktuellsten Korrekturinformationen zugreifen. Gleichzeitig wird ein neuer Ordner für den folgenden Satzlauf auf dem Fileserver erstellt und die Variable Satzlauf hochgezählt. Da Kunden noch nicht in das System integriert sind, können diese auch nicht in einer Aktivität Kundenkorrektur die Druckfreigabe erteilen. 9. PDF Erstellung Nach der Druckfreigabe werden die druckfähigen PDF-Daten durch einen Mitarbeiter der Gruppe TUSTEP-Satz überprüft. Dieser stellt die Daten dann dem Kunden oder direkt der Druckerei zur Verfügung. Optional kann die Applikation Clean XML und HTML Erstellung aufgerufen werden. Die Variable Daten OK muss nach dem Abschluss der Arbeiten gesetzt werden. Beim Verlassen der Aktivität über die Transition Daten versendet wird der Sub-Workflow Auftragsabschluss aufgerufen. 10. Clean XML Diese Applikation beinhaltet einen Konvertierer, der überflüssige Satzanweisungen aus den Daten entfernt. 11. HTML Erstellung Diese Applikation erstellt HTML-Daten aus den XML-Daten. 12. Ende Strukturoffensive Diese Aktivität beendet den Satzworkflow.

3 Analyse 52 3.5.4 Auftragsabschluss Zur Standardisierung wird der Hilfsprozess Auftragsabschluss identisch für alle Projekte erstellt. Ebenso wie der Hilfsprozess Auftragsannahme soll er in allen Projekten einsetzbar sein und als Sub-Workflow wiederverwendet werden können. Bestandsaufnahme Der Workflow Projektabschluss beinhaltet typischerweise die folgenden Prozessschritte: Vom Projektleiter wird überprüft, ob der Auftrag vollständig ausgeführt wurde und ob alle erforderlichen Aufgaben erfüllt sind. Dann wird auf Grundlage des Angebots und der möglicherweise angefallenen zusätzlichen Arbeitszeiten eine Abrechnung erstellt und eine Wirtschaftlichkeitsanalyse durchgeführt. Danach wird die Rechnung für den Auftrag erstellt. Zusätzlich wird noch die Endsicherung der Daten durchgeführt, um die Satz- und Auftragsdaten für mögliche Folgeaufträge bereitzuhalten. Die Abrechnung und Wirtschaftlichkeitsanalyse sowie das Zahlungsverhalten des Kunden soll auch in Zukunft nicht in das WfMS integriert werden. Workflow-Modellierung Der Workflow Auftragsabschluss ist ähnlich dem Workflow Auftragsannahme einfach strukturiert. Der Workflow ist in Abbildung 3.4 grafisch dargestellt. Der jpdl-quellcode des Workflows kann im Anhang A.3.1 eingesehen werden. Abbildung 3.4: Prozessbild des Workflows Auftragsabschluss (basierend auf jpdl)

3 Analyse 53 Es wird nur die Swimlane Projektleiter benötigt. Ein Mitglied dieser Gruppe ist für die Abarbeitung der Aufgaben zuständig. 1. Auftrag abschließen Bei dieser Aktivität wird vom Projektleiter geprüft, ob der Auftrag vollständig erfüllt ist. 2. Rechnung erstellen Die Aktivität ist abgeschlossen, wenn die Rechnung erstellt ist. Der Bezahlvorgang und mögliche Mahnvorgänge sollen nicht vom WfMS verwaltet werden, so dass direkt die Aktivität Daten archivieren aufgerufen werden kann. 3. Daten archivieren Für die Endsicherung des Auftrags kann ein Archivierungspfad und die Archivierungs Datei vom Projektleiter eingetragen werden. Zusätzlich können noch Hinweise zur Archivierung eingegeben werden, die unter dem Archivierungspfad in der Datei readme.txt abgelegt werden. Zur Sicherheit muss die Variable Daten OK gesetzt werden. Hinweise zur Archivierung [String] Archivierungspfad [String] Archivierungs Datei [String] Daten OK [Boolean] Von der Applikation Archiv erstellen werden die Auftragsdaten komprimiert und im Archivierungspfad abgespeichert. Archiv erstellen Diese Applikation erstellt ein ZIP-Archiv mit den Hinweisen zur Archivierung und den Projektdaten. 4. Ende Auftragsabschluss Diese Aktivität beendet den Workflow.

4 Evaluation By a small sample we may judge of the whole piece. Miguel de Cervantes Saavedra (1547 1616) Don Quixote de la Mancha Die im Kapitel Analyse erarbeiteten Kriterien für das System werden in diesem Kapitel an konkreter Software evaluiert. Zu Beginn werden die zu untersuchenden WfMS und Wiki-Systeme ausgewählt und vorgestellt. Diese werden dann anhand der erarbeiteten Kriterien getestet. Dazu wird die in der Analyse erarbeitete Aufteilung in Ausschlusskriterien und wünschenswerte Features übernommen. Sowohl die technischen Anforderungen hinsichtlich der Komplexität und Wartbarkeit des Systems als auch die wirtschaftlich vertretbaren Kosten für den Betrieb und die Weiterentwicklung werden berücksichtigt. Dann werden die Ergebnisse ausgewertet und eine Aufwandsabschätzung vorgenommen. 4.1 Ausgewählte WfMS Sowohl im kommerziellen als auch im Open-Source Bereich gibt es eine Fülle von Java basierenden WfMS. In dieser Arbeit werden nur Open-Source Implementierungen untersucht, d.h. die Produkte müssen entweder mit der GNU General Public License (GPL) oder GNU Lesser General Public License (LGPL) lizenziert sein 1. Im Folgenden werden nun Open-Source Systeme vorgestellt, die zusätzlich einen hohen Verbreitungsgrad, eine große Anzahl an aktiven Entwicklern und eine stabile Entwicklungsstufe aufweisen. Für eine Übersicht auf weitere Java WfMS wird auf http://www.manageability.org/blog/stuff/ workflow in java verwiesen. 1 Beide Lizenzen lassen eine Anpassung bzw. Veränderung des Quellcodes zu. Zu den Unterschieden der beiden Lizenzen im Detail siehe [Fre96].

4 Evaluation 55 4.1.1 Enhydra Shark Enhydra Shark ist ein LGPL lizenziertes Produkt von Enhydra.org. Die Software kann unter http://shark.objectweb.org kostenlos heruntergeladen werden. Die Implementierung der Workflow-Engine basiert auf dem XPDL-Standard. Für den Entwurf von Workflows steht der grafische XPDL-Editor Enhydra JaWE 2 oder dessen Weiterentwicklung JPEd 3 zur Verfügung. Der Workflow-Enactment-Service wird in der Standardinstallation als CORBA-Service erzeugt. Shark kann aber auch als Modul bei der Entwicklung eines eigenen Clients oder als Webservice genutzt werden. Für die Testinstallation wird eine auf Swing basierende Administrationsschnittstelle mitgeliefert, die die CORBA-API des WfMS nutzt. Gründe für die Auswahl Enhydra Shark wurde ausgewählt, da es von vielen Quellen als stabiles Produkt verifiziert wurde und bei Arbeiten zum Thema Open-Source-WfMS regelmäßig erwähnt wird. Das Produkt wird aktuell weiterentwickelt und es erscheinen regelmäßig neue Versionen, die aktuelle Version 2.0 erschien im Juni 2006. Die Software wird unter anderem von professionellen Entwicklern der Together Software AG entwickelt, die auch kommerziellen Support anbietet. Die strikte Ausrichtung am XPDL-Standard und die damit verbundene Zukunftssicherheit machen Enhydra Shark zu einem interessanten Kandidaten für die Evaluation. 4.1.2 JBoss jbpm Die Software Java Business Process Manager (jbpm) ist ebenfalls unter der LGPL lizenziert und wird maßgeblich von JBoss Inc. 4 entwickelt. Das Produkt ist in die so genannte JBoss Enterprise Middleware Suite (JEMS), ein Softwarepaket, das verschiedene JBoss Middleware Produkte zusammenfasst, integriert. Dies soll die Entwicklung und Bereitstellung von e-business Applikationen erleichtern. Die aktuelle Version 3.1.2 steht unter http://www.jboss.com/products/jbpm/downloads zum Download bereit. JBoss jbpm bezeichnet sich als flexibles und erweiterbares WfMS, Abbildung 4.1 zeigt das Konzept. Besonderer Wert wird auf die eigenentwickelte Workflow-Ausführungssprache jpdl gelegt, die den Anspruch erhebt, sowohl ein mächtiges Tool für Software Entwickler als auch einfach erlernbar 2 Abrufbar unter http://forge.objectweb.org/projects/jawe 3 Abrufbar unter http://jped.sourceforge.net 4 Das Hauptprojekt der Firma JBoss ist die Implementierung des J2EE-konformen JBoss Application Servers.

4 Evaluation 56 für Manager, die für das Prozessdesign verantwortlich sind, zu sein. In diesem prozessorientierten Programmiermodell kann innerhalb des Workflow-Schemas nahtlos Java Code platziert werden. Die Standardinstallation enthält bereits einen rudimentären Webclient und JUnit Tests. Abbildung 4.1: Interaktion durch jbpm [Koe04] Gründe für die Auswahl Die Integration innerhalb der JEMS-Pakets stellt eine zukünftige Weiterentwicklung der Software sicher und bietet viele zukünftige Erweiterungsmöglichkeiten. Zudem entwickeln und koordinieren die bei JBoss angestellten Vollzeit-Entwickler das Projekt. Obwohl die jpdl nicht standardkonform ist, erscheint der Ansatz interessant und einer näheren Prüfung würdig. Ein weiterer Grund für die Aufnahme in die engere Auswahl ist die ausgezeichnete Dokumentation, die unter http://www.jboss.com/products/jbpm/docs eingesehen werden kann. 4.1.3 Bonita Das WfMS Bonita ist unter der LGPL lizenziert und wird maßgeblich vom französischen Unternehmen Bull 5 entwickelt. Die neueste Version 2.0 kann unter http://bonita.objectweb.org heruntergeladen werden. Das Workflow-System ist ebenfalls in einen Application Server integriert, es wird die Verwendung von JOnAS 6 empfohlen. Die Workflow-Engine basiert auf dem XPDL-Standard und hat als besonderes Feature die Möglichkeit, Prozessdefinitionen während der Laufzeit zu verändern. Diese Flexibilität ist ein Alleinstellungs- 5 http://www.bull.com 6 Der Java Open Application Server ist eine Implementation des J2EE-Standards. Abrufbar unter http://jonas. objectweb.org.