Falling into the trap of BPM Round-Trip Eingineering – a common example in the context of BPMN
“I’ve already documented my processes graphically in my drawing tool, so how can I import and run it in your workflow system?” Manufacturers of workflow-management and business process management systems have been fielding this question and others like it since the early 1990s. Continuing with the theme of my initial article BPM Round-Trip Engineering – Vision and Reality, I would like to walk through a short but specific example to explain why turning a graphically documented process model into an executable process is not as easy as you might think. Exporting a process from a common drawing tool into a workflow engine shouldn’t be so hard, right? If we assume that we’re working according to an interoperability standard, then the devil – as they say – is in the details.
In this case, the devil resides in a detailed answer to the question of who is expected to perform an activity. The graphical model of Business Process Model and Notation (BPMN) facilitates use of swim lanes to depict areas of a company where specific tasks in a business process shall be executed. In the following flowchart I have placed the areas of sales and production in the lower pool in a simplified example of order processing. The customer’s pool, which requests, evaluates, and accepts the quotation; receives the products; and pays the invoice, is not further differentiated.
For documentation purposes, it is often adequate to simply specify an activity by name (such as “Capture quotation request”) and assign it to a swim lane. In real-life situations, though, additional differentiation is provided. In the most straightforward case, a request for quotation lands in a group inbox. From there, each member retrieves and complete a task. In more complex situations, case data is precaptured. Parameters and stored rules are then referenced in order to determine which employee will receive the task directly.
If an employee in the sales department sends the order to production so the availability of requested products can be evaluated, then the next task (Generate reply to customer) will be returned to the previous employee instead of going into the group inbox. There is no standard convention in BPMN for this particular case. In other words, this is the first exception to the rule, so the two tool manufacturers must decide on the characteristics of such a control parameter.
SAPERION gives us the ability to say that the person executing an activity becomes its OWNER. But this must also be entered into the modeling tool. I created the flowchart above using the Process Editor from Signavio, our partner for BPM round-trip engineering. Our new version 7 will be available soon and will make it possible to enter the term @OWNER for the Assignment attribute of the selected activity. Therefore: when the process for the “Draft reply” activity appears at runtime, the workflow engine will send the activity to the person who previously worked on this activity and was designated as the OWNER.
In a nutshell: We have already departed from the BPMN standard.
But we’re not even done yet. In many cases, the person handling a process will have to decide who will perform the next activity. Of course, once a request for quotation has been captured, the production department will always review it next. But what if the person from the sales department knows from experience who can best review the particular situation at hand? Here as well, there are no attributes for executing the process. As a result, the Signavio Process Editor must be able to insert a small flag into a dialogue so this parameter can be properly adopted when exported to the SAPERION Workflow Engine.
In the above-mentioned article, which I wrote one-and-a-half years ago, I offered my view that the new version 2.0 of BPMN (which is now close to release) will take us one large step forward in the area of BPM Round-Trip Engineering. However, we will still need a few years until the standard provides executability that is adequate for human-centric workflows. SAPERION and Signavio are currently working on integration issues that will help make this a reality.
1 Comment »
RSS feed for comments on this post. TrackBack URL


Hi Martin.
Ich gehe übrigens auch mit BPMN 2.0 immer noch weiter davon aus, das wir eine Art Mapping zum ausführbaren Modell werden wollen (auch wenn nicht unbedingt brauchen). Denn da kann ich dann auch viel einfacher mal ne logische Info (“@OWNER”) reinpacken um dann durch einen automatischen Schritt ein Standardkonformes BPMN 2.0 XML rauszubekommen… Das habe ich auch hier ein bisschen beschrieben: http://www.bpm-guide.de/2010/06/06/why-you-may-want-a-mapping-in-your-bpmn-roundtrip/.
Schöne Grüße
Bernd