Geekly Articles each Day
📜 ⬆️ ⬇️

A brief description of BPMN with an example

Brief Description of BPMN

Much has been written about BPMN. But the problem is that almost all of the information that can be found on the Internet is aimed at people who have previously encountered BPMN or another standard for modeling business processes. I propose to understand from scratch - what is BPMN? What are the features and advantages of this technology and why it appeared and turned out to be so in demand, at least abroad. Yes, and in our country she is more and more interested.

I also want to immediately draw your attention to the fact that here I will talk about BPMN notation, i.e. about business process modeling language. Of course, I will try to describe the basics of BPMN as simply as possible so that they can be understood even by beginners. But it is also important to understand that here I will speak about language, and not about methodology.
')
The methodology of business process modeling is a very broad concept, in fact, this is the very base whose knowledge is necessary for the practical application of business process modeling languages. I will talk about it in future articles more than once. Why do I emphasize this? Many people (and I also at one time) believe that it is enough to learn the language of business modeling, and you will be able to build business processes.

Practice shows that basic knowledge is indispensable. And to everyone who is just planning to study modeling, I strongly advise you first to familiarize yourself with the methodology, to understand the general principles of business modeling, to gain certain skills in business analysis. And only then proceed to the study of BPMN or any other language.

And to understand the causes of BPMN and all the nuances of modeling using this system of notations, you also need to know the basic problems that BPMN solves, what they used to work before BPMN appeared, and what difficulties they encountered. After all, the emergence of new systems and notations is impossible without an understanding of certain issues. And I think that this aspect is very important for understanding the essence of the question, what is actually BPMN.

Personally, I first met BPMN about eight years ago, when I began to study Bizagi Modeler system. I became interested in this system due to the fact that I had long understood the importance of modeling. Before that, I personally used IDEF0 and IDEF3, but there I faced certain limitations. The fact is that IDEF0 is somewhat limited in number of possibilities. And IDEF3 personally seemed overly strict and “dry” to me, it was difficult to model many types of business processes with the participation of software products.

At that time, Bizagi was a relatively simple module, in which there was a convenient editor for modeling (drawing) business processes, but there were no tools for executing business processes. But even then, the strict rules of BPMN adopted in the Bizagi system helped to avoid a significant number of errors that were so common in the usual “drawing” of business processes in graphic editors or on paper.

In search of an optimal solution for myself, I studied ARIS, 1C tools for business modeling, various business process modeling systems that were invented by various business consultants, both Russian and foreign. And, of course, I got acquainted with the BPMN notation.

When I first met BPMN, I liked it in many ways, the idea was very good, but from my point of view, the execution at that time was still “raw”. And I began to fully use BPMN about 3 years ago, after the tasks that I began to solve became so complicated that IDEF0 could not be fully applied. And it turned out that the notation was evolving, and now I actively use BPMN in my work.

BPM: BASIC TERMS


In order to understand what BPMN is, you need to understand that part of this abbreviation “BPM” has two decoding - Business Process Modeling and Business Process Management. In the first case, this is directly the modeling of the business process, and in the second, the management of business processes, i.e. a common system, part of which is Business Process Modeling.

At the same time, business process modeling is the basis and the main goal. With the help of modeling, we can describe any business process, and they can be executed in a variety of control systems.

There is another concept that is worth mentioning immediately - this is “BPMS”, i.e. Business Process Modeling System. This term describes the very control systems in which modeling is performed, as well as the execution of business processes.

We can say that BPMN is part of two major components:


LANGUAGE DESCRIPTION OF BUSINESS PROCESSES


When you first encounter the modeling of business processes, it is very difficult to understand where to start, where to look for a basis for understanding how business models are built. And I also faced it in due time.

And the basis here is the presence of a language describing business processes. And it is important to understand that this is really a language, like programming languages ​​or even languages ​​that people speak, it is also simple at the basic level and difficult if you start learning the nuances. This language has its own rules, semantics, spelling, its own laws, which must be studied and strictly followed them. On the other hand, like any artificial language, intended not for live communication, but for the strict and unambiguous description of some actions and processes, it is basically simpler than “living” languages, and its rules are strictly logical.

In addition, due to the limitations of the tasks that face this language, it is much more defined in terminology. But still there are a lot of nuances here, some combinations of “words” that carry their own semantic meaning. And it is very important to strictly follow the rules of combining different elements of the language and know the limitations (what is unacceptable with what to combine, how to begin the description, how to finish, etc.).

And like any technological language, the description of business processes has its own specific constructions, which will be extremely difficult to understand without a certain level of technological knowledge. Therefore, it is also important, in the first place, to understand the technologies themselves, for which it is intended to describe, to study the language of describing business processes.

For example, to model business processes, you will need to know such concepts as “conditions”, “cycle”, “decomposition”, etc.

It is important to understand: BPMN is not a language for describing IT systems. This notation is intended to describe the subject area of ​​a real business. And here both software systems and people (company employees, customers, suppliers) can be involved. This is the most important difference between this notation and graphic tools for describing programs.

A LITTLE STORY OF BPMN


For a better understanding of the features of business process modeling and the structure of a modeling language, I want to talk a little bit about the history of the appearance of BPMN notation. The development of a business process modeling system and specifications for it (modeling language) has been underway for a relatively long time.

The first version of BPMN 1.0 was released in May 2004 by the Business Process Management Initiative. This version had limited capabilities and was, so to speak, a “trial version” that needed numerous modifications.

The next version of BPMN 1.1 is released in January 2008, and here the Object Management Group, the organization that emerged from the merger of BPMI with another software company, was engaged in development and support.

Another release comes just a year later, BPMN version 1.2 is released in January 2009. OMG developer remains the same. The team that deals with the product, after the merger, practically does not change.

In January 2011, OMG releases a version of BPMN 2.0, and in December 2013 the latest release is released - BPMN 2.0.2. This version is offered to all users today, as the system has turned out to be stable, the modeling capabilities in it are very broad, and the modeling language (set of symbols) is mostly understood by all business users - both businessmen, business consultants, and technical specialists.

From the history we can conclude that the period of changes in this language has passed, and you can safely study and use it in practice.

Today BPMN is one of the most common methods for describing business processes that today both business users and software products designed to work with business models "understand". Those. This description language is also standard for creating executable algorithms in the field of business management.

I especially want to emphasize this point, as I myself was confronted at first with a lack of understanding, why make certain things difficult? After all, to describe business processes, for example, with GAP analysis (gap analysis) or to present a business model in a simplified form to the customer, you do not need the whole variety of BPMN elements. But when automation begins, when the business model becomes not just a convenient scheme, but can be exported to other software products as executable data, everything falls into place. The latest version of BPMN is really stable and all language requirements are justified.

WHAT IS THE NOTATION OF BPMN?


And here I want to make a small digression. The fact is that the translation of terms and concepts from English into Russian is a difficult task. An expert can usually find the most accurate word, but a completely different person is involved in translation, often without any idea of ​​the essence of the concepts that he translates. As a result, many inaccuracies appear, concepts become more complicated, confusion arises. I already wrote about the peculiarities of translation and the difficulties of using terms in comparison with graphics, for example, in the article Introducing IDEF0 notation and an example of use (see the “A few words about the benefits of graphics” section).

In this article I will operate with the concepts and terms that I use myself in practice. And they will not always coincide with the words that you met on Wikipedia or some translated manuals. The reason lies precisely in the fact that I, as a specialist, in some cases found for myself a more accurate translation of the English term. And the use of the word that I chose for myself helps to understand the essence of the process much faster.

Of course, I will explain all the terminology as needed. Therefore, I think that there will be no problems with understanding and terms. But still pay attention to this moment, I think the right one.

The language for describing business processes is based on the following basic objects:


Here I will not talk about all the existing elements of BPMN, there are actually a lot of them. And if necessary, you can always use the documentation on BPMN, where all existing elements are described in detail.

I will dwell only on the basic elements, without which no business model can do. For the first acquaintance with BPMN and understanding of the basic principles of the work of notations, this is enough.

EVENT (EVENT)


EVENT (EVENT)

Event - this is the event that occurred in the description of the process or choreography (I will tell about it separately). These events can be initial, final or intermediate.

For example, we describe the process of receiving an order from a customer by phone:


The end can be a variety of events. Here you can see the list of customer needs, save the order document, and create an invoice, tax, etc., on its basis.

ACTIVITY (ACTION)


ACTIVITY (ACTION)

Activity - these are the actions (tasks) that must be performed at a certain stage of the business process. When modeling, they are usually denoted as rectangles into which the essence of the action is entered.

Actions can be elementary, i.e. indivisible into some more simple actions, never elementary, i.e. such that when detailing are divided into a sequence of certain more simple actions.

Usually the actions are divided as follows:


GATEWAY (GATEWAY, SWIVEL)


GATEWAY (GATEWAY, SWIVEL)

A gateway is a control node that appears in the case of a conditional branch of a business process. Graphically depicted as a diamond.

Also, gateways are needed in cases where the procedure depends on certain factors. For example, when working with customers, the gateway appears at the stage when a customer makes a purchase decision - “yes or no”. With a positive decision, it is necessary to arrange the purchase, with a negative decision, to find out possible reasons for the refusal, to work with the “refusal”, etc.

FLOW (FLOW) AND MESSAGE FLOWS (FLOW OF MESSAGES)


FLOW (FLOW) AND MESSAGE FLOWS (FLOW OF MESSAGES)

Flow Flow - a sequence of actions, denoted as an arrow, and shows what action to take after what.

Message Flows are dashed arrows in the business model that show the messages exchanged between the business process participants. For example, if an order is transferred from the customer to the sales department for processing, it is accompanied by a message that contains information about this order. Also Message Flows can link two separate pools in a diagram.

Message Flows Association is another kind of lines, in contrast to messages, which are dashed lines, this option is displayed as a sequence not of segments, but of points. Needed in order to show the artifacts (about them - below).

POOL (POOL)


POOL (POOL)

A pool is an object describing a single process in a diagram. It may not be shown in the diagram, but it is always there. There can be several Pools on one diagram. The pool can be expanded to view details.

A pool may also contain so-called "tracks." They are needed to indicate the participants of the processes that are hidden in the pool. For example, a sales manager, a sales manager, perhaps an accountant or a cashier are involved in working with clients.

DATE OBJECT (DATA, DATA OBJECTS)


DATE OBJECT (DATA, DATA OBJECTS)

Data objects are items that show what data and documents are needed for an action to start, or that are the result of an action taken. The data object can be an order. For the manager, this will be the result of actions, and for the warehouse that receives the order - the beginning of the action (collection of goods and shipment).

MESSAGE


MESSAGE

This element is required to show communication between two participants in the process. This could be Email, messages within the collaboration system, correspondence in any of the instant messengers used by participants in the process, communications on the company's website, sms messages, etc.

ARTEFACT (ARTEFACT)


Under artifacts in BPMN understand objects that are not actions and not related to actions directly. This may be any documents, data, information that does not directly affect the execution of the process.

There are two types of artifacts:


The Object Group is another opportunity to combine several elements under a common symbol in order to save space on the diagram and increase the simplicity of its perception. Here, various activities gather under one common name. A group of objects can also always be considered in detail. The group looks like a rectangle with rounded corners, made a dashed line with dots.

Text Annotation (text annotations) is used for various refinements to the chart. This may be comments, explanations, other information that will increase the readability of the diagram. Annotations is an unclosed rectangle, made with a solid line, from which a line consisting of points leads to the annotation object.

EXECUTABLE AND UNEXPOSSIBLE BUSINESS PROCESSES


In business modeling, processes can be divided into two types - executable, which will actually work with special software, for example, Bizagi, and non-executable, i.e., business models that are needed only to study and demonstrate options for the enterprise.

In principle, there is not much difference between their construction; here only the desired result is important. Or, the business model will be applied only to facilitate mutual understanding between the customer (manager) and the consultant (performer). Either this notation will be subsequently used in any software environment for organizing the work of the company. In the usual manuals you will not find this division into two parts. But I personally think that it makes sense to conditionally divide business processes, since with different desired outcomes, different depth of detail and the choice of possible tools for work will be required.

Executable business processes must necessarily be built in strict compliance with all the rules of BPMN notation, because otherwise the software will not be able to work correctly with the business model. Executable processes are needed, for example, in enterprises where a process approach to activities is adopted. The software allows you to monitor all processes in real time, and based on the data obtained at each stage, the head of the company and departments will always be able to understand at what stage the work on this or that process is. This method can significantly improve management efficiency.

Non-executable business processes are needed solely to demonstrate any business model. This may be a diagram showing the real state of affairs in the enterprise; it may be a graphic illustration of the proposed changes during reengineering. In this case, of course, you can use any convenient tools, including the traditional for many IDEF0. And compliance with the rules of language modeling is necessary solely to achieve mutual understanding.

I recommend at the initial stage of working with BPMN to create non-executing business processes. This is really a very convenient notation in order to illustrate your ideas and suggestions, demonstrate the bottlenecks in business, even just for yourself to understand the structure of work of a company is very convenient with the use of notations. Visual graphics and strict rules help a lot.

The executable version requires deep knowledge of BPMN, as well as careful attention to every detail, since you, in essence, create a program (algorithm) for the computer, just use for this not a text language, but graphic notations. This case is for experienced professionals.

IS BPMN SUITABLE FOR SMALL AND MEDIUM BUSINESSES?


BPMN notations can and even should be used when working with small and medium-sized businesses. It is possible that you will not implement a business model at the software level, as this is always an additional cost, and in a small business there is no need for such tools to monitor and analyze work.

But, nevertheless, at the level of non-executable business processes, I use BPMN very actively. The fact is that for all the complexity of entry (ie, learning and ability to work with notations), the level of understanding of BPMN is low, i.e. no special knowledge and skills are required to read notations. Graphical notations are understood intuitively. And I have not yet met a single person for whom reading the notation would be difficult. This notation was created specifically to find a common language between the analyst and ordinary businessmen (managers).

As a result, as I wrote above, with the help of BPMN you save your time and time of the customer (manager) and achieve the highest level of mutual understanding. Notations do not allow “double reading”, and therefore they are very helpful in their work.

MINUSES AND IMPORTANT FEATURES OF BPMN


I have already said a lot about how convenient BPMN is. But to choose any tool, it is also important to understand the possible drawbacks. I will tell you about them now:


EXAMPLE OF PRACTICAL APPLICATION OF BPMN


Of course, without an example, a description of business process modeling would be incomplete and not completely clear. I decided to take as an example the process of securing customer orders, since this stage of work is present in almost any direction of the business, and therefore the implementation of this process in practice will be understandable without additional explanation to a wide circle of readers.

The result of this process should be providing the buyer with the names of the goods he needs.

This business process is as follows:

  1. Sales Manager receives information about customer needs (order).
  2. A CRM document is created in the CRM system.
  3. If the necessary goods are available, the manager creates an expenditure document in the accounting program. If the product is not available, the manager makes a request to the purchasing department.
  4. The purchasing department issues a request for suppliers to receive the goods.

At this point, we will consider the business process completed, since the buyer, now or after receiving goods from suppliers, will be able to buy everything necessary.

BPMN allows to model certain real processes at a certain level when modeling business processes. So, in our case, we leave behind the brackets the receipt of the order and the coordination of the list of goods and their value with the client. This can be detailed if necessary separately. Also in this example, we left behind brackets the processes of payment for goods, shipments, execution of expenditure documents, etc. And now we have another task - to describe the process of providing the buyer with the necessary goods.

The entry point is the receipt of the order from the buyer. The exit point is “product reservation”.
BPMN Sample Chart Image

Please note that after receiving the order, the arrow leads to the diamond stage, i.e. condition:


Why might need such a description of the business process? In a visual form, you can show your business customers how the relationship between sales and purchasing departments functions or should function in order to maximize customer needs. Also, using this business process, it will be much easier for technicians to create and customize software to automate the company's work, since the diagram clearly shows which processes should occur in what sequence, what information comes in at what stage, and also from what sources, which of the users should have access to certain processes and documents.

If necessary, this business process can be detailed, which also helps to see what and how it works (should work) to get the result.

HOW TO DEVELOP BPMN DIAGRAMS IN PRACTICE?


Here I want to share some tips on how to start and how to develop business process models. My advice is based on the knowledge of business modeling features and personal practical experience.

  1. It is necessary to schedule the beginning and end of the process. This is where the modeling of any process begins. So we designate the framework in which we will work.
  2. To begin with, it is best to describe a linear sequence of actions: step by step, the movement from the beginning to the final result. Further branches are added if necessary. In this order, it is much easier to work than to put two or more branches at the same time and get confused in the arrows, from where and where it goes.
  3. It's time to identify those responsible. Prior to that, we worked with events "in pure form." Now they have performers and responsible.
  4. Add data, footnotes, comments.

I personally create diagrams in this sequence. In principle, you can do it in some other way. The main thing is to avoid confusion in the modeling process.

What else would you like to advise:

  1. Create diagrams as less branched as possible. The more elements appear on your diagram, the more difficult it will be for you and your customers to read.
  2. Use the most simple and understandable terminology. It is very important that your customers, as well as technical specialists, who will work with diagrams, understand all (or almost all) of the terms without further explanation.
  3. All process names should be as informative and understandable as possible. Otherwise, the readability of the diagram will also be extremely low. For the names of the processes, the terms accepted in the particular organization for describing the work or simply intuitively understandable phrases are best suited.
  4. It is also important to call areas of responsibility for the employees of the company whose business model you describe. The simplest solution is to choose names among existing units. And if the necessary position or department in the company does not yet exist, do not be afraid to invent it yourself. But try to make the name also “speaking”, understandable for a wide range of business audiences.
  5. There should be enough subprocesses to avoid unnecessary detailing, but no more. Remember the sense of proportion. If there are too few subprocesses, then actions that would be worth hiding in them will be in the general process, creating additional objects, arrows, branches and, as a result, confusion. If you overdo it with the desire to put everything in the subprocesses, the diagram will lose its information content, and some changes in the subprocess will begin to affect the results of the whole process unnoticed.
  6. Do not be afraid to make mistakes! If you make a mistake in the executable methodology, it will become clear very quickly in the process of executing (debugging) the process. If you create a simple visual scheme, then minor errors are not so important, the main thing is that this scheme will help you and the people for whom you are doing it (customers, technical specialists) to understand all the nuances of your idea. And in any case, they learn from mistakes, and corrections to the business model can be quickly and simply.

And, of course, no matter what business modeling option you need, you shouldn’t be afraid of BPMN - it’s very easy to learn the notation, and even your minimal knowledge will not be needed to read such diagrams to your colleagues and clients, the modeling is very intuitive . Try it, you will also succeed.

More articles on this topic:



Also, currently I am preparing a book for publication and an online course in which I will describe in detail my own vision of the process approach to business, as well as my own practical experience in the field of functional and process modeling. Anyone can subscribe to the notice of the release of a new book on and other news link .

Source: https://habr.com/ru/post/331254/

More articles:


All Articles