Better process discovery and modeling lead to better BPM

Editor's note: In this Q & A, ebizQ's Peter Schooff talks with consultant Anatoly Belychook about trends in and best practices for process discovery and modeling. Belychook, a frequent contributor to the ebizQ Forum, is president of Business Console, a BPM consultancy based in Moscow. Schooff opens the conversation, excerpted from a longer podcast, by asking Belychook to describe the system of levels, or classifications, that he has developed for BPM.



AB: BPM Level 1 is pure modeling and documentation. Then, BPM Level 2 is automation of isolated processes, also known as workflows. And BPM Level 3 is closed-loop management of the network of processes comprising an end-to-end process. We may also add Level 0 here for processes that are executed informally—"under the carpet," so to speak.

This classification system resembles the well-known Gartner [BPM maturity] model; it corresponds to the first three levels of Gartner's model. But I believe it’s a little simpler and easier to articulate.

Another difference is the concept of "multi-speed" BPM behind this classification. Even if an organization has reached Level 3 of BPM, that doesn't mean it applies the Level 3 methods and technologies to all its processes. No, it just means that it can take any process it wishes to Level 3, but the majority of processes would still be managed at Level 2, 1 or even Level 0. The level of BPM is about capability, not about the actual implementation.

PS: Now to drill down: What do you see as the current state in the enterprise of process discovery and modeling?

AB: It's a very, very interesting moment just now, as BPMN [Business Process Modeling Notation] becomes mainstream quite rapidly. We can see this from the growing number of customer requests for BPMN. We can see this from the growing number of orders for BPMN training.

And we can see that BPMN drives many organizations to rejuvenate their process efforts. Some organizations are thinking about reshaping their existing diagrams and models into BPMN. Some others are considering executable BPMN, which is a new and refreshing idea for many of them, and this is the way right to reach BPM Level 3.

I believe it's a huge step for all the BPM industry. Actually, we all owe the [BPMN committee of the Object Management Group, a standards organization] for reaching consensus on and publishing the BPMN 2.0 standard. It's not perfect, maybe, but that doesn’t matter. The point is, we can see that a universally accepted standard was born—and that doesn't happen so often in our industry.

I believe this year will become an important milestone for BPMN.

One more point: If we go back to the concept of multi-speed BPM that I just described, BPMN has a big advantage here. It provides a smooth path from the bottom levels to top levels. One may start by drawing some simplistic, analytical kind of BPMN models using just a handful of BPMN elements. Pretty simple, pretty straightforward. It doesn't require some kind of training; it can be embraced very rapidly. But it opens the way to reach whatever level you want to reach, including Level 3. You just extend your BPMN palette, make the process model more complicated, more solidly describing the process. This is a great thing. Other competing process notations cannot take you this way, so it's a big advantage.

PS: How important is it to get the "as-is" view of processes, and what's the best way to do this?

AB: There are basically two views of the matter. [One view holds that, obviously,] optimization is the key. But, in reality, there's always a choice: Either we start with optimization and implement the optimized version of the process. Or we take top-level control over the process first, and then improve it, optimize it in one step [or] in many steps as we wish. I believe that the [best] BPM way is the second option. We always follow this path and, hence, the as-is process is starting point of our BPM projects.

Regarding process discovery: There are old and well-known and proven techniques like interviewing stakeholders or tracing a process by sitting shoulder-by-shoulder with a process participant. They all work well. But the best way to discover process, from our experience, is [via] a short cycle that includes modeling, executing the process in the test environment within the [business process management suite (BPMS)]—we call it "verification"—and then fixing process issues found here and there in the model.

Modern BPMSs are so good in prototyping that this cycle can be round-tripped in hours, if not minutes. It's amazing how efficient this way to discover process is.

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.

I'm not talking here about elementary sets of patterns developed to evaluate process engines. This is about high-level and more business-oriented patterns [such as those in resource planning].

It's common today to compare patterns vs. templates. My personal opinion is that templates are less useful because the ones I've seen are about auxiliary processes that don't really affect business. Nobody makes their core business processes publicly available.

Another key modeling technique is process decomposition. Once again, it's a specific vision and a specific mindset that any process analyst must develop. It’s an ability to see levels of abstractions and the technical knowledge of how to isolate these levels in BPMN sub-processes.

PS: What are some of the biggest mistakes you see companies make with process discovery and modeling?

AB: One of the biggest, yet very common, mistakes could be called "putting the process functionality first." The right way is to start with business issues, then proceed with process issues, and then get to process functionality as the third step. So you start with communicating about what the current business goals are, then you identify the business processes that are responsible for reaching these goals. You set the targets for these processes. Only then do you proceed to desired process functionality.

Unfortunately, way too often, people and organizations jump right to process functionality. Most people don’t realize how dramatically the process architecture and the final process scheme depend on the particular business goals they set up.

So if business goals are used as the cornerstone of the development process or the analysis process, then more control, more monitoring, more escalations are implemented in the process. Otherwise, if you just jump into process functionality and start from this point, then the process tends to be overloaded with micromanagement. The cross-functional issues remain out of scope and aren't addressed. I believe this is the biggest mistake that can be made.

This Q & A was excerpted from a more in-depth ebizQ podcast on process discovery and modeling. It has been edited for length, clarity and editorial style.

About the Author

Peter Schooff is a former contributing editor for ebizQ, where he also managed the ebizQ Forum for several years. Previously, Peter managed the database operations for a major cigar company, served as writer/editor of an early Internet entertainment site and developed a computer accounting system for several retail stores. Peter can be reached at pschooff@techtarget.com.

More by Peter Schooff

About ebizQ

ebizQ is the insider’s guide to next-generation business process management. We offer a growing collection of independent editorial articles on BPM trends, issues, challenges and solutions, all targeted to business and IT BPM professionals.

We cover BPM standards, governance, technology and continuous process improvement, as well as process discovery, modeling, simulation and optimization, among many other areas. We follow case management, decision management, business rules management, operational intelligence, complex event processing and other related topics. We closely track important trends such as the rise of social BPM, mobile BPM and BPM in the cloud. We also explore BPM’s use in functional areas, such as supply chain and customer management, and in key verticals, such as financial services, health care, insurance and government.

ebizQ's other BPM-oriented content includes podcasts, webcasts, webinars, white papers, a variety of expert blogs, a lively online forum and much more.