This post was originally published at bpmntraining.ru.

Typical BPMN use cases are:

1. create a process-based operations manual (let’s call this “analogue” process modeling)
2. create a BPMS-executable model (let’s call this “digital” process modeling)
3. create process-based software requirements for application developers

Let’s define the analogue/digital divide first and then proceed to use case #3.

» read the rest

Bruce Silver shared his thoughts about the conditional event in the recent post.

For those not deeply immersed into BPMN 2.0, the conditional event pauses a process until specified logical expression becomes true (changes its value from false to true, to be precise). I’m writing this post in October, so the good conditional start example would be:

Fig. 1. Conditional start event example.

Here the process starts when the logical expression becomes true, i.e. when winter comes. (BTW, this is the real rule in effect here in Moscow.)

The typical conditional intermediate example:

Fig. 2. Conditional intermediate event example.

Here the process waits until the invoice record stored in some unspecified system would be marked as paid. (This is overly simplistic version - please be patient, the more robust will follow.)

Bruce says that he prefers not to use conditional events and excluded it from the “Method and Style” - the collection of best practices he created, supports and promotes by his famous book (the best BPMN guide in my opinion).

With all respect to Bruce as my BPMN teacher, I have a different opinion on the matter: I believe that conditional event is the best solution for certain quite common process collaboration scenarios. (To be more specific, it’s the conditional intermediate event; the conditional start event doesn’t have much value so it won’t be discussed here.) » read the rest

The BPMN 2.0.2 specification is ambiguous regarding the subject.

Please compare:

1) Table 10.89 at p. 250 says:

The None Intermediate Event is only valid in normal flow, i.e., it MAY NOT be used on the boundary of an Activity. Although there is no specific trigger for this Event, it is defined as throw Event. It is used for modeling methodologies that use Events to indicate some change of state in the Process.

2) Table 10.93 at p. 259 also clearly shows that None intermediate is a Throw event.

3) However the text at p. 271 says the opposite:

There are three (3) variations of None Events: a Start Event, a catch Intermediate Event, and an End Event

Here is what other authoritative sources say -

4) Bruce Silver, “BPMN Method & Style”:

Omission of eventDefinition signifies a throwing None event, which is allowed; it can be used in the diagram to indicate a particular state of the instance.

5) Tibco:

Intermediate None event indicates an unspecified change in the process.

6) Camunda:

Intermediate none events (throwing) can be used to indicate some state achieved in the process.

Looks like the text at p.271 should be corrected to -

There are three (3) variations of None Events: a Start Event, a throw Intermediate Event, and an End Event

PS. Thanks to my colleague Julia Wagner for pointing to this issue.

UPDATE: Bruce Silver’s comment -

Anatoly, Yes I agree with your post - (3) is incorrect, along with 400 other errors reported since 2009.

I wrote here already that it’s common for what business considers a business process to become several process pools in BPMN - look at process patterns “internal order” or “incoming processor”. In both examples the “client” process posts a task into DB and process to wait message from the “server” process that the task is completed.

The diagrams are valid but here is the caveat: server should know the client internals - namely the event on the client side. It’s ok if the server deals with a single client but what if not?

» read the rest

Last time we found out that only two of five BPMN gateways are absolutely necessary: XOR and AND.

Now let’s consider events. BPMN events are categorized by type (13 variants) and position (8 variants). Let’s consider event types:

1. None

» read the rest

It’s a paradox but the term “process” remains the most ambiguous in BPMN, as the recent discussion on the BPM.com forum has shown.

• In our day-to-day life we call “process” almost anything from digestion to the formation of galaxies.
• Many consultants are comfortable with the process definitions that cover any orderly set of activites aimed at certain result. It makes sense when we focus on business performance but when we get into details it becomes hard to ignore the difference e.g. between processes and projects. One may treat a project as special case of a process indeed but the fact is that we manage projects and processes substantially differently so a definition that makes no difference between processes and projects would be counter-productive. That’s why I like the term “business capability” - it provides an umbrella term for different kinds of business activities yet it doesn’t merge them all into “process” treated too widely.
• Process definition narrows even more in BPMN context. First, there is a clear difference between a process and subprocess in BPMN: the former is triggered by external event (e.g. a message, timer or free will of process initiator) while the latter is called from overarching process or subprocess. Secondly, the entities more abstract than a single process are beyond BPMN scope completely. There is no element to model process groups in BPMN so one can’t depict things like “value chain”, “supporing processes” or “product promotion”.

Thus, if we look at the process hierarchy through the prism of BPMN, we’d find several levels of process groups at the top, several levels of subprocesses at the bottom and a thin layer of what BPMN calls a process in the middle:

See also:

• What Is a BPMN Process (And What Is Not)

Complete BPMN palette includes hundreds of elements if all allowed combinations are counted. Seasoned professional should know the semantics and usage rules of any but at the same time shouldn’t seek to use them all.

Firstly, exotic elements would make the diagram less comprehensible for business users, leading to refusal in some cases. Probably the biggest BPMN advantage is that it’s both intuitive and strict enough, allowing business users, analysts and IT developers to be on the same page. But this is going to happen only if a good style and healthy minimalism are followed.

Secondly, if BPMS powered processes are considered, no engine implements BPMN completely and strictly. Hence the popular questions: how critical is a given BPMN element being not supported? Is there a workaround?

In this article we’ll investigate BPMN gateways - which ones are must-have and how others can be workarounded. The other BPMN elements will follow.

» read the rest

In my previous post I did a favor to BPMN messages fans by including these elements into human-powered palette. Frankly, I’d recommend to leave them off because in too many cases people use message events excessively and incorrectly, like in the example below:

Dangerous! Do not try this at home.

People that use just tasks, gateways and control flows, tend to create more straightforward and more comprehensible diagrams than those who are aware of BPMN messages and message elements. BPMN message events/tasks are similar to automatic tasks: they are for process engines and aren’t supposed to be executed by a human.

The most common misunderstanding is associating the envelope icon with email. A human task should be utilized to model sending an email in human-powered environment; if the process is BPMS-powered then script task is the best option:

Wrong: email via messages	Right: email via human task (human-powered process)	Right: email via script task (BPMS-powered process)

If one just wants to depict that a certain task communicates with some external entity (e.g. customer or supplier) then black box pools and message flows attached directly to the task may be an option:

Better yet, keep the diagram clear from message flows and black box pools. If the task is labelled “Get customer’s commitment” then it’s pretty clear that it communicates with the customer, no need to clutter the diagram:

There is only one case when black boxes and messages are essential: if one needs to depict ALL the messages going to/from the external entity in order to visualize the complete “communication contract” with the said entity.

The final note about message events vs. message tasks: their primary functions are identical. The subtle differences are those between events and tasks in general: unlike events, tasks may carry attached events (e.g. timers) and/or modifiers (e.g. mutli-instance) which is handy sometimes:

Either your BPMN diagram is executed by BPMS engine or it must be executed by human performers: each performer shall not only execute the assigned task but also route the process to next task and next performer.

As an example, performer A should pass the case either to B or C depending on the result of Task 1 assigned to him:

Performer A should be aware that it’s his/her responsibility not only to perform the task but also to execute the following XOR gateway. He/she should know what the following BPMN element means and how to process it. It’s clear enough in the example above - everyone would guess it’s a gateway - but other BPMN elements are not that obvious.

I would not even try to instruct an employee how to execute e.g. a non-interrupting boundary escalation as well as most other events. Please keep in mind that if you leverage some BPMN element in a diagram that will be human-powered then you’ll have to train every employee how to handle it. You should also be prepared to mistakes mistakes they will inevitably make. This pressures to keep the active BPMN palette as low as possible.

Service & script tasks? You won’t need them - an automatic procedure launched by a user is a user task, not script neither service.

The BPMN elements worth to be recommended for human-powered processes:

• Pool & Lane
• Data Object, Data Store & Data Flow
• Annotation & Association
• Control & Message Flow
• Tasks: User & Manual; no Script, Service, Business Rule, Send & Receive
• Cycles: Multi-Instance is essential; Loop is excessive hence not recommended
• Subprocesses: Embedded & Reusable, Collapsed only (Expanded is not recommended), Ad-Hoc; Event Subprocess is excessive and complicated hence not recommended
• Gateways: Exclusive & Parallel; no Complex, no Event-Based; Inclusive is excessive and non-trivial hence better to be avoided
• Events: None, Timer, Message (including attached interrupting and non-interrupting), Terminate, Error
• our of scope altogether: Transactions, Compensations & Cancellations

Update: consider leaving send & receive message tasks and message events out of the human-powered BPMN palette. Read more about BPMN messages >>

As we can see, only a handful of BPMN elements are suitable for human-powered processes.

On the other hand, it’s surprising how much can be modelled even with that limited palette. In fact, the better you are in BPMN, the less elements you are using on day-to-day basis.

Some organization develops and then executes some plans.

1. Anti-pattern: planning and execution in one process

Planning will last until all plan items will be executed - this is no good. » read the rest