Es ist erfreulich, dass mittlerweile weitere deutschsprachige BPMN-Bücher auf dem Markt erscheinen, nimmt doch das Interesse an dieser Standardnotation nach wie vor zu. Doch die Kenntnis der Notation alleine genügt nicht, und so konstatieren die Autoren, dass praktisch alle BPMN-Nutzer vielfältige Probleme bei der richtigen Anwendung der BPMN haben. Die Tatsache, dass die Bedeutung der BPMN-Elemente recht exakt definiert ist, ist durchaus ein Vorteil gegenüber anderen Notationen. Andererseits ist es oftmals schwierig, verständliche und übersichtliche Modelle zu erstellen, da die korrekte und vollständige Darstellung gemäß BPMN oftmals recht viele Details erfordert.
Aus ihrer praktischen Erfahrung heraus haben die Autoren deswegen ein Framework entwickelt, das die Handhabung der BPMN erleichtern soll. Es enthält insgesamt vier Ebenen:
- Strategisches Prozessmodell: Hier geht es darum, Prozesse im Überblick zu modellieren und ein schnelles Verständnis zu erleichtern.
- Operatives Prozessmodell: Auf dieser Ebene werden operative Abläufe fachlich detailliert modelliert. Ziel ist es einerseits, die Prozesse für die Prozessbeteiligten geeignet darzustellen, und andererseits, eine fachliche Spezifikation als Grundlage für die Entwicklung einer IT-Unterstützung zu schaffen.
- Technisches Prozessmodell für die Ausführung durch eine Process Engine bzw. IT-Spezifikation für die klassische IT-Entwicklung.
- Implementierung: Beim Einsatz einer Process Engine entfällt diese Ebene, da die Modelle der dritten Ebene direkt durch die Process Engine ausgeführt werden. Ansonsten findet hier die Umsetzung der IT-Spezifikation statt.
Auf der ersten Ebene tritt das oben geschilderte Problem Exaktheit vs. Verständlichkeit besonders stark auf, da hier explizit Übersichtsmodelle gewünscht sind. Um dieses Dilemma zu lösen haben sich die Autoren dazu entschieden, bewusst Vereinfachungen zuzulassen, wobei sie der Regel folgen, die BPMN-Syntax möglichst korrekt anzuwenden, aber wo erforderlich eine ungenaue bzw. unvollständige inhaltliche Darstellung zuzulassen. So wird im Beispiel eines Bewerbungsprozesses nur eine Bewerber-Bahn verwendet, obwohl ja eigentlich eine Vielzahl von Bewerbern beteiligt ist. Ebenso werden Rückfragen, Schleifen u. ä. weg gelassen. Entsprechend wird auf der ersten Ebene nur eine Teilmenge der gesamten BPMN-Konstrukte eingesetzt.
Von der Bahn zum Pool
Auf der zweiten Ebene werden die Modelle verfeinert und erweitert. Hierbei handelt es nicht um eine reine BPMN-konforme Hierarchisierung mittels Unterprozessen. Da beispielsweise auch zusätzliche Verzweigungen und Ereignisse eingeführt werden, enstehen tatsächlich ganz neue Modelle auf dieser Ebene. Auch die herkömmlichen Modellierungstool werden daher nicht in der Lage sein, diese Abhängigkeiten sauber zu verwalten.
Um die entstehende Komplexität auf dieser Ebene in den Griff zu bekommen werden die Modelle zudem in unterschiedliche Pools aufgeteilt. Hier wird ein weiteres Defizit der BPMN deutlich: Wechselt man von einer groben zu einer feinen Betrachtungsweise, so kann es sinnvoll sein, die Bahnen der Übersichtsmodelle in Pools umzuwandeln und somit die Sequenzflüsse teilweise durch Nachrichtenflüsse zu realisieren. Die BPMN (und damit auch BPMN-Tools) bietet jedoch keinerlei Konstrukte an, um derartige Zusammenhänge zu verwalten. Für jeden Prozessbeteiligten wird auf der zweiten Ebene ein eigener Pool modelliert. Vorteil: Man kann jedem Beteiligten ein individuelles Modell zur Verfügung stellen, das nur den Sequenzfluss dieses einen Beteiligten enthält und die Zusammenarbeit mit den anderen Beteiligten über Nachrichtenflüsse zu deren zugeklappten Pools darstellt. Die Details der anderen Beteiligten sind somit ausgeblendet. Hilfreich wäre hierfür ein Tool, das es erlaubt, Pools nach Belieben auf- und zuzuklappen.
Das Verstecken der Details anderer Beteiligter in zugeklappten Pools hat andererseits auch Nachteile: Einerseits geht die Gesamtsicht auf den Prozess verloren, andererseits sind recht aufwändige Sequenzflusskonstrukte mit ereignisbasierten Gateways und vielen Ereignissen erforderlich, worunter die intuitive Verständlichkeit wieder etwas leidet. Bei dem vorgestellten, relativ kleinen Beispiel wäre eine komplette Darstellung des Prozesses in einem Pool unter Umständen sogar übersichtlicher. Hier wäre ein etwas größeres Beispiel sicherlich hilfreich. Ein solches ist für die Website zum Buch angekündigt, auf der es sich bisher aber leider noch nicht findet.
Fachliche Modelle sind nicht ausführbar
Ein ähnliches Verfahren wird für die Vorbereitung der Ausführung durch eine Process Engine angewandt: Hier erhät die Process Engine einen eigenen Pool, der für jeden Prozessbeteiligten eine eigene Bahn enthält. Jeder Beteiligte hat außerdem nach wie vor seinen eigenen Pool. Hierdurch kann das Zusammenspiel mit der Process Engine auf fachlicher Ebene genau beschrieben werden. Außerdem können Prozessabschnitte, die außerhalb der Process Engine durchgeführt werden, besser modelliert werden. So wird z. B. deutlich, ob eine Entscheidung von der Process Engine oder einem Mitarbeiter getroffen wird. Auch hier muss man wieder abwägen zwischen den genannten Vorteilen und den Nachteilen einer doch recht umfangreichen und komplexen Darstellung. Neben dem BPMN-Modell werden auf fachlicher Ebene auch weitere Beschreibungen benötigt, wie Klassendiagramme, Entscheidungstabellen und Maskenentwürfe.
Die Umsetzung von Modellen gemäß der klassischen IT-Entwicklung erfolgt über die Ableitung von Use Cases, deren Detailabläufe selbst wieder mit BPMN beschrieben werden könne. Dieses Thema wird nur kurz gestreift, da die Implementierung prozesslastiger Anwendungen ohne Process Engine von den Autoren als nicht sinnvoll betrachtet wird.
Entsprechend wird der Ausführung von BPMN-Modellen durch Process Engines mehr Platz eingeräumt. Hier wird deutlich gesagt, dass fachliche Modelle nicht auführbar sind und die Generierung von technischen Modellen aus fachlichen Modellen stark überschätzt wird. Aber bereits durch die Nutzung einer gemeinsamen Notation und die Verwendung ähnlicher Modelle entsteht schon ein deutlicher Nutzen.
Es wird beschrieben, wie ein technisches Prozessmodell aussieht und wie die erforderlichen Datenstrukturen und logischen Ausdrücke, Serviceaufrufe usw. spezifiziert werden. Hierzu werden auch die erforderlichen XML-Strukturen vorgestellt. Im Gegensatz zu vielen anderen Publikationen mogeln sich die Autoren nicht an den praktischen Problemen bei der Umsetzung vorbei. Sie erläutern vielmehr sehr konkret, welche Fragestellungen beispielsweise hinsichtlich der Umsetzung von modellierten Ereignissen, der Korrelation von Nachrichten zu Prozessinstanzen oder der Umsetzung von fachlichen Transaktionen zu klären sind.
Alles in allem handelt es sich um ein sehr praxisorientiertes Buch mit vielen konkreten Anwendungshinweisen. Auch wenn man in seiner Modellierungspraxis nicht zwangsläufig jeden Vorschlag unverändert übernehmen muss, so sind die vielen Ratschläge und Tipps doch eine nützliche Hilfe. Was anhand des Buchs außerdem deutlich wird: Sowohl die BPMN selbst, als auch heutige Modellierungstools weisen noch deutliche Schwächen auf. Und es wäre sicherlich nützlich, wenn sich die Diskussionen im BPMN-Umfeld stärker um die praktische Anwendbarkeit drehen würden als z. B. um die immer gleiche und in vielen Teilen obsolete Frage der Überführung nach BPEL.
Freund, J.; Rücker, B.; Henninger T.:
Praxishandbuch BPMN
Hanser, München Wien 2010.
Das Buch bei Amazon (Anzeige)
Ich würde mich Ihrem Fazit absolut anschließen. Sowohl in dem Punkt, dass Jakob Freund und Bernd Rücker reale Probleme in der Modellierungspraxis mit BPMN ansprechen, als auch dass Tools diese realen Probleme teilweise nur mangelhaft adressieren.
Letzteres betrifft Signavio als Tool-Anbieter natürlich im Insbesonderen. Aus diesem Grund haben wir im Rahmen unserer Partnerschaft mit der camunda beschlossen, die Thematik „Stakeholder-bezogene Sichten“ mit einem neuen Ansatz zukünftig Tool-seitig zu unterstützen.
Und zwar nicht im Sinne einer Checklisten-Alibi-Funktion mit wenig Praxisrelevanz wie etwa das von Ihnen angesprochene BPMN-zu-BPEL. Vielmehr soll eine deutlich bessere Zielgruppen-Orientierung beim Prozess-Publishing sowie der Prozess-Kollaboration die Folge sein.
Das ganze funktioniert in wenigen Worten zusammengefasst wie folgt:
* der Modellierer pflegt auf Ebene 2 oder Ebene 3 ein sehr umfängliches Prozessdiagramm mit mehreren aufgeklappten und ausdetaillierten Pools/Lanes
* dieses umfängliche Diagramm geht aber selbst nicht ins Publishing
* stattdessen kann auf dieses Diagramm entsprechende „Sichten“ definieren
* eine „Sicht“ ist nichts anderes als das ursprüngliche Diagramm, bei dem ich wählen kann, ob einzelne Pools/Lanes ausgeblendet werden sollen oder zugeklappt dargestellt werden sollen. Somit entstehen sehr viel kleinere und spezifischere Diagramme als „Sichten“, die ich z.B. einzelnen Prozessbeteiligten zugänglich machen kann.
* Änderungen, die ich am umfänglichen Diagramm vornehme sind natürlich automatisch und ohne manuelles Nachziehen in den Sichten verfügbar
Diese Funktion ist prototypisch bereits umgesetzt und wird derzeit mit camunda gemeinsam verprobt.
Viele Grüße aus Berlin,
Torben Schreiter
Das klingt vielversprechend. Schön, dass solche Anregungen direkt aufgegriffen werden.
Wir hatten gestern eine WebCon mit Signavio dazu, und ich muss sagen, dass der aktuelle Stand sehr vielversprechend ist. Wenn es weiter so gut vorangeht, sollten wir bis Ende Juni eine Plattform haben, die das Framework durchgängig unterstützt.
http://www.computerwoche.de/software/soa-bpm/1929685/
Viele Grüße
Jakob Freund