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.

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

You’d simplify BPMN work and at the same time make resulting diagrams simpler and clearer by accepting the following assumptions:

1. All information is stored
2. Organization has a mechanism of tasks assignation and transfer
3. Every task is accompanied by appropriate instruction
4. Every task has standard duration and there is a way to control it

1. All information is stored

Don’t ask how and where process data (attributes) are stored. Just take for granted that there is some dedicated storage and you are able to handle it. » read the rest

Texts about BPMS tend to focus at first hand on business process notations and diagrams. User interfaces to process tasks and web portal functionality are usually next topics, followed by business rules and integration. Such topics as data modeling at the design phase and data manipulation during the process execution are often out of sight.

Yet process model and data model are the key aspects of any process application architecture. Therefore, process modeling and data modeling are equally important core competencies of a process engineer. » read the rest

A recent ebizQ question «What is the most important question to ask when starting a BPM project?» collected a record number of responses. Peter did not specify the role - which side asks the question? Since the majority of active participants (writers) are BPM vendors or consultants, they proposed the question as if they were asking a potential clients. The majority agreed that the most important questions are about the context, objectives and metrics of success of the BPM project and I totally agree with this.

But let us turned back to ourselves: what is the toughest question a potential customer can ask a BPM vendor?

For me, the most difficult question is “Where is the money?”

» read the rest

Not a Process Yet

Following up the previous post - may we call a business processes things like “Oil Mining” or “New Product Promotion?”

Once again, the answer depends on the context. In BPMN they aren’t business processes, definitely. From BPMN perspective business process is a specific sequence of actions initiated by a specific event and ended by some specific result.

» read the rest

Everyone knows what a business process is. Yet it’s difficult to find two people agreeing on the term. Should they look in a book for the definition? But there are are dozens of different definitions.

We must face the fact that there is no universally-accepted definition of a business process and probably newer will be. Hence it’s no use to develop the true definition and I won’t do that. I’ll try instead to explain what do I mean by the term “business process”.

» read the rest

If you’re working with on a complex enough business process then at some point the process diagram will become bloated and unreadable. This means it’s time to make hierarchical decomposition - in simple words, split the process to subprocesses. The old rule of having 5 to 9 activities per level is fully applicable to BPMN.

Let’s consider the contract process with three phases:

1. Agree essential terms of the contract
2. Agree the contract text
3. Authorize the contract

Naive process diagrams like the following aren’t rare:

» read the rest

Unfortunately, the question “how to model human decisions in BPMN” isn’t frequently asked.

“Unfortunately” because the intuitive answer is wrong. This is not a fork but a parallel execution:

After exiting the “Approve Claim” task the process will continue in parallel on the outgoing flows whatever is written on them.

Valid BPMN diagram looks like this:

It’s implied that the process has a boolean attribute “Approved”. User sets this attribute at the “Approve Claim” task, the gateway checks its value and the process continues in one of the flows.

As you can see, BPMN authors didn’t provide a special construct for human decisions but implemented them rather artificially: a special attribute that must be set by a human and checked in the gateway immediately after.

The user interface for the task where the decision is made may look like this:

When “Done” button form is pressed the task is completed.

I agree with Keith Swenson that BPMN misses explicit support of human routings.

Firstly, human-based and automatic routings look alike at a diagram. Yet this is an important aspect of the process.

If it was my decision I’d introduce explicit support of human routing into BPMN. Since first diagram above is actually more intuitive than valid BPMN, I’d leverage on it:

The existing flow types - Control Flow, Conditional Flow and Uncontrolled Flow - are extended by Human Controlled Flow here, marked with a double dash.

Another issue are screen forms like the one above which provoke user mistakes: it’s tempting to press “Done” and get rid of the task without paying attention to the attributes.

If a decision is requested from a human then the form should look like this:

The buttons could be generated automatically from the process diagram above.

Yet it’s possible to utilize this technique for standard BPMN, too:

“Done” button is replaced by “Approve” and “Deny” here, each of them being bound to two actions: set the attribute value and complete the task.

Now I’m going to use this occasion to appeal to BPMS vendors: please give the opportunity to create more than one button completing the task and bind them to attributes. If you didn’t do it yet, of course.

While talking with a client yesterday I failed to articulate clearly the difference between templates and patterns.

In fact, they represent two methods of problem solving:

• A template is a standard solution for a certain type of tasks. E.g. when I’m going to conclude a partnership agreement I pick up the appropriate template and it becomes a zero version of the document.
• A pattern prinicipally is a standard solution too, but it is used creatively on the basis of a “problem shape” rather than problem’s formal type. Unlike templates, patterns may come with a positive (”how to do”) or negative sign (”how better not to do”).

Vague enough, right? Trying to make it simple, I found an analogy in chess:

• Debuts are templates: learn them and use them, chessbooks plot the game 20 moves ahead from the initial position.
• Typical combinations of the middle game are patterns. E.g. fork is a pattern: if you can see an opportuntiy then use it or threaten to do so. Two rooks on the same vertical is a pattern too while two pawns is an antipattern: try to avoid such a position if possible. But no chessbook contains instructions how to make a fork starting from the initial position.

With regard to business processes, sometimes a business process model is called a process template. Process instances are created from templates about the same way as zero version of the document in the example above.

The second meaning of the term “template” is a typical, standard process model. A vendor or consultant develops a process model on the basis of previous experience and then offers it to prospective customers. Supposedly the customer will be able to use it with small customization, saving efforts in comparison with a development from scratch.

For example, my company Business Console successfully implemented a BPM solution targeting a sales process executed through geographically distributed offices and now we offer it as a template, i.e. a starting point of a BPM project to companies that manufacture and install plastic windows, metal doors, custom-made furniture etc.

Pattern in BPM is a typical process fragment of typical way of communication between processes (some examples).

One may ask: which one is more usefull? My opinion it’s a pattern:

• Templates are specific (one process - one template), patterns are universal. A good pattern can be used in a variety of business processes regardless of the industry.
• A practical benefit of using a template may be less than expected. It usually covers the happy path only and the devil is in details - various workarounds, escalations and exceptions.
• The effect of using the right pattern can be large. For example, there was a case in our practice when the process plotted at 6 A4 sheets glued side-by-side was reduced to the elegant design with just 15 activities by using the right pattern.
• The value of the antipattern is its ability to preserve you from mistakes. The price of a mistake is unlimited in theory and sometimes it’s really big in practice.

Another reason of my skepticism towards templates is the fact that in case of BPM we are targeting continuous improvement, not one-time automation. Templates, by definition, can be applied only once: during initial modeling. The ability to use patterns will remain open forever. It’s quite possible that after discovering a new pattern you will look at the processes you designed from a different perspective and will find a way to improve and/or simplify them.