This pattern is less common than e.g. «Internal Order» yet it’s used quite often - probably once per each two BPMN classes.

Examples:

• Purchase by Tender
• Competitive Hiring

Simplified diagram depicts the essence of the pattern: » read the rest

In the previous post we considered a message from external entity that needs to be processed to determine which process instance it should be routed to. But at least there were no incertainity about which process template (process type) the message corresponds: client requests a credit card from a clerk (credit card issuance process),  CV arrives to Human Resources (enrollment process), payment notification reaches Finance (sales process).

Now let’s consider more complicated case: documents arrive to the company’s post address by traditional mail. They don’t reach process participant’s desk directly but go to the general administration office. » read the rest

Let’s consider the credit card issuance process:

Fig. 1. Credit card issuance with a “passive” task “Issue card”.

Business scenario: after the card is manufactured, the client must come to the bank branch within 45 days and request it. Now look at the task “Issue card”: if the average client comes in for the card after 10 days and the branch issues 100 cards per day then 1000 of these tasks will queue into bank clerk’s task list. » 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

Definition 1: Orchestration - a diagram depicting a sequence of activities coordinated from a single center of control.

Notes:

• Synonyms to orchestration are workflow and, in fact, process.
• Orchestration is modeled by a white-box pool in BPMN; it may also contain optionally black-box pools presenting external entities.
• The phrase “coordinated from a single center of control” means that even if a process diverges at some point, the branches remain coordinated e.g. they can be synchronized later in a converging fork; the whole process will end when all branches are completed.

Definition 2: Collaboration - a diagram showing interactions between processes.

Notes:

• In BPMN 1.x interprocess communication was called choreography. In BPMN 2.0 choreography is reserved for a totally new type of diagram - what used to be a choreography in BPMN 1.x is called collaboration now. So it goes.
• A collaboration diagram contains more than one white-box pool.
• Some people reduce collaboration to the exchange of messages but generally speaking, processes may communicate via messages, signals and/or data (data store, conditional event).
• Processes on a collaboration diagram are executed independently except specific sync points where messages and signals are sent/received, data read/written.

The big BPMN advantage is its support of collaboration as well as orchestration. This is also a key criterion for choosing a BPMS. Yet as my BPMN training shows, the right balance between orchestration and collaboration is tricky.

There are two common pitfalls:

1. At a first approach to BPMN analysts try to do the job with orchestration only. Yet it works only for very simple processes like vacation request. Cross-functional processes that are of greatest interest for the business are multi-threaded by nature and hence can’t be modeled within orchestration.
2. After getting acquainted with messages and learning that they can only be used between pools, many analysts introduce unnecessary pools into their diagrams. For example they love to use pools and messages where a subprocess would suffice:

Fig.1 Process antipattern: “Messaging instead of subprocess”

The common arguments in favor of this scheme:

• “This process is performed by another entity.” - Use swimlanes not pools to show a performer.
• “The process can be called from several points.” - So do reusable subprocesses.
• “The link between the caller and the calling process becomes visible.” - First of all, expanded subprocesses are transparent, too:

Fig.2 Expanded subprocess

• Secondly, for a well-structured diagram with properly separated abstraction levels collapsed subprocesses are sufficient: when we look at the process top-level, we must understand its logic without knowing the details of subprocesses. The subprocess contents shaill be presented on a separate page:

Fig.3 Collapsed subprocess

It’s a matter of style rather than correctness - the diagram in Figure 1 is formally correct. Yet I recon it’s an antipattern and inventing a wheel because messages are used to model a behaviour witch is already built-in into subprocess invocation:

• when a control flow reaches a subprocess a token emerges with a subprocess and the caller goes into a wait state
• when the subprocess completes the caller continues

In summary, here are my rules for the optimal balance between orchestration and collaboration:

Rule 1. If your attempts to model a process are unsuccessful because some significant aspects are missed repeatedly then stop and think - maybe in fact it’s not a single process but two or more?

Rule 2. Do not overuse collaboration - stay within the orchestration as long as possible. Never introduce collaboration into a diagram just because you’ve recently learned how to do that.

In the following article I’ll share my experience of identifying independent processes during analysis.

Ivo Velitchkov made me pay attention to the difference between BPMN 1.x и BPMN 2.0 in respect to data flow modeling.

Data exchange in BPMN 1.x is modeled with Data Objects:

Fig. 1 Data Objects in BPMN 1.x

BPMN 1.x Data Object is an artifact used to inform what a process does. With the help of Association it may be linked to a Task, Control Flow or Message Flow yet it won’t directly affect any of them.

Data Objects can model a range of physical or electronic objects. We may for example drop a Data Object outside a pool and label it “Orders Database” in order to model interprocess communications via data.

Yet as Ivo rightfully pointed out the diagram depicted above becomes illegal under BPMN 2.0!

The point is that Data Object is associated with a process context in BPMN 2.0: it is drawn within a process (subprocess) boundary and it only exists from a process (subprocess) instance start to end. Therefore it can’t be accessed from the external process.

Persistent data not tied to a process lifecycle are modeled with Data Store, so this element should be used to model interprocess communication via data in BPMN 2.0:

Fig. 2. Data Objects and Data Stores in BPMN 2.0

As a side note, BPMN 2.0 makes a difference between single-item data objects and collections - the latter carry a special marker. It also introduces special markers for Data Inputs and Data Outputs and new elements - Input Sets and Output Sets.

BPMN 2.0 also defines Data Association in addition to the general Association inherited from 1.x. While general Association serves documenting purposes only, the Data Association is “executable”: one may define source, target and optionally transformation at the model attribute level. One may define right at the model the data manipulations that should be performed at activity start and end, message send and receive. Visual representation remains the same: dotted line with V-shaped arrow.

BPMN 2.0 specification is slightly controversial with respect to Data Association:

• P.221 says that Data Association is used with Data Objects without mention of Data Stores. Since Data Objects always belong to a process, one may conclude that Data Associations should never cross a pool border. This rule would make the second diagram illegal - please refer to Ivo Velitchkov’s comment.
• Yet p.208 says clearly that Data Store may serve as input or output for a Data Association.

So I believe that the diagram at fig.2 is valid.

Besides, even if you or your tool has objections against using Data Associations with Data Stores then you still can use plain old Associations that look exactly the same.

This is third and last part of a study on managing cross-functional business process. Previous parts:

1. Vulgar Interpretation of Cross-Functional Business Processes
2. Cross-Functional Patterns

In the second part we introduced two basic ways to organize work within cross-functional business processes:

• Synchronous - the performing unit starts work as soon as it received an internal order. Technically it’s implemented by a single process.
• Asynchronous - orders are first accumulated in the input buffer unit of the performing unit, then extracted and processed with some frequency. Technically it’s implemented by two (when there is a single resource) or larger number of processes.

Synchronous mode grants minimal process execution time while asynchronous maximizes the performance (measured by the number of process instances completed per unit of time).

According to my observations asynchronous mode prevails in real life because departments and people both feel more comfortable when they are not chased by a continuous flow of a variety of tasks but have an opportunity to somehow organize and plan their activities.

Business and process analysts prefer synchronous schemes - not with something special in mind but because they just follow the path of least resistance: these schemes are plain simpler. This may lead to conflicts at the process implementation: people are pushed into the process framework which they feel uncomfortable.

Now if we look at it from the organization’s goals perspective (i.e. process performance) then the synchronous scheme is preferred because it provides the highest quality of customer service. A performer may not feel comfortable but it doesn’t matter on the condition that he/she isn’t overloaded (which does not happen as often as it may seem). Improving an individual’s performance may be a sub-optimization which is a bad word.

How can we bring these views together? I’m going to give some recommendation about optimal process schemes

» read the rest

It’s time to pay the debts - returning to cross-functional processes modeling as promised.

Remindment: the first part stated that it’s usually impossible to implement cross-functional processes by orchestration only (i.e. within a single BPMN pool). The borders betwen departments are material, they mark differences in manner and rhytm of different kinds of work. Because of these differences the fragments of a process belonging to each department are technically implemented by separate pools while the cross-functional process as a whole is implemented by a set of such pools communicating via messages and data.

In this article we’ll consider common cross-functional process patterns.

Let’s use the following example:

Under routine financial planning all bills received by a company are processed by the finance department first: they determine validity of the claim, check the amount and date, assign priority in accordance with established business rules. Then the bill is submitted for approval to CFO or some other manager who makes a decision about payment taking into account priority, amount and term.

The simplest process diagram may look like this:

» 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.

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