BPMN 2.0:

EINE ZWISCHENBILANZ

setzt hatten. Andere große und weltweitrelevante Anbieter von Prozess-Enginesverweigern sich bis heute der BPMN undbleiben älteren Standards, wie z. B. derBusiness Process Execution Language(BPEL) und der XPDL (XML Process De -finition Language (XPDL), oder ihrer eige-nen proprietären Prozessbeschrei bungs -sprache, treu.

Aus Sicht dieser Hersteller ist das natür-lich verständlich, aus Anwendersicht abereher enttäuschend. Zwar muss man zuge-stehen, dass die Idee der einfachen Aus -tauschbarkeit von Prozess-Engines dankBPMN 2.0 ohnehin in der Praxis kaum rea-listisch ist: Dafür sind proprietäre Erwei -terungen des Standards in den jeweiligenProdukten aus unterschiedlichen undzumeist nachvollziehbaren Gründen zuhäufig erforderlich. Trotzdem lohnt sichdas Erlernen einer einheitlichen Aus -führungssprache: Einen guten Teil desKnow-hows, das man für die Prozess -

Die Business Process Model and Notation (BPMN) 2.0 wurde im Januar 2011 verabschiedet.Die primäre Intention dieses Standards ist die Verbesserung der Abstimmung zwischenBusiness und IT bei der Entwicklung von Anwendungen für das Human-Workflow-Managementund die Orchestrierung von (Web-)Services. Knapp zwei Jahre später ist es nun Zeit für eineZwischenbilanz: Wo stehen wir in der Zusammenarbeit zwischen Business und IT, wenn es umdie Automatisierung von Geschäftsprozessen mit BPMN geht?

m e h r z u m t h e m a :bpmn.info

26 27

halb der IT realisiert werden. Dieses Phä -no men beschränkte sich nicht auf dieProzessautomatisierung, sondern konnteauch allgemein in IT-Projekten beobachtetwerden, wie beispielsweise dem Atlas-Projekt des Bundesministeriums der Finan -zen (vgl. [Cam-b]).

Mit der Version 2.0 und der somit direk-ten Ausführbarkeit der Prozessmodellewaren dementsprechend große Hoffnungenverbunden, da die zuvor notwendigenMappings nun entfielen und ein echterRoundtrip der Modelle zwischen Businessund IT in greifbare Nähe rückte.

Schleppende Umsetzungin den EnginesObwohl die Prozess-Engine-Anbieter IBM,Oracle und SAP selbst die drei hauptver-antwortlich treibenden Kräfte hinterBPMN 2.0 waren, sollte es noch einigeMonate dauern, bis sie den Standard inihren eigenen Produkten überhaupt umge-

Der Siegeszug von BPMNObwohl die Business Process Model andNotation (BPMN) bereits 2002 entwickeltwurde, begann ihre eigentliche Verbreitungim Jahre 2005 mit der Adaption durch dieObject Management Group (OMG), dieunter anderem den UML-Standard verant-wortet. Seitdem wurde sie weltweit vonzahlreichen Unternehmen und Behördenaufgegriffen, wobei sie gerade in Deutsch -land erst relativ spät wahrgenommen wur-de. Eine Ursache dürfte in der hierzulandetraditionellen Dominanz der ereignisge-steuerten Prozesskette (EPK) sowie be -stimmter Tools für das organisatorischeProzessmanagement liegen, deren Her -steller eigene Notationen definiert habenund diese auch gern beibehalten hätten.Ungefähr im Jahr 2008 begann aber auchin Deutschland die Trendwende zu Gunstender BPMN, nicht zuletzt, weil viele Unter -nehmen lieber einen global gültigenStandard für die Prozessmodellierung ver-wenden als die proprietäre Notation ir -gend eines Tool-Herstellers.

Zur VorgeschichteIn BPMN modellierte Geschäftsprozessekönnen zwar erst direkt in Prozess-Enginesausgeführt werden, seit die Version 2.0 einformales Metamodell in Form eines XML-Schemas vorgibt, das der Serialisierung derDiagramme dient. Tatsächlich wurde derStandard jedoch schon zuvor für dieProzessautomatisierung eingesetzt, bei-spielsweise 2010 bei der 1&1 Internet AG:Dort wurde die Bestellabwicklung vonDSL-Anschlüssen in BPMN modelliert undmit Hilfe einer Modelltransformation(Mapping) in die proprietäre Prozess -sprache von JBoss jBPM 3 überführt (vgl.[Cam-a]). Schon damals konnten nennens-werte Vorteile bei der Prozessabstimmungzwischen Fachabteilung und IT sowie imRahmen des Prozessbetriebs auch inner-

schwerpunk t

Jakob Freund

(jakob.freund@camunda.com)

ist Geschäftsführer der camunda services GmbH

und berät seine Kunden zu den Themen Business

Process Management und BPMN. Er interessiert

sich für Prozessarchitekturen, die sowohl die

Organisation als auch die technische Umsetzung

von Kernprozessen direkt unterstützen.

der au tor

Abb. 1: Tool-Kette auf Basis von BPMN 2.0.

6/2012

umsetzung in einem Produkt von Oracleaufbauen muss, kann man für die Auto -matisierung mit SAP Netweaver wiederver-wenden. Sobald das Produkt jedoch eineandere Sprache spricht, muss man dieLernkurve in dieser Hinsicht kompletterneut durchlaufen.

Auch deshalb ist es umso erfreulicher,dass neue Anbieter von Prozess-Enginesden Markt betreten haben, die von Anfangan konsequent auf BPMN 2.0 setzen.Dabei hat sicher auch das Open-Source-Projekt „Activiti“ (vgl. [Act]) unterstützt,das eine native BPMN-2.0-Engine enthältund in unterschiedliche kommerzielleProdukte integriert wurde.

Erfreuliche Umsetzung in denModellierungswerkzeugenDer Markt für Modellierungswerkzeuge istschon weiter. Mittlerweile haben die meis -ten etablierten Hersteller BPMN in ihrenProdukten berücksichtigt. An dieser Stellehat tatsächlich das marktwirtschaftlichePrinzip gewirkt: Manch ein Anbieter warzunächst wenig begeistert von BPMN, hatdann aber notgedrungen die Unter stützungumgesetzt, da sie in Ausschrei bungen undKundenanfragen immer häufiger zumK.O.-Kriterium wurde.

Mittlerweile kann man als Kunde also auseiner breiten Palette von BPMN-Werk zeugenwählen, die sowohl als Open-Source bzw. alsFreeware als auch zu kleinen und großenLizenzpreisen von bis zu sechsstelligen

Beträgen verfügbar sind. Damit einher gehtein größerer und besser funktionierenderMarkt für Beratungs- undSchulungsleistungen: Dem BPMN-Exper tenist es egal, mit welchem Tool der Kundearbeitet. Er kann auf jedem Produkt schulenund beraten, das BPMN ordentlich unter-stützt. Dementsprechend zahlreich sind mitt-lerweile auch die Informa tions quellen imInternet sowie die Bücher, Beratungs- undSeminarangebote zu BPMN. Der damit ver-bundene zunehmende Qualitäts- undPreiswettbewerb dürfte schlussendlichwiederum dem Kunden zu Gute kommen.

In Bezug auf die angestrebte verbesserteAbstimmung zwischen Business und IT spieltdie Kombinierbarkeit von Model -lierungswerkzeugen und Prozess-Engineseine besondere Rolle. Im Idealfall können

Business-Analysten, Requirements-Engi -neers, Product Owner und andere Akteuremit einem intuitiv bedienbaren Werkzeugden Soll-Prozess modellieren und die Ent -wickler können dieses Modell in derEntwicklungsumgebung ihrer Prozess-En -gine direkt übernehmen und in die technischeAusführung bringen (siehe Abbil dung 1).Wenn dabei Änderungen des Prozessmodellserforderlich werden, können diese sofort indas fachliche Model lierungswerkzeug zurük-kgespielt und bei Bedarf durch den Vertreterder Fachseite geprüft und freigegeben wer-den. Diese Kombination aus Forward- undReverse-Engineering wird in der BPM-Weltauch als Roundtrip bezeichnet. Ein guter Teilder Idee hinter BPMN 2.0 basiert auf derAmbition, diesen Roundtrip praktisch zuverwirklichen.

Auch hier fällt die Bilanz in Bezug auf diegrößeren Hersteller eher ernüchternd aus:Ein vollständiger BPMN-Roundtrip miteinem wirklich businesstauglichen Tool ein-erseits und einer entwicklerfreundlichenUmgebung andererseits ist bislang nicht inSicht. Dabei wäre das technisch gar nicht soschwierig und es wurde bereits demons triert,wie eine BPMN-2.0-Prozess-Engine mit achtunterschiedlichen BPMN-Model lierungs -werk zeugen gekoppelt werden kann, darun-ter so bekannte Werkzeuge wie „BOC Ado -nis“ oder „Enterprise Archi tect“ (vgl.[BPM-a]). Dabei ist es sogar möglich, dieHistorie für eine durchlaufene Prozessinstanzinklusive der Laufzeitin for ma tionen, wie z.B. der Durchlaufzeit für einzelne Aufgaben,direkt im Diagramm des fachlichen Werk -zeugs einzublenden (siehe Abbildung 2).

Anforderungen an dieBetriebsorganisationMit der Popularität von BPMN nahmnaturgemäß auch die Anzahl ihrer Kritiker

schwerpunk t

Abb. 2: Laufzeitinformationen für eine konkrete Prozessinstanz, eingeblendet in einemBPMN-Diagramm aus Adonis (der Prozess steht momentan in der Aufgabe„Rechnung klären“, erkennbar an der orangefarbenen Markierung).

Abb. 3: Dieses Diagramm sieht einfach aus, ist aber missverständlich.

haben die Erfahrung gemacht, dass auchFachanwender ohne BPMN-Kenntnisse die-se Darstellung relativ schnell verinnerlichenund auf andere Prozessfragmente anwendenkönnen, denn tatsächlich handelt es sichhierbei um ein Muster, das in den unter-schiedlichsten Prozessen immer wiederkehrt.Ganz nebenbei ist dieses Diagramm nichtnur eindeutig interpretierbar, sondern ineiner BPMN-2.0-Prozess-Engine auch nochdirekt ausführbar. In der EPK haben wir einesolche Form der Modellierung überhauptnicht zur Verfü gung.

Das Beispiel ist nur die Spitze desEisbergs: Es gibt zahlreiche Modellierungs -muster dieser Art, deren Existenz den meis -ten Interessierten zunächst gar nichtbewusst ist, die aber den eigentlichen Wertvon BPMN in der Praxis ausmachen. Hierwird auch deutlich, dass BPMN tatsächlichein starkes Umdenken erfordert, wenn manbislang mit älteren Prozessnotationen wieder EPK gearbeitet hat. Insofern ist es nichtüberraschend, dass EPK-Kenner häufiggrößere Schwierigkeiten haben, BPMN zuverinnerlichen, als Menschen, die nochüberhaupt keine Erfahrung in der Prozess -modellierung haben. Im schlimmsten Fallmussten wir feststellen, dass leidenschaftli-che EPK-Anhänger BPMN anders anwen-den als eigentlich gedacht, damit sie ihrebisherigen Denkmuster nicht aufgebenmussten. Ein schönes Beispiel hierfür ist die„Prozess-Schnittstelle“ in der EPK, die eineVerknüpfung von zwei Prozessen im Sinneeines Vorgängers und Nachfolgers ermög-licht. Das Konzept widerspricht fundamen-tal den zentralen BPMN-Denkmustern, dieeine solche Beziehung nur entweder alseinen sequenziellen Aufruf von zweiTeilprozessen innerhalb eines Ober -prozesses begreifen würden oder als eineKollaboration zweiter autonomer Prozesse,die über Nachrichtenflüsse miteinanderkommunizieren.

Insgesamt kann man festhalten, dassBPMN zwar die Abstimmung zwischenFach- und IT-Seite wesentlich verbessernkann, dies aber auch das Meistern einersteilen Lernkurve auf Seiten der Prozess -modellierer bedingt. Das gilt wohlgemerktfür die Ersteller, nicht für die Betrachter derProzessmodelle. Ein guter Prozessmodel -lierer ist in der Lage, mit BPMN sehr aus-sagekräftige, häufig direkt ausführbareBPMN-Diagramme zu erstellen, die trotz-dem auch von BPMN-unkundigen Fach an -wendern schnell verstanden und korrektinterpretiert werden können.

28 29

ger hinzieht, die entstehende Verzögerungnach fünf Tagen gemeldet werden, damitder Vorgang eskaliert werden kann. Wennman diesen Prozess modelliert und sichdabei auf diejenigen Symbole der BPMNbeschränkt, die man auch aus anderenNotationen kennt, besteht eine guteChance, dass ein Diagramm wie inAbbildung 3 dabei herauskommt. ZumVergleich zeigt Abbildung 4 eine traditio-nelle EPK, die nach demselben Prinzip auf-gebaut ist.

Diese Modelle erscheinen zunächst ein-fach, da die verwendeten Symbole mehroder weniger allgemein bekannt sind.Jedoch ist die Semantik weder korrekt nocheindeutig nachvollziehbar: Den Modellenzufolge würde, wenn die Antragsprüfungfünf Tage oder länger dauert, diese Ver -zögerung erst nach abgeschlossenerPrüfung gemeldet werden. Wir könntenalso den Antrag auch 100 Tage lang prüfen– eine Verzögerung wird stets erst gemel-det, wenn die Prüfung abgeschlossen ist.Wir könnten das Ganze umbauen, um dergewünschten Semantik näher zu kommen,werden diese aber nie ganz erreichen,zumindest nicht ohne eine größere Anzahlvon Symbolen hinzuzuziehen und damitdas Diagramm schlussendlich wieder un -übersichtlich zu machen.

In Abbildung 5 sehen wir, wie wir diegewünschte Semantik relativ elegant errei-chen können. Wir benutzen dazu ein ange-heftetes Zeitereignis, das als „nicht unter-brechend“ markiert ist (gestrichelte Linie).Jetzt drücken wir aus, dass nach fünf Tageneine Verzögerung gemeldet wird, wenn dieAntragsprüfung entsprechend lange dauert(und auch nur dann). Die Antragsprüfungwird nicht abgebrochen, sondern parallelzur Verzögerungsmeldung fortgesetzt. Wir

zu. Ein häufiges Argument gegen denStandard ist die Komplexität der Notation:Über 60 unterschiedliche Symbole sind dar-in enthalten und man darf natürlich be -zweifeln, dass der durchschnittliche Fach -anwender, beispielsweise im Vertrieb oderin der Buchhaltung, all diese Symbole erler-nen wird. Mittlerweile hat sich aber dieErkenntnis durchgesetzt, dass genau dieserFachanwender erstens tatsächlich zugäng-licher für viele Symbole ist, als zunächstangenommen, und zweitens die gesamtePalette auch gar nicht kennen muss, umvon BPMN zu profitieren.

Das folgende Prozessfragment verdeut-licht das: Ein eingegangener Antrag wirdgeprüft. Wenn der Antrag in Ordnung ist,wird er angenommen, ansonsten abgelehnt.Außerdem soll, wenn sich die Prüfung län-

schwerpunk t

Abb. 4: Eine EPK-Version desDiagramms aus Abbildung 3.

Abb. 5: Das Zeitereignis markiert eindeutig, unter welchen Umständen eineVerzögerung gemeldet wird.

6/2012

Neue technische PatternsDa BPMN eine vom konkreten Soft -wareprodukt unabhängige Sprache ist,wird sie auch zunehmend zu einem belieb-ten Vehikel für Architekturdiskussionen inder IT-Community:

■ In seiner Dissertation hat beispielsweiseVolker Stiehl die Umsetzung der be -kannten EAI-Workflow-Patterns mitBPMN und Prozess-Engines beleuchtet(vgl. [Sti11]).

■ Bernd Rücker schlägt eine konkreteUmsetzung des UI-Mediator-Patternszur Kombination von Masken- undProzessflüssen in Prozess-Engines vor(vgl. [BPM-b]).

■ Daniel Meyer modelliert möglicheStrategien zur Sicherung der Trans -aktionssicherheit in BPMN undbeschreibt ihre Konsequenzen für Pro -zess anwendungsarchitekturen (sieheAbbildung 6 bzw. [BPM-c]).

Obwohl diese und viele weitere Diskus -sionsteilnehmer aus unterschiedlichen Kon -texten stammen und verschiedeneSoftware produkte kennen, sprechen siedoch mit BPMN alle eine gemeinsameSprache und können auf diese Weise ihrWissen weitergeben, ihre Erfahrungen aus-tauschen und neue Lösungsansätze mitein-ander diskutieren.

Verfeinerungen funktionierennur seltenIn der Lehre und Praxis dominiert bis heu-te eine etwas problematische Vorstellungdavon, wie man von einem fachlichen zueinem technischen Prozessmodell gelangenkann: Dieser zufolge beschreibt man einenGeschäftsprozess zunächst nur grob undverfeinert ihn dann über Teil- oder Unter -prozesse (in BPMN Sub Processes), bis man

einen Detaillierungsgrad erreicht hat, dereine direkte Ausführung in einer Prozess-Engine erlaubt. Während also die unterenEbenen des Modells technisch verwertetwerden, können die oberen Ebenen alsDokumentation für Mitarbeiter oderAuditoren dienen.

Dieses auf den ersten Blick sehr plausibleVorgehen wird inzwischen seit fast zehnJahren empfohlen – und doch gibt es so gutwie keine Beispiele aus realen Projekten, indenen es tatsächlich funktioniert hat (ichkann das zwar nicht empirisch belegen,beschäftige mich aber seit 2004 mit demThema und beziehe hier insofern Stellungaus meiner eigenen Sicht). Wo liegt dasProblem? Zusammengefasst gibt es – ganzunabhängig von BPMN – zwei Ursachen:

1. Eine konsistente Verfeinerung ist häufigschon auf fachlicher Ebene schwierigund beim Übergang in die technischeUmsetzung so gut wie unmöglich.

2. Das ausführbare Prozessmodell istnicht nur die technische Abbildung

fachlicher Anforderungen, sondernselbst ebenfalls ein fachlicher Artefaktund darf daher nicht nur von Ent -wicklern determiniert werden.

Um den ersten Punkt zu verdeutlichen,betrachten wir einen typischen End-to-End-Prozess, den Rechnungseingang inAbbildung 7, auf grober Ebene. Das Pro -blem ergibt sich, wenn wir diesen Prozessverfeinern wollen, um bestimmte Detailsaufzunehmen. Beispielsweise wird die Ge -schäftsführung nicht jede Rechnung sofortbezahlen, die genehmigt wurde. Nehmenwir an, sie macht nur einmal pro Monat,z. B. zum Monatsende, einen Sammel -durchlauf, um alle aufgelaufenen Rech -nungen zu bezahlen. Dieser Umstand istgewissermaßen eine Detailinformation(Wie erledigt die Geschäftsführung dieAufgabe „Rechnung bezahlen?“), aber wirkönnen sie in diesem Diagramm nicht sau-ber und präzise beschreiben. Natürlichkönnten wir irgendeinen Hinweis hinein-setzen, eine Textanmerkung an der Auf -gabe „Rechnung bezahlen“ zum Beispiel.Aber wir wollen ja den Ablauf insgesamtverfeinern, um ihn im Ergebnis so detail-liert zu beschreiben, dass eine Prozess-Engine ihn ausführen kann, soweit dassinnvoll ist. Mit diesem Prozessmodell istdas jedoch unmöglich: Es beschreibt genaueinen Vorgang (eine Rechnung) und fürjede Rechnung wird die Aufgabe „Rech -nung bezahlen“ ausgeführt. Es ist unmög-lich, in dieses Modell z. B. einen Teilprozess„Rechnungen bezahlen“ einzufügen, dererst am Monatsende ausgeführt wird.Besser ausgedrückt, wäre es sogar möglich,aber dieser Teilprozess würde genauso oft

schwerpunk t

Abb. 6: Ein „Two-Phase-Commit“, modelliert in BPMN (Quelle: Daniel Meyer,camunda).

Abb. 7: Der Prozess „Rechnungseingang“, grob beschrieben.

30 31

ausgeführt, wie es eingehende Rechnungengibt, d. h. bei 20 Rechnungen pro Monatwird am Monatsende zwanzigmal derTeilprozess „Rechnungen bezahlen“ ausge-führt, was wohl kaum im Sinne desErfinders wäre. Dieses Prinzip ist nicht ver-handelbar und es gilt auch nicht erst, seit esBPMN gibt. Dahinter steckt das Paradigmades Tokens, das nach einem eindeutig defi-nierten Schema durch ein Prozessmodellläuft, egal ob es sich dabei um BPMN, EPKoder eine andere „kontrollflussbasierteNotation“ handelt (vgl. [All09]).

Ein weiteres Problem auf dem Weg zumausführbaren Modell betrifft die Unter -scheidung zwischen dem „menschlichen“und dem „technischen“ Fluss. Beginnen wirmit der Annahme, dass der oben dargestell-te Prozess durch einen Workflow unterstütztwerden soll. Wir können die dargestelltenAufgaben typisieren, um dar zu stellen, obeine Aufgabe manuell (eine Hand), als User-Task (ein Torso) oder als Service-Task(Zahnräder) ausgeführt wird. ManuelleAufgaben werden unabhängig von derProzess-Engine von Menschen erledigt,User-Tasks sind Aufgaben, die ein Anwendervon der Prozess-Engine in seiner Aufgaben -liste zugeordnet bekommt und dann erledigt(typisches Human-Work flow-Managementalso), und Service-Tasks werden direkt vonder Prozess-Engine ausgeführt, indem dieseeine Schnittstelle aufruft.

Während die Prozess-Engine sowohlUser- als auch Service-Tasks interpretiert,

überspringt sie manuelle Aufgaben wäh-rend der Ausführung. Wir kommen aber inVerlegenheit, sobald wir innerhalb einesProzesses Entscheidungspunkte in Formvon Gateways haben, die mal von einem

Menschen und mal von einer Prozess-Engine interpretiert werden sollen.

In dem in Abbildung 8 gezeigten Prozesssoll die Team-Assistenz eine erhalteneRechnung noch vor dem Scannen darauf

schwerpunk t

Abb. 8: Die Rechnung wird manuell geprüft, bevor der Workflow starten soll.

Abb. 9: Menschliche und technische Abläufe im Zusammenspiel(Kollaborationsdiagramm).

6/2012

prüfen, ob sie bestimmten Anforderungengenügt (z. B. ob sie eine vollständige An -schrift enthält). Tut sie das nicht, muss eineneue Rechnung angefordert werden. Nurwenn die Rechnung in Ordnung ist, wirdsie gescannt und damit der technischeWorkflow in Gang gesetzt. Das in Abbil -dung 8 gezeigte Beispiel kann so nicht ineine Prozess-Engine „deployed“ werden:Während die Engine die beiden rechtenGateways interpretieren soll, um den Flusszu steuern, wird erwartet, dass sie das ersteGateway ignoriert (zumal ein technischerProzess ja auch noch gar nicht gestartetwurde). Ein Prozessfluss kann jedoch nurentweder von einer Maschine (Prozess-Engine) oder von einem Menschen kontrol-liert werden, was auch für jede Verfei -nerung des Flusses gilt.

Eine mögliche Lösung dieses Problems istin Abbildung 9 dargestellt. In diesemKollaborationsdiagramm gibt es drei sogenannte Pools, in denen jeweils ein Pro -zess enthalten ist. Der oberste Prozessbeschreibt das Verhalten der Team-Assis -tenz, der mittlere Pool beschreibt den tech-nischen Workflow in der Prozess-Engineund der unterste zeigt, dass die Ge -schäftsführung am Monatsende alle fälli-gen Überweisungen ausführen wird. Mitdieser strikten Trennung von menschlichenund technischen Flüssen können wir denProzess in Gänze betrachten, analysierenund diskutieren und ihn gleichzeitig konsis -tent und direkt in der Prozess-Engineumsetzen, denn der mittlere Pool ist tat-sächlich ohne Transformation genausoablauffähig, wie er hier dargestellt wird.

In dem Beispiel wird auch der zweiteoben angeführte Grund für die Schwächedes Verfeinerungsparadigmas deutlich: DerSchritt „PDF archivieren“ wird automa-tisch ausgeführt, kein Anwender ist darandirekt beteiligt. Dass diese Datei archiviertwird, ist aber nicht etwa der Wunsch eines

Softwareentwicklers, sondern eine fachli-che Anforderung. Sie muss also von derFachseite kommen, obwohl im mittlerenPool doch scheinbar „nur“ die technischeUmsetzung beschrieben wird. Es istschlichtweg nicht möglich, das gezeigteKollaborationsdiagramm in einem gröbe-ren Diagramm zusammenfassen, ohne grö-ßere Fehler im Token-Fluss in Kauf zu neh-men. Das ist in der Praxis jedoch wenigerkritisch, als häufig angenommen wird.Tatsächlich basiert unser methodischesFramework zur Anwendung der BPMN,das im „Praxishandbuch BPMN“ (vgl.[Fre12]) beschrieben wird, auf genau die-ser Erkenntnis. Nichtsdestotrotz wird er -kennbar, dass einige grundsätzliche Para -digmen, die bislang in der Welt derProzessmodellierung galten, möglicher-weise infrage gestellt werden müssen.

FazitBPMN wird von vielen Unternehmen ver-schiedenster Branchen sowie im öffent-

lichen Dienst genutzt und ist in zahlreichenProdukten implementiert. Als Kommunika -tionsvehikel zwischen Business und ITkonnte sich der Standard trotz der zum Teilverzögerten Umsetzung durch die Soft -warehersteller bereits bewähren. Nicht s -destotrotz befinden wir uns noch in einerfrühen Phase der Lernkurve und jedegewonnene Erkenntnis wirft neue Fragenauf dem jeweils nächsthöheren Niveau auf.Insgesamt gibt es aber bereits ein großesÖkosystem an Softwareherstellern, Bera -tern, Anwendern und Wissenschaftlern, indem konkrete Lösungsansätze für dasProzessmanagement sowohl für die fachli-che Prozessorganisation als auch für dietechnische Prozessumsetzung auf Basis vonBPMN intensiv entwickelt, diskutiert undgetestet werden. Unterm Strich darf BPMNinsofern schon aus heutiger Sicht als eineErfolgsgeschichte bewertet werden, dieeinen wichtigen Beitrag zur Weiterent -wicklung der Informatik leistet. ■

schwerpunk t

Literatur & Links

[Act] Activiti, Activiti BPM Platform, siehe: Activiti.org

[All09] T. Allweyer, BPMN 2.0, Books On Demand, 2009

[BPM-a] BPM-Guide.de, BPMN 2.0 funktioniert, siehe: bpm-guide.de/2012/06/18/bpmn20-works/

[BPM-b] BPM-Guide.de, Page-Flow vs. Process-Flow – how a UI Mediator might help, siehe: bpm-

guide.de/2012/04/04/pageflow-vs-process-flow-and-ui-mediator-pattern

[BPM-c] BPM-Guide.de, Where is the „retry” in BPMN 2.0, siehe:

bpm-guide.de/2012/06/15/where-is-the-retry-in-bpmn-2-0/

[Cam-a] camunda, Prozessautomatisierung mit BPMN und Open Source, siehe:

camunda.com/references/1&1_de.pdf

[Cam-b] camunda, Prozessmodellierung und IT-Spezifikation mit BPMN 2.0, siehe:

camunda.com/references/bmf_de.pdf

[Fre12] J. Freund, B. Rücker, Praxishandbuch BPMN, Carl Hanser Verlag 2012

[Sti11] V. Stiehl, Systematisches Konstruieren von Verbundanwendungen unter Verwendung von

BPMN, TU Darmstadt 2011, siehe: tuprints.ulb.tu-darmstadt.de/2751/1/verbundanwendungen.pdf