BPMN 2.0: Prozessautomatisierung mit jBPM und Activiti

IT-Systeme spielen eine große Rolle bei der Umsetzung optimierter Prozesse. jBPM und Activiti sind zwei weit verbreitete Open Source-Plattformen für die Prozessautomatisierung. Zahlreiche Organisationen haben bereits heute eine Kombination aus Signavio für die fachliche Prozessgestaltung und jBPM oder Activiti auf der Automatisierungsseite produktiv im Einsatz. Dieser Artikel beleuchtet das Zusammenspiel der Technologien und Ansätze.

Prozessoptimierung dank IT

Die Umsetzung optimierter Prozesse hat häufig zwei Dimensionen: Die organisatorisch/fachliche Umsetzung und die IT-Umsetzung.

Organisatorisch/fachliche Umsetzung: Hier werden veränderte Prozessverantwortlichkeiten implementiert, Aufgaben neu geschnitten oder in eine neue Reihenfolge gebracht, Prozessschritte über die Organisation neu verteilt und Kennzahlensystem und Reporting neu strukturiert. Es dreht sich alles um die organisatorische Implementierung von Prozessen: Der Prozess verändert sich, indem die involvierten Personen ihr Verhalten anpassen.

IT-Umsetzung: IT-Systeme bieten zahlreiche Möglichkeiten, Prozesse effektiver und effizienter zu gestalten:

  • Vermeidung von Mehrfacheingaben / Medienbrüchen
  • Schnellere Auffindbarkeit von Informationen
  • Hilfen beim Ausfüllen von Formularen
  • Erzwingen von Prozessschritten oder Reihenfolgen von Schritten
  • Örtliche und zeitliche Verteilung von Prozessen
  • Vollständige Automatisierung einzelner Schritte, die bisher manuell gemacht wurden
  • Automatische Aktualisierung mehrerer Systeme
  • Nachvollziehbarkeit (Auditierfähigkeit)
  • Automatisches Reporting / KPI-Dashboards

Für die IT-Unterstützung stehen häufig drei Optionen zur Verfügung:

  • Einsatz einer Standardsoftware (z.B. ERP, CRM) mit Customizing
  • Klassische Individualentwicklung (z.B. Java, ABAP, Python)
  • Prozessautomatisierung über eine Prozess-Engine

 

Prozess-Engines

Prozess-Engines sind Softwaresysteme, die statt klassischem Programmcode (z.B. Java, ABAP, Python) ein Prozessmodell als zentrales Implementierungsartefakt ansehen. Statt Klassen und Objekten stehen hier Prozessmodelle und Prozessinstanzen im Vordergrund. Dies hat den Vorteil, dass das Programmiermodell die fachlichen Anforderungen oft sehr viel näher abbildet als klassischer Programmcode. Prozess-Engines werden dabei übrigens auch “Workflow-Engines” oder “BPM-Suites” genannt.

Typische Vorteile von Prozess-Engines gegenüber klassischer Softwareentwicklung sind:

  • Kürzere Implementierungszyklen
  • Einfachere Anpassbarkeit des Prozesses
  • Prozessmonitoring und -reporting als Standardfunktion
  • Prozessstatusüberwachung entlang von Prozessen

 

Fachliche Modellierung vs. technische Modellierung

Eine häufig gestellte Frage ist: In meinem Fachbereich habe ich meine Prozesse modelliert. Was muss ich jetzt tun, um den Prozess in einer Engine auszuführen? Kann das der Fachbereich selbst machen oder muss die IT involviert werden?

Wenn Sie BPMN 2.0 für die fachliche Modellierung genutzt haben, dann haben Sie bereits einen wichtigen Schritt getan. Denn dies ist die Sprache der Wahl auch für die Prozessautomatisierung.

Das fachliche Modell begnügt sich häufig damit zu beschreiben, welche Arbeitsschritte zu erledigen sind, wo Entscheidungspunkte liegen, wo Schritte parallelisiert werden können, wo Informationen anfallen, wo mit dem Kunden kommuniziert wird und wer für die Durchführung von Aktivitäten verantwortlich ist. Wichtig ist auch, wie lange Schritte dauern oder was im Falle von Eskalationen zu tun ist. Der Fokus liegt hier auf den Themen, die später für die organisationale Umsetzung des veränderten Prozesses wichtig ist.

Für die IT-Implementierung muss man nun noch einen Schritt weiter gehen: Es muss spezifiziert werden, welche Daten im Prozess anfallen (Variablen / Datenobjekte), wie sich diese auf Inputs/Outputs von Schritten beziehen (Datenmapping), welche IT-Funktionen oder Formulare in den Schritten verwendet werden, welche Benutzerverwaltung verwendet wird und wie genau eine Entscheidung getroffen werden muss (Verzweigungsbedingung). Hinzu kommen viele weitere Themen wie Zugriffsrechte, Sicherheit oder auch transaktionale Eigenschaften.

Man könnte jetzt vermuten, dass man einen fachlichen Prozess einfach nur mit technischen Informationen annotieren müsste, um ihn ausführbar zu machen. Dies funktioniert allerdings nur in sehr einfachen Szenarien, z.B. der Bearbeitung eines Urlaubsantrages oder der Einstellung eines neuen Mitarbeiters (HR-Onboarding).

Gerade bei der Automatisierung von Kernprozessen trifft man aber schnell auf zusätzliche Herausforderungen. Z.B. stellt sich heraus, dass gewisse Teile eines Prozesses in Batch-Verarbeitung stattfinden oder dass ein viel ausgefeilteres Exception-Handling nötig ist. Auch ergeben sich ganz grundlegende Fragen wie: Welcher Teil des Prozesses soll überhaupt in der Prozess-Engine ausgeführt werden und welcher Teil läuft in anderen Systemen oder wird sogar manuell durchgeführt?

Das BPMN-Framework von unserem Certified Partner camunda, das im “Praxishandbuch BPMN” präsentiert wird, zeigt einen pragmatischen Weg, wie man mit den Modellen auf den verschiedenen Ebenen am besten umgehen kann.

Kann ein Prozess vom Fachbereich also selbst implementiert werden? In sehr einfachen Fällen theoretisch ja. In den allermeisten Fällen ist eine Einbindung der IT-Abteilung in die Umsetzung allerdings ratsam bzw. sogar zwingend erforderlich.

 

Auswahlkriterien für Engines

Es stehen verschiedenste Prozess-Engines für die Prozessautomatisierung zur Auswahl. Je nach Anwendungsfall haben unterschiedliche Kriterien unterschiedlich hohe Bedeutung:

  • Modellierungssprache: Wird BPMN 2.0 oder eine proprietäre Sprache verwendet? Wie gut ist die Anbindung an die fachliche Modellierung?
  • Schnittstellen zu bestehenden Systemen: Wie einfach lassen sich existierende Systeme anbinden? Gibt es vorgefertigte Adapter?
  • Formulare: Wie einfach lassen sich Formulare umsetzen? Wie können Formularlogik, Validierungen, etc. hinterlegt werden?
  • Offenheit: Wie einfach lassen sich Erweiterungen in dem System unterbringen?
  • Implementierungstechnologie: Welches Know-How benötigt man, um Prozesse zu implementieren (z.B. XSLT, Java, proprietäre Technologie)? Wer kann unterstützende Dienstleistungen anbieten?
  • Entwicklungsumgebung: Kann die gewohnte Softwareentwicklungsumgebung (IDE) genutzt werden? Gibt es die Möglichkeit, Prozesse zu “debuggen”? Wie sieht es mit Testinfrastrukturen aus?
  • Performance: Wie gut skaliert das System bei tausenden oder Millionen von Prozessinstanzen?

Hinweis: Bei der Prozessautomatisierung über eine Engine handelt es sich in den allermeisten Fällen genauso um ein Softwareentwicklungsprojekt wie auch bei der Individualentwicklung oder bei umfangreichem Customizing. Etablierte Ansätze wie agile / iterative Methoden sind hier genauso relevant wie bei anderen Softwareprojekten auch.

 

Zero-Coding vs. Less-Code

 

In den letzten Jahren rückte vor allem das Thema “Zero-Coding” vs. “Less-Code” in den Fokus. “Zero-Coding” bedeutet dabei, dass die Entwicklungsumgebung keine Programmierung im klassischen Sinn vorsieht, sondern das grafische Prozessmodell über Konfigurationsdialoge zu einem ausführbaren technischen Modell verfeinert werden kann. Dadurch dass viele typische Szenarien in der Plattform bereits vorgedacht wurden, stehen häufig zahlreiche Bausteine (“Services”, Adapter, Transformatoren, etc.) zur Verfügung, die mit überschaubarem Aufwand kombiniert werden können. Das Zusammenfügen erfordert ein Datenmapping, bei dem Outputs eines Bausteins und Inputs eines anderen Bausteins entsprechend übereinander gelegt werden.

Spannend wird es natürlich, wenn Funktionalität erfordert wird, die noch nicht als Baustein zur Verfügung steht. Hier muss dann häufig der Hersteller der Engine ran, um dies entsprechend per Customizing zur Verfügung zu stellen.

Da die Anzahl der realisierbaren Szenarien auch extrem groß ist, ist die Konfiguration im Rahmen des “Zero-Coding” manchmal sogar wesentlich komplexer als eine Implementierung über klassische Softwareentwicklung.

Daher hat sich das “Less-Code”-Prinzip in der Prozessautomatisierung etabliert. Die Idee dabei ist, dass grundsätzlich die gleiche Entwicklungsumgebung und Technologie verwendet wird wie bei klassischer Softwareentwicklung. Beispielsweise können hier Eclipse, NetBeans oder IntelliJ als IDE, Git oder svn als Codeverwaltung und Java als Sprache zum Einsatz kommen.

“Less-Code” heißt, dass die Prozess-Engine als Komponente in die Entwicklung eingebunden wird. So viel wie möglich wird über die Engine abgewickelt. Datenmappings, Implementierung zusätzlicher Bausteine, etc. geschieht aber wie bei der klassischen Softwareentwicklung. Damit kombiniert man die Vorteile aus beiden Bereichen.

 

jBPM und Activiti

jBPM und Activiti sind die beiden bekanntesten Prozess-Engines aus der Kategorie “Less-Code”. Bei beiden handelt es sich um Open Source-Projekte und beide nutzen Java als grundlegende Technologie. jBPM wird von Red Hat voran getrieben. Activiti wurde von den ehemaligen jBPM-Chefentwicklern ins Leben gerufen und existiert unter dem Dach von Alfresco.

Sowohl jBPM als auch Activiti wurden als “Embeddable Engine” konzipiert. D.h. die Komponenten fügen sich nahtlos in eine bestehende Java-Ausführungsumgebung ein. Dies steht im Gegensatz zu den meisten anderen Prozess-Engines, die “standalone” betrieben werden und dann über Systemschnittstellen, z.B. Web Services, mit anderen Systemen verbunden werden. Vorteile der “Embeddable Engine” liegen damit zum einen in der einheitlichen Implementierungsumgebung und zum anderen im einfacheren Systembetrieb.

jBPM setzte in früheren Versionen auf ein eigenes Format (jPDL). Dieses steht auch als Export bei Signavio zur Verfügung. Noch reibungsloser klappt der Austausch, seitdem jBPM durchgängig auf BPMN 2.0 XML setzt. Die aktuelle Version ist jBPM 5, für produktive Projekte wird aber weiterhin häufig die Version jBPM 3 genutzt.

Activiti hat von Anfang an auf BPMN 2.0 XML gesetzt. Allerdings verwendet Activiti einige ausführungsrelevante Attribute, die in einem eigenen XML-Namespace vorliegen. So sieht die Verwendung von Formularen oder Java-Funktionen als Implementierung für Tasks im XML sehr schlank und elegant aus.

Beiden Engines ist gemein, dass sie zwar die wesentlichen BPMN-Sprachkonstrukte unterstützen, aber nicht den kompletten Sprachumfang umgesetzt haben.

Activiti kann man als Community-Edition kostenlos herunter laden. Interessiert man sich für einen produktiven Einsatz, so bietet sich die camunda fox Engine an. Dieses Produkt ist eine Stabilisierung der Activiti-Code-Basis und bietet noch einige nützliche Erweiterungen (siehe auch “BPM-Roundtrip-Engineering”), die Projekte enorm beschleunigen können bzw. den Einsatz noch robuster machen. Am wichtigsten ist natürlich, dass für die camunda fox Engine auch professioneller Support zur Verfügung steht - ein Muss für die Automatisierung von Kernprozessen.

Die Performance von fox kann sich sehen lassen: Mehrere hundert tausend Prozessinstanzen pro Stunde können das System nicht schocken. Ein Cluster-Betrieb und Multi-Tenancy werden auch nativ unterstsützt.

Während jBPM bereits seit einigen Jahren bei vielen Unternehmen produktiv im Einsatz ist, erfreut sich Activiti eines enormen Momentums auf Community-Seite und eines rasanten Wachstums der Anzahl produktiver Installationen.

In Europa ist momentan ein starker Trend hin zu Activiti zu beobachten. Während vor zwei Jahren häufig jBPM 3 und intalio die erste Wahl für Open Source-Engines waren, sehen wir hier sehr viele Anfragen und neue Projekte auf Basis von Activiti. In den USA scheint jBPM weiterhin sehr stark verbreitet zu sein - auch bei neuen Projekten. Dies ist wahrscheinlich auch damit zu erklären, dass die Activiti-Hauptentwickler in Europa ansässig sind, während einige Protagonisten von jBPM in den USA arbeiten.

 

Modellierung: Was ist das geeignete Tool?

Für ein erfolgreiches BPM-Implementierungsprojekt müssen die Fachabteilungen und die IT Hand in Hand arbeiten. Weiter oben haben wir bereits beleuchtet, dass womöglich sogar mehrere BPMN-Modelle auf den verschiedenen Ebenen entstehen.

Es stellt sich natürlich die Frage nach dem geeigneten Tooling für das Projekt.

Manche “Zero-Coding”-Anbieter propagieren, man könnte die Entwicklungsumgebung auch gleichzeitig als Umgebung für die fachliche Prozessmodellierung nutzen. Durch den Fokus auf die Automatisierung kommen hier aber häufig die fachlichen Anforderungen an das Tooling zu kurz.

Typische Nachteile von implementierungs-zentrischen Modellierungsumgebungen sind:

  • Die Entwicklungsumgebung ist zu komplex für die Fachanwender
  • Es wird eine aufwändige Softwareinstallation benötigt
  • Die Modellierung ist auf einzelne Prozesse ausgelegt - eine Verknüpfung verschiedener Modelle / Prozesse ist nicht möglich
  • Diskussions- / Kollaborationsfunktionen sind nicht vorhanden
  • Die Bedienbarkeit wurde eher auf die technische Implementierung optimiert und nicht auf die einfache Erstellung von Diagrammen
  • Attributierungen / hinterlegbare Detailinformationen orientieren sich an der Implementierung - nicht aber an den organisationalen Aspekten

 

Zwei Modellierungswerkzeuge und BPM-Roundtrip-Engineering

Es ist dringend zu empfehlen, ein auf die Fachanwender zugeschnittenes Modellierungswerkzeug wie Signavio zu verwenden - auch in einem Prozessautomatisierungsprojekt. Denn ein Prozessautomatisierungsprojekt ist kein reines IT-Projekt: Auch hier geht es vor allem auch um die Abstimmung fachlicher Prozesse.

Auf der anderen Seite bietet Signavio nicht die Entwicklungsunterstützung wie z.B. der Activiti Designer. Dieser ist ja direkt integriert in die IDE und hilft bei der korrekten Anbindung von Java-Komponenten.

Insofern ist es ein typischer Ansatz, zwei Werkzeuge zu verwenden: Signavio für die fachliche Abstimmung und Dokumentation der Prozesse und ein entwicklungszentrisches Werkzeug für die Ausimplementierung des Prozesses.

Bei Activiti steht beispielsweise der Activiti Designer als eclipse-Plugin zur Verfügung. Dieser Editor bietet gute Unterstützung z.B. in Richtung Code-Completion. Dadurch dass sowohl beim Activiti Designer als auch bei Signavio BPMN 2.0 als Modellierungssprache verwendet wird, ist der Grundstein für einen reibungslosen Austausch zwischen Fach- und IT-Welt gelegt.

Für einen reibungslosen Austausch zwischen den beiden Tools gibt es ausgereifte Synchronisierungskomponenten.

Im Rahmen des camunda fox-Produktes (die professionelle Variante von Activiti inkl. Code-Stabilisierung, Support und zusätzlichen Komponenten) steht ein solcher Roundtrip-Mechanismus im Zentrum. Im Kern werden zwar einfach BPMN 2.0-Dateien hin und her synchronisiert und als entsprechende neue Version vermerkt. Fox geht aber noch einen Schritt weiter: Das System identifiziert die ausführungsrelevanten Teile eines BPMN-Prozessmodells und blendet die anderen Teile in der Entwicklungsumgebung direkt aus. So bleibt der XML-Code immer schön übersichtlich.

Der Signavio Process Editor wurde speziell auf den Roundtrip optimiert:

  • Unterstützung aller ausführungsrelevanten Attribute für jBPM und Activiti (auch solcher, die über den BPMN 2.0-Standard hinaus gehen)
  • “Durchschleifen” von ausführungsrelevanten Informationen, die in einem eigenen Engine-spezifischen XML-Namespace definiert wurden
  • Erzeugung eines “Developer friendly”-XML, das für das Lesen und Editieren in einem Texteditor optimiert wurde
  • Grafischer Vergleich verschiedener Prozessversionen
  • Direkte Nutzung der Mashup API für das Prozessmonitoring

...und wie steht es mit Signavio und anderen Engines?

Signavio unterstützt den BPMN 2.0 Standard vollständig (inkl. XML-Import, -Export und Synchronisation). BPMN 2.0 ist das internationale Standard-Austauschformat für Prozessmodelle. Zahlreiche Unternehmen stehen hinter BPMN, z.B. SAP, IBM, Oracle.

Signavio wurde als OEM-Komponente in zahlreiche Workflow-Produkten integriert. Hier fungiert der Signavio Process Editor als “Zero-Coding”-Umgebung. Wenn verschiedene Modelle auf Fach- und IT-Ebene entstehen, werden sie entsprechend im gleichen Tool verwaltet.

Für zahlreiche weitere Produkte haben wir Referenzkunden, die erfolgreich einen kombinierten Einsatz mit Signavio betreiben. Wir pflegen enge Beziehungen zu zahlreichen Engine-Herstellern um eine reibungslose Integration zu gewährleisten. Eine kürzliche abgeschlossene Studie zeigt beispielsweise den Austausch zwischen Signavio und SAP Netweaver BPM.

Signavio ist die optimale Plattform für die fachliche Prozessgestaltung. Das Tool ist der ideale Ausgangspunkt für die Automatisierung des Prozesses - egal mit welcher Engine.

Sprechen Sie uns an, wenn Sie sich für ein bestimmtes Szenario interessieren.

 

Fazit

Die camunda fox Engine (das “professionalisierte Activiti”) ist eine mächtige Plattform für die Automatisierung von Prozessen.

Dank umfangreicher Integration ist Signavio erste Wahl für alle jBPM- und Activiti- / camunda fox-Projekte. Auch bei Automatisierungsprojekten, die nicht auf jBPM oder Activiti setzen, unterstützt Signavio die fachliche Prozessmodellierung optimal.

Signavio ist der optimale Ausgangspunkt für alle Automatisierungsprojekte, egal mit welcher Engine. Mehr zu jBPM: http://www.jboss.org/jbpm Mehr zu Activiti: http://activiti.org/ Mehr zu camunda fox:

uniE506 Zur Nachrichtenübersicht