Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Posts Tagged ‘BPMN’

BPMN, DFD Style: Illegal Yet Practical

It was stated in the previous article that from BPMN perspective the top level process analysis deals with process families rather than processes.

Unfortunately BPMN doesn’t provide tools for modeling such things. Analysts resort to IDEF0 most often, I prefer DFD - but anyway it’s no good that we have to use two notations.

So I draw DFD diagrams with BPMN palette. It looks like this:

» read the rest

05/21/12 | Articles |     Comments: 4

Not a Process Yet / Not a Process Any Longer

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

05/15/12 | Articles | ,     Comments: 9

(Русский) Семинар в Киеве 19.04.2012

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

03/13/12 | News | , , ,     Comments: 4

Process Pattern: Tender

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

12/01/11 | Articles | ,     Comments: 2

«Process Discovery and Modeling Done Right»: my podcast with ebizQ

My activities in BPMN got me a reputation of an expert in process modeling. Let it be so; yet I believe it’s rather the basics of the craft than its top and personally I’m more interested in issues arising at BPM and performance consulting intersection and business process BPMS implementation methodology. It’s a common story: the public is more attracted to what an expert considers almost trivial while what he treats as an achievement may come unnoticed. As an example, the most popular posts at this blog are those tagged “FAQ”.

ebizQ editor Piter Schooff recorded a podcast effectively presenting me as a «modeling guy». OK, if Peter believes modeling is a good topic right now then I’m not going to argue. The podcast is published at ebizQ: «Process discovery and modeling done right» (transcript).

Correcton: page 3 of the transcript reads -

PS: What are some best practices for effective process modeling?

AB: You might notice from my blog that I’m a proponent of process patterns. Pattern is a typical process fragment common to a number of real world processes. And the matching word for “pattern” is “recognition.” With an adequate training and some practice, a process analyst just sees familiar patterns in the process task he is working on. And this way, he or she gets the results much faster, [but] they’re more error-prone because they are based on proven fragments or patterns.

Of course I meant “less error-prone” here.

This was my second podcast at ebizQ. Prevoious podcast: «Avoiding BPM done wrong» (transcript).

08/19/11 | Others | ,     Comments: 4

Serious BPM Consulting

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

07/29/11 | Articles | ,     Comments: 5

How Many BPM Flavors Do We Need?

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.

07/22/11 | Articles | ,     Comments: 16

Process Pattern: Post Office

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

07/07/11 | Articles | , ,     Comments: 12

Process Pattern: Incoming Processor

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

07/01/11 | Articles | ,     Comments: 63

Limited Usability of BPMN Lanes

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.

06/27/11 | Articles | ,     Comments: 32

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