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.

Sorry, this entry is only available in Русский.

The process maturity model is probably the most underappreciated concept of the Business Process Management discipline.

Virtually every company becomes caught by the business process idea, sooner or later. The BPM promises – sales up! costs down! unprecedented agility! – make people eager to implement the “BPM thing” as soon as possible, if not yesterday.

But here is the trap: people tend to view BPM as an ocean of opportunities where almost any course may be charted. While in reality it’s rather a railroad line named “BPM maturity scale”. Knowing the map of this line is absolutely critical because the process maturity is a part of company’s culture so it can’t be picked up arbitrary or changed easily – only step by step. One should honestly evaluate at what station the organization currently stays and then buy a ticket to the next one. Taking what seems to be a short way may derail the company’s BPM train. » read the rest

When it comes to technology, Digital Transformation is probably the hottest topic at corporate boardrooms today.

Why so? Mobile, social, cloud and big data aren’t that new; Google Trends shows that they have passed the peak. Yet Digital Transformation often associated with these components doubles in popularity each year.

Before talking about “T” in DT, let’s clarify the “D” word. » read the rest

Shelly Sweet (i4process) published a great article about Change Management in Business Process Improvement (BPI) projects: part 1, part 2. » read the rest

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

Scott Francis wrote a great post that very much resonates to our experience.

BPM projects are special because business processes are volatile by their nature. They are changing because (1) the business environment is ever changing and (2) our own understanding of what is the best way to do our job and to serve our customers is changing.

It happens all the time: as soon as the customer’s process is discovered and mapped, people at the customer side say: “do we really work this way?!” Meaning that it’s so obviously inefficient and ineffective. Yet it only becomes obvious after the analysis is done by a competent process team, not in advance.

This is why an attempt to do the process work traditional way - on the basis of rigid specifications and contract terms - is doomed. Here is how Scott describes it:

1. Incredibly detailed specifications for the software, regardless of the native capabilities of the underlying software platforms.
2. Named resources (staff) on the project, in the contract.
3. The contract includes most or all of the specifications, binding the vendor to an exact implementation definition, and removing all doubt about what is desired.
4. Having secured very rigorous contracts, with performance penalties and exacting specifications, the contract will also specify an extremely aggressive average rate for the personnel on the project.

» read the rest

A customer needs to put in order the contract approval process. Desired timeframe is “yeserday”.

But to do so they need to agree the contract with the BPM consultant

The true story…

Process vs. Project Management distinction is in fact very artificial - at a closer look one doesn’t exist without the other.

Both for projects and processes two levels of management can be specified:

1. managing business/company (or its part)
2. managing the management system - let’s call it meta-management

For example, managing the new shop construction is about creating timely and accurate schedule, back it up with resources, make everyone know what he/she should do, where and when. Reporting and control, addressing deviations and adjusting schedule - this is the project management routine. It’s the first level of the project management. » read the rest