zurück zum Artikel

Ein Klischee im Zusammenhang mit Business Process Management (BPM) hat sich lange Zeit hartnäckig gehalten: Es sei komplex, teuer und scheitere häufig. Bei Beachtung mehrerer Regeln sollte jedoch einer erfolgreichen BPM-Einführung nichts mehr im Wege stehen.

Ein Klischee im Zusammenhang mit Business Process Management (BPM) hat sich lange Zeit hartnäckig gehalten: Es sei komplex, teuer und scheitere häufig. Heute besteht allerdings kein Grund mehr zu jenem Pessimismus, denn mittlerweile hat sich auf dem Gebiet einiges getan. Bei Beachtung der folgenden acht Regeln sollte einer erfolgreichen BPM-Einführung nichts mehr im Wege stehen.

Dieser Artikel dient nicht als Einführung in BPM, sondern beginnt vielmehr mit einem Anwendungsfall als Beispiel, um Best Practices und häufig begangene Fehler im BPM-Umfeld zu erläutern. Die dafür ausgewählte Anwendung ist ein Kreditantrag. Abbildung 1 zeigt den zustandsbehafteten, lang laufenden Geschäftsprozess eines solchen Antrags. Das Schaubild beschreibt den Prozess und umfasst die Ausführung automatischer Skripte und Services sowie die Interaktionen mit den Menschen. An der Modellierung sind sowohl Fachbereich als auch der IT-Bereich beteiligt. Abhängig von den Ergebnissen der einzelnen Bearbeitungsschritte wird der Kreditantrag schließlich am Ende des Prozesses akzeptiert oder abgelehnt.

BPM, ja oder nein?

BPM ist kein Schweizer Taschenmesser, das als Allzweckwaffe für jedes Problem das passende Werkzeug bereithält. Oder anders formuliert: Es ist nicht die Antwort auf alle Fragen und sollte in bestimmten Situationen sogar vermieden werden. Insbesondere ist nicht für jeden Geschäftsprozess oder Workflow gleich BPM notwendig. Abläufe, bei denen BPM keinen Mehrwert schafft, sollte man wie bisher einfach ausprogrammieren. BPM schafft insbesondere Mehrwert bei lang laufenden, zustandsbehafteten Prozessen, sich häufig ändernden Prozessen und dem manuellen Eingriff durch Menschen.

Der Kreditantrag ist ein gutes Beispiel für lang laufende, zustandsbehaftete Prozesse und menschliche Interaktionen. Bei ihnen lohnt sich die Einführung von BPM. Denn durch seinen Einsatz wird spürbarer Mehrwert geschaffen, indem sich die Transparenz und die Flexibilität der Prozesse bemerkbar erhöhen. Die eigenständige Implementierung der Prozesslogik dagegen wäre mit deutlich mehr Aufwand verbunden und fehleranfälliger.

Regel 1: Um BPM erfolgreich zu gestalten, darf es nur eingesetzt werden, wenn es wirklich Mehrwert schafft.

Klare Ziele für eine gute Zusammenarbeit

BPM hat das Ziel, Geschäftsprozesse fortlaufend zu verbessern und lässt sich insofern als "Prozessoptimierungsprozess" verstehen. Vor allem das Business/IT-Alignment – die Abstimmung von
Geschäftsfunktionen und IT – ist der Schlüssel zum Erfolg. Denn bei der Prozessoptimierung geht es weder allein um die IT noch ausschließlich um das Geschäft. Für eine erfolgreiche Einführung von BPM sind viel Kommunikation und gute Zusammenarbeit zwischen den Fachabteilungen und der IT notwendig. Das zu erreichen ist eine der größten Herausforderungen von BPM. Dabei werden folgende Ziele verfolgt:

• erhöhte Effizienz
• erhöhte Transparenz
• erhöhte Flexibilität
• bessere Qualität
• reduzierte Kosten
• Erschließung neuer Geschäftsmodelle

Das wichtigste Ziel im konkreten Anwendungsfall ist, mehr Transparenz und höhere Flexibilität während des gesamten Verlaufs eines Kreditantrags zu schaffen. Fachbereich und IT sollen gemeinsam die einzelnen Prozessschritte optimieren und, wo immer möglich, auch automatisieren. Die Einführung von BPM ist nur erfolgreich, wenn diese Ziele von Beginn an im Mittelpunkt stehen. Mindestens ebenso wichtig ist, dass die Entscheidungsträger das Projekt von Anfang an unterstützen und ihr Rückhalt für alle Projektbeteiligten erkennbar ist. Ein BPM ohne konkretes Ziel funktioniert nicht. Zudem sollten Leistungskennzahlen festgelegt werden, um den Erfolg oder Nichterfolg der Einführung messen zu können.

Regel 2: Um BPM erfolgreich zu gestalten, sind die Ziele klar zu definieren und transparent zu machen.

Evolutionäre Entwicklung aus SOA

Serviceorientierte Architekturen (SOA) sind das Grundgerüst, auf dem Ansätze wie BPM, Cloud Computing oder Mashups beruhen, wie es Anne Thomas Manes 2009 in ihrem Artikel "SOA is dead; Long Live Services [1]" treffend beschrieben hatte. Insofern ist BPM eine logische Evolution, die sich aus SOA heraus entwickelt hat.

Ein auf SOA beruhendes BPM ist die passende Antwort auf das steigende Verlangen nach einer flexiblen Anwendungslandschaft, anstatt wie bislang in den engen Grenzen starrer Silos zu verharren. Moderne Anwendungen und Ressourcen sollten lose gekoppelt und abgegrenzt von den Prozessen sein. Ansonsten wird die Prozesslogik fest in eine bestimmte technische Plattform gezwängt, wodurch Änderungen zeitaufwendig und teuer werden und damit den eigentlichen Zweck von BPM ad absurdum führen. Ohne SOA und dessen Services mit sauber definierten Schnittstellen ergibt eine BPM-Einführung wenig Sinn. Denn die Vorteile einer erfolgreichen BPM-Anwendung lassen sich ohne Services nicht realisieren.

Im Anwendungsfall ist der Kreditantrag in zahlreiche lose gekoppelte Services aufgeteilt, etwa Skript- oder Java-Service-Tasks und menschliche Interaktion. Das Fundament für eine erfolgreiche BPM-Einführung ist damit gelegt. Würde man den gesamten Kreditantrag hingegen als eine einzige, große Aufgabe betrachten, wären BPM-Ziele wie höhere Flexibilität und verbesserte Effizienz nicht erreichbar.

Regel 3: Um BPM erfolgreich zu gestalten, muss es auf einer serviceorientierten Architektur beruhen.

Über den gesamten Lebenszyklus hinweg

BPM ist nicht nur Tooling. Stattdessen geht es bei der Prozessoptimierung um ein lang laufendes Vorgehen mit zahlreichen Individuen, Techniken und Tools. Der BPM-Lebenszyklus besteht aus folgenden Phasen, die sich iterativ wiederholen: Analyse, Modellierung, Ausführung, Überwachung und Optimierung.

Das Tooling ist wichtig und sollte den gesamten Lebenszyklus unterstützen. Dennoch wäre die Strategie, zunächst ein BPM-Tool einzuführen und danach mit der Modellierung sowie der Umsetzung zu beginnen, wenig ratsam und kann schnell scheitern. Sobald die ersten Geschäftsprozesse modelliert wurden und klar ist, wie sie ausgeführt und überwacht werden sollen, kann man BPM-Tools evaluieren, vorher nicht.

Nicht selten sind zu Beginn eines Projekts viele Anforderungen noch unbekannt oder unklar. So werden in dem Prozess für einen Kreditantrag vermutlich einige komplexe Geschäftsregeln zur Ermittlung der Kreditfähigkeit des Kunden benötigt. Da sich die Regeln häufig ändern, müssen sie flexibel konfigurierbar sein. Dann wäre ein Tool, das keine Rules Engine integriert hat, sicherlich nicht die beste Entscheidung. Denn die nachträgliche Integration einer eigenen Rules Engine bedeutet zusätzlichen Aufwand und erhöht die Komplexität. Daher empfiehlt es sich, dem BPM-Lebenszyklus zu folgen und nicht schon zu Beginn das möglicherweise falsche Produkt auszuwählen. Durch das Vorgehen reduziert man nicht nur den Aufwand, sondern versteht auch die Rollen und Prozesse einfacher. Letztlich ermöglicht das die Auswahl richtiger beziehungsweise sinnvoller Tools.

Regel 4: Um BPM erfolgreich zu gestalten, ist von Beginn an der gesamte Lebenszyklus zu betrachten.

Regeln 5 bis 7

Ausflug in die Mythologie

Vier Mythen von BPM [2] 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 [3]). Er ist seit Januar 2011 in der Version 2.0 [4] 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 [5] 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 [6] (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 [7] 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 [8] 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.

Fazit

Integration nicht um jeden Preis

Ein BPM-Produkt kann bei der Integration der Systeme eingesetzt werden. Beispielsweise existiert im BPMN-Standard ein Service-Task für SOAP-Webservices. Damit lässt sich jede denkbare Technik direkt aus dem Prozess heraus aufrufen. Darüber hinaus sind Skript-Service-Tasks beispielsweise für Groovy oder JavaScript, ein Java-Service-Task (als Extension) und andere nützliche Features verfügbar. Letztlich ließe sich die gesamte Anwendungslogik im Geschäftsprozess gleich mit implementieren.

Dennoch bleibt die Frage, ob ein BPM-Produkt wirklich für die Systemintegration eingesetzt werden sollte? Falls nur ein oder zwei Services zu integrieren sind, ist das sicherlich in Ordnung. In allen anderen Situationen sollte aber gemäß dem Motto "Separation of Concerns" eine saubere Trennung zwischen Geschäftsprozess- und Integrationslogik durchgeführt werden. Ansonsten drohen unübersichtlicher "Spaghetti-Code", hohe Komplexität und hohe Wartungskosten, wodurch die Vorteile einer SOA wieder vernichtet wären.

Ein BPM-Produkt ist eben kein Integrationstool, sondern eine Prozess-Engine. BPM sollte nicht zum Selbstzweck eingesetzt werden, sondern nur dann, wenn es echten Mehrwert bietet. Es soll nicht Funktionen aufwendig nachbilden, die andere Tools und Patterns bereits erledigen. Für die Systemintegration existieren die sogenannten Enterprise Integration Patterns [9], die sich mit leichtgewichtigen Integrationsframeworks wie Apache Camel oder Spring Integration oder mächtigen ESB-Produkten (Enterprise Service Bus) wie WebSphere Message Broker (proprietär) oder Talend ESB (Open Source) umsetzen lassen. Wolfgang Pleus hat einen kurzen, aber guten Blog-Eintrag [10] über die Kombination von BPM Engine und Integrationsframework sowie deren Überlappungen geschrieben.

Der Kreditantrag ruft ein paar Skripte und Services auf, wobei technisches Wissen für Routing, Transformationen und Schnittstellen benötigt wird. Daher sollte man die Integrations- unbedingt von der Prozesslogik trennen, um den Entwicklungs- und Wartungsaufwand so gering wie möglich zu halten. Da der Geschäftsprozess nur die Schnittstellen zu den Services enthält, löst ein entsprechendes Framework oder Tool die Integrationslogik.

Regel 8: Um BPM erfolgreich zu gestalten, darf es nicht für die Systemintegration zweckentfremdet werden.

Fazit

BPM lässt sich in Projekten erfolgreich einführen und einsetzen. Allerdings entscheidet die Einhaltung der abgeleiteten Regeln über Erfolg oder Misserfolg eines BPM-Projekts. Klare Zielsetzungen, die Betrachtung des ganzen BPM-Lebenszyklus von Beginn an sowie eine sinnvolle Auswahl geeigneter Tools sind die wichtigsten Faktoren für den Erfolg.

Kai Wähner
ist als IT-Consultant bei der MaibornWolff et al GmbH tätig. Seine Schwerpunkte liegen in den Bereichen Java EE, SOA, Cloud Computing und Enterprise Architecture Management. Außerdem ist er Autor von Fachartikeln und hält Vorträge auf internationalen IT-Konferenzen. (ane [11])

URL dieses Artikels:
https://www.heise.de/-1715608

Links in diesem Artikel:
[1] http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html
[2] http://www.activevos.com/blog/soa/the-four-myths-of-bpm-projects-what-it-project-teams-need-to-know/2011/01/18/
[3] http://www.bpmn.org/
[4] https://www.heise.de/news/BPMN-2-0-fuer-eine-bessere-Zusammenarbeit-zwischen-Fachabteilung-und-IT-1175099.html
[5] http://activiti.org/
[6] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
[7] http://www.infoq.com/articles/bpmn-2
[8] http://www.jboss.org/jbpm
[9] http://www.eaipatterns.com/
[10] http://www.pleus.net/blog/?p=1028
[11] mailto:ane@heise.de

Copyright © 2012 Heise Medien