Seite 2: Regeln 5 bis 7

Inhaltsverzeichnis

Ausflug in die Mythologie

Vier Mythen von BPM sorgen schnell in vielen Unternehmen für Probleme und Unklarheiten:

• Der Fachbereich wird ausführbare Prozessmodelle erzeugen.
• Der Fachbereich kann ausführbare Prozessmodelle erzeugen.
• Der Fachbereich will ausführbare Prozessmodelle erzeugen.
• Die Entwickler wollen, dass der Fachbereich ausführbare Prozessmodelle erzeugt.

Auch in Zukunft wird es sowohl einen Fachbereich als auch Entwickler geben. Beide Domänen haben ein unterschiedliches Verständnis von Geschäftsprozessen. Der Fachbereich wird wohl niemals komplexe Geschäftsprozesse modellieren können. Auch Tools können diese Aufgabe nicht lösen. Erschwerend kommt hinzu, dass beide Seiten meist unterschiedlich kommunizieren und Äußerungen dadurch oft missverstanden werden. Daher kommt es umso mehr darauf an, dass Fachbereich und IT eng zusammenarbeiten – nur dann lässt sich BPM erfolgreich umsetzen.

Da der Fachbereich über das Know-how zu Kreditanträgen verfügt, sollte er, sofern möglich, die Geschäftsprozesse modellieren und die Entwickler nur die technischen Details hinzufügen. Allerdings können und wollen viele Fachbereiche nicht in einer solchen Prozesssicht denken. IT-Experten hingegen sind seit ihrer Ausbildung darin geschult, können sich dafür aber häufig weniger für die eigentliche fachliche Komplexität begeistern. Daher ist es oftmals sinnvoll – und auf keinen Fall schädlich – wenn IT-Experten die gesamten Prozesse modellieren. Wichtig ist allerdings, dass der Fachbereich immer über Meetings, Workshops oder Reviews eingebunden ist. Schließlich soll die IT Mehrwert schaffen, indem sie die Probleme des Fachbereichs löst.

Regel 5: Um BPM erfolgreich zu gestalten, müssen IT und Fachbereich eng zusammenarbeiten.

Reichlich Standards

Für BPM existiert eine große Anzahl an Standards, zum Beispiel BPMN, XPDL, BPEL, jPDL, WF-XML und ARIS EPC. Sie spielen eine wesentliche Rolle, um im BPM-Umfeld zukunftssicher und herstellerunabhängig agieren zu können. Dank ihnen können die verschiedenen Rollen sogar Tools unterschiedlicher Hersteller einsetzen.

Der wichtigste Standard ist BPMN (Business Process Model and Notation). Er ist seit Januar 2011 in der Version 2.0 verfügbar. Im Vergleich zu BPMN 1.0 erhielt die aktuelle Version einige wichtige neue Features. Durch das standardisierte XML-Format zur Beschreibung von Geschäftsprozessen lässt sich BPMN beispielsweise nicht mehr nur für die Modellierung von Workflows verwenden. Dank ausreichender Einschränkungen kann man nun auch die Ausführung der Geschäftsprozesse eindeutig beschreiben. Zudem führte BPMN 2.0 standardisierte "Extension Points" ein, wodurch jeder Hersteller eigene – nicht im Standard festgelegte Funktionen – ergänzen kann. Beispielsweise bietet das quelloffene BPM-Framework Activiti einen Java-Service-Task an, mit dem sich auf Java-Klassen deutlich einfacher als mit dem im BPMN-Standard enthaltenen Webservice-Task zugreifen lässt.

WSBPEL (Web Services Business Process Execution Language, kurz: BPEL) ist ein weiterer wichtiger BPM-Standard. Allerdings kann man ihn nur für das Ausführen von SOAP-Webservices verwenden. Da BPMN 2.0 implizit das Ausführen von Geschäftsprozessen berücksichtigt, ist es nicht mehr unbedingt notwendig, dass neue BPM-Engines den relativ komplexen BPEL-Standard noch unterstützen. Dennoch muss eine BPMN-2.0-Implementierung mit BPEL zusammenarbeiten können, um vollständig standardkonform zu sein. Weitere Details zur Beziehung zwischen BPMN 2.0 und BPEL sind in einem interessanten Interview auf InfoQ mit mehreren BPM-Experten erläutert.

Der Kreditantrag wurde mit BPMN 2.0 entworfen. Der Standard ist sowohl für den Fachbereich als auch die IT geeignet und lässt sich zudem für die Modellierung ebenso wie für die Ausführung von Geschäftsprozessen verwenden. Viele andere BPM-Standards dagegen sind entweder veraltet oder viel zu komplex. Beispielsweise würde das noch verbreitete BPEL viele Restriktionen hinzufügen und die Komplexität deutlich erhöhen.

Regel 6: Um BPM erfolgreich zu gestalten, sollte der BPMN 2.0 verwendet werden.

Im Dschungel der Helfer

Da zahlreiche BPM-Produkte auf dem Markt verfügbar sind, ist es schwer, den Überblick zu behalten respektive zu entscheiden, welches das jeweils passende Tool für das eigene Unternehmen oder Projekt ist. Das übliche Prozedere bei der Produktauswahl umfasst insbesondere das Erstellen einer Liste mit Vergleichskriterien und die anschließende Evaluierung der Produkte, beispielsweise bezüglich der unterstützten Techniken, Standards, GUI-Designer sowie der Community, Dokumentation des kommerziellen Supports.

Das Vorgehen funktioniert für viele Produktvergleiche. Im BPM-Umfeld allerdings sollte eine Frage unbedingt am Anfang des Projekts beantwortet sein: Soll ein entwicklerzentrisches oder ein designzentrisches Produkt zum Einsatz kommen? Entwicklerzentrische Produkte wie Activiti oder JBoss jBPM sind direkt in Anwendungen integrierbar und werden in die gewohnte Entwicklungsumgebung eingebunden. Es sind Frameworks, mit denen man Quellcode und die zugehörigen Unit-Tests schreibt. Ein GUI-Designer ist oftmals nicht integriert. Üblicherweise sind entwicklerzentrische Produkte einfach zu benutzen und quelloffen verfügbar. Da sie eine API für bekannte Programmiersprachen wie Java und Webservice-Schnittstellen (REST/SOAP) bieten, sind sie nach wenigen Minuten in das eigene Projekt integriert und lauffähig. Es gibt aber auch bei ihnen eine Kehrseite der Medaille: Oftmals sind beispielsweise noch nicht alle Funktionen stabil lauffähig und die Dokumentation ist nicht detailliert, oder es stehen nur rudimentäre Weboberflächen für Modellierung und Monitoring zur Verfügung.

Auf der anderen Seite existieren meist proprietäre Design-Produkte, die den "Zero Coding"-Ansatz anstreben. Das sind richtige Produkte, nicht nur integrierbare Frameworks. Das Schreiben von Quellcode ist oft nicht notwendig oder gar nicht möglich. Stattdessen setzt der Anwender die Geschäftsprozesse in einem grafischen Designer via Drag & Drop um. Die Praxis zeigt hierbei, dass er oftmals umständliche Workarounds benötigt, wenn eine gewünschte Funktion nicht verfügbar ist. Denn einfach hinzufügen geht eben nur mit Quellcode. Um zu vermeiden, dass man einen Showstopper erst im Laufe des Projekts aufgrund einer fehlenden Funktion findet, ist ein Proof of Concept bei den proprietären Produkten dringend zu empfehlen.

Zudem sind sie oftmals teuer und allzu mächtig, denn neben dem eigentlichen BPM-Produkt wird oft auch zusätzliche Software des gleichen Herstellers wie ein Application Server oder eine Rules Engine benötigt. Allein die Testinstallation für die Evaluierung zieht sich schnell über zwei bis drei Tage hin, bevor sich das BPM-spezifische "Hello World" aufsetzen lässt. Im Gegensatz zu entwicklerzentrischen Open-Source- bieten die proprietären Produkte aber auch große Vorteile wie hohe Stabilität, ausgereifte Weboberflächen und gute Integrationsoptionen in die restliche Entwicklungsumgebung (IDE, Datenbank, Modellierungstools etc.) – desselben Herstellers natürlich.

Neben den proprietären Produkten von Herstellern wie Oracle oder IBM existieren im Bereich der Design-Produkte Open-Source-Alternativen wie Bonita Open Solution oder ProcessMaker. Diese sind einfach zu installieren und nach kurzer Einarbeitung einsetzbar. Sie besitzen nicht die Mächtigkeit der Produkte der "Big Player". Dafür bieten sie den großen Vorteil, dass eigene Erweiterungen relativ einfach hinzufügbar sind.

Ist diese Frage hinsichtlich der Tools erst einmal beantwortet, lassen sich die übrig gebliebenen Produkte anhand der anderen Vergleichskriterien evaluieren.

Die Prozesslogik des Kreditantrags benötigt nur fachliche Informationen. Da keine komplexen Abläufe oder Verzweigungen vorhanden sind, sind auf dem Level auch keine technischen Informationen zu beschreiben. Daher kann der Fachbereich den Prozess modellieren, den die Entwickler nachher um die technischen Details ergänzen. Es empfiehlt sich dafür ein einfach zu installierendes und intuitiv bedienbares Produkt. Sofern ein Proof of Concept gelingt, lässt sich ohne Bedenken ein designzentrisches Produkt aus dem Open-Source-Lager einsetzen.

Regel 7: Um BPM erfolgreich zu gestalten, ist das zum Einsatz passende BPM-Tool auszuwählen.