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

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

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

In the previous article we divided the collaborative work continuum into projects, processes, cases, document-oriented workflows and issues.

We also noted that it was made for analysis purposes only; in reality, they are interrelated. As an illustration, the PMBOK (Process Management Body of Knowledge) talks about processes more than about projects; similarly, the big part of BPM CBOK (Business Process Management Common Body of Knowledge) is devoted to processes improvement and process transformation projects.

This interrelation shows itself in the following: » read the rest

Interestingly, when you meet a certified project manager, he/she almost immediately starts talking about how important is to manage projects and how it should be done. Similarly, a process management expert looks at the world through processes.

In reality, however, most organizations have to deal with processes, projects and cases which are somewhere between the two. Therefore they need a balanced, unbiased view of projects, processes and cases that in essence are just different kinds of collaborative work. Projects, projects and cases have more in common than it may seem at the first glance: whatever approach is taken, there always is an initial state, resources and goals to be reached.

Yet it’s hard to be an expert in different knowledge areas. One can learn the theory but it takes years to become an experienced practitioner. That’s why it’s relatively easy for an organization to find a project or process experts but there is risk that they will overestimate the importance of one approach at the expense of the other. » read the rest

In the previous articles, we positioned Project Management and Process Management as systematic ways to compensate the issues of pure functional management: loss of control at handoffs, loss of focus on corporate goals, sub-optimization, etc. Let us now consider the tools (i.e. software) support for functional, project and process management.

Let’s start with the functional management. First, there are standalone applications – accounting, warehouse, product lifecycle management (PLM), advanced planning & scheduling (APS), etc. targeted to specific departments. Historically, these applications have appeared first as the earliest form of management was functional management. » read the rest

In the first article we described how the division of labor increases productivity of an individual employee yet, at the same time, creates a disconnect between departments reducing the company’s effectiveness.

These problems arise when the company grows. As long as the founder is in charge, and the number of employees is limited, the mutual understanding and motivation among managers is sufficient to limit “friction” to a minimum. Then, e.g. a new ambitious sales director comes onboard to reorganize the sales department.  The changes might be positive overall, but the former mutual understanding with the director of Manufacturing is no longer there, leading to tensions, that evolve in a search for a “scapegoat” in meetings with the CEO.

Another case: a business owner (who is also the CEO) decides that the business is finally standing firmly on its feet, and he can withdraw from the operational management and devote his life to surfing. In few months, the company plunges into a feudal disarray.

What options does the executive have in dealing with the coming disorder? » read the rest