Frank's Blog

BPM 2013 - Agile BPM Methodology 

Today I'm blogging directly from the International Conference on Business Process Management 2013, taking place in Beijing, China. While not really anything on the net works as expected, at least my blog does :-)

Since I'm not sure what I'm allowed to write about from this conference (no, hopefully just kidding), I'll simply focus on promoting our conference paper that Christian Thiemich and I wrote about An Agile BPM Methodology.

The paper is a really nice summary of Christian's Master Thesis updated with recent results. Best of all, it's written in English, so anyone who is interested in an agile BPM methodology can finally take a closer look.

Edit (Sep 01, 2013): You can find the corresponding presentation here.
[ view entry ] ( 6357 views ) permalink $star_image$star_image$star_image$star_image$star_image ( 3 / 5754 )
Production Case Management 


During the last decade, Business Process Management (BPM) has gained lasting acceptance as a discipline for modeling, executing, and monitoring business processes. Especially in the area of structured and repeated work, a high level of standardization and automation can lead to high gains in profits. Nowadays, however, BPM is often extended to areas of (partly) unstructured work. Our experience shows that—depending on the type of company—around 50-70 per cent of all processes are not well structured and cannot easily be modeled in standard notations as BPMN. Nevertheless, since in many companies these processes also represent mission-critical core processes, there is a high interest in gaining the BPM advantages as done for structured workflows.

Traditionally, the area of unstructured work is investigated in the field of Case Management. Case Management can be split into two different kinds: Adaptive Case Management (ACM) and Production Case Management (PCM), see Keith Svenson's blog. ACM focuses on unstructured work, where the activities are tied together at runtime via a central case document. Production Case Management, in contrast, focuses on pre-defined processes that typically only represent so-called ”happy paths”. While the former one has been investigated in depth during the last years, the latter one is not yet well investigated. Based on strong demands from our customers, we developed a certain kind of Production Case Management.

The idea is based on our experience that the business departments of companies have difficulties modeling processes that are not strongly structured. This is especially difficult, as the industry-standard BPMN 2.0 does not support the modeling of Case Management besides very basic concepts like the Ad-Hoc Sub Process. What can easily be captured by business departments, however, are so called ”happy paths” or 80 per cent process diagrams. These diagrams can also be easily represented in BPMN 2.0.

A student of mine, Jan Oehlert, investigated the idea of providing a framework that is able to combine a set of these ”happy path” diagrams and merge them together to provide a superset of the state transitions that are contained within the single diagrams. This raises several research questions, such as analyzing the ”merged” process diagrams for correctness, so that they can be executed correctly. It raises the question of how to integrate documents (data models) into the process diagrams. It raises the question of how to integrate additional state transitions that should explicitly not be modeled in a process diagram. It also raises questions about best-practices how BPMN 2.0 can be employed to model the set of diagrams and data models required.


We would like to motivate our research with a simple example. Production Case Management is best applied on businesses with semi-structured business processes that are difficult to capture in a single diagram. The approach is most fitting, when there exist many variants with many instances of the business processes. One example are the back-office processes of large travel agencies that handle complaints from agencies and customers. Another, more simplified example, is a classical sales process.

As shown in the figure above, a ”happy path” sales process is made up of only two sequential activities, ”Create Offer” and ”Approve” offer executed by different roles. Attached to the process is a business (data) object that runs through different states. Since it is convenient for many business people to describe such a happy path diagram, it could easily be captured and agreed upon. Nevertheless, in most case already a huge amount of instances (cases) is handled by this simple business process diagram.

The first part of a process that needs to be defined in order to be executed via a PCMS is the process diagram or, to stress the core idea of our framework, multiple process diagrams. This approach may sound like traditional BPM but, in contrary to it, the process diagrams in PCM do not represent strictly to be followed execution paths. Therefore the diagrams are not required to be complete or need to include every possible execution step. They aim to be what we call ”80 per cent diagrams”, showing only the most likely paths and leaving out those that are not expected to appear very often. We also present the idea of leaving out ”every time possible” activities or events and placing them into separate diagrams instead. Once all diagrams of a process are merged together, the functionality of those separately modeled activities or events will be available without expanding other diagrams. In conclusion, process diagrams in PCM act more as supporting guidelines for the knowledge worker than as restrictive execution paths. We aim to keep them simple and comprehensible.
For instance, additional paths, either extensions or variants, are then simply modeled in different diagrams belonging to the same business process.

An example is shown in the figure above. Corresponding to the BPMN 2 standard, both activities ”Create Offer” and ”Approve Offer” are re-using the activities found in the first diagram via call behavior. Please note that an additional task ”Insert Technical Details”, executed by a different role, together with an additional state of the business object has been added.

In the second step of modeling processes for PCM, we extend our process diagrams by process data. As we have learned from numerous customer projects, there is typically one central data object, containing all case-relevant data (with arbitrary complex structures). We define this data object with its attributes in a separate Business Object Diagram (BOD) and use the BPMN node ”Data Object” to represent it in the earlier or simultaneously created process diagrams. The data model uses to grow whilst the modeling of the process diagrams as the need for further attributes is discovered during this phase. The BPMN node ”Data Object” can carry a state, what we make use of to define the different states a case can be in.

Examples of data objects have already been given in the examples. We assume our data object ”Offer” to only have three attributes ”Creator”, ”Price”, and ”Approved” for highlighting the principle.

From its instantiating to its termination, a case runs through a number of different states, typically like ”new”, ”in process” and ”closed”. In order to keep our framework as flexible as possible, we do not limit the number of potential case states to a pre-defined set. We rather allow the user to self-define them by placing data object nodes in a specific state into the process diagrams and associating them with sequence flows. Whenever a certain sequence flow is followed at runtime, the case is meant to take over the state which is carried by the data object connected to this sequence flow, denoted as case state transition. Later on we will introduce the concept of initial and final states to distinguish the beginning and the ending of the business processes and the individual start and end events found in the process diagrams.

States are also used to link different process diagrams together. An example is shown in the figure above. This part of the process is available if the state of the data object is ”Approved”.

Once all process diagrams are defined and modeled soundly, a case state life cycle is created, consisting of states and state transitions. To provide even more flexibility to our framework, we also support additional state transitions that are not based on any process diagram but exist as further requirements. How those ”additional state transitions” are specified, e.g. by forms or a special type of diagram, is left to precise implementations.

For the execution of the business process consisting of multiple process di- agrams, all possible state transitions of the business object are merged into a single state-transition-graph, representing the Case State Lifecycle, shown in the figure above for the example. Solid lines represent state transitions derived from the process diagrams, whereas dotted lines represent additional state transitions not depicted in a diagram. Regarding the sales process, it should be possible to rework ”Approved” offers, as denoted by the dotted transitions.

If we teased you enough, you can get the full story in all its glory right here (Jan's Master Thesis). Sorry, German only.
[ view entry ] ( 7354 views ) permalink $star_image$star_image$star_image$star_image$star_image ( 2.9 / 230 )
BPMN 2.0 Poster in Chinese 

Finally, one of my wishes for BPMN presentations has come true: The BPMN 2.0 Poster in Chinese is available! Every time I liked to highlight the complexity of BPMN 2.0 in a presentation I wished I could simply show a Chinese version of the famous poster.

Anyway, thanks to our colleagues from the School of Software Engineering in Beijing Jiaotong, we now have a Chinese version along with a written discussion of the Chinese BPMN terms available right on the Poster's Website: The well discussed translation will hopefully pave the way for a broad introduction of BPMN in China.

While you're on the link, please also take a closer look at all the other interesting languages that we offer, currently counting at 13: English, German, French, Spanish, Russian, Swedish, Italian, Dutch, Portuguese, Polish, Hebrew, Ukrainian, and Chinese (in order of their creation)! Visually interesting is the Hebrew version, with text running from right to left.

One more thing: Finally, take a closer look at the footer: The page has been viewed more than 180.000 times!
[ view entry ] ( 7089 views ) permalink $star_image$star_image$star_image$star_image$star_image ( 3 / 257 )
BPMB goes National (inofficial) 

Last friday I attended our regular BPMB (Berlin BPM initiative) meeting, discussing the topic of BPM Governance. While the presentations (from Siemens and comdirect Bank) have been as fine as expected and a lot of discussion took place (as usual), I figured out one remarkable fact: Almost half of the 14 attendees came from outside Berlin!

By outside, I really mean a bit of a ride away. We had two people attending from south-east (Dresden), one from Erlangen, and three from the north (nearby Hamburg, Quickborn, Bremen). This is especially interesting, as the BPMB is a free (e.g. no money involved) initiative from/for people interested in BPM, including vendors, customers, consultants, researchers and anyone else who has a stake in BPM. From my point of view, this is a really stark sign of visibility for our BPM roundtable, also in the European view.

If you would like to join us in one of our workshops, just visit the BPMB homepage or register for the Newsletter at the BPM-Netzwerk.
[ view entry ] ( 4396 views ) permalink $star_image$star_image$star_image$star_image$star_image ( 2.9 / 1354 )
Agile BPM Methodology 

Hi out there! I'm back with my blog, after having fixed some PHP5 related issues (my provider forced me to upgrade). Nevertheless, I brought a very exiting must-read for you (as long as you understand at least a bit German): A student of mine, Christian Thiemich, wrote a wonderful Thesis about an agile BPM methodology.

While you might should know what BPM means, a methodology might be alien to you. Basically, a methodology brings together a development framework (such as Waterfall or Scrum), tools and techniques (such as Quick Checks), and artifacts (e.g. process models). The framework guides you in when to use which tools and techniques to create which artifacts.

The presented framework relies upon the proven Scrum software development framework as well the Integrated BPM project methodology. The former provides the ingredients for a state-of-the-art agile development framework, whereas the latter provides a toolbox for executing the earlier phases of BPM development projects (focused on business and service modeling).

By bringing together those two state-of-the-art frameworks, Christian opens the door for real customer-centric BPM projects - the Customers get the processes they really need, not the ones they designed upfront.

If I teased you enough, get the full story here.
[ view entry ] ( 5947 views ) permalink $star_image$star_image$star_image$star_image$star_image ( 3 / 212 )

<<First <Back | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | Next> Last>>