Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Posts Tagged ‘BPMN’

Message Flows, Events And Tasks

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:

01/19/17 | Articles |     Comments: 6

Human-Powered BPMN

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.

01/10/17 | Articles |     Comments: 9

Process Patterns: Plan-Execute (Four Different Ones)

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

07/20/15 | Articles | ,     Comments: 4

What Is a BPMN Process (And What Is Not)

The term “process” has different meanings depending on the context, confusing BPMN beginners. This brief note should help.

1. BPMN process is repeatable

E.g. “Company closure” is not a process because it may be executed only once. (Of course if you do not provide liquidation services for others. )

2 . BPMN process is predictable

A process may take different paths depending on data or events, it may run in parallel etc., but it is assumed that we know all the gateways in advance - not at the execution but at design time.

This is a strong assumption that doesn’t match everything we call processes in everyday life. For example it’s hardly possible to predict the route of patient’s treatment at the hospital from his admission to the emergency room. The same applies to a case in court: the opposing party may submit a document that will turn the course of the process by 180 degrees from what we’ve planned in advance.

Such unpredictable scenarios should be treated as projects or cases depending on the context.

3 . BPMN process is non-trivial

If a it can’t be decomposed into tasks then it’s not a process. A process is a set of related tasks and/or sub-processes i.e. it’s not atomic.

A subprocess is non-atomic too. The difference between a process and a subprocess is that a process is associated with external events (it responds to an event at start and initiates an event at completion) whle a subprocess is triggered not by an external event but simply by a control flow in the parent process or subprocess.

4 . BPMN process is concrete

A BPMN process has a well-defined start event, a predetermined flow of actions and defined set of completion states.

“Budget process”, by contrast, isn’t a BPMN process. From BPMN perspective it’s a set of related processes (e.g. “Budget approval”, “Budget execution reporting”) plus tasks belonging to processes from other domains like “Check budget availability” in the “Purchasing” process.

Similarly, “Promotion process” isn’t a process but a family of related processes in terms of BPMN. “Manage something” probably stands for a process family, too.

5 . BPMN process is discrete

If there is a flow in your process that returns it to the very beginning e.g. after an approval task then consider an altenative option - to end the process with a negative status having in mind that another instance may be started any time.

E.g. if a hiring process didn’t succeed then it’s better to end it with appropriate status than to loop. It can be started over again, probably with different input (with a more generous salary offered).

It’s better in terms of monitoring and analysis: we honestly admit that the process is not always successful. The process duration data becomes more trustable, too.

6. BPMN process inputs and outputs are primarily events

The common view of a process is something processing inputs into outputs - here inputs and outputs are resources.

BPMN processes are different: they respond to inputs and generates outputs, i.e. inputs and outputs are  events. I’ts also possible to model input and output resources in BPMN but these are optional while start and end events are obligatory.

Process start is a handler of some external event, process end initiates an event in the external environment. A particular but quite common case is “none start” (free will) event and “none end” event that produces no effect to the environment.

7. BPMN process is the story of an object, not of a subject

Do not attempt to use BPMN for things like “employee’s working day”.

The right approach is to model processes like “Client’s order end-to-end”.

8. BPMN process is not completed until all the work is done

BPMN process starts when someone is willing to initiate a certain sequence of activities or when an external event (e.g. a client’s order arrived) triggers it and it doesn’t end until the very end, i.e. while there are things to do (e.g. a customers service called a buyer after shipment) .

“Here the sales process ends and accounting process begins” is a bad idea - it’s a single cross-functional process, not two separate ones.

9. BPMN process is customer-oriented

Treat a process as end-to-end, ruled not by business units boundaries but by the customer’s view (external customer’s, ideally): start from the customer’s request and continue until valueable result is delivered.

Switching from traditional “inside-out” view isn’t easy so use the following method: instead of modeling the saless process consider the process of buying by your customer; the process of submitting a complaint and obtaining response instead of internal complaint processing and so on. Find out what is the optimal process from the customer’s perspective.

Internal consideration’s should be taken into account at some stage of process design too but it’s better to start from the customer’s view of the process.

10. BPMN process is macro-, not micromanagement

It’s possible to use BPMN for detailed regulation of a single workplace activities but it’s not why we love it. If employees are not trained then it’s a problem indeed but it’s a functional rather than process problem. And there are many solutions for it apart from BPMN.

The process problem is this: employees are functionally competent (i.e. are able to do their jobs) but the whole process is complicated as it requires precise coordination of efforts of business units separated by the hierarchy and geographically. The responsibility for the handoffs and for the end result is unclear, resulting in poor overall performance.

BPMN is the tool of choise for this kind of problems because it makes the interaction between participants explicit and equally clear for all stakeholders - top management, business units and “process engineers” (including IT) responsible for the process implementation.

04/04/14 | Articles | ,     Comments: 15

Live Process Analysis & Modeling Experience

It ain’t a classic blog post but rather a rolling-out story. No one knows how it will go neither who is the killer :)

The reader of this blog Crisitan submitted a comment asking how to model “state machine”-like processes:

Here is my made-up story: we are trying to model and implement a computerized system for handling the lifecycle of some licence obeying the rules below.

The Ministry of Energy of some country issues licences for oil exploration and production to applying oil companies. Oil companies must get a licence before they may legally produce or explore for oil in that country. When companies get a licence from ministry, they are said to own the licence. In order to get the licence, a company must first apply for it via ministry. Any licence application gets reviewed by ministry staff and, if application is approved, it results in the issuance of the licence. A licence has an Issue Date and an Expiry Date. Every time Expiry Date is moved forward, it does so at most one year at a time, but it may be moved forward repeatedly thru the Renew Licence function of the system.

» read the rest

11/11/13 | Articles | ,     Comments: 51

Process Pattern: “Find a Victim”

Depicting process interactions with external stakeholders is a standard stumbling block for BPMN newcomers.

A typical example:

Fig.1

There are a whole bunch of errors: » read the rest

08/17/13 | Articles | ,     Comments: 17

Tell The Story

Occasionally I get BPMN diagrams like this:

Payment process BPMN diagram, incorrect

This is the “Payment process” composed of interacting “Accounting department process”, “Business unit finance department process” and “Corporate finance department process.” » read the rest

07/15/13 | Articles |     Comments: 13

Command vs. Respond

Question #1 of BPMN-based process analysis: what are we going to do - Command or Respond?

  • Command means using orchestration only, i.e. model within a single BPMN pool.
  • Respond means providing handlers for events raised by external entities (clients, partners, government agencies), internal services and/or enterprise software systems.

» read the rest

02/05/13 | Articles | ,     Comments: 7

Another Warning About BPMN Message

A process A sends BPMN message to a process B. What if A sent the message before B has become ready to receive it, i.e. before a token arrived to B2?

» read the rest

01/22/13 | Articles |     Comments: 7

Robots Don’t Talk To Humans

It’s common to see BPMN diagrams using send tasks to illustrate that we send documents to external entity and receive tasks to model obtaining an answer. Or (which is practically the same) using send message and receive message events for these purposes. » read the rest

01/07/13 | Articles | ,     Comments: 84

Copyright © 2008-2017 Anatoly Belychook. Thanks to Wordpress and Yahoo.  Content  Comments