![\"\"](\"https:\/\/pmb.com.ua\/en\/wp-content\/uploads\/2021\/01\/Alexey-Gromyko-bpmn-ukr.png\")
<\/figure>\nOleksii Gromyko has been working with BPMN 2.0 notation for over 10 years. “Visualizing processes using this notation is a mandatory step that I use in all my projects. It’s a key element and the value I create as a consultant,” explains the expert.<\/p>\n
Oleksii Gromyko’s portfolio includes over 50 projects where BPMN 2.0 was applied. His client list includes Nova Poshta, EVA, IDS Borjomi, Yuriay-Pharm, Ferrexpo, and dozens of other brands.<\/p>\n
To begin, could you tell us why and when consultants started using BPMN notation?<\/strong><\/p>\n Historically, the first notation appeared over 100 years ago. It was a simple flowchart. In the 1970s, it became clear that this was insufficient: flowcharts didn\u2019t allow for building process hierarchies (when there’s a large process, we can’t “drill down” to lower levels to clarify its subprocesses). Additionally, flowcharts didn\u2019t work with events. They didn\u2019t show, for example, that a client request could come in or that additional information might be needed at some point. This led to the need to develop the flowchart concept further, and thus, process notations emerged. In 2003, a community of leading consultants worldwide came together to develop a unified business process visualization language.<\/p>\n This didn\u2019t happen by chance in 2003. That\u2019s when automation started gaining tremendous momentum, and it became clear that businesses and IT needed to develop a clear system of notation. In 2004, BPMN 1.0 notation was introduced, and in 2009, a draft version of 2.0 was released, which was officially approved in 2011.<\/p>\n The entire model logic is based on determining who is responsible for performing each step. This means that it’s impossible for a failure to occur simply because each participant thought someone else was responsible for the work.<\/p>\n<\/blockquote>\n How does the second version of the notation differ from the previous one?<\/strong><\/p>\n The 2.0 suffix highlights that this is a mature notation, not something that was just invented yesterday. It has been validated over time. But, of course, this is not the only change. Along with BPMN 2.0 notation, the concept of “executable business processes” emerged. This means that if we model a business process using BPMN 2.0, it can definitely be automated in the form it was modeled. For IT specialists, this is a significant difference.<\/p>\n Moreover, this is the first notation where the responsibility of performers<\/em> is clearly defined. The entire model logic is based on determining who is responsible for performing each step. This means that it\u2019s impossible for a failure to occur simply because each participant thought someone else was responsible for the task.<\/p>\n Do I understand correctly that a process described using BPMN 2.0 notation can be universally understood by specialists around the world?<\/strong><\/p>\n On the one hand, all the elements of the notation are clearly defined. However, besides the rules, there is also the concept of “modeling style.” The style is what makes the model unambiguously readable within the company. These two aspects are always discussed in detail during our training sessions<\/a>.<\/p>\n When should companies start modeling processes? Do modeling styles differ for different companies?<\/strong><\/p>\n Using BPMN 2.0 notation, the same situation can be modeled in various ways. Therefore, we recommend that every organization develops an internal Modeling Agreement<\/strong>. This is standard practice. The style agreement complements the standard rules. If we draw an analogy, it’s like the general rules of a particular language and the editorial policy of a specific magazine.<\/p>\n When should companies start modeling processes?<\/strong><\/p>\n Every time their employees want to do something with business processes. For example:<\/p>\n make them clear for the whole team,<\/p>\n<\/li>\n create operational guidelines,<\/p>\n<\/li>\n define areas of responsibility,<\/p>\n<\/li>\n prepare the process for automation,<\/p>\n<\/li>\n set up a risk management and compliance system (ensuring conformity with internal or external requirements and standards),<\/p>\n<\/li>\n onboard new employees quickly,<\/p>\n<\/li>\n optimize processes.<\/p>\n<\/li>\n<\/ul>\n The first step for each of these tasks is to build a process model.<\/p>\n Where should a specialist begin when learning the notation?<\/strong><\/p>\n The tricky thing about the notation is that many of its elements seem intuitively clear. And if you start using them without consulting or clarifying the rules, it can lead to mistakes. It\u2019s like with a foreign language. A person may think they understand how to use a particular word, but in reality, they might be using it incorrectly.<\/p>\n The minimum set of symbols, standardized for all countries and languages, allows people from different specializations to unambiguously interpret what is happening in the process.<\/p>\n<\/blockquote>\n Why use notation if the process can be described in text?<\/strong><\/p>\n Visualizing a process frees you from the need to write things like: “Now N should perform this task and pass the result to M.” Instead, we just draw a rectangle and write the task the employee should complete, then use an arrow to show what happens next. We don\u2019t write “a client approached us,” we use the event “client inquiry.” And everyone understands what that means. The minimal set of symbols, standardized across all countries and languages, allows people from different fields to unambiguously interpret what is happening in the process.<\/p>\n\n
\n
Every time their employees want to make improvements to business processes.<\/p>\n<\/blockquote>\n\n
\n