BPM- Systeme im Vergleich

Transkript

1 BPM- Systeme im Vergleich Es gibt heutzutage eine Vielzahl an Systemen, welche bei der Umsetzung des Business Process Management Unterstützung leisten. Die Unterschiede liegen dabei oftmals im Detail, können aber dennoch entscheidend für einen Projekterfolg sein. In diesem Artikel wird ein Kriterienkatalog für den Vergleich der wichtigsten Funktionalitäten im Business Process Management eingeführt. Die eingeführten Kriterien werden anschließend für den Vergleich von vier Business Process Management Systemen verwendet: ActiveVOS 8.0, Activiti 5.0, Bizagi Xpress und Intalio Dr. Manuel Götz

2 Inhaltsverzeichnis 1 Einleitung Ausgewählte BPM- Systeme ActiveVOS Activiti Bizagi Xpress Intalio BPMS Vergleichskriterien Modellierung und Implementierung Modellierungssprache Einbindung weiterer Modellierungselemente Anzeige der Verantwortlichkeiten Formulardefinitionen für Prozessschritte Definition des Datenflusses Verifikation von Modellen Simulation Automatisierte Testläufe Dokumentation Versionierung Modellierung Import und Export von Prozessmodellen Deploymentalternativen Ausführung Ausführungsformate... 14

3 3.2.2 Erweiterung um Ausführungselemente Skalierung Persistenz Versionierung Ausführung Web Services Integration Integration einer Programmiersprache Einbinden weiterer Konnektoren Nutzeroberfläche für Prozessbeteiligte Administratoroberfläche Schnittstellen Vergleich der BPM- Systeme Einzeldiskussion ActiveVOS Activiti Bizagi Xpress Intalio BPMS Vergleichsübersicht Fazit Quellen Kontaktinformationen... 40

4 1 Einleitung Business Process Management (BPM) ist mittlerweile als Methodik in seinem Wert anerkannt und in einer Vielzahl von Unternehmen etabliert. Noch mehr Unternehmen haben den Wert erkannt und planen eine Einführung [29]. Bei diesem Unterfangen sind viele Entscheidungen verschiedenster Art zu treffen. Dazu gehören strategische Entscheidungen hinsichtlich Vorgehen und Methodik ebenso wie auf fachlichen Gesichtspunkten basierende Realisierungsentscheidungen. Eine zentrale Entscheidung ist in diesem Zusammenhang die Auswahl eines BPM- Systems, welches die Umsetzung der gewünschten Methodik bestmöglich unterstützt. Es gibt eine Fülle von Angeboten an BPM- Systemen, welche nicht einfach zu überblicken ist. Die Unterschiede liegen im Detail und die Tragweite einer Entscheidung ist für BPM- Neulinge nicht immer abschätzbar. Für große Konzerne gibt es verschiedene Studien wie die Ovum- Vergleichsstudie [24], welche die Systeme nach verschiedenen Gesichtspunkten untersucht. Die ausgewählten Kriterien lassen sich aber nicht direkt auf die Bedürfnisse von Unternehmen kleinerer oder mittlerer Größe anwenden. Weiterhin liegen viele der in großen Studien untersuchten BPM- Systeme in einem Preissegment, welches das gegebene Budget teilweise um Dimensionen übersteigt. Für diesen Preis wird eine Vielzahl an Features geboten, welche nicht benötigt wird oder welche erst bei einem Einsatz in einer bestimmten Software- Umgebung meist im Zusammenspiel mit anderen Produkten desselben Herstellers - ihr volles Potential entfalten können. Für diese Vergleichsstudie wurden bewusst vier BPM- Systeme gewählt, welche im mittleren bis unteren Preissegment zu finden sind. Gleichzeitig müssen alle Kernfunktionalitäten eines modernen BPM- Systems angeboten werden. Beispiele für solche Kernfunktionalitäten sind die Modellierung und Ausführung von Prozessen. Diese Funktionalitäten sind sicherlich in mehr als den berücksichtigten BPM- Systemen verfügbar. Als letztes Auswahlkriterium diente daher das subjektive Kriterium des geschätzten Interesses. Folglich wurden aus den zur Verfügung stehenden Kandidaten schließlich diejenigen BPM- Systeme ausgewählt, zu welchen die BPM- Berater von itransparent am häufigsten nach Informationen gefragt wurden. Die Vergleichskriterien orientieren sich ebenfalls an denjenigen Kriterien, welche häufig von Kundenseite an ein BPM- System gestellt werden. Jeder Kunde hat gewisse spezielle Anforderungen, aber ein Großteil der Anforderungen ist wiederkehrend und dient als Grundlage für den hier angewandten Kriterienkatalog. Die Zielsetzung dieses Vergleichs ist es nicht, einen Sieger zu finden und vorbehaltlos zu empfehlen. Jedes der analysierten BPM- Systeme weist Stärken und Schwächen auf. Somit gilt es, für konkrete Einsatzszenarien das am besten geeignete BPM- System bestimmen zu können. Hierbei spielen die speziellen Anforderungen eines jeden Kunden

5 eine große Rolle. Ziel ist es also, die Auswahl eines BPM- Systems für einen bestimmten Anwendungsfall zu erleichtern. 2 Ausgewählte BPM- Systeme Zu Beginn werden die vier ausgewählten BPM- Systeme kurz vorgestellt. Um die Ausrichtung eines jeden BPM- Systems zu verdeutlichen, geschieht dies in freier Form und ohne die Orientierung an einem Kriterienkatalog. Die ausgewählten Systeme werden in alphabetischer Reihenfolge eingeführt; mit der Reihenfolge ist keinerlei Wertung verbunden. 2.1 ActiveVOS ActiveVOS von Active Endpoints setzt in der Ausführung von Prozessen auf eine sehr strikte Umsetzung der Standards BPEL 2.0 [8], WS- HumanTask [4] und BPEL4People [7]. In der Modellierung orientiert man sich am Standard BPMN 2.0 [24]. Durch die Umsetzung von Standards soll beim Einsatz von BPM eine Abhängigkeit von einem bestimmten BPM- System vermieden werden, da die Prozesse selbst portabel bleiben. ActiveVOS basiert auf dem Open Source BPEL Server ActiveBPEL. Diverse Erweiterungen wie Clustering- Mechanismen machen es aber auch für den Einsatz unter großer Last geeignet. Weiterhin wurde eine fortgeschrittene Modellierungsumgebung entwickelt, in welcher die Prozesse erstellt werden. Eine Besonderheit von ActiveVOS ist dabei, dass ein Prozessmodell on- the- fly also ohne Zeitverzögerung direkt während der Modellierung in ausführbaren BPEL- Code überführt wird. Dies verhindert Round- Trip- Probleme, wie sie bei einem generativen Ansatz [20] zur Erstellung ausführbarer Prozesse auftreten können. In ActiveVOS werden Änderungen ausschließlich im Prozessmodell vorgenommen. Somit sind ausgeführte Prozesse immer konsistent zum vorliegenden Modell. Als besonderes Feature wurde in ActiveVOS das Complex Event Processing (CEP, [8]) integriert, welches Echtzeit- Auswertungen auf einem oder einer Menge von Prozessen ermöglicht. Eingesetzt wird ActiveVOS von einer Vielzahl von Unternehmen und Institutionen. Als Institution kann beispielsweise das FBI genannt werden, welches ActiveVOS zur Umsetzung der Services für das Next Generation Identification System nutzt [2]. Diese Services umfassen beispielsweise die Suche nach Fotos oder Fingerabdrücken. Toyota Motor Europe nutzt ActiveVOS als Komponente ihres Fortbildungssystems, welche den Zugriff auf Materialien oder den Veranstaltungskalender regelt [4]. Anwendungen mit sehr hoher Last wurden bei CERN realisiert, wo ActiveVOS eine Kernkomponente der Service- orientierten Architektur ist. Es wurden über 50 verschiedene Prozesse wie Materialbestellung oder Zugangskontrollen umgesetzt, welche täglich ca mal als

6 neue Instanz gestartet werden. Insgesamt wurden bei CERN bisher ca. 1.2 Mio. Prozess- Instanzen mit ActiveVOS ausgeführt [1]. Abbildung 1 Screenshot von ActiveVOS [3] 2.2 Activiti 5.0 Activiti ist mit Abstand das jüngste BPM- System in diesem Vergleich. Da es von den Entwicklern selbst als (inoffizielle) Weiterentwicklung das viel eingesetzten jbpm- Systems [27] verstanden wird, wird bereits die erste Version als 5.0 bezeichnet. Durch die Mitwirkung verschiedener Entwickler des jbpm- Projekts an Activiti findet dabei auch ein entsprechender Wissenstransfer statt. Veröffentlicht ist Activiti als Open Source- Projekt unter der Apache License.

7 Prozesstechnisch setzt Activiti auf die Umsetzung des BPMN 2.0- Standards sowohl als Modellierungs- wie als Ausführungssprache. Trotzdem wird eine starke Trennlinie zwischen der reinen Modellierung eines Prozesses und dessen Implementierung zum Zwecke der Ausführung gezogen. So werden Fachexperten nicht mit technischen Informationen überlastet und IT- Experten können in einer geeigneten Entwicklungsumgebung arbeiten. Dabei ist Activiti stark auf die Umsetzung in Java fokussiert. Abbildung 2 ScreenShot von Activiti [5] Hinter dem Activiti- Projekt stehen verschiedene namhafte Firmen wie Signavio, Camunda, Alfresco oder MuleSoft. Da es als Open Source- Projekt angelegt ist, kann sich darüber hinaus jeder Interessierte an der Weiterentwicklung beteiligen. 2.3 Bizagi Xpress Eine strenge Trennung von Modellierung und Implementierung von Prozessen nimmt Bizagi vor. Zusätzlich zur Implementierungsumgebung Xpress gibt es einen frei erhältlichen Modeler (getestet wurde Version 1.5.1), welcher auf die

8 modellierungsrelevanten Funktionen reduziert ist. Diese Reduzierung kommt insbesondere Fachexperten mit wenig technischem BPM- Wissen entgegen. Abbildung 3 Screenshot von Bizagi [8] Prozessmodelle können aus dem Modeler in die Implementierungsumgebung Xpress übernommen und anschließend dort technisch umgesetzt werden. Auch Änderungen aus fachlicher Sicht sind in Xpress weiterhin möglich. Die Modellierung selbst wird mit der Modellierungssprache BPMN 2.0 durchgeführt. Bei der Implementierung wird ein IT- Experte in mehreren Wizards komfortabel durch die zur Umsetzung notwendigen Schritte geführt. Die Ausführung selbst erfolgt proprietär auf Basis eines Datenbank- Schemas. BizAgi ist vor allem im Finanz- und Versicherungssektor stark vertreten. Zu den Kunden gehören beispielsweise die Sachsen Bank (Deutschland), die BHF- Bank International (Niederlande) und die Banco della Marche (Italien).

9 2.4 Intalio BPMS Intalio BPMS ist eines der am längsten existierenden Open Source BPM- Systeme. Durch diese lange Lebensdauer und wegen der Open Source- Strategie kann es auf eine große Verbreitung verweisen. Intalio BPMS setzt ebenfalls auf den Standard BPMN allerdings in Version 1.2 und auf eine Ausführung mit BPEL 2.0 Dabei wird ein Zero- Coding- Ansatz angestrebt und zumindest bei Standard- Fällen auch erreicht. Ein Beispiel für diesen Ansatz ist der Data Editor, in dem ein Datenfluss zwischen Prozessschritten dargestellt und modelliert werden kann. Abbildung 4 Screenshot von Intalio BPMS [16] Als Kunden kann Intalio Unternehmen aus verschiedenen Branchen und verschiedener Größe anführen. Dabei ist allerdings auf der Homepage nicht immer eindeutig ersichtlich, ob diese Kunden wirklich das Intalio BPMS oder ein anderes Intalio- Produkt einsetzen oder zu welchem Zweck sie es nutzen. Aus dem Versicherungssektor gehören

10 die Allianz oder die Versicherungskammer Bayern zu den Kunden. Als Dienstleister nutzt beispielsweise Faceo das Intalio BPMS zur Planung und zum Management von industriell genutzten Gebäuden. Connexion verwaltet mit diesem BPM- System verschiedene Kommunikationsnetzwerke. 3 Vergleichskriterien Um BPM- Systeme objektiv vergleichen zu können, müssen Vergleichskriterien definiert werden. Die hier verwendeten Kriterien werden in diesem Kapitel mit einer kurzen Erläuterung eingeführt und im weiteren Verlauf in Bezug auf die einzelnen BPM- Systeme diskutiert. Die Kriterien selbst leiten sich aus solchen Anforderungen ab, welche häufig an BPM- Systeme gestellt werden. Für eine bessere Übersicht werden sie in Kriterien bezüglich der Modellierung und der Ausführung von Prozessen unterteilt. 3.1 Modellierung und Implementierung In diesem Kapitel finden sich Kriterien, welche für das Erstellen eines Prozessmodells sowohl auf fachlicher als auch auf technischer Ebene bedeutsam sind. Dies reicht von der Auswahl / Anpassung der Modellierungssprache bis zu den Deployment- Möglichkeiten eines ausführbaren Prozessmodells auf einem Server Modellierungssprache Die Modellierungssprache ist häufig ein entscheidender Faktor, wenn nach der Zufriedenheit von Fachexperten mit einem BPM- System gefragt wird. Auf der einen Seite muss eine Modellierungssprache leicht verständlich und erlernbar sein, auf der anderen Seite sollen aber auch möglichst alle komplexen Zusammenhänge in realen Anwendungsfällen damit ausgedrückt werden können. Der Modellierungsstandard Business Process Modeling and Notation (BPMN) hat sich inzwischen in vielen Bereichen durchgesetzt. Deswegen setzen viele BPM- Systeme BPMN als Modellierungssprache um. Da es inzwischen allerdings mehrere Versionen gibt, ist das gängige Label "BPMN wird unterstützt" für ein BPM- System nicht mehr sonderlich aussagekräftig. Die Version 1.2 hatte beispielsweise nur eine Diagrammart, während in der Version 2.0 vier Diagrammtypen definiert werden (Prozessdiagramme, Choreographiediagramme, Kollaborationsdiagramme, Konversationsdiagramme). Dabei unterstützen selbst BPM- Systeme, die mit BPMN 2.0 als Modellierungssprache werben, nur selten alle Diagrammtypen. Die Mischung aus ungenauen Angaben und der zentralen Stellung der Modellierung im BPM macht die Auswahl eines BPM- Systems in diesem Punkt zu einem heiklen Unterfangen. Es muss sorgfältig geprüft werden, ob die unterstützte

11 Modellierungssprache alle Anforderungen erfüllt. Andernfalls werden sich Unzulänglichkeiten durch ein gesamtes BPM- Projekt ziehen und sich im Verlauf potenzieren Einbindung weiterer Modellierungselemente Insbesondere von Seiten der Fachexperten wird im Verlauf eines Projekts häufig die Frage nach weiteren Modellierungselementen und somit nach Erweiterungen der Modellierungssprache gestellt. Diese Anforderung ist meist in der Erkenntnis eines Fachexperten begründet, dass Gegebenheiten der Realität sich nicht adäquat in einer Modellierungssprache umsetzen lassen. Prinzipiell gibt es zwei Kategorien, in welche sich geforderte Erweiterungen unterteilen lassen. Zum einen kann die Modellierung für das Verständnis eines Fachexperten schlicht zu feingranular oder technisch sein. In diesem Fall kann durch Komposition verschiedener bestehender Modellierungselemente in einem neuen Modellierungselement Abhilfe geschaffen werden. Zum anderen kann aber auch eine Semantik bzw. ein Verhalten eines Modellierungselements zur Laufzeit gefordert sein, welches sich mit einer Modellierungssprache nicht umsetzen lässt. In diesem Fall müsste eine wirkliche Erweiterung einer Modellierungssprache um ein neues Element erfolgen. Generell gilt, dass die Erweiterung einer Modellierungssprache der Anforderung nach einer standardisierten Modellierungssprache in den meisten Fällen entgegensteht. Ein Standard schließt spezielle Erweiterungen in vielerlei Hinsicht aus, um durch einheitliche Modelle Verständigungsprobleme zu vermeiden. Vor der Auswahl eines BPM- Systems sollte also die Frage geklärt werden, ob eine angebotene Modellierungssprache den Anforderungen genügt. Falls dies nicht der Fall ist, so sind Erweiterungsmöglichkeiten und deren Umsetzung zu prüfen Anzeige der Verantwortlichkeiten Wenige Geschäftsprozesse lassen sich komplett automatisieren. Meist ist beispielsweise an einem oder mehreren Punkten die Einbindung von Menschen in den Prozessverlauf notwendig, um eine Entscheidung zu treffen oder zumindest zu überprüfen. Dabei muss es bei der Ausführung das Ziel sein, die betreffenden Entscheider mit allen notwendigen Informationen zu versorgen und unwichtige Informationen zu filtern. Aus Modellierungssicht sollte in einem Prozessmodell erkennbar sein, welche Person oder Personengruppe für die Ausführung eines bestimmten Prozessschritts verantwortlich ist. In nicht allgemein definierter Form ist diese Zuweisung von Prozessschritten an Personen in jedem ausführbaren Modell hinterlegt. Oftmals muss sie jedoch in ausführungsorientierten Properties gesucht werden oder ist sehr technisch

12 beispielsweise in Form einer LDAP- Abfrage [8] definiert. Im Sinne einer guten Modellierung sollten die Verantwortlichkeiten direkt in einem Prozessmodell in lesbarer und verständlicher Form verfügbar sein. Dies kann in vielen Fällen Fehlzuweisungen verhindern, da Fachexperten die Verantwortlichkeiten überprüfen können Formulardefinitionen für Prozessschritte Die Ausführung von Prozessschritten durch Menschen erfolgt meist durch die Verwendung von Formularen. Daher ist eine gängige Anforderung an ein BPM- System eine Unterstützung bei der Formulardefinition und bei der Einbindung von Formularen in einen Prozess zu bieten. In einem international agierenden Umfeld wird diese Anforderung oft um die Unterstützung mehrsprachiger Formulare erweitert Definition des Datenflusses Prozesse bestehen aus einer Vielzahl von Prozessschritten. Zwischen diesen Prozessschritten werden häufig Datenflüsse definiert, d.h. in einem Prozessschritt werden Daten gesammelt, welche dann in einem anderen Prozessschritt verarbeitet werden. In diesem Zusammenhang wird von Datenproduzenten und Datenkonsumenten in einem Prozessmodell gesprochen. Verarbeitete Daten können dabei in unterschiedlicher Form auftreten. Dokumente werden beispielsweise häufig ohne weitere Interpretation durch einen Prozess zwischen Prozessschritten transferiert. Für Daten, auf deren Grundlage beispielsweise automatisiert Entscheidungen getroffen werden sollen, müssen interpretierbare Datenstrukturen definiert werden. Da die Definition solcher Datenstrukturen auch im BPMN- Standard nur ungenügend Berücksichtigung findet, bietet hier jedes BPM- System eine eigene Lösung. Diese Lösungen unterscheiden sich sowohl in Mächtigkeit als auch in Benutzerfreundlichkeit und sind bei der Planung von datenintensiven Prozessen ein wichtiges Kriterium Verifikation von Modellen Ein Prozessmodell ist nach der Modellierung durch einen Fachexperten in der Regel nicht ausführbar. Dafür benötigte Informationen werden durch IT- Experten in der Implementierungsphase hinzugefügt. In dieser Phase ist eine automatisierte Verifikation eines Prozessmodells durch ein BPM- System, welche auf formale Fehler im Hinblick auf Modellierungssprache und Ausführungssprache hinweist, eine große Hilfe. Unzulänglichkeiten werden schnell identifiziert und können noch vor der Testphase behoben werden. Als Folge wird die Entwicklungsgeschwindigkeit je nach Qualität der Verifikation in einem BPM- System leicht oder deutlich erhöht.

13 3.1.7 Simulation Ausführbare Prozesse werden meist im Zusammenspiel mit einer Service- orientierten Umgebung erstellt. Dabei hat man nicht immer Kontrolle über die externen Services für Testzwecke. Diese Services können beispielsweise kostenpflichtig und somit zu teuer für eine Testphase sein oder ihre Erstellung erfolgt erst zu einem späteren Zeitpunkt in einem Projekt. In einem solchen Fall ist eine Simulation hilfreich. Unter Simulation wird hier die Möglichkeit verstanden, ein Prozessmodell ohne Aufrufe an Services zu testen. Stattdessen sollen die Rückgabewerte externer Aufrufe im BPM- System definiert werden können. So lässt sich das Verhalten eines Prozesses in einem kontrollierten Umfeld testen und es kann überprüft werden, ob sich ein Prozess unter bestimmten Bedingungen wie erwartet verhält. Fehler durch externe Systeme sind dabei ausgeschlossen. Dadurch erlaubt eine Simulation eine verlässliche Analyse in Bezug auf ein korrektes Prozessverhalten Automatisierte Testläufe Im BPM wird davon ausgegangen, dass Messungen und Analysen basierend auf ausgeführten Prozessen zu weiteren Erkenntnissen führen und die kontinuierliche Verbesserung eines Prozesses ermöglichen. Eine Folge dieses Vorgehens ist, dass es regelmäßig neue Prozessversionen mit eingefügten Änderungen gibt. Das Einbringen von Änderungen birgt neben den erwünschten positiven Effekten aber immer die Gefahr unbeabsichtigter Nebeneffekte oder neuer Fehler. Ein Feature zum Verhindern solcher Fehler sind automatisierte Testläufe. Diese decken gängige Szenarien ab und werden nach dem Einbringen von Änderungen ausgeführt. Da die Anzahl potentieller Testläufe insbesondere bei komplexen Prozessen sehr hoch ist, ist eine automatisierte Unterstützung unerlässlich. Dies ermöglicht das Auffinden von Nebeneffekten nach Änderungen und dient somit der Prozessstabilität und letztlich der Qualität Dokumentation BPM ist kein Implementierungskonzept oder ein Vorgehensmodell. BPM ist ein holistischer, ganzheitlicher Ansatz in Bezug auf die Strukturierung und Ausführung von Prozessen. Zur Unterstützung eines ganzheitlichen Ansatzes muss ein BPM- System auch Funktionalität in Bezug auf die Dokumentation eines Prozesses oder Projektes bieten. Grundsätzlich bringt der BPM- Ansatz im Hinblick auf Dokumentation schon sehr viel mit sich. Allein ein Prozessmodell sagt - in anschaulicher Form modelliert - viel über einen Ablauf aus. Allerdings ist dies in realen Projekten nicht ausreichend. Eine Einbettung ausführlicher Kommentare und Beschreibungen in ein Prozessmodell muss in einer Form möglich sein, welche über die Prozessabbildung hinausgeht. Zu diesen

14 Kommentaren und Beschreibungen ist allgemeiner Zugang zu ermöglichen, d.h. sie dürfen nicht nur über ein BPM- System einsehbar sein. Möglichkeiten dafür sind der Zugang über einen Browser oder der Export in gängigen Dokumentformaten wie beispielsweise Word. Dabei muss die Verknüpfung zwischen Prozessen und Kommentaren erhalten bleiben, um den Kontext herzustellen und zielgerichtete Diskussionen zu erlauben Versionierung Modellierung Prozessmodelle sind ständigen Änderungen unterworfen. Dies ist zum einen auf die Anforderungen nach Verbesserungen zurückzuführen, zum anderen müssen Prozesse neuen Gegebenheiten in den realen Abläufen oder der IT- Umgebung angepasst werden. Aus diesem Grund besteht Bedarf für eine Versionierung von Prozessmodellen, wofür ein BPM- System entsprechende Unterstützung bieten muss. Dies ermöglicht das Rückspringen auf frühere Versionen bei Fehlerfällen oder ein Nachverfolgen der Prozessentwicklung. Somit geht auch bei Anpassungen eines Prozessmodells kein Wissen verloren, welches zu einem späteren Zeitpunkt hilfreich sein kann Import und Export von Prozessmodellen Prozessmodelle stellen die internen Abläufe beispielsweise eines Unternehmens oder einer Institution dar. Die BPM- Systeme, mit welchen Prozesse initial erstellt wurden, veralten häufig in einer deutlich höheren Geschwindigkeit als die Prozesse. Jährliche Releases neuer Major- Versionen sind nicht ungewöhnlich. Um nicht an ein BPM- System oder gar an eine spezielle Release- Version gebunden zu sein, sind Import- und Exportformate von hoher Bedeutung. Sie ermöglichen den automatisierten Transfer von Prozessmodellen zwischen verschiedenen BPM- Systemen. Bei Unterstützung standardisierter Formate wie XPDL [35] ist sogar der Transfer zwischen BPM- Systemen verschiedener Hersteller möglich. Dadurch wird eine langfristige Bindung an einen Hersteller vermieden Deploymentalternativen Soll ein Prozessmodell nach der Modellierung ausgeführt werden und somit die modellierten Abläufe zukünftig IT- technisch unterstützen, so wird es gewöhnlich einem Server übergeben. Dieser Vorgang wird Deployment genannt. Ein Deployment kann in verschiedenen Formen realisiert werden. Grundsätzlich sollten jedoch mindestens die beiden folgenden Alternativen in einem BPM- System möglich sein: Entwicklungs- Deployment Bei der Entwicklung eines Prozessmodells muss das Verhalten zur Laufzeit

15 getestet werden. Im Normalfall wird dabei nur eines oder sehr wenige Prozessmodelle deployed. Diese Deployments haben Test- Charakter und sollten möglichst schnell und mit wenig Aufwand erfolgen. Stage- Deployment Bevor Prozesse im Produktivbetrieb eingesetzt werden, durchlaufen sie meist verschiedene Stufen (Stages), auf welchen unterschiedliche Facetten eines Prozesses getestet werden. Gängige Stufen sind dabei Teststufe, Integrationsstufe und Produktivstufe. Bei diesen Stufen ist im Normalfall nicht ein einziger Prozess Teil des Deployments, sondern eine Vielzahl von Prozessen und weiteren Ressourcen. Diese sollen automatisiert an einen bestimmten Server übergeben werden. Für diese Deployments muss ein BPM- System skriptbasierte oder weitere Möglichkeiten zur Verfügung stellen, um nicht jeden Prozess manuell und einzeln zwischen den Stages überführen zu müssen. 3.2 Ausführung Nach einem Deployment unterstützen und automatisieren Prozesse die Ausführung von Abläufen. Bei richtiger Umsetzung bringt dies einen Gewinn im Hinblick auf Ausführungsgeschwindigkeit und Verwaltungsaufwand. Eine Voraussetzung für eine richtige Umsetzung ist die Auswahl eines BPM- Systems, welches die konkreten Anforderungen erfüllt. Wichtige Kriterien für diese Auswahl sind im Folgenden aufgeführt Ausführungsformate Jeder ausführbare Prozess ist in einer Ausführungssprache formuliert. Diese Ausführungssprache kann von einem entsprechenden Server interpretiert und somit ausgeführt werden. Eine Ausführungssprache definiert also das Ausführungsformat. Die Wahl einer Ausführungssprache ist wegen der zahlreichen zu berücksichtigenden Eckpunkte eine komplexe und weitreichende Entscheidung. Eine häufig genannte Anforderung in diesem Zusammenhang ist beispielsweise, dass kein proprietäres, sondern ein standardisiertes Format gewünscht ist. Existierende Standards von Bedeutung in dieser Hinsicht sind beispielsweise BPEL 2.0 oder die direkte Ausführung der BPMN 2.0. Die Verwendung von Standards erhöht die Austauschbarkeit des verwendeten BPM- Servers. Im Gegenzug kann eine standardisierte Ausführungssprache aber nicht oder nur in starken Grenzen an spezielle Bedürfnisse eines Kunden angepasst werden Erweiterung um Ausführungselemente Die Erweiterung um Modellierungselemente wurde bereits in diskutiert. Aber auch in der Ausführung kann eine Erweiterung um verschiedene Ausführungselemente

16 gewünscht sein. Beispielsweise kann eine Semantik im Kontrollfluss erwünscht sein, welche unter Verwendung bestehender Ausführungselemente nur schwer oder kaum umsetzbar ist. Als einfaches Beispiel kann die Anforderung dienen, dass eine Menge von Elementen in einer beliebigen Reihenfolge, aber niemals zwei Elemente gleichzeitig ausgeführt werden sollen. Diese Semantik ist zwar mit BPEL 2.0 als Kaskade von XOR- Elementen umsetzbar, aber diese Umsetzung ist komplex und kaum performant. Ein eigenes Ausführungselement wäre in diesem wie in weiteren Fällen eine vorteilhafte Lösung. Eine ausführliche Diskussion dieses Beispiels und von Erweiterungen in Modellierungs- und Ausführungssprachen im Allgemeinen findet sich in [14] Skalierung In realen Anwendungsfällen werden nicht selten tausende oder Millionen von Prozessinstanzen gleichzeitig ausgeführt. Diese Last muss vom BPM- System und der integrierten IT- Umgebung bewältigt werden. Gleichzeitig muss eine angemessene Performance sichergestellt werden. Dieser Herausforderung kann durch Mechanismen wie beispielsweise Clustering begegnet werden, welche die Last auf mehrere Server verteilen und so einen Lastausgleich schaffen. Solche Mechanismen können aber nur schwer nachgerüstet werden, sondern müssen in einem BPM- System verankert sein. Eine Abschätzung der Last sollte daher vor der Auswahl eines BPM- Systems vorgenommen werden und in die Entscheidung einfließen Persistenz Prozesse in oder nach Ausführung dienen in verschiedener Hinsicht als Quelle für Informationen. Viele BPM- Systeme ermöglichen ein Monitoring und bieten somit detaillierte Erkenntnisse hinsichtlich des augenblicklichen Zustands eines Prozesses und vergangener Aktionen an. Weiterhin dienen Prozesse häufig als Informationsquelle für Reports und weitere automatisierte Auswertungen. Sowohl im Sinne der Ausfallsicherheit als auch für die längerfristige Verwendung als Informationsquelle sind Daten von und über Prozessen in Ausführung daher persistent beispielsweise in einer Datenbank zu speichern. Entsprechende Mechanismen müssen in einem BPM-.System vorgesehen werden Versionierung Ausführung Ein wesentliches Element des BPM ist die ständige Verbesserung und Anpassung von Prozessen an neue Gegebenheiten. Dies spiegelt sich in der Ausführung durch konsequentes Deployment neuer Versionen eines ausführbaren Prozesses wider. Ein BPM- System muss daher mindestens eine Strategie anbieten, nach welcher das

17 Einbringen neuer Versionen behandelt wird. Ein Beispiel für eine solche Strategie ist das weitere Ausführen laufender Prozesse in der alten Version und das Instanziieren neuer Prozesse in der neuen Version. Alternativ können beispielsweise auch laufende Prozesse während der Ausführung in eine neue Version migriert werden. Je nach Anwendungsumfeld werden dabei unterschiedliche Anforderungen an die Verfügbarkeit von Strategien gestellt. Bei relativ kurz laufenden Prozessen ist beispielsweise in vielen Fällen eine Fortsetzung laufender Prozesse in der alten Version problemlos möglich. Gleichzeitig ist diese Alternative technisch unproblematisch und mit wenig Aufwand durchführbar. Laufen Prozesse aber beispielsweise mehrere Monate oder Jahre, so kann eine Migration alternativlos sein. Vor der Auswahl eines BPM- Systems sollten daher die angebotenen Alternativen in Bezug auf die Tauglichkeit im eigenen Umfeld abgewogen werden Web Services Integration Prozesse werden meist auf einem Server in einem Netzwerk ausgeführt und kommunizieren mit verschiedenen weiteren Systemen oder Endgeräten des Nutzers wie Rechnern oder Smartphones. Als Kommunikationstechnik hat sich dabei die Nutzung von Web Services etabliert, woraufhin beispielsweise auch die Standards BPEL 2.0 und BPMN 2.0 ausgelegt sind. Ein BPM- System sollte daher den Aufruf und von Web Services ebenso wie den Empfang von Web Service- Nachrichten unterstützen, um eine Automatisierung von Abläufen in einer IT- Umgebung zu ermöglichen. Dies verhindert, dass eine IT- Umgebung nur im Hinblick auf ein BPM- System aufgebaut wird. Unabhängig vom konkreten BPM- System bleiben Web Services wiederverwendbar und der Austausch eines BPM- Systems bleibt somit beherrschbar Integration einer Programmiersprache Größere logische oder mehrfach benötigte Komponenten eines Prozesses werden im Sinne der Wiederverwendung meist als Web Service umgesetzt und im Laufe eines Prozesses aufgerufen. Allerdings gibt es immer wieder kleine logische Komponenten, deren Verwendung aufgrund einer sehr speziellen Aufgabe lokal stark auf einen einzigen Prozessteil begrenzt ist. Für diese kleinen Komponenten ist die Erstellung eines Web Service vom Aufwand her nicht gerechtfertigt. Solche Komponenten lassen sich beispielsweise durch die Integration einer Programmiersprache wie Java, C++ oder C# in ein BPM- System schnell und einfach erstellen. Diese Integration sollte dabei sowohl die Erstellung der logischen Komponente als auch eine einfache und schnelle Möglichkeit zur Integration in ein

18 Prozessmodell umfassen. Weiterhin muss ein Mechanismus definiert sein, der eine solche Komponente zur Laufzeit eines Prozesses aufruft und ausführt Einbinden weiterer Konnektoren BPM- Projekte sind häufig auch Integrationsprojekte, da in eine Prozessautomatisierung weitere Systeme einbezogen werden. Diese Systeme müssen von einem BPM- System über technische Schnittstellen aufgerufen werden können. Eine Lösung ist eine manuelle Implementierung und Nutzung von Web Service- Schnittstellen für die entsprechenden Systeme. Dieses Vorgehen ist jedoch zeit- und kostenaufwendig. BPM- Systeme integrieren als Alternative daher oft eine Vielzahl von Konnektoren für gängige Systeme, welche eine vorentwickelte Schnittstelle für die Kommunikation anbieten. Beispielhaft können Konnektoren zu SAP oder Oracle- Systemen genannt werden. Die Verfügbarkeit solcher Konnektoren reduziert den Entwicklungsaufwand für die Integration von Prozessen in eine IT- Umgebung deutlich. Weiterhin ist ein BPM- Anbieter für die Weiterentwicklung und Wartung eines Konnektors verantwortlich, was dauerhaft gebundene Ressourcen auf Seiten des Kunden einsparen kann. Vor der Wahl eines BPM- Systems sollte also eine Liste der zu integrierenden Systeme erstellt und die Verfügbarkeit von Konnektoren für ein System geprüft werden Nutzeroberfläche für Prozessbeteiligte Nur in einer begrenzten Zahl von BPM- Projekten wird eine vollständige Automatisierung von Prozessen erreicht oder auch nur angestrebt. In den meisten Fällen sollen menschliche Nutzer in die Ausführung eines Prozesses einbezogen werden und Entscheidungen treffen, Informationen eingeben oder mit Informationen versorgt werden. Zu diesem Zweck wird eine Nutzeroberfläche benötigt, welche Interaktionen der Prozessbeteiligten mit dem BPM- System erlaubt. Die meisten BPM- Systeme liefern eine vorgefertigte Benutzeroberfläche. Diese Benutzeroberflächen unterscheiden sich jedoch stark hinsichtlich ihres Umfangs, der Benutzerfreundlichkeit und verfügbarer Features. Auf Kundenseite gibt es in beinahe jedem Anwendungsfall spezielle Anforderungen und bei einem geplanten Einsatz eines BPM- Systems muss geprüft werden, ob die mitgelieferte Benutzeroberfläche entsprechend angepasst werden kann. Ist dies nicht der Fall oder soll eine bereits vorhandene Benutzeroberfläche verwendet werden, so muss die Verfügbarkeit von Schnittstellen des BPM- Systems zur Anbindung einer externen Nutzeroberfläche geprüft werden. Aufgrund der stark unterschiedlichen Antwortzeiten von IT- Systemen und menschlichen Benutzern ist dabei eine triviale Web Service- Kommunikation nicht ausreichend. Der Standard BPEL 2.0 wurde

19 beispielsweise um die Standards BPEL4People und WS- HumanTask erweitert, um diesen Umständen Rechnung zu tragen Administratoroberfläche Auf einem BPM- Server laufen potentiell einige Millionen Prozessinstanzen täglich gleichzeitig. Um eine solche Menge an Vorgängen zu verwalten und einen Server entsprechend zu konfigurieren, wird eine Administrationskonsole benötigt. Eine Administrationskonsole sollte dabei mindestens in den drei folgenden Punkten Unterstützung bieten: Server- Ressourcen Ein Server sollte hinsichtlich der Ressourcen- Auslastung überwacht und entsprechend konfigurierbar sein. Falls beispielsweise dauerhaft eine zu hohe Last erreicht wird, dann muss über den Aufbau eines Clusters oder den Einsatz anderer Mechanismen nachgedacht werden. Diese und weitere Einstellungen zur Zuweisung von Ressourcen sollte eine Administrationskonsole anbieten. Instanz- Monitoring Erfahrungsgemäß laufen die meisten Prozesse nach einer Einführungsphase problemlos ab und unterstützen die Prozessbeteiligten ohne weitergehenden Administrationsaufwand. Einige wenige Prozesse werden zumindest von Benutzerseite allerdings regelmäßig als fehlerhaft empfunden, weil sie sich anders verhalten als erwartet. Ein Prozess wird jedoch exakt seiner Implementierung gemäß ausgeführt. Daher ist entweder die Implementierung fehlerhaft oder Benutzer haben Eingaben getätigt, deren Auswirkungen sie nicht abgesehen haben. In beiden Fällen ist es sehr nützlich, wenn der bisherige Ablauf einer Prozessinstanz mit allen Eingaben nachvollzogen werden kann. Damit lässt sich am konkreten Fall der Fehler finden und in Form einer neuen Prozessversion oder einer kleinen Nutzerschulung beheben. Prozessinstanz- Eingriff Prozessbeteiligte machen Eingaben und beeinflussen damit den Ablauf einer Prozessinstanz. Dabei ist davon auszugehen, dass Menschen selbst Spezialisten von Zeit zu Zeit Fehler machen und eine falsche Eingabe tätigen oder eine falsche Entscheidung treffen. Insbesondere bei lang laufenden Prozessen ist es sehr unbefriedigend, wenn nach einer Falscheingabe Entscheidungen nicht mehr rückgängig gemacht werden können. In ausgewählten Fällen sollte es daher dem Administrator möglich sein, in den Ablauf eines Prozesses direkt einzugreifen und beispielsweise Daten zu ändern oder einen Prozess auf einen früheren Ausführungszustand zurückzusetzen. Ist dies nicht vorgesehen und in einem Modell keine Möglichkeit eines Rücksprungs eingebaut, so besteht die einzige Alternative in einem Neustart einer Instanz und der manuellen Neuausführung. Dies ist weder hinsichtlich des Aufwands noch der Nutzerzufriedenheit eine gute Lösung.

20 Schnittstellen Ein BPM- System läuft nur in Ausnahmefällen ohne Kommunikation mit weiteren Systemen. Um andere Systeme aufrufen zu können, werden Konnektoren eingesetzt. Allerdings sollte auch das BPM- System verschiedene Schnittstellen anbieten, um von anderen Systemen aufgerufen zu werden. Beispiele dafür sind die Schnittstellen zur Interaktion mit einer Benutzeroberfläche oder die Schnittstellen zur Instanziierung und zum Start eines Prozesses durch ein externes System. 4 Vergleich der BPM- Systeme Nachdem in Kapitel 3 die Vergleichskriterien eingeführt und diskutiert wurden, sollen diese nun auf die in Kapitel 2 vorgestellten BPM- Systeme angewandt werden. Dies soll den Vergleich der Systeme erleichtern und eine Einschätzung hinsichtlich der Tauglichkeit eines jeden Systems in einem konkreten Anwendungsfall erleichtern. 4.1 Einzeldiskussion In diesem Abschnitt werden die BPM- Systeme einzeln im Hinblick auf alle Kriterien diskutiert. Dies ermöglicht eine größere Informationsfülle, als sie in einer Vergleichstabelle gegeben werden kann. Somit kann dem Funktionsumfang jedes einzelnen BPM- Systems differenzierter Rechnung getragen werden ActiveVOS 8.0 Bei der folgenden Diskussion von ActiveVOS 8.0 werden dabei nur bestehende Komponenten betrachtet. Zu entwickelnde und über Schnittstellen integrierbare Erweiterungen werden nicht berücksichtigt. Modellierungssprache Als Modellierungssprache wird eine angepasste Version der Prozessdiagramme aus BPMN 2.0 verwendet. Diese angepasste Version trägt dem Mismatch zwischen der Modellierungssprache BPMN 2.0 und der Ausführungssprache BPEL 2.0 Rechnung, indem Modellierungselemente ohne Entsprechung in der Ausführungssprache nicht angeboten werden. Choreographiediagramme, Kollaborationsdiagramme und Konversationsdiagramme der BPMN 2.0 werden in der Modellierung generell nicht unterstützt. Einbinden weiterer Modellierungselemente