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 BPPMN 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

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

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