Disclaimer: bits of ads below.

When we launched bpms.ru in 2005 and when participated in first BPM conferences in 2006, there were just a handful of BPM offerings in Russia.

Now BPM has become an acknowledged brand; about a dozen of vendors actively promote it in Russia and several dozens offer consulting. Many of them have qualification, references and competence to fulfill a BPM project smoothly. Model a process, develop data model and screen forms, add business rules, org structure, integration, BAM and that’s it: the process application is ready.

But the major issues of BPM projects are not in development and not IT-related whatsoever. Two issues are common for discussions at conferences, customers’ sites and online forums: 1) how to gain measurable benefits from BPM and 2) how to ensure that BPM would be part of organization’s culture and not a one-time project.

How to get benefits from BPM project?

The question is often raised as how to sell BPM within the organization. The project sponsor isn’t willing to share the enthusiasm until being explained how the project success will improve the company’s balance sheet bottom line.

» read the rest

It’s no secret that different people call BPM very different things. Some people call BPM the good old reengineering with its «as-is» and «to-be», others put BPM label on documenting business processes and/or quality management initiatives, the third believe that business process automation within ERP is BPM too, the fourth equate BPM with BPMS purchasing and implementation, fifth do BPM with ECM-embedded workflow, etc.

I personally join those who treat BPM in the spirit of Smith and Fingar’s «Business Process Management: The Third Wave» - as a coherent discipline comprising methodology, technology (BPMS) and (I add on my own) agile implementation. Qualifying BPM features for me are 1) closed loop management of business processes and 2) bridging the gap between business and IT. I dislike the idea of introducing a new term to label practices already existed for a decade. (BPM acronym spread widely since 2003 while re-engineering exists since the early 90s and the quality management ideas apply to the 80s.)

BPM in the broad and narrow sense

So we have two basic BPM interpretations:

1. BPM in the broad sense, or business process management, or BPM as an umbrella concept - whatever methods or technologies dealing with business processes
2. BPM in the narrow sense, or Business Process Management - a specific holistic discipline (methodology plus technology plus implementation) established in the first decade of XXI century.

Some time ago Alexander Samarin proposed to develop a commonly agreed BPM definition. Sadly enough, the commonly agreed definition cannot be worked out, it can only emerge. It’s hard to reach consensus because at the end of the day each vendor and consultant claims that BPM is what his organization does. BPM is a strong brand nowadays.

This state of affairs isn’t favorable to BPM market indeed (in any interpretation of the term). What the potential BPM project sponsor should think about this range of opinions? “If you’re so smart and pretend to teach me then why can’t you agree on basic definitions with each other?”

Sometimes it generates fun: a participant of a recent bpms.ru seminar representing major Russian insurance company insisted that his company doesn’t do BPM while other participants urged him it does, appealing to his own words. So what is BPM anyway if we can’t even say for sure whether we are doing it in our own company?

I believe we should accept that there is no and won’t ever be a single interpretation of BPM, period.  Incidentally, there is no and won’t be a single interpretation of the term “business process”. Consequently, anyone who wants to speak on these topics, request or offer a service in this area must begin with a definition: what he/she personally calls BPM and what he/she calls a business process. At a minimum, the responsible professional should clarify whether he/she follows a broad or narrow-sense definition of BPM.

But it’s better to position ourselves more precisely.

A three-level BPM classification

Gartner’s BPM Maturity Model can be used as a starting point for BPM classification.

In 2006 Gartner proposed a 6-level (zero to five) BPM maturity model that I dare to summarize as follows:

• Phase 0. Functional management. Organization has yet to realize that its performance as a whole depends not only on how certain functions are performed, but also on how well these functions coordinate with each other, i.e. the quality of business processes interconnecting them.
• Phase 1. Business processes awareness. The organization explores itself through the prism of business processes. End-to-end business processes are discovered and process owners are appointed. Everyone draw process diagrams. Gaps and bottlenecks are identified and eliminated, without investments into processes automation (BPMS).
• Phase 2. Automated execution and control of business processes. The organization learns to manage business processes in a continuous loop model - execute - analyze and seeks to improve their effectiveness, mostly on a separate processes basis.
• Phase 3. Execution and control of end-to end business processes. Process boundaries are expanded under the control of BPMS, inter-process communications are worked out and end-to-end processes are established connecting the company to its customers/partners and/or their business processes.
• Phase 4. Explicit and automatic link between business goals and business processes. With the help of simulation and dynamic business rules, business goals changes trigger automatic rebuilding the network of business processes.
• Phase 5. Adaptive business structure. The ability to quickly react to changing business environment, anticipate these changes and create opportunities through deeper integration into various markets and partner ecosystems.

The last two phases, I would attribute to science fiction category. Guess nobody has seen them in reality by now, including Gartner analysts. Phase zero isn’t a process phase really, so three phases remains:

BPM-1: Business processes description and modeling

BPM-2: Managing separate business processes

BPM-3: Managing end-to-end business processes networks

Well this is a working set. The original Gartners’s model is so cumbersome and expressed in such a language that I personally am unable to explain it to an ordinary businessman.

We may further define sub-levels:

• BPM-1starts with text process descriptions, a more advanced version is graphical process modeling capable to generate text description automatically and a single repository of business processes.
• BPM-2 doesn’t always implement continuous improvement cycle, in many cases it is reduced to one-time process automation.

If both clients and vendors/consultants referred to classification above while specifying their demands and offerings respectively, then it would contribute to better mutual understanding. E.g. a customer could describe itself as follows:

We are now at BPM-1 level using text descriptions mostly. In order to pass ISO9000 certification on a regular basis, we need full BPM-1 competence on our own, with graphical models and a single process repository.

We need an external consultant with proven industry expertise and BPM-2 qualification for supporting processes in human resources area.

We need an external consultant with BPM-3 qualification for “Order-to-Cash” operational processes. In addition to the process work, it should help us create a competence center that would do 80% of the work after 12 months.

After that it could select consulting companies capable at BPM-1, BPM-2 and BPM-3, and have a close look to the toolbox:

• BPM-1 requires a process modeler/designer, Enterprise Architecture tool would also be handy
• BPM-2 can be supported by a workflow engine built-in into ECM or CRM
• BPM-3 requires a full-scale BPMS, it can be used for BPM-1 and BPM-2 tasks, too

One should not look at this classification in such a way that the levels are always better than lower ones and that we should put all efforts in advancing to higher levels for all our processes. Gartner’s model produces exactly this view and I believe it’s wrong.

The key words are “for all processes.” Trying to evenly raise the maturity of all processes is a recipe for disaster. In accordance with Pareto’s law, 20% of processes are responsible for 80% of the company’s performance. Wouldn’t it be wiser to focus on these 20%?

Sure the BPM-3 grants much more control over the processes than BPM-1. But it’s much more expensive as well! Complete BPMS implementation of an end-to-end business process is a custom IT development, apart from other considerations. And cheap custom IT development just doesn’t happen.

BPM-3 consultant can achieve more tight control over a business process yet it doesn’t entitle him to look down on BPM-1 colleagues because he/she can achieve the results in a relatively narrow front while their scope is much wider albeit maybe not so deep.

My second complaint about Gartner’s maturity model: it produces such a view phases should be passed successively, step by step. Not necessarily!

An organization infected with process management ideas may set itself a goal to get from zero to third BPM phase. OK, it’ll take time to gain the necessary competence and finally do the job but anyway the intermediate stops at levels 1 and 2 are not required.

BPMN as a common ground

Everything relating to business processes is fundamentally volatile. For example, we must be ready that in six months we come to the conclusion that some process for which we believed BPM-1 is sufficient from now on requires BPM-3. Of course we’d like investments into BPM-1 to be preserved during the transition to BPM-3.

The recipe is simple: leverage BPMN.

BPMN is methodologically neutral - in other words, it can be used in very different ways for very different purposes.

• BPM-1 requires minimum BPMN to draw analytical process diagrams
• BPM-2 requires BPMN orchestration
• BPM-3 requires full BPMN palette, including messages, signals, events, transaction subprocesses etc.

There will be certain degree of compatibility between diagrams, so transforming BPM-1 analytical BPMN diagram into BPM-2 executable BPMN diagram would be easier and much more robust than, say, producing BPMN from IDEF0. There is no real alternative to BPMN at BPM-3 so better keep with it at all levels.

The final note: we (Business Console) provides BPM-3 consultancy.

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

Lanes (known as swimlanes in BPMN 1.x) represent process performers in BPMN.

Rules for the lanes:

1. Lanes are optional.
2. Lanes may be nested (hierarchical).
3. Lanes semantics is fully at the discretion of the diagram’s author - it may be a function, role, position…
4. Embedded subprocesses do not have pools and therefore can’t have lanes.
5. Lanes are meaningful only to the user tasks - service tasks, script tasks, subprocesses, gateways, events are irrelevant to which lane you put them in.
6. Even for the user tasks the lane is essentially a comment - actual performer is defined by the model attributes of the given task.

Novice BPMN users love lanes and use them at first excercises with enthusiasm:

Figure 1. BPMN diagram with lanes.

However using lanes won’t allow showing the process “happy path” which arguably is more valuable from ease of perception standpoint:

Figure 2. BPMN diagram with a happy path.

Moreover, when dealing with large processes there is no room for lanes at all.

There is a general rule applicable to any notation including BPMN: the number of activities at any diagram level should not exceed 7-9. Otherwise the scheme becomes too difficult to perceive:

Figure 3. “Flat” diagram with a large number of activities is hard to understand.

Accordingly, if the process comprises a large number of tasks, it should be decomposed into subprocesses:

Figure 4. Subprocesses help creating a simple diagram from a complex process.

But this style of modeling leaves no room for lanes:

• At the top level there are only subprocesses while lanes apply only to the user tasks (rule 5).
• Subprocess diagram doesn’t allow pools nor lanes (rule 4).

More precisely, rule 4 applies only to the embedded processes; reusable subprocesses may have lanes. I’ve seen diagrams where reusable subprocesses where used instead of embedded solely to be able to depict lanes. This is definitely bad practice - embedded subprocesses shall be used for the decomposition. Reusable subprocesses introduce additional complexity because unlike embedded they are executed in a separate data context.

If you can’t live without diagramming performers then use BPMN artifact “group”:

Figure 5. BPMN groups shows performers within the embedded subprocess.

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

We at Business Console decided not to offer PoCs any more.

Let me explain why first and then what’s instead. » 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.

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