I want to share some thoughts about it.

First Prof. Börger looks at some of weaknesses of the BPMN 2.0 Standard.

He sais:

The crucial criterion is how well the practitioner is supported when walking through the different levels of detail (refinement levels).

The standard does not support process structure at the risk of producing incomprehensible spaghetti diagrams.

The standard document fails to provide a seamless systematic mechanism for refinement from conceptual to executable models, which is necessary to guarantee the reliability of the implementation.

I discussed the same topic some days ago. I agree that the standard does not prescribe a solution to the problem, but as I said keeping some basic rules the solution is easy. It is always a question of discretion how much should be prescribed by a standard and how much should be described in a guideline or methodology or best practice how to use a standard effectively. There are always many ways to do it wrong, but as long as it is easily possible to do it right, it should not be such of a headache. As I said I will discuss the way to do it right in the seminar BPMNexpress. In general also I teach it also in the mentoring.

He also sais:

Furthermore a statistical evaluation (of BPMN 1.1) shows that `the average BPMN model uses less than 20% of the available vocabulary’ and that, out of the more than 50 graphical elements in BPMN, `Only five elements (normal flow, task, end event, start event, and pool) were used in more than 50% of the models we analyzed.’

Yes, and this is why it is possible to learn what you really need to know about BPMN in half a day. Of course full mastery is only reached within a longer process of modeling, mentoring and quality assurance. But this is normal with any modeling method.

The he talks about difficult modeling concepts in BPMN 2.0:

The lifecycle concept is an example of an underspecified feature, particularly in relation to the equally underspecified interruption mechanisms like exceptions or cancellation or compensation for transactions.

I have the same opinion. I tried to convince the BPMN 2.0 standardization team that these concepts are too difficult and problematic. Now I recommend to my clients not to use them. However for all of these problems, there is an easier way to solve them.

A general notion of state is missing and, as a consequence, the specification of relevant data dependent conditions is only poorly supported.

In fact BPMN 2.0 has a notion of state for data objects. This already helps a lot! I do recommend to my clients the use of state for data objects and it makes many modeling problems much simpler.

And yes, the state model is not very elaborated – but it can be extended.

Communication and process interaction are poorly supported for concurrent execution, e.g. of independent (not embedded) subprocesses or of processes belonging to different parts of one organization or to different cooperating organizations.

An analogous problem results from the poor interweaving of different BPMN diagram types, in particular that no consistency criteria are imposed for them, for example collaboration vs choreography vs process diagrams.

I do not agree at all. This is one major part of what is new in BPMN 2.0 compared to BPMN 1.x. I will teach this in BPMNdelta.

Later Prof. Börger looks at difficulties with WPI Workflow Patterns

The workflow patterns, as presented by the WPI, come without pragmatic or rational foundation. In fact there is no statistical underpinning showing how frequently which patterns appear in real-life business processes.

My opinion is that some of these are of practical relevance and others are not. I am preparing a publication on the topic, but it is not finished. Also most of these patterns that are relevant in practice can be reduced back to very simple principles of modeling.

Prof. Börger has the same opinion as he sais:

In fact most patterns are not of fundamental character but are easily definable from a small set of more basic and rather simple patterns.

In the last section Prof. Börger discusses YAWL and coloured petri nets. Some of his statements:

In this section, we show that the purported semantic foundation of YAWL using coloured Petri nets is not `suitable’ for the practice of BPM.

… deal with patterns that Petri nets have difficulty expressing, in particular patterns dealing with cancellation, synchronization of active branches only, and multiple concurrently executing instances of the same task.’

… languages which `lack the concepts to be able to deal with the broad range of requirements one may encounter when trying to precisely capture business scenarios’ directly applies to Petri nets, work flow nets, reset nets and other extensions proposed for modeling business processes.

I already discussed some days ago, why I would not build a new standard for Adaptive Case Management based on BPMN and I argued it is because of the “token logic” – actually what is meant is the petri net logic of BPMN. So we – Prof. Börger and me – have the same opinion on this if we refer to advanced scenarios. These are some of the topics that I will discuss in BPMfuture.

As I said BPMN is good for some problems, but it is difficult with more flexibility as it is needed for Adaptive Case Management and in general for the work of knowledge workers. Instead of building more and more complex formal constructs to address all of these special cases it is easier to not use petri net at all for Adaptive Case Management.

However I am more optimistic than Prof. Börger when we refer to cancellation scenarios and BPMN. Yes – he is right it is very difficult with petri net – but BPMN also has other features of modeling. It is possible in BPMN to use data objects and state – and therefore it becomes easier to model cancellation scenarios. I do teach this in BPMNexpress.

Finally he proposes to use a concept of introducing Product Lines to BPM. I have to study this more, before I say something about it.

I disagree.

My modeling guideline gives some basic rules, and if they are followed, this does not happen.

• First it is important to distinguish between level of granularity and degree of detail. These are not the same thing.
• Second it is important to model the data objects and their state.
• Third it is necessary to model different variants of one and the same process in different models.
• Fourth we mostly do not work with sub-processes but with call activities
• Fifths we model the preconditions and the post-conditions of a process in such a way, that they fit together.

If these simple rules are followed, then I can guarantee a concise and well integrated set of models.

You can learn this and more in the half-day seminar BPMNexpress.

At the BPMN 2011 Practitioner’s Day in Potsdam we had the opportunity to try out tangible BPM modeling or t.BPM. It is a research project of the Hasso-Plattner-Institute. Instead of modeling in half-dark rooms with flickering monitors we went outside into the sun. There we had tables prepared and plastic shapes for BPMN available. The team grouped around the table and we placed the shapes on the table to model. Pens were available to label the shapes and connect them.

I really liked this very much. It was fun. And I think it was quite productive. The focus of all team members was on the model and we were fast in achieving a result. It was good to discuss during modeling. I also liked, that by this all were focused on the model itself, not the tool. Often when modeling we lose time to fiddle with the tool, the routing of lines etcetera. I think I might use it in future BPMN classroom trainings. I expect that it is possible for the participants to focus on the model and the BPMN method; to have a shared collaboration experience. So in my eyes it is ideal for BPMN classroom trainings.

To my surprise Why do Process Modeling Projects fail? made it quite high in the ranks. But if I think about it – yes – I understand the question very well.

I had my own share of failed projects, especially when I was novice in the area. And each failed project taught me something that I did not know before. After a while trying again and again I discovered stunning facts that were the foundation for succeeding success.

In my eyes this is absolutely natural in the area of knowledge work. And modeling is knowledge work. Therefore it is inevitable to try, to fail, to learn and finally to succeed.

If somebody promises: “I have the silverbullet method.” something is wrong. Either the task is too simple and therefore mainly irrelevant, or it is a lie. Business Processes are far from being simple, and if they are, then they are not worth modeling them, because they describe an area where only commodity business is done.

It looks so simple on the first glance. But it isn’t. For example take the other question: How to model one process with different variations at once? It is not so simple to answer this question. In my experience what is necessary to succeed in business process modeling is a deeper understanding about the laws of the business processes domain. Otherwise the result will be too complex to be used in practical terms. For example a car can be engineered, if the engineer understands the underlying laws of physics. Even if the car modeling tools look simple in the first place, they alone are not sufficient, nor are “methods” to model. Tools can help, methods can help. But they are not sufficient. Many training classes teach tools or methods. But to achieve a deeper understanding of the laws of the business processes domain in general, and the laws of the business processes from the special domain that I am modeling, they do not suffice.

The need for methods and tools is also expressed in the questions What are the 5 golden rules of process design? And Which business process management tool and notation suit my needs best? Given what I said I would answer this:

1. We need to find out the laws of business processes domain and the special domain that I am modeling.
2. We need to find 5 rules that respect these domain laws.
3. We need to identify the notation, that best fits to these domain laws and
4. We need to build or select a tool that supports this notation and is convenient to use.

Of course this has been tried many times. BPMN 2.0 and BPMN in general is just another attempt towards this goal. But still one of the most asked questions is: Why do Process Modeling Projects fail? I have my own opinion about the natural laws of business processes. I have modeled many hundreds Business Processes with 1000+ models from the areas of Customer Relationship Management, Supplier Relationship Management, Logistics, Supply Chain Planning, Financial Accounting, Project Management, Human Resources and others. I think BPMN respects some of the laws of business processes, but not all. For example Flexibility and Extensibility is not respected enough. It is not respected enough, that the result of a process is more important than the steps within the process, because the result is needed for another process, but the steps are irrelevant. Therefore there are too many variations of the processes, which are actually not needed, if the results of processes are modeled instead of the steps leading to the result. Another opinion about BPMN type of modeling I have is that most processes are over specified. This means the model is much less flexible than the reality.

In these days the Workflow Coalition will publish a book “Mastering the Unpredictable”. There we – process thought leaders from industry – argue that today’s process technology does not yet reflect the laws of unpredictable business processes and that there exist many of those.

Two recent Gartner key Predictions give insight in this very interesting and emerging part of process technology:

By 2012, 20 per cent of customer-facing processes will be knowledge-adaptable and assembled just in time to meet the demands and preferences of each customer, assisted by BPM technologies.

By 2013, dynamic BPM will be an imperative for companies seeking process efficiencies in increasingly chaotic environments.

So the whole process technology topic is still making very necessary progress. New domain specific languages will emerge, of which BPMN is but one. These new languages will respect the now known laws of the business process domain in a better way than today.

This all is nice and good. But what should I do today? Wait for a better future? Certainly not.

What are practical findings from using BPMN? is a very clear question and it is the most asked question. And in my opinion this is the best question. Because it is possible to use BPMN in a way, that respects the domain laws of business processes, even if they are not yet built into the notation. And this knowledge is exchanged by practical tips solving practical problems. Yes, there is a need to better understand the theory as the question What is new in BPMN 2.0? indicates. But even more there is the need for practical tips.

In my experience this can be achieved by coaching and governance. This is supported by the question What is required for BPMN coaching and governance? which is also quite high in the ranks. The answer is another question: Why you need a center of excellence BPM? The answer is: To provide the necessary coaching and governance. Of course there is much more to know about what is required for BPMN coaching and governance.

In some weeks I will start a coaching program. You are invited to it. You should have theoretical background already and you should have some practical experience already as well. The number of participants is limited to 7 for one year. It includes a Kick off meeting, weekly Web-Meetings as well as monthly meetings in a city somewhere in the middle of all participants. I addition to this coaching program I will offer training classes for the public as need arises. One training class will certainly address BPMN 2.0, another probably about how to organize coaching and governance inside your company- all with a very pragmatic approach. Of course the blog also will continue and I may publish another book or articles once in a while. I am looking forward to meet many of you in person who are reading this blog now for a while.

After that, I am sure we will engage in an interesting discussion about these. This can take any form that is required. It may be Blog Posts, Webinars, Network Meetings, Seminars, writing a book about it or a scientific article or pointing to events, where the topic is discussed.

I am really interested in the results.

Model Business Process

First of all the Business Process itself is modeled. The focus of this activity is to identify the steps that need to be performed to reach the goal and their dependency. This is done irrespective of the participants, which are not completely clear at this point in time.

Break into Participants

This is a design decision. Often Participants are companies of the business world. Still it is a design decision how fine or coarse granular they are designed and which part of the process is executed in which participant. For example it is possible to define different departments within a company as one or many participants.

Model Choreography

Now the interaction between participants can be modeled by means of the choreography model. This is a top-down approach. Therefore it defines the frame of subsequent detailed process modeling within the participants.

Model Public Processes / Services of Participants

As a next step the public processes and services of the participants can be modeled. It is decisive to model which services which participant exposes and which constraints exist between the service operations (e.g. an order needs to be confirmed, before it can be delivered).

If a complete system is designed from scratch, the public process models and the services are designed as To-Be processes and services. But in most instances the participants will at least in part already exist. Therefore As-Is models will be created and must be aligned with the To-Be model. This is the most challenging part of all. Because if the public process of a participant cannot be freely designed, because the cost to change it is too high, then the choreography must be changed, which in turn means, that the other participant may need to change. This is the most challenging negotiation in the design process.

Derive Business Objects

Before an implementation can start, Business Objects, which implement the behavior of the participants, need to be derived. The behavior of the Business Objects needs to be made consistent with the public behavior of the participant.

In the end the public behavior of the participant will be an abstract process, while the business objects will be concrete. This will also be very clear, when it is time to model correlation rules – i.e. which message instance is processed by which process instance. At this point in time, the most natural process instance will be the business object instance. Remember: The public process is only an abstract process – therefore it does not have instances.

Model Common Monitoring Process

Now the details have been modeled and we want to re-aggregate the execution of the processes into a common process view on instance level. The Monitoring Process View is needed as a re-simplification of the already modeled details. In the optimal case the monitoring process is equal to the original process model which stood at the beginning. Most probably there will be deviations for good reasons. This of course is also a good exercise to re-confirm the original requirements and justify the deviations from it.

That’s when I thought, what if Business Process Modeling could be made more real by means of virtual reality. In know – Second Life is not the place, where one would meet too many Business Process Modelers. But – there are businesses to be fair. Even though the hype is gone, it’ still there and – a place where I could try the idea of more tangible Business Process Modeling in a virtual reality.

Viola.

What, if a group of avatars would meet and collaboratively move around and build the process? Discuss about it, while they watch each other? They could simulate the process and adapt it, if necessary.

Ok – maybe the process is more like the 3D version of a paper or screen type of pattern. So why not try one or the other pattern? Like walk though the process?

Maybe completely new patterns of representing models emerge over time. Maybe it is also an idea to sit at a table and use activities like lego bricks.

Maybe even if 3D is exploited in a better way, sub processes can be displayed together with the main process. Or the whole process is like a big house with many rooms.

Interestingly enough in the last BPM 09 conference in Ulm there was a scientific discussion about tangible process modeling. There was a research project where Activities were made tangible by means of plastic bricks and people moved them around on the table. In the real world I mean. They mentioned the next challenge was to digitalize the result in a more effective way. Well – maybe virtual reality modeling is the solution to this problem. In some future.

So – that’s my fun project.

http://www.bpmn-selftest.org/

I made it to rank 14 of 394. However I wonder who the 13 were, that were better . So give it a try, maybe you can beat me. The test is anonymous however.

Nevertheless I want to share what I thought when I saw the models. They were quite complicated. I think if models are as complicated in a real project as those in the test, then something went terribly wrong in the first place. I agree, that it is fine for a research project to use artifical complicated models, to find out more about human model comprehension. And I am very interested in the research result. But models must be much simpler than those.

Simpler models could be reached by limiting the scope of one model – i.e. splitting it up in different parts, using submodels for example. As far as I remember human comprehension can assess 7 items at once, not more. So in essence I think a model should not contain more than about 7 important steps.

Also it can mean to model only the most important cases and model the special cases in a different model.

And it can mean to question, if BPMN is the right model language for the purpose chosen. I know that BPMN is popular and becomes even more, because it is a standard. But in my eyes the question remains, if the task flow oriented modeling it does is really the best way to do it. In my eyes it should be evaluated as a result of this research project, if goal driven and constraint based modeling would not result in much easier models.

So – it is very useful to have this tool for the top-down design of process interaction now. Inversely it can be used for the validation of an already existing bottom-up modeling. In reality it will be a mixture between the two. It is of central importance to have the enforceability in mind, that is to define a process, that is actually executeable by the participants. For this the model levels serve as basis for validation.

If we go down to the technical modeling, it is now possible to model Conversations, which are groups of Message Flows, Correlations, which are assignments between a message and a process instance, Service Bindings, Data Flow, … Compared to BPMN 1.2 the DataFlow is more than an artifact now (i.e. more than just a pictogram). It has a datastructure and the Activities have DataInput and DataOutput. Also the DataObject can be used as Parameterspecification for reusable Subprocesses. The Events have been enhanced. There are complex Events, Events , that can interrupt an activity or not, it is possible to define Event-Subprocesses that run aside from the Sequence Flow.

Here some critical comments from my side may be allowed. I think the workflow type of modeling is too strong in this. First there are strong sequence flow relationships established, only to be loosened later by many Events. I think it would be better for the future to define the relationships more loosely from the beginning. For example they could be modeled as preconditions depending on the status. That is something for the future.

Personally I found the discussion around the relationship between public and private processes very fascinating. One time it seemed like we had so many problems with it, that we could not do it. And additionally to this there was the climax of the debate with the concurrent submission. We were blamed, that our model was too strict. A very good discussion! But we found a very simple and elegant solution to these problems. The sequence flow is now not so strict than it was before. It has been loosened, and the difficulties disappeared.

Furthermore one important area is to have in mind the asynchronity of messages. That can produce race conditions between messages. However this in my opinion is not mainly a technical problem, but is due to the asynchronous nature of business processes, that I hope to discuss in the Blog as well in the future. Most problems on the message technology side can be avoided on the business process design level – and that is good news.

There are more changes from 1.2 to 2.0, but in my view these were the most important.BPMN has become quite powerful. Sometimes it is not so clear as to how to solve a certain modeling problem. However the success will depend on elaborating best practices and good guidance.

My wishlist for BPMN in the future? Modeling of Interactions with and of Business Objects. Find simpler ways to model special cases. Model a Process specific  Status.

But now is the time that BPMN 2.0 has to be used and proven in practice. After that we can establish our common opinion about the wishlist for the future. It is a language. And the vocabluary is only the beginning of the process to learn to speak that language. Therefore a good coaching process is what I can recommend.

Elaborating more on what I said before about loosely coupled processes, I want to emphasize today, that the cut of the processes is of major importance – i.e. which parts are loosely coupled and which parts are tightly coupled. Furthermore if process parts are loosely coupled, it is of big importance which process parts are public and which are private. Public process parts constitute a contract, that the other participant can rely on (when to request, when to confirm), while private processes are only needed within the operations of one participant’s organization – for example an approval or a special form of approval that is irrelevant to the other partner. This has these benefits:

• Flexibility: It is possible for one participant to adapt the private process to changes as business requires it without the need to negotiate with the other partner, as long as the change still complies to the public process.
• Stability: The participant can rely on the behavior of the opposite participant, even when the opposite participant makes changes that comply to the public process.
• Visibility: In Process Monitoring internals are not visibible because they should not. It is a decision of discretion which parts of the process should be visible to other partners. However I believe that BPMN 2.0 might be amended for this purpose, because for this it might be necessary that also non-communication activities can be part of a public process.
• Decoupling: The number of private processes that comply to a public process needs not to be multiplied with the number of choreographies, that comply to a public process. Say you have 3 choreographies that you want to combine with 3 private processes. Then without decoupling you have 3*3=9 process models. With decoupling you have 3 + 1 + 3 = 7 process models.

It is important to understand, that the Choreography is an abstract process while the private process is a concrete process – i.e. can be executed by a process engine and has process instances. So the Choreography Model will never be executed by a process engine. It is the summary view of the participants. It never proceeds on it’s own. It proceeds, if one of the participants proceed (as far as the public process is concerned).

If you ever tried to build a central process with process instances that decide about the message flow, you might have tasted how difficult that is. For simple processes this might still be possible. However you always find these difficulties:

• Either the central process does not have enought information to decide – and that are business decisions in the end – or
• The central process needs to know nearly everything.
• As soon as information reaches the central process by means of messages, it is already outdated (because the sender might have evolved in the mean time).
• Also in many decisions it is necessary to involve humans, not just rules.
• If humans are involved, they might not only to decide left-right, but regroup – solve differently (e.g. create return instead of lowering delivery quantity).

This all leads to the conlusion, that I have made for myself: If there is a middle tier, it needs to be a full fledged business application in the end. With business objects, UIs and the like.

Then we have 3 partipants instead of 2 – which is fine. Then we have 2 Choreographies between them, which are still abstract.